[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. php设计模式2

    代理模式 <?php /** * 代理模式:为其他对象提供一个代理以控制这个对象的访问 它是给某一个对象提供一个替代者,使之在client对象和subject对象之间编码更有效率. 代理可以提供 ...

  2. vue+cordova构建跨平台应用集成并使用Cordova plugin

    安装 //安装 vue-cil npm install --global vue-cli //安装cordova npm i cordova -g cordova 新建项目 //新建cordova 项 ...

  3. 说一说MVC的MenuCard(五)

    1.数据库设计 create database BookShop go use bookshop go --模块表 create table Module ( ModuleID ,), ModuleN ...

  4. 从锅炉工到AI专家(7)

    说说计划 不知不觉写到了第七篇,理一下思路: 学会基本的概念,了解什么是什么不是,当前的位置在哪,要去哪.这是第一篇希望做到的.同时第一篇和第二篇的开始部分,非常谨慎的考虑了非IT专业的读者.希望借此 ...

  5. Presto 常用配置及操作

    一.介绍 Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节. Presto的设计和编写完全是为了解决像Facebook这样规模的商业数据仓库的交互式分析和处 ...

  6. 你真的会PHP吗？

    Note: 1) PHP中的数据类型 PHP一共支持八种数据类型, 4种标量类型,boolean(布尔型),integer(整形),float/double(浮点型)和string(字符串类型), 2 ...

  7. selenium和webdriver区别

    接触selenium大概半年时间了.从开始的预研,简单的写个流程到后期的自动化框架的开发,因为本人不属于代码方面的大牛,一直的边研究边做.逐步深入学习.近期发现自己对本身selenium的发展还存在困 ...

  8. 权限管理系统之项目框架搭建并集成日志、mybatis和分页

    前一篇博客中使用LayUI实现了列表页面和编辑页面的显示交互,但列表页面table渲染的数据是固定数据,本篇博客主要是将固定数据变成数据库数据. 一.项目框架 首先要解决的是项目框架问题,搭建什么样的 ...

  9. 【.NET Core项目实战-统一认证平台】第十一章 授权篇-密码授权模式

    [.NET Core项目实战-统一认证平台]开篇及目录索引 上篇文章介绍了基于Ids4客户端授权的原理及如何实现自定义的客户端授权,并配合网关实现了统一的授权异常返回值和权限配置等相关功能,本篇将介绍 ...

  10. Smobiler 4.4 更新预告 Part 1（Smobiler能让你在Visual Studio上开发APP）

    在4.4版本中,大家对产品优化的一些建议和意见进行了相应的优化和修复,同时,还新增了一些令人激动的功能和插件. 下面先为大家介绍4.4版本中Smobiler的优化和修复: 优化 1, PageView ...