[20190415]关于shared latch(共享栓锁).txt

http://andreynikolaev.wordpress.com/2010/11/17/shared-latch-behaves-like-enqueue/

For the shared latches Oracle 10g uses kslgetsl(laddr, wait, why, where, mode) function. Oracle 11g has kslgetsl_w()
function with the same interface, but internally uses ksl_get_shared_latch(). Like in my previous post, I guess the
meaning of kslgetsl() arguments as:

--//对于共享锁存，Oracle 10g使用kslgetsl(laddr，wait，why，where，mode)函数。Oracle 11g具有相同接口的kslgetsl_w()函数，但
--//在内部使用ksl_get_share_latch()。与上一篇文章一样，我认为kslgetsl()参数的含义是：
--//注:我以前一直以为还是kslgetsl,原来11g已经改为kslgetsl_w,不过内部使用还是ksl_get_shared_latch().

laddress -- address of latch in SGA
    wait     -- flag. If not 0, then willing-to-wait latch get
    where    -- location from where the latch is acquired (x$ksllw.indx)
    why      -- context why the latch is acquired at this where.

And the last one is:

mode – Exclusive or shared mode

the mode argument took only two values:
     8 -- "SHARED"
    16 -- "EXCLUSIVE"

--//我觉得在不理解之前,最好的方法拿别人的例子自己亲自做一遍.慢慢体会与理解.

1.环境:
SYS@book> @ ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SYS@book> @ laddr.sql 'gcs partitioned table hash'
old   1: select addr, name from v$latch where lower(name) like '%'||lower('&&1')||'%'
new   1: select addr, name from v$latch where lower(name) like '%'||lower('gcs partitioned table hash')||'%'
ADDR             NAME
---------------- ----------------------------------------
0000000060018A18 gcs partitioned table hash

old   1: select addr, name from v$latch_parent where lower(name) like '%'||lower('&&1')||'%'
new   1: select addr, name from v$latch_parent where lower(name) like '%'||lower('gcs partitioned table hash')||'%'
ADDR             NAME
---------------- ----------------------------------------
0000000060018A18 gcs partitioned table hash

old   1: select addr, name from v$latch_children where lower(name) like '%'||lower('&&1')||'%'
new   1: select addr, name from v$latch_children where lower(name) like '%'||lower('gcs partitioned table hash')||'%'
no rows selected

--//ADDR='0000000060018A18'.作者拿"gcs partitioned table hash" latah测试有一定道理,这个latch不用在单实例的情况下.

--//测试脚本.我在原作者的脚本上做了一些修改:
$ cat shared_latch.txt
--//connect / as sysdba
col laddr new_value laddr
col vmode  new_value vmode
select decode(lower('&&1'),'s',8,'x',16) vmode from dual ;
SELECT addr laddr FROM v$latch_parent WHERE NAME='gcs partitioned table hash';
oradebug setmypid
oradebug call kslgetsl_w 0x&laddr 1 4 5  &mode
host sleep &&2
oradebug call kslfre 0x&laddr
--//exit

--//说明:参数1 s,x 表示SHARED,EXCLUSIVE.参数2表示sleep的秒数
--//注:不能使用mode,mode是保留字,使用vmode代替.
--//顺便说一下,我不知道作者如何测试,我遇到的问题如果设置共享拴锁,查询v$latch视图会挂在哪里,无法执行.
--//我换成了v$latch_parent视图(源链接使用v$latch视图)

$ cat peek.sh
#! /bib/bash
sqlplus -s -l / as sysdba <<EOF
spool $1
col laddr new_value laddr
SELECT sysdate,addr laddr FROM v\$latch_parent WHERE NAME='gcs partitioned table hash';
oradebug setmypid
$(seq $2|xargs -I{} echo -e 'oradebug peek 0x&laddr 8\nhost sleep 1' )
spool off
EOF
--//peek 长度8(64位),注意intel的大小头问题.
--//latch_free.sql脚本放在最后.比较长.

2.测试1:
--//测试S mode的情况.
--//执行. peek.sh脚本.
$ . peek.sh /tmp/peeks.txt 30
[oracle@gxqyydg4 IP=100.78 ~/hrp430/latch ] $ . peek.sh /tmp/peeks.txt 30

SYSDATE             LADDR
------------------- ----------------
2019-04-15 10:11:00 0000000060018A18

Statement processed.
[060018A18, 060018A1C) = 00000000
[060018A18, 060018A1C) = 00000000
[060018A18, 060018A1C) = 00000001
[060018A18, 060018A1C) = 00000001
[060018A18, 060018A1C) = 00000002
[060018A18, 060018A1C) = 00000002
[060018A18, 060018A1C) = 00000002
[060018A18, 060018A1C) = 00000002
[060018A18, 060018A1C) = 00000002
[060018A18, 060018A1C) = 00000002
[060018A18, 060018A1C) = 00000002
[060018A18, 060018A1C) = 00000002
[060018A18, 060018A1C) = 00000001
[060018A18, 060018A1C) = 00000001
[060018A18, 060018A1C) = 00000000
..
--//注意看peek值的变化.0->1->2-1->0,注这里peek的长度是4.

--//session 1:
SYS@book(295.15 spid=40791 pid=21)>  @shared_latch.txt s 10
     VMODE
----------
         8

LADDR
----------------
0000000060018A18

Statement processed.
Function returned 1

Function returned 0

--//session 2:
--//等几秒执行(我的测试等2秒):
SYS@book(101.9 spid=40540 pid=31)>  @ shared_latch.txt s 10
     VMODE
----------
         8

LADDR
----------------
0000000060018A18
Statement processed.
Function returned 1
Function returned 0

--//session 3:
SYS@book> @ latch_free
Process 21
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=295
Process 31
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=101

--//通过测试,可以发现共享栓锁在以共享模式获取时,不会阻塞,该地址的前4个字节记录的是持有S mode的数量.
--//如果你觉得手工测试比较麻烦,修改如下:

$ cat shared_latch_t.txt
connect / as sysdba
col laddr new_value laddr
col vmode  new_value vmode
select decode(lower('&&1'),'s',8,'x',16) vmode from dual ;
SELECT addr laddr FROM v$latch_parent WHERE NAME='gcs partitioned table hash';
oradebug setmypid
oradebug call kslgetsl_w 0x&laddr 1 4 5  &vmode
host sleep &&2
oradebug call kslfre 0x&laddr
exit

--//建立测试脚本(a.sh)如下:
$ cat a.sh
#! /bin/bash
source peek.sh /tmp/peeks.txt 20 > /dev/null &
seq 20 | xargs -I{} echo -e 'sqlplus -s -l / as sysdba <<< @latch_free\nsleep 1'  | bash >| /tmp/latch_free.txt &
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
wait

--//测试结果如下:
$ grep  -v '^$' /tmp/peeks.txt | uniq -c
      1 SYSDATE             LADDR
      1 ------------------- ----------------
      1 2019-04-15 11:32:44 0000000060018A18
      1 Statement processed.
      2 [060018A18, 060018A20) = 00000001 00000000
      2 [060018A18, 060018A20) = 00000002 00000000
      2 [060018A18, 060018A20) = 00000003 00000000
      2 [060018A18, 060018A20) = 00000002 00000000
      2 [060018A18, 060018A20) = 00000001 00000000
--//没有阻塞,10秒之内都获取latch.
     10 [060018A18, 060018A20) = 00000000 00000000
--//第1列表示该行出现的次数(我每秒取样1次).

$ cat /tmp/latch_free.txt
2019-04-15 11:32:44
2019-04-15 11:32:45
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:32:46
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142
Process 35
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=156

2019-04-15 11:32:47
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142
Process 35
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=156

2019-04-15 11:32:48
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142
Process 35
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=156
Process 36
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=170

2019-04-15 11:32:49
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142
Process 35
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=156
Process 36
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=170

2019-04-15 11:32:50
Process 35
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=156
Process 36
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=170

2019-04-15 11:32:51
Process 35
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=156
Process 36
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=170

2019-04-15 11:32:52
Process 36
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=170

2019-04-15 11:32:53
Process 36
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=170

2019-04-15 11:32:54
2019-04-15 11:32:56
--//结果不说明了,与上面的测试一样,仅仅多了1个会话.最重要一点S mode下不会出现阻塞的情况.

3.测试2:
--//测试X mode的情况.
 $ cat b.sh
#! /bin/bash
source peek.sh /tmp/peeks.txt 30 > /dev/null &
seq 30 | xargs -I{} echo -e 'sqlplus -s -l / as sysdba <<< @latch_free\nsleep 1'  | bash >| /tmp/latch_free.txt &
sqlplus /nolog @ shared_latch_t.txt x 5 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt s 5 > /dev/null &
#sleep 2
sqlplus /nolog @ shared_latch_t.txt s 5 > /dev/null &
wait
--//注:我注解sleep 2,大家根据需要调整时间间隔.
$ grep  -v '^$' /tmp/peeks.txt | uniq -c
      1 SYSDATE             LADDR
      1 ------------------- ----------------
      1 2019-04-15 11:35:44 0000000060018A18
      1 Statement processed.
      5 [060018A18, 060018A20) = 00000020 20000000
     10 [060018A18, 060018A20) = 00000001 00000000
     15 [060018A18, 060018A20) = 00000000 00000000
--//注意前面第1列是该行出现的次数(我每秒取样1次).也就是5秒是0x00000020(PID=32,前4位),10秒是00000001.
--//注意前5秒的peek的记录.后4位0x20000000,也就是X mode peek记录是前4位是PID,后4位是0x20000000.

$ cat /tmp/latch_free.txt
2019-04-15 11:35:44
2019-04-15 11:35:45
Process 32
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=114

2019-04-15 11:35:47
Process 32
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=114
  Process 33, waiting for: 0000000060018A18 whr=5 why=4
  Process 34, waiting for: 0000000060018A18 whr=5 why=4
--//X mode获取阻塞了2个会话的共享拴锁.

2019-04-15 11:35:48
Process 32
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=114
  Process 33, waiting for: 0000000060018A18 whr=5 why=4
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:35:49
Process 32
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=114
  Process 33, waiting for: 0000000060018A18 whr=5 why=4
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:35:50
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4
--//如果出现阻塞,会导致顺序的申请共享拴锁串行化处理,阻塞S mode模式.
--//这也是为什么看到10秒是0x00000001的情况.

2019-04-15 11:35:51
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:35:52
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:35:53
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:35:54
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:35:55
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:35:56
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:35:57
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:35:59
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:36:00
2019-04-15 11:36:01

--//可以看出在第1个会话X mode的情况下(peek看到值是0x20=32,对应PID号),阻塞后面2个S mode会话,并且导致后面S mode拴锁串行化,顺序执行.
--//注意S mode后面的peek记录值是S mode的数量(不是PID).

4. 测试3:
--//顺序获取 S模式,X模式,S模式的情况.
$ cat c.sh
#! /bin/bash
source peek.sh /tmp/peeks.txt 20 > /dev/null &
seq 20 | xargs -I{} echo -e 'sqlplus -s -l / as sysdba <<< @latch_free\nsleep 1'  | bash >| /tmp/latch_free.txt &
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt x 6 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
wait

$ grep  -v '^$' /tmp/peeks.txt | uniq -c
      1 SYSDATE             LADDR
      1 ------------------- ----------------
      1 2019-04-15 11:44:02 0000000060018A18
      1 Statement processed.
      2 [060018A18, 060018A20) = 00000001 00000000
      4 [060018A18, 060018A20) = 00000001 40000000
      6 [060018A18, 060018A20) = 00000021 20000000
      6 [060018A18, 060018A20) = 00000001 00000000
      2 [060018A18, 060018A20) = 00000000 00000000
--//注意看peek值变化,开始2秒(S mode)peek值0x00000001 00000000,第2个会话X mode时,前4位是0x00000001(表示持有S mode的数量),后4位是0x40000000,持续时间4秒.
--//也就是S mode 阻塞X 模式,必须等待S mode释放,X mode才能持有.
--//接着第2个会话持有X mode,peek值00000021 20000000,前4位是PID 0x21=33.后4位是20000000,X 模式会阻塞S mode.后面不再说明了.

2019-04-15 11:44:02
2019-04-15 11:44:03
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58

2019-04-15 11:44:04
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58
  Process 33, waiting for: 0000000060018A18 whr=5 why=4
--//S mode 阻塞 X mode.

2019-04-15 11:44:06
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58
  Process 33, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:44:07
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58
  Process 33, waiting for: 0000000060018A18 whr=5 why=4
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:44:08
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58
  Process 33, waiting for: 0000000060018A18 whr=5 why=4
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:44:09
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4
--//X mode 阻塞 S mode.

2019-04-15 11:44:10
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:44:11
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:44:12
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:44:13
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 11:44:14
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:44:15
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:44:16
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:44:18
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:44:19
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:44:20
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 11:44:21
2019-04-15 11:44:22

--//大家可以自行建立脚本测试.比如例子:
$ cat d.sh
#! /bin/bash
source peek.sh /tmp/peeks.txt 30 > /dev/null &
seq 30 | xargs -I{} echo -e 'sqlplus -s -l / as sysdba <<< @latch_free\nsleep 1'  | bash >| /tmp/latch_free.txt &
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt x 6 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
sqlplus /nolog @ shared_latch_t.txt s 6 > /dev/null &
wait

$ grep  -v '^$' /tmp/peeks.txt | uniq -c
      1 SYSDATE             LADDR
      1 ------------------- ----------------
      1 2019-04-15 11:55:59 0000000060018A18
      1 Statement processed.
      2 [060018A18, 060018A20) = 00000002 00000000 <= 2个会话(也许指PID更加合适一些)S mode
      4 [060018A18, 060018A20) = 00000002 40000000 <= X mode获取阻塞,设置后4位0x40000000
      6 [060018A18, 060018A20) = 00000022 20000000 <= X mode获取成功,前4位PID,后4位0x20000000.
     12 [060018A18, 060018A20) = 00000001 00000000 <= X mode释放,导致后续的S mode 串行化,需要12秒
      6 [060018A18, 060018A20) = 00000000 00000000
--//不再说明.仅仅记住一点X mode会导致S mode的获取串行化.

5. 测试4:
--//顺序获取 X模式,X模式,X模式的情况.
$ cat e.sh
#! /bin/bash
source peek.sh /tmp/peeks.txt 20 > /dev/null &
seq 20 | xargs -I{} echo -e 'sqlplus -s -l / as sysdba <<< @latch_free\nsleep 1'  | bash >| /tmp/latch_free.txt &
sqlplus /nolog @ shared_latch_t.txt x 5 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt x 5 > /dev/null &
sleep 2
sqlplus /nolog @ shared_latch_t.txt x 5 > /dev/null &
wait

$ grep  -v '^$' /tmp/peeks.txt | uniq -c
      1 SYSDATE             LADDR
      1 ------------------- ----------------
      1 2019-04-15 12:09:53 0000000060018A18
      1 Statement processed.
      5 [060018A18, 060018A20) = 0000001C 20000000
      5 [060018A18, 060018A20) = 00000021 20000000
      5 [060018A18, 060018A20) = 00000022 20000000
      5 [060018A18, 060018A20) = 00000000 00000000
--//我想不用我解析,大家应该明白.X mode获取成功,前4位PID,后4位0x20000000.
--//X mode是排他的模式,肯定阻塞X mode的获取,可以看到每次都是5秒.

$ cat /tmp/latch_free.txt
2019-04-15 12:09:53
2019-04-15 12:09:54
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58

2019-04-15 12:09:55
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58
  Process 33, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 12:09:56
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58
  Process 33, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 12:09:57
Process 28
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=58
  Process 33, waiting for: 0000000060018A18 whr=5 why=4
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 12:09:58
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 12:09:59
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 12:10:00
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 12:10:01
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 12:10:03
Process 33
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=128
  Process 34, waiting for: 0000000060018A18 whr=5 why=4

2019-04-15 12:10:04
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 12:10:05
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 12:10:06
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 12:10:07
Process 34
 holding: 0000000060018A18  "gcs partitioned table hash" lvl=6 whr=5 why=4, SID=142

2019-04-15 12:10:08
2019-04-15 12:10:09

6.总结:
--//A. S mode 下: peek记录的前4位持有S mode的数量.后4位是0x0. (这里针对的64位的系统)
--//B. S mode 下,如果出现X mode,peek记录的前4位持有S mode的数量.后4位是0x40000000.
--//一旦X mode持有变成 前4位持有会话PID号,后4位0x20000000.
--//C. X mode 持有,会导致顺序的S mode 串行化.从调优角度讲这是最"可怕"的事情.
--//D. 从以上测试可以看出 shared latch优化的重点就是减少X mode出现的频次.
--//E. 大家可以使用我写的脚本重复测试,也修改时间间隔.验证我看到的情况是否正确.
--//最后不小心又写的太长,希望大家能看懂^_^.给一个建议,从测试方法等各个方面,我会认真看注解以及反馈.谢谢!!

7.附件latch_free.sql:
$ cat latch_free.sql
/*
     This file is part of demos for "Contemporary Latch Internals" seminar v.18.09.2010
     Andrey S. Nikolaev (Andrey.Nikolaev@rdtex.ru)
     http://AndreyNikolaev.wordpress.com

This query shows trees of processes currently holding and waiting for latches
     Tree output enumerates these processes and latches as following:
Process <PID1>
 <latch1 holding by PID1>
    <processes waiting for latch1>
       ...
 <latch2 holding by PID1>
    <processes waiting for latch2>
       ...
Process <PID2>
...
*/
set head off
set feedback off
set linesize 120
select sysdate from dual;
select   LPAD(' ', (LEVEL - 1) )
     ||case when latch_holding is null then 'Process '||pid
             else 'holding: '||latch_holding||'  "'||name||'" lvl='||level#||' whr='||whr||' why='||why ||', SID='||sid
       end
     || case when latch_waiting  is not  null then ', waiting for: '||latch_waiting||' whr='||whr||' why='||why
       end latchtree
 from (
/* Latch holders */
select ksuprpid pid,ksuprlat latch_holding, null latch_waiting, to_char(ksuprpid) parent_id, rawtohex(ksuprlat) id,
       ksuprsid sid,ksuprllv level#,ksuprlnm name,ksuprlmd mode_,ksulawhy why,ksulawhr whr  from x$ksuprlat
union all
/* Latch waiters */
select indx pid,null latch_holding, ksllawat latch_waiting,rawtohex(ksllawat) parent_id,to_char(indx) id,
       null,null,null,null,ksllawhy why,ksllawer whr from x$ksupr where ksllawat !='00'
union all
/*  The roots of latch trees: processes holding latch but not waiting for latch */
select pid, null, null, null, to_char(pid),null,null,null,null,null,null from (
select distinct ksuprpid pid  from x$ksuprlat
minus
select indx pid from x$ksupr where ksllawat !='00')
) latch_op
connect by prior id=parent_id
start with parent_id  is null;

--//我修改加入set feedback off,显示时间的语句便于观察.

[20190415]关于shared latch(共享栓锁).txt的更多相关文章

  1. [20190416]完善shared latch测试脚本2.txt

    [20190416]完善shared latch测试脚本2.txt --//昨天测试shared latch,链接:http://blog.itpub.net/267265/viewspace-264 ...

  2. [20190419]shared latch spin count 2.txt

    [20190419]shared latch spin count 2.txt --//上午测试shared latch XX模式的情况,链接:http://blog.itpub.net/267265 ...

  3. [20190416]查看shared latch gets的变化.txt

    [20190416]查看shared latch gets的变化.txt 1.环境:SYS@book> @ ver1PORT_STRING                    VERSION  ...

  4. [20190505]关于latch 一些统计信息.txt

    [20190505]关于latch 一些统计信息.txt --//我在两篇文章,提到一些latch的统计信息.链接如下:http://blog.itpub.net/267265/viewspace-2 ...

  5. [20190319]shared pool latch与library cache latch的简单探究.txt

    [20190319]shared pool latch与library cache latch的简单探究.txt --//昨天看Oracle DBA手记3:数据库性能优化与内部原理解析.pdf 电子书 ...

  6. [20190419]shared latch spin count.txt

    [20190419]shared latch spin count.txt --//昨天测试exclusive latch spin count = 20000(缺省).--//今天测试shared ...

  7. 深入理解shared pool共享池之library cache的library cache lock系列四

    本文了解下等待事件library cache lock,进一步理解library cache,之前的文章请见:  深入理解shared pool共享池之library cache的library ca ...

  8. [20190416]11g下那些latch是Exclusive的.txt

    [20190416]11g下那些latch是Exclusive的.txt --//昨天测试了11g下那些latch是共享的,链接:--//是否反过来剩下的都是Exclusive的.继续测试: 1.环境 ...

  9. 深入理解shared pool共享池之library cache系列二

    背景 继续上文:深入理解shared pool共享池之library cache系列一,学习library cache数据结构,本文主要学习library cache object(lco)的数据结构 ...

随机推荐

  1. Kubernetes因限制内存配置引发的错误

    今天对一个pod进行内存资源调整后, 一直卡在ContainerCreating的状态, 执行describe命令查看该 Pod 详细信息后发现如下 . [root@master-01 ~]# kub ...

  2. Jquery Live方法

    $("button").live("click",function(){ $("p").slideToggle();}); ive() 方法 ...

  3. 『NOIP2018普及组题解』

    标题统计 题目描述 凯凯刚写了一篇美妙的作文,请问这篇作文的标题中有多少个字符? 注意:标题中可能包含大.小写英文字母.数字字符.空格和换行符.统计标题字 符数时,空格和换行符不计算在内. 输入格式 ...

  4. 使用SDL2显示一张图片,SDL2上手贴

    SDL全名Simple DirectMedia Layer,是一个跨平台的底层音频.视频.键盘.鼠标操作库,操作实际通过更底层的OpenGL/Direct3D完成,在保留跨平台的兼容性之外提供了非常高 ...

  5. EF架构~让mysql支持DbFunctions扩展函数

    回到目录 对于在Linq To Entity里使用日期函数需要DbFunctions里的扩展方法,而不能使用.net里的日期函数,因为linq的代码会被翻译成SQL发到数据库端,如你的.net方法对于 ...

  6. 前端笔记之JavaScript（九）定时器&JSON&同步异步/回调函数&函数节流&call/apply

    一.快捷位置和尺寸属性 DOM已经提供给我们计算后的样式,但是还是觉得不方便,因为计算后的样式属性值都是字符串类型. 不能直接参与运算. 所以DOM又提供了一些API:得到的就是number类型的数据 ...

  7. Why DDD and layered architecture

    As a developer, you may think that your job is to write code. However, Software development is not a ...

  8. 函数式编程之-bind函数

    Bind函数 Bind函数在函数式编程中是如此重要,以至于函数式编程语言会为bind函数设计语法糖.另一个角度Bind函数非常难以理解,几乎很少有人能通过简单的描述说明白bind函数的由来及原理. 这 ...

  9. MySQL8.0.12 安装及配置、读写分离，主从复制

    一.安装 1.从网上下载MySQL8.0.12版本,下载地址:https://dev.mysql.com/downloads/mysql/ 2. 下载完成后解压 我解压的路径是:D:\Java\mys ...

  10. SQL优化总结之二

    1.列优先 如图有表A和表B,对其查询时,会有如下语句: select a.*,b.* from a,b where a.id = b.a_id; 注意from 后边的表名, a.如果多表查询是完全无 ...