记得几年前，当小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进程
从上面的信息可以看到,sysdumpstart进程和ocssd.bin的进程具有相同的父进程(进程号010A006)，该父进程是一个shell程序，而ocssd.bin是oracleclusterware中的一个进程，因此该父进程必然是Oracle的一个脚本程序。Oracle的某个监控进程发现异常后调用了sysdumpstart让系统重新启动，以便维护集群的一致性。使用pdt *命令打印page device table的信息
当时系统存在pending的换页I/O，说明系统当时的性能差！到这里，可以收工了！至于剩下的，则是小y是留给那家服务商的考验...
更多实战分享和风险提示，请关注“中亦安图”公众号！也可以加小y微信，进微信群探讨技术，shadow-huang-bj。喜欢就转发吧，您的转发是我们持续分享的动力！！
回复“001” 第一期：技术人生系列 · 我和数据中心的故事（第一期）小机上运行Oracle需要注意的进程调度bug
回复“002” 第二期：技术人生系列 · 我和数据中心的故事（第二期）-风险提醒之Oracle RAC高可用失效
回复“003” 第三期：技术人生系列 · 我和数据中心的故事（第三期）-中亦科技关于数据库文件损坏风险的提醒
回复“004” 第四期：技术人生系列 · 我和数据中心的故事（第四期）-导致Oracle性能抖动的参数提醒
回复“005” 第五期：技术人生系列 · 我和数据中心的故事（第五期）-清算/报表/日终跑批程序之性能优化案例（一）
回复“006” 第六期：技术人生系列 · 我和数据中心的故事（第六期）-Oracle内存过度消耗风险提醒
回复“007” 第七期：技术人生系列 · 我和数据中心的故事（第七期）-Systemstate Dump分析经典案例（上）
回复“008” 第八期：技术人生系列 · 我和数据中心的故事（第八期）-Systemstate Dump分析经典案例（下）
回复“009” 第九期：技术人生系列 · 我和数据中心的故事（第九期）-SQL优化之基于SQL特征的改写
回复“010”第十期：技术人生系列·我和数据中心的故事（第十期）-一次导致数据丢失的小变更
回复“011”第十一期：技术人生系列·我和数据中心的故事（第十一期）-一次启停引发的故障
回复“012”第十二期：技术人生系列·我和数据中心的故事（第十二期）-风险预警·如何预防开发问题流到生产
回复“013”第十三期：技术人生系列·我和数据中心的故事（第十三期）-风险预警-容易忽略的导入问题问题
回复“014”第十四期：技术人生系列·我和数据中心的故事（第十四期）-橙色预警-Oracle游标泄露（open_cursor耗尽）
回复“015”第十五期：技术人生系列·我和数据中心的故事（第十五期）-橙色预警：索引空间泄露导致业务中断
回复“016”第十六期：技术人生系列·我和数据中心的故事（第十六期）-红色警报--Oracle宕机潮来临，快快行动起来！
回复“016续”第十六期续：技术人生系列·我和数据中心的故事（第十六期续）-oracle rbal进程内存泄露问题续集
回复“017”第十七期：技术人生系列·我和数据中心的故事（第十七期）-看中国最美女DBA的一次价值连城的系统优化！
回复“018”第十八期：技术人生系列·我和数据中心的故事（第十八期）-记一条500行执行计划的SQL问题分析-从应急处理到根因分析
