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
如何选择level?
一般来说,不建议使用3以上级别的hang分析,因为可能会产生非常大的trace,还可能对系统的IO有一定影响。
从oracle 9i开始 hanganalyze提供给了对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一样,除非没有依赖对象。
本节我基于scott用户产生两个会话,模拟死锁会话(一个update,一个delete)
SQL> oradebug help
HELP [command] Describe one or all commands
SETMYPID Debug current process
SETOSPID Set OS pid of process to debug
SETORAPID ['force'] Set Oracle pid of process to debug
SHORT_STACK Dump abridged OS stack
DUMP <dump_name>[addr] Invoke named dump
DUMPSGA [bytes] Dump fixed SGA
DUMPLIST Print a list of available dumps
EVENT Set trace event in process
SESSION_EVENT Set trace event in session
DUMPVAR <p|s|uga>[level] Print/dump a fixed PGA/SGA/UGA variable
DUMPTYPE
SQL> oradebug hanganalyze 3;
Hang Analysis in /oracle/admin/orcl/udump/orcl_ora_2622.trc
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
-bash-3.2$ more /oracle/admin/orcl/udump/orcl_ora_2622.trc
/oracle/admin/orcl/udump/orcl_ora_2622.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: truerhel5
Release: 2.6.18-164.el5
Version: #1 SMP Tue Aug 18 15:51:48 EDT 2009
Machine: x86_64
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 2622, image:oracle@truerhel5(TNS V1-V3)
*** SERVICE NAME:(SYS$USERS) 2010-08-07 21:11:10.818
*** SESSION ID:(145.36) 2010-08-07 21:11:10.818
*** 2010-08-07 21:11:10.818
==============
HANG ANALYSIS:
==============
Open chains found:
Chain 1 : : --每列的注解:分为cnode sid sess_srno proc_ptr ospid wait_event
<0/148/27/0x70e5e4a8/2543/SQL*Net message from client> --会话148(持锁会话)
-- <0/146/84/0x70e5f478/2607/enq: TX - row lock contention> --会话146(等待锁会话),竞争事件为:row lock contention
Other chains found:
Chain 2 : :
<0/144/108/0x70e5ccf0/2614/jobq slave wait>
Chain 3 : :
<0/145/36/0x70e5fc60/2622/No Wait>
Chain 4 : :
<0/150/2/0x70e623e8/2338/Streams AQ: waiting for time man>
Chain 5 : :
<0/151/1/0x70e5ec90/2319/Streams AQ: qmn coordinator idle>
Chain 6 : :
<0/158/7/0x70e61c00/2336/Streams AQ: qmn slave idle wait>
Extra information that will be dumped at higher levels:
[level 4] : 1 node dumps -- [REMOTE_WT] [LEAF] [LEAF_NW]
[level 5] : 5 node dumps -- [SINGLE_NODE] [SINGLE_NODE_NW] [IGN_DMP]
[level 6] : 1 node dumps -- [NLEAF]
[level 10] : 13 node dumps -- [IGN]
State of nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor):
[143]/0/144/108/0x70f5dcf8/2614/SINGLE_NODE/1/2//none
[144]/0/145/36/0x70f5f130/2622/SINGLE_NODE_NW/3/4//none
[145]/0/146/84/0x70f60568/2607/NLEAF/5/8/[147]/none
[147]/0/148/27/0x70f62dd8/2543/LEAF/6/7//145
[149]/0/150/2/0x70f65648/2338/SINGLE_NODE/9/10//none
[150]/0/151/1/0x70f66a80/2319/SINGLE_NODE/11/12//none
[154]/0/155/1/0x70f6bb60/2315/IGN/13/14//none
[155]/0/156/1/0x70f6cf98/2313/IGN/15/16//none
[157]/0/158/7/0x70f6f808/2336/SINGLE_NODE/17/18//none
[159]/0/160/1/0x70f72078/2305/IGN/19/20//none
[160]/0/161/1/0x70f734b0/2303/IGN/21/22//none
[161]/0/162/1/0x70f748e8/2301/IGN/23/24//none
[162]/0/163/1/0x70f75d20/2299/IGN/25/26//none
[163]/0/164/1/0x70f77158/2297/IGN/27/28//none
[164]/0/165/1/0x70f78590/2295/IGN/29/30//none
[165]/0/166/1/0x70f799c8/2293/IGN/31/32//none
[166]/0/167/1/0x70f7ae00/2291/IGN/33/34//none
[167]/0/168/1/0x70f7c238/2289/IGN/35/36//none
[168]/0/169/1/0x70f7d670/2287/IGN/37/38//none
[169]/0/170/1/0x70f7eaa8/2285/IGN/39/40//none
====================
END OF HANG ANALYSIS
====================
其内容意思大概如下
cnode--节点代号,如果为rac,其值就存在,单节点的值为0
sid---session的sid
sess_srno---session的serial#
proc_ptr--系统进程指向的address
ospid ----进程号
wait_event---session的等待事件
转摘白大师部分节选
Hanganalyze是从Oracle 8i r2(8.1.6)开始提供的,其用法十分简单:
ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level ';
或者
ORADEBUG hanganalyze
比如:
sql>oradebug setmypid;
sql>oradebug hanganalyze 3;
对于:
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
-bash-3.2$ sqlplus -prelim '/as sysdba' --通过prelim选项进入已经hang住(正常方式进不了sqlplus)的数据库
SQL*Plus: Release 10.2.0.1.0 - Production on Sat Aug 7 21:17:42 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> show parameter sga
ORA-01012: not logged on
SQL> conn /as sysdba
Prelim connection established
SQL>
http://blog.itpub.net/16978544/viewspace-701657/