ursor_sharing=SIMILAR 引发大量的 cursor: mutex S

今天一个朋友的数据库11.2.0.1 遇到这个问题，导致业务大面积的瘫痪查看等待如下：

  IN_NUM EVENT_NAME                                                       NOW_SNAP_ID NOW_WAITED_TOTAL WAIT_TIME_MICRO    ROW_NUM
---------- ---------------------------------------------------------------- ----------- ---------------- --------------- ----------
         1 cursor: mutex S                                                         8196     574159937294    113469206148          1
         1 DB CPU                                                                  8196     264925348737     94172222209          2
         1 library cache lock                                                      8196     377415652600     58003457267          3
         1 direct path read                                                        8196      16531321401      4584378285          4
         1 db file sequential read                                                 8196       2798779765      1387124732          5 

默认一小时的AWR event
可以看到基本处于崩溃的边缘，其原因MOS解释如下：

GOAL

Customer upgraded the DB Repository for Oracle Waveset from Oracle 10g to  Oracle 11g.  
Cursor sharing was set to SIMILAR as per the Oracle Waveset Documentation in 10g.
Child cursors were getting released in 10g. Customer noticed child cursors were not getting released in 11g.

Cursor Mutex S wait event and too many child cursors open when cursor sharing is set to similar.

As per the documentation in MOS 1169017.1 cursor sharing should be exact or force.

SOLUTION

The recommendation to set the 'cursor_sharing' option as 'SIMILAR' was to remedy the known issues when 'cursor_sharing' was set to be the default 'EXACT' option in previous versions of Oracle Waveset and Oracle 10g as repository.

Since the Oracle 11g database deprecates the 'SIMILAR' option, the recommendation now is to set 'cursor_sharing' to 'FORCE'.

REFERENCES

BUG:13983028 - RECOMMENDATION FOR CURSOR_SHARING PARAMETER WITH ORACLE 11G REPOSITORY

记录一下

时间： 2024-10-23 08:52:51

ursor_sharing=SIMILAR 引发大量的 cursor: mutex S的相关文章

ora-600[25027][x][0] 插入大字段问题

一个朋友数据库断电后重启遭遇此问题 ORA-00600: internal error code, arguments: [25027], [22], [0], [], [], [], [], [], [], [], [], [] ----- Current SQL Statement for this session (sql_id=8ywdkvd1vbrqm) ----- INSERT INTO VEH_XML_DATA (ID, JYLSH, JKID, HPHM, HPZL, CLSBD

11.2.0.1 大量的 Mutex S 并且和Sys.Aud$有关

今天网友给我一份AWRRPT TOP5如下: cursor: mutex S 71,373,261 295,337 4 73.78 Concurrency DB CPU   30,974   7.74   library cache lock 560,800 18,037 32 4.51 Concurrency db file sequential read 1,168,603 8,481 7 2.12 User I/O enq: TX - row lock contention 11 8,10

Oracle Mutex 等待事件

Oracle Mutex 等待事件之: cursor pin S pin S 等待事件说明,当一个会话(session)试图去更新一个共享的 Mutex Pin,同时已经有其他会话正在更新(updating)同一个 Shared Mutex Pin.注意,Pin S 的Mutex位于子游标上,是动态创建的,无法从等待事件中获得,但是可以在竞争出现的情况下,通过观察 x$mutex_sleep_history 来获得. 文档说明如下: Oracle Mutex 等待事件之: cursor pin

【MOS】常见问题cursor library cache类型的等待事件

[MOS]常见问题:'cursor:mutex ..'/ 'cursor:pin ..'/ 'library cache:mutex ..'类型的等待事件 (文档 ID 1525791.1) 文档内容 用途 问题和答案   什么是 'cursor: ' 等待事件?   最常见的等待事件是什么?   等待事件最常见的原因是什么?   如何避免这些等待事件?   可以在什么位置找到原因诊断以及关于这些等待事件的更多信息?   有用参考 参考 适用于: Oracle Database - Enterp

Oracle AWR报告详细分析 (文档 ID 1523048.1)

Oracle AWR报告详细分析  (文档 ID 1523048.1) AWR 是 Oracle  10g 版本 推出的新特性, 全称叫Automatic Workload Repository-自动负载信息库 AWR 是通过对比两次快照(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分. WORKLOAD REPOSITORY report for  DB Name DB Id Instance Inst num Release RAC Host ICCI 13140

Oracle中的游标、硬解析、软解析、软软解析、解析失败

Oracle中的游标.硬解析.软解析.软软解析.解析失败 一. 游标的分类及共享游标 游标(Cursor)是Oracle数据库中SQL解析和执行的载体,它可以分为共享游标(Shared Cursor)和会话游标(Session Cursor).共享游标可以细分为父游标(Parent Cursor)和子游标(Child Cursor),可以通过视图V$SQLAREA和V$SQL来查看当前缓存在库缓存(Library Cache)中的父游标和子游标,其中V$SQLAREA用于查看父游标,V$SQL用

【MOS】Troubleshooting Performance Issues (文档 ID 1377446.1)

[MOS]Troubleshooting Performance Issues (文档 ID 1377446.1) In this Document Purpose   Best Practices   Pro-Active Problem Avoidance and Diagnostic Collection   Performance Service Request Diagnostic Collection (SRDC) documents Troubleshooting Steps  

shared pool 深度解析2+

Library cache是Shared pool的一部分,它几乎是Oracle内存结构中最复杂的一部分,主要存放shared curosr(SQL)和PLSQL对象(function,procedure,trigger)的信息,以及这些对象所依赖的table,index,view等对象的信息. Library cache需要解决三个问题: 1.快速定位的问题:Library cache中对象众多,Oracle如何管理这些对象,以便服务进程可以迅速找到他们需要的信息.比如某个服务进程需要迅速定位

Oracle OWI 等待事件视图(v$session_wait/v$session_event/v$system_event)

    通常情况下,用户提交一条SQL语句,总会存在这样或那样的等待事件.也就是说由于所需资源被占用导致进程不得不处于等待状态.Oracle为我们提供了获取这些等待事件的可用视图.根据这些视图可以得知哪些事件导致该SQL语句效率低下而采取相应的修改或调整.本文基于Oracle 10g描述了如何通过视图v$session_wait,v$session_event,以及v$system_event去获取等待事件的相关信息.   1.等待事件相关参数  timed_statistics      指定