密碼錯誤頻繁登陸引起的「library cache lock」或「row cache lock」等待

密碼錯誤頻繁登陸引起的」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版本的真實狀況：

在這類狀況下，時間模型 - Time Model 中會顯示以下指標，其中 connection management call elapsed time 佔據了主要的DB Time，這個等待直接代表是在創建數據庫鏈接時產生的：

這類問題，在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