密码错误频繁登录引发的“library cache lock”或“row cache lock”等待

2021-04-11 22:53:07 阅读：144 来源： 互联网

标签：lock cache library Oracle event row

密码错误频繁登录引发的”library cache lock”或”row cache lock”等待

对于正常的系统，由于密码的更改，可能存在某些被遗漏的客户端，不断重复尝试使用错误密码登录数据库，从而引起数据库内部长时间的”library cache lock”或”row cache lock”的等待，这种情形非常常见。这种现象在Oracle 10.2和11.1中体现的等待事件为：”row cache lock”，而在Oracle 11.2中体现的等待事件为：”library cache lock”。

row cache lock等待事件的处理：http://blog.itpub.net/26736162/viewspace-2139754/

在 Oracle 11g 中，为了提升安全性，Oracle 引入了『密码延迟验证』的新特性。这个特性的作用是，如果用户输入了错误的密码尝试登录，那么随着登录错误次数的增加，每次登录前验证的时间也会增加，以此减缓可能对于数据库重复的口令尝试***。

但是对于正常的系统，由于口令的更改，可能存在某些被遗漏的客户端，不断重复尝试，从而引起数据库内部长时间的 Library Cache Lock的等待，这种情形非常常见。

如果遇到这一类问题，可以通过Event 28401关闭这个特性，从而消除此类影响，以下命令将修改设置在参数文件中：

ALTER SYSTEM SET EVENT =
'28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;

出现这类问题非常典型的AWR报告呈现如下，首先在 TOP 5 中，你可能看到显著的 Library Cache Lock 的等待，以下范例来自11.2.0.3.0版本的真实情况：
31de0003e8d693e4746b

在这类情况下，时间模型 - Time Model 中会显示如下指标，其中 connection management call elapsed time 占据了主要的DB Time，这个等待直接表明是在建立数据库连接时产生的：
31de0003e8d85f11b208

这类问题，在Oracle的11g中是常见和确定的，在MOS上可以找到相应的记录：High 'library cache lock' Wait Time Due to Invalid Login Attempts(1309738.1）此外Oracle 11g开启了密码大小写验证，如果从Oracle 10g升级过来，需要特别的当心这个变化，通过初始化参数SEC_CASE_SENSITIVE_LOGON 可以来控制这个特性。

High 'library cache lock' Wait Time Due to Invalid Login Attempts (文档 ID 1309738.1)

类型: 状态: 上次主更新: 上次更新:

PROBLEM PUBLISHED 2017-8-2 2017-8-2

In this Document

Symptoms

Changes

Cause

Solution

References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.5 and later
Information in this document applies to any platform.

SYMPTOMS

'Library cache lock' or 'row cache lock' can be observed when concurrent users login with wrong password to the database.
The 'row cache lock' is seen in 10.2 and 11.1 while the 'library cache lock' is seen in 11.2.
ASH Report displays
- High Percentage of execution time attributed to Connection Management:
- High percentage of calls of type OAUTH
Stack contains one of the following functions:
kziavua
kziaia
kziasfc
Checking the exclusive holder from DBA_DDL_LOCKS, a session may be seen holding a lock type (kglhdnsp) 79 on object (kglnaobj) 5:
SQL> select * from dba_ddl_locks where mode_held='Exclusive';
SESSION_ID OWNER NAME TYPE MODE_HELD MODE_REQU
---------- --------- ---------- ---------- --------- ---------
612 5 79 Exclusive None

If AUDIT_TRAIL is enabled, login failures can be checked by running SQLs similar to the following:
Checks for entries in the last 7 days in DBA_AUDIT_TRAIL with error ORA-1017 invalid username/password; logon denied
select username, os_username, userhost, client_id, trunc(timestamp), count(*) fa
iled_logins
from dba_audit_trail
where returncode = 1017
and timestamp > sysdate - 7
group by username, os_username, userhost, client_id, trunc(timestamp);

Checks for entries in the last 7 days in DBA_AUDIT_SESSION where an error was returned
select username, os_username, userhost, timestamp, returncode
from sys.dba_audit_session
where returncode != 0
and timestamp > sysdate - 7;

CHANGES

Many users with wrong password try to login to the database simultaneously

CAUSE

A hang is possible in earlier versions of RDBMS as a result of an unpublished bug fixed in the following versions:

    12.1.0.1 (Base Release)
    11.2.0.2 (Server Patch Set)
    11.1.0.7 Patch 42 on Windows Platforms

Document 9776608.8 Bug 9776608 - Hang from concurrent login to same account with a wrong password

Even with this fix, numerous failed logins attempts can cause row cache lock waits and/or library cache lock waits.

This was reported in:

Bug 11742803 LOTS OF 'LIBRARY CACHE LOCK' DURING USER LOGON AUTHENTICATION

This was closed as not a bug because there is an intentional wait when a login fails.

SOLUTION

In Oracle 11g Release 11.1.0.7, the wait is disabled unconditionally

In Oracle 11g Release 2 and higher, in order to disable the wait between login failures the event 28401 needs to be explicitly enabled:

The event can be set as follows:

alter system set event ="28401 TRACE NAME CONTEXT FOREVER, LEVEL 1" scope=spfile;

To unset the event, set as follows:

SQL> Alter system set event= '28401 trace name context off' scope=spfile ;

For more information see:

Document:7715339.8 Logon failures causes "row cache lock" waits - Allow disable of logon delay

The following functions match per above bug:

nanosleep nanosleep kziasfc kpolnb kpoauth

Note: Care should be taken when setting this event, as this is disabling the sleep time which can leave the system more vulnerable.

For databases using MTS, a further enhancement has been created in:

Bug 19867671 - LIBRARY CACHE LOCK CAUSED BY WRONG PASSWORD LOGIN <=====This bug is superseded by following bug:
Bug 20016491 : DB12.2SEC: LOCK_DATE NOT RESET EVEN AFTER A/C UNLOCKED POST PWD_LOCK_TIME ELAPSE

as setting the event is not as effective as it is for dedicated systems. The following enhancement is included in 12.2:

"The failed login counter will be disabled entirely for any user that has the setting UNLIMITED for their account's FAILED_LOGIN_ATTEMPTS password profile setting."

Bug:19867671 LIBRARY CACHE LOCK CAUSED BY WRONG PASSWORD LOGIN

To find which Session is Holding a Particular Library Cache Lock, review following note:

Document 122793.1 How to Find which Session is Holding a Particular Library Cache Lock

REFERENCES

BUG:11742803   - LOTS OF 'LIBRARY CACHE LOCK' DURING USER LOGON AUTHENTICATION

NOTE:7715339.8   - Bug 7715339 - Logon failures causes "row cache lock" waits - Allow disable of logon delay
BUG:19867671   - LIBRARY CACHE LOCK CAUSED BY WRONG PASSWORD LOGIN

标签：lock,cache,library,Oracle,event,row
来源： https://blog.51cto.com/lhrbest/2700126

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。