11.1.0.7 row cache lock 修改使用者名稱密碼 bug 7715339
This note gives a brief overview of bug 7715339.
The content was last updated on: 27-JUL-2011
Click 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
Platforms affected Generic (all / most platforms affected)
Fixed:
This issue is fixed in
Symptoms: |
Related To: |
|
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 . 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 as it makes the database more vulnerable to logon attacks. 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
HOOKS "WAITEVENT:row cache lock" EVENT:28401 LIKELYAFFECTS XAFFECTS_11.1.0.6 XAFFECTS_V11010006 AFFECTS=11.1.0.6 XAFFECTS_11.1.0.7 XAFFECTS_V11010007 AFFECTS=11.1.0.7 XPRODID_5 PRODUCT_ID=5 PRODID-5 RDBMS XCOMP_RDBMS COMPONENT=RDBMS TAG_PERF TAG_SEC PERF SEC FIXED_11.2.0.1
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
(This link will only work for PUBLISHED bugs)
Information on the sections in this article
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22034023/viewspace-708156/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 11G 修改使用者密碼導致的row cache lock密碼
- 公司網站使用者名稱密碼修改?網站密碼
- 批次錯誤使用者名稱與密碼導致業務使用者HANG住(library cache lock)密碼
- 批量錯誤使用者名稱與密碼導致業務使用者HANG住(library cache lock)密碼
- 修改oracle中的使用者名稱和密碼Oracle密碼
- wordpress修改繫結的mysql使用者名稱密碼MySql密碼
- 等待事件之Row Cache Lock事件
- 更改MYSQL使用者名稱密碼MySql密碼
- Latch: Row Cache Objects (One bug?)Object
- git 使用者名稱密碼相關Git密碼
- 隱藏域 使用者名稱密碼密碼
- tortoiseGIT儲存使用者名稱密碼Git密碼
- hanganalyze解決row cache lock(ZT)
- WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!AIENQ
- [ORACLE 11G]ROW CACHE LOCK 等待Oracle
- mongodb怎樣給本地資料庫新增使用者名稱密碼和修改賬號密碼?MongoDB資料庫密碼
- git儲存使用者名稱與密碼Git密碼
- tomcat設定使用者名稱密碼Tomcat密碼
- ibm網站使用者名稱密碼IBM網站密碼
- 轉)用hanganalyze解決row cache lock
- (轉)用hanganalyze解決row cache lock
- 根據教程中,輸錯密碼或使用者名稱後,卻不能返回‘使用者名稱或密碼錯誤’密碼
- github修改使用者名稱Github
- 快速修改Oracle使用者名稱Oracle
- Oracle EM Express要求使用者名稱和密碼OracleExpress密碼
- Activiti-Explorer 使用者名稱與密碼密碼
- 百度文庫使用者名稱密碼密碼
- VMWare Server 2.0 的使用者名稱和密碼Server密碼
- 破解本地 mysql 使用者名稱和密碼(轉)MySql密碼
- 使用者名稱和密碼輸入練習密碼
- 關於登入(使用者名稱,密碼,驗證碼)密碼
- 故障排除:"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! "AIENQ
- WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!的分析AIENQ
- 轉貼_用hanganalyze解決row cache lock
- 用hanganalyze解決row cache lock(轉貼)
- 根據使用者名稱和密碼查詢使用者密碼
- 表單使用者名稱和密碼記住效果密碼
- JavaScript驗證使用者名稱密碼是否為空JavaScript密碼