RE: clearing 'stateless' alerts in OEM 12c not functioning as expected

  • From: Matt Adams <MAdams@xxxxxxxxxxxxxxxxxxx>
  • To: Peter Sharman <pete.sharman@xxxxxxxxxx>, ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 8 Oct 2015 21:07:53 +0000

Yes, I did and that one didn't really help. It's also one of the many web
pages that are strangely similar (although given the presentation she gave at
the Great Lakes Oracle Conference and the conversation we had after it, I'd
venture a guess she may the original and everyone else is copying her page).

Unfortunately, the method she describes for selecting multiple incidents in the
OEM Gui does not work for me. Any attempt to select more than 25 at a time has
problems.

Matt

From: Peter Sharman [mailto:pete.sharman@xxxxxxxxxx]
Sent: Thursday, October 08, 2015 4:51 PM
To: Matt Adams; ORACLE-L
Subject: RE: clearing 'stateless' alerts in OEM 12c not functioning as expected

Matt

Did your googling return this?
http://dbakevlar.com/2013/03/em12c-clearing-stateless-alerts-vs-clearing-other-alerts/
:)

I've worked with other customers who don't clear the alerts. One reason may be
that the management of the issue is done through another tool like Service Now,
and all EM does is send SNMP traps to Service Now. Just a thought that you
might have a similar setup.

Pete
[Oracle logo]
Pete Sharman
Database Architect, DBaaS / DBLM
Enterprise Manager Product Suite
33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
Phone: +61262924095<tel:+61262924095> | | Mobile: +61414443449
Email: pete.sharman@xxxxxxxxxx<mailto:pete.sharman@xxxxxxxxxx> Twitter:
@SharmanPete LinkedIn: au.linkedin.com/in/petesharman
Website: petewhodidnottweet.com
________________________________
"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: Matt Adams [mailto:MAdams@xxxxxxxxxxxxxxxxxxx]
Sent: Friday, October 9, 2015 7:40 AM
To: ORACLE-L <oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>>
Subject: clearing 'stateless' alerts in OEM 12c not functioning as expected

This is my 9th day at my new job here, and every day, I understand less and
less about this environment.

Such as why they would allow a production database to rack up roughly 3300
unacknowledged incidents on the OEM 12c console. The vast majority of these
incidents appear to be for ORA-600 errors that appeared in the alert log, and
the vast majority of them appeared in 2014 or the first half of 2015
(database is 11.2.0.4 on solaris).


Event Message: Internal error (ORA 600 [kqlnrc_1]) detected in
/u00/app/oracle/diag...


Clearing these by hand is tedious beyond all endurance.

Now, I've been always been under the impression that these sort of alerts
(where the underlying cause cannot be corrected and cause the alert to clear
automatically) were considered 'stateless' alerts and could be cleared with a
emcli command:

emcli login -username=SYSMAN
<password entered>
emcli sync --- just done out of habit whenever I fire up emcli
emcli clear_stateless_alerts -target_type=oracle_database -target_name=prodbb1
-preview -older_than=0 --- I also tried non-zero values for this parameter

However, when I tried the above command, it says there are no alerts to be
cleared

Total Alerts
============
0

If I run

Emcli get_metrics_for_stateless_alerts -target_type=oracle_database

I see the following (along with all the rest of the stateless types of alerts)

Generic Internal Error
oracle_database:adrAlertLogIncidentError
:genericInternalErrStack



Either I have a fundamental misunderstanding of how this is supposed to work,
or something is broken.
A parsing of many of the documents discovered using google to search for
relevant information is providing no answers (although it is give excellent
proof of the amount of plagiarism going on in the technical blog world.)

Any insights would be appreciated.

Matt Adams

**** This communication may contain privileged and/or confidential information.
If you are not the intended recipient, you are hereby notified that disclosing,
copying, or distributing of the contents is strictly prohibited. If you have
received this message in error, please contact the sender immediately and
destroy any copies of this document. ****
**** This communication may contain privileged and/or confidential information.
If you are not the intended recipient, you are hereby notified that disclosing,
copying, or distributing of the contents is strictly prohibited. If you have
received this message in error, please contact the sender immediately and
destroy any copies of this document. ****

JPEG image

Other related posts: