bug 7715339 登入失敗觸發 ‘row cache lock’ 等待,7715339row
Bug 7715339 - Logon failures causes "row cache lock" waits - Allow disable of logon delay
(文檔 ID 7715339.8) 到底部
修改時間:2012-7-26類型:PATCH
為此文檔評級 通過電子郵件發送此文檔的連結 在新視窗中開啟文檔 可列印頁
Bug 7715339 Logon failures causes "row cache lock" waits - Allow disable of logon delay
This note gives a brief overview of bug 7715339.
The content was last updated on: 19-JUN-2012
Click here for details of each of the sections below.
Affects:
Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions >= 11.1
Versions confirmed as being affected
11.1.0.7
Platforms affected Generic (all / most platforms affected)
Fixed:
This issue is fixed in
11.2.0.1 (Base Release)
Symptoms:
Related To:
Performance Affected (General)
Waits for "row cache lock"
Security ( Authentication / Privileges / Auditing )
Description
In 11g there is an intentional delay between allowing failed logon
attempts to retry. For some specific application types this can cause
a problem as the row cache entry is locked for the duration of the
delay . This can lead to excessive row cache lock waits for DC_USERS
for specific users / schemas .
This "fix" allows the logon delay to be disabled in 11.2.0.1 onwards
by setting event 28401 in the init.ora.
eg:
event="28401 trace name context forever, level 1" # disable logon delay.-----該事件會禁用登入延遲,一種假死的狀態
This "event" will disable the logon sleep delay system-wide,
ie. it will affect all user accounts, system-wide, and so should be used
with extreme caution.
Example scenario:
A mix of correct and incorrect logon attempts occur for user X
On each successive failed login attempt the failed logon count
is incremented for user X.
Without this fix (without the event set):
After 3 successive failures a sleep delay is introduced starting
at 3 seconds and extending to 10 seconds max. During each delay
the user X row cache lock is held in exclusive mode preventing
any concurrent logon attempt as user X (and preventing any
other operation which would need the row cache lock for user X).
With the fix (with the event set):
There is no sleep delay.
In either scenario the configured logon profile rules are still
applied (eg: The profile option FAILED_LOGIN_ATTEMPTS is still
honoured and so if the account becomes locked due to exceeeding
this FAILED_LOGIN_ATTEMPTS then further attempts to
log in will then correctly fail immediately with no delay).
Note:
One off fixes for this issue for 11.1.0.7 do not need an event set -
interim patches for 11.1 disable the delay unconditionally.
Work Around:
Ensure the correct password is used - especially for connection
intensive logons
Getting a Fix
Use one of the "Fixed" versions listed above
(for Patch Sets / bundles use the latest version available as
contents are cumulative - the "Fixed" version listed above is
the first version where the fix is included)
or
You can check for existing interim patches here: Patch:7715339
Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.
References
Bug:7715339 (This link will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article
零基礎向DBA發展需要學這個
itpub的大神VAGE推薦的學習路線僅供參考:
初級階段:可以從OCP教材開始,還有文檔中的Administrator's Guide、Concepts、Performance Tuning Guide、Backup and Recovery Advanced User's Guide、Backup and Recovery Basics。特別是Administrator's Guide、Concepts、Performance Tuning Guide,要詳細閱讀。多操作,多實驗。
中級階段:不斷的操作,加上metalink上看各類文章,自己總結。有一個很重要,到Oracle官網上,找到OCM的考試大綱,按圖索冀,逐個擊破,之於考不考OCM,另當別論。書的話,可以參考《9i&10g編程藝術》,《基於成本的oracle最佳化法則》,《大話叢集rac》,《ORACLE RAC日記》等等。
進階:繼續看書(最佳化,特性,整合)往深度廣度學。可以以如下內容為專題,逐個鑽研:
1、儲存格式:資料檔案格式、資料存放區格式等
2、共用池方面:解析流程及原理,共用相關於Latch、Lock、Pin,Row cache lock原理,相關的等待事件。以及共用池記憶體配置機制。
3、Buffer Cache部分:邏輯讀、物理讀流程及原理,相關的Latch、Pin,還有相關的等待事件。
4、Redo:Redo的產生流程、相關Latch、等待事件。
5、Undo:Undo的空間使用規則、提交和復原的原理
6、備份、恢複機制原理,學會使用BBED
7、ASM
8、RAC
可以參考DSI。還有Liwes的新書Oracle Core。
找oracle 11g培訓 怎分辨?
首先查詢那個機構是不是在Oracle官方的WDP授權頁面中,然後看是不是Oracle官方的統一價格,要是高於統一價格的話,說明有亂收費的嫌疑;還有就是看課程安排,是不是一氣呵成的,如果還有串講班什麼的,說明它後期還可能強迫你二次收費;然後就是看裝置、講師資質,其實通過試聽Oracle培訓的試聽課程來判斷一下也是不錯,像CUUG的公開課我就有空就聽聽,雖然沒在哪報過名,但是覺得講的還是不錯的。還有到培訓機構實地考察一下都是不錯的選擇,別人說什麼都是假的,你要自己多聽多看然後做判斷。