好久不来这里写东西。今天有点时间，来这里写点近期遇到的事情。前段时间，某电信业务用户因某核心生产库近期多次宕机重新启动，多方人员介入无果后。给我发来了邮件。大概意思就是如今该问题已经造成了比較严重的后果，希望能帮助介入分析、诊断并解决该问题。
通过之前介入该问题的人员了解到。到眼下为止，已经是第三次宕机重新启动了，时间区间大概为2个多月的样子。
第一次重新启动后。由于运维人员并未获取到当时有价值的信息，因此。并没有一个结论。第二次其它数据库相关人员定位到可能是该版本号（11.2.0.4,3）的某个bug引起的，并给出了解决方式。他们之所以这么解决。是由于在数据库的alert.log中发现了该bug的信息。因此，都坚信这就是该问题的根源所在，实施该方案后，大家心里就踏实了。可令大家没想到的是，过了不久，相同的故障依然重现了。至此，给我发来了邮件。通过和相关人员的沟通，并获得了问题发生时仅有的信息（获取的信息并不全），仅仅是听到他们说。该问题发生时非常奇怪，系统突然hang住的样子，并且期间。不管是DB还是OS层面的操作。都没什么反应。他们也有的怀疑OS或DB层面的异常，甚至怀疑到了硬件的问题。
。。
，当然，他们的怀疑也不无道理。通过运维人员提供的DB日志，发现了一个奇怪的问题，该数据库在问题发生期间，并非由于故障导致的自己主动宕机，而极可能是人为关闭了数据库。这有点出人意料，其它相关人员也极力否认，这是预料中的，没人愿意承认这样的事情，况且。当中一次在23点左右发生的，他们用这个时间来反驳我：这个时间点，谁还会操作数据库？想想也是。这毕竟仅仅是一个线索而已。例如以下就是当时的日志信息:
会不会CLUSTER由于某些因素主动重新启动了数据库呢？由于运维人员差点儿没提供什么信息，于是，又让他们採了OS层面的信息，进一步证实了我的推測：
那么。什么因素导致了cluster主动重新启动了数据库呢？继续看看运维提供的awr报告，定位到了异常过程和对应sql例如以下：
反馈用户后。用户側人员非常快定位到问题所在。处理后，至今近半年，故障没再发生，一切正常。