Oracle故障和性能诊断流程V01_20120116

1编写目的介绍在现场出现Oracle故障和性能问题时的诊断流程，让项目支撑人员在解决Oracle问题时有据可依。2适用场景当现场出现以下问题时，可依照本文档进行处理：1）Oracle异常关闭、重启、Hang住等故障。2）PM相关程序出现性能急剧下降的情况。3）PM相关程序出现Hang住等故障。3分析流程3.1信息收集及初步诊断本节介绍以下知识点：1）出现问题时，需要收集什么样的信息？2）这些信息的作用是什么？3）如何进行收集？4）如何对这些信息进行分析，从而得到初步诊断结论？初步诊断结论是指引起问题的原因，但不是根因。例如，初步诊断结论是内存问题、IO问题、等待事件的问题、执行计划的问题、统计信息的问题。3.1.1PM运行情况（黄）反映PM运行情况的数据主要包括运行日志以及存储运行数据的表（例如COUNTERLOADMESSAGE、SUM_SUMMARYTASKQUEUE表等）。从以上内容中，可以分析出PM在运行过程中是否有错误发生，以及是否存在性能问题。以下内容均以C03版本为准，C02和V4.5可能有变化，需结合实际情况作相应调整。1)如何收集：a)运行日志：加载环境变量后，使用cd$PM4H_LOG进入日志目录b)运行数据表：TableNameSchemaNameDescriptionCOUNTERLOADMESSAGEpm4h_db反映入库程序的运行状态PILOADMESSAGEpm4h_db反映PIMapping程序的运行状态SUM_SUMMARYTASKQUEUEpm4h_ad反映汇总程序的运行状态SUM_BHTASKQUEUEpm4h_ad反映忙时程序的运行状态2)如何分析：a)运行日志：i.可以使用catlogfilename|grepERROR的方式，搜索指定日志中是否存在错误信息。logfilename可以是具体的日志文件名，也可以是使用了通配符的表达式。例如搜索所有的汇总日志中是否存在错误，可使用如下命令：catSummarize*|grepERRORii.如果某个日志文件中存在ERROR信息，可以使用vi命令编辑该文件，依次输入/ERROR和回车，搜索ERROR信息，查看详细的错误信息。（/是vi编辑器中的搜索命令）iii.对于性能分析，可以分为两种情况，一种是程序出现Hang住的情况，表现为日志长时间无内容输出；另一种是程序没有Hang住，但在单位周期内无法处理完一周期的性能数据。iv.出现Hang住的情况时，可以使用两种方式找到Hang住的任务。一种是通过日志分析出当前正在执行的任务。以汇总执行日志为例，可以分析Hang住时那一轮的日志中，哪些任务只有start日志，没有end日志，这些任务就是Hang住的任务；另一种是在DB服务器上使用top命令查看当前正在运行的Oracle进程，找到进程运行时间长的进程，并找到进程对应的SQL，进而分析出Hang住的任务。v.出现整体性能下降时，可以通过其它方面的信息来查找问题。b)运行数据表：i.运行数据表的数据主要用于分析核心模块的运行效率以及工作量的变化。ii.分析COUNTERLOADMESSAGE表中每天产生的MSG数量，可以得出入库程序的工作量和性能情况。PILOADMESSAGE和COUNTERLOADMESSAGE类似。iii.分析SUM_SUMMARYTASKQUEUE表中每小时执行完成的TASK数量，可以得出汇总执行程序的工作量和性能情况。SUM_BHTASKQUEUE和SUM_SUMMARYTASKQUEUE类似。3.1.2操作系统资源情况（孙）CPU信息收集登录系统后，使用top、vmstat、iostat、mpstat等命令，都可以查看到操作系统的CPU使用情况。相关的解释如下。top命令（CPU部分）loadaverageCPU负载。1分钟、5分钟、15分钟前到现在的平均值%us用户进程占用CPU百分比%sy内核空间占用CPU百分比%ni用户进程空间内改变过优先级的进程占用CPU百分比%id空闲CPU百分比%wa等待输入输出的CPU时间百分比%hi硬件中断CPU时间百分比%si软件中断CPU时间百分比%st虚拟CPU等待实际CPU的时间的百分比(StealTime)表1-1TOP命令中的CPU信息vmstat命令（CPU部分）usCPU用户进程使用CPU时间百分比syCPU系统进程使用CPU时间百分比idCPU闲置时间百分比waCPU等待输入输出的CPU时间百分比stCPU虚拟CPU等待实际CPU的时间的百分比(StealTime)表1-2vmstat命令中的CPU信息iostat命令（CPU部分）%user用户进程占用CPU百分比%nice用户进程空间内改变过优先级的进程占用CPU百分比%system内核空间占用CPU百分比%iowait等待输入输出的CPU时间百分比%steal虚拟CPU等待实际CPU的时间的百分比(StealTime)%idle空闲CPU百分比表1-2iostat命令中的CPU信息初步诊断使用CPU利用率和负载来进行CPU的初步诊断。1.CPU利用率的参考值：正常情况下=70%1）如果CPU的利用率长期大约70%，说明CPU的已经比较繁忙；2）如果故障时刻，连续超过95%以上，说明可能是CPU存在瓶颈。2.CPU负载的参考值范围：CPU核数*0-CPU核数*31）CPU负载越小越好；如果负载=CPU核数，还可以接受；2）如果负载=CPU核数*3，则说明系统负载非常高。更详细的资料，见附录一《TOP命令详解》、附录二《iostat命令详解》、附录三《vmstat命令详解》。内存信息收集登录系统后，使用top、vmstat、free等命令，都可以查看到操作系统的CPU使用情况。相关的解释如下（以free命令为例）。total总计物理内存的大小used已使用多大free可用有多少Shared多个进程共享的内存总额Buffers磁盘缓存之：BufferCache内存数cached磁盘缓存之：PageCache内存数表1-3free命令中的内存信息更详细的资料，见附录四《free命令详解》。初步诊断诊断内存是是否是瓶颈的标准：swap和+buffers/cache。1）只要不用swap的交换空间，就不用担心自己的内存太少。如果常常swap用很多，可能你就要考虑加物理内存了。这也是linux看内存是否够用的标准。2）如果是应用服务器的话，一般只看第二行，+buffers/cache，即对应用程序来说free的内存太少了，也是该考虑优化程序或加内存了。IO信息收集登录系统后，使用iostat命令获取服务器的I/O使用情况。如下：iostat命令rrqm/s每秒进行merge的读操作数目。即delta(rmerge)/swrqm/s每秒进行merge的写操作数目。即delta(wmerge)/sr/s每秒完成的读I/O设备次数。即delta(rio)/sw/s每秒完成的写I/O设备次数。即delta(wio)/srsec/s每秒读扇区数。即delta(rsect)/swsec/s每秒写扇区数。即delta(wsect)/srkB/s每秒读K字节数。是rsect/s的一半，因为每扇区大小为512字节。wkB/s每秒写K字节数。是wsect/s的一半。avgrq-sz平均每次设备I/O操作的数据大小(扇区)。即delta(rsect+wsect)/delta(rio+wio)avgqu-sz平均I/O队列长度。即delta(aveq)/s/1000(因为aveq的单位为毫秒)。await平均每次设备I/O操作的等待时间(毫秒)。即delta(ruse+wuse)/delta(rio+wio)svctm平均每次设备I/O操作的服务时间(毫秒)。即delta(use)/delta(rio+wio)%util一秒中有百分之多少的时间用于I/O操作，或者说一秒中有多少时间I/O队列是非空的。即delta(use)/s/1000(因为use的单位为毫秒)表1-4iostat命令中的I/O信息初步诊断表1-4中是最主要的I/O参数，使用他们来进初步的诊断：1）如果%util接近100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。2）如果%util接近100%，表明I/O请求太多，I/O系统已经满负荷，磁盘可能存在瓶颈，一般%util大于70%，I/O压力就比较大，读取速度有较多的wait.同时可以结合vmstat查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比，高过30%时IO压力高)。3）await的大小一般取决于服务时间(svctm)以及I/O队列的长度和I/O请求的发出模式。如果svctm比较接近await，说明I/O几乎没有等待时间；如果await远大于svctm，说明I/O队列太长，应用得到的响应时间变慢。持续收集资源信息信息收集需要在系统上部署NMON软件。具体的部署方法见附录五《NMON的部署方法》。初步诊断见附录六《NMON的诊断方法》3.1.3Alert日志和Trace文件（孙）信息收集收集方法：第一步：ftp到alert日志的目录，将alert日志收集下来。方法一：Alert日志的目录可以通过oracle的参数background_dump_dest找到。如图1-1所示。方法二：使用这个语句selectvaluefromv$diag_infowherename='DiagTrace'得到alert日志的位置。另外，RAC节点下的日志文件结构和普通的日志文件结构不一样。请参考附件《附录五：OracleRAC集群环境下日志文件结构》。第二步：找到故障发生时的时间段的log日志进行分析。第三步：如果通过alert日志看不到具体的信息，可以通过alert日志的提示，转到相应的trace文件，进行信息收集。示例如下：其中：“/opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8723.trc”和“/opt/oracle/db/diag/rdbms/vmos5200/vmos52001/incident/incdir_28441/vmos52001_ora_8723_i28441.trc”就是trace文件。第四步：也可以登录网站，查找具体的错误代码。例如：错误代码：kksfbc-wrong-kkscsflgs。初步诊断在alert日志中能够看到大部分严重错误、警告，以及一些重要的操作产生的日志。从ORACLE的角度来看，alert日志的信息可以分为如下几类：所有的内部错误（ORA-00600），块损坏错误（ORA-01578），死锁（ORA-00060）。管理性的操作，如create，alter，drop语句和start，shutdown，archivelog语句MTS模式（多线程服务器。区别于专用服务器）下共享服务器进程和调度进程的信息和错误自动刷新物化视图时发生的错误非默认的启动参数各个后台进程运行产生的错误。Oracle的后台进程见附录六《Oracle的后台进程》。同时用户也可以使用Oracle的DBMS_SYSTEM包的KSDWRT过程向alert日志书写自定义信息Job执行失败错误从用户的角度，或者DBA的角度来看，alert日志的信息可以分为如下几类：1）故障级错误：这种信息需要优先定位；故障类信息如：SatNov0510:13:372011Errorsinfile/opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8723.trc(incident=28441):ORA-00600:internalerrorcode,arguments:[kksfbc-wrong-kkscsflgs]