Mutex是Oracle从10g开始使用的一种数据结构,与latch极其类似,也是用于SGA内存结构的并发访问控制。在10g中,Mutex主要用于保护Cursor相关的内存结构,Parent Cursor, Child Cursor , Cursor Stat,同时兼有Pin Cursor的并发访问控制作用。

而从11g开始,Mutex又代替了library cache latch等多个与library cache相关的latch。

Mutex与latch相比,有哪些优点?我个人认为最重要的有2点:

  • Mutex通常在被保护对象内部,这样mutex的数量就多了很多,争用就更少。比如11g中,每一个Latch Latch Hash Bucket由一个mutex保护,而bucket数量高达131072,相比library cache latch最多只有67个child latch,数量上多了很多。很显然,分布在131072个Mutex上的竞争比67个Library cache latch上的竞争少得多。
  • Mutex从结构上来讲比latch更多简单,整个Mutex只有十几个字节,而Oracle在对Latch的结构优化和精简的情况下最少也有100多个字节。这样更小的结构意味着在处理Mutex时也只需要更少的指令,而更快。
  • Mutex代替Cursor上的library cache pin,比library cache pin更有效率。

本文主要描述如何通过system state dump来分析mutex的等待,因此对Mutex的工作机制以及相应的等待事件详解不做过多介绍。有机会我会在另外的文章中专门来讲这两部分。

我们来分析的system state dump来源于一个朋友,他的系统里面出现大量的'cursor: pin S wait on X'和'cursor: Mutex X'等待事件。他将产生的system state dump发给我,以分析出产生问题的root cause。由于system state dump比较在在,同时里面涉及的一些内容不适合放在网上,因此本文只给出分析过程,没有上传trace文件。数据库的版本是11.1.0.7。

首先试图找到'cursor: pin S wait on X'等待的阻塞进程,随便找到一个等待cursor:pin S wait on X的会话,在dump trace 文件中查找waiting for 'cursor: pin S wait on X':

    (session) sid: 1471 ser: 57513 trans: (nil), creator: 0x450d504f0
              flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
              flags2: (0x40008) -/-
              DID: , short-term DID: 
              txn branch: (nil)
              oct: 3, prv: 0, sql: 0x455d15680, psql: 0x45bd0c8c8, user: 92/XXXX
    ksuxds FALSE at location: 0
    service name: SYS$USERS
    client details:
      O/S info: user: idol, term: unknown, ospid: 1234
      machine:     program: JDBC Thin Client
      application name: JDBC Thin Client, hash value=2546894660
    Current Wait Stack:
     0: waiting for 'cursor: pin S wait on X'
        idn=de12d336, value=5cf00000000, where|sleeps=572cf03e3
        wait_id=56059196 seq_num=26772 snap_id=1
        wait times: snap=0.001772 sec, exc=0.001772 sec, total=0.001772 sec
        wait times: max=0.010000 sec
        wait counts: calls=1 os=1
        in_wait=1 iflags=0x5a2
    There is at least one session blocking this session.
    Dumping one blocker:
      inst: 1, sid: 1487, ser: 5556

其实这里已经指出“inst: 1, sid: 1487, ser: 5556”,表示阻塞的会话是sid,serial#为1487,5556。那么如果这里没有这个信息,那么我们从哪里去寻找blocker?注意前面一段信息:idn=de12d336(对cursor来说其实是sql的hash value的低4字节), value=5cf00000000, where|sleeps=572cf03e3,这里idn表示mutex的identifier,即mutex的标识,value的高8字节(64位系统是高8字节,而32位系统是高4位字节)是SID,0x5cf即10进制的1487。

而在稍后面部分,可以看到:

      KGX Atomic Operation Log 0x455507d20
       Mutex 0x3ff3c3d28(1487, 0) idn de12d336 oper GET_SHRD
       Cursor Pin uid 1471 efd 0 whr 5 slp 13085
       opr=2 pso=0x454d03f00 flg=0
       pcs=0x3ff3c3ca8 nxt=0x41720aca0 flg=35 cld=0 hd=0x455d0dda8 par=0x3ff3c4650
       ct=0 hsh=0 unp=(nil) unn=0 hvl=ff3c4448 nhv=1 ses=0x45181f760
       hep=0x3ff3c3d28 flg=80 ld=1 ob=0x3ff3c3868 ptr=0x412040780 fex=0x41203faf0

这里有Mutex请求的更详细的信息,Mutex 0x3ff3c3d28(1487, 0) idn de12d336 oper GET_SHRD表明这个请求是以SHARE方式请求,但是Mutex被1487这个会话持有。idn与前面idn相匹配。Cursor Pin uid 1471 efd 0 whr 5 slp 13085 这里表明Mutex的类型是Cursor Pin,正是前面提到的Mutex的一种。uid 1471表明是当前请求的SID为1471。

'cursor: pin S wait on X'等待类似于以往的library cache pin等待,表示需要将cursor pin在内存中。这个等待出现,表明有会话正在修改这个cursor,比如正在执行解析,生成执行计划等。

接下来我们看SID=1487的会话正在等待什么,或者说是在执行什么操作,查找'(session) sid: 1487':

    (session) sid: 1487 ser: 5556 trans: (nil), creator: 0x450d514f0
              flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
              flags2: (0x40008) -/-
              DID: , short-term DID: 
              txn branch: (nil)
              oct: 3, prv: 0, sql: 0x455d15680, psql: 0x45bd0c8c8, user: 92/XXXXX
    ksuxds FALSE at location: 0
    service name: SYS$USERS
    client details:
      O/S info: user: idol, term: unknown, ospid: 1234
      machine:       program: JDBC Thin Client
      application name: JDBC Thin Client, hash value=2546894660
    Current Wait Stack:
     0: waiting for 'cursor: mutex X'
        idn=5336, value=1, where|sleeps=3385a5f33
        wait_id=500096450 seq_num=64401 snap_id=1
        wait times: snap=0.000000 sec, exc=0.000000 sec, total=0.000000 sec
        wait times: max=0.000000 sec
        wait counts: calls=0 os=0
        in_wait=0 iflags=0x15e0

可以看到,这个会话正在等待'cursor: mutex X'。不幸的是,这一次没有直接表明holder是谁了。idn=5336, value=1, where|sleeps=3385a5f33,这里value=1,很简单,但是表明的意义却不简单,这表明什么?低8字节为1,表明这个Mutex是被共享持有,而高8字节为0,这是共享持有的Mutex的正常状况,Mutex可能被多个会话共享持有,因此只有引用计数,而不会有持有的SID。这里1就是引用计数,表示被1个会话持有。只有在会话获取Mutex的过程中,才会暂时性的将Mutex的SID设为正在获取的SID,而一旦完成获取,就将Mutex中的SID即value的高8字节部分清0。

继续往后查看:

      KGX Atomic Operation Log 0x4543ce390
       Mutex 0x3ff3c3d28(1487, 0) idn de12d336 oper EXCL
       Cursor Pin uid 1487 efd 0 whr 1 slp 0
       opr=3 pso=0x454daaa50 flg=0
       pcs=0x3ff3c3ca8 nxt=0x41720aca0 flg=35 cld=0 hd=0x455d0dda8 par=0x3ff3c4650
       ct=0 hsh=0 unp=(nil) unn=0 hvl=ff3c4448 nhv=1 ses=0x45181f760
       hep=0x3ff3c3d28 flg=80 ld=1 ob=0x3ff3c3868 ptr=0x412040780 fex=0x41203faf0

上面一段信息表明,正是1487这个会话以EXCLUSIVE方式持有idn=de12d336的这个mutex,这正是1471会话正需要以SHARE方式获取的Mutex。

      KGX Atomic Operation Log 0x45a2b7908
       Mutex 0x44b764498(0, 1) idn 7fff00005336 oper GET_EXCL
       Cursor Stat uid 1487 efd 8 whr 3 slp 28652
       oper=OPERATION_DEFAULT pt1=(nil) pt2=(nil) pt3=(nil)
       pt4=(nil) u41=0 stt=0

上面一段信息表明,1487这个会话正在以EXCLUSIVE请求的mutex是idn=7fff00005336,Mutex类型是Cursor Stat。Cursor Stat类型的EXCLUSIVE方式请求通常是需要更新cursor的统计信息。而以SHARE方式请求通常是查询cursor的统计信息,比如说查询v$sqlstat视图。注意这里GET_EXCL表示正在以EXCLUSIVE方式请求获取(持有)mutex,而EXCL表示已经以EXCLUSIVE方式持有mutex。延伸开来,GET_SHRD表示请求SHARE方式的mutex,SHRD表示以SHARE方式持有mutex。REL_SHRD表示正在释放SHARE方式持有的mutex,也就是递减引用计数。

那么,接下来我们就要寻找是哪个会话持有了idn=7fff00005336的mutex。查找'idn 7fff00005336 oper‘,找到如下内容:

      KGX Atomic Operation Log 0x45955b2f0
       Mutex 0x44b764498(0, 1) idn 7fff00005336 oper SHRD
       Cursor Stat uid 1497 efd 7 whr 6 slp 0
       oper=OPERATION_DEFAULT pt1=(nil) pt2=(nil) pt3=(nil)
       pt4=(nil) u41=0 stt=0

可以看到的确有会话(1497)正在以共享方式持有idn=7fff00005336的mutex。往前查看,可以看到会话信息:

    (session) sid: 1497 ser: 29349 trans: (nil), creator: 0x45cccc3f0
              flags: (0x51) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
              flags2: (0x408) -/-
              DID: , short-term DID: 
              txn branch: (nil)
              oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS
    ksuxds FALSE at location: 0
    service name: SYS$BACKGROUND
    Current Wait Stack:
      Not in wait; last wait ended 14005 min 23 sec ago 
    Wait State:
      auto_close=0 flags=0x21 boundary=(nil)/-1
    Session Wait History:
     0: waited for 'db file sequential read'
        file#=2, block#=1952c, blocks=1
        wait_id=1171 seq_num=1174 snap_id=1
        wait times: snap=0.018420 sec, exc=0.018420 sec, total=0.018420 sec
        wait times: max=infinite
        wait counts: calls=0 os=0
        occurred after 0.000034 sec of elapsed time

再往前可以找到进程信息:

PROCESS 38:
  ----------------------------------------
  SO: 0x45cccc3f0, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
   proc=0x45cccc3f0, name=process, file=ksu.h LINE:10706, pg=0
  (process) Oracle pid:38, ser:76, calls cur/top: 0x440d0ae48/0x43c5e5f88
            flags : (0x2) SYSTEM
            flags2: (0x30),  flags3: (0x0) 
            int error: 0, call error: 0, sess error: 0, txn error 0
  ksudlp FALSE at location: 0
  (post info) last post received: 0 0 42
              last post received-location: ksv2.h LINE:1603 ID:ksvpst: run
              last process to post me: 450d4b4f0 1 2
              last post sent: 0 0 151
              last post sent-location: kcrf.h LINE:3095 ID:kcrfw_redo_gen: wake LGWR after redo copy
              last process posted by me: 45ccbe3f0 1 6
    (latch info) wait_event=0 bits=0
    Process Group: DEFAULT, pseudo proc: 0x4510353e0
    O/S info: user: oracle, term: UNKNOWN, ospid: 13549 
    OSD pid info: Unix process pid: 13549, image: oracle@xxxxx (m001)

可以看到m001这个进程持有了mutex。但是会话没有在执行任何sql语句,而从会话的等待来看,last wait ended 14005 min 23 sec ago ,这个是不正常的,m001进程应该是出现了异常。

m001进程是什么,这是mmon的slave进程,其中一个作用就是执行awr snapshot。很显然这个进程要访问v$sqlstat,是需要持有Cursor Stat类型的mutex的。

至此就找到了所有等待的root holder。不过把这个结果告诉维护这个库的朋友时,告知服务器之前“死”了,已经重启了。重启后检查数据库,发现在故障期间很长一段时间内的确是没有产生awr snapshot。至于m001进程出了什么异常,为什么会出现异常,本文就不再详细讨论。实际上服务器重启之后也没有继续跟踪这一问题。

mutex从设计上来说,与latch相比有着很明显的优点,只是作为新生事务(相对于目前仍然在广泛使用的10g来说), 存在BUG的可能性比较大。深入了解mutex,可以帮助我们更好地诊断mutex引起的相关问题。

Trackback

4 comments untill now

  1. 以前我们公司的库上也出现过这个问题,后来强制重启后问题就没再发生过,不过博主分析的很好,受益匪浅!

    [回复]

  2. 受益了,深感佩服。

    [回复]

  3. 此老熊彼老熊乎?

    [回复]

    老熊 回复:

    @spainee,
    彼老熊又是谁,哈哈!

    [回复]

Add your comment now