昨天还在跟Andy抱怨写书的人会在书里大量帖日志来充字数坑读者捞钱的事,不过刚才有一库挂了,开始查阅日志。在分析一个trace日志时,翻阅了下eygle的一个很经典的分析思路的文章,整理了下给大家。文章的重点不是导致报错的原因跟解决的办法,而是寻找问题的思路与手段,eygle也是最擅长这样剥丝抽茧般地寻找问题。这才是最宝贵的,毕竟一旦知道真正的原因了,问题就立刻有办法迎刃而解了,而最难的是如何去发现问题的根源。在Oracle数据库的运行过程中,可能会因为一些异常遇到数据库挂起失去响应的状况,在这种状况下,我们可以通过对系统状态进行转储,获得跟踪文件进行数据库问题分析;很多时候数据库也会自动转储出现问题的进程或系统信息;这些转储信息成为我们分析故障、排查问题的重要依据。1.1状态转储的常用命令当数据库出现一些挂起状态时,往往会严重影响到数据库使用,进程级的问题影响范围较小,而系统级的问题则会影响全局。在出现数据库系统或进程失去响应时,如果SQL*Plus工具仍然可以连接,可能视图查询没有相应,但是可以通过oradebug工具来进行进程及系统状态信息的转储,从而可以进行Hang分析。DUMP进程状态可以使用:altersessionssetevents'immediatetracenameprocessstatelevel';或者使用:oradebugsetmypidoradebugulimitoradebugdumpprocessstate当诊断数据库挂起时,可以使用DUMP命令转储整个系统状态:altersessionssetevents'immediatetracenamesystemstatelevel';或:oradebugsetmypidoradebugulimitoradebugdumpsystemstate如果为了获取全面一点的信息,可以使用Level10。SQL>oradebugsetmypidSQL>oradebugunlimitSQL>oradebugdumpsystemstate10另外如果系统挂起,无法用SQL*Plus连接,从Oracle10g开始,可以使用sqlplus-prelim选项强制登录,然后即可进行系统状态信息转储:sqlplus-prelim'/assysdba'oradebugsetmypidoradebugunlimit;oradebugdumpsystemstate101.2WAITEDTOOLONGFORAROWCACHEENQUEUELOCK!案例在一次客户现场培训中,客户提出一个系统正遇到问题,请求我协助诊断解决,理论联系实践,这是我在培训中极力主张的,我们的案例式培训业正好遇到了实践现场。问题是这样的:此前一个Job任务可以在秒级完成,而现在运行了数小时也无法结束,一直挂起在数据库中,杀掉进程重新手工执行,尝试多次,同样无法完成。客户的数据库环境为:OracleDatabase10gEnterpriseEditionRelease10.2.0.3.0-64bitProductionWiththePartitioning,OLAPandDataMiningoptionsNodename:SF2900Release:5.9Version:Generic_118558-33Machine:sun4u介入问题诊断首先需要收集数据,我最关注两方面的信息:1.告警日志文件,检查是否出现过异常2.生成AWR报告,检查数据库内部的运行状况通常有了这两部信息,我们就可以做出初步判断了。检查数据库的告警日志文件,我们发现其中出现过一个如下错误:>>>WAITEDTOOLONGFORAROWCACHEENQUEUELOCK!<<<这个错误提示出现在7点左右,正是JOB的调度时间附近,显然这是一个高度相关的可能原因。1.3DUMP转储文件分析定位问题这个异常生成了转储的DUMP文件,获得该文件进行进一步的详细分析。该文件得头部信息如下:Redothreadmountedbythisinstance:1Oracleprocessnumber:29Unixprocesspid:8371,image:oracleEDW@SF2900***2010-03-2706:54:00.114***ACTIONNAME:()2010-03-2706:54:00.106***MODULENAME:(SQL*Plus)2010-03-2706:54:00.106***SERVICENAME:(EDW)2010-03-2706:54:00.106***SESSIONID:(120.46138)2010-03-2706:54:00.106>>>WAITEDTOOLONGFORAROWCACHEENQUEUELOCK!<<