记得几年前，当小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重启。

引起系统宕机的进程是sysdumpstart。这个进程一旦被调用，将会生成系统dump并重新启动系统。

2

从黄色底纹部分获取到sysdumpstart进程号。
使用P * 命令来查看进程的信息

灰色表示该进程的进程号，黄色表示父进程的进程号，用十六进程表示.
上述的各列为

查看调用sysdumpstart的父进程

发现是一个sh,该shell的进程号是010A006

3

继续查看该sh的父进程，发现是0000001，00001是INIT进程

此处，查看父进程已经到头了。需要查看进程号010A006的子进程，从绿色和粉色底纹部分可知子进程是008F096

4

接着查看008F096的子进程，可知子进程是01D5046，是一个sh进程。

5

然后查看01D5046的子进程，可见是ocssd.bin进程

从上面的信息可以看到,sysdumpstart进程和ocssd.bin的进程具有相同的父进程(进程号010A006)，该父进程是一个shell程序，而ocssd.bin是oracleclusterware中的一个进程，因此该父进程必然是Oracle的一个脚本程序。Oracle的某个监控进程发现异常后调用了sysdumpstart让系统重新启动，以便维护集群的一致性。
当时系统存在pending的换页I/O，说明系统当时的性能差！到这里，可以收工了！至于剩下的，则是小y是留给那家服务商的考验...