数据库故障诊断（Troubleshooting）之性能问题导致的数据库严重故障案例之一

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

会不会CLUSTER因为某些因素主动重启了数据库呢？因为运维人员几乎没提供什么信息，于是，又让他们采了OS层面的信息，进一步证实了我的猜测：

那么，什么因素导致了cluster主动重启了数据库呢？继续看看运维提供的awr报告，定位到了异常过程和相应sql如下：

反馈用户后，用户侧人员很快定位到问题所在，处理后，至今近半年，故障没再发生，一切正常。