数据库HANG是十分严重的故障，对DBA具有一定的挑战性。系统HANG或者出现一些致命性的故障，那么DBA的第一工作要旨是尽快恢复系统运行。其次是要搞清楚系统故障的原因。本文老白介绍几个常用的分析工具的使用方法，并通过一个小例子介绍如何使用工具进行分析。
1. 几个主要分析工具及使用方法
HANGANALYZE
$sqlplus‘/as sysdba’
SQL>ORADEBUGSETMYPID
SQL>ORADEBUGHANGANALYZE 3
SYSTEMSTATE DUMP
$sqlplus‘/as sysdba’
SQL>ORADEBUGSETMYPID
SQL>ORADEBUG DUMP SYSTEMSTATE <LEVEL>
level一般可以用10,如需要诊断详细的信息，可以使用266
10046 TRACE
$sqlplus ‘/as sysdba’
SQL>alter system set events ‘10046trace name context forever,level <level>;
一般情况下level 10可以满足绝大多数诊断需求。
tusc/truss/pstack等诊断进程的系统调用
通过tusc,truss,pstack等工具观察故障进程的堆栈调用
v$active_session_history
如果是事后分析数据库出现HANG的情况，那么通过ASH数据也是一种十分有效的方法。
强制登录数据库
当数据库HANG住时，可以使用sqlplus –prelim参数强制登录数据库，登录的会话只能做hanganalyze,systemstatedump等操作，不能执行SQL。
2. 分析路线图
1、首先检查alert log，udump下的trace等，查看是否有异常。如果发现数据库日志中存在ORA-600/ORA-7445或者其他明显的故障，则要分析这些是不是导致HANG的原因。通过ls -lrt查看alert log和前台后台进程的trc文件，对于在HANG的时候（如果是当前，则可以看最新的时段）有日志输出的前台和后台进程，trc文件要特殊关注。特别是diag、pmon、nmon、lms/lmd等的trc文件。
2、检查操作系统日志等，是否存在异常
3、检查物理内存,swap使用率等，排除swap满导致的问题
4、检查文件句柄，进程数是否满
5、使用top/topas,ps 等命令查看是否存在异常
6、使用sar –d命令查看IO情况
7、做hanganalyze，查看是否存在HANG住的现象
8、对故障的会话做10046 trace，分析该会话是否存在异常等待事件
9、使用tusc/truss/pstack等工具查看系统调用的情况
10、做一份SYSTEMSTATE DUMP（10级或者更高）
3. 举例
sqlplus "/as sysdba"
sql>oradebug setmypid
sql>oradebug hanganalyze 3
Hang Analysis in/oracle/app/oracle/admin/acct/udump/ora_7054_acct.trc
打开这个文件，发现：
Found 36 objects waiting for<sid/sess_srno/proc_ptr/ospid/wait_event>
<153/8226/0xbd414b0/25567/enqueue>
Cycle 1 :<sid/sess_srno/proc_ptr/ospid/wait_event> :
<61/60457/0xbcd9640/29261/library cache lock>
--<153/8226/0xbd414b0/25567/enqueue>
61号会话等待library cachelock，导致153号会话被锁死，153号会话的锁，阻塞了36个对象的等待请求
通过v$session发现61号会话是c2b recv进程，杀掉该进程就可以恢复正常
