12.22.06
DSI 301 Advanced Server Support Skills之Hang,Loop And Crash Diagnostics
概述:
当一个oracle的进程或者是实例异常终止,在终止前,oracle一般会记录诊断信息.在大多数情况下,这些诊断信息以trace文件的形式存在,当然,在实例正常运行的时候,也可以通过事件来产生trace信息.如果你发现你的oracle的trace文件不足以处理你的问题,那么则需要查找os的trace文件以及硬件的trace文件;
1:一般错误
一个instance或者是进程的crash分为:
内部错误(ora-600)
操作系统的冲突(segmentation,bus以及access的冲突)
要注意的是,segmentation冲突,通常是访问segment(data,stack或者是text)的时候发生,而access冲突,通常是访问内存的时候发生
hang:等待一个不会发生的事件
loop:进程或者实例并没有hang,但是无限循环的执行某些操作;
低性能:没有东西被hang住,但是性能不可测量.操作系统级别的诊断现实进程过多的消耗了cpu时间
区别hang和loop的一个方法,是可以去看cpu的消耗,一般来说,hang不消耗cpu,而loop将cpu消耗完
诊断文件:
包含以下几种文件
alert.log文件
trace文件
应用的log文件,例如sql*plus的trace文件
core dump文件
以及系统的log文件
但是要注意的是,如果没有具体的执行的语句,那么,core dump文件通常没有什么作用,如果trace文件存在,core文件不会有更多的信息,如果没有trace文件,调用堆栈可以在系统级别使用debugger来得到.
alert.log文件:
任何一个实例都有一个alert.log文件,该文件如果不存在,则oracle会自己创建一个这样的文件.
该文件中记录如下内容:
回滚和前滚的诊断数据;
错误的总结性信息以及记录详细错误的trace文件的入口;
从数据库创建以来的对于在出现问题的时候分析问题的信息(除非清除了,因为清除alert.log文件的信息不会导致任何故障,有时候会作清除)
alert.log文件,将写在background_dump_dest这个参数指定的目录下.文件名一般为alert
trace文件:
任何一个服务进程,在遭遇到异常的时候,都会写诊断信息到trace文件中.
trace文件的头包含以下信息:
OS以及OS版本
oracle版本以及安装的组件
实例名称
进程ID
一个比较重要的trace文件中的信息是堆栈的trace;
堆栈的trace描述了在进程crash前的调用的顺序;
使用堆栈的trace和源代码,可以分析问题所在.
应用的log文件:
应用的log文件通常是遭遇在用户端的,例如sql*plus的spool文件或者是exp/imp的log文件;
unix上的core文件,通常是从失败进程的内存的中dump出来的.
系统log文件:
系统log文件在os级别抓取错误发生时候的错误信息
如果是硬件或者是os问题这种文件将非常有用;
hang的情形:
进程等待一个永远不会发生的事情;
最有用的发现这类事件的方法是使用多重dump或者v$session_wait,v$lock,v$latch以及v$latchholder
这些视图和dump将展现导致hang的信息;
hang情景的时候,一般得到了cpu,但是没有cpu的使用.
loop
进程循环的作不应该发生的操作,例如请求一个被其他的对象持有的资源,例如发生在系统级别的等待事件;
使用多重dump或者v$session_wait,v$lock,v$latch以及v$latchholder
这些视图和dump将展现导致loop的信息;
可以使用两种方法得到系统状态的dump
1:SQL>alter session set events ‘immediate trace name systemstate level 10’;
2:SQL>oradebug setospid
SQL>oradebug dump systemstate 10
诊断loop
为了确认loop的问题,可以:
频繁的获得系统情形的dump;
通过ORADEBUG获得进程的堆栈信息;
频繁的查询数据字典视图并且查看进程有什么改变;
低性能
进程变慢;
如果进程消耗了过多的cpu事件,那么不是hang,可能是loop或者是当前变的太慢;
如果一个进程不是hang,也不是loop,那么可能是变慢,需要进行优化;
可以通过不同级别的优化,包括硬件,数据库以及应用级别的;
分析BESTAT/ESTAT以及TKPROF输出来明白应用和数据库的情形是一个好的处理低性能的开始点;
状态对象
状态对象是在SGA中关联不同的数据库入口的结构,例如
后台和前台进程
sessions
latch以及enqueues
有几种不同的状态对象,包括进程,sessions,以及事务状态对象;
每一种状态对象都是为特殊的目的设计的;
通常通过PMON来清除失败后的资源;
进程状态对象
每一个oracle后台和前台进程都有一个进程状态对象;
在MTS环境下,PSEUDO有一个附加的状态对象
每一个oracle的进程和状态对象间都有一对一的关系,但是PSEUDO进程是例外,该进程是用来在session迁移时保持sessions分配的.
一个专用连接用户session是属于PSEUDO进程的,除非其他的session切换到这里,在这种情况下,它将移动到新进程的状态对象中;
PSEUDO进程是在MTS环境中提供session迁移的,数目是依据平台的;
状态对象的层次:
从上到下为:
进程
session ,调用
事务;
也就是说,进程有一个session,session有一个打开的事务;
通常情况下,一个进程有且仅有一个session对象,进程有多个session对象通常是在XA和MTS环境或者是OCI应用中.
状态dump
可以dump状态对象到一个trace文件中去诊断问题;
有两种dump的类型
进程状态dump
系统状态dump
一个进程状态dump是dump一个进程中的所有状态对象;
一个系统状态dump是dump系统中所有进程的所有状态对象;
进程状态dump
dump进程状态:
SQL>alter session set event ‘immediate trace name processstate level 10’;
在出错的时候dump进程状态(从init.ora):
‘
dump当前正在运行的进程的进程状态:
SQL>oradebug setospid
SQL>oradebug dump processstate 10
系统状态dump
系统状态是一个实例中所有进程的进程状态dump
立即dump一个系统状态:
SQL>alter session set events ‘immediate trace name systemstate level 10’;
在出错的时候dump系统状态(从init.ora)
‘
数据字典视图
当诊断hang和loop的时候,下面的视图会有比较有用的信息:
v$session_wait,v$session_event
v$latch,v$latchholder,v$latchname
v$sysstat,v$lock
v$process,v$session,v$trnsaction
x$kcbfwati(buffer waits),x$ksqst(enqueues)