Library cache lock
sridhar kumar sahu, January 11, 2017 - 3:03 am UTC
But whenever we tried to login with wrong password it goes for library cache lock I saw it.
Regards,
Sridhar
January 11, 2017 - 6:16 am UTC
I'm sure you'll provide us with some evidence of this, and reproduction steps :-)
MOS already did it ?
J. Laurindo Chiappa, January 11, 2017 - 10:45 am UTC
Maybe the questioner is seeing the effects of the issues registered/explained in MOS note Document ID 1309738.1 High ‘library cache lock’ Wait Time Due to Invalid Login Attempts ?
Regards,
J. Laurindo Chiappa
January 11, 2017 - 1:09 pm UTC
That is not due to a failed login attempt by a (single) session, that is related to the amount of concurrency in login attempts. Perhaps this is what our original poster is referring to, when they say "multiple time" ?
Library cache lock
sridhar kumar sahu, January 11, 2017 - 11:36 am UTC
Hi J. Laurindo Chiappa,
Yes you are correct. Let me modify a little bit to my question.
Why we experience "library cache lock" wait event when concurrent users tries to login with wrong password to the database?
Earlier my question was bit different which created confusion.
and 1309738.1 is the doc id which i was referring to. I don't have any live evidence now for this issue, but i have seen this issue for some databases.
Regards,
Sridhar
January 11, 2017 - 1:10 pm UTC
Ah ok - I misinterpreted what you meant by "multiple times".
Yes - its a bug.
More details
J. Laurindo Chiappa, January 11, 2017 - 1:47 pm UTC
Connor, I think we need more details : some situations will configure BUG and some not...
For example,Bug 11742803 : LOTS OF 'LIBRARY CACHE LOCK' DURING USER LOGON AUTHENTICATION was closed as 'Not a Bug' , it was a normal behavior - as a secutity measure (to fight DOS-type/bruteforce attacks) after a wrong password is sent a small delay is done and a resource lock occurs... In 10g password management (and thus the applied locks) were done in in 'row cache' but in 11g it changed to 'library cache'... The library cache lock wait is seen due to the fact that the account status gets updated internally due to incorrect login and is maintained in the library cache.... The referenced note explains this and it and it remeber us that this is a TOTALLY NORMAL AND EXPECTED behavior, I think - not a bug, in any shape or form...
And of course, in common use/situations the (expected and normal) lock would be quickly released, so it would not appear as one of the top wait events....
BUT other situations were not normal : for example, Bug 9776608 Hang from concurrent login to same account with a wrong password registered a situation where concorrent login attempts for the same account could lead to a 'race condition', this was for sure a bug...
Best regards,
J. Laurindo Chiappa
Library cache lock
sridhar kumar sahu, January 13, 2017 - 2:46 am UTC
Thank you all of you for all your explanations.
Really helpful