Oracle Internal Research内部原理研究

【内部原理】模拟Cursor: Pin S on X并解释X$mutex_sleep.location

2013/10/09 by admin Leave a Comment

X$mutex_sleep.location 的官方解释是 Location that attempted to acquire the latch (Mutex’s code location (where field) ，这个解释看上去还是有些模糊，我们来做个试验看看

我们简单地使用 gdb来模拟一个Curosr : Pin S on X等待事件，并以此事件来解释X$mutex_sleep.location 的真实含义
我们会打开3个session 分别为A、B、C ，一个gdb ，和一个sqlplus 用以oradebug

Session A:

[oracle@mlab2 ~]$ sqlplus  / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 8 21:40:19 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production

create table emp as select * from scott.emp;

SQL> var b1 number;
SQL> begin :b1 := 7902; end;
  2  /

PL/SQL procedure successfully completed.

SQL> select * from emp where empno = :b1
  2  /

     EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM
---------- ---------- --------- ---------- --------- ---------- ----------
    DEPTNO
----------
      7902 FORD       ANALYST         7566 03-DEC-81       3000
        20

获取session A的SPID ，使用gdb attach到该SPID

[oracle@mlab2 ~]$ gdb $ORACLE_HOME/bin/oracle 26868

break kxsPeekBinds
bt 4
end 
cont

登录session B 并flush shared pool:

alter system flush shared_pool;

登录session C 并执行上面的查询语句：

var b1 number;
begin :b1 := 7902; end;
/
select * from emp where empno = :b1
/

如上如果顺利的话session C会hang在cursor: pin S wait on X 等待事件上，而gdb中显示 session A 的stack call为：

(gdb) cont
Continuing.

Breakpoint 1, 0x0000000002123fa0 in kxsPeekBinds ()
#0  0x0000000002123fa0 in kxsPeekBinds ()
#1  0x00000000025b821c in opitca ()
#2  0x0000000001ecf7a9 in kksSetBindType ()
#3  0x0000000009641a89 in kksfbc ()
(gdb) bt
#0  0x0000000002123fa0 in kxsPeekBinds ()
#1  0x00000000025b821c in opitca ()
#2  0x0000000001ecf7a9 in kksSetBindType ()
#3  0x0000000009641a89 in kksfbc ()
#4  0x00000000095bff0a in opiexe ()
#5  0x0000000001ba5992 in kpoal8 ()
#6  0x00000000095bbdad in opiodr ()
#7  0x00000000097a629f in ttcpip ()
#8  0x000000000186470e in opitsk ()
#9  0x0000000001869235 in opiino ()
#10 0x00000000095bbdad in opiodr ()
#11 0x00000000018607ac in opidrv ()
#12 0x0000000001e3a48f in sou2o ()
#13 0x0000000000a29265 in opimai_real ()
#14 0x0000000001e407ad in ssthrdmain ()
#15 0x0000000000a291d1 in main ()

即 session A在kxsPeekBinds 窥视绑定变量过程中以EXCL排它模式PIN住 child cursor，而 session C需要执行该SQL 需要以SHRD PIN该child cursor 并进入cursor: pin S wait on X 等待

select * from x$mutex_sleep;

ADDR                   INDX    INST_ID MUTEX_TYPE                       MUTEX_TYPE_ID LOCATION_ID LOCATION                                     SLEEPS  WAIT_TIME
---------------- ---------- ---------- -------------------------------- ------------- ----------- ---------------------------------------- ---------- ----------
00007F6D82F54108         15          1 Cursor Pin                                   7           5 kkslce [KKSCHLPIN2]                         1500022          0

SQL>  select mutex_type,location_id,location,sleeps from x$mutex_sleep_history order by sleeps asc;

MUTEX_TYPE                       LOCATION_ID LOCATION                                     SLEEPS
-------------------------------- ----------- ---------------------------------------- ----------
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               1
Library Cache                            109 kglllal1 109                                      1
Library Cache                             95 kglpndl1  95                                      1
Library Cache                             57 kgllkc1   57                                      1
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               1
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               1
Library Cache                             32 kglini1   32                                      1
Library Cache                              4 kglpin1   4                                       1
Library Cache                              2 kglget2   2                                       1
Library Cache                             62 kglhdgn1  62                                      1
Library Cache                            106 kglhdgn2 106                                      1
Library Cache                              4 kglpin1   4                                       1
Library Cache                              4 kglpin1   4                                       1
Library Cache                            111 kglllal3 111                                      1
Library Cache                              4 kglpin1   4                                       1
Library Cache                             85 kgllkdl1  85                                      1
Library Cache                             62 kglhdgn1  62                                      1
Library Cache                             62 kglhdgn1  62                                      1
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               1
Library Cache                            111 kglllal3 111                                      1
Library Cache                             85 kgllkdl1  85                                      1
Library Cache                             32 kglini1   32                                      1
Cursor Parent                             34 kkscsAddChildNode [KKSPRTLOC34]                   1
Library Cache                             62 kglhdgn1  62                                      1
Library Cache                             62 kglhdgn1  62                                      1
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               2
Library Cache                             90 kglpnal1  90                                      2
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               2
Library Cache                             57 kgllkc1   57                                      2
Library Cache                            106 kglhdgn2 106                                      2
Library Cache                            119 kglUpgradeLock 119                                2
Library Cache                            102 kglhdgc1  102                                     2
Library Cache                            106 kglhdgn2 106                                      2
Library Cache                             57 kgllkc1   57                                      2
Library Cache                             90 kglpnal1  90                                      2
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               2
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               3
Library Cache                            112 kgllldl2 112                                      3
Library Cache                            106 kglhdgn2 106                                      3
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               3
Library Cache                              4 kglpin1   4                                       3
Library Cache                             57 kgllkc1   57                                      3
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               3
Library Cache                             57 kgllkc1   57                                      3
Library Cache                              4 kglpin1   4                                       3
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               4
Library Cache                             57 kgllkc1   57                                      4
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               4
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               4
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               5
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                               6
Library Cache                              4 kglpin1   4                                       6
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                             179
Cursor Pin                                 5 kkslce [KKSCHLPIN2]                         2657144

SQL> select event from v$session where sid=138;

EVENT
----------------------------------------------------------------
cursor: pin S wait on X

session C对应的stack call:

SQL> oradebug short_stack;
ksedsts()+465<-ksdxfstk()+32<-ksdxcb()+1927<-sspuser()+112<-__sighandler()<-__select()+19<-skgpwwait()+332<-kgxWait()+774<-kgxSharedExamine()+568
<-kxsGetRuntimeLock()+240<-kkscsCheckCursor()+556<-kkscsSearchChildList()+1171<-kksfbc()+12417<-kkspsc0()+1171<-kksParseCursor()+116<-opiosq0()+2027
<-kpooprx()+274<-kpoal8()+842<-opiodr()+917<-ttcpip()+2183<-opitsk()+1710<-opiino()+969<-opiodr()+917<-opidrv()+570<-sou2o()+103<-opimai_real()+133
<-ssthrdmain()+265<-main()+201<-__libc_start_main()+244

kkscsSearchChildList 搜索child cursor list
kkscsCheckCursor 检查child cursor
kxsGetRuntimeLock kgxSharedExamine 尝试获取child cursor上的SHRD 共享PIN
尝试获取失败后 进入Mutex等待 kgxWait

查询 x$mutex_sleep 发现 location为 kkslce [KKSCHLPIN2] ，LOCATION_ID为 5 ，我们通过 systemstate 266来看一下Mutex的情况：

SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump systemstate 266;
Statement processed.
SQL> oradebug tracefile_name 
/s01/diag/rdbms/g11r204/G11R204/trace/G11R204_ora_26999.trc

    SO: 0x11b8900d0, type: 4, owner: 0x11b528118, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
     proc=0x11b528118, name=session, file=ksu.h LINE:12729, pg=0
    (session) sid: 138 ser: 29 trans: (nil), creator: 0x11b528118
              flags: (0x41) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
              flags2: (0x40009) -/-/INC
              DID: , short-term DID:
              txn branch: (nil)
              edition#: 100              oct: 3, prv: 0, sql: 0x11412a3e8, psql: 0x10f565680, user: 0/SYS
    ksuxds FALSE at location: 0
    service name: SYS$USERS
    client details:
      O/S info: user: oracle, term: pts/2, ospid: 26921
      machine: mlab2.oracle.com program: sqlplus@mlab2.oracle.com (TNS V1-V3)
      application name: sqlplus@mlab2.oracle.com (TNS V1-V3), hash value=339804622
    Current Wait Stack:
     0: waiting for 'cursor: pin S wait on X'
        idn=0xc97fc340, value=0x8e00000000, where=0x500000000
        wait_id=12 seq_num=13 snap_id=1
        wait times: snap=2.245331 sec, exc=2.245331 sec, total=2.245331 sec
        wait times: max=infinite, heur=1 min 12 sec
        wait counts: calls=0 os=0
        in_wait=1 iflags=0x5a2
    There is at least one session blocking this session.
      Dumping 1 direct blocker(s):
        inst: 1, sid: 142, ser: 253
      Dumping final blocker:
        inst: 1, sid: 142, ser: 253

mutex的idn=0xc97fc340

      KGX Atomic Operation Log 0x10f10c230
       Mutex 0x10ef26e68(142, 0) idn c97fc340 oper LONG_EXCL(18)
       Cursor Pin uid 142 efd 0 whr 1 slp 0
       opr=3 pso=0x1140fa930 flg=0
       pcs=0x10ef26dd0 nxt=(nil) flg=34 cld=0 hd=0x10f24b0a0 par=0x10ef268d0
       ct=1 hsh=0 unp=(nil) unn=0 hvl=ef276c0 nhv=1 ses=0x11b883d50
       hep=0x10ef26e68 flg=80 ld=1 ob=0x10ef25830 ptr=0x1163cc070 fex=0x1163cb430

      KGX Atomic Operation Log 0x10eee2a10
       Mutex 0x10ef26e68(142, 0) idn c97fc340 oper GET_SHRD(1)
       Cursor Pin uid 138 efd 0 whr 5 slp 2074
       opr=2 pso=0x10eedbd60 flg=0
       pcs=0x10ef26dd0 nxt=(nil) flg=34 cld=0 hd=0x10f24b0a0 par=0x10ef268d0
       ct=1 hsh=0 unp=(nil) unn=0 hvl=ef276c0 nhv=1 ses=0x11b883d50
       hep=0x10ef26e68 flg=80 ld=1 ob=0x10ef25830 ptr=0x1163cc070 fex=0x1163cb430

      SO: 0x1140fa930, type: 78, owner: 0x11b883d50, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
       proc=0x11b51fb58, name=LIBRARY OBJECT LOCK, file=kgl.h LINE:8751, pg=0

      LibraryObjectLock:  Address=0x1140fa930 Handle=0x10f24b0a0 Mode=N CanBeBrokenCount=2 Incarnation=2 ExecutionCount=0
        ClusterLock=0x10f10c230 Context=0x7f5dfce48600 User=0x11b883d50 Session=0x11b883d50 ReferenceCount=1
        Flags=CBK/[0020] SavepointNum=0
      LibraryHandle:  Address=0x10f24b0a0 Hash=0 LockMode=N PinMode=X LoadLockMode=0 Status=VALD
        Name:  Namespace=SQL AREA(00) Type=CURSOR(00)
        Statistics:  InvalidationCount=1 ExecutionCount=0 LoadCount=2 ActiveLocks=2 TotalLockCount=3 TotalPinCount=5
        Counters:  BrokenCount=2 RevocablePointer=2 KeepDependency=0 Version=0 BucketInUse=0 HandleInUse=0 HandleReferenceCount=0
        Concurrency:  DependencyMutex=0x10f24b150(0, 0, 0, 0) Mutex=0x11412a528(0, 35, 0, 0)
        Flags=RON/PIN/PN0/EXP/CHD/[10012111]
        WaitersLists:
          Lock=0x10f24b130[0x10f24b130,0x10f24b130]
          Pin=0x10f24b110[0x10f24b110,0x10f24b110]
          LoadLock=0x10f24b188[0x10f24b188,0x10f24b188]
        LibraryObject:  Address=0x10ef25830 HeapMask=0000-0001-0001-0000 Flags=EXS[0000] Flags2=[0000] PublicFlags=[0000]
          DataBlocks:
            Block:  #='0' name=KGLH0^c97fc340 pins=0 Change=NONE
              Heap=0x10f24afe8 Pointer=0x10ef258d0 Extent=0x10ef257b0 Flags=I/-/P/A/-/-
              FreedLocation=0 Alloc=2.304688 Size=3.976562 LoadTime=4377720080
            Block:  #='6' name=SQLA^c97fc340 pins=0 Change=NONE
              Heap=0x10ef26f10 Pointer=0x1163cc070 Extent=0x1163cb430 Flags=I/-/P/A/-/E
              FreedLocation=0 Alloc=10.718750 Size=11.859375 LoadTime=0
        NamespaceDump:
          Child Cursor:  Heap0=0x10ef258d0 Heap6=0x1163cc070 Heap0 Load Time=10-08-2013 21:43:08 Heap6 Load Time=10-08-2013 21:43:08  

      SO: 0x1140fab30, type: 78, owner: 0x11b883d50, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
       proc=0x11b51fb58, name=LIBRARY OBJECT LOCK, file=kgl.h LINE:8751, pg=0

      LibraryObjectLock:  Address=0x1140fab30 Handle=0x11412a3e8 Mode=N CanBeBrokenCount=1 Incarnation=1 ExecutionCount=0

        User=0x11b883d50 Session=0x11b883d50 ReferenceCount=1 Flags=CNB/[0001] SavepointNum=5254b4ac
      LibraryHandle:  Address=0x11412a3e8 Hash=c97fc340 LockMode=N PinMode=0 LoadLockMode=0 Status=VALD
        ObjectName:  Name=select * from emp where empno = :b1
          FullHashValue=2d346c57ec22f350eb98796dc97fc340 Namespace=SQL AREA(00) Type=CURSOR(00) Identifier=3380593472 OwnerIdn=0
        Statistics:  InvalidationCount=1 ExecutionCount=1 LoadCount=3 ActiveLocks=2 TotalLockCount=3 TotalPinCount=1
        Counters:  BrokenCount=1 RevocablePointer=1 KeepDependency=1 Version=0 BucketInUse=2 HandleInUse=2 HandleReferenceCount=0
        Concurrency:  DependencyMutex=0x11412a498(0, 1, 0, 0) Mutex=0x11412a528(0, 35, 0, 0)
        Flags=RON/PIN/TIM/PN0/DBN/[10012841]
        WaitersLists:
          Lock=0x11412a478[0x11412a478,0x11412a478]
          Pin=0x11412a458[0x11412a458,0x11412a458]
          LoadLock=0x11412a4d0[0x11412a4d0,0x11412a4d0]
        Timestamp:  Current=10-08-2013 21:40:55
        HandleReference:  Address=0x11412a5b8 Handle=(nil) Flags=[00]
        LibraryObject:  Address=0x10ef26830 HeapMask=0000-0001-0001-0000 Flags=EXS[0000] Flags2=[0000] PublicFlags=[0000]
          ChildTable:  size='16'
            Child:  id='0' Table=0x10ef276e0 Reference=0x10ef27140 Handle=0x10f24b0a0
        NamespaceDump:
          Parent Cursor:  sql_id=fr63tdr4rzhu0 parent=0x10ef268d0 maxchild=1 plk=y ppn=n

结论：

如上述trace ，以LONG_EXCL(18)方式持有Mutex 0x10ef26e68的是SID=142的session 其whr 即location id 为1，而对应的等待cursor:pin S on X的session的whr 为5 sleep 为2074次，这里whr=5 对应了 x$mutex_sleep.location , 所以我们可以明确知道 x$mutex_sleep 也即v$MUTEX_SLEEP视图上的 LOCATION字段指的是发起对该Mutex申请的代码路径code location，而不是还持有该Mutex的代码路径或曰内核函数。

Filed Under: Oracle, Oracle Internal Research内部原理研究

Oracle中的Low HWM与 High HWM 高水位

2013/09/22 by admin 5 Comments

在MSSM的FREELIST下，高水位High Water Mark代表所有相关块，高水位以上就是未格式化unformatted 的数据块，INSRT数据时不能直接使用。当FREELIST中不包含可插入数据块时 HWM默认每次上升5个数据块。

对于ASSM管理的BITMAP 数据段而言，Oracle允许在数据段的中部出现unformatted blocks未格式化的数据块，基于以下的原因：

一、在以前 HWM以下的数据块必然是formatted ，为了维护这一点代价是昂贵的：

长时间持有HW enqueue 队列锁对并发的抑制
过于频繁的持有HW enqueue在Oracle研发看来是罪恶的

上涨HWM 而不格式化这样的话更有效率，因为格式化往往涉及到 IO，是一种较慢的操作

二、在直接路径加载过程中，最后的一个extent中的数据块将被全部format 格式化，而如果下一次还是direct load直接路径加载数据的话，它不会从Freelist上获取数据块，而是使用HWM以上新的数据盘区extent。如果这个数据段是典型的一直在direct load加载数据的话，则可能在freelist上有很多unused block从来不被使用，而被浪费了。这可能造成空间的浪费，尤其是在Extent size 很大的时候或者数据段几乎从来不传统路径插入数据的时候。保留这些数据块为unformatted则可以让加载数据时利用到这些空间空洞

为了实现这一点就需要使用2个High Water Mark 即Low HWM和High HWM; Low HWM以下都是formatted 数据块而 High HWM以上都是unformatted数据块。

  Extent Header:: spare1: 0      spare2: 0      #extents: 18413  #blocks: 147304
                  last map  0xabc23541  #maps: 36     offset: 2716
      Highwater::  0xabc23f6c  ext#: 18412  blk#: 3      ext size: 8
  #blocks in seg. hdr's freelists: 0
  #blocks below: 147299
  mapblk  0xabc23541  offset: 325
                   Unlocked
  --------------------------------------------------------
  Low HighWater Mark :
      Highwater::  0xabc23f6c  ext#: 18412  blk#: 3      ext size: 8
  #blocks in seg. hdr's freelists: 0
  #blocks below: 147299
  mapblk  0xabc23541  offset: 325
  Level 1 BMB for High HWM block: 0xabc23ef9
  Level 1 BMB for Low HWM block: 0xabc23ef9
  --------------------------------------------------------
  Segment Type: 1 nl2: 2      blksz: 8192   fbsz: 0
  L2 Array start offset:  0x00001434
  First Level 3 BMB:  0x00000000
  L2 Hint for inserts:  0xabc0000a
  Last Level 1 BMB:  0xabc23ef9
  Last Level II BMB:  0xabc1d5fa
  Last Level III BMB:  0x00000000
     Map Header:: next  0xabc009a1  #extents: 307  obj#: 99039  flag: 0x10000000
  Inc # 0
  Extent Map

在顺序读取过程中，那些unformatted数据块将被忽略。关于一个数据块究竟是format了还是没有的信息是存放在2个高水位之间的bitmap中。当扫描数据段的块时，扫描算法并不参考LOW HWM以下的bitmap block； High HWM用来作为顺序读取该数据段时停止扫描的位置。

格式化数据块一般发生在搜索空间时，如果数据块被发现时unformatted，则格式化一部分数据块(至少16个)。格式化数据块未必更新Low HWM。

何时更新LOW HWM是一个问题: Low HWM在当前extent和之前的extent中的所有数据块均被格式化的情况下被更新，否则不更新。

来举2个场景： HENO=高水位盘区号， HBNO= 高水位数据块号，MyEno = My Extent number; MyBno = My block number. ：

如果(HEno == MyEno && MyBno == HBno+1)，例如在同一个extent中格式化下一个范围的block

如果(HEno + 1 == MyEno && HBno == HExtentSize &&MyBno == 0)，例如在前一个extent中所有的数据块均已format 然后要format下一个extent时

对于High HWM而言，如果High HWM以下的数据块不够用，则可能上升High HWM，这个过程需要用到HW Enqueue队列锁。High HWM移动的块数目取决于一级bitmap block控制的块数目，HIGH HWM以下包含了所有的L1 bitmap block。

Filed Under: Oracle, Oracle Internal Research内部原理研究

全面解析9i以后Oracle Latch闩锁原理

2013/08/19 by admin 2 Comments

Latch闩锁在Oracle中属于 KSL Kernel Services Latching，而从顶层视图来说 KSL又属于VOS Virtual Operating System。

Latches 是一种低级别(low-level)的锁机制，初学IT的同学请注意低级不代表简单， C语言对比java语言要低级一些但C并不比java简单。

在一些文章著作中也将latch称为spin lock 自旋锁。 latch用来保护共享内存(SGA)中的数据以及关键的代码区域。一般我们说有2种latch：

1)Test and Set 简称TAS :

TAS是计算机科学中的专指， test-and-set instruction 指令用以在一个原子操作(atomic 例如非中断操作)中写入到一个内存位置，并返回其旧的值。常见的是值1被写入到该内存位置。如果多个进程访问同一内存位置，若有一个进程先开始了test-and-set操作，则其他进程直到第一个进程结束TAS才可以开始另一个TAS。

关于TAS指令更多信息可以参考wiki ，包括TAS的伪代码例子: http://t.cn/zQgATRr

askmac.cn

在Oracle中Test-And-Set类型的latch使用原生的Test-And-Set指令。在绝大多数平台上，零值zero代表latch是空闲或者可用的 , 而一个非零值代表 latch 正忙或者被持有。但是仅在HP PA-RISC上正相反。 TAS latch只有2种状态 : 空闲或者忙。

2) Compare-And-Swap 简称 CAS

Compare-And-Swap 也是计算机专有名词， Compare-And-Swap(CAS)是一个用在多线程环境中实现同步的原子指令( atomic )。该指令将在一个给定值(given value)和指定内存位置的内容之间比对，仅在一致的情况下修改该内存位置的内容为一个给定的新值(不是前面那个值)。这些行为都包含在一个单独的原子操作中。原子性保证了该新的值是基于最新的信息计算获得的；如果该内存位置的内容在同时被其他线程修改过，则本次写入失败。该操作的结果必须说明其到底是否执行了取代动作。它要么返回一个布尔类型的反馈，要么返回从指定内存地址读取到的值(而不是要写入的值)。

关于CAS的更多信息可以参考 http://t.cn/hcEqh

Oracle中的 Compare-And-Swap Latch也使用原生态的Compare-And-Swap指令。和TAS Latch类似，空值代表latch是free的，而一个非空值代表latch正忙。但是一个CAS latch 可以有多种状态：空闲的、以共享模式被持有、以排他模式被持有。 CAS latch可以在同一时间被多个进程或线程以共享模式持有，但还是仅有一个进程能以排他模式持有CAS latch。典型的情况下，共享持有CAS latch的进程以只读模式访问相关数据，而一个排他的持有者目的显然是要写入/修改对应CAS latch保护的数据。

举例来说， CAS latch的共享持有者是为了扫描一个链表 linked list ，而相反排他的持有者是为了修改这个列表。共享持有者的总数上线是0x0fffffff即10进制的 268435455。

注意几乎所有平台均支持CAS latch，仅仅只有HP的PA-RISC平台不支持(惠普真奇葩)。在PA-RISC上CAS latch实际是采用TAS latch。所以虽然在HP PA-RISC上代码仍会尝试以共享模式获得一个latch，但是抱歉最终会以排他模式获得这个latch。

一般一个latch会包含以下信息：

Latch type 类型， latch type定义了是TAS 还是CAS latch， latch class和 latch number
Latch的 level 级别
持有该latch的代码位置where ,例如使用kslgetl函数获得某个latch，则持有文职为kslgetl
持有该latch的原因
nowait模式下获得该latch的次数 V$LATCH.IMMEDIATE_GETS
wait模式下第一个尝试失败的次数 V$LATCH .MISSES
nowait模式下尝试失败的次数 V$LATCH.IMMEDIATE_MISSES
获取latch失败造成sleep的总时间 X$KSLLTR.KSLLTWSL, V$LATCH.SLEEPS
首次spin成功获得latch的次数 X$KSLLTR.KSLLTHST0, V$LATCH.SPIN_GETS
latch wait list等等

子闩 child latch

当一个单一的latch要保护过多的资源时会造成许多争用，在此种场景中 child latch变得很有用。为了使用child latch，需要分割原latch保护的资源为多个分区，最常见的例子是放入到多个hash buckets里，并将不同子集的资源分配给一个child latch。比起每一个hash bucket都去实现一个单独的latch来说，编程上使用child latch要方便的多，虽然这不是我们用户所需要考虑的。为一个latch 定义多个child latch，则这个latch称为parent latch父闩。 child latch 可以继承 parent latch的一些属性，这些属性包括级别和清理程序。换句话说， child latch就像是parent 父闩的拷贝一样。

经典情况下，在SGA 初始化过程中child latch将被分配和初始化(startup nomount)。但在目前版本中(10/11g)中也允许在实例启动后创建和删除latch。

child latch又可以分成2种：

允许一个进程/线程在同一时刻持有2个兄弟child latch
不允许一个进程/线程在同一时刻持有2个兄弟child latch

因为child latch从parent latch那里继承了属性，所以注意 child latch的 latch level和 parent 父闩是一样的。因为一个进程/线程不能在同一时间持有2个latch level一样的闩，所以正常情况下一个进程/线程也不能同一时间持有2个兄弟child latch。

回到我们说的hash bucket的例子里来，假设一个进程/线程有将一个resource从一个hash bucket 移动到另一个hash bucket的需求，在此场景中就需要同时持有2个兄弟child latch。但是如果允许这种同时持有2个兄弟child latch的行为发生的话，那么很容易造成死锁deadlock的麻烦。 oracle 不允许进程/线程任意地同时获得2个兄弟child latch，由于此种操作很容易引起死锁。由此引入了一些规则：兄弟child latch必须是相关的child number ,且进程/线程只能以特性的顺序来同时get 2个兄弟child latch，即child number 从大到小低贱的顺序。

此外需要注意的是仅有TAS latch可以同时get多个兄弟child latch，目前还不支持 CAS的latch。

Latch 清理恢复

Oracle中定义了一个latch，就需要这个latch对应的清理函数cleanup function，这个函数在以下2个场景中生效：

当某个latch被持有，但是持有进程遇到了某一个错误 ==》主动
当持有latch的进程die掉，需要PMON进程前去恢复这个latch的状态 ==》被动

经典情况下，执行清理函数的进程要么把正在执行过程中的操作回滚掉，要么前滚掉。为了为前滚(rolling forward)或者回滚(rolling back)提供必要的信息， oracle在latch结构中加入了recovery的结构，其中包含了这个正在执行过程中的操作的日志信息，这些日志信息必须包含足以前滚或者回滚的数据。如我们以前讲过的，理论上oracle进程可能在运行任何指令的时候意外终止，所以清理恢复是常事。

清理恢复最恶心的bug是PMON 执行cleanup function时因为代码bug ，把PMON自己给弄dead了，由于PMON的关键的后台进程，所以这会引起实例终止。

Latch和 10.2.0.2后引入的KGX Mutex对比

和 latch一样， kgx mutex也是用来控制串行化访问SGA中数据的，但仍有一些重要区别：

KGX mutex要比 CAS latch更轻量级， mutex 结构大约为16个字节，而一个latch结构大约是100个字节。因此 mutex嵌入到大量其他对象结构中是可行的，因为他的struct 足够小
之所以mutex可以提供更小的结构很廉价的成本，其原因是使用mutex有一个简单的前提假设：对于mutex的争用是很小的。因此没有为mutex那样提供一个优化过的wait list ， mutex做更多的 SPIN & WAIT 并消耗更多的CPU。此外mutex也没有提供任何死锁检测和预防机制，这些都完全取决于Kgx mutex的用户自身的行为。
Latch在内部视图(例如X$KSLLT)中提供全面的诊断信息。 KGX mutex在(x$mutex_sleep、x$mutex_sleep_history等内部视图)中提供部分信息，同时也允许其用户在回调程序中用特定信息填充这些视图。
除了共享和排他模式之外， KGX mutex还提供一种examine 模式，允许其在不以共享或排他模式持有mutex的情况下client检查一个mutex的状态以及其用户数据。这种模式是latch所没有的

Latch 和Enqueue lock队列锁对比，以下是latch和enqueue的几个重大区别：

在典型情况下，latch被认为将仅仅被持有很短的一段时间(ms级别)，而enqueue 将被持有比之长得多的多的时间(秒=》分钟=》小时)。例如TX 队列事务锁在整个事务的生命周期中被持有。 latch被设计出来就是为了在函数运行到某几十个乃至上百个指令过程中被持有，这是很短暂的过程
latch是为了避免同一时间有一个以上的进程运行相似的代码片段，而enqueue是为了避免同一时间多于一个的进程访问相同的资源
latch的使用较为简单，而enqueue的使用则由于命名空间namespace和死锁检测的问题而较为麻烦
latch只有2个模式共享和排他，而enqueue 则支持6个模式
RAC中 latch 总是本地存放在当前实例的SGA中，而enqueue可以是Local的也可能是Global的
9i以前latch不是FIFO的，是抢占式的；从9i开始大多数latch也是FIFO了； enqueue始终是FIFO的

有同学仍不理解 latch和enqueue的区别的话，可以这样想一下， latch 保护的SGA中的数据对用户来说几乎都是不可见的，例如 cache buffer的hash bucket 对不研究内部原理的用户来说等于不存在这个玩样，这些东西都是比较简单的数据结构struct ，如果你是开发oracle的人你会用几百个字节的enqueue 来保护几个字节的一个变量吗？

而队列锁 TX是针对事务的， TM是针对表的，US是针对 undo segment的，这些东西在实例里已经属于比较高级的对象了，也是用户常可见的对象，维护这些对象需要考虑死锁检测、并发多模式访问、RAC全局锁等等问题，所以需要用更复杂的enqueue lock。

死锁dead lock

为了使得latch使用足够轻量级，死锁预防机制十分简单。由此Oracle开发人员在构建一个latch时会定义一个数字级别 level (从 0 到 16 )，并且Oracle要求它们必须以level增序顺序获取。若一个进程/线程在持有一个 latch的情况下，要求一个相同或者更低level的latch的话，KSL层会生成一个内部错误，这种问题称为 “latch hierarchy violation”。

SQL> select distinct level# from v$latch order by 1;

    LEVEL#
----------
         0
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        14
        15
        16

仅有以nowait模式get latch时可以以级别(level) 非兼容的级别获得一个latch，但是这种情况非常少。

Latch Level 级别

Oracle在定义latch level的时候取决于以下2个原则：

那些latch是在被持有的情况下，进程/线程还会去get其他的latch?
当已经有latch被进程/线程持有的情况下，那些latch还会被 get?

如上文dead lock的描述， latch level的一大作用是帮助减少latch dead lock。

Latch Class

latch的类class定义了如下的内容：

spin count
yield count (number of times we yield cpu before sleeping)
wait time sample rate (0 implies it is not enabled)
sleep (in microseconds and repeated [see below])

对于post/wait 类而言 SLEEP_BUCKET和SLEEP_TIME 是被忽略的。

以下是几个latch class:

Class 0 Post/Wait Class ，绝大多数latch都是该类型

Class 1 Waiter List Latch。该Latch保护对应latch的Waiter List，这种latch被假定总是只被持有非常短的时间(指令级别)，有充分的理由花费更多的spin count 消耗更多的CPU ，并尽可能减少sleep时间

Class 2 那些由于多种原因，不能使用post/wait机制的latch 。例如process allocation latch 这个闩是在一个新进程创建时所需要获取的，但是新进程还没加载post/wait的上下文，显然无法用post/wait ，所以这种 latch不能用post /wait机制

Class 3 非常短持有的latch，特性与class 1类似。

CLASS_KSLLT字段代表了latch的类型

SQL> select CLASS_KSLLT,count(*) from x$kslltr group by CLASS_KSLLT;

CLASS_KSLLT   COUNT(*)
----------- ----------
          2          1
          0        702

SQL> select KSLLTNAM,CLASS_KSLLT from x$kslltr where CLASS_KSLLT=2;

KSLLTNAM                                                         CLASS_KSLLT
---------------------------------------------------------------- -----------
process allocation                                                         2

从9.0.2 开始每个latch class的SPIN COUNT、YIELD COUNT 、WAITTIME_SAMPLING 、 SLEEP_TIME[1] …. SLEEP_TIME[i] 均在参数_latch_class_X中定义。

SQL> col name for a20
SQL> col avalue for a20
SQL> col sdesc for a20

SELECT x.ksppinm NAME,y.ksppstvl avalue,x.KSPPDESC sdesc
 FROM SYS.x$ksppi x, SYS.x$ksppcv y
 WHERE x.inst_id = USERENV ('Instance')
 AND y.inst_id = USERENV ('Instance')
 AND x.indx = y.indx
AND x.ksppinm like '%latch%class%';

NAME                 AVALUE               SDESC
-------------------- -------------------- --------------------
_latch_class_0                            latch class 0
_latch_class_1                            latch class 1
_latch_class_2                            latch class 2
_latch_class_3                            latch class 3
_latch_class_4                            latch class 4
_latch_class_5                            latch class 5
_latch_class_6                            latch class 6
_latch_class_7                            latch class 7
_latch_classes                            latch classes override

SQL> select INDX,SPIN,YIELD,WAITTIME,SLEEP0 from X$KSLLCLASS;

      INDX       SPIN      YIELD   WAITTIME     SLEEP0
---------- ---------- ---------- ---------- ----------
         0      20000          0          1       8000
         1      20000          0          1       1000
         2      20000          0          1       8000
         3      20000          0          1       1000
         4      20000          0          1       8000
         5      20000          0          1       8000
         6      20000          0          1       8000
         7      20000          0          1       8000

8 rows selected.

举例来说 _latch_class_1=”5000 2 0 1000 2000 4000 8000″ 则

SPIN_COUNT=5000
YIELD_COUNT=2
wait time sampling: 0 (不收集，一般都是1即收集)
增序的sleep time 1000 => 2000 => 4000 => 8000，单位是microseconds，超过4次则保持在8000

每一个wait class 适应自己对应_latch_class_X中的SPIN_COUNT、YIELD_COUNT等参数。而实例参数_SPIN_COUNT只做为向后兼容，若对应的latch Class没有自己的SPIN_COUNT属性才会生效。

由此实际生效的SPIN_COUNT由由以下几个参数按优先级从高到低生效：

首先是设置过的_latch_class_X 中的SPIN_COUNT
设置够的_SPIN_COUNT
内部函数

注意除非是oracle support建议你去修改这些latch参数，否则在任何系统中都不该去尝试修改它们，如果你确实遇到了latch free的问题，那么你应当首先做 SQL 调优和并发调整。

SPIN

还记得电影《inception》盗梦空间里中旋转的陀螺吗，旋转的陀螺在英文里就是spinning top。 spin 自旋是 latch话题中一个频率很高的词，但是一直以来我们对自旋的理解都不够彻底，下面我们彻底解释 9i以后的自旋SPIN 和 Busy Latch原理。

SPIN 是指当进程首先尝试获取latch失败后( 一般是别人持有了该latch)，有2种选择要么是退让CPU(yield CPU) 休眠一段时间后再重新尝试获取latch ，要么是本进程抱着希望在CPU 上空转，因为如果我不用CPU了让给别人用了就会造成context switch上下文切换 (vmstat 里看到的CS)，而我在CPU上空转的话就可以等等看这个latch是否会在这段时间里被人家释放，我的一次空转称为SPIN 一次，而SPIN_COUNT定义了我在这次总的SPIN 操作里总共SPIN 空转多少次，例如SPIN_COUNT=2000(注意见上文中对SPIN_COUNT的描述)就是说我有机会空转 2000次，空转一次后我跑去查看一下latch是否被别人释放了，如果没有我继续下一次空转，如果是释放了那么我就获得这个latch了，也就是SPIN_GETS成功了。如果SPIN 2000次了还是没有等到释放latch，则SPIN_GETS没有成功，之后该SLEEP就SLEEP( 9i前后从9i开始有区别，具体见下文)。

如果上述SPIN GET的成功获得了latch，那么因为我没有退让CPU 也就没有上下文切换，所以显然我获得latch的速度要比直接sleep并重试来的快。

另假设我提高了某个latch对应的 spin_count ，例如修改latch_class_1中的SPIN_COUNT为更高的值，则在上述情况下可能SPIN循环的次数更多，也就意味着有更高的概率在 SPIN阶段获得 latch，而代价是SPIN消耗更高的 CPU时间片。相反若降低SPIN_COUNT，则意味着SPIN阶段获得latch的概率降低， SPIN消耗相对少的CPU。

在中古的硬件中可能有仅有1个CPU的系统，虽然现在很少见了，但是显然在仅有一个CPU的情况下SPIN是无意义的，因为如果你把唯一的一个CPU用来SPIN了，显然真正持有对应latch的那个进程获取不到CPU，获取不到CPU的结果是它无法释放这个latch。在这种环境里代码自动把spin_count调整为1。

SPIN 与Latch Busy

9i之前的 spin与latch busy 运作伪代码可以点击这里（main for 8i)。

从9.0.2开始oracle 开始大量启用 post/wait和latch class机制，我们来描述一下伪代码

SLEEPs                  //睡眠次数计数
yields                  //yield 计数  copyright askmac.cn
on_wait_list = FALSE;

while (如果未获得latch)
{
  在对应的latch上SPIN ，循环次数为SPIN_COUNT，SPIN_COUNT 来源一般为 _latch_class_X
    if (获得latch)
	   break; 

  if(yields < YIELD_COUNT)                     // YIELD_COUNT来源为latch_class_X 
  {
    yields++;
	yield CPU ;                               
  }

   else

   {
     yield =0;

	 if (如果latch是post/wait机制的)
	  {
	    on_wait_list=TRUE ; 
		get wait list latch ;                  //获得wait list latch
		add current process to wait list;      //将被进程加入到wait list的尾部
        free wait list latch;                  //释放wait list latch
        wait to be posted;                     //等待被post
	  }
	 else 
	  {
	   wait for SLEEP_TIMES[sleeps] microseconds;   //等待SLEEP_TIME[sleeps]对应的时间 来源为latch_class_X 
	   if ( sleeps	 < SLEEP_BUCKETS)               //SLEEP_BUCKETS 一般为4
	   sleeps++;
	 }
 }
 }

//如果某一刻获得了一个post/wait latch，且本进程在wait list上，则需要从wait list 上把自己移走：

if( 如果我在wait list上)
{
get wait list latch ;                       //获得wait list latch
remove current process from wait list;      //从wait list 上把自己移走
free wait list latch;                       //释放wait list latch
}

从9i开始绝大多数 latch都是 post/wait class的，出去少量非post/wait class的latch和PMON进程外，进程都会进入非时控的sleep (sleep[1]..[sleep[i] i到4以后不再增加) 不会自己醒来，仅在该latch的持有者释放该latch 且等待的进程在wait list的头部的情况下被post唤醒 (awake)。 Oracle 选择这种非时控的sleep的原因为了避免在miss后引起反复的上下文交换context switch 以便改善性能。

但是这种实现也存在一种风险，即需要应对那些持有latch进程意外终止和存在丢失 post的bug的情况。

Filed Under: Oracle, Oracle Internal Research内部原理研究

Script:诊断解析等待和高version count

2013/07/30 by admin Leave a Comment

Script:诊断解析等待和高version count

select * from 
   (select sql_id, count(child_number) 
      from v$sql_shared_cursor 
     group by sql_id
     order by count(child_number) desc)
where rownum <=5;

-- Script Code
set serveroutput on 

DECLARE
  v_count number;
  v_sql varchar2(500);
  v_sql_id varchar2(30) := '&sql_id';
BEGIN
  v_sql_id := lower(v_sql_id);
  dbms_output.put_line(chr(13)||chr(10));
  dbms_output.put_line('sql_id: '||v_sql_id);
  dbms_output.put_line('------------------------');
  FOR c1 in 
    (select column_name  
       from dba_tab_columns 
      where table_name ='V_$SQL_SHARED_CURSOR' 
        and column_name not in ('SQL_ID', 'ADDRESS', 'CHILD_ADDRESS', 'CHILD_NUMBER', 'REASON')
      order by column_id)
  LOOP
    v_sql := 'select count(*) from V_$SQL_SHARED_CURSOR 
              where sql_id='||''''||v_sql_id||''''||' 
              and '||c1.column_name||'='||''''||'Y'||'''';
    execute immediate v_sql into v_count;
    IF v_count > 0 
    THEN 
      dbms_output.put_line(' - '||rpad(c1.column_name,30)||' count: '||v_count);
    END IF;
  END LOOP;
END;
/

oradebug setmypid
oradebug unlimit;
alter session set events 'immediate trace name systemstate level 266';
 alter session set events 'immediate trace name library_cache level 11';
 alter session set events 'immediate trace name cursordump level 16'; 
oradebug tracefile_name;

SELECT b.*
FROM v$sqlarea a ,
  TABLE(version_rpt(a.sql_id)) b
WHERE loaded_versions >=100;


SELECT b.*
FROM v$sqlarea a ,
  TABLE(version_rpt(NULL,a.hash_value)) b
WHERE loaded_versions>=100;

version_rpt3_22.sql

Filed Under: Oracle, Oracle Internal Research内部原理研究

用三种方法证明DROP USER(有Table)会触发Object级Checkpoint

2013/07/15 by admin Leave a Comment

预备知识：

drop user 能引发checkpoint的前提是 USER下面有TABLE，因为DROP USER 等若隐含了不可flashback drop的DROP TABLE。
如果user下无任何表，则此讨论不成立

多种的checkpoint中， drop table 触发的是OBJECT CHECKPOINT

其行为为写出所有节点上属于某个对象 object 的所有脏dirty buffer到磁盘

可能由以下操作触发：
drop table xx;
drop table xx purge;
truncate table xx;

【Maclean Liu技术分享】深入理解Oracle中 Mutex的内部原理

2013/04/14 by admin Leave a Comment

【Maclean Liu技术分享】深入理解Oracle中 Mutex的内部原理

本文适合对Oracle Mutex/latch有兴趣了解其深入内部原理的同学

下载地址：

【Maclean Liu技术分享】深入理解Oracle中Mutex的内部原理

Filed Under: Oracle, Oracle Internal Research内部原理研究 Tagged With: mutex

深入理解Oracle中的Mutex

2013/04/13 by admin 10 Comments

了解 Oracle Mutex

虽然Mutex中文翻译为互斥锁，但为了和OS mutex充分的区别，所以我们在本文里称Oracle Mutex为Mutex。

Oracle中的mutex，类似于Latch，是一种低级的串行机制，用以控制对SGA中部分共享数据结构的访问控制。 Oracle中的串行机制有不少，引入它们的目的是避免一个对象出现下述现象：

当某些进程在访问该对象时，该资源被重新分配
当某些进程在修改它时，被其他进程读取
当某些进程在修改它时，被其他进程修改
当某些进程在读取它时，被其他进程修改

不同于Latch，Mutex的使用更灵活，用途更多，例如:

哪些需要被mutex保护的共享数据结构可以有自己独立的mutex，即一个对象拥有自己独立的mutex，不像Latch往往一个需要保护大量对象，举例来说，每一个父游标有其对应的mutex，而每一个子游标也有其对应的mutex
每一个数据结构可能有一个或多个mutex保护，每一个mutex负责保护其结构的不同部分
当然一个mutex也可以用来保护多于一个的数据结构

理论上mutex即可以存放在其保护的结构本身中(其实是嵌入在结构里)，也可以存放在其他地方。一般情况下Mutex是在数据结构需要被保护时动态创建出来的。如是嵌在需要保护结构体内的mutex，则当所依附的数据结构被清理时该mutex也将被摧毁。

Mutex带来的好处

虽然mutex和latch都是Oracle中的串行机制，但是mutex具有一些latch没有的好处

更轻量级且更快

Mutex作为Latch的替代品，具有更快速获得，更小等优势。获取一个mutex进需要大约30~35个指令，而Latch则需要150~200个指令。一个mutex结构的大小大约为16 bytes，而在10.2版本中一个latch需要112个bytes，在更早的版本中是200个bytes。从200个bytes 精简到112个是通过减少不必要的统计指标 SLEEP1~SLEEP11、WAITERS_WOKEN, WAITS_HOLDING_LATCH等从而实现的。今后我们将看到更多关于Latch的代码优化。

减少伪争用

典型情况下一个Latch保护多个对象。当一个Latch保护多个热对象时，并行地对这些对象的频繁访问让latch本身变成性能的串行点。这也就是我们此处说的伪争用点，因为争用是发生在这个串行保护的机制上，而不是进程去访问的对象本身。与latch不同，使用mutex的情况下Oracle开发人员可以为每一个要保护的数据结构创建一个独立的mutex。这意味着Latch的那种伪争用将大大减少，因为每一个对象均被自己独立拥有的mutex保护

Mutex在一些地方替代了latch和PIN

一个Mutex可供多个Oracle进程并行地参考，反过来说进程们可以以S(Shared 共享) mode模式参考一个Mutex。以S mode一起共享参考这个mutex的进程的总数成为参考总数reference count。Mutex自身结构中存放了这个ref count的数据。另一方面，mutex也可以被以X (Exclusive)mode排他模式被仅有一个进程所持有Held。

Mutex有2种用途，一方面他们可以充当维护必要串行机制的结构，如同latch那样；同时也可以充当pin，避免对象被age out。

举例来说，mutex结构中包含的ref count信息可以用作替代library cache pin。在mutex充当cursor pin之前，当一个进程要执行=>pin一个cursor时需要做的是针对性地创建library cache pin和删除这个library cache pin(均为S mode)。mutex充当cursor pin之后，进程只需要增加和减少mutex上的ref count即可。

当某一个进程首次解析一个游标 Cursor，他将临时创建并移除一个library cache pin，但是该进程后续的解析或执行进要求增加或者减少ref count。注意在这个增加/减少ref count的过程中无需acquire latch，这是因为mutex自身能起到限制串行访问修改ref count的作用。当一个进程要移除自己的mutex pin时，它减少ref count，同样的无需acquire 任何latch。

Mutex和Latch的交互

Latches和Mutex 是独立的串行机制，举例来说一个进程可以同时持有latch和mutex。在进程异常dead的情况下，一般latch要比Mutex更早被PMON清理。一般情况下不存在mutex的死锁。不像latch，在早期版本例如9i之前我们经常遇到latch死锁的问题。

Mutex的用途

在版本10.2中仅仅有 KKS 这个内核层是mutex的客户，KKS 意为 Kernel Kompile Shared，它是Library Cache中的shared cursor游标共享部分层次的代码。在之后的版本中，ORACLE开发部门更多地使用了Mutex，不局限于KKS。

KKS游标共享如何使用Mutex

kks 使用mutex以便保护对于下述基于parent cursor父游标和子游标child cursor的一系列操作。

对于父游标parent cursor的操作：

基于发生的不同操作，对应不同的等待事件：
- 在某个父游标名下创建一个新的游标 ==> cursor:mutex X
- 检查一个父游标 ==> cursor:mutex S
- 绑定值捕获 ==> cursor:mutex X
保护父游标的mutex嵌入在父游标结构内
针对父游标parent cursor的Mutex类型为’Cursor Parent’ (kgx_kks2).
针对父游标parent cursor的Mutex等待事件均为’ Cursor: mutex *’的形式

针对游标统计信息的操作

基于对不同的游标统计信息的操作有不同的等待事件：
- 构造，更新游标相关的统计信息 ==> cursor:mutex X
- 检测游标相关的统计信息，例如访问V$SQLSTATS ==> cursor : mutex S
相关的游标可能在父游标中，也可能在游标统计信息相关的hash table上
针对游标统计信息的Mutex类型为Cursor Stat (kgx_kks1)
针对游标统计信息的Mutex等待事件均为’ Cursor: mutex *’的形式

Mutex是如何替代library cache pin来保护cursor heap的？

传统的’library cache pin’在10.2.0.2之后默认被取代，此处PIN被Mutex及其ref count取代。当进程执行游标语句时或者需要PIN，或者需要hard parse一个子游标heap。
在版本10.2.0.1中，使用mutex部分代码替代PIN的功能默认是不激活的，实际上这取决于隐藏参数_KKS_USE_MUTEX_PIN，在10.2.0.2之后_KKS_USE_MUTEX_PIN默认为TRUE。换而言之在版本10.2中我们还是可以关闭KKS使用MUTEX替代PIN保护CURSOR的，但是在版本11g中则几乎无法关闭MUTEX。注意10.2中仅当KKS真正使用MUTEX时，library cache pin不再用作cursor pin。
基于对不同的游标统计信息的操作有不同的等待事件：
- 为执行某个SQL而PIN一个游标Cursor ==>Cursor: Pin S Wait on X
- 当执行一个游标而PIN Cursor，而该Cursor正被其他进程以S mode检测 ==> cursor:pin S
当试图重建一个游标Cursor ==> Cursor: pin X 该等待事件一般不太会看到，因为当一个游标正被执行，且其需要重建时会有另一个游标被创建
保护游标的mutex嵌入在游标结构内
Mutex类型为’Cursor Pin’ (kgx_kks3)
等待事件均为 ‘cursor: pin *’的形式

KKS使用MUTEX情况下SQL语句的解析与执行的收益

在版本10.2中，以下是几个SQL解析与执行从MUTEX哪里获得主要收益：

在某个父游标下构建一个新的子游标
- 首先这种构建新子游标的操作更廉价了，当时Maclean仍要告诫你一个父游标下过多的子游标仍不是一件好事情
对父游标的检测
- 在找到一个合适的游标并执行前，父游标需要被适当检测。对父游标的这种检测目前也使用mutex来保护了，所以这种检测更的成本更低了
对于已经加载在Library Cache 中的SQL语句重复执行
- 常规情况下，当一个进程要执行SQL游标前总是必须要先pin它
- 不使用MUTEX的情况：若游标处于OPEN状态下以便今后的重复执行，且参数cursor_space_for_time(CSFT 目前已不推荐使用该参数)为TRUE，则每一次重复执行可以不需要library cache pin。若游标处于OPEN状态下但是cursor_space_for_time=false，则进程在重复执行SQL游标前总是要先拿library cache pin
- 使用MUTEX的情况: 相反，若使用mutex来替代library cache pin时，则无需关心cursor_space_for_time 。仅第一个进程需要做一个PIN，其他后续进程都只需要简单地在对应保护cursor heap的mutex上拿一个共享reference 。

查询SQL统计信息

通过V$SQLSTAT视图(本质上是X$KKSSQLSTAT)访问SQL统计信息时，其所需要的CPu和获取的Latch数量要远远少于访问其他V$SQL视图。在早期版本中, 并行地访问V$SQL或者V$SQLAREA视图会造成 library cache latch的争用。

Mutex 的统计信息

下面是一个AWR中的Mutex Sleep Statistics，这些数据主要来源于V$MUTEX_SLEEP视图。

Mutex Sleep Summary

ordered by number of sleeps desc

Mutex Type	Location	Sleeps
Library Cache	kglhdgh1 64	2,356
Library Cache	kglpnal2 91	2,345
Cursor Pin	kkslce [KKSCHLPIN2]	2,084
Library Cache	kglpin1 4	956
Library Cache	kglhdgn2 106	784
Library Cache	kglpndl1 95	691
Library Cache	kglpnal1 90	605
Library Cache	kgllkdl1 85	580
Library Cache	kgllkal1 80	404
Library Cache	kglllal3 111	282
Library Cache	kglllal1 109	218
Library Cache	kglhdgn1 62	163
Library Cache	kgllldl2 112	156
Library Cache	kgllkc1 57	105
Library Cache	kglget2 2	100
Library Cache	kglini1 32	53
Library Cache	kglget1 1	31
Cursor Pin	kksLockDelete [KKSCHLPIN6]	22
Library Cache	kgllkal3 82	18
Library Cache	kglUnsetHandleReference 120	10
Cursor Pin	kksxsccmp [KKSCHLPIN5]	10
Library Cache	kglobld1 75	8
Cursor Pin	kksfbc [KKSCHLPIN1]	8
Library Cache	kglUpgradeLock 119	7
Library Cache	kglhdgc1 102	2
Cursor Pin	kksfbc [KKSCHLFSP2]	2
Library Cache	kgldtin1 42	1
Library Cache	kglhbh1 63	1
Library Cache	kgllkal5 84	1
Library Cache	kglrdtin1 44	1
Cursor Parent	kkscsPruneChild [KKSPRTLOC35]	1

Mutex的类型Mutex Type

Mutex的类型其实就是 mutex对应的客户的名字，在版本10.2中基本只有KKS使用Mutex，所以仅有3种:

Cursor Stat (kgx_kks1)
Cursor Parent (kgx_kks2)
Cursor Pin (kgx_kks3)

在版本11g中扩展了对Mutex的使用，在Library Cache的HASH BUCKET中嵌入了mutex以保护hash bucket，所以多了一种mutex type : Library Cache

哪些代码函数会申请Mutex?

Oracle中哪些代码函数会申请Mutex? 例如KKSFBC等，其实很像 V$LATCH_MISSES 的location列

10.2中最常见的下面的几个函数

kkspsc0 -负责解析游标 – 检测我们正在解析的游标是否有对象的parent cursor heap 0存在

kksfbc – 负责找到合适的子游标或者创建一个新的子游标

kksFindCursorstat

11g开始有大量函数需要用到Mutex了

SQL> select location from X$MUTEX_SLEEP_HISTORY;

LOCATION
—————————————-
kkslce [KKSCHLPIN2]
kksfbc [KKSCHLFSP2]
kglhdgn2 106
kglpin1 4
kglhdgn2 106
kglllal1 109
kglpin1 4
kglpndl1 95
kglpin1 4
kglpin1 4
kksfbc [KKSCHLFSP2]
kglhdgn1 62
kglpnal1 90
kglllal3 111
kglpnal1 90
kglpnal1 90
kglget2 2
kglllal3 111
kglget2 2
kglobld1 75
kkslce [KKSCHLPIN2]
kglpndl1 95
kglpndl1 95
kglpin1 4
kkslce [KKSCHLPIN2]
kglpin1 4
kglget2 2
kglllal1 109
kgllkc1 57
kglget2 2
kglpnal1 90
kglpin1 4
kglpin1 4
kglpin1 4
kgllkdl1 85
kglllal3 111
kgllldl2 112
kglpin1 4
kglpndl1 95
kkslce [KKSCHLPIN2]
kksLockDelete [KKSCHLPIN6]
kglpndl1 95
kkslce [KKSCHLPIN2]
kglpnal1 90
kglpin1 4
kglpin1 4
kgllldl2 112
kgllkdl1 85
kglpin1 4
kglhdgn2 106
kglhdgn2 106
kksLockDelete [KKSCHLPIN6]
kglhdgn1 62

Mutex的Get和Sleep

当一个Mutex被申请时，一般称为一个get request。若初始的申请未能得到授权，则该进程会因为此次申请而进入到255次SPIN中(_mutex_spin_count Mutex spin count)，每次SPIN循环迭代过程中该进程都会去看看Mutex被释放了吗。

若该Mutex在SPIN之后仍未被释放，则该进程针对申请的mutex进入对应的mutex wait等待事件中。实际进程的等待事件和等待方式由mutex的类型锁决定，例如 Cursor pin、Cursor Parent。举例来说，这种等待可能是阻塞等待，也可以是sleep。

但是请注意在V$MUTEX_SLEEP_*视图上的sleep列意味着等待的次数。相关代码函数在开始进入等待时自加这个sleep字段。

等待计时从进程进入等待前开始计算等待时间，当一个进程结束其等待，则等待的时间加入都总和total中。该进程再次尝试申请之前的Mutex，若该Mutex仍不可用，则它再次进入spin/wait的循环。

V$MUTEX_SLEEP_HISTORY视图的GETS列仅在成功申请到一个Mutex时才增加。

短期持有一个mutex: spin 循环255次一般可以有效以S mode获得一个mutex, 前提是该Mutex 已经被以S mode持有。简单来说若有2个进程同时以S mode去申请一个Mutex，则稍晚的一个申请者需要进入SPIN并等稍早一点的申请者完成它的例如创建针对该mutex的一个reference的操作，但这都是非常迅速的操作。

长期持有一个Mutex: 如若一个Mutex已经被某进程以X mode持有，则往往有其进程以SHRD模式去申请该mutex时仍发现该mutex 以X mode被其他进程所持有，则往往这个EXCL 持有是 LONG_EXCL(可以通过SSD DUMP发现)，则后续的申请者往往要进入spin循环，甚至需要等待

上面我讲了willing-to-wait的mutex，实际上mutex 的申请也可以是 nowait的。进程以nowait申请mutex时不会进入spin-cycle也不sleep，它只继续常规处理。当一个nowait get失败时，将增加一次miss，但是实际上V$MUTEX_SLEEP_*中记录的miss不是这样的miss，视图中记录的miss是等待的次数，对于真正的miss没有统计项。

Wait Time等待时间

类似于latch，spin time 不算做mutex的消耗时间，它只包含等待消耗的时间。

真正理解Mutex相关的等待

Mutex数据结构中存放了Holder id持有者ID ， Ref Count，和其他Mutex相关的统计信息。 Holder id对应于持有该Mutex的session id (v$session.sid) 。特别注意， Ref Count是进程并发以S mode参考该Mutex的进程数量(如下文的演示)。

当一个Mutex被以X mode 持有，则Holder id 为对应持有该mutex的session id，而Ref Count为0。

每一个共享S mode持有者仅仅增加mutex上的Ref Count。可供大量session并发以S mode持有参考一个Mutex。但是注意更新ref count的操作是串行的，这是为了避免错漏并维护mutex中正确的ref count。

下面我们详细介绍一个执行游标过程中对mutex share pin的过程：

某进程以SHRD 模式申请一个Mutex，并尝试临时修改该Mutex的Holder ID
若该Mutex正被他人更新，则该session会将Holder id设置为本session的sid，之后该进程将增加ref count，之后再清楚mutex上的Holder id。简单来说这个Holder id是真正做了并行控制的功能。若该Holder id 被设置了，则说明该Mutex要么被以EXCL模式持有，要么正有一个其他进程在以S mode申请该Mutex的过程中(例如更新Ref Count)。当更新Ref Count时临时设置holder id的目的就是为了实现避免其他进程并发更新该Mutex的机制。通过这些例子说明了 , Mutex既可以用作Latch并发控制，也可用作pin。
若Holder id已被设置，则申请进程将可能进入等待事件。例如若当前Mutex的持有者进程正以X mode更新该Mutex，则申请者的等待事件应为”cursor: pin S on X” 。而若当持有者Holder并不是”真的要持有” 该Mutex，而仅仅是尝试更新其Ref Count,则第二个进程将等在’ Cursor :pin S’等待事件上；实际正在更新Ref count的操作时很快的，是一种轻微的操作。当第一个进程正在更新mutex，则后续的申请进程将进入spin 循环中255次等待前者结束。当mutex上不再有 Holder id时(如前者的进程已经更新完Ref Count)时，则申请者进程将Holder ID设为自身的SID，并更新Ref Count，并清除Holder id。若在255次循环SPIN后mutex仍不被释放，则该进程进入等待并不再跑在CPU上。

Mutex相关的等待事件

cursor: mutex * events等待事件

cursor: mutex * events等待事件用于Cursor Parent 和 Cursor stats类型的操作：
- ‘cursor: mutex X’ ，某个进程申请以EXCL mode持有mutex时进入该等待，该Mutex要么正被其他进程以SHRD模式参考，这导致X mode的申请必须要等待直到Ref count=0，或者该mutex正被另一个进程以X mode持有。
- 相关操作要求以EXCL X mode持有Mutex的：
  - 在一个父游标下创建一个新的子游标
  - 捕获SQL中的绑定变量
  - 更新或构件SQL统计信息V$SQLSTATS
‘Cursor: Mutex S’ ，某个进程以SHRD S mode申请一个Mutex，而该Mutex要么被其他进程已EXCL X mode所持有，要么其他进程正在更新mutex 上的Ref Count。
- 相关类型的操作一般是检测父游标或者CURSOR统计信息数据，此外查询V$SQLSTATS也会造成CURSOR statistics被查询

‘cursor: pin * events’等待事件

该类等待事件一般是为了pin相关的子游标

cursor: pin S 当一个进程以共享pin模式申请一个Mutex，而不能立即获得时，进入cursor: Pin S等待事件。 Mutex Pin是以共享类型的操作，例如执行一个游标。
- 当一个进程等在cursor: pin S上，说明该进程在对一个共享的mutex pin 参考或取消参考时，有其他的进程也正在为同样的cursor heap创建或者取消一个共享Mutex pin。实际上cursor: pin S 等待事件应当很少见，因为更新共享Mutex pin 的reference 应当是很快的。再重复一次，S mode的Mutex可以被并发持有，但是更新Mutex的Ref Count仍需要串行地处理。一旦reference count被增加好，则后续进程将可以为同样的cursor heap增加reference count。因此此处mutex 即可以扮演Latch的角色(串行控制ref count的更新)，又可以扮演pin的角色(ref count本身)。
‘cursor: pin X’ 当一个进程需要以EXCL X mode获得mutex时，这类需要EXCL X 模式的串行操作包括:
- 构建一个子游标
- 某个进程已经以X mode持有该Mutex
- 一个或多个进程正在reference 该Mutex (shared mutex pin)
‘Cursor: pin S on X’ 最常见的等待事件，进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex，但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。

Mutex的相关统计视图

V$MUTEX_SLEEP

shows the wait time, and the number of sleeps for each combination of mutex type and location.

Column	Datatype	Description
`MUTEX_TYPE`	`VARCHAR2(32)`	Type of action/object the mutex protects
`LOCATION`	`VARCHAR2(40)`	The code location where the waiter slept for the mutex
`SLEEPS`	`NUMBER`	Number of sleeps for this `MUTEX_TYPE` and `LOCATION`
`WAIT_TIME`	`NUMBER`	Wait time in microseconds

V$MUTEX_SLEEP_HISTORY

displays time-series data. Each row in this view is for a specific time, mutex type, location, requesting session and blocking session combination. That is, it shows data related to a specific session (requesting session) that slept while requesting a specific mutex type and location, because it was being held by a specific blocking session. The data in this view is contained within a circular buffer, with the most recent sleeps shown.

Column	Datatype	Description
`SLEEP_TIMESTAMP`	`TIMESTAMP(6)`	The last date/time this `MUTEX_TYPE` and `LOCATION` was slept for by the`REQUESTING_SESSION`, while being held by the `BLOCKING_SESSION`.
`MUTEX_TYPE`	`VARCHAR2(32)`	Type of action/object the mutex protects
`GETS`	`NUMBER`	The number of times the mutex/location was requested by the requesting session while being held by the blocking session. `GETS` is only incremented once per request, irrespective of the number of sleeps required to obtain the mutex.
`SLEEPS`	`NUMBER`	The number of times the requestor had to sleep before obtaining the mutex
`REQUESTING_SESSION`	`NUMBER`	The SID of a session requesting the mutex
`BLOCKING_SESSION`	`NUMBER`	The SID of a session holding the mutex
`LOCATION`	`VARCHAR2(40)`	The code location where the waiter slept for the mutex
`MUTEX_VALUE`	`RAW(4)`	If the mutex is held in exclusive (X) mode, this column shows the SID of the blocking session, else it shows the number of sessions referencing the mutex in S mode.
`P1`	`NUMBER`	Internal use only
`P1RAW`	`RAW(4)`	Internal use only
`P2`	`NUMBER`	Internal use only
`P3`	`NUMBER`	Internal use only
`P4`	`NUMBER`	Internal use only
`P5`	`VARCHAR2(64)`	Internal use only

接着我们会在环境中模拟cursor pin S wait on X的场景，并通过systemstate dump和v$mutex_sleep , v$mutex_sleep_history等视图观察这一现象

session A:
SQL> select * from v$version;

BANNER
—————————————————————-
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bi
PL/SQL Release 10.2.0.5.0 – Production
CORE 10.2.0.5.0 Production
TNS for Linux: Version 10.2.0.5.0 – Production
NLSRTL Version 10.2.0.5.0 – Production
www.askmac.cn

SQL> show parameter kks
SQL>
SQL> create table mac_kks tablespace users nologging as select * from dba_objects;

Table created.