系统Hang住时用oradebug分析的方法
2011-08-08 09:24
148 查看
系统Hang住时用oradebug分析的方法
某个用户做分析表的操作时,进程被阻塞,library cache lock,引起阻塞的进程也就是普通的查询该表的语句。
原因是有很多这个表相关的SQL在执行,产生这方面的冲突,分析的时候要修改相关的统计数据,而统计数据对于SQL分析是有影响的,如果一个SQL在执行过程中,是不允许修改和表相关的一些信息的。
如果系统hang住了,可以使用oradebug做一个HANGANALYZE来分析。
HANGANALYZE是系统级的分析,属于轻量级分析,不会对系统产生影响。
例如做一个1级的分析:
做的方法分两部
在SQLPLUS里,用SYS账号
1、 oradebug setmypid
2、 oradebug hanganalyze 1
之后将会生成一个trace报告,例如以下内容。
==============
HANG ANALYSIS:
==============
Open chains found:
Chain 1 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<48/29750/0x3ed60060/7856/PX Deq: Join ACK>
-- <141/31823/0x3ed5d680/2291/library cache pin>
Chain 2 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<76/16377/0x3ed554b0/6507/No Wait>
Chain 3 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<98/8617/0x3ed65c80/4550/No Wait>
说明:
nodenum:定义每个session的序列号
sid:session的sid
sess_srno:session的Serial#
ospid:OS的进程ID
state:node的状态
adjlist:表示blocker node
predecessor:表示waiter node
示例中,SID=141的就是被HANG主的会话,SID=48就是阻塞者。
Sid=48的这个进程挂死了,但是他持有了library cache pin,所以阻塞了141,杀掉48(OSPID=7856)就解决问题了。
而后根据等待事件的信息,具体原因具体分析。
HANGANALYZE报告里的阻塞有可能是HANG住,也有可能只是由于比较慢引起的,所以在分析的时候,可以做一个HANGANALYZE,然后隔几分钟再做一次,两次对比着看,如果是比较慢引起的,两次报告的情况会发生变化,如果是HANG住了,是不会变化的
某个用户做分析表的操作时,进程被阻塞,library cache lock,引起阻塞的进程也就是普通的查询该表的语句。
原因是有很多这个表相关的SQL在执行,产生这方面的冲突,分析的时候要修改相关的统计数据,而统计数据对于SQL分析是有影响的,如果一个SQL在执行过程中,是不允许修改和表相关的一些信息的。
如果系统hang住了,可以使用oradebug做一个HANGANALYZE来分析。
HANGANALYZE是系统级的分析,属于轻量级分析,不会对系统产生影响。
例如做一个1级的分析:
做的方法分两部
在SQLPLUS里,用SYS账号
1、 oradebug setmypid
2、 oradebug hanganalyze 1
之后将会生成一个trace报告,例如以下内容。
==============
HANG ANALYSIS:
==============
Open chains found:
Chain 1 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<48/29750/0x3ed60060/7856/PX Deq: Join ACK>
-- <141/31823/0x3ed5d680/2291/library cache pin>
Chain 2 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<76/16377/0x3ed554b0/6507/No Wait>
Chain 3 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<98/8617/0x3ed65c80/4550/No Wait>
说明:
nodenum:定义每个session的序列号
sid:session的sid
sess_srno:session的Serial#
ospid:OS的进程ID
state:node的状态
adjlist:表示blocker node
predecessor:表示waiter node
示例中,SID=141的就是被HANG主的会话,SID=48就是阻塞者。
Sid=48的这个进程挂死了,但是他持有了library cache pin,所以阻塞了141,杀掉48(OSPID=7856)就解决问题了。
而后根据等待事件的信息,具体原因具体分析。
HANGANALYZE报告里的阻塞有可能是HANG住,也有可能只是由于比较慢引起的,所以在分析的时候,可以做一个HANGANALYZE,然后隔几分钟再做一次,两次对比着看,如果是比较慢引起的,两次报告的情况会发生变化,如果是HANG住了,是不会变化的
相关文章推荐
- 系统HANG住分析工具及方法
- 系统HANG住分析工具及方法
- 苹果官方 Crash文件分析方法 (iOS系统Crash文件分析方法)
- apue第六章 系统数据文件和信息(详细分析shadow的加密方法)
- 基于Web的系统测试分析与测试方法(二)
- VxWorks系统异常分析方法
- 自考工作分析之工作分析的系统方法
- 系统的用户分析方法及分析内容
- 结构化系统分析和设计方法简介
- 原创:电视系统分析方法
- Android系统SettingsPrivider分析与修改方法
- 蓝屏含义原理分析处理方法代码电脑计算机故障系统安全 - 蓝屏知识大全
- 论软件需求分析方法和工具的选用—论文2:企业集团的信息管理系统应用
- 系统架构分析设计方法
- Scripts:分析RAC hang的脚本(此脚本要慎用,在某些版本下可能会导致系统重启)RACDIAG.SQL
- win7 64位系统web项目导出excel问题分析及解决方法汇总
- nmon监控AIX|linux,用nmon_analyser分析系统监控数据的方法
- 日志分析系统——Hangout源码学习
- 系统集成资质-下午案例分析题解答方法
- 二进制程序分析工具Pin在Windows系统中的安装和使用方法