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

58次阅读
没有评论

共计 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

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

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

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-20发表,共计10078字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)