密碼延遲驗證導致的系統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/a
conn test/a
conn test/a
conn test/a
conn test/a
conn test/test
conn test/a
ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
18:31:26 SQL> ERROR:
ORA-01017: invalid username/password; logon denied

18:31:26 SQL> ERROR:
ORA-01017: invalid username/password; logon denied

18:31:26 SQL> ERROR:
ORA-01017: invalid username/password; logon denied

18:31:27 SQL> ERROR:
ORA-01017: invalid username/password; logon denied

18:31:29 SQL> ERROR:
ORA-01017: invalid username/password; logon denied

18:31:32 SQL> ERROR:
ORA-01017: invalid username/password; logon denied

18:31:36 SQL> Connected.
18:31:36 SQL> ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
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；

設定該事件後重啟資料庫即可。