Oracle AWR案例分析：备库太慢，拖垮了主库性能

最近有一家医院的客户抱怨 Oracle 数据库运行缓慢，并将 AWR 报告发给我分析。这篇文章记录了我分析和排查问题的过程。

从负载概要（Load Profile）来看，这是一个典型的 OLTP 类型系统，负载不轻，但整体并无异常。

在 AWR 报告中，"Top Events" 一节往往能揭示性能症状，这次也不例外。

第二大等待事件是 "log file sync"，平均等待时间高达 78 毫秒，已经严重偏慢。

而 "db file scattered read" 和 "db file sequential read" 的平均等待时间为 0 毫秒，说明存储性能非常好。因此，"log file sync" 的缓慢并不是由存储问题引起的，除非log file和data file位于不同的磁盘。

接着我查看了后台等待事件中的 "log file parallel write"，这个事件表示 LGWR 进程实际将重做日志写入磁盘的等待。

从 "log file parallel write" 平均仅 1 毫秒的等待时间来看，磁盘 I/O 性能非常出色，这与前面的读等待一致。说明问题不是存储瓶颈。但后台等待事件列表给出了更多线索：

"LNS wait on SENDREQ" 是后台等待中最多的，这表示主库的 LNS（Log Network Server）进程在等待从库返回收到redo日志的确认。

其次，"LGWR-LNS wait on channel" 等待事件说明 LGWR（Log Writer）进程正在等待 LNS 完成工作。

从这两个高等待事件可以看出，性能瓶颈在于主库向备用库传输重做数据的过程中。主库在等待备用库写入完成。

继续向下查看 "init.ora parameters" 部分，我发现了如下参数设置：

SQL 复制代码

log_archive_dest_2 = SERVICE=datgorcl LGWR SYNC AFFIRM valid_for=(online_logfiles, primary_role) db_unique_name=datgorcl

（其中参数值中的数据库名已做脱敏处理以保护客户隐私。）

这里的 SYNC 表示主库在提交前必须等待备用库确认接收到重做数据；AFFIRM 表示备用库必须将重做日志写入磁盘后才能确认。这种组合确保了最高的数据安全性（无数据丢失），但每次提交都需要等待网络传输和磁盘 I/O，从而导致 "log file sync" 变慢。

由于在 Top Events 中有明显的 GC（Global Cache）相关等待，我接着查看了 "RAC Statistics" 部分。

数据显示，无论是 CR 块还是 Current 块的 flush time 都非常慢，原因显然与 "log file sync" 的缓慢一致。而缓慢的 flush time 又进一步导致了更多 GC 相关等待事件的出现。

与客户进一步沟通得知，这是一个实验室信息管理系统（LIS），为了保障数据安全，他们在一台虚拟机上搭建了备用库。虚拟机性能较弱，导致备用库响应慢，从而拖慢了主库。

我建议客户将log_archive_dest_2参数中的 SYNC 改为 ASYNC，将 AFFIRM 改为 NOAFFIRM，以异步方式传输重做日志。客户最终选择直接关闭备库，问题也随之解决。

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

关于号主，姚远：

Oracle ACE（Oracle和MySQL数据库方向）

华为云最有价值专家

《MySQL 8.0运维与优化》的作者

拥有数十项数据库认证

曾任IBM公司数据库部门经理

20+年DBA经验，服务2万+客户

精通C和Java，发明两项计算机专利

两次获得国家部级奖