分析為何oracle 10.2.0.5只會獲取child#=1的shared pool latch之系列六
結論
1,可以用oradebug dump heapdump 3轉儲共享池的結構資訊這個級別一般3即可,6的代價有些大了
2,語法如下:
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump heapdump 3
Statement processed.
SQL> oradebug tracefile_name
/home/ora10g/admin/ora10g/udump/ora10g_ora_6533.trc
3,轉儲共享池的TRC檔案結構如下:
第一部分:LATCH資訊
KGH Latch Directory Information
ldir state: 2 Last allocated slot: 77
Slot [ 1] Latch: 0xa4222c98 Index: 2 Flags: 3 State: 2 next: (nil)
第二部分:HEAP資訊,可見共計5個堆,對應子池的個數,由引數_kghdsidx_count控制
HEAP DUMP heap name="sga heap" desc=0x60000058
extent sz=0x47c0 alt=216 het=32767 rec=9 flg=-126 opc=0
parent=(nil) owner=(nil) nex=(nil) xsz=0x160
ds for latch 1: 0x60034fe0 0x60036838 0x60038090 --可見保護其子堆需要3個latch
ds for latch 2: 0x6003e808 0x60040060 0x600418b8
ds for latch 3: 0x60048030 0x60049888 0x6004b0e0
ds for latch 4: 0x60051858 0x600530b0 0x60054908
ds for latch 5: 0x6005b080 0x6005c8d8 0x6005e130 0x6005f988 --保護其子堆需要4個latch
reserved granule count 0 (granule size 16777216)
第三部分:上述每個堆的具體資訊,而且TRC下述資訊是以每個堆的子堆為基礎展開的,其它子堆結構同理
HEAP DUMP heap name="sga heap(1,0)" desc=0x60034fe0
extent sz=0xfe0 alt=216 het=32767 rec=9 flg=-126 opc=0
parent=(nil) owner=(nil) nex=(nil) xsz=0x1000000
latch set 1 of 5
durations enabled for this heap
reserved granules for root 0 (granule size 16777216)
可見子堆由區構成,而區又包括多個CHUNK
第四部分是一個空閒列表的BUCKET列表
FREE LISTS:
Bucket 0 size=32
Bucket 1 size=40
Bucket 2 size=48
Bucket 3 size=56
Bucket 4 size=64
Bucket 5 size=72
Bucket 6 size=80
Bucket 7 size=88
Bucket 8 size=96
Bucket 9 size=104
中間略
Bucket 250 size=12352
Bucket 251 size=12360
Bucket 252 size=16408
Bucket 253 size=32792
Bucket 254 size=65560
也就是說管理空閒空間是由BUCKET進行管理,把可以分配或回收的CHUNK地址資訊儲存在對應的BUCKET中,具體要儲存在哪個BUCKET中,要看CHUNK的大小,和對應的BUCKET進行匹配
第五部分:是一個預備的空間列表BUCKET列表(同第四部分理)
RESERVED FREE LISTS:
Reserved bucket 0 size=32
Reserved bucket 1 size=4400
Reserved bucket 2 size=8216
Reserved bucket 3 size=8696
Reserved bucket 4 size=8704
Reserved bucket 5 size=8712
Reserved bucket 6 size=8720
Reserved bucket 7 size=9368
Reserved bucket 8 size=9376
Reserved bucket 9 size=12352
Reserved bucket 10 size=12360
Reserved bucket 11 size=16408
Reserved bucket 12 size=32792
Reserved bucket 13 size=65560
第六部分:未PIN住的可以重建或重用的chunk列表(lru優先,關於LRU還要研究),如下包括很多CHUNK
UNPINNED RECREATABLE CHUNKS (lru first):
Chunk 0a3bd5420 sz= 56 recreate "fixed allocatio" latch=0x9e5c8db0 --CHUNK地址,大小,狀態及型別,CHUNK對應的LATCH地址,經在TRC檔案查詢,可以和TRC檔案第一部分的LATCH關聯起來
Chunk 0a3bc7fb8 sz= 56 recreate "fixed allocatio" latch=0x9e5c7d10 --fixed allocatio對應x$ksmsp的ksmchcom,可以理解為CHUNK的名稱
中間略
Chunk 0a3ba1a78 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3ba1848 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
SEPARATOR
Chunk 0a3bb2340 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3bb2110 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
中間略
Chunk 0a3b631e0 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3b62fb0 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3b62d80 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3b62b50 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
第七部分:永久或持久的CHUNK列表,同上理,包括很多個CHUNK,不過這裡僅一個CHUNK,且其型別為PERM,而且沒有LATCH保護
PERMANENT CHUNKS:
Chunk 09e0cd000 sz= 15937536 perm "perm " alo=8424224
Permanent space = 15937536
4,共享池CHUNK的資訊可以查詢X$KSMSP
SQL> select addr,ksmchidx,ksmchcom,ksmchptr,KSMCHCLS,ksmchsiz,ksmchtyp,ksmchdur from x$ksmsp where ksmchcom='fixed allocatio' and ksmchsiz=56 and KSMCHCLS='recr' and ksmchptr='00000000A3BD5420';
ADDR KSMCHIDX KSMCHCOM KSMCHPTR KSMCHCLS KSMCHSIZ KSMCHTYP KSMCHDUR
---------------- ---------- ---------------- ---------------- -------- ---------- ---------- ----------
00002B0CBA8B5548 1 fixed allocatio 00000000A3BD5420 recr 56 72 2
5,如果HANG SHARED POOL LATCH,oradebug dump heapdump會HANG住
6,暫未在TRC檔案找到SHARED POOL LATCH
7,上述TRC檔案每個部分後面會列出對應部分可用空間總大小
測試
SQL> select * from v$version where rownum=1;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
--轉儲共享池shared pool
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump heapdump 3
Statement processed.
SQL> oradebug tracefile_name
/home/ora10g/admin/ora10g/udump/ora10g_ora_6533.trc
--TRC檔案
---第一部分是一些latch的資訊
KGH Latch Directory Information
ldir state: 2 Last allocated slot: 77
Slot [ 1] Latch: 0xa4222c98 Index: 2 Flags: 3 State: 2 next: (nil)
Slot [ 2] Latch: 0xa4222d78 Index: 3 Flags: 3 State: 2 next: (nil)
Slot [ 3] Latch: 0x6000a6c0 Index: 4 Flags: 3 State: 2 next: (nil)
中間略
Slot [ 75] Latch: 0x600270b0 Index: 1 Flags: 3 State: 2 next: 0x600e85c0
Slot [ 76] Latch: 0x6002abf0 Index: 2 Flags: 3 State: 2 next: (nil)
Slot [ 77] Latch: 0x60031378 Index: 3 Flags: 3 State: 2 next: 0x600e81b8
---第二部是heap的資訊,可見共計5個heap堆(注: _kghdsidx_count=5,堆即分配記憶體的一種記憶體結構)
HEAP DUMP heap name="sga heap" desc=0x60000058
extent sz=0x47c0 alt=216 het=32767 rec=9 flg=-126 opc=0
parent=(nil) owner=(nil) nex=(nil) xsz=0x160
ds for latch 1: 0x60034fe0 0x60036838 0x60038090 --可見保護其子堆需要3個latch
ds for latch 2: 0x6003e808 0x60040060 0x600418b8
ds for latch 3: 0x60048030 0x60049888 0x6004b0e0
ds for latch 4: 0x60051858 0x600530b0 0x60054908
ds for latch 5: 0x6005b080 0x6005c8d8 0x6005e130 0x6005f988 --保護其子堆需要4個latch
reserved granule count 0 (granule size 16777216)
第三部分是上述每個子堆的具體資訊,僅講述一個子堆即可,其它同理
可知:
1,前4個堆,每個堆有3個子堆
最後一個堆,有4個子堆
2,TRC檔案的下面內容是以每個堆的子堆為基礎進行,我分析也以此為準
下面詳解第三部分,即第一個堆的第一個子堆,即sga heap(1,0),其中1表示第一個堆,0表示第一個子堆
HEAP DUMP heap name="sga heap(1,0)" desc=0x60034fe0
extent sz=0xfe0 alt=216 het=32767 rec=9 flg=-126 opc=0
parent=(nil) owner=(nil) nex=(nil) xsz=0x1000000
latch set 1 of 5
durations enabled for this heap
reserved granules for root 0 (granule size 16777216)
可見子堆下面是一個區extent
EXTENT 0 addr=0x9e000000
可見區extent下面是很多個chunk
Chunk 09e000058 sz= 48 R-freeable "reserved stoppe" --每個chunk包括地址,大小,狀態及型別
Chunk 09e000088 sz= 839496 R-free " "
Chunk 09e0ccfd0 sz= 48 R-freeable "reserved stoppe"
Chunk 09e0cd000 sz= 15937536 perm "perm " alo=8424224
Total heap size = 16777128 --這個推大小,就是上面所有chunk的大小之和
可見有一個空閒可用的列表,記錄很多個bucket,每個bucket的編號及大小,共計254個bucket
FREE LISTS:
Bucket 0 size=32
Bucket 1 size=40
Bucket 2 size=48
Bucket 3 size=56
Bucket 4 size=64
Bucket 5 size=72
Bucket 6 size=80
Bucket 7 size=88
Bucket 8 size=96
Bucket 9 size=104
中間略
Bucket 250 size=12352
Bucket 251 size=12360
Bucket 252 size=16408
Bucket 253 size=32792
Bucket 254 size=65560
Total free space = 0
接著是一個預備的空閒可用的列表,格式同上,也是記錄很多個bucket
RESERVED FREE LISTS:
Reserved bucket 0 size=32
Reserved bucket 1 size=4400
Reserved bucket 2 size=8216
Reserved bucket 3 size=8696
Reserved bucket 4 size=8704
Reserved bucket 5 size=8712
Reserved bucket 6 size=8720
Reserved bucket 7 size=9368
Reserved bucket 8 size=9376
Reserved bucket 9 size=12352
Reserved bucket 10 size=12360
Reserved bucket 11 size=16408
Reserved bucket 12 size=32792
Reserved bucket 13 size=65560
上述區extent中的chunk中的未使用過的chunk,注意後面的 " "
Chunk 09e000088 sz= 839496 R-free " "
而且可見chunk的資訊是記錄在每個bucket中
標明上述預備的空閒可用空間的大小為839496,剛好就是上述哪個chunk
Total reserved free space = 839496
未PIN住的可以重建或重用的chunk列表(lru優先,關於LRU還要研究),如下包括很多CHUNK
UNPINNED RECREATABLE CHUNKS (lru first):
Chunk 0a3bd5420 sz= 56 recreate "fixed allocatio" latch=0x9e5c8db0 --CHUNK地址,大小,狀態及型別,CHUNK對應的LATCH地址,經在TRC檔案查詢,可以和TRC檔案第一部分的LATCH關聯起來
Chunk 0a3bc7fb8 sz= 56 recreate "fixed allocatio" latch=0x9e5c7d10 --fixed allocatio對應x$ksmsp的ksmchcom,可以理解為CHUNK的名稱
中間略
Chunk 0a3ba1a78 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3ba1848 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
SEPARATOR
Chunk 0a3bb2340 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3bb2110 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
中間略
Chunk 0a3b631e0 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3b62fb0 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3b62d80 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
Chunk 0a3b62b50 sz= 560 recreate "KQR PO " latch=0x9e5c7d10
標明上述未PIN住的空間大小
Unpinned space = 221984 rcr=78 trn=322
永久或持久的CHUNK列表,同上理,包括很多個CHUNK,不過這裡僅一個CHUNK,且其型別為PERM,而且沒有LATCH保護
PERMANENT CHUNKS:
Chunk 09e0cd000 sz= 15937536 perm "perm " alo=8424224
Permanent space = 15937536
標明上述永久的CHUNK空間的大小
我們繼續分析
--x$ksmsp記錄共享池中chunk的相關資訊,可見共計20917個CHUNK
SQL> select count(*) from x$ksmsp;
COUNT(*)
----------
20917
查詢上述 未PIN住的可以重建或重用的chunk列表 第一個CHUNK
SQL> select addr,ksmchidx,ksmchcom,ksmchptr,KSMCHCLS,ksmchsiz,ksmchtyp,ksmchdur from x$ksmsp where ksmchcom='fixed allocatio' and ksmchsiz=56 and KSMCHCLS='recr' and ksmchptr='00000000A3BD5420';
ADDR KSMCHIDX KSMCHCOM KSMCHPTR KSMCHCLS KSMCHSIZ KSMCHTYP KSMCHDUR
---------------- ---------- ---------------- ---------------- -------- ---------- ---------- ----------
00002B0CBA8B5548 1 fixed allocatio 00000000A3BD5420 recr 56 72 2
由下可見TRC檔案第一部分LATCH對應V$LATCH_chidlren,且注意:ADDR為小寫,不要用大寫,否則查詢不到資訊
SQL> select addr,latch#,level#,name from v$latch_children where lower(addr) like '%a4222c98%';
ADDR LATCH# LEVEL# NAME
---------------- ---------- ---------- --------------------------------------------------
00000000A4222C98 29 0 ksfv messages
但是仍然找不到shared pool latch
加大DUMP級別看看,可否找到shared pool latch
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump heapdump 10
ORA-00085: current call does not exist
SQL> oradebug dump heapdump 6
Statement processed.
SQL> oradebug tracefile_name
/home/ora10g/admin/ora10g/udump/ora10g_ora_8143.trc
還是找不到shared pool latch,轉換思路,先HANG shared pool latch,再檢視DUMP檔案,看可否有,如還沒有,就是我分析思路不對
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x00000000600E7AF0 4 1
BEFORE: [0600E7AF0, 0600E7AF4) = 00000000
AFTER: [0600E7AF0, 0600E7AF4) = 00000001
SQL> oradebug setmypid
Statement processed.
不過好現如果HANG SHARED POOL LATCH,發現oradebug dump heapdump 6 也hang住了
SQL> oradebug dump heapdump 6
只能以PRELIM方式先恢復SHARED POOL LATCH
[ora10g@seconary ~]$ sqlplus -prelim '/as sysdba'
SQL*Plus: Release 10.2.0.5.0 - Production on Thu Nov 19 07:37:53 2015
Copyright (c) 1982, 2010, Oracle. All Rights Reserved.
SQL> oradebug poke 0x00000000600E7AF0 4 0
ORA-00074: no process has been specified
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x00000000600E7AF0 4 0
BEFORE: [0600E7AF0, 0600E7AF4) = 000000FF
AFTER: [0600E7AF0, 0600E7AF4) = 00000000
發現heapdump 3也不行會HANG
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump heapdump 3
Statement processed.
這樣,HANG住CHILD#=2的shared pool latch,看什麼情況,最後發現也會HANG住,可能因為不是一個子池的原因,深入原因還要研究
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x00000000600E7B90 4 1
BEFORE: [0600E7B90, 0600E7B94) = 00000000
AFTER: [0600E7B90, 0600E7B94) = 00000001
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9240380/viewspace-1841437/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 在oracle 10.2.0.5分析硬解析及軟解析及軟軟解析獲取shared pool latch機制系列五Oracle
- 共享池之六:shared pool latch/ library cache latch /lock pin 簡介
- latch:shared pool的一點理解
- oracle實驗記錄 (oracle 分析shared pool(1))Oracle
- ORACLE SGA之shared poolOracle
- 轉_診斷latch:shared pool等待事件事件
- oracle優化--shared_pool (1)Oracle優化
- 優化Shared Pool Latch與Library Cache Latch競爭優化
- Oracle shared poolOracle
- oracle實驗記錄 (oracle 分析shared pool(2))Oracle
- 理解Oracle Shared PoolOracle
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列1優化
- oracle 11g latch之v$latch系列二Oracle
- oracle 11g latch之v$latch系列三Oracle
- Shared Pool 的轉儲與分析
- Oracle Shared Pool Memory ManagementOracle
- zt_Oracle shared pool internals_共享池_shared_poolOracle
- ORACLE記憶體管理 之五 SGA variable pool,shared_pool,large_pool,java_poolOracle記憶體Java
- shared pool library cache latch 競爭優化辦法優化
- Oracle基礎包之DBMS_SHARED_POOL(十)Oracle
- 簡單分析shared pool(一)
- 簡單分析shared pool(二)
- 簡單分析shared pool(三)
- Shared Pool優化和Library Cache Latch衝突優化優化
- oracle 11g latch之系列一Oracle
- Oracle Shared Pool機制之——Latches, Locks, Pins and MutexesOracleMutex
- 《深入解析Oracle》第六章,Buffer Cache與Shared Pool原理Oracle
- 深入理解shared pool共享池之library cache系列一
- 深入理解shared pool共享池之library cache系列二
- oracle優化--shared_pool (3)Oracle優化
- oracle優化--shared_pool (2)Oracle優化
- oracle 11g latch之v$latch和systemstate dump檔案之系列四Oracle
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列6優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列5優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列4優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列3優化
- 【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列2優化
- 為何我的程式獲取不了圖片?