RE: Clearing stateless events in OEM 12c
Date: Wed, 11 Jul 2012 15:02:55 -0700 (PDT)
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.
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
From: Jorgensen, Finn [mailto:Finn.Jorgensen_at_constellation.com] Sent: Tuesday, 3 July 2012 3:58 AM
To: oracle Freelists (Oracle-L_at_freelists.org) Subject: Clearing stateless events in OEM 12c
I'm building a OEM 12c environment for monitoring and tuning my employers databases. This is to replace the old OEM 10.2.0.5 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