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 ...
随机推荐
- C#利用最新版的WPS实现导入导出
微软的EXCEl操作相信大家也知道,不方便,安装包太大,而且表格的数据量也只有6000多(是6000多还是60000多我就忘记了),在导出导入大量数据的就没办法,而wsp表格则实现了百万数据的容量,而 ...
- web-ylbtech-数据库备份-数据库设计
ylbtech-DatabaseDesgin:web-ylbtech-数据库备份-数据库设计 DatabaseName:ylbtech Model:备份 Type:数据库备份设计 Url: 1.A,数 ...
- c# 读取IntPtr 中的数据 z
c++的写法是这样的: LRESULT CPictureQueryDlg::OnQueryPicNty(WPARAM wp, LPARAM lp) { EnableWindow(TRUE); BYTE ...
- Java魔法类:sun.misc.Unsafe
Unsafe类在jdk 源码的多个类中用到,这个类的提供了一些绕开JVM的更底层功能,基于它的实现可以提高效率.但是,它是一把双刃剑:正如它的名字所预示的那样,它是Unsafe的,它所分配的内存需要手 ...
- 将垃圾送入无底洞,顺便整理dev知识
相信用过Linux的童鞋们都用过crontab来做定时任务,不需要额外的安装程序和配置,一条简单的语句搞定定时任务,但是小伙伴们发现了没,如果你的定时任务执行频率很高而且会产生大量的输出的话,你的老爷 ...
- 判断是否为BST
递归的方法,用返回false的方法.中序遍历的想法很好,空间浪费.遍历的过程记录上一次的值进行比较. //题目描述 // //请实现一个函数,检查一棵二叉树是否为二叉查找树. //给定树的根结点指针T ...
- Android APP的安装路径
转载自:http://blog.csdn.net/libaineu2004/article/details/25247711 一.安装路径在哪? Android应用安装涉及到如下几个目录: syste ...
- Python面试必须要看的15个问题
本文由EarlGrey@编程派独家编译,转载请务必注明作者及出处. 原文:Sheena@codementor 译文:编程派 引言 想找一份Python开发工作吗?那你很可能得证明自己知道如何使用Pyt ...
- 配置使VirtualBox下的linux可以宿主机互访并上网
1. 设置VirtualBox,选择桥接网卡 2. 配置linux的ifcfg-eth0 配置完成后,用service network restart重启网络. 3. 然后查后路由配置是否正确 如果没 ...
- 使用Maven将Hadoop2.2.0源码编译成Eclipse项目
编译环境: OS:RHEL 6.3 x64 Maven:3.2.1 Eclipse:Juno SR2 Linux x64 libprotoc:2.5.0 JDK:1.7.0_51 x64 步骤: 1. ...