Procwatcher: Useful Script to Monitor Oracle Processes

也许总在某个时候,作为Oracle DBA的你心里会想,这进程到底在干什么呢?为什么占用这么高的CPU?为什么写这么多数据到磁盘上产生这么大的IO? 当然,我们有各种各样的诊断方法来确认这些进程在做什么,不过,也很有可能在初步的诊断之后,还是一无所获,这时候也许类似于oradebug short_stack这样的命令或者是操作系统级别的debug命令能够让我们在重重迷雾中找到一些指路的明灯。不能否认,在某些时候,只是灵光一闪,从某些特征上忽然醒悟了该从哪个方向入手,就能帮助我们最终解决问题。 这里介绍的Procwatcher是一个shell脚本,运行在UNIX/LINUX操作系统级别,帮助我们给指定的Oracle Clusterware后台进程(比如crsd.bin, evmd.bin等)以及Oracle RDBMS后台进程(比如dbwr, smon, pmon等)进行定期的debug跟踪,将收集的stack traces按照进程和日期存储在磁盘上。 不要期望能够完全看明白stack trace的内容,那些是给专业的Oracle Support人员看的,但是我们至少可以知道在一个进程非常缓慢或者非常忙碌的时候,它被hang在了什么地方,也许是一个类似于kslwait这样的函数,这些就是蛛丝马迹,可以通过这些关键字去Metalink中找寻更有价值的信息。或者把这些trace内容上传给Oracle Support人员,也对解决疑难问题有很大帮助。 此脚本的内部注释非常完整,基本上所有的帮助信息都可以从脚本注释中找到。 启动和关闭脚本的命令分别是: ./prw.sh start ./prw.sh stop 注意点: 1. 获取stack trace通常会对被debug的进程有短暂的suspend操作,比如ocssd.bin如果被suspend过长(超过css misscount时间),则会导致节点被重启。可以修改脚本中的CRSPROCS参数,将不需要trace的进程去除。 2. 在AIX平台上慎用EXAMINE_CRS=true,也就是在AIX平台上最好不要用这个脚本去获取Oracle Clusterware后台进程的stack trace,可能造成程序被hang住。 3. 默认保留2天的trace记录,可以通过下面的语法修改为3天或者更多。 ./prw.sh start 3 可以登录Metalink的朋友可以在Note:459694.1中下载该脚本。 没有Metalink帐号的朋友在这里下载脚本。

Oracle Clusterware consolidated logging

使用过Oracle Clusterware 10gR1的朋友应该还记得各个后台进程的log都被散乱地放在各自的目录中,可惜的是,也许你刚刚熟悉了每个log的位置,然后当你将10gR1升级到10gR2,你就发现所有的log你都找不到了,它们不再在原来的位置,Oracle重新整理放在了统一的目录下。 这里记录一下10gR2和11gR1中Oracle Clusterware的log位置。以下ORACLE_HOME指Oracle RDBMS软件的安装目录,ORA_CRS_HOME指Oracle Clusterware软件的安装目录。 CRS logs $ORA_CRS_HOME/log/[hostname]/crsd/ CSS logs $ORA_CRS_HOME/log/[hostname]/cssd/ EVM logs $ORA_CRS_HOME/log/[hostname]/evmd $ORA_CRS_HOME/evm/log/ Resource logs $ORA_CRS_HOME/log/[hostname]/racg $ORACLE_HOME/log/[hostname]/racg SRVM logs $ORA_CRS_HOME/log/[hostname]/client $ORACLE_HOME/log/[hostname]/client Cluster Network Communication logs $ORA_CRS_HOME/log OPMN logs $ORA_CRS_HOME/opmn/logs alert logs $ORA_CRS_HOME/log/[hostname]/alert[hostname].log OPROCD logs /var/opt/oracle/[hostname] CLSOMON files $CRS_HOME/log/[hostname]/cssd/oclsomon 当Oracle Clusterware发生问题的时候,需要寻求Oracle Support的帮助,那么这些位置的log都是可能会需要的。 我们也可以使用在10gR2之后Oracle提供的perl脚本来获取诊断信息。 在10gR2版本中,执行: $ORA_CRS_HOME/bin/diagcollection.pl -collect 在11gR1版本中,执行: $ORA_CRS_HOME/bin/diagcollection.pl -crshome=$ORA_CRS_HOME -collect 该脚本执行结束以后,将会产生几个tar.gz文件,包括crsData_[hostname].tar.gz,ocrData_[hostname].tar.gz,oraData_[hostname].tar.gz和basData_[hostname].tar.gz 。…

Using Diagwait during Oracle Clusterware Node evictions

什么情况下Oracle Clusterware会重启(Evict,驱逐)节点机器? 1. 节点机器在interconnect network上无法ping通,没有了network heartbeat,比如网络问题。 2. 节点机器无法存取Voting Disk,没有了disk heartbeat,比如磁盘问题。 3. 由于节点机器过于繁忙,导致没有空闲资源来完成上述的两种动作之一,比如CPU问题,内存问题。 具体的Timeout算法参看Metalink Note:294430.1。 通常,在某个节点被驱逐之后,cssd.log或者crsd.log或者操作系统自身的log中会有具体的信息记载,通过这些log可以知道到底是什么原因导致了节点被驱逐。但是,可能在某些情况下,由于操作系统在被强行reboot之前过于繁忙,根本没有任何空余的CPU时间片来将内存中的log内容写入到磁盘log文件中,这时候,我们在log中看到的就是忽然的一段时间空白之后就是Cluster重新启动的信息了。 在10.2.0.3之后,我们可以设置diagwait,来延迟eviction,让系统在重启之前等待几秒,尽量让log可以写入到磁盘上。该功能目前已经backport到10.1.0.5中,因此在 10.1.0.5 (or higher), 10.2.0.3 (or higher) 和11.1.0.6 (or higher)这些版本中都可以设置diagwait。 注:set diagwait不仅仅会延迟eviction,同时会将oprocd进程的检查margin从默认的500ms(10205中是1500ms)提升到10000ms(也就是10秒),opocd如果发现两次检查的时间间隔超过margin值,就会强制重启服务器,所以实际上set diagwait同样提高了RAC环境的稳定性。 在不支持的版本中设置diagwait将会得到”unrecognized parameter diagwait specified” 错误提示。 设置diagwait的方法,使用root用户执行以下命令: 1. 停止Clusterware #crsctl stop crs #/bin/oprocd stop 2. 确认Clusterware stack已经完全关闭 #ps -ef |egrep “crsd.bin|ocssd.bin|evmd.bin|oprocd” 3. 在集群的任意节点上设置diagwait等待时间13秒 #crsctl set css diagwait 13…