记得几年前，当小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主动发起的重启。
1
通过status查看CPU的状态，如果可以找到某颗CPU正在做sysdumpstart，则有可能是10gRAC机制将OS重启。
2
从黄色底纹部分获取到sysdumpstart进程号。
使用P * 命令来查看进程的信息
灰色表示该进程的进程号，黄色表示父进程的进程号，用十六进程表示.
上述的各列为
查看调用sysdumpstart的父进程
发现是一个sh,该shell的进程号是010A006
3
继续查看该sh的父进程，发现是0000001，00001是INIT进程
此处，查看父进程已经到头了。需要查看 进程号010A006 的子进程，从绿色和粉色底纹部分可知子进程是 008F096
4
接着查看 008F096 的子进程，可知子进程是 01D5046 ，是一个sh进程。
5
然后查看 01D5046 的子进程，可见是ocssd.bin进程
使用pdt *命令打印page device table的信息
当时系统存在pending的换页I/O，说明系统当时的性能差！ 到这里 ， 可以收工了！至于剩下的，则是小y是留给那家服务商的考验... 本文转载于中亦安图
