Wrong wait events in 11.2 ("cursor: mutex S" instead of "cursor: mutex X") (文档 ID 9591812.8)
2014-01-20 10:53
1316 查看
Bug 9591812 Wrong wait events in 11.2 ("cursor: mutex S" instead of "cursor: mutex X")
This note gives a brief overview of bug 9591812.The content was last updated on: 28-JUN-2013
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.2 but BELOW 12.1 |
Versions confirmed as being affected | 11.2.0.2 11.2.0.1 |
Platforms affected | Generic (all / most platforms affected) |
Regression introduced in 11.2.0.1
Fixed:
Symptoms: | Related To: |
Diagnostic Output Problem / Improvement Waits for "cursor: mutex S" Waits for "cursor: mutex X" Waits for "cursor: pin S" Waits for "cursor: pin X" | Performance Monitoring V$SESSION_WAIT |
Description
When examining information related to performance, a wait for a cursor mutex in exclusive mode ('cursor: mutex X') may be incorrectly shown as a wait in share mode ('cursor: mutex S'). Also a "cursor: pin X" wait may be shown as "cursor: pin S". eg: The processstate of a waiting process shows something like: Current Wait Stack: 0: waiting for 'cursor: pin S' idn=0x10439dee, value=0xffffffffffffffff, where=0x100000000 but the mutex information in the trace shows a GET_LONG_EXCL request: KGX Atomic Operation Log c0000005255cc710 Mutex c000000528a43b30(-1, -1) idn 10439dee oper GET_LONG_EXCL Cursor Pin uid 764 efd 0 whr 1 slp 27284 Rediscovery Notes: If the call stack or processstate of a session shows that it is waiting for a cursor mutex in exclusive mode GET_LONG_EXCL but V$SESSION_WAIT and other performance-related view show that it is waiting for the mutex in share mode ('cursor: mutex S' or 'cursor: pin S'). Workaround Be cautious when interpreting S mode mutex / pin waits.
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:9591812 (This link will only work for PUBLISHED bugs)Note:245840.1 Information on the sections in this article
|
|
Database Products > Oracle
Database > Oracle
Database > Oracle
Database - Enterprise Edition
相关文章推荐
- "Cursor: Pin S Wait On X" Contention Mutex Sleep Reason Primarily (文档 ID 1268724.1)
- High "Resmgr:Cpu Quantum" Wait Events In 11g Even When Resource Manager Is Disabled (文档 ID 949033.1)
- WAITEVENT: "cursor: pin S" Reference Note (文档 ID 1310764.1)
- Exception in thread "main" org.hibernate.TypeMismatchException: Provided id of the wrong type
- 11.2 RAC: In "crsctl stat res -t" State Details May Be Missing or Incorrect (文档 ID 1086563.1)
- WAITEVENT: "library cache: mutex X" (文档 ID 727400.1)
- High "enq: SQ - contention" waits in RAC (文档 ID 2156730.1)
- WAITEVENT: "cursor: pin S wait on X" Reference Note (文档 ID 1298015.1)
- WAITEVENT: "library cache: mutex X" (文档 ID 727400.1)
- Troubleshooting: Waits for Mutex Type Events (文档 ID 1377998.1)
- WAITEVENT: "buffer busy waits" Reference Note (文档 ID 34405.1)
- How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' (文档 ID 786507.1)
- Configuring file creation in Flash recovery area and order of Precedence (文档 ID 305810.1)
- WAITEVENT: "log file sync" Reference Note (文档 ID 34592.1)
- WAITEVENT: "log file parallel write" Reference Note (文档 ID 34583.1)
- index$_join$ or Other Internal Table Appears in Audit Trail Instead of Base Table. (Doc ID 955968.1)
- WAITEVENT: "library cache pin" Reference Note (文档 ID 34579.1)
- Bug 9239863 - Excessive "library cache:mutex X" contention on hot objects (文档 ID 9239863.8)
- Bug 7307972 - Excessive waits on 'library cache: mutex x' (文档 ID 7307972.8)
- 常见问题:'cursor:mutex ..'/ 'cursor:pin ..'/ 'library cache:mutex ..'类型的等待事件 (文档 ID 1525791.1)