1 、故障描述

某次某用户突发应用卡顿，严重影响单位正常业务流程，紧急进行远程排查后，发现一个关键异常：该查询返回结果时快时慢，快速响应时瞬间返回，延迟时卡顿达 5 秒以上，且延迟状态下会出现大量 library cache lock 等待事件。通过持续观察会话关联的 SQL_ID ，锁定核心可疑对象 ——SQL_ID:9zg9qd9bm4spu ，初步判断其为本次卡顿的根源。

2 、根因分析

针对 SQL_ID:9zg9qd9bm4spu 展开深度分析，其对应的 SQL 文本为：

update user$ set spare6=DECODE(to_char(:2, 'YYYY-MM-DD'), '0000-00-00', to_date(NULL), :2) where user#=:1

该 SQL 由系统业务用户发起，但核心疑点在于：业务用户正常操作应访问业务表，而非直接更新 Oracle 系统基表 user$ 。这一异常行为引发警惕，随即通过 Oracle MOS 文档及外部技术社区检索，最终明确该问题源于 Oracle 已知 Bug （ Bug 号： 33121934 ），且故障数据库版本（ 19c ）正处于该 Bug 的影响范围，官方已提供针对性修复补丁。

进一步查阅补丁说明得知：该补丁支持 RAC 环境滚动安装，但需前提条件：数据库已应用 19c 版本 19.15.0.0.220419DBRU 的补丁集更新（ PSU 33806152 ）。 RAC 滚动安装流程如下：

a)    关闭目标节点 Oracle 主目录下所有服务（含数据库、 ASM 、监听器、节点应用程序及 CRS 守护进程）；

b)    执行 opatch apply -local 命令在本地节点安装补丁；

c)    启动该节点所有服务，对其他节点重复上述步骤（单次仅操作一个节点）。

经与用户紧急沟通，获得即时打补丁授权后，工程师按流程完成双节点滚动安装，并根据 MOS 指引设置隐藏参数使其即时生效：

alter system set "_disable_last_successful_login_time"=true;

参数生效后， library cache lock 等待事件彻底消失， SQL_ID:9zg9qd9bm4spu 不再出现，初步判定问题已解决。

然而故障排查并未就此结束， library cache lock 消失后，数据库出现新的异常：等待事件查询仍时快时慢，延迟时卡顿超 5 秒，且大量 gc buffer busy acquire 等待事件涌现。通过会话关联分析，所有异常等待均指向 SQL_ID:d2217udafsm66 ，其 SQL 文本为：

select count(*) from link_sources$ where username = :uname

gc buffer busy acquire 等待事件的核心指向 RAC 集群通信、内存融合或跨节点数据访问问题。首先排查集群心跳网络，通过 ping 命令测试心跳链路，初期未发现延迟或丢包现象，暂时排除网络基础问题。

随后，全面核查集群日志、实例告警日志等关键文件，均未找到有效故障线索。为进一步定位问题，在用户同意后启动单节点测试：

a)    关闭节点一数据库实例，仅保留节点二数据库实例运行：等待事件查询正常，无gc buffer busy acquire ；

b)    关闭节点二数据库实例，仅保留节点一数据库实例运行：等待事件查询正常，无异常等待。

测试结果验证了核心推测： gc 相关等待仅在双节点同时运行时出现，确属集群跨节点通信引发的问题。

为尝试解决集群通信问题，决定重启其中一台服务器硬件。但重启后该节点集群无法正常启动，报出关键错误：

CRS-7503: The Oracle Grid Infrastructure process 'ocssd' observed comunication issues between node 'rac1' and node 'rac2',interface list oflocal node 'rac1'is 'xxx.xx.19.1:42217;', interface list of remote rac2'xxx.19.19.2:51138;'

该报错与此前 ping 测试结果矛盾 —— 明明测试无网络问题，却出现明确的节点间通信异常。立即重新执行心跳链路 ping 测试，结果令人意外：多次测试中，心跳包丢包率高达 30%~50% ，彻底推翻此前的网络正常判断。

用户迅速联系硬件厂商介入排查，最终定位故障根源：服务器光模块损坏导致心跳链路不稳定。当晚新光模块更换完成，重启双节点集群后， gc buffer busy acquire 等待事件完全消失，等待事件查询响应迅速稳定，应用卡顿现象彻底解决。

3 、解决方案

故障根源：本次数据库卡顿的核心原因是服务器光模块损坏导致的集群心跳链路丢包， Oracle Bug 33121934 仅为次要影响因素，且被网络故障放大；

排查关键： RAC 环境中 gc 系列等待事件需优先排查集群通信（心跳链路、网络设备），单节点或双节点对比测试是定位集群相关问题的高效方法；

网络验证： ping 测试需多次执行并统计丢包率，单次测试结果可能存在偶然性，无法全面反映网络稳定性。