昨天一業務系統在做資料遷移時，遷移完畢後，導致系統業務非常慢，資料一直查詢不出來。透過作業系統TOP命令檢視系統壓力，資料庫沒有任何壓力，非常空閒，後來懷疑是網路問題，於是遠端登入到主機上，使用資料庫使用者登入資料庫，發現其他資料庫使用者登入非常快，而該業務系統的使用的使用者登入非常緩慢，幾乎要等10多秒才能登陸上。
問題出現象後，透過v$session， gv$session_wait查詢等待事件，在資料庫中出現大量的library cache lock。而且username全部為空。
select * from gv$session_wait where event like 'library cache lock';
在v$session檢視中查詢library cache lock等待相關的會話資訊，發現username為空而且不是oracle後臺進行。這就是說這些會話還沒有連線到資料庫，一直在等待驗證狀態。
1.首先我是透過下面語句查詢的。
select sid,username,event,schemaname from v$session;

1 DIAG idle wait SYS

2 ASM background timer SYS

3 class slave wait SYS

4 class slave wait SYS

7 library cache lock SYS

8 library cache lock SYS

9 library cache lock SYS

10 library cache lock SYS

11 Streams AQ: waiting for time management or cleanup tasks SYS

12 library cache lock SYS

16 library cache lock SYS

17 Space Manager: slave idle wait SYS

18 library cache lock SYS

19 library cache lock SYS

21 library cache lock SYS

22 library cache lock SYS

23 library cache lock SYS

25 library cache lock SYS

26 library cache lock SYS

27 library cache lock SYS

28 library cache lock SYS

29 library cache lock SYS

30 library cache lock SYS

31 library cache lock SYS

33 library cache lock SYS

34 library cache lock SYS

36 library cache lock SYS

37 library cache lock SYS

38 library cache lock SYS

39 library cache lock SYS

40 library cache lock SYS

41 library cache lock SYS

42 library cache lock SYS

43 library cache lock SYS

44 library cache lock SYS

45 library cache lock SYS

47 library cache lock SYS

49 library cache lock SYS

51 library cache lock SYS

52 library cache lock SYS
....................................
後來和同事分析了下，懷疑是不是oracle 11g 新特性密碼錯誤驗證延遲導致的。

密碼錯誤驗證延遲

Preventing passwords from being broken. If a user tries to log in to Oracle Database multiple times using an incorrect password, Oracle Database delays each login after the third try. This protection applies for attempts made from different IP addresses or multiple client connections. For the first three attempts, there is no delay. Afterwards, it gradually increases the time before the user can try another password, up to a maximum of about 10 seconds. If the user enters the correct password, he or she is able to log in successfully without any delay.
This feature significantly decreases the number of passwords that an intruder would be able to try when attempting to log in. It is designed to prevent repeated attacks on password checking.
我們透過修改引數。遮蔽了密碼錯誤驗證延遲EVENT="28401 TRACE NAME CONTEXT FOREVER, LEVEL 1"

SQL> ALTER SYSTEM SET EVENT = ‘28401 TRACE NAME CONTEXT FOREVER, LEVEL 1’；
後來資料庫正常了。
我們也可以使用oerr ora 28401檢視密碼錯誤驗證延遲事件。
[oracle@test ~]$ oerr ora 28401
28401, 00000, "Event to disable delay after three failed login attempts"
// *Document: NO
// *Cause: N/A
// *Action: Set this event in your environment to disable the login delay
// which will otherwise take place after three failed login attempts.
// *Note: THIS IS NOT A USER ERROR NUMBER/MESSAGE. THIS DOES NOT NEED TO BE
// TRANSLATED OR DOCUMENTED.

總結：

導致這次錯誤的原因是應用系統在做資料遷移時，我業務使用者刪除了，drop user test cascade;把使用者相關的表一起刪除了，隨後建立了相同的使用者。在此期間應用一直沒停下來，應用系統一直在嘗試登陸資料庫，oracle 資料庫在11g的新特性中新增密碼錯誤後延遲驗證的功能，在密碼錯誤登陸次數過多後，使用者驗證延遲時間是遞增的，從開始的兩秒遞增到六秒，因此下次做資料遷移時，需要先停止應用系統，大家也不要嘗試著以錯誤的密碼過多的登陸資料庫。

補充從10g升級到11g之後需要注意的幾個密碼方面問題：

1. 11g預設開始密碼區分大小寫，可以透過把引數設定為SEC_CASE_SENSITIVE_LOGON =FALSE 遮蔽

2. 11g密碼預設有效期180天，可以透過修改ALTER PROFILE DEFAULT[根據實際的profile] LIMIT PASSWORD_LIFE_TIME UNLIMITED; 注意需要修改密碼生效

3. 密碼錯誤驗證延遲，可以透過設定EVENT="28401 TRACE NAME CONTEXT FOREVER, LEVEL 1" 遮蔽

密碼延遲驗出現大量library cache lock

相關文章