大量的library cache：mutex X

gdpr-dba

今天早上数据库突然hung住，用户投诉前台无法登陆，在em性能页中查看，发现有大量的library cache：mutex X，其中这条语句尤为严重：
select
privilege#
from
sysauth$
where
(grantee#=:1
or
grantee#=1)
and
privilege#>0


执行计划如下：

操作	对象	顺序	行	字节	成本	CPU (%)	时间	查询块名称/对象别名	谓词	投影
SELECT STATEMENT		3			2	100
INLIST ITERATOR		2						SEL$1		"PRIVILEGE#"[NUMBER,22]
INDEX RANGE SCAN	I_SYSAUTH1	1	3	24	2	0	0:0:1	SEL$1 / SYSAUTH$@SEL$1	(("GRANTEE#"=:1 OR "GRANTEE#"=...	"GRANTEE#"[NUMBER,22], "PRIVIL...

执行统计信息

总计 每次执行 每行 执行数 2,987,942 1 0.43 用时 (秒) 829.03 <0.01 <0.01 CPU 时间 (秒) 475.94 <0.01 <0.01 缓冲区获取数 18,945,215 6.34 2.71 磁盘读取数 4 <0.01 <0.01 直接写入数 0 0.00 0.00 行数 6,994,106 2.34 1 提取数 9,982,084 3.34 1.43

数据库版本是11.2.0.3，平台是windows 2008。

按我对library cache：mutex X的理解，应该是有硬解析才会持有mutex X吧，可以看出这里的基本都是软解析，怎么会导致严重的library cache：mutex X等待呢？

[ 本帖最后由 gdpr-dba 于 2012-4-6 10:02 编辑 ]

gdpr-dba

发现这个论坛我都贴不了图片，而且格式有点乱，不管了~~

gdpr-dba

补充一下共享游标统计信息

分析总数  2,987,674
硬分析数  3
子游标  2
加载的计划  2
失效数  0
游标最大大小 (KB)  21.01
所有游标大小 (KB)  41.98
首次加载时间  2012-3-19 9:25:45 (UTC+08:00)
上次加载时间  2012-4-2 22:01:01 (UTC+08:00)

Maclean Liu(刘相兵

Action Plan:

1. library cache：mutex X==> 这应当是 版本 11g吧

2. 上传问题时段的AWR报告

3. 压缩后打包上传问题时段的diag、SMON、PMON进程的TRACE文件

gdpr-dba

刘大，awr报告已上传，帮忙看看，谢谢。

Maclean Liu(刘相兵

11.2.0.3.0  RAC=Yes         Microsoft Windows x86 64-bit  22.32 (mins)


Top 5 wait event

Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
latch: row cache objects        1,679        49,760        29636        68.71        Concurrency
library cache: mutex X        1,474        3,281        2226        4.53        Concurrency
latch: shared pool        5,031        2,642        525        3.65        Concurrency
DB CPU                 1,051                 1.45         
cursor: pin S wait on X        23        503        21883        0.69        Concurrency


Parses:        36.7        28.3                  
Hard parses:        2.0        1.5           ==> 硬解析并不多



Statistic Name        Time (s)        % of DB Time
connection management call elapsed time        15,532.90        21.45
parse time elapsed        9,567.86        13.21
hard parse elapsed time        5,583.33        7.71


connection management call  连接和  parse time  解析 消耗了主要的DB TIME，可能发生了hang


latch: row cache objects

row cache objects        kqreqd: reget        0        593        16
row cache objects        kqreqd        0        109        26
row cache objects        kqrpre: find obj        0        84        791




library cache: mutex X

Library Cache        kglhdgn2 106        229,842        0
Library Cache        kgllkdl1 85        79,591        0



shared pool        8,192.00        8,192.00        7,808.00        8,320.00        0        GRO/DEF
shared        KGLH0        1,507.44        1,387.50        -7.96
shared        KGLHD        225.81        209.78        -7.10
shared        SQLA        4,208.33        3,671.65        -12.75
shared        free memory        1,348.55        2,026.77        50.29


shared pool  的free memory 从 1,348 上升到 2026MB ，其中SQLA和 KGLHD (kgl handle)、KGLH0 (kgl heap 0) 使用量发生过下降


是否有人在这段时间中 flush 过shared POOL?

memory_target        22548578304
shared pool =8g

gdpr-dba

谢谢刘大，应该没有flush过share pool，因为只有我一个dba，我没做过应该就没有其他人做过了。如果是单纯的高并发的软解析会造成library cache：mutex X吗？

Maclean Liu(刘相兵

"如果是单纯的高并发的软解析会造成library cache：mutex X吗？"

还是有可能的， 但是可以观察AWR发现 问题时段的 软硬解析的频率远未达到水平。