從Oracle 11.1開始，錯誤的使用者名稱密碼登入可能會導致在資料庫層面看到顯著的“row cache lock”等待。
很多使用者認為這是一個bug，而實際上這是一個資料庫保護機制。
Oracle的sqlplus工具會在3次錯誤密碼輸入後自動斷開連線，但是外部應用程式卻可以編碼，不斷呼叫登入API進行密碼嘗試。所以如果沒有一個資料庫層面的安全控制，這將是非常危險的。
從Oracle 11.1開始，資料庫會在對同一個使用者3次錯誤的密碼嘗試之後，開始鎖定這個使用者3秒鐘，才允許下一次登入。這個鎖定時間將從3秒逐漸延長，不斷增加。
所有以該使用者登入的session都會等待“row cache lock”，哪怕他是用正確的密碼登入的。

很多使用者不理解這樣做是為了幫助使用者避免風險，而對看到的“row cache lock”等待提出抱怨。
所以Oracle在Bug 7715339的修復中提供了一個方法（event 28401）來繞過這段程式碼，來供使用者做不同選擇。
event="28401 trace name context forever, level 1" # disable logon delay
必須說明的是，這實際上並不是一個bug，而是一個功能增強。使用者必須清楚如果設定了這個事件，將使您的資料庫暴露在密碼猜測的風險之下。

Bug 7715339的修復被包含在11.2.0.1 PSU之中。而在11.1.0.7上打補丁7715339，預設已經相當於開啟event 28401了。
在11.2.0.2之後，Oracle修改程式碼，將這一段“row cache lock”等待修改成了“library cache lock”等待。
總結一下：
1)11.1.0.X上，錯誤的使用者名稱密碼登入，將導致顯著的“row cache lock”等待。
使用者可以在11.1.0.7上打補丁7715339，不用設定event 28401，就可繞過這段安全控制程式碼。
2)11.2.0.1上，錯誤的使用者名稱密碼登入，將導致顯著的“row cache lock”等待。
使用者不用打補丁（因為已經包含在11.2.0.1中了），直接設定event 28401，就可繞過這段安全控制程式碼。
3)11.2.0.2以上的版本（包含11.2.0.2），錯誤的使用者名稱密碼登入，將導致顯著的“library cache lock”等待。
使用者不用打補丁（因為已經包含在11.2.0.1中了），直接設定event 28401，就可繞過這段安全控制程式碼。

必須再次說明的是，使用者必須清楚如果打補丁或者設定了這個事件，將使您的資料庫暴露在密碼猜測的風險之下。

正題：
有使用者反饋，即使設定了event 28401，仍會觀察到錯誤的使用者名稱密碼登入導致“library cache lock”等待，這是為什麼呢？為此，我們做了以下測試進行說明：

起10個程式，同時進行錯誤的使用者名稱密碼登入，並測試未設定event 28401和設定event 28401進行比較，從V$SYSTEM_EVENT中多次觀察獲取平均等待時間：
select total_waits,Time_waited_fg/total_waits
from V$SYSTEM_EVENT
where event='library cache lock'

未設定event 28401：
91   1395.252747252747252747252747252747252747
98   2352.959183673469387755102040816326530612
106   2687.698113207547169811320754716981132075
116   3495.862068965517241379310344827586206897

<========library cache lock的平均等待時間很快從13.95秒逐漸增加到34.95秒，並且持續增加。

設定event 28401之後：
23142   2.97325209575663296171463140610146054792
24329   3.03592420568046364421061284886349623906

<========即使在24329次等待之後，library cache lock的平均等待時間仍然穩定在0.03秒。

也就是說，event 28401是生效的，“等待時間從3秒逐漸增加的”的安全機制被繞過了，但是“library cache lock”卻無法避免。
這是因為，錯誤的使用者名稱密碼登入仍會在資料庫內部更新該使用者的登入次數，錯誤登入次數，上次登入時間等資訊，需要申請“library cache lock”。
而“library cache lock”的等待時間跟併發登入的程式數和資料庫效能有關。
如果有多個使用者進行不斷的進行錯誤的密碼嘗試，可能仍會觀察到較高的“library cache lock”等待。
因為“錯誤的密碼嘗試”應用程式的程式碼邏輯一般都是非常瘋狂的，正確的登入可能一次就過了，而一旦錯誤會反覆嘗試並且沒有sleep等待，這將導致一秒鐘可能會發起幾百次上千次的嘗試，
而多個程式併發時就容易觀察到平均等待幾十毫秒甚至幾百毫秒的“library cache lock”了。因為會不斷嘗試，在資料庫層面會累積而很容易觀察到。
但是設定event 28401之後，一般不會有幾十秒上百秒的單次等待了，因為單次遞增的等待機制被繞過了。

總體來講，資料庫管理員應該儘快發現並解決錯誤的使用者名稱密碼登入問題（它們一般是因為資料庫密碼被更改而應用程式沒有及時同步造成的），而不應該過度依賴event 28401。
因為無論從哪個角度來看，錯誤的使用者名稱密碼登入都是一個應用層面的異常問題，是應該被避免的。

錯誤的使用者名稱密碼登入導致的資料庫效能問題

相關文章