密碼延遲驗證導緻的系統HANG住

又是一個11g新特性導緻的問題。

[@more@]

這個新特性很早之前就研究過，也在其他客戶處碰到過類似的問題。從11g開始，如果一個使用者使用不正确的密碼嘗試登入資料庫，那麼随着登入失敗次數的增加，每次登入驗證前延遲等待的時間也會增加：

SQL> set time on

18:30:54 SQL>

18:30:58 SQL> conn test/test

Connected.

18:31:25 SQL>

18:31:25 SQL> conn test/a

conn test/a

conn test/test

ERROR:

ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

18:31:26 SQL> ERROR:

18:31:27 SQL> ERROR:

18:31:29 SQL> ERROR:

18:31:32 SQL> ERROR:

18:31:36 SQL> Connected.

18:31:36 SQL> ERROR:

18:31:36 SQL>

可以看到，從第三次密碼錯誤的登入開始，每次延遲時間開始變成2秒、3秒并一次遞增。既是這時提供正确的密碼登入，會話也會延遲N秒，然後進行驗證。不過一旦驗證成功，會将失敗計數清零，後續的錯誤登入會重新計數。

不過這隻是單一會話嘗試失敗登入的情況，如果同時存在兩個會話，則很快延遲驗證時間就會達到10秒、20秒的級别。如果同時大量的連接配接采用錯誤的密碼，基本上這個使用者的登入就會被完全HANG住。

客戶的資料庫就出現了類似的情況，資料庫版本為11.2.0.3 RAC，在資料庫中觀察，三個節點每個節點的會話數都接近SESSIONS參數設定的上線3000，而背景進階日志已經出現了ORA-20錯誤。由于客戶系統的關鍵使用者隻有一個，是以幾乎所有的會話都無法正常的登入到資料庫中。而在資料庫上發現，大量的會話使用者名、EVENT以及PROGRAM都資訊都是NULL，這說明這些會話還沒有完成驗證成功的登入到資料庫中。而目前主機的CPU資源使用并不高，那些已經連接配接到資料庫中的程序也可以正常的工作。嘗試使用SYSTEM等其他使用者發現可以迅速的登入資料庫。所有這一切都已經說明，目前有一個或多個中間件伺服器在使用錯誤的密碼連接配接資料庫，由于密碼延遲驗證的政策，導緻所有後續的連接配接都被HANG住。

任何一個新特性帶來性能或功能上的提高的同時，也會引入相關的bug，顯然這個安全性上的考慮，有時候也會帶來驗證的性能問題，甚至成為用來攻擊資料庫的一種手段。

之前幾次并沒有給出徹底屏蔽密碼延遲驗證的手段，而Oracle最強大之處就在于幾乎所有的功能和特性都有對應的開關，通過設定EVENTS

28401可以屏蔽密碼延遲驗證：

SQL> ALTER SYSTEM SET EVENT = ‘28401 TRACE NAME CONTEXT

FOREVER, LEVEL 1’ SCOPE = SPFILE；

設定該事件後重新開機資料庫即可。