数据库 update 操作慢，我为什么断定是硬件故障
发布时间：2022-10-11 10:18:56 所属栏目：MySql教程 来源：
导读： 如何完整处理一个故障，聊聊我的思路。
技术人人都可以磨炼数据库更新操作，但处理问题的思路和角度各有不同，希望这篇文章可以抛砖引玉。
一、问题背景
某业务模块反馈系统涉及提交保存
技术人人都可以磨炼数据库更新操作，但处理问题的思路和角度各有不同，希望这篇文章可以抛砖引玉。
一、问题背景
某业务模块反馈系统涉及提交保存
|
如何完整处理一个故障，聊聊我的思路。 技术人人都可以磨炼数据库更新操作，但处理问题的思路和角度各有不同，希望这篇文章可以抛砖引玉。 一、问题背景 某业务模块反馈系统涉及提交保存类的操作异常缓慢，应用运维的兄弟排查说update相关的操作卡住了，卡在了数据库。 卡在了数据库...留给我一句这，真让人头大。 数据库环境：Oracle 19c RAC 操作系统：CentOS Linux release 7.6.1810 (Core) 存储：EMC存储 二、故障现象 三、故障说明 四、疑问点排查及分析思路 1、什么时间点开始有异常?异常前有没有做过变更？ 应用运维的兄弟反映昨天开始出现异常，而且系统已经很久没有做过变更了。 ps：很多系统故障都是由变更引发的，提前了解系统做过什么操作对追根溯源很重要 2、提交和保存类操作慢，DB是不是有阻塞会话？ 3、阻塞会话等待什么? 两个节点等待和lgwr、control write有关，多次查询等待时有时无。 查看pid为34852的会话 可以看到节点2卡在了lgwr进程上。 检查节点2的io等待情况 查看节点2的io流程情况，io绝对值并不大 对比节点1的io流量 两个节点的io流量绝对值都不大，怀疑是硬件故障 查看节点2的io空闲率 排查到当前这一步，基本上可以断定存储故障，为了验证一下这个思路，我关闭了节点2实例，业务层面再次发起提交保存类操作速度恢复正常。 4、解决？ rac的io链路是比较长的，如主机上的hba卡，光纤，san交换机，存储控制器，前端口等，都有可能出现问题，我的工作到此结束，解决硬件故障那是服务器厂商的事 长舒一口气，故障处理结束，故障分析处理方案整理成册，争取著作等身。 全文结束。 （编辑：百客网 - 百科网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐