1. 数据库hang的几种可能性

oracle 死锁 或者系统负载非常高比如cpu使用或其他一些锁等待很高都可能导致系统hang住，比如大量的DX锁。
通常来说，我们所指的系统hang住，是指应用无响应，普通的sqlplus几乎无法操作等等。

2. 如何进行hang分析？hang分析有哪些level？如何选择level？

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

2、10G下sqlplus -prelim

如果10G，可以使用sqlplus -prelim选项强制登录

export ORACLE_SID=ora9
sqlplus -prelim '/ as sysdba'
oradebug setmypid
oradebug unlimit;
oradebug dump systemstate 10

如何选择level？

一般来说，不建议使用3以上级别的hang分析，因为可能会产生非常大的trace，还可能对系统的IO有一定影响。
从oracle 9i开始 hangalanyze提供给了对rac的支持。

有如下2种方式：

1) ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level ';

2) 使用oradebug 命令

ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze ---针对rac的用法

oradebug setmypid
oradebug hanganalyze 3 ---非rac环境

通常在做hang分析的时候，oracle建议同时做一个systemstate的dump

oradebug SYSTEMSTATE dump level 2 level 2即可， 包含了所有session的信息。

sqlplus -prelim / as sysdba ---10g可以使用此方式登录
oradebug setospid
oradebug unlimit
oradebug dump systemstate 10

补充：有时候我们可能还需要对某个进程进行trace aix环境，我们可以使用dbx命令

如下例子：

dbx -a PID (where PID = any oracle shadow process) ---通过ps -ef|grep xxx查看
dbx() print ksudss(10)
dbx() detach

3. 如何解读hang分析的trace文件，获取有用信息?

* ACTION NAME:() 2010-03-12 00:04:01.497
* MODULE NAME:(sqlplus@S7_C_YZ_YZSJK (TNS V1-V3)) 2010-03-12 00:04:01.497 ---模块名 跟v$session.module_name一样
* SERVICE NAME:(SYS$USERS) 2010-03-12 00:04:01.497
* SESSION ID:(5184.45287) 2010-03-12 00:04:01.497 ----sid (5184) serial# (35287)

* 2010-03-12 00:04:01.497

HANG ANALYSIS:

Found 54 objects waiting for
<0/5210/10419/0x99d0a88/11215038/No Wait> ------从这里看 session 5210 阻塞了54个对象
Open chains found:
Chain 1 : : ---从这里开始 以下的session都是被前面的5210阻塞 通常来说是一个阻塞另一个
<0/5210/10419/0x99d0a88/11215038/No Wait>
-- <0/3994/15494/0xd9ac1b0/6574102/enq: TM - contention>
-- <0/4962/58962/0xca03618/5710044/enq: DX - contention>
Other chains found: ---下面的session也是被前面所阻塞 不过不是直接阻塞（by Open chains） 间接阻塞
Chain 2 : :
<0/4001/31548/0xf9f3ab0/4980956/enq: DX - contention>
Chain 3 : :
<0/4014/30717/0xaa27b48/7446746/gc buffer busy>
Chain 4 : :
<0/4039/42115/0xd9f5710/5595180/PX Deq: Table Q Normal>

Cycle 1 : : ---cycle 通常是死锁 一般来说很有可能就是hang的根源
<980/3887/0xe4214964/24065/latch free>
-- <2518/352/0xe4216560/24574/latch free>
-- <55/10/0xe41236a8/13751/latch free>

4. 不同版本hang分析的差异？trace有何异同？

如下是oracle8~10g的 hanganalyze trace信息格式：

Oracle 8.x : [nodenum]/sid/sess_srno/session/state/start/finish/[adjlist]/predecessor
Oracle9i: [nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor
Oracle10g：[nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor

Nodenum --》 每个session做hanganalyze生成的一个序列号
sid --》 Session ID
sess_srno --》 Serial#
ospid --》 OS Process Id (v$process spid)
state --》 State of the node
adjlist --》 adjacent node (Usually represents a blocker node) --通常是阻塞者
predecessor --》 predecessor node (Usually represents a waiter node) --通常是被阻塞者
cnode --》 节点号 从9i开始才有

关于state 有如下几种值:

IN_HANG --》 该状态是一个非常危险的状态，通常表现为一个节点陷入了死循环或是hung。 一般来说出现这种情况，该节点的临辟节点也是一样的状态 即adjlist

如下例子：
[16]/0/17/154/0x24617be0/26800/IN_HANG/29/32/[185]/19 ---从IN_HANG 我们可以看出 185是16的邻居节点，185被16阻塞
[185]/1/16/4966/0x24617270//IN_HANG/30/31/[16]/16 ---从这里看 185阻塞了16（16是waiter）

LEAF --》通常是被认为blockers的重点对象。那么如何去确定呢？ 一般来说，根据后面的predecesor来判断该session是不是blocker或者是waiter。

如下例子：
[ nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor
[16]/0/17/154/0x24617be0/26800/LEAF/29/30//19 --从这里看19是waiter 因此我们认为17阻塞了20
[19]/0/20/13/0x24619830/26791/NLEAF/33/34/[16]/186

LEAF_NW --》 跟leaf类似 不过可能会占用cpu
NLEAF --》该状态的session通常被认为 “stuck” session。即其他session所需要的资源正被其holding。
IGN --》该状态的session通常是处理IDLE状态，除非其adjlist存在，如果是，那么该session正在等待其他session。
IGN_DMP --》跟 IGN 类似。

如下例子：

[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
[189]/1/20/36/0x24619830//IGN/95/96/[19]/none
[176]/1/7/1/0x24611d80//IGN/75/76//none

----从上面看，189在等待19,19在等待16，而176是一个idle session。

SINGLE_NODE，SINGLE_NODE_NW 可以认为跟LEAF，LEAF_NW一样，除非没有依赖对象。