1、故障描述
某次某用户核心数据库在8月22日8时左右发生故障。接收到用户反馈之后，工程师进行应急响应，诊断处理数据库问题并优先恢复业务。以下内容为本次故障排查之明细。
2、根因分析
(1)、数据服务器无法登录
服务器无法通过ssh登录，虚拟化登录服务器查看到有OOM报错，考虑优先重启服务器恢复业务。
(2)、排查 AWR 报告
通过7.30到8.00的AWR报告发现数据库CPU使用超100%，数据库非常繁忙
数据库的等待事件大多为resmgr:cpu quantum
查看SQL执行情况8dt6hudq1n0v2执行需要867秒，怀疑数据库均被此sql阻塞
排查数据库发现此sql和awr报告中一致
(3)、排查 ASH 视图
查到的问题SQL也为8dt6hudq1n0v2，问题大概率是由此SQL导致的
(4)、数据库实例恢复后跟踪
CPU使用率非常高
数据库等待均由8dt6hudq1n0v2此sql导致
3、解决方案
本次核心数据库故障根因定位为应用系统慢sql导致，此sql每次查询需要860秒，高峰期库里同时有近30个会话在查询此SQL，导致数据库的CPU和内存被打满，建议业务先关闭此sql的查询，后续进行优化。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30310891/viewspace-3181468/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
Oracle 数据库实例异常宕机案例分析
请登录后发表评论
登录
全部评论
