11GR2 奇怪的library cache: mutex X 严重争用

kerlion · 发表于 2012-2-28 17:25

搞笑的metalink这样说的：
Workaround:
The only workaround is to set optimizer_secure_view_merging=false
which may not be acceptable in many cases.

Karsus · 发表于 2012-2-28 17:52

好像有点类似，
NND, 我先改了试试看。

Yong Huang · 发表于 2012-2-28 23:20

You must be referring to "Bug 12679678 : CURSOR: MUTEX S, LIBRARY CACHE LOCK AND CURSOR: PIN S WAIT ON X WITH JAVA PROCE". But the bug report clearly says "We tried the workaround of setting optimizer_secure_view_merging=false but this did not help."

There're lots of articles about library cache: mutex X contention. Read more before you draw a conclusion.

Yong Huang

sundog315 · 发表于 2012-2-29 08:08

本帖最后由 sundog315 于 2012-2-29 08:11 编辑

不见得就是这个BUG

建议还是多查查support.oracle.com。library cache: mutex X的相关BUG挺多的。

可以参考这篇文章
Troubleshooting: Waits for Mutex Type Events [ID 1377998.1]

Karsus · 发表于 2012-2-29 19:06

刚刚重启了DB, 发现一件奇怪的事, 关闭DB后glance里还能看到几个Oracle的Dedicated进程，但ps -ef却看不见，kill -9也提示没有这个process.

kerlion · 发表于 2012-3-1 11:25

最后问题解决没有，是bug吗？希望有个结果

Karsus · 发表于 2012-3-1 14:11

找HP原厂问过了，glance和ps -ef的部分没有问题。
重启DB后，到目前为止一切正常，所以...很怪....

重启前在 x$kglob , v$mutex_sleep_history 的查询中，某个KGLxxxxxx下面那句SQL的sleep 确实是非常非常的大。

Karsus · 发表于 2014-7-9 12:53

实际上我觉得Oracle在high loading 的时候，Memory的管理有时就是会有那么点小问题，尤其是在应用还很混杂的情况下。
今年我又快迎接peak time了，但是DB的架构我按应用和业务进行了拆分改成了Multi DB的架构，部分逻辑拆到中间的AP层(主要是业务调度的管理)，这样每个DB的应用逻辑和SQL相对单纯，这部分在2013年改建完后，顺利度过了3倍2012的量。
不过2012是一套Superdome 2， 2013的新业务换成了3套BL870.

postgresql_user · 发表于 2014-7-27 16:08

Karsus 发表于 2012-2-29 19:06
刚刚重启了DB, 发现一件奇怪的事, 关闭DB后glance里还能看到几个Oracle的Dedicated进程，但ps -ef却看不见， ...

pmon未清理完

Yong Huang · 发表于 2014-8-9 11:54

Karsus, according to your message #18, you did an excellent job! Hope you can blog about it to give more details.

[讨论] 11GR2 奇怪的library cache: mutex X 严重争用

浏览过的版块