一次数据库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现象。