如何经常使用Oracle诊断事情

昨天我发了一篇诊断事情的文章，倡导国产数据库参考一下Oracle的诊断事情，能够为用户提供一些罕用的诊断事情。随后有好友问我，Oracle都有哪些诊断事情，能不能写篇文章归类剖析一下，他们也好参考。当天我就便捷引见一下Oracle期待事情的总体状况，特意重点引见一些与数据库提升相关的诊断事情。

Oracle的诊断事情关键用于四个方面，1）依据须要DUMP数据用于剖析；2）当某个ORA失误出现时发生DUMP；3）修负数据库运转个性；4）在数据库运转的时刻失掉额外的TRACE消息。

从trace的分类上也分为immediate dump、ON-ERROR DUMP、变卦运转个性、附加输入性trace等几种。

Immediate dump关键是用于做一些数据、内存的DUMP，用于剖析疑问。比如：alter session set events 'immediate trace name controlf level 10';用于将控制文件DUMP进去，可以用于剖析控制文件里的一些消息，并用于定位ORACLE的BUG，或许用于剖析数据库出现疑问时的外在要素。

ON-ERROR DUMP是为了取得数据库失误的更为具体的消息，从而用于剖析数据库的某个失误的更深档次的要素。比如event = "60 trace name errorstack level 1"可以在数据库出现死锁时生成LEVEL 1级的TRACE。某些系统假设频繁出现死锁，动不动把TRACE写满了，那么也可以用这个事情封锁ORA-60发生的TRACE。

变卦运转个性的事情普通是用于修复某些BUG或许让数据库针对某种业务场景做一些运转调整，从而满足用户的需求。

第四类TRACE是要求数据库输入更多的调试消息，从而剖析某些疑问。昨天说的10046、10053等TRACE都是此类TRACE。

TRACE可以在系统级设置，也可以在会话级设置，下面这张图说明了系统级TRACE和会话级TRACE之间的相关。会话会承袭系统级TRACE，也可以笼罩系统级TRACE的设置。某些TRACE也可以独自在会话级设置。

不论TRACE的才干有多强，关于运维人员来说，TRACE的关键作用是两个：缺点诊断和功能提升。经常出现的可用TRACE启动剖析的缺点报考实例或许进程crash （Internal errors /ora-600/ORA-7445、OS与RDBMS之间的兼容性引发的疑问、Segmentation violations, UNIX/LINUX的bus errors 、WINDOWS的Access violations等）、或许由于期待某个事情而 hang 住数据库或许某些会话、进程堕入非反常的循环（loop）、系统变慢等等。

假设没有出现HANG或许LOOP现象，那么很或许是数据库系统出现了功能疑问，功能提升可以从配件、DB、运行等层面启动，此时除了TRACE外，应该同时经常使用AWR/ADDM启动基础功能剖析，EVENT 10046和TKPROF是很好的运行功能剖析工具，也是十分罕用的功能诊断工具。

当数据库出现HANG或许LOOPING的时刻，各级STATE DUMP（SYSTEM STATE DUMP/PROCESS STATE DUMP）都是十分关键的剖析工具。此外HANGANALYZE也是一个十分有效的TRACE工具。此外V$SESSION_WAIT, V$LOCK, V$LATCH, V$LATCHHOLDER这些系统视图也是很好的辅佐剖析工具。

比如某个数据库HANG住，自愿重启，须要了解为什么会HANG住。普通状况下咱们可以查找diag的TRACE，在Oracle 10g之后，当数据库出现HANG或许十分缓慢的时刻，DIAG会智能发生一个SYSTEM STATE DUMP或许HANGANALYZE，这个可以作为预先剖析疑问的十分关键的素材。

此时的剖析还是要从剖析缺点的终点ALERT LOG中去查找答案。这是很多不足阅历的DBA经常犯的失误，那就是当疑问出现的时刻没有第一期间去检查ALERT LOG，而是自觉的去做各种剖析。在这个案例中，ALERT LOG里无显著线索，只要一个SYSTEM STATE DUMP可供剖析，那么经常使用ass.awk剖析SYSTEM STATE DUMP或许可以找到一些供下一步剖析的蛛丝马迹，并了解过后系统的总体状况。

下面是ass剖析的结果可以看出以下的消息：1）BLOCKER未知，latch c0000000c2df3b70或许是剖析的关键；2）存在一个PR锁，说明有进程正在启动，PR锁的持有者是41号进程，

latch c0000000c2df3b70的持有者也是41号进程。因此41号进程是下一步剖析的要点。

经过在SYSTEM STATE DUMP中搜查发现41号进程是MMON进程，正在期待某个子进程启动终了。因此可以失掉消息，下一步剖析的要点是检查MMON正在启动哪个进程。

OSP REQ HOLDER对象中，咱们看到了MMON在启动m000的时刻，进程启动形态是“DEAD”。咱们取得了一个十分关键的消息。mmon能否持有了某个资源，hang住了本系统，少量会话期待log file switch(checkpoint incomplete)，须要检查ckpt的PROCESS STATE DUMP。

从下面的消息可以看出，阻塞CKPT的会话是fbf5e4278，就是mmon自身。至此，monn启动m000失败的要素还须要进一步排查，不过从下面的剖析咱们可以取得足够的消息了。缺点要素是mmon启动m000失败造成了mmon HANG住，mmon持有的pr锁阻塞了ckpt

ckpt阻塞了log file switch。这个疑问在宕机4小时前缺点就出现了，同时xit中出现了少量的ROW CACHE LOCK WAIT TOO LONG的告警。假设咱们能够及时发现这个告警，杀掉mmon或许调整statistics_level可处置疑问，防止宕机出现。