为什么oracle 10.2.0.5只会获取child#=1的shared pool latch

这篇文章主要介绍了为什么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

感谢你能够认真阅读完这篇文章，希望小编分享的“为什么oracle 10.2.0.5只会获取child#=1的shared pool latch”这篇文章对大家有帮助，同时也希望大家多多支持，关注行业资讯频道，更多相关知识等着你来学习!