以前在11g上碰到过一次类似的情况,由于ALTER SYSTEM KILL SESSION导致资源被完全占用,在一段时间内数据库处于HANG住状态。这次又碰到类似的问题。
简单描述一下问题产生的环境,用户在进行测试,在很短的时间内连续启动了多个应用服务器,导致大量的并发进程同时连接到数据库中,致使数据库服务器CPU利用率一下冲到100%。
由于数据库的这种状态,用户决定中止一些进程来释放服务器上的资源。但是通过kill -9和alter system kill session杀掉大量的会话后,数据库服务器反而处于HANG死状态,这时连sqlplus / as sysdba都无非正常登录。
于是用户继续通过kill -9清除所有非本地连接,到最后所有连接到数据库的非本地连接已经完全被杀掉,而服务器上的CPU资源已经下降,只有Oracle的PMON进程占用了单CPU的50%左右,其他CPU完全空闲。可是此时数据库仍然无非正常登录。
此时只能通过sqlplus –prelim “/ as sysdba”方式登录,然后利用oradebug执行systemstate的dump,查看导致数据库HANG死的原因。
检查SYSTEMSTATE的DUMP文件,发现PMON进程和大量的DEAD进程都在经历library cache: mutex X等待事件。而整个DUMP文件中library cache: mutex X等待事件出现了3000多次。这个等待事件是不正常的。
查询MOS发现果然是bug:Bug 9312879 “library cache: mutex x” waits after killing sessions / PMON slow to clean up。在11.1中,如果会话在KILL,那么PMON进程可能在清除进程会话是出现异常,导致清除进程失败后不断尝试,并最终产生这个问题。
这个BUG在11.2.0.1和11.1.0.7.7中被fixed,而Oracle对于这个问题的临时解决方案是不要kill会话。看来11.1版本和11.2相比确实是问题更多一些。
-
Recent Posts
Recent Comments
- yangtingkun on 非空字段空值对查询的影响
- Eric Zong on 非空字段空值对查询的影响
- Kamus on Oracle Ace Director
- 设置全局死锁优先级 | yangtingkun on RAC全局死锁检测时间
- ORA-600(krbounotread_noctx)错误 | yangtingkun on ORA-600(krboReadBitmap_badbitmap)错误
Archives
- December 2020
- February 2019
- December 2018
- November 2018
- October 2018
- July 2018
- June 2018
- May 2018
- July 2016
- July 2013
- June 2013
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
Categories
Meta