hanganalyze理解

1. 数据库hang的几种可能性
oracle死锁或者系统负载非常高比如cpu使用或其他一些锁等待很高都可能导致系统hang住，比如大量的DX锁。
通常来说，我们所指的系统hang住，是指应用无响应，普通的sqlplus几乎无法操作等等。
2. 如何进行hang分析？hang分析有哪些level？如何选择level？

我们知道当一个数据库hang住时,最头痛的问题是无法登陆数据，也就无法进行故障的处理,因此很多人只能通过重启
操作系统来讲解决问题，其实从Oracle 10g开始,Oracle提供了prelim的登陆方式，如下:
sqlplus -prelim / as sysdba
oradebug setospid <process ID>
oradebug unlimit
oradebug dump systemstate 10


数据库hanganalyze级别含义：
hanganalyze有如下几种level：
10     Dump all processes (IGN state)
 5      Level 4 + Dump all processes involved in wait chains (NLEAF state)
 4      Level 3 + Dump leaf nodes (blockers) in wait chains (LEAF,LEAF_NW,IGN_DMP state)
 3      Level 2 + Dump only processes thought to be in a hang (IN_HANG state)
 1-2    Only HANGANALYZE output, no process dump at all


从上面的信息看,在进行hanganalyze dump时有多种级别的level可以选择，那么如何选择level？一般来讲,不建议使用level 3以上的操作,因为产生的trace可能会很大,尤其是大型的OLTP系统;
另外一般数据库hang住时可能系统压力都巨大,所以再产生很大的trace可能导致问题更加严重。


从oracle 9i开始hangalanyze 操作提供了针对Oracle RAC的支持,有如下2种方式：
1) ALTER SESSION SET EVENTS ‘immediate trace name HANGANALYZE level <level>’;

2) ORADEBUG

针对rac的用法

ORADEBUG setmypid

ORADEBUG setinst all

ORADEBUG -g def hanganalyze <level>      

对于单实例，我们通常进行如下操作即可:
oradebug setmypid
oradebug hanganalyze 3

oradebug setmypid
oradebug unlimit
oradebug setinst all   --RAC环境
oradebug hanganalyze 3  -- 级别一般指定为3足够了
oradebug -g def dump systemstate 10  --RAC环境系统状态
oradebug tracefile_name


其次在做hang分析的时候,建议同时做一个systemstate dump或针对个别的process进行processstate dump,如下：

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.


---dump 整个操作系统的状态
---systemstate dump
oradebug setmypid
oradebug unlimit
oradebug dump systemstate   2;
oradebug -g def dump systemstate 10  --RAC环境
oradebug close_trace
oradebug tracefile_name
 

--根据操作系统进程追踪
---processstate dump
oradebug setospid xxxx
或者ORACLE SID，它们是一样的：
oradebug setorapid 18   --根据Oracle ID
oradebug dump processstate  3;
oradebug close_trace

oradebug trace file_name

获取某进程的状态信息
   oradebug setospid 22180
   oradebug dump processstate 10
   oradebug tracefile_name

获取进程错误信息状态
   oradebug setospid 22180
   oradebug dump errorstack 3

----根据要update语句或者sid 找到要跟踪的进程，例如存在锁的情况，可以根据阻塞的sql来生成spid
select p.spid
from v$session s,v$process p,v$sqlarea c
where s.username is not null and s.PADDR=p.ADDR and s.sql_id=c.sql_id
and s.sql_fulltext like'%UPDATE t_config_info%'
SPID

在另一个会话中执行下面的语句
SQL> oradebug setospid SPID
SQL> oradebug unlimit
SQL> oradebug dump processstate 10
SQL> oradebug tracefile_name

---查看oradebug 的帮助
SQL> oradebug help
SQL> oradebug dumplist

数据库hanganalyze 参数解析：
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 

接着解释一下比较重要的一些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：近似于空闲会话

参考：

http://blog.csdn.net/tianlesoftware/article/details/6321961

http://www.killdb.com/2014/01/23/about-oracle-hanganalyze.html

http://www.cnblogs.com/kerrycode/p/5236927.html