oracle轮流重启rac节点故障
现象描述
2025 年11 月06 日19:00 开始关闭his 库1 节点，准备更换内存。于19:46 完成关库动作，开始更换内存。业务于20:04 发现连接不上。20:15 一节点服务器启动，尝试恢复业务，20:44 分scan 切换完成，业务恢复。
问题详细诊断
一节点于19:00 开始shutdown immediate 关库，一直卡住，原因为存在未决分布式事务（通过dblink 访问对端数据库，未收到对端的commit 或者rollback 等确认信息，导致本地事务无法完结）。由于时间过久，最终于19:46 强制在一节点关库。（当前未决分布式事务问题已处理）
由于一节点强制关库，基于oracle rac 的特性，为了确保数据的一致性，19:00 ——19:46 未提交的事务会于二节点进行强制回滚。过长时间的回滚导致服务器资源崩溃。
部署的osw 可查看到从19:51:40 之后到20:14:52 之间只有一条记录，说明资源撑爆了，下图为io 使用率满了。io 于15 分1 节点启动，重新加入集群后恢复。
主机日志显示19:53 之前io 撑爆了。
oswps 日志显示load average 过高（his 库日常为15 左右），cpu 排列等待过高。虽然io 在15 分时恢复了，但是之前的cpu 等待序列依旧过高，导致2 节点依旧资源撑爆，无法ora.asm 、ora.listener_scan1 服务。
crt 连接服务器显示为空白，集成商ping ip 发现能ping 通，当时判断为网络层面问题，后续排查为资源撑满导致。
oraagent_grid.log 日志显示19:51:28 check 资源状态，19:52:00 确认ora.asm 资源状态超时，状态从online 变更为unknow 。
oraagent_grid.log 日志显示19:53:25 check scan 监听资源状态，19:53:25kill 了scan 监听，导致业务无法连接存活的2 节点。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69980685/viewspace-3104723/ ，如需转载，请注明出处，否则将追究法律责任。
