Re: OEM reporting failed login attempts on read-only physical standby database

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_at_dxc.com> 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_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of DOUG KUSHNER <dougk5_at_cox.net>
> Sent: Friday, June 24, 2022 5:21 AM
> To: oracle-l_at_freelists.org <oracle-l_at_freelists.org>
> 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
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l