In our 11gR2 RAC databse, we got some ORA-00600 errors in the alert log file. These errors have been fixed by applying the oracle patches. But, in the Oracle Enterprise Manager these old alerts are not cleared. To manually clear the alerts, I did the following steps;

1. Go to Enterprise Manager Home Page > select Instance Name > Metrics and policy settings > changed the view to all metrics > Choose the “Generic Internal Error” metric to disable it.

Follow the links below to see the steps;

http://www.oracle-class.com/wp-content/uploads/2011/11/EM1.png

http://www.oracle-class.com/wp-content/uploads/2011/11/EM2.png

http://www.oracle-class.com/wp-content/uploads/2011/11/EM3.png

http://www.oracle-class.com/wp-content/uploads/2011/11/EM4.png

2. Go to the Instance from the SSH client > export correct environment for the database instance > as the oracle database software owner issue “emctl clearstate agent” command.

3. Go to console and check the alert is cleared now,

4. To enable the metric now for future alerts; Go to DB Console Home Page > select Instance Name > Metrics and policy settings > changed the view to all metrics > Click on “Generic Internal Error” metric and enable it again by adding the characters “.*” in the critical threshold field and save the changes.

How to manually clear EM Grid Control alerts

We can use the procedure outlined below to clear outstanding warning and critical alerts which are displayed on the EM Grid console home page. Normally these alerts get cleared automatically when the event ot threshold which caused these events in the first place is longer in the ‘critical’ or ‘warning’ state.

But there are some times when we wish to manually clear the alerts – there are some notes on Metalink which document cases where alerts are not cleared even after the event which caused them no longer exists – and also we may want to clear all the warning alerts which concern alerts related to logins by SYS user – out of the box auditing of the SYS user logins is enabled and every time SYS connects, it will generate a warning alert.

In a forthcoming post I will detail now to create a customised monitoring template and deploy it enterprise wide.

Let us see an example where we would like to clear outstanding alerts related to database ADRP.

The table SYSMAN. MGMT_TARGETS has information on the monitored targets and the table SYSMAN. MGMT_CURRENT_SEVERITY contains data related to all critical and warning alerts.

We can query the MGMT_CURRENT_SEVERITY table and see that there are two rows in the table pertaining to ADRP database.

SQL> select TARGET_NAME,TARGET_TYPE ,TARGET_GUID  from  mgmt_targets
  2  where TARGET_NAME like 'adrp%';

TARGET_NAME
--------------------------------------------------------------------------------
TARGET_TYPE
----------------------------------------------------------------
TARGET_GUID
--------------------------------
adrp
oracle_database
90BDD386E4F020F5356060DB6B94CAA3


SQL> select count(*) from mgmt_current_severity where TARGET_GUID='90BDD386E4F020F5356060DB6B94CAA3';

  COUNT(*)
----------
         2

We can use this procedure to delete the required rows – note that this block will in turn call the EM_SEVERITY package which will perform the clean up of dependant internal tables

DECLARE
   CURSOR c1 IS
     SELECT s.target_guid,
            s.metric_guid,
            s.key_value
       FROM mgmt_targets t JOIN mgmt_current_severity s
            ON s.target_guid = t.target_guid
      WHERE LOWER(t.target_name) LIKE 'adrp%'
        AND t.target_type = 'host';


BEGIN
    FOR r IN c1 LOOP
       em_severity.delete_current_severity(r.target_guid,
          r.metric_guid,
          r.key_value);
       DELETE from sysman.mgmt_severity
       WHERE
         target_guid = r.target_guid AND
         metric_guid = r.metric_guid AND
         key_value = r.key_value;


    END LOOP;
    COMMIT;
end;
/

SQL> select count(*) from mgmt_current_severity where TARGET_GUID='90BDD386E4F020F5356060DB6B94CAA3';

  COUNT(*)
----------
         0