Tag: OEM

OEM 13c and Amazon’s RDS

Amazon released a note late last year about Amazon’s RDS is now supporting Oracle Enterprise Manager Agents.
Amazon RDS supports agent version 12 (12.1.0.5), 13R1 and 13R2 (13.2.0.0).
You can use this to monitor your DB instances running on Amazon’s RDB but there are some limitations, like the fact you cannot execute jobs against those targets.
See below for more information about this.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Oracle.Options.OEMAgent.html
Thanks,
Alfredo

Enable NFS mount point monitoring in OEM 13c

OEM doesn’t monitor NFS mount points by default. In case you need to monitor NFS mount points you have 2 options.
Either create a metric extension using an OS script or to enable a property called EM_MONITOR_ALL_DISKS in the agent’s configuration file.
There are two ways to accomplish the second option. You can go and modify the emd.properties file or you can use the OEM console to modify it.
The OEM console can submit a job called “Agents Configuration Operation”. This job is going to prompt you for a name and the agents you want to modify the property. The Parameters tab has all the available parameters to modify. Just set the EM_MONITOR_ALL_DISKS to true and submit the job.

If you want to modify this manually. Just follow the instruction in the MOS note 1513537.1.
Thanks,
Alfredo

Exclusion not working in OEM 13c Rule Sets

While setting up Rules and RuleSets you may want to exclude either target types or alert categories from your notifications. Well, there’s an issue if you try to do this in OEM 13c.
If you configure a Rule that has the exclusion and contains more than one category, then you will keep receiving alerts from it. So the exclusion won’t work.
In order to fix it you need to apply a patch or the January 2018 BP for OEM.
MOS note (Doc ID 2347238.1) shall be used as a reference.
Thanks,
Alfredo

“Failed to find the OPatch patch directory” while applying patch 25105555 ( 13.2.0.0.161231) from OEM console

While applying patch 25105555 ( 13.2.0.0.161231) to an agent using the “provisioning and Patching” console from OEM 13.2 and choosing the “Upgrade OPatch” option, got this error:
———- Error Message ———-
Error: 010
Failed to find the OPatch patch directory “/tmp/p6880880_600000000057471_2000_0/oracle/OPatch”.
If you chose “No” for the “StagePatches” option, ensure that you manually place the patch at the required location and retry the operation.
———– End Message ———–
Tue Aug 27 15:41:48 2017 – Patching aborted.
You have to follow the solution section from below MOS note:
EM 13c: Applying EM-AGENT Bundle Patch 25105555 ( 13.2.0.0.161231) from Enterprise
Manager 13.2 Cloud Control Fails with Message: Error: 010 Failed to find the OPatch patch directory (Doc ID 2229452.1)
It depends on whether you have an online or offline OMS configuration.
After doing this I was able to apply patch 25105555 to the agent.
Hope this helps.

Alfredo

2017 April PSU – OEM sending tablespace related alerts every collection schedule

I noticed that several alerts related to tablespace full were sent from OEM every collection schedule. At first sight I thought this may be related to OEM itself but after spending some significant time in MOS found a bug note stating that the 2017 April PSU patch was responsible.



The issue is that dba_tablespace_usage_metrics is not accounting for autoextend datafiles. So even if you add a new datafile, your used space will continue be reported as it was before.
You need to apply patch 26198757 on top of April PSU.
Hope this help you to avoid all this noise and happy patching.
Thanks,

Alfredo

OMS responded illegally [ERROR- Failed to Update Target Type Metadata] in 13c R2

I want to discuss about this OMS error coming from the agent’s heartbeat status. The agent shows with an unreachable status but is actually up and running.
$: emctl status agent
Oracle Enterprise Manager Cloud Control 13c Release 2
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
—————————————————————
Agent Version          : 13.2.0.0.0
OMS Version            : (unknown)
…
Last Reload            : (none)
Last successful upload                       : (none)
Last attempted upload                        : (none)
Total Megabytes of XML files uploaded so far : 0
Number of XML files pending upload           : 2,210
Size of XML files pending upload(MB)         : 2.89
Available disk space on upload filesystem    : 56.39%
Collection Status                            : Collections enabled
Heartbeat Status       : OMS responded illegally [ERROR- Failed to Update Target Type Metadata]
Last attempted heartbeat to OMS              : 2017-01-24 21:09:21
Last successful heartbeat to OMS             : (none)
Next scheduled heartbeat to OMS              : 2017-01-24 21:09:51
—————————————————————
Agent is Running and Ready
In this case the agent is not able to upload the metadata because is different in the OMS.
This is mainly due to a patch in the agent side that is missing in the OMS. By mistake I applied the latest bundle patch to the agent before applying it to the OMS.
Just another proof that any patches have to be installed to the OMS first then the agents.
Thanks,

Alfredo

Upgrade OPatch for OEM 13c R2 Agents

Opatch utility has to be updated often as Oracle delivers regular updates to it. I was used to version 12 and it only required an overwrite of the OPatch directory. Well, not anymore with version 13c R2.
I will walk you through an OPatch upgrade from 13.8 to 13.9 version.
First export your agent ORACLE_HOME:
$: export ORACLE_HOME=/u01/oracle/oemagent/agent_13.2.0.0.0/
Verify the current OPatch version:
$: $ORACLE_HOME/OPatch/opatch version
OPatch Version: 13.8.0.0.0
OPatch succeeded.
Download and unzip the 13.9 version in a temporary directory:
$: unzip p6880880_139000_Generic.zip
Archive:  p6880880_139000_Generic.zip
   creating: 6880880/
  inflating: 6880880/README.txt
  inflating: 6880880/opatch_generic.jar
  inflating: 6880880/version.txt
As you can see, now we have some zip files and a java file. Execute java to upgrade OPatch as follows:
$: $ORACLE_HOME/jdk/bin/java -jar opatch_generic.jar -silent oracle_home=$ORACLE_HOME
Launcher log file is /tmp/OraInstall2017-01-19_08-47-21PM/launcher2017-01-19_08-47-21PM.log.
Extracting the installer . . . . Done
Checking if CPU speed is above 300 MHz.   Actual 3000.000 MHz    Passed
Checking swap space: must be greater than 512 MB.   Actual 16383 MB    Passed
Checking if this platform requires a 64-bit JVM.   Actual 64    Passed (64-bit not required)
Checking temp space: must be greater than 300 MB.   Actual 18842 MB    Passed
Preparing to launch the Oracle Universal Installer from /tmp/OraInstall2017-01-19_08-47-21PM
Installation Summary
Disk Space : Required 6 MB, Available 5,229 MB
Feature Sets to Install:
        Next Generation Install Core 13.9.1.0.0
        OPatch 13.9.1.0.0
        OPatch Auto OPlan 13.9.1.0.0
Session log file is /tmp/OraInstall2017-01-19_08-47-21PM/install2017-01-19_08-47-21PM.log
Loading products list. Please wait.
 1%
 40%
Loading products. Please wait.
 43%
 …
 97%
 99%
Updating Libraries
Starting Installations
 1%
 …
 91%
 92%
Install pending
Installation in progress
 Component : oracle.swd.opatch 13.9.1.0.0
Copying files for ‘oracle.swd.opatch 13.9.1.0.0 ‘
 Component : oracle.glcm.osys.core 13.9.1.0.0
Copying files for ‘oracle.glcm.osys.core 13.9.1.0.0 ‘
 Component : oracle.glcm.oplan.core 13.9.1.0.0
Copying files for ‘oracle.glcm.oplan.core 13.9.1.0.0 ‘
 Component : oracle.glcm.opatch.common.api 13.9.1.0.0
Copying files for ‘oracle.glcm.opatch.common.api 13.9.1.0.0 ‘
 Component : oracle.glcm.opatchauto.core 13.9.1.0.0
Copying files for ‘oracle.glcm.opatchauto.core 13.9.1.0.0 ‘
Install successful
Post feature install pending
Post Feature installing
 Feature Set : apache_commons_cli_lib
 Feature Set : oracle.glcm.opatchauto.core.actions.classpath
Post Feature installing ‘apache_commons_cli_lib’
 Feature Set : oracle.glcm.opatchauto.core.binary.classpath
 Feature Set : oracle.glcm.osys.core.classpath
Post Feature installing ‘oracle.glcm.opatchauto.core.binary.classpath’
Post Feature installing ‘oracle.glcm.osys.core.classpath’
 Feature Set : apache_commons_compress_lib
 Feature Set : oracle.glcm.opatchauto.core.wallet.classpath
Post Feature installing ‘oracle.glcm.opatchauto.core.actions.classpath’
Post Feature installing ‘apache_commons_compress_lib’
 Feature Set : oracle.glcm.opatchauto.core.classpath
Post Feature installing ‘oracle.glcm.opatchauto.core.wallet.classpath’
Post Feature installing ‘oracle.glcm.opatchauto.core.classpath’
 Feature Set : oracle.glcm.opatch.common.api.classpath
 Feature Set : oracle.glcm.oplan.core.classpath
Post Feature installing ‘oracle.glcm.opatch.common.api.classpath’
Post Feature installing ‘oracle.glcm.oplan.core.classpath’
Post feature install complete
String substitutions pending
String substituting
 Component : oracle.swd.opatch 13.9.1.0.0
String substituting ‘oracle.swd.opatch 13.9.1.0.0 ‘
 Component : oracle.glcm.osys.core 13.9.1.0.0
String substituting ‘oracle.glcm.osys.core 13.9.1.0.0 ‘
 Component : oracle.glcm.oplan.core 13.9.1.0.0
String substituting ‘oracle.glcm.oplan.core 13.9.1.0.0 ‘
 Component : oracle.glcm.opatch.common.api 13.9.1.0.0
String substituting ‘oracle.glcm.opatch.common.api 13.9.1.0.0 ‘
 Component : oracle.glcm.opatchauto.core 13.9.1.0.0
String substituting ‘oracle.glcm.opatchauto.core 13.9.1.0.0 ‘
String substitutions complete
Link pending
Linking in progress
 Component : oracle.swd.opatch 13.9.1.0.0
Linking ‘oracle.swd.opatch 13.9.1.0.0 ‘
 Component : oracle.glcm.osys.core 13.9.1.0.0
Linking ‘oracle.glcm.osys.core 13.9.1.0.0 ‘
 Component : oracle.glcm.oplan.core 13.9.1.0.0
Linking ‘oracle.glcm.oplan.core 13.9.1.0.0 ‘
 Component : oracle.glcm.opatch.common.api 13.9.1.0.0
Linking ‘oracle.glcm.opatch.common.api 13.9.1.0.0 ‘
 Component : oracle.glcm.opatchauto.core 13.9.1.0.0
Linking ‘oracle.glcm.opatchauto.core 13.9.1.0.0 ‘
Linking in progress
Link successful
Setup pending
Setup in progress
 Component : oracle.swd.opatch 13.9.1.0.0
Setting up ‘oracle.swd.opatch 13.9.1.0.0 ‘
 Component : oracle.glcm.osys.core 13.9.1.0.0
Setting up ‘oracle.glcm.osys.core 13.9.1.0.0 ‘
 Component : oracle.glcm.oplan.core 13.9.1.0.0
Setting up ‘oracle.glcm.oplan.core 13.9.1.0.0 ‘
 Component : oracle.glcm.opatch.common.api 13.9.1.0.0
Setting up ‘oracle.glcm.opatch.common.api 13.9.1.0.0 ‘
 Component : oracle.glcm.opatchauto.core 13.9.1.0.0
Setting up ‘oracle.glcm.opatchauto.core 13.9.1.0.0 ‘
Setup successful
Save inventory pending
Saving inventory
 93%
Saving inventory complete
 94%
Configuration complete
Logs successfully copied to /u01/app/oraInventory/logs.
Verify the new OPatch version

$: $ORACLE_HOME/OPatch/opatch version
OPatch Version: 13.9.1.0.0
OPatch succeeded. 
Thanks,

Alfredo

OEM Agent Plug-in Testing

Today I want to write about Oracle Enterprise Manager (OEM) 12c plug-ins and how to test them. 

OEM is divided into two logical parts, the EM Platform and the EM Plug-ins. The EM Platform basically consists of the UI console, job system, metrics, EM agent, etc. The EM Plug-ins are modules that you can attach to you EM Platform to extend the monitoring functionality. As a result, we have plug-ins for Oracle Databases, Fusion Middleware, even hardware or 3rd-party vendors like MS SQL Server.

The plug-ins have a set of Perl scripts that the agent uses to compute status and metrics for the targets. You can find these scripts under “/plugins//scripts”.
Let us see an example:

Fusion Middleware plug-in version 12.1.0.7:
$ cd  /plugins/oracle.sysman.emas.agent.plugin_12.1.0.7.0/scripts

In there you can see tons of Perl scripts. These scripts are being used by the agent to compute response and metrics for the targets registered in the agent.

Now let’s say you have a Web Cache target that shows an incorrect status in OEM and you want to know how the agent computes the response status of this target.

 $ ls webcache*.pl
webcacheesm.pl  webcacheIsStandalone.pl  webcacheresource.pl  webcacheresponse.pl

You can see that there’s a response script available. 
Now the question is, how to test it?

Based on the MOS id 1534087.1, you can create an env.sh script to load the required variables to your shell. I did create the env.sh file and source it:

$ . env.sh

Now I’m able to test the webcacheresponse.pl:

$ perl webcacheresponse.pl
em_result=1

Looks like having 1 as the result means that the Web Cache is up per the script’s logic. This result is passed to the agent and finally to the OMS.

Hope this is helpful for you while trying to investigate status related issues with your targets.
Thanks,

Alfredo

ORA-21780: Maximum number of object durations exceeded.

I noticed that the Oracle Enterprise Manager (OEM) repository database was throwing ORA-21780 errors every 10 seconds. This is what I found in the alertlog file:
Mon May 11 17:51:56 2010
Errors in file /oracle_binaries/app/diag/rdbms/oem/OEM1/trace/OEM1_smon_12465.trc:
ORA-21780: Maximum number of object durations exceeded.
Errors in file /oracle_binaries/app/diag/rdbms/oem/OEM1/trace/OEM1_smon_12465.trc:
ORA-21780: Maximum number of object durations exceeded.
Now looking at the SMON trace file:
*** 2015-05-11 17:56:57.999
SMON: following errors trapped and ignored:
ORA-21780: Maximum number of object durations exceeded.
*** 2015-05-11 17:57:08.155
         Drop transient type:   SYSTPE9CqEeDOZcXgUPAKvfBsfQ==
*** 2015-05-11 17:57:08.155
SMON: following errors trapped and ignored:
ORA-21780: Maximum number of object durations exceeded.
*** 2015-05-11 17:57:18.245
         Drop transient type:   SYSTPE9CqEeDOZcXgUPAKvfBsfQ==
*** 2015-05-11 17:57:18.245
SMON: following errors trapped and ignored:
ORA-21780: Maximum number of object durations exceeded.
As per MOS note 1081950.1, this is a non-reproducible issue and the cause is not identified.
It also states that this only happens in RAC environments.  The workaround provided is to manually drop those types, so let’s drop them.
First, we need to identify the problematic types and the owner.
SQL> select distinct(o.OWNER#) from obj$ o, type$ t
where o.oid$ = t.tvoid and
bitand(t.properties,8388608) = 8388608 and (sysdate-o.ctime) > 0.0007;
NAME                         
——————————
115
Then we need to identify the username of the previous query:
SQL> select username from dba_users where user_id=115;
USERNAME
——————————
SYSMAN
And finally, identify and drop the types:
SQL> alter session set nls_date_format=’DD-MON-YYYY HH24:MI:SS’;
set pagesize 1000
select ‘DROP TYPE SYSMAN.”‘||o.name||'” FORCE;’ from obj$ o, type$ t
where o.oid$ = t.tvoid and
bitand(t.properties,8388608) = 8388608 and (sysdate-o.ctime) > 0.0007;
Session altered.
SQL> SQL>   2    3
‘DROPTYPESYSMAN.”‘||O.NAME||'”FORCE;’
——————————————————–
DROP TYPE SYSMAN.”SYSTPE/jlp3fkcwzgUPAKvfAxHg==” FORCE;
DROP TYPE SYSMAN.”SYSTPFHGYs/8tGgLgUPAKvfAKqg==” FORCE;
DROP TYPE SYSMAN.”SYSTPFOpLxs22zYbgUPAKvfAnig==” FORCE;
DROP TYPE SYSMAN.”SYSTPFe/P5cSmQTDgUPAKvfA/HQ==” FORCE;
DROP TYPE SYSMAN.”SYSTPFWL+wF51Fc/gUPAKvfByCA==” FORCE;
DROP TYPE SYSMAN.”SYSTPFiwpaJHEvQTgUPAKvfAwiw==” FORCE;
DROP TYPE SYSMAN.”SYSTPFkBG80DWv1ngUPAKvfBD9Q==” FORCE;
DROP TYPE SYSMAN.”SYSTPFkEdeM4CTOngUPAKvfBrTQ==” FORCE;
8 rows selected.
After those types were dropped, no more error messages appeared in the alertlog file.
Thanks,
Alfredo

OEM 12c very slow after upgrade to 12.1.0.4

I noticed that OEM 12c console was very slow a few hours after the upgrade to 12.1.0.4 version. 

Looking at the repository DB, found several OMS sessions consuming significant CPU resources.
Bug 19199023 explains that some SQL queries executed against the repository consume high CPU on the servers. This bug affects the DB plug-in 12.1.0.6 and the patch 19176910 should be applied to the plug-ins.

More information available on MOS note, 12.1.0.4 OEM: High CPU utilization on Repository Database due to SYSMAN query WITH TARGETGUID AS (SELECT target_guid, host_name FROM mgmt_targets (Doc ID 1912172.1)
Thanks,

Alfredo