為什么oracle 10.2.0.5只會獲取child#=1的shared pool latch

179次閱讀

共計 10078 個字符，預計需要花費 26 分鐘才能閱讀完成。

這篇文章主要介紹了為什么 oracle 10.2.0.5 只會獲取 child#= 1 的 shared pool latch，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。

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

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

感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“為什么 oracle 10.2.0.5 只會獲取 child#= 1 的 shared pool latch”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業資訊頻道，更多相關知識等著你來學習!

正文完