RE: Clearing stateless events in OEM 12c

From: Jorgensen, Finn <>
Date: Thu, 12 Jul 2012 10:58:09 -0400
Message-ID: <9CE162BC5ED2C643956B526A7EDE46FF0321DEC41BEC_at_EXM-OMF-04.Ceg.Corp.Net>


Thanks a lot for your very thorough reply to my question. Replies to your points:

  1. I have not run into ORA-600's/7445's yet in my test databases so I did not know this. Good information
  2. Multiple instances of the same ORA- error captured in the same scan of the alert log does already create a single incident with multiple events and can be cleared by clearing just the one incident. However, if the error persists across multiple scans of the alert log multiple incidents will be created. I had hoped it was just incrementing the counter on the existing incident like you are suggesting I open a enhancement request for. I will do that. 3.1) I tried the emcli command. It doesn't work for me. I run this command and get this result: emcli clear_stateless_alerts -older_than=0 -target_type=oracle_database -target_name=UC4DEV

No alert found.

3.2) I have such a rule. In fact, 12c comes with such a rule out of the box. It clears stateless alerts after 7 days. I will modify this to suit my needs. 3.3) This is what I was asking for in the first place :)

A point of my own:

4) the support person later suggested going to the database target and clicking on "Oracle database->Logs->Alert log errors" and then clicking on "clear every open alert". This is a good idea except all the alerts in this screen has a severity of [check mark] so when I click on the button to clear them it says there are no open alerts. This is despite incidents and events being open in the incident manager. Anyways all that is documented in my SR 3-5896374157. If you have access you can see I have many SR's both open and closed about 12c problems. I use this email address on MOS.

Thanks again for your reply.


-----Original Message-----
From: Peter Sharman [] Sent: Wednesday, July 11, 2012 6:03 PM
To: Jorgensen, Finn; oracle Freelists ( Subject: RE: Clearing stateless events in OEM 12c

Actually, the support answer is technically correct, if a little undiplomatic (that's good coming from an Aussie!) ;)

A couple of points on this:

Firstly, alert log monitoring is a bit special. There is a specific subset of Oracle errors (such as ORA-600, etc.) that are handled as ADR incidents. These are considered critical errors in software. For this subset of errors, an ADR incident and also an EM12c incident is automatically created for each occurrence and a Problem object (in EM12c) is also created for it. The Problem object is meant to represent the underlying cause of these incidents. The Problem object will have a count and link to its associated incidents. So if another instance of the same ORA-600 error occurs, then another ADR incident and EM 12c incident is created and the incident count in the Problem object is incremented to 2. To resolve the Problem, users are expected to use the Problem object in EM and use Support Workbench to package the diagnostic data and send them to Support.

Secondly, for other errors in the alert log (i.e. errors are not considered critical errors in software), then you can choose to create an Incident for it in EM. If the same error occurs in the future, then there is no automatic grouping of these errors into one incident (an enhancement request you might want to log here is that there should really be one metric alert for the same alert log error and we should just count the no. of occurrences of that error.)

Thirdly, for this specific case - manual clearing of this 'stateless' metric alert - then this is the solution:

1) Use EMCLI clear_stateless_alert ==> use this option to do bulk clearing of these metric alerts
2) Create a rule to automatically clear the alert log metric alert after it is has been open for xx days This avoids the accumulation of these alerts if someone has forgotten to clear them after they've resolved the issue
3) In the next patchset,  the Incident Manager UI will allow you to bulk select and manually clear incidents (this assumes that it contains events that are manually clear-able).

Thirdly, as you're no doubt well aware the UI has been completely rewritten from earlier releases. My personal perspective is that the UI is a huge improvement over earlier versions. Of course, that doesn't mean it's perfect by any means, so if there are operations like this that are problematic for you, log it as an enhancement request for the UI.



Pete Sharman
Principal Product Manager
Enterprise Manager Product Suite
33 Benson Crescent CALWELL ACT 2905 AUSTRALIA Phone: +61262924095 | | Fax: +61262925183 | | Mobile: +61414443449 

"Controlling developers is like herding cats." Kevin Loney, Oracle DBA Handbook

"Oh no, it's not, it's much harder than that!" Bruce Pihlamae, long term Oracle DBA

-----Original Message-----
From: Jorgensen, Finn [] Sent: Tuesday, 3 July 2012 3:58 AM
To: oracle Freelists ( Subject: Clearing stateless events in OEM 12c

Hi List.
I'm building a OEM 12c environment for monitoring and tuning my employers databases. This is to replace the old OEM environment we currently use. One of many problems I've run into is that in 12c you can't select multiple incidents in the incident manager and then clear them all with one mouse click. You have to select and clear them one at a time. This becomes a problem when you are monitoring things like the alert log for certain ORA- errors which can easily produce several hundred incidents before getting picked up and fixed.

I opened an SR with Oracle to see if there is a resolution to this problem. Their answer was a reference to Doc ID 1454960.1 which suggests using emcli calls to clear the incidents. While that's possible it's not very user friendly. Does anybody else have experience with this problem? Anybody have a different solution? Why wouldn't Oracle just let me search and "shift-select" multiple incidents and then just hit the "Clear" button like they did in 10g? This seems like a big step backwards.


>>> This e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely for the addressee. If you are not the intended recipient, do not use the information in this e-mail in any way, delete this e-mail and notify the sender. -IP2


Received on Thu Jul 12 2012 - 09:58:09 CDT

Original text of this message