正德厚生,臻于至善

一次数据库hang住的分析过程

cat hang.sql 
--sqlplus /nolog
connect / as sysdba
oradebug setmypid
oradebug unlimit
oradebug hanganalyze 3
wait 90 seconds
oradebug hanganalyze 3
oradebug tracefile_name

原文链接:https://www.cnblogs.com/abclife/p/5381755.html

现象:
  普通用户和sysdba都无法登陆,业务中断

分析过程:
1.先做hanganalyze和systemstate dump
$ sqlplus -prelim "/as sysdba"
SQL> oradebug setmypid
Statement processed.
SQL> oradebug hanganalyze 3
Statement processed.
SQL> oradebug hanganalyze 3
Statement processed.
SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/db11/db11/trace/db11_ora_2495.trc
SQL>

2.分析trace文件


有76个会话被会话494阻塞了,而会话494在等待shared pool…
会话494,496,519之间可能相互独立,也可能存在互相阻塞的关心。

继续分析日志:


”adjlist“表示nodenum,所以会话494被会话598阻塞,会话496也被会话597阻塞
所以进程号553382、sid=598的会话就是数据库hang住时的阻塞源头

会话598在做什么,需要从systemstate dump中做分析,但是系统重启前没有做systemstate dump分析。

因为oracle中的进程要么是前台进程,要么是后台进程,在oracle启动的时候,会记录后台进程的进程id号,

从alter日志中发现:


根据MMAN进程猜测与动态调整SGA有关。关闭动态SGA管理后,系统恢复正常,不再有hang现象。

赞(0) 打赏
未经允许不得转载:徐万新之路 » 一次数据库hang住的分析过程
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

联系我们

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏