资讯专栏INFORMATION COLUMN

RAC集群节点1重启分析一例

IT那活儿 / 3961人阅读
RAC集群节点1重启分析一例

12月21日上午09点00分左右接短信告警,XXX库节点1实例断连,第一时间登陆环境检查,发现XXX库节点1主机于09点01分左右发生重启完成。通过分析节点1集群日志发现08点35分到09点01分无报错信息,09点02分04秒左右节点1开始启动集群,节点1数据库后台日志显示8点51分切换日志后无报错信息,后续集群启动完成后开始启动数据库实例。


OSW日志显示:示节点1在8点55分出现断点,cpu和内存资源正常,b队列较高,节点1在故障时间8点55分左右IO耗尽,导致主机无法响应,网络通信失败,节点1网络心跳超时,发起主机重启。9点01分主机重启完成。


8点55分左右IO耗尽的原因:节点1在8点45分左右,大量未使用绑定变量、全表扫描的同一类型高耗sql同时执行,导致数据库产生大量的direct path read异常等待事件,direct path read(sql发起从磁盘中读操作,耗IO资源),最后IO资源耗尽,致主机无法响应,网络通信失败,节点1网络心跳超时,发起主机重启。9点01分主机重启完成。

具体分析如下:

数据库节点1主机9点1分重启完成:


oracle集群日志显示在8点35分到9点02分发起集群启动之间无报错信息:


oracle后台日志显示数据库实例在8点51分到9点21分启动实例无报错信息:


Osw日志显示节点1在8点55分出现断点,cpu和内存资源正常,b队列较高




节点2Ping节点1私网也是在8点55分之后出现断点:


节点2ping节点1私网在8点55分左右出现丢包,说明节点1主机已宕:


节点1在8点时间段的IO情况来看,正常:


在故障时间点(8点55分左右)节点1主机IO出现大量磁盘读动作



8点50分左右节点1在宕掉之前出现明显的IO等待:


通过非故障时间点与故障时间点进行比较发现:节点1在故障时间8点55分左右IO耗尽,导致主机无法响应,网络通信失败,节点1网络心跳超时,发起主机重启。9点01分主机重启完成。

 

进一步检查8点55分左右IO耗尽的原因,发现节点1在8点45分左右数据库产生大量的direct path read异常等待事件,direct path read(sql发起从磁盘中读操作,耗IO资源)


AWR报告显示:direct path read大量物理读占大量IO资源


产生direct path read大量物理读源头的sql如下:同一类型的高耗sql语句,SQL没有经过审核进行上线



sql语句如下所示:未使用绑定变量产生多个不同sql_id,多个全表扫会话跑同一类型高耗sql(大量类似SQL同时执行),导致IO资源耗尽,并且这些sql都未经数据库侧进行评审上线。


高耗sql如下:全表扫描


检查重启后数据库实例状态、CRS状态、监听状态等。并通知应用检查应用


后续改进措施:

1、   应用侧核查高耗sql模块,并进行优化,数据库侧可以协助提供技术支持。

2、   开发商加强上线评审,评审通过后方可上线,避免私自未经评审上线。

3、应用修改连接机制,进行数据库高可用配置(连接数据库VIP,而不是物理IP)




文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/130247.html

相关文章

  • DBASK问答集萃(2)

    摘要:新晋技术专家下面是墨天轮部分新晋的技术专家。大家可以点击往期阅读墨天轮技术专家邀请函了解详情,申请成为我们的技术专家,加入专家团队,与我们一起创建一个开放互助的数据库技术社区。新关联公众号墨天轮是一个开放互助的数据库技术社区。 引言 近期我们在DBASK小程序增加了数据库 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的专题栏目和一些新的技术...

    liuchengxu 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<