latch: library cache等待

gll1989

系统：HP-UX B.11.31 oracle数据版本 10.2.0.1.0
生产库在10点半左右hang住了，导致应用系统进不了。经过7-8分钟后系统正常
通过AWR看到
1、硬解析占用5%
2、软解析比较严重
跟平时时间段比较，也是这个情况，但latch: library cache等待不严重。
通过ASH看到
92npf1g0x6n0r、b33v5stbh62kf这两个SQL，具体的SQL语句已经看不到了


还有做了oradebug dump library_cache 10，这个两个SQL内容
92npf1g0x6n0r、b33v5stbh62kf通过什么方式可以查询出来，可否通过DBA_HIST_ACTIVE_SESS_HISTORY和library_cache跟踪日志中查询出来，它们是如何关联

请各位老大帮忙分析一下：上传了AWR和ASH。

Maclean Liu(刘相兵

Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
latch: library cache         334,217         24,117         72         29.8        Concurrency
cursor: mutex X         38,692,704         16,522         0         20.4        Concurrency
library cache pin         102,178         11,803         116         14.6        Concurrency
kksfbc child completion         136,565         8,066         59         10.0        Other
CPU time                  3,423                  4.2         



Parses:         1,069.80         74.53
Hard parses:         52.34         3.65

Soft Parse %:         95.11

10.2.0.1.0

sga_target        12582912000

library cache        kglpndl: child: before processing        0        86,065        99,134
library cache        kglpin: child: heap processing        0        56,377        65,921
library cache        kglhdgc: child:        0        48,049        43,455
library cache        kglhdgn: child:        0        23,728        36,067
library cache        kglobpn: child:        0        19,261        28,254
library cache        kgldti: 2child        0        18,842        9,883
library cache        kglpnp: child        0        10,908        13,980
library cache        kglrtl        0        5,377        2,814
library cache        kglpndl: child: after processing        0        5,130        877
library cache        kglobld        0        5,001        6,504
library cache        kglpnc: child        0        2,768        3,624
library cache        kglpin        0        2,092        1,317
library cache        kglpur: child        0        2,015        4,500
library cache        kglukp: child        0        1,636        1,906
library cache        kgldte: child 0        0        1,403        2,097

Maclean Liu(刘相兵

SQL AREA        7,256        97.66        1,454,134        3.79        40,781        4

sql area purged        18,016        19.63        1.37

shared        free memory        626.80        691.05        10.25

Maclean Liu(刘相兵

SQL AREA 发生过较大量的reload，而 shared pool的free memory出现过 626 到691的上升， 由于10.2.0.1 中AWR没有SGA component resize的环节，我们参考 Report Summary Cache Sizes 假定 没法发生过granule transfer， 那么很有可能是因为大量硬解析 导致 shared pool 碎片过多 ，需要age out 部分SQL AREA，导致SQL AREA导致 出现 大量解析等待


action plan:

1、 10.2.0.1 不该是 现在还在用的版本了
2、 考虑不要用ASMM SGA_TARGET
3、 减少硬解析，否则shared pool碎片问题是解决不了的， 要么用cursor_sharing=FORCE

ziyoo0830

mark 一下。。。

gll1989

谢谢刘大的指导