中亦科技黄远邦技术人生（19） ——通过案例教你识别操作系统重启是否为ORACLE CRS 引起

字数 2347阅读 2117评论 0赞 3

记得几年前，当小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 重启。
![1.png](/home/attachment/201708/31/994339_150415954640981.png)

引起系统宕机的进程是sysdumpstart。这个进程一旦被调用，将会生成系统dump 并重新启动系统。
2、从黄色底纹部分获取到sysdumpstart 进程号。
使用P * 命令来查看进程的信息
![7.png](/home/attachment/201708/31/994339_150415972751920.png)

灰色表示该进程的进程号，黄色表示父进程的进程号，用十六进程表示.
上述的各列为
![8.png](/home/attachment/201708/31/994339_150415974399054.png)

查看调用sysdumpstart 的父进程
![QQ截图20170828095743.png](/home/attachment/201708/31/994339_150415975917424.png)

发现是一个sh, 该shell 的进程号是010A006
3、继续查看该sh 的父进程，发现是0000001，00001 是INIT 进程
![3.png](/home/attachment/201708/31/994339_150415977773824.png)

此处，查看父进程已经到头了。需要查看进程号010A006 的子进程，从绿色和粉色底纹部分可知子进程是008F096
4、接着查看008F096 的子进程，可知子进程是01D5046，是一个sh 进程。
![4.png](/home/attachment/201708/31/994339_150415980549598.png)

5、然后查看01D5046 的子进程，可见是ocssd.bin 进程
![5.png](/home/attachment/201708/31/994339_150415982257370.png)

从上面的信息可以看到,sysdumpstart 进程和ocssd.bin 的进程具有相同的父进程( 进程号010A006)，该父进程是一个shell 程序，而ocssd.bin 是oracleclusterware 中的一个进程，因此该父进程必然是Oracle 的一个脚本程序。Oracle 的某个监控进程发现异常后调用了sysdumpstart 让系统重新启动，以便维护集群的一致性。
使用pdt * 命令打印page device table 的信息
![6.png](/home/attachment/201708/31/994339_150415985269139.png)

当时系统存在pending 的换页I/O，说明系统当时的性能差！到这里，可以收工了！至于剩下的，
则是小y 是留给那家服务商的考验...

数据库优化数据库

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

中亦科技黄远邦技术人生（19） ——通过案例教你识别操作系统重启是否为ORACLE CRS 引起

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料