Hanganalyze 使用
It is important to find the that the reason hangs the database.
How can we do, is a headache thing. And we can use oracle internal tool to find the cause, which is hanganalyze.
Level of hanganalyze
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
How to use hanganalyze
Single node
ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level <level>';
ORADEBUG hanganalyze <level>
Rac:
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze <level> For example SQL> update test set empno=9999 where empno=7788; 1 row updated. Another session SQL> update test set empno=9111 where empno=7788;
SQL> oradebug setmypid
SQL> oradebug hanganalyze 3
Hang Analysis in /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_55.trc
The contents of /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_55.trc
Trace file /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_55.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
System name: SunOS
Node name: Solaris10
Release: 5.10
Version: Generic_142910-17
Machine: i86pc
Instance name: prod
Redo thread mounted by this instance: 1
Oracle process number: 33
Unix process pid: 55, image: oracle@Solaris10 (TNS V1-V3) *** 2013-08-05 03:33:20.007
*** SESSION ID:(34.21990) 2013-08-05 03:33:20.007
*** CLIENT ID:() 2013-08-05 03:33:20.007
*** SERVICE NAME:(SYS$USERS) 2013-08-05 03:33:20.007
*** MODULE NAME:(sqlplus@Solaris10 (TNS V1-V3)) 2013-08-05 03:33:20.007
*** ACTION NAME:() 2013-08-05 03:33:20.007 Processing Oradebug command 'hanganalyze 3' *** 2013-08-05 03:33:20.303
===============================================================================
HANG ANALYSIS:
instances (db_name.oracle_sid): prod.prod
oradebug_node_dump_level: 3
analysis initiated by oradebug
=============================================================================== Chains most likely to have caused the hang:
[a] Chain 1 Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'
Chain 1 Signature Hash: 0x38c48850
[b] Chain 2 Signature: 'Streams AQ: waiting for messages in the queue'
Chain 2 Signature Hash: 0xa00e2e87 ===============================================================================
Non-intersecting chains: -------------------------------------------------------------------------------
Chain 1:
-------------------------------------------------------------------------------
Oracle session identified by:
{
instance: 1 (prod.prod)
os id: 29878
process id: 32, oracle@Solaris10 (TNS V1-V3)
session id: 5
session serial #: 20196
}
is waiting for 'enq: TX - row lock contention' with wait info:
{
p1: 'name|mode'=0x54580006
p2: 'usn<<16 | slot'=0x4001e
p3: 'sequence'=0x430
time in wait: 1 min 20 sec
timeout after: never
wait id: 27
blocking: 0 sessions
current sql: update test set empno=9111 where empno=7788
short stack: ksedsts()+279<-ksdxfstk()+33<-ksdxcb()+928<-sspuser()+127<-__sighndlr()+6<-call_user_handler()+594<-sigacthandler()+238<-_syscall6()+27<-sskgp
wwait()+293<-ksliwat()+3146<-kslwaitctx()+147<-ksqcmi()+4000<-ksqgtlctx()+2538<-ksqgelctx()+590<-ktcwit1()+377<-kdddgb()+2953<-kdusru()+6214<-updrowFastPath()+1696<-qer
upFetch()+2551<-updaul()+1265<-updThreePhaseExe()+470<-updexe()+531<-opiexe()+9433<-kpoal8()+4217<-opiodr()+1087<-ttcpip()+1417<-opitsk()+1589<-opiino()+1777<-opiodr()+
1087<-opidrv()+858<-sou2o()+87<-opimai_re
wait history:
* time between current wait and wait #1: 0.005578 sec
1. event: 'Disk file operations I/O'
time waited: 0.000045 sec
wait id: 26 p1: 'FileOperation'=0x2
p2: 'fileno'=0x4
p3: 'filetype'=0x2
* time between wait #1 and #2: 0.005175 sec
2. event: 'SQL*Net message from client'
time waited: 1 min 42 sec
wait id: 25 p1: 'driver id'=0x62657100
p2: '#bytes'=0x1
* time between wait #2 and #3: 0.000002 sec
3. event: 'SQL*Net message to client'
time waited: 0.000002 sec
wait id: 24 p1: 'driver id'=0x62657100
p2: '#bytes'=0x1
}
and is blocked by
=> Oracle session identified by:
{
instance: 1 (prod.prod)
os id: 29867
process id: 35, oracle@Solaris10 (TNS V1-V3)
session id: 99
session serial #: 4407
}
which is waiting for 'SQL*Net message from client' with wait info:
{
p1: 'driver id'=0x62657100
p2: '#bytes'=0x1
time in wait: 1 min 37 sec
timeout after: never
wait id: 86
blocking: 1 session
current sql: <none>
short stack: ksedsts()+279<-ksdxfstk()+33<-ksdxcb()+928<-sspuser()+127<-__sighndlr()+6<-call_user_handler()+594<-sigacthandler()+238<-_read()+10<-sntpread(
)+28<-ntpfprd()+91<-nsbasic_brc()+411<-nioqrc()+718<-opikndf2()+763<-opitsk()+764<-opiino()+1777<-opiodr()+1087<-opidrv()+858<-sou2o()+87<-opimai_real()+541<-ssthrdmain
()+295<-main()+203<-_start()+108
wait history:
* time between current wait and wait #1: 0.000009 sec
1. event: 'SQL*Net message to client'
time waited: 0.000002 sec
wait id: 85 p1: 'driver id'=0x62657100
p2: '#bytes'=0x1
* time between wait #1 and #2: 0.001566 sec
2. event: 'db file sequential read'
time waited: 0.000022 sec
wait id: 84 p1: 'file#'=0x4
p2: 'block#'=0xab
p3: 'blocks'=0x1
* time between wait #2 and #3: 0.004235 sec
3. event: 'SQL*Net message from client'
time waited: 23.537121 sec
wait id: 83 p1: 'driver id'=0x62657100
p2: '#bytes'=0x1
} Chain 1 Signature: 'SQL*Net message from client'<='enq: TX - row lock contention'
Chain 1 Signature Hash: 0x38c48850
------------------------------------------------------------------------------- ===============================================================================
Sessions in an involuntary wait or not in a wait: -------------------------------------------------------------------------------
Chain 2:
-------------------------------------------------------------------------------
Oracle session identified by:
{
instance: 1 (prod.prod)
os id: 14055
process id: 39, oracle@Solaris10
session id: 222
session serial #: 38
}
is waiting for 'Streams AQ: waiting for messages in the queue' with wait info:
{
p1: 'queue id'=0x3037
p2: 'process#'=0x3ff4ed7e0
p3: 'wait time'=0x5
time in wait: 1.537508 sec
timeout after: 3.462492 sec
wait id: 206308
blocking: 0 sessions
current sql: <none>
short stack: ksedsts()+279<-ksdxfstk()+33<-ksdxcb()+928<-sspuser()+127<-__sighndlr()+6<-call_user_handler()+594<-sigacthandler()+238<-_syscall6()+27<-sskgp
wwait()+293<-ksliwat()+3146<-kslwait()+263<-kwqidexfcy()+1415<-kwqidsc81i()+2140<-kwqidrdq()+11126<-kwqidsfmp()+500<-kwqidafm0()+4246<-kwqididqx()+3562<-kpoaqdq()+2955<
-opiodr()+1087<-ttcpip()+1417<-opitsk()+1589<-opiino()+1777<-opiodr()+1087<-opidrv()+858<-sou2o()+87<-opimai_real()+541<-ssthrdmain()+295<-main()+203<-_start()+108
wait history:
* time between current wait and wait #1: 0.000182 sec
1. event: 'SQL*Net message from client'
time waited: 0.000325 sec
wait id: 206307 p1: 'driver id'=0x54435000
p2: '#bytes'=0x1
* time between wait #1 and #2: 0.000023 sec
2. event: 'SQL*Net message to client'
time waited: 0.000003 sec
wait id: 206306 p1: 'driver id'=0x54435000
p2: '#bytes'=0x1
* time between wait #2 and #3: 0.000665 sec
3. event: 'Streams AQ: waiting for messages in the queue'
time waited: 5.000056 sec
wait id: 206305 p1: 'queue id'=0x3037
p2: 'process#'=0x3ff4ed7e0
p3: 'wait time'=0x5
} Chain 2 Signature: 'Streams AQ: waiting for messages in the queue'
Chain 2 Signature Hash: 0xa00e2e87
------------------------------------------------------------------------------- ===============================================================================
Extra information that will be dumped at higher levels:
[level 4] : 1 node dumps -- [LEAF] [LEAF_NW]
[level 5] : 2 node dumps -- [NO_WAIT] [INVOL_WT] [SINGLE_NODE] [NLEAF] [SINGLE_NODE_NW] State of ALL nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[4]/1/5/20196/3ff5c8e40/29878/NLEAF/[98]
[98]/1/99/4407/3ff6d52a0/29867/LEAF/
[221]/1/222/38/3ff841aa8/14055/SINGLE_NODE/ *** 2013-08-05 03:33:20.311
===============================================================================
END OF HANG ANALYSIS
=============================================================================== *** 2013-08-05 03:33:20.312
===============================================================================
HANG ANALYSIS DUMPS:
oradebug_node_dump_level: 3
=============================================================================== State of LOCAL nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[4]/1/5/20196/3ff5c8e40/29878/NLEAF/[98]
[98]/1/99/4407/3ff6d52a0/29867/LEAF/
[221]/1/222/38/3ff841aa8/14055/SINGLE_NODE/ No processes qualify for dumping. ===============================================================================
HANG ANALYSIS DUMPS: END
=============================================================================== *** 2013-08-05 03:33:20.312
Oradebug command 'hanganalyze 3' console output:
Hang Analysis in /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_ora_55.trc
Hanganalyze 使用的更多相关文章
- How to hanganalyze and systemstate dumps
Oracle support request hang analysis and system state dumps when rasing SR. One 10.1 or higher versi ...
- 11g v$wait_chains 与 hanganalyze
11g之后,通过v$wait_chains视图诊断数据库hang和Contention 11g之前,通常我们数据库hang住了之后,我们会对数据库做hang analyze来进行分析,在11g之后 ...
- PMON failed to acquire latch, see PMON dump
前几天,一台Oracle数据库(Oracle Database 10g Release 10.2.0.4.0 - 64bit Production)监控出现"PMON failed to a ...
- Oracle Hang分析--转载
1. 数据库hang的几种可能性 oracle 死锁 或者系统负载非常高比如cpu使用或其他一些锁等待很高都可能导致系统hang住,比如大量的DX锁. 通常来说,我们所指的系统hang住,是指应用无响 ...
- Oracle systemstate dump介绍
当数据库出现严重的性能问题或者hang起的时候,那么我们非常需要通过systemstate dump来知道进程在做什么,在等待什么,谁是资源的持有者,谁阻塞了别人.在出现上述问题时,及时收集syste ...
- truncate表hang住（等待时间较长），出现enq：RO fast object reuse等待事件
有一个应用truncate表等待了一晚上,一个定时任务,跑了几年了,今天早上来发现昨晚没有执行完成,hang住了,查询发现等待事件 fast object reuse. 10.2.0.4的库 Bug ...
- oracle dump event
一.Memory Dumps 1).Global Area ALTER SESSION SET EVENTS 'immediate trace name global_area level n'; 1 ...
- Oracle Hang Manager
名词术语1.Cross Boundary Hang 交叉边界hang.在12.1.0.1中,hang manager可以检测database和asm之间的hang.2.Deadlock or Clos ...
- 一次数据库hang住的分析过程
现象: 普通用户和sysdba都无法登陆,业务中断 分析过程: 1.先做hanganalyze和systemstate dump $sqlplus -prelim "/as sysdba&q ...
随机推荐
- Hive技术文档
Hive是什么? Hive是蜂房的意思,为什么hadoop上的这层数据仓库叫Hive? 因为生物学上蜂房是一个结构相当精良的建筑,取名Hive足见则个数据仓库在数据存储上也是堪称精良的.Hive是Fa ...
- XSS 前端防火墙（2）：可疑模块拦截
由于是在前端防护,策略配置都能在源代码里找到,因此很快就能试出破解方案.并且攻击者可以屏蔽日志接口,在自己电脑上永不发出报警信息,保证测试时不会被发现. 昨天提到最简单并且最常见的 XSS 代码,就是 ...
- Excel的最大行数
使用Excel2007或Excel2010,在“另存为” 菜单中可以选择为“Excel 07-2003 工作薄”,从中我们可以看出,到了2007版以后,存储格式变了,简单一点从扩展名便可以看出,一个是 ...
- MYSQL性能查看（命中率,慢查询)
网上有很多的文章教怎么配置MySQL服务器,但考虑到服务器硬件配置的不同,具体应用的差别,那些文章的做法只能作为初步设置参考,我们需要根据自己的情况进行配置优化,好的做法是MySQL服务器稳定运行了一 ...
- Tesseract-OCR识别验证码
1. 安装Tesseract-OCR,安装后测试下是否安装成功
- 文件的压缩与解压XZip,XUnzip
参考http://www.codeproject.com/KB/cpp/xzipunzip.aspx CreateZip() –创建一个空的 zip 文件 HZIP CreateZip(void *z ...
- textBox只能输入汉字
private void textBox1_KeyPress(object sender, KeyPressEventArgs e) { if ((e.KeyChar > 0 && ...
- 事务处理: databse jdbc mybatis spring
事务的认识需要一个相当漫长的流程,慢慢在实践中理解,然后在强化相关理论基础. 数据库中的事务: 传统的本地事务处理都是依靠数据库自身事务处理能力,而事务本身是传统关系型数据库的基石.简单来说事务就是一 ...
- 耳机jack构造及在应用时可能出现的问题
目前市场上耳机分为4环耳机(图1所示,iphone型)和3环耳机(图2所示).4环耳机称为headset,3环耳机称为headphone,两者之间的区别就是4环耳机比3环耳机多个micphone.而J ...
- DzzOffice1.0 Beta2 全新安装图文教程及界面简单了解
本文说明:本文档用于帮助您全新安装完整的 DzzOffice Beta版软件.DzzOffice 是一款开源的云存储与应用管理工具,主要用于企业管理阿里云.亚马逊等云存储等空间,把空间可视化分配给成员 ...