可以看到gcs/ges resource/enqueue这部分内存都消耗了1.4g 左右，还是比较大的，另外ASM extent pointer array
也有300多m。这个可能跟asm的extent分配有关系，对于DW缓解，建议不要使用默认的uniform AU 1m，太小了。
总体来看，从这个subpool的使用情况来看，无法看出是不是碎片严重了。但是从dump下面的library 数据来看，也是
能看出一些端倪的，如下：
LIBRARY CACHE STATISTICS: namespace gets hit ratio pins hit ratio reloads invalids -------------- --------- --------- --------- --------- ---------- ---------- SQL AREA 325150175 0.984 2560976170 0.992 2656085 3942426 TABLE/PROCEDURE 73717472 0.996 786560445 0.998 481299 1362 BODY 11738443 1.000 86301250 1.000 521 0 TRIGGER 3247968 1.000 3248823 0.999 153 2 INDEX 576294 0.993 577639 0.974 8448 0 ........ |
大家可以看到，SQL area 这里的reloads和invalids太高了。说明这个时间点shared pool的可用内存可能不多。虽然
从前面的dump看free memory还不少。 我们需要明白一点，Oracle消耗shared pool的内存，是需要连续的一段内存区域。
从这里来看如果如不是shared pool碎片严重那么可能就是有大的SQL操作。我们看该进程的信息发现该进程一直在等待
某个latch Child parallel query alloc buffer，如下：
SO: 0xc000001842ba9750, type: 2, owner: 0x0000000000000000, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xc000001842ba9750, name=process, file=ksu.h LINE:12616 ID:, pg=0
(process) Oracle pid:664, ser:2, calls cur/top: 0xc0000015e1989c10/0xc000001711b743a8
flags : (0x0) -
flags2: (0x0), flags3: (0x10)
intr error: -2147473260, call error: 0, sess error: 0, txn error 0
intr queue: 2147494036
ksudlp FALSE at location: 0
(post info) last post received: 2147494036 136 12
last post received-location: ksu.h LINE:13927 ID:ksusig
last process to post me: c000001832b0b620 242 0
last post sent: 0 0 356
last post sent-location: kxfp.h LINE:4561 ID:kxfprienq: slave
last process posted by me: c000001832b0b620 242 0
(latch info) wait_event=0 bits=50
holding (efd=10) c000001804617de8 Child parallel query alloc buffer level=6 child#=23
Location from where latch is held: kxfpb.h LINE:496 ID:kxfpbalo: allocate a buffer
Context saved from call: 13835058152010268280
state=busy [holder orapid=664
|