数据库故障诊断(Troubleshooting)之性能问题导致的数据库严重故障案例之一
2018-04-12 13:51
477 查看
好久不来这里写东西,今天有点时间,来这里写点最近遇到的事情。前段时间,某电信业务用户因某核心生产库最近多次宕机重启,多方人员介入无果后,给我发来了邮件,大概意思就是现在该问题已经造成了比较严重的后果,希望能帮助介入分析、诊断并解决该问题。通过之前介入该问题的人员了解到,到目前为止,已经是第三次宕机重启了,时间区间大概为2个多月的样子。第一次重启后,因为运维人员并未获取到当时有价值的信息,因此,并没有一个结论;第二次其他数据库相关人员定位到可能是该版本(11.2.0.4,3)的某个bug引起的,并给出了解决方案,他们之所以这么解决,是因为在数据库的alert.log中发现了该bug的信息,因此,都坚信这就是该问题的根源所在,实施该方案后,大家心里就踏实了。可令大家没想到的是,过了不久,同样的故障依旧重现了,至此,给我发来了邮件。通过和相关人员的沟通,并获得了问题发生时仅有的信息(获取的信息并不全),只是听到他们说,该问题发生时很奇怪,系统突然hang住的样子,而且期间,无论是DB还是OS层面的操作,都没什么反应,他们也有的怀疑OS或DB层面的异常,甚至怀疑到了硬件的问题。。。,当然,他们的怀疑也不无道理。通过运维人员提供的DB日志,发现了一个奇怪的问题,该数据库在问题发生期间,并不是因为故障导致的自动宕机,而极可能是人为关闭了数据库,这有点出人意料,其他相关人员也极力否认,这是预料中的,没人愿意承认这种事情,况且,其中一次在23点左右发生的,他们用这个时间来反驳我:这个时间点,谁还会操作数据库?想想也是,这毕竟只是一个线索而已,如下就是当时的日志信息:
会不会CLUSTER因为某些因素主动重启了数据库呢?因为运维人员几乎没提供什么信息,于是,又让他们采了OS层面的信息,进一步证实了我的猜测:
那么,什么因素导致了cluster主动重启了数据库呢?继续看看运维提供的awr报告,定位到了异常过程和相应sql如下:
反馈用户后,用户侧人员很快定位到问题所在,处理后,至今近半年,故障没再发生,一切正常。
会不会CLUSTER因为某些因素主动重启了数据库呢?因为运维人员几乎没提供什么信息,于是,又让他们采了OS层面的信息,进一步证实了我的猜测:
那么,什么因素导致了cluster主动重启了数据库呢?继续看看运维提供的awr报告,定位到了异常过程和相应sql如下:
反馈用户后,用户侧人员很快定位到问题所在,处理后,至今近半年,故障没再发生,一切正常。
相关文章推荐
- 数据库故障诊断(Troubleshooting)之性能问题导致的数据库严重故障案例之中的一个
- 数据库故障诊断(Troubleshooting)之性能问题导致的数据库严重故障案例之一
- 故障诊断 | 存储Cache丢失导致数据库无法open的案例分享
- 大量并发SQL导致数据库性能问题诊断优化
- 故障诊断 | 存储Cache丢失导致数据库无法open的案例分享
- 最具戏剧性的分析诊断案例——十分钟锁定数据库性能“元凶”
- 新书速递:《Oracle DBA手记—数据库诊断案例与性能优化实践》即将上市
- 解决Scrapy性能问题——案例五(Item并发太多导致溢出)
- 用sp_lock诊断SQL Sever的性能问题(数据库管理员不得不看)转的。
- 数据库性能优化分析案例---解决SQL语句过度消耗CPU问题
- 常见问题:如何使用AWR报告来诊断数据库性能问题 (文档 ID 1523048.1)
- 一个不起眼的问题导致性能的严重的下降
- 《Oracle DBA手记——数据库诊断案例与性能优化实践》编辑手记
- 故障案例:mysql5.6下,mysqlbinlog版本不对可能导致的问题
- 故障分析:数据库一致性关闭缓慢问题诊断
- 最具戏剧性的分析诊断案例——十分钟锁定数据库性能“元凶”
- Oracle数据库案例整理-Oracle系统运行时故障-Shared Pool内存不足导致数据库响应缓慢
- 2017-04-27 DBA日记,关于存储光纤交换机故障引发的数据库性能问题
- 诊断Java代码中常见的数据库性能热点问题应该这么做!
- 阿里云数据库CloudDBA智慧解决数据库性能优化和问题诊断难题