记得几年前,当小y在mos上找到”Bug 17208793 Producing an AIX system crash dumps on clusterwareinitiated reboots”这篇文章的时候,几乎泪奔了。
作为读者的你,可能没有意识到什么,但是对小y而言,简直是如获至宝;因为小y常年处理的case中,其中有一类case叫做RAC节点驱逐。
我们知道,当RAC两个节点私网无法通讯的时候,整个集群就不敢往下写了,否则会破坏数据,这个时候必须请一个节点离开集群,这样集群才能对外提供服务。而ORACLE选择的方式是将OS重启。起初ORACLE想的还是很周全的,为了方便后续查问题,CRS的init.cssd脚本将会调用操作系统的sysdumpstart来生成一个OS的sysdump,包括CPU和内存的状态等即时信息。这些信息,很多时候将为我们提供很大的帮助,当然,前提是如果你看的懂sysdump的内容哦 ^_^
可惜的是,11g开始,ORACLE在主动重启OS前不再调用sysdumpstart生成sysdump了,这在一段时间内困扰着小y。因此,当看到这个MOS的这个ER的时候,自然是喜出望外,往事浮现眼前…
如烟往事。。。。
阳光明媚的下午,正在一个客户那里做调优的时候,接到了来自公司华南QC的电话
“小y,帮看个问题吧。一个超大型快递公司,IBM小机等硬件是我们维保的,最近一套AIX上的10G RAC在频繁重启,但是RAC上没有什么有用的日志,没有部署oswatcher。
客户这边的情况是,只要我们能确认这几次OS重启是由于性能问题,导致RAC主动发起的重启,那接下来由客户自己负责来联系当前的Oracle服务商分析即可”。
“好吧,你抓个snap过来,我分析看看”。挂完电话,心里真不是滋味。
不过小y也大概猜到了,电话里说到的那家Oracle服务商,看起来处境不妙啊。
首先,重启几次了,最后需要找到中亦科技,说明在该服务商在ORACLEDB层面的分析遇到麻烦了。据描述,不难猜测出来,很可能在OS重启前,系统在很短时间内出现了挂起,所以CRS没有来得及记录日志,即时部署了OSW,也很难抓到当时的性能状况了。
如何确认OS重启是ORACLE而非硬件引起
晚上回到家里,打开邮件,开始了分析。
这里,小y采用kdb进行dump分析,目的是确认这几次OS重启是由于性能问题,导致RAC主动发起的重启。
通过status查看CPU的状态,如果可以找到某颗CPU正在做sysdumpstart,则有可能是10gRAC机制将OS重启。
从黄色底纹部分获取到sysdumpstart进程号。
使用P * 命令来查看进程的信息
灰色表示该进程的进程号,黄色表示父进程的进程号,用十六进程表示.
上述的各列为
继续查看该sh的父进程,发现是0000001,00001是INIT进程
接着查看008F096的子进程,可知子进程是01D5046,是一个sh进程。
然后查看01D5046的子进程,可见是ocssd.bin进程
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论