首页 > 代码库 > 性能问题导致的数据库严重故障案例之一

性能问题导致的数据库严重故障案例之一

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


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


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




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




性能问题导致的数据库严重故障案例之一