Oracle教程学习之使用Hanganalyze诊断Oracle故障及等待事件(oradebug)
Oracle教程学习之使用Hanganalyze诊断Oracle故障及等待事件(oradebug)
客户突然报障说系统比较慢，登录Oracle数据库服务器查看系统资源非常忙，登录数据库发现非常卡，风哥现在介绍一下使用Oracle Hanganalyze来分析与诊断这个故障的过程
1、首先介绍一下为什么要使用Hanganalyze？
Hanganalyze工具使用内核调用检测会话在等待什么资源，报告出占有者和等待者的相互关系。另外，它还会将一些比较”interesting”的进程状态dump出来，这个取决于我们使用hanganalyze的分析级别。
Oracle 数据库“真的”hang住了，可以理解为数据库内部发生死锁。因为普通的DML死锁，oracle服务器会自动监测他们的依赖关系，并回滚其中一个操作， 终止这种相互等待的局面。而当这种死锁发生在争夺内核级别的资源（比如说是pins或latches）时，Oracle并不能自动的监测并处理这种死锁。
其实很多时候数据库并没有hang住，而只是由于数据库的性能问题，处理的时间比较长而已。
hanganalyze工具从oracle8i第二版开始提供，到9i增强了诊断RAC环境下的“集群范围”的信息，这意味着它将会报告出整个集群下的所有会话的信息。
2、hanganalyze基本的使用方法
目前有三种使用hanganalyze的方法:
一种是会话级别的：
fgedu.net@SQL>ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level ';
一种是实例级别:
fgedu.net@SQL>ORADEBUG hanganalyze
一种是Oracle RAC集群范围的：
fgedu.net@SQL>ORADEBUG setmypid
fgedu.net@SQL>ORADEBUG setinst all
fgedu.net@SQL>ORADEBUG -g def hanganalyze
各个level的含义如下：
1-2:只有hanganalyze输出，不dump任何进程
3：Level2+Dump出在IN_HANG状态的进程
4：Level3+Dump出在等待链里面的blockers(状态为LEAF/LEAF_NW/IGN_DMP)
5：Level4+Dump出所有在等待链中的进程（状态为NLEAF）
Oracle官方建议不要超过level 3，一般level 3也能够解决问题，超过level 3会给系统带来额外负担。
如果sqlplus不能登录,可以使用sqlplus -prelim /as sysdba登录操作。
3、风哥为大家讲解整个案例的分析过程
登录数据库：
fgedu.net@SQL> ORADEBUG setmypid
从上面可以看到sid 154锁住了141，所以只要将154 kill掉，141就可以继续执行了。
Kill掉154的session风哥推荐有两种办法：
1）alter system kill session ‘sid,serial#’;
fgedu.net@SQL> select s.sid,s.serial#,p.spid from v$process p,v$session s where p.addr=s.paddr and s.username='TEST1';
SID SERIAL# SPID
---------- ---------- ------------
141 14 9720
154 3 9544
fgedu.net@SQL> alter system kill session '154,3';
系统已更改。
2）杀进程
如果是windows:在DOC窗口下执行：orakill ORACLE_SID ospid
orakill TEST1 9544
如果是Unix或者linux下，那么就用kill -9 ospid
执行kill操作后：回到窗口A看到：通道结束
在窗口B看到成功删除。
4、关于HANGANALYZE的TRC文件中术语解释
sid是 Session ID
sess_srno是serial#
proc_ptr是Process Pointer
ospid 是OS Process ID
cnode是Node Id，Oracle9i才用
Nodenum是hanganalyze
自己为了记录这些会话而定制的编号，从0开始排起。
State 是node的状态
Adjlist是临近的node(通常代表一个blocker node)
Predecessor是Predecessor node ,通常代表一个 waiter node
State有如下几种状态：
IN_HANG：这表示该node处于死锁状态，通常还有其他node（blocker）也处于该状态
LEAF/LEAF_NW：该node通常是blocker。通过条目的”predecessor”列可以判断这个node是否是blocker。LEAF说明该NODE没有等待其他资源，而LEAF_NW则可能是没有等待其他资源或者是在使用CPU.
如下的实例说明了node16阻塞了node19的资源：
[nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor
[16]/0/17/154/0x24617be0/26800/LEAF/29/30//19
[19]/0/20/13/0x24619830/26791/NLEAF/33/34/[16]/186
NLEAF：通常可以看作这些会话是被阻塞的资源。发生这种情况一般说明数据库发生性能问题而不是数据库hang
IGN/IGN_DMP：这类会话通常被认为是空闲会话，除非其adjlist列里存在node。如果是非空闲会话则说明其adjlist里的node正在等待其他node释放资源。
SINGLE_NODE/SINGLE_NODE_NW：近似于空闲会话
5、Scripts-Hanganalyze and systemstate
sqlplus -prelim / as sysdba;
Hanganalyze and systemstate
$ sqlplus /nolog
connect / as sysdba
oradebug setmypid
oradebug unlimit
oradebug hanganalyze 3
wait 90 seconds
oradebug hanganalyze 3
exit
$ sqlplus /nolog
connect / as sysdba
oradebug setmypid
oradebug unlimit
oradebug dump systemstate 10
wait 90 seconds
oradebug dump systemstate 10
wait 90 seconds
oradebug dump systemstate 10
exit
Use level 266 where appropriate
Related articles
Note 61552.1 Diagnosing Database Hanging Issues
Note.215858.1 Interpreting HANGANALYZE trace files to diagnose hanging and performance problems
Note.423153.1 Understanding and Reading Systemstates
266: 256+10 -->short stack+ dump
--如果是-g all，代表RAC
systemstate dump有多个级别：
2: dump (不包括lock element)
10: dump
11: dump + global cache of RAC
256: short stack （函数堆栈）
258: 256+2 –>short stack +dump(不包括lock element)
266: 256+10 –>short stack+ dump
267: 256+11 –>short stack+ dump + global cache of RAC
level 11和 267会 dump global cache, 会生成较大的trace 文件，一般情况下不推荐。
一般情况下，如果进程不是太多，推荐用266，因为这样可以dump出来进程的函数堆栈，可以用来分析进程在执行什么操作。
但是生成short stack比较耗时，如果进程非常多，比如2000个进程，那么可能耗时30分钟以上。这种情况下，可以生成level 10 或者 level 258， level 258 比 level 10会多收集short short stack, 但比level 10少收集一些lock element data.