OEM is a bit like Windows in that the occasional restart can clear up a lot of
wierdness. This issue occurred over a period of about 4 hours and ended as
mysteriously as it began.
Since the audit trail (on disk) didn't reveal anything, I'm wondering now if
this metric just reflects failed OEM connection attempts? It could have been a
network issue between our OEM platform and the DR site which is across a WAN.
Regards,
Doug
On June 24, 2022 at 11:35 AM "Powell, Mark" <mark.powell2@xxxxxxx> wrote:
If you do not see a problem on either the primary or secondary instance
have you considered restarting OEM then looking to see if the error still
shows?
Mark Powell
Database Administration
(313) 592-5148
---------------------------------------------
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on
behalf of DOUG KUSHNER <dougk5@xxxxxxx>
Sent: Friday, June 24, 2022 5:21 AM
To: oracle-l@xxxxxxxxxxxxx <oracle-l@xxxxxxxxxxxxx>
Subject: OEM reporting failed login attempts on read-only physical
standby database
The database in question is an 11.2.0.4 2-node RAC read-only standby
database on Exadata, Starting this evening, OEM began raising 'Event
name=audit_failed_logins2:failed_login_count', reporting hundreds of failed
login attempts. Of course OEM does not provide any additional information, so
it remains a mystery.
The primary and standby databases are both auditing failed connections,
so I searched through the *.aud files on both nodes of the standby database
and didn't find any clues.
What should we check next?
Regards,
Doug
