ME ( Metric Extension ) Metric Is Not Collected For Some Databases

By default, ME metric will not be collected if associated target has a severity on response:state metric. So override this default by explicitly choosing Advanced option while creating ME.

For some databases, ME ( Metric Extension ) is not collecting data. But for the rest databases, it is working fine.

me_not_collecting

Checking the ME ( Metric Extension ) definition and found an advanced option is not selected.

selection

After creating a new version of this ME ( Metric Extension ) by checking this mentioned option, it works fine.

The reason is  this database has frequent Warning/Critical response metric alert. like  :

…..
….

Event Type=Metric Alert
Event name=Server_Adaptive_Threshold_Metric:instance_efficiency__response_time_pt
Metric Group=Server_Adaptive_Threshold_Metric
Metric=Response Time Per Txn
Metric value=258.497253691275
Key Value=SYSTEM
Rule Name=DEFAULT_RULESET_FOR_ALL_TARGETS,METRIC_ALERT_INCIDENT_CREATION
Rule Owner=
Update Details:
Metrics “Response Time Per Txn” is at 258.497
Incident created by rule (Name = Incident management rule set for all targets, Create incident for critical metric alerts [System generated rule]).

Use Corrective Action ( CA ) to Automate Archivelog Backup When FRA Usage is Over Threshold of Metric Extension ( ME ) in OEM

Take advantage of OEM Corrective Action ( CA ) to automate archive logs backup after FRA usage over threshold.

In Previous posts, we have created following related posts:

  1. Create a Metric Extension (ME) to Monitor FRA Usage on OEM
  2. Create an Incident Rule for Metric Extension ( ME ) to Monitor FRA Used in OEM

Now and then, FRA usage is easily over threshold, DBA needs logon system and manually run an archivelog backup.  It is easily to make database hung if FRA usage is 100%.

Here we use “Corrective Actions” to run a RMAN archivelog backup when the FRA usage is over warning / Critical threshold.

Subscribe to get access

Read more of this content when you subscribe today.

10) After a little while, an alert is received about “Corrective action status=Succeed”

Corrective action=RMAN_AUTO_BACKUP_ARCHIVELOGS
Corrective action owner=SYSMAN 
Corrective action status=Succeeded 
Corrective action output=SID: RACTEST1
HOME: /u01/app/oracle/product/11.2.0/dbhome_1
BASE: /u01/app/oracle
SID: RACTEST1
HOME: /u01/app/oracle/product/11.2.0/dbhome_1
BASE: /u01/app/oracle

Host=RACTEST1.ractest 
Target type=Cluster Database 
Target name=RACTEST-CLUSTER 
Categories=Capacity 
Message=The value of Flash Recovery Area % Used for +FRA is 82
Severity=Warning 
Event reported time=Dec 22, 2016 9:01:54 PM EST 
Target Lifecycle Status=Development 
Comment=RAC TEST
Operating System=Linux
Platform=x86_64
Associated Incident Id=209879 
Associated Incident Status=New 
Associated Incident Acknowledged By Owner=No 
Associated Incident Priority=High 
Associated Incident Escalation Level=0 
Event Type=Metric Alert 
Event name=ME$RACRecoveryAreaSpace:FRA_PERCENT_USED 
Metric Group=ME$RACRecoveryAreaSpace
Metric=FRA_PERCENT_USED
Metric value=82
Key Value=+FRA
Key Column 1=FRA_NAME
Rule Name=Flash Recovery Area Percent Used for ME

Create an Incident Rule for Metric Extension ( ME ) to Monitor FRA Used in OEM

Step by step demonstrates how to create an incident rule for a Metric Extension ( ME).

In another post, we created a Metric Extension (ME) to Monitor FRA Usage on OEM. Here we need create an Incident Rule for creating an incident and notification for all events of Warning or Critical.

Subscribe to get access

Read more of this content when you subscribe today.

8) After a couple of minutes, the below alert is received:

Host=ractest1 
Target type=Cluster Database 
Target name=RACTEST
Categories=Capacity 
Message=The value of Flash Recovery Area % Used for +FRA is 80 
Severity=Warning 
Event reported time=Dec 22, 2016 3:08:43 AM EST 
Target Lifecycle Status=TEST
Comment=RACTEST CLuster
Operating System=Linux
Platform=x86_64
Associated Incident Id=209693 
Associated Incident Status=New 
Associated Incident Owner=TESTUSER
Associated Incident Acknowledged By Owner=No 
Associated Incident Priority=High 
Associated Incident Escalation Level=0 
Event Type=Metric Alert 
Event name=ME$RACRecoveryAreaSpace:FRA_PERCENT_USED 
Metric Group=ME$RACRecoveryAreaSpace
Metric=FRA_PERCENT_USED
Metric value=80
Key Value=+FRA
Key Column 1=FRA_NAME
Rule Name=RACTEST Ruleset,Flash Recovery Area Percent Used for ME 
Rule Owner=TESTUSER
Update Details:
The value of Flash Recovery Area % Used for +FRA is 80
Incident created by rule (Name = RACTEST Ruleset, Flash Recovery Area Percent Used for ME; Owner = TESTUSER).

Create a Metric Extension (ME) to Monitor FRA Usage on OEM

OEM Metric Extension (ME) is a great feature for developing customized metrics, which are unavailable by default.

As we know “Archive Area % Used” metric does not work for using FRA as archive destination when the destination is set to USE_DB_RECOVERY_FILE_DEST. We only receive after “Recovery Area % Used” metric triggers when it hits a Warning threshold of 85% full, and Critical of 97% full.

But the fixed thresholds of 85( Warning )/97( Critical) is not good enough for handling FRA full. So we developed a customized more flexible way to  monitor and alert when FRA is used as archive destination.

Subscribe to get access

Read more of this content when you subscribe today.

So, the Metric Extension ( ME) is created successfully, in another post, we will create a Incident Rule which will create an incident and notification for all the over threshold Warning and Critical alerts.

Create an Incident Rule for Metric Extension ( ME ) to Monitor FRA Used in OEM

Further more, we will create a Corrective Action ( CA ) against this Metric Extension ( ME ) to start a archive log backup automatically.

Use Corrective Action ( CA ) to Automate Archivelog Backup When FRA Usage is Over Threshold of Metric Extension ( ME ) in OEM

Plugin versions on agent does not support target type oracle_pdb

It seems a bug.

Tried to add a CDB database with PDBS into 12c OEM, and got the following errors.

Failed RACTEST : Plugin versions on agent https://oemnode1:3872/emd/main/  does not support target type oracle_pdb

 Actually there is another CDB database of same cluster has been added onto OEM months ago. So the error message is misleading.

Below actions were taken, then CDB database was added onto OEM successfully.

  1.  Shutdown and startup CDB database with all PDBS  open.
  2. Bounced OEM agent.
  3. Manually added cluster DB, cluster DB instances, and pluggable databases successfully.