溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

錯誤的用戶名密碼登錄導致的數(shù)據(jù)庫性能問題

發(fā)布時間：2020-08-07 04:22:03 來源：ITPUB博客 閱讀：198 作者：guocun09 欄目：關系型數(shù)據(jù)庫
從Oracle 11.1開始，錯誤的用戶名密碼登錄可能會導致在數(shù)據(jù)庫層面看到顯著的“row cache lock”等待。
很多用戶認為這是一個bug，而實際上這是一個數(shù)據(jù)庫保護機制。
Oracle的sqlplus工具會在3次錯誤密碼輸入后自動斷開連接，但是外部應用程序卻可以編碼，不斷調用登錄API進行密碼嘗試。所以如果沒有一個數(shù)據(jù)庫層面的安全控制，這將是非常危險的。
從Oracle 11.1開始，數(shù)據(jù)庫會在對同一個用戶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，而是一個功能增強。用戶必須清楚如果設置了這個事件，將使您的數(shù)據(jù)庫暴露在密碼猜測的風險之下。

Bug 7715339的修復被包含在11.2.0.1 PSU之中。而在11.1.0.7上打補丁7715339，默認已經相當于打開event 28401了。
在11.2.0.2之后，Oracle修改代碼，將這一段“row cache lock”等待修改成了“l(fā)ibrary 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”等待。
用戶不用打補?。ㄒ驗橐呀洶?1.2.0.1中了），直接設置event 28401，就可繞過這段安全控制代碼。
3)11.2.0.2以上的版本（包含11.2.0.2），錯誤的用戶名密碼登錄，將導致顯著的“l(fā)ibrary cache lock”等待。
用戶不用打補?。ㄒ驗橐呀洶?1.2.0.1中了），直接設置event 28401，就可繞過這段安全控制代碼。

必須再次說明的是，用戶必須清楚如果打補丁或者設置了這個事件，將使您的數(shù)據(jù)庫暴露在密碼猜測的風險之下。

正題：
有用戶反饋，即使設置了event 28401，仍會觀察到錯誤的用戶名密碼登錄導致“l(fā)ibrary 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秒，并且持續(xù)增加。

設置event 28401之后：
23142    2.97325209575663296171463140610146054792
24329    3.03592420568046364421061284886349623906

<========即使在24329次等待之后，library cache lock的平均等待時間仍然穩(wěn)定在0.03秒。

也就是說，event 28401是生效的，“等待時間從3秒逐漸增加的”的安全機制被繞過了，但是“l(fā)ibrary cache lock”卻無法避免。
這是因為，錯誤的用戶名密碼登錄仍會在數(shù)據(jù)庫內部更新該用戶的登錄次數(shù)，錯誤登錄次數(shù)，上次登錄時間等信息，需要申請“l(fā)ibrary cache lock”。
而“l(fā)ibrary cache lock”的等待時間跟并發(fā)登錄的進程數(shù)和數(shù)據(jù)庫性能有關。
如果有多個用戶進行不斷的進行錯誤的密碼嘗試，可能仍會觀察到較高的“l(fā)ibrary cache lock”等待。
因為“錯誤的密碼嘗試”應用程序的代碼邏輯一般都是非常瘋狂的，正確的登錄可能一次就過了，而一旦錯誤會反復嘗試并且沒有sleep等待，這將導致一秒鐘可能會發(fā)起幾百次上千次的嘗試，
而多個進程并發(fā)時就容易觀察到平均等待幾十毫秒甚至幾百毫秒的“l(fā)ibrary cache lock”了。因為會不斷嘗試，在數(shù)據(jù)庫層面會累積而很容易觀察到。
但是設置event 28401之后，一般不會有幾十秒上百秒的單次等待了，因為單次遞增的等待機制被繞過了。

總體來講，數(shù)據(jù)庫管理員應該盡快發(fā)現(xiàn)并解決錯誤的用戶名密碼登錄問題（它們一般是因為數(shù)據(jù)庫密碼被更改而應用程序沒有及時同步造成的），而不應該過度依賴event 28401。
因為無論從哪個角度來看，錯誤的用戶名密碼登錄都是一個應用層面的異常問題，是應該被避免的。
向AI問一下細節(jié)

免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經查實，將立刻刪除涉嫌侵權內容。

AI
助
手