I’m going to summarise my thoughts:
Passchng.exe should be easy to track down where it’s coming from, you
already know the machine. This is using the wrong password to connect to
the user. That wrong password attempt then locks the user from logging in
for another N seconds (login attempts experience the dc_users lock). This N
seconds increases with failed attempts.
Is this program a legitimate program? I know I would much rather use
sql*plus to change a DB user password. Surely, someone in your org has
raised a different issue if it is legitimate - our super important DB user
is using the wrong password.
Either it is legitimate and needs fixing - it should know what the password
is of the user it’s connecting as or it is illegitimate and you need to
work with your security teams to get it removed and nuked from orbit.
I don’t think it matters what the alter user statement is. It’s probably
the internal one Oracle is using to set the login lock timer, I forget how
this worked back in 11.2.
Your second priority is upgrading.
Thanks,
Andy
On Wed, 27 Oct 2021 at 00:25, Mladen Gogala <gogala.mladen@xxxxxxxxx> wrote:
On 10/25/21 06:30, Pap wrote:
My mistake, one correction:- the cache_id for all those 'row cache
lock' is pointing to dc_users.
Once upon a time, dc_ parameters were set in the init.ora. The "dc_"
comes from "dictionary cache". Oracle instance had a fixed size
dictionary for each type of objects: tables, views, indexes, sequences,
users and some other stuff, too. Today, those caches are dynamic and
extensible. However, if two processes attempt to manipulate the same
cache entry, like the same username, one will have to wait, as you have
just discovered. My favorite situation with dc_rowcache waits includes
ordered sequences and RAC. That's when the story gets really, really
interesting.
--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
--
//www.freelists.org/webpage/oracle-l
