[20190319]shared pool latch與library cache latch的簡單探究.txt
阿新 • • 發佈：2019-03-19
手記 table 獲取 inux pub free unix put cursor
--//把一些常用命令先執行多次(3次以上避免執行時分析時掛起),比如 @ &r/wait10g,也可以事先多開幾個sys登錄會話.
$ cat wait10g.sql
select p1raw,p2raw,p3raw,p1,p2,p3,sid,serial#,seq#,event,state,wait_time,seconds_in_wait from v$session where wait_class<>‘Idle‘
order by event ;
SELECT addr
,latch#
,child#
,level#
,name
,gets
,sleeps
,immediate_gets
,immediate_misses
,spin_gets
FROM V$LATCH_CHILDREN
WHERE name LIKE ‘library cache‘;
ADDR LATCH# CHILD# LEVEL# NAME GETS SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS
000000007A753430 215 29 5 library cache 1256 0 0 0 1
000000007A7534D0 215 28 5 library cache 741 0 0 0 0
000000007A753570 215 27 5 library cache 1022 0 0 0 0
000000007A753610 215 26 5 library cache 958 0 0 0 0
000000007A7536B0 215 25 5 library cache 1079 0 0 0 0
000000007A753750 215 24 5 library cache 1022 0 0 0 0
000000007A7537F0 215 23 5 library cache 1076 0 0 0 3
000000007A753890 215 22 5 library cache 950 0 0 0 0
000000007A753930 215 21 5 library cache 1028 0 0 0 0
000000007A7539D0 215 20 5 library cache 1223 0 0 0 0
000000007A753A70 215 19 5 library cache 941 0 0 0 0
000000007A753B10 215 18 5 library cache 781 0 0 0 0
000000007A753BB0 215 17 5 library cache 1050 0 0 0 3
000000007A753C50 215 16 5 library cache 1098 0 0 0 0
000000007A753CF0 215 15 5 library cache 1295 0 0 0 1
000000007A753D90 215 14 5 library cache 1431 0 0 0 1
000000007A753E30 215 13 5 library cache 1186 0 1 0 0
000000007A753ED0 215 12 5 library cache 1265 0 0 0 2
000000007A753F70 215 11 5 library cache 942 0 0 0 0
000000007A754010 215 10 5 library cache 1401 0 0 0 6
000000007A7540B0 215 9 5 library cache 1181 0 0 0 0
000000007A754150 215 8 5 library cache 1131 0 0 0 0
000000007A7541F0 215 7 5 library cache 1191 0 0 0 1
000000007A754290 215 6 5 library cache 611 0 0 0 0
000000007A754330 215 5 5 library cache 1189 0 0 0 0
000000007A7543D0 215 4 5 library cache 1165 0 0 0 0
000000007A754470 215 3 5 library cache 861 0 0 0 0
000000007A754510 215 2 5 library cache 1328 0 0 0 1
000000007A7545B0 215 1 5 library cache 1199 1 0 0 0
29 rows selected.
--//29個latch.
--//library cache latch數量與cpu數量有關.選取大於cpu數量的最接近的質數.我當前cpu數量24(實際上2個cpu, 每個Core Count:
--//6,Core Enabled: 6,Thread Count: 12),這樣顯示的24個cpu,我自己還第一次註意這個細節.
--//我簡單驗證修改cpu_count=8,library cache latch的數量是11.修改cpu_count=12,library cache latch的數量是13.大家可以自行驗證.
--//註意必須重啟才生效.
SCOTT@test> show parameter cpu_count
NAME TYPE VALUE
--------- -------- -----
cpu_count integer 24
SELECT addr
,latch#
,child#
,level#
,name
,gets
,sleeps
,immediate_gets
,immediate_misses
,spin_gets
FROM V$LATCH_CHILDREN
WHERE name LIKE ‘shared pool‘
ORDER BY addr;
ADDR LATCH# CHILD# LEVEL# NAME GETS SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS
---------------- ------ ------ ------ ----------- ----- ------ -------------- ---------------- ---------
00000000600E7840 214 1 7 shared pool 43351 0 0 0 849
00000000600E78E0 214 2 7 shared pool 8 0 0 0 0
00000000600E7980 214 3 7 shared pool 8 0 0 0 0
00000000600E7A20 214 4 7 shared pool 8 0 0 0 0
00000000600E7AC0 214 5 7 shared pool 8 0 0 0 0
00000000600E7B60 214 6 7 shared pool 8 0 0 0 0
00000000600E7C00 214 7 7 shared pool 8 0 0 0 0
7 rows selected.
--//註意僅僅一個shared pool latch的gets很大,其它實際上啟動後不會使用.
--//shared pool latch的數量與共享池內存大小,cpu數量有關.實際上取 共享池內存大小/512M(對於11G是這樣,早期版本有一些除256M,128M)
--//以及cpu數量/4的最小值.我設置sga才484M.僅僅1個shared pool latch.
--//另外latch實際上共享池內存的一片區域.你可以註意.相鄰地址相減大小一樣,相當於數組.比如:
--//0x600E7840=1611561024
--//0x600E78E0=1611561184
--//600E7980=1611561344
--//1611561184-1611561024 = 160
--//1611561344-1611561184 = 160
2.測試前準備:
--//打開3個會話窗口,將一些需要執行的sql語句執行多次,避免測試時硬解析時掛起.
--//desc dept.
--//select * from dept ;
--// @ &r/wait10g
--//Select * from dept where deptno=12;
3.測試1:
--//session 1:
SCOTT@test> @ &r/spid
SID SERIAL# PROCESS SERVER SPID PID P_SERIAL# C50
---------- ---------- ------------ --------- ------ ------- ---------- --------------------------------------------------
157 5 13448 DEDICATED 13449 17 3 alter system kill session ‘157,5‘ immediate;
--//session 2:
SYS@test> oradebug setmypid
Statement processed.
SYS@test> oradebug peek 0x00000000600E7840 4
[0600E7840, 0600E7844) = 00000000
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
--//給shared pool加上latch.
--//session 1:(第1次執行)
SCOTT@test> select * from dept where deptno=12;
--//註意seelect小寫與前面不同,主要是執行一次硬解析,同時避開一些遞歸語句.
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- ------------------ ------- --------- ---------------
00000000600E7840 00000000000000D6 00 1611561024 214 0 157 5 114 latch: shared pool WAITING 0 60
00000000600E7840 00000000000000D6 00 1611561024 214 0 162 1 3266 latch: shared pool WAITING 0 66
00000000600E7840 00000000000000D6 00 1611561024 214 0 160 1 44 latch: shared pool WAITING 0 90
00000000600E7840 00000000000000D6 00 1611561024 214 0 159 1 625 latch: shared pool WAITING 0 69
--//session 2:
SYS@test> oradebug dump systemstate 266
Statement processed.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//這樣掛起會話中語句執行成功!!
SYS@test> @ &r/wait10g
no rows selected
--//說明硬解析的sql語句需要獲取shared pool.
4.檢查轉儲文件內容:
PROCESS 17:
----------------------------------------
SO: 0x7ce63c10, type: 2, owner: (nil), flag: INIT/-/-/0x00
(process) Oracle pid=17, calls cur/top: 0x7cfa89b0/0x7cfa89b0, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 0 0 0
last post received-location: No post
last process to post me: none
last post sent: 0 0 33
last post sent-location: ksrpublish
last process posted by me: 7ce604b8 1 22
(latch info) wait_event=0 bits=20
Location from where call was made: kghalo:
waiting for 600e7840 Child shared pool level=7 child#=1
Location from where latch is held: kghupr1: Chunk Header
Context saved from call: 1986860088
state=busy, wlstate=free
waiters [orapid (seconds since: put on list, posted, alive check)]:
12 (197, 1552958147, 2)
13 (176, 1552958147, 2)
10 (173, 1552958147, 5)
17 (167, 1552958147, 167)
waiter count=4
gotten 75402 times wait, failed first 851 sleeps 0
gotten 0 times nowait, failed: 0
on wait list for 600e7840
holding (efd=4) 7a7537f0 Child library cache level=5 child#=23
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Location from where latch is held: kglhdgn: child:: latch
Context saved from call: 6
state=busy, wlstate=free
Process Group: DEFAULT, pseudo proc: 0x7cea6ac8
O/S info: user: oracle, term: pts/3, ospid: 13449
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OSD pid info: Unix process pid: 13449, image: oracle@xxxxdg (TNS V1-V3)
Short stack dump:
--//ospid: 13449,註意看下劃線內容,指示它還持有library cache level=5 child#=23.對於child#=23.也就是第一次硬解析還需要持有
--//library cache latch,是否相同的sql語句每次解析都需要持有library cache latch,而且child#都是一樣的呢?
--//可以推測應該一樣,假設2條相同的sql語句需要硬解析,如果持有library cache latch的child#不一樣,這樣有可能出現2個光標在共
--//享池?所以推測下次執行相同語句使用的library cache latch的child#應該與前一次相同.
5.繼續測試:
--//session 2:
SYS@test> oradebug peek 0x000000007A7537F0 4
[07A7537F0, 07A7537F4) = 00000000
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//給對應library cache 加latch,child#=23.
--//session 1:(第2次執行)
SCOTT@test> select * from dept where deptno=12;
--//再次掛起!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- -------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 157 5 146 latch: library cache WAITING 0 27
--//這就是軟解析,需要持有library cache ltach.P1raw=000000007A7537F0也可以對上.
--//註:另外補充說明一下 第2,3次執行 軟解析也需要1次shared pool latch.
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:(第2次執行)
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//執行成功!!繼續:
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:(第3次執行)
SCOTT@test> select * from dept where deptno=12;
--//再次掛起!
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
6.測試2:
--//當前已經執行select * from dept where deptno=12;3次,如果session_cached_cursors非0的情況下,該光標已經被緩存,也就是相同
--//會話的情況下次執行,就是軟軟解析,不需要在持有library cache ltach.
--//session 3:
SYS@test> select * from v$open_cursor where SID=157;
SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_ID SQL_TEXT
---------------- ---------- --------- ---------------- ---------- ------------- ----------------------------------
000000007CF80200 157 SCOTT 000000007683E920 30432287 2f476y80x0r0z select * from dept where deptno=12
000000007CF80200 157 SCOTT 000000007C9C1D68 3393152264 4gd6b1r53yt88 table_1_ff_14f_0_0_0
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//執行成功!!也就是當光標緩存後,sql語句執行不需要在持有對應的library cache latch,oracle通過這樣的方式(軟解析,軟軟解析)減少latch的使用.
7.測試3:
--//如果打開新的會話窗口,再次執行select * from dept where deptno=12;,對於新會話並沒有緩存該光標,第1次執行應該也是軟解析.
--//通過測試說明問題.
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//首先取消shared pool latch.註意library cache latch還在.child#=23.
--//註:另外補充說明一下 第2,3次執行 軟解析也需要1次shared pool latch.估計這樣不允許這時建立新的子光標.
--//session 4:
SCOTT@test> @ &r/spid
SID SERIAL# PROCESS SERVER SPID PID P_SERIAL# C50
---------- ---------- ------------ --------- ------ ------- ---------- --------------------------------------------------
141 45 13648 DEDICATED 13649 25 3 alter system kill session ‘141,45‘ immediate;
SCOTT@test> select * from dept where deptno=12;
--//再次掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- -------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 141 45 33 latch: library cache WAITING 0 18
--//sid=141,正是新打開的會話sid=141.
--//session 2:取消library cache latch.
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//正常執行!!也就是新打開會話即使其它會話已經緩存光標,第1次執行也是軟解析.
--//如果會話再次執行,應該該光標緩存,就不再需要對應的library cache latch.
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//ok,執行成功!!也就是這次是軟軟解析.
8.測試3:
--//如果會話改變參數,這樣會產生新的子光標,看看這樣的情況會持有那些latch.
--//session 1:
SCOTT@test> show parameter optimizer_index_caching
NAME TYPE VALUE
----------------------- ------- -----
optimizer_index_caching integer 0
SCOTT@test> alter session set optimizer_index_caching=1;
Session altered.
--//修改參數optimizer_index_caching,這樣如果執行select * from dept where deptno=12;會產生新的子光標.
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:(修改參數後第1次執行)
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- -------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 157 5 172 latch: library cache WAITING 0 21
00000000600E7840 00000000000000D6 00 1611561024 214 0 160 1 59 latch: shared pool WAITING 0 48
00000000600E7840 00000000000000D6 00 1611561024 214 0 159 1 799 latch: shared pool WAITING 0 45
--//註意僅僅看sid=157行,還需要library cache latch,因為父光標已經存在.
--//session 2:取消對應library cache latch.
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:檢查發現會話一樣掛起!!
SCOTT@test> select * from dept where deptno=12;
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
00000000600E7840 00000000000000D6 00 1611561024 214 0 157 5 173 latch: shared pool WAITING 0 51
00000000600E7840 00000000000000D6 00 1611561024 214 0 160 1 59 latch: shared pool WAITING 0 192
00000000600E7840 00000000000000D6 00 1611561024 214 0 159 1 799 latch: shared pool WAITING 0 189
--//可以發現現在等待事件變成了latch: shared pool(sid=157).可以發現要因為參數的變化,要生產新的子光標,需要持有shared pool
--//latch 從共享池內存建立子光標.
--//session 2:取消shared pool latch.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//執行成功!!繼續測試:
--//session 2: 再次設置latch.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:(修改參數後第2次執行)
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 157 5 176 latch: library cache WAITING 0 21
--//需要對應library cache latch.
--//session 2: 取消library cache latch.
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
--//還是掛起!!看看等待事件.
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
00000000600E7840 00000000000000D6 00 1611561024 214 0 157 5 177 latch: shared pool WAITING 0 12
--//奇怪還是需要持有shared pool latch.為什麽??
--//session 2: 取消shared pool latch.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//session 1:(修改參數後第2次執行)
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//不理解為什麽第2次執行(在修改參數optimizer_index_caching後)還需要持有shared pool latch...
--//再來看看:
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:(修改參數後第3次執行)
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 157 5 180 latch: library cache WAITING 0 24
--//session 2:取消library cache latch.
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
00000000600E7840 00000000000000D6 00 1611561024 214 0 157 5 181 latch: shared pool WAITING 0 64
--//session 2: 取消shared pool latch.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//執行成功!!
--//session 2:再來看看:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//可以發現同一會話如果產生新的子光標,第1,2,3次執行都需要library cache latch和shared pool latch.第4次執行光標已經cache,不再需要持有對應latch.
9.測試4:
--//再回到session 4,參數沒有變化optimizer_index_caching變化.看看現在的情況(該會話已經執行)select * from dept where deptno=12; 2次:
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000001
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//軟軟解析依舊有效.
SYS@test> select * from v$open_cursor where SID in (157,141) and sql_text like ‘%deptno%‘;
SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_ID SQL_TEXT
---------------- ---------- --------- ---------------- ---------- ------------- ----------------------------------
000000007CF80200 157 SCOTT 000000007683E920 30432287 2f476y80x0r0z select * from dept where deptno=12
000000007CF6AB80 141 SCOTT 000000007683E920 30432287 2f476y80x0r0z select * from dept where deptno=12
10.測試5:
--//修改session 4參數:
--//session 4:
SCOTT@test> alter session set optimizer_index_caching=1;
Session altered.
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 4:
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 00000001
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//軟軟解析!!
11.總結:
--//不好寫.11g已經不存在這個shared pool latch,改為mutexes.所以測試在10g下進行!!
--//硬解析先要library cache latch,估計查詢該光標是否在共享池存在,如果不存在,持有shared pool latch,使用共享池內存建立父子光標.
--//再持有library cache latch.關於這點從前面的轉儲可以發現.但是等待事件先出現的是shared pool latch,然後才是library cache latch.
--//軟解析的情況要正常需要持有library cache latch以及shared pool latch.
--//軟軟解析不需要持有對應的library cache latch和shared pool latch.
--//即使光標緩存的情況下,新建立的會話第1次執行也需要持有library cache latch.shared pool latch.
--//如果某種原因產生子光標的情況下,第1,2,3次執行都需要library cache latch和shared pool latch.第4次執行光標已經cache,不再需要持有對應
--//library cache latch和shared pool latch.
[20190319]shared pool latch與library cache latch的簡單探究.txt
--//昨天看Oracle DBA手記3：數據庫性能優化與內部原理解析.pdf 電子書,看了eygle的關於latch之類的測試.
--//自己也重復測試看看.
--//首先說明一下11g已經不存在這個shared pool latch,改為mutexes.所以測試在10g下進行:
--//註意不要在生產系統做這樣的測試!!
1.環境:
SCOTT@test> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- ----------------------------------------------------------------
--//把一些常用命令先執行多次(3次以上避免執行時分析時掛起),比如 @ &r/wait10g,也可以事先多開幾個sys登錄會話.
$ cat wait10g.sql
select p1raw,p2raw,p3raw,p1,p2,p3,sid,serial#,seq#,event,state,wait_time,seconds_in_wait from v$session where wait_class<>‘Idle‘
order by event ;
SELECT addr
,latch#
,child#
,level#
,name
,gets
,sleeps
,immediate_gets
,immediate_misses
,spin_gets
FROM V$LATCH_CHILDREN
WHERE name LIKE ‘library cache‘;
ADDR LATCH# CHILD# LEVEL# NAME GETS SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS
000000007A753430 215 29 5 library cache 1256 0 0 0 1
000000007A7534D0 215 28 5 library cache 741 0 0 0 0
000000007A753570 215 27 5 library cache 1022 0 0 0 0
000000007A753610 215 26 5 library cache 958 0 0 0 0
000000007A7536B0 215 25 5 library cache 1079 0 0 0 0
000000007A753750 215 24 5 library cache 1022 0 0 0 0
000000007A7537F0 215 23 5 library cache 1076 0 0 0 3
000000007A753890 215 22 5 library cache 950 0 0 0 0
000000007A753930 215 21 5 library cache 1028 0 0 0 0
000000007A7539D0 215 20 5 library cache 1223 0 0 0 0
000000007A753A70 215 19 5 library cache 941 0 0 0 0
000000007A753B10 215 18 5 library cache 781 0 0 0 0
000000007A753BB0 215 17 5 library cache 1050 0 0 0 3
000000007A753C50 215 16 5 library cache 1098 0 0 0 0
000000007A753CF0 215 15 5 library cache 1295 0 0 0 1
000000007A753D90 215 14 5 library cache 1431 0 0 0 1
000000007A753E30 215 13 5 library cache 1186 0 1 0 0
000000007A753ED0 215 12 5 library cache 1265 0 0 0 2
000000007A753F70 215 11 5 library cache 942 0 0 0 0
000000007A754010 215 10 5 library cache 1401 0 0 0 6
000000007A7540B0 215 9 5 library cache 1181 0 0 0 0
000000007A754150 215 8 5 library cache 1131 0 0 0 0
000000007A7541F0 215 7 5 library cache 1191 0 0 0 1
000000007A754290 215 6 5 library cache 611 0 0 0 0
000000007A754330 215 5 5 library cache 1189 0 0 0 0
000000007A7543D0 215 4 5 library cache 1165 0 0 0 0
000000007A754470 215 3 5 library cache 861 0 0 0 0
000000007A754510 215 2 5 library cache 1328 0 0 0 1
000000007A7545B0 215 1 5 library cache 1199 1 0 0 0
29 rows selected.
--//29個latch.
--//library cache latch數量與cpu數量有關.選取大於cpu數量的最接近的質數.我當前cpu數量24(實際上2個cpu, 每個Core Count:
--//6,Core Enabled: 6,Thread Count: 12),這樣顯示的24個cpu,我自己還第一次註意這個細節.
--//我簡單驗證修改cpu_count=8,library cache latch的數量是11.修改cpu_count=12,library cache latch的數量是13.大家可以自行驗證.
--//註意必須重啟才生效.
SCOTT@test> show parameter cpu_count
NAME TYPE VALUE
--------- -------- -----
cpu_count integer 24
SELECT addr
,latch#
,child#
,level#
,name
,gets
,sleeps
,immediate_gets
,immediate_misses
,spin_gets
FROM V$LATCH_CHILDREN
WHERE name LIKE ‘shared pool‘
ORDER BY addr;
ADDR LATCH# CHILD# LEVEL# NAME GETS SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES SPIN_GETS
---------------- ------ ------ ------ ----------- ----- ------ -------------- ---------------- ---------
00000000600E7840 214 1 7 shared pool 43351 0 0 0 849
00000000600E78E0 214 2 7 shared pool 8 0 0 0 0
00000000600E7980 214 3 7 shared pool 8 0 0 0 0
00000000600E7A20 214 4 7 shared pool 8 0 0 0 0
00000000600E7AC0 214 5 7 shared pool 8 0 0 0 0
00000000600E7B60 214 6 7 shared pool 8 0 0 0 0
00000000600E7C00 214 7 7 shared pool 8 0 0 0 0
7 rows selected.
--//註意僅僅一個shared pool latch的gets很大,其它實際上啟動後不會使用.
--//shared pool latch的數量與共享池內存大小,cpu數量有關.實際上取 共享池內存大小/512M(對於11G是這樣,早期版本有一些除256M,128M)
--//以及cpu數量/4的最小值.我設置sga才484M.僅僅1個shared pool latch.
--//另外latch實際上共享池內存的一片區域.你可以註意.相鄰地址相減大小一樣,相當於數組.比如:
--//0x600E7840=1611561024
--//0x600E78E0=1611561184
--//600E7980=1611561344
--//1611561184-1611561024 = 160
--//1611561344-1611561184 = 160
2.測試前準備:
--//打開3個會話窗口,將一些需要執行的sql語句執行多次,避免測試時硬解析時掛起.
--//desc dept.
--//select * from dept ;
--// @ &r/wait10g
--//Select * from dept where deptno=12;
3.測試1:
--//session 1:
SCOTT@test> @ &r/spid
SID SERIAL# PROCESS SERVER SPID PID P_SERIAL# C50
---------- ---------- ------------ --------- ------ ------- ---------- --------------------------------------------------
157 5 13448 DEDICATED 13449 17 3 alter system kill session ‘157,5‘ immediate;
--//session 2:
SYS@test> oradebug setmypid
Statement processed.
SYS@test> oradebug peek 0x00000000600E7840 4
[0600E7840, 0600E7844) = 00000000
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
--//給shared pool加上latch.
--//session 1:(第1次執行)
SCOTT@test> select * from dept where deptno=12;
--//註意seelect小寫與前面不同,主要是執行一次硬解析,同時避開一些遞歸語句.
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- ------------------ ------- --------- ---------------
00000000600E7840 00000000000000D6 00 1611561024 214 0 157 5 114 latch: shared pool WAITING 0 60
00000000600E7840 00000000000000D6 00 1611561024 214 0 162 1 3266 latch: shared pool WAITING 0 66
00000000600E7840 00000000000000D6 00 1611561024 214 0 160 1 44 latch: shared pool WAITING 0 90
00000000600E7840 00000000000000D6 00 1611561024 214 0 159 1 625 latch: shared pool WAITING 0 69
--//session 2:
SYS@test> oradebug dump systemstate 266
Statement processed.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//這樣掛起會話中語句執行成功!!
SYS@test> @ &r/wait10g
no rows selected
--//說明硬解析的sql語句需要獲取shared pool.
4.檢查轉儲文件內容:
PROCESS 17:
----------------------------------------
SO: 0x7ce63c10, type: 2, owner: (nil), flag: INIT/-/-/0x00
(process) Oracle pid=17, calls cur/top: 0x7cfa89b0/0x7cfa89b0, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 0 0 0
last post received-location: No post
last process to post me: none
last post sent: 0 0 33
last post sent-location: ksrpublish
last process posted by me: 7ce604b8 1 22
(latch info) wait_event=0 bits=20
Location from where call was made: kghalo:
waiting for 600e7840 Child shared pool level=7 child#=1
Location from where latch is held: kghupr1: Chunk Header
Context saved from call: 1986860088
state=busy, wlstate=free
waiters [orapid (seconds since: put on list, posted, alive check)]:
12 (197, 1552958147, 2)
13 (176, 1552958147, 2)
10 (173, 1552958147, 5)
17 (167, 1552958147, 167)
waiter count=4
gotten 75402 times wait, failed first 851 sleeps 0
gotten 0 times nowait, failed: 0
on wait list for 600e7840
holding (efd=4) 7a7537f0 Child library cache level=5 child#=23
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Location from where latch is held: kglhdgn: child:: latch
Context saved from call: 6
state=busy, wlstate=free
Process Group: DEFAULT, pseudo proc: 0x7cea6ac8
O/S info: user: oracle, term: pts/3, ospid: 13449
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OSD pid info: Unix process pid: 13449, image: oracle@xxxxdg (TNS V1-V3)
Short stack dump:
--//ospid: 13449,註意看下劃線內容,指示它還持有library cache level=5 child#=23.對於child#=23.也就是第一次硬解析還需要持有
--//library cache latch,是否相同的sql語句每次解析都需要持有library cache latch,而且child#都是一樣的呢?
--//可以推測應該一樣,假設2條相同的sql語句需要硬解析,如果持有library cache latch的child#不一樣,這樣有可能出現2個光標在共
--//享池?所以推測下次執行相同語句使用的library cache latch的child#應該與前一次相同.
5.繼續測試:
--//session 2:
SYS@test> oradebug peek 0x000000007A7537F0 4
[07A7537F0, 07A7537F4) = 00000000
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//給對應library cache 加latch,child#=23.
--//session 1:(第2次執行)
SCOTT@test> select * from dept where deptno=12;
--//再次掛起!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- -------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 157 5 146 latch: library cache WAITING 0 27
--//這就是軟解析,需要持有library cache ltach.P1raw=000000007A7537F0也可以對上.
--//註:另外補充說明一下 第2,3次執行 軟解析也需要1次shared pool latch.
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:(第2次執行)
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//執行成功!!繼續:
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:(第3次執行)
SCOTT@test> select * from dept where deptno=12;
--//再次掛起!
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
6.測試2:
--//當前已經執行select * from dept where deptno=12;3次,如果session_cached_cursors非0的情況下,該光標已經被緩存,也就是相同
--//會話的情況下次執行,就是軟軟解析,不需要在持有library cache ltach.
--//session 3:
SYS@test> select * from v$open_cursor where SID=157;
SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_ID SQL_TEXT
---------------- ---------- --------- ---------------- ---------- ------------- ----------------------------------
000000007CF80200 157 SCOTT 000000007683E920 30432287 2f476y80x0r0z select * from dept where deptno=12
000000007CF80200 157 SCOTT 000000007C9C1D68 3393152264 4gd6b1r53yt88 table_1_ff_14f_0_0_0
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//執行成功!!也就是當光標緩存後,sql語句執行不需要在持有對應的library cache latch,oracle通過這樣的方式(軟解析,軟軟解析)減少latch的使用.
7.測試3:
--//如果打開新的會話窗口,再次執行select * from dept where deptno=12;,對於新會話並沒有緩存該光標,第1次執行應該也是軟解析.
--//通過測試說明問題.
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//首先取消shared pool latch.註意library cache latch還在.child#=23.
--//註:另外補充說明一下 第2,3次執行 軟解析也需要1次shared pool latch.估計這樣不允許這時建立新的子光標.
--//session 4:
SCOTT@test> @ &r/spid
SID SERIAL# PROCESS SERVER SPID PID P_SERIAL# C50
---------- ---------- ------------ --------- ------ ------- ---------- --------------------------------------------------
141 45 13648 DEDICATED 13649 25 3 alter system kill session ‘141,45‘ immediate;
SCOTT@test> select * from dept where deptno=12;
--//再次掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- -------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 141 45 33 latch: library cache WAITING 0 18
--//sid=141,正是新打開的會話sid=141.
--//session 2:取消library cache latch.
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//正常執行!!也就是新打開會話即使其它會話已經緩存光標,第1次執行也是軟解析.
--//如果會話再次執行,應該該光標緩存,就不再需要對應的library cache latch.
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//ok,執行成功!!也就是這次是軟軟解析.
8.測試3:
--//如果會話改變參數,這樣會產生新的子光標,看看這樣的情況會持有那些latch.
--//session 1:
SCOTT@test> show parameter optimizer_index_caching
NAME TYPE VALUE
----------------------- ------- -----
optimizer_index_caching integer 0
SCOTT@test> alter session set optimizer_index_caching=1;
Session altered.
--//修改參數optimizer_index_caching,這樣如果執行select * from dept where deptno=12;會產生新的子光標.
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:(修改參數後第1次執行)
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- -------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 157 5 172 latch: library cache WAITING 0 21
00000000600E7840 00000000000000D6 00 1611561024 214 0 160 1 59 latch: shared pool WAITING 0 48
00000000600E7840 00000000000000D6 00 1611561024 214 0 159 1 799 latch: shared pool WAITING 0 45
--//註意僅僅看sid=157行,還需要library cache latch,因為父光標已經存在.
--//session 2:取消對應library cache latch.
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:檢查發現會話一樣掛起!!
SCOTT@test> select * from dept where deptno=12;
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
00000000600E7840 00000000000000D6 00 1611561024 214 0 157 5 173 latch: shared pool WAITING 0 51
00000000600E7840 00000000000000D6 00 1611561024 214 0 160 1 59 latch: shared pool WAITING 0 192
00000000600E7840 00000000000000D6 00 1611561024 214 0 159 1 799 latch: shared pool WAITING 0 189
--//可以發現現在等待事件變成了latch: shared pool(sid=157).可以發現要因為參數的變化,要生產新的子光標,需要持有shared pool
--//latch 從共享池內存建立子光標.
--//session 2:取消shared pool latch.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//執行成功!!繼續測試:
--//session 2: 再次設置latch.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:(修改參數後第2次執行)
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 157 5 176 latch: library cache WAITING 0 21
--//需要對應library cache latch.
--//session 2: 取消library cache latch.
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
--//還是掛起!!看看等待事件.
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
00000000600E7840 00000000000000D6 00 1611561024 214 0 157 5 177 latch: shared pool WAITING 0 12
--//奇怪還是需要持有shared pool latch.為什麽??
--//session 2: 取消shared pool latch.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//session 1:(修改參數後第2次執行)
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//不理解為什麽第2次執行(在修改參數optimizer_index_caching後)還需要持有shared pool latch...
--//再來看看:
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:(修改參數後第3次執行)
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
000000007A7537F0 00000000000000D7 00 2054502384 215 0 157 5 180 latch: library cache WAITING 0 24
--//session 2:取消library cache latch.
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 3:
SYS@test> @ &r/wait10g
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATE WAIT_TIME SECONDS_IN_WAIT
---------------- ---------------- ----- ---------- ---------- ---------- ---------- ---------- ---------- --------------------- ------- --------- ---------------
00000000600E7840 00000000000000D6 00 1611561024 214 0 157 5 181 latch: shared pool WAITING 0 64
--//session 2: 取消shared pool latch.
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000000
BEFORE: [0600E7840, 0600E7844) = 000000FF
AFTER: [0600E7840, 0600E7844) = 00000000
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//執行成功!!
--//session 2:再來看看:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 1:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//可以發現同一會話如果產生新的子光標,第1,2,3次執行都需要library cache latch和shared pool latch.第4次執行光標已經cache,不再需要持有對應latch.
9.測試4:
--//再回到session 4,參數沒有變化optimizer_index_caching變化.看看現在的情況(該會話已經執行)select * from dept where deptno=12; 2次:
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000001
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//軟軟解析依舊有效.
SYS@test> select * from v$open_cursor where SID in (157,141) and sql_text like ‘%deptno%‘;
SADDR SID USER_NAME ADDRESS HASH_VALUE SQL_ID SQL_TEXT
---------------- ---------- --------- ---------------- ---------- ------------- ----------------------------------
000000007CF80200 157 SCOTT 000000007683E920 30432287 2f476y80x0r0z select * from dept where deptno=12
000000007CF6AB80 141 SCOTT 000000007683E920 30432287 2f476y80x0r0z select * from dept where deptno=12
10.測試5:
--//修改session 4參數:
--//session 4:
SCOTT@test> alter session set optimizer_index_caching=1;
Session altered.
--//session 2:
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 000000FF
AFTER: [07A7537F0, 07A7537F4) = 00000001
--//session 4:
SCOTT@test> select * from dept where deptno=12;
--//掛起!!
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000000
BEFORE: [07A7537F0, 07A7537F4) = 00000001
AFTER: [07A7537F0, 07A7537F4) = 00000000
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//session 2:
SYS@test> oradebug poke 0x000000007A7537F0 4 0x00000001
BEFORE: [07A7537F0, 07A7537F4) = 00000000
AFTER: [07A7537F0, 07A7537F4) = 00000001
SYS@test> oradebug poke 0x00000000600E7840 4 0x00000001
BEFORE: [0600E7840, 0600E7844) = 00000000
AFTER: [0600E7840, 0600E7844) = 00000001
--//session 4:
SCOTT@test> select * from dept where deptno=12;
no rows selected
--//軟軟解析!!
11.總結:
--//不好寫.11g已經不存在這個shared pool latch,改為mutexes.所以測試在10g下進行!!
--//硬解析先要library cache latch,估計查詢該光標是否在共享池存在,如果不存在,持有shared pool latch,使用共享池內存建立父子光標.
--//再持有library cache latch.關於這點從前面的轉儲可以發現.但是等待事件先出現的是shared pool latch,然後才是library cache latch.
--//軟解析的情況要正常需要持有library cache latch以及shared pool latch.
--//軟軟解析不需要持有對應的library cache latch和shared pool latch.
--//即使光標緩存的情況下,新建立的會話第1次執行也需要持有library cache latch.shared pool latch.
--//如果某種原因產生子光標的情況下,第1,2,3次執行都需要library cache latch和shared pool latch.第4次執行光標已經cache,不再需要持有對應
--//library cache latch和shared pool latch.
[20190319]shared pool latch與library cache latch的簡單探究.txt