RE: clearing 'stateless' alerts in OEM 12c not functioning as expected
Date: Thu, 8 Oct 2015 21:07:53 +0000
Message-ID: <049d765eb59544858a1cca6de58c773c_at_wpvl1dag03.hcrec.com>
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_at_oracle.com]
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_at_oracle.com<mailto:pete.sharman_at_oracle.com> 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_at_TroverSolutions.com]
Sent: Friday, October 9, 2015 7:40 AM
To: ORACLE-L <oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>>
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 emcliemcli 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. ****
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Oct 08 2015 - 23:07:53 CEST