奇怪的library cache lock和cursor: mutex

runinwind

我们客户一个DB，以前运行还算正常，现在连续2个周一宕机，故障现象是正常业务时突然迅速涌现几百个cursor: mutex S和latch free等待，但是从dba_hist_active_session_history中看到最初是从1分钟内出现几百个library cache lock开始的，而且session都在等待同一个session，这个session正在运行的SQL很简单，平时是不会堵塞的。然后2分钟内这些library cache lock全变成了cursor: mutex S。我对这块的原理不是很清楚，不知道DB到底怎么了，附上awr报告，请各位老大帮忙分析一下。

psufnxk2000

SQL AREA        239,693        36.45        38,617,607        0.22        26,157        24,859

是不是有什么ddl的操作

runinwind

psufnxk2000 发表于 2013-4-15 23:32
SQL AREA        239,693        36.45        38,617,607        0.22        26,157        24,859

是不是有什么ddl的操作

这个是生产库，当时没有已知的DDL操作

Stone

Foreground Wait Class

Wait Class	Waits	%Time -outs	Total Wait Time (s)	Avg wait (ms)	%DB time
Concurrency	22,538,878	100	856,458	38	90.80
DB CPU			23,726		2.52

Foreground Wait Events

Event	Waits	%Time -outs	Total Wait Time (s)	Avg wait (ms)	Waits /txn	% DB time
cursor: mutex S	22,522,392	100	841,696	37	491.20	89.24
latch free	62,543	0	15,498	248	1.36	1.64

从AWR可以看到基本上数据库的主要负载在大量的并发,占到90.80% DB time，造成大量的“cursor: mutex S”，占到89.24% DB time。所以这两个数据还是基本上匹配的。

Operating System Statistics - Detail

Snap Time	Load	%busy	%user	%sys	%idle	%iowait
15-Apr 15:00:46	2.78
15-Apr 16:00:45	1,031.79	43.01	38.65	4.25	56.99	3.91

另外主机的负载疯狂飙升3 -> 1,031.79，所以机器崩溃也就不足为怪啦。

根据Oracle官方对这个Event的描述，这个等待的原因主要是因为有别的session正在以exclusive(排斥)的模式持有被需要的cursor。
所以具体分析这个/这些session，找到什么原因造成如此大的并发，特别是跟其他正常时段相比。那么解决问题应该也就不远啦。
cursor: mutex SA session waits on this event when it is requesting a mutex in shared mode, when another session is currently holding a this mutex in exclusive mode on the same cursor object.

当然也可以对问题时段做一个ash报告，具体锁定问题语句，和应用一起沟通下，共同解决问题。

还有就是在问题时间段的数据库硬解析特别高，可以找到相关的语句，分析一下，什么原因，比如说没有绑定变量之类的。

Good luck :)

dla001

SGA breakdown difference   
KGH: NO ACCESS
这个东西真够大的。查一下相关的信息吧。