Oracle AWR报告分析：诊断RAC Global cache log flush性能故障

我收到一份客户提供的 Oracle AWR 报告，对方抱怨系统性能“慢得无法忍受”。
从这个 Top Events 表可以看出，常见的 块传输类等待事件（如 gc current/cr block 2-way/3-way）并没有出现，取而代之的是大量争用类等待事件：

• gc buffer busy release
• gc buffer busy acquire
• gc current block busy
• gc cr block busy

这说明，问题并不是 RAC 节点之间传输的块太多，而是块在传输过程中的争用和延迟非常严重。
为进一步确定问题出在哪个阶段，我查看了 AWR 报告的 “RAC Statistics” 部分：

“Global Cache and Enqueue Services – Workload Characteristics” 部分清楚显示了块传输效率低。
在健康的 RAC 系统中，CR（一致性读）和 Current（当前块）接收时间通常小于 1 毫秒，但这里的数值却明显偏高。

在 RAC 中，块通过 Cache Fusion 在节点间传输，通常会经历以下三个阶段：

• Build/Pin：构建或锁定要传出的数据块
• Flush：将数据块及其 redo 信息刷新到磁盘
• Send：通过 interconnect 网络发送到目标节点

在这份报告中，Build/Pin 和 Send 阶段几乎没有耗时（0 ms），但 Flush 阶段耗却高的异常：

• CR 块平均 266.7 毫秒
• Current 块平均 398.1 毫秒

这说明问题出现在 写入 redo 日志（Flush） 这一阶段。

在 Top Event 中，log file sync 的平均等待时间高达 396 毫秒，这在正常系统中是极其罕见的。
这进一步印证了 Redo 写入延迟严重 的判断。

经过与存储团队和系统管理员的进一步排查，最终确认：
存放 Redo Log 的磁盘组出现故障，导致写入延迟异常，从而引发了整个集群的性能瓶颈。

号主在certview.oracle.com网站上的证书清单截图。

关于号主，姚远：

• Oracle ACE（Oracle和MySQL数据库方向）
• 华为云最有价值专家
• 《MySQL 8.0运维与优化》的作者
• 拥有 Oracle 10g、12c和19c OCM等数十项数据库认证
• 曾任IBM公司数据库部门经理
• 20+年DBA经验，服务2万+客户
• 精通C和Java，发明两项计算机专利
  两次获得国家部级奖