干过数据库性能排查的人大概都见过log file sync霸占 AWR Top 5 的场景。这个等待事件本身不复杂就是会话提交事务时在等 LGWR 把日志写完。真正复杂的是导致它飙高的根因可以藏得很深尤其是当系统里跑着 Oracle 12c 的 Adaptive Scalable Log Writer 时表面上看起来是日志写入瓶颈实际却可能是这个新特性“帮了倒忙”。我见过不少同行在这个问题上绕了弯路本文就把这个场景掰开揉碎讲清楚它是什么、为什么会反噬提交路径、怎么确认、怎么处置。这个主题适合正在维护 12.1.0.2 或 12.2 以上版本、遇到过 log file sync 异常上升的 DBA也适合准备上线 12c 并想提前避坑的架构师。我会按真实的排查顺序来写而不是按官方文档的顺序。1. 先搞懂 Adaptive Scalable Log Writer 到底做了什么1.1 从单 LGWR 到“日志写入进程池”的演进在 10g、11g 时代日志写入全靠一个 LGWR 进程。它把 redo log buffer 里的内容搬出来写入当前在线日志文件写完后通知所有等待在这个提交点上的会话“可以返回了”。这个过程是串行的一个提交、一次写盘、一次返回。那时候为了提高吞吐Oracle 引入了 group commit批量提交机制多个会话的提交请求可以攒在一起一次写盘、统一通知这也是 log file sync 平均等待能压下来的核心手段。进入 12c 后内存里 log buffer 的分配机制变了引入了多 redo strand 的设计每个 strand 有独立的分配区域降低了高并发下的 redo allocation 竞争。到了 12.1.0.2Oracle 又向前迈了一步让 LGWR 可以根据负载动态派生出额外的日志写入工作者进程这就是 Adaptive Scalable Log Writer 的雏形。12.2 里更进一步引入 Log Writer Process Pool多个日志写进程可以分别承担不同 redo 区域的写盘工作。用生活化的类比来说以前是一个收银员在柜台前给所有顾客结账人多就得排队虽然可以一次给好几个人一起结group commit但高峰还是吃力。后来改成多个收银员同时开工听上去吞吐应该上去了但问题在于——这些收银员共用一本台账互相之间需要对账、交接、确认进度一旦协调成本高于结账本身节省的时间顾客反而等得更久了。log file sync 就是这么被拖高的。1.2 自适应机制如何决定“扩展”自适应体现在两处一是是否启动额外的日志写进程二是启动几个。Oracle 会根据系统负载、CPU 数量、日志产生速率、提交频率等指标做动态判断。理论上的目标是当单 LGWR 成为瓶颈时通过并行写盘来降低日志写入时间从而缩短提交等待。这套机制涉及一些内部进程不仅限于一个。在 12.1.0.2 中主 LGWR 仍然存在额外工作者以从属进程形态出现在 12.2 的进程池模式下会看到多个lwtr进程同时存在各自负责独立的 redo 写入区域。这些进程之间需要协调的公共资源包括log buffer 中 strand 的分配状态、不同写入区间的完成进度、以及通知提交会话“写完了”的信号机制。我见过一些系统在 40 核以上的 OLTP 环境里提交频率很高、单次事务很小恰好是自适应机制最喜欢“插手”的场景。负载采样器发现 LGWR 的写等待上升就触发扩容逻辑派生更多日志写进程。表面看是“对症下药”实际上在这个读写比例极其敏感的高并发小事务场景下多进程协调的开销直接叠加到了每次提交的关键路径上最终 log file sync 非但没降反而比单 LGWR 时高出 30% 甚至更多。1.3 设计初衷与实际的偏差设计者的初衷很明确通过并行化缩短日志写入时间。但要缩短 log file sync前提是并行写入带来的收益要大于协调成本。这在以下场景中是成立的比如日志写入量极大、单个日志文件所在的存储能够支撑真正的并发写、且提交型负载不是唯一主导。但如果存储路径本身是串行化的——在很多中端存储、虚拟化共享磁盘、乃至某些云盘场景下多个进程并发写同一文件并不比单进程顺序写更快——并行化就只剩下了额外开销。再叠加另一个因素自适应扩展和收缩是动态的进程的启动、停止、状态同步都会引入额外等待。在我的现场观察中这类系统里 ASH 里除了 log file sync往往还会出现与进程间通信、共享结构等待相关的事件。如果你在 AWR 里看到 log file sync 和这些“不常见”的等待同时出现就要高度怀疑是日志写入器扩展机制在捣乱。2. 怎么确认 log file sync 就是被它“坑”的2.1 先看现象哪些典型现场值得怀疑不是所有 log file sync 飙高都跟 Adaptive Scalable Log Writer 有关所以第一步是快速过滤出可疑特征。我一般先看五点数据库版本12.1.0.2 及以上12.2 更常见尤其是 12.2 的 RAC 环境。CPU 核数多通常不低于 32 核核心多时自适应机制更容易触发并行。负载特征高并发小事务、频繁短提交像是支付、订单、会话管理类的业务。AWR 中 log file sync 排在 Top 事件前列且平均等待时间超过 5ms——正常状态应该在 1-3ms 之间。操作系统层面能看到多个lwtr进程或者查询v$lgwr_worker_info能看到多个 worker 处于活跃状态。如果上面几条同时命中基本可以进入下一步深入验证。但要注意这还只是“可疑”不能直接下结论。2.2 用 AWR/ASH 把根因钉死要拿到确凿证据我建议走三条线交叉验证第一确认扩展进程是否真的在工作。查询v$lgwr_worker_info这个视图会列出日志写入工作者进程的状态、处理的 redo 区域、以及最近的活动统计。如果多个 worker 都有持续的写入活动说明扩展机制正在活跃使用中。同时可以查v$process或操作系统层确认lwtr进程数量。第二统计等待事件分布。从 AWR 报告或者直接查dba_hist_system_event对比同一时段内log file sync、log file parallel write、log buffer space等事件的变化趋势。这里有个关键点如果只看到 log file sync 高而 log file parallel write 并不高说明磁盘写盘本身不是瓶颈时间消耗在“协调和通知”上恰好符合多日志写进程协调开销过大的特征。第三做一次“开关对照实验”。在维护窗口把相关隐藏参数设为关闭值重启实例用相同负载跑一段时间对比 log file sync 的平均等待。这是最直接的判定手段比任何分析都更有说服力。注意实验前后要保证业务负载形态相近最好在同一个业务周期内完成。2.3 确认后要做的备份与回退准备一旦高度怀疑不要直接在生产库上改参数。我在处理这类问题时操作顺序是固定的先备份当前 spfileCREATE PFILE/tmp/pfile_before_change.ora FROM SPFILE;记录基线数据当前 log file sync 平均值、Top 等待事件、每秒提交次数。提前写好回退方案如果关闭后出现新的问题如何在最短时间内恢复原参数并重启。选择变更窗口优先选业务低谷同时预留足够长的观察期至少覆盖一个业务高峰。生产环境最怕的不是问题本身而是改了参数之后说不清楚是变好了还是变差了。所以基线和观察方案必须在动手之前定好。3. 解决实操参数调整与效果验证3.1 关键隐藏参数清单12.1.0.2 与 12.2 分别处理先说结论解决这个 log file sync 问题的核心是限制或关闭自适应日志写入器的扩展能力。不同版本要处理的参数不一样。12.1.0.2 中主要控制开关是_use_adaptive_log_writer_slaves默认值为 TRUE。这个参数控制 LGWR 是否允许动态创建额外的日志写从属进程。要关闭它ALTER SYSTEM SET _use_adaptive_log_writer_slavesFALSE SCOPESPFILE;12.2 及以后除了上述参数还有一个更高层的开关_use_adaptive_log_writer以及进程池相关参数例如限制最高实例数_lgwr_pool_hwm_instances如果只是想限制扩展规模而不是完全关闭可以将_lgwr_pool_hwm_instances设置为 1相当于只保留一个进程池实例。但我实际遇到过的场景绝大多数是直接关闭更省心因为问题是协调开销太大而不是并行不够。3.2 单实例/ RAC 场景的调整步骤以 12.2 RAC 两节点为例完整的操作流程如下。在所有节点上先执行检查SELECT inst_id, name, value FROM gv$parameter WHERE name IN (_use_adaptive_log_writer_slaves,_use_adaptive_log_writer);然后逐节点修改注意这里必须是SCOPESPFILEALTER SYSTEM SET _use_adaptive_log_writer_slavesFALSE SCOPESPFILE; ALTER SYSTEM SET _use_adaptive_log_writerFALSE SCOPESPFILE;单实例环境只需要执行一次RAC 环境要在每个节点上各执行一次或者使用sid*的范围设定。修改完成后重启所有实例。对于 RAC通常是滚动重启逐个节点重启保持业务不中断。重启后再次查询参数值和lwtr进程数量确认已经回落。这里有个容易踩的坑很多 DBA 以为ALTER SYSTEM命令执行完就生效了但这类隐藏参数属于静态参数必须重启。如果你改完没重启就急着下结论说“没用”那多半是自己误判了。3.3 不改参数时还能做什么关闭参数不是唯一出路有些场景下业务上不方便重启或者在重保期间不能动那就得考虑从其他路径缓解 log file sync。存储 IO 路径redo 日志文件放独立的高速存储最好是支持低延迟单块写入的设备。注意“支持并发写”这个前提如果存储本身对并发写不友好多进程写反而更糟。redo 文件大小扩大在线日志文件尺寸减少日志切换频率。切换瞬间的 checkpoint 和文件操作会放大提交延迟别把它和自适应写进程的影响混在一起。提交参数评估业务是否能接受commit_wait和commit_logging的调整通过延迟写或者批量提交来换取响应时间下降。这个必须和业务团队确认因为涉及事务持久性语义。应用层减少无意义的 commit合并小事务。很多 log file sync 飙升的系统本质是每秒提交次数太高给小事务“减频”往往立竿见影。上述手段可以和关闭自适应写进程组合使用但我个人建议不要同时上太多变量否则出了问题很难定位是哪个改动带来的收益或负收益。3.4 效果验证读哪些数据才算真的好了改完参数、重启完接下来要回答的问题是到底好没好判断依据不能只看 log file sync 的数值我通常看三组数据。第一组等待事件变化。log file sync 的平均等待是否回落到正常范围Top 5 事件里它是否退出了前几名的位置。第二组应用侧指标。每秒提交次数、事务吞吐量在同等负载下是否保持不变或上升这点很关键——如果 log file sync 降了但业务吞吐也掉了说明引入了另一个瓶颈。第三组日志写入相关进程数量。v$lgwr_worker_info里是否只剩一个活跃进程OS 层lwtr进程数量是否恢复预期。观察周期至少要覆盖一个完整的业务高峰不要只看 10 分钟就下结论。我曾经遇到一个系统改动后前半小时数据好看进入业务高峰后反而出现新的等待原因是关闭扩展进程后单 LGWR 写能力不足。这也说明关闭自适应写进程并非在所有系统上都正确有些系统确实需要并行写盘。4. 常见问题与排查技巧实录4.1 常见误区Log file sync 高不等于磁盘慢这是我见过最多的误区。很多 DBA 一看到 log file sync 高第一个念头就是“磁盘太慢了上 SSD”。实际上log file sync 等待的是 LGWR 完成“写日志并确认”的完整过程这个时间由三部分组成日志数据从 log buffer 复制到日志文件的写入时间、写完后的确认通知时间、以及如果存在多写进程时的协调时间。磁盘 IO 延迟只影响第一部分而自适应写进程引入的协调开销影响的主要是第二和第三部分。所以会出现一个现象redo 已经写进了存储但会话仍然在等待而且等的时间比写盘时间还长。判断方法是同时看log file sync和log file parallel write两个事件如果前者远高于后者意味着问题不在物理写盘而在写盘之外的通路。另外一个相关误区是“redo 太小导致切换频繁”。日志切换确实会带来额外延迟但它一般会在 AWR 中表现为log file switch completion或log file switch (checkpoint incomplete)等事件。如果你看不到这类事件就不应该把矛头指向 redo 文件大小别被表象带偏。4.2 典型场景对照表场景特征主要影响因素推荐动作12.2 RAC高并发小事务多个lwtr进程活跃写进程池协调开销关闭_use_adaptive_log_writer必要时保持_use_adaptive_log_writer_slavesFALSE12.1.0.2 单实例多核 OLTPlog file sync 异常高从属写进程同步开销设置_use_adaptive_log_writer_slavesFALSEredo 存放在 ASM 上磁盘写延迟低但提交仍慢日志写进程间协调 提交通知路径先确认 log file parallel write 时间若并行写正常则调整写进程参数虚拟化共享存储单卷 IO 能力有限IO 本身无法并发提速不盲目开并行优化存储配置或减少提交频率业务侧每秒提交次数极高commit 路径整体压力应用层合并事务配合关闭自适应写进程4.3 几个让我印象深刻的坑第一个坑改完参数没重启白白折腾了一个维护窗口。前面已经提过但如果再强调一遍——这个参数改动后不会在线生效你执行完ALTER SYSTEM后查v$parameter看到的值还是旧的千万别误判。12.2 之前某些版本对_use_adaptive_log_writer_slaves的改动可以动态修改但 12.2 的进程池相关参数基本都要重启操作前先确认版本行为。第二个坑单独设置一个参数不生效。我在 12.2 RAC 上处理过一个案例只把_use_adaptive_log_writer设为 FALSE启动后lwtr进程数量还是多于一个。后来把_use_adaptive_log_writer_slaves也一起关闭才真正回到单进程模式。所以 12.2 上两个参数最好一起改动然后再验证进程数量。第三个坑关闭自适应写进程后log buffer 空间的等待上升。某系统关闭扩展后 log file sync 确实降下来了但log buffer space开始冒头。原因很简单少了一个写进程log buffer 的消耗速度变慢缓冲区压力变大。解决办法是适当增大 log buffer或者从应用侧降低提交频率。这也提醒我调优动作做完必须跟踪周边事件不能只看目标指标。5. 个人经验何时该怀疑它何时该先查别的5.1 我的快速判定路径如果你现在正被 log file sync 困扰我建议按这条路来定位十分钟内就能给出方向先看版本。低于 12.1.0.2 基本和本文主题无关直接查 IO 延迟和提交频率。12.1.0.2 以上查v$lgwr_worker_info和 OS 层lwtr进程数。如果活跃 worker 只有 0 或 1 个这个特性大概率不是主因。对比 log file sync 和 log file parallel write。差别越大越说明瓶颈不在磁盘。看每秒提交次数。低并发、低提交频率的系统自适应写进程没机会捣乱。全部可疑条件命中后再考虑做开关实验。不建议上来就动参数先把观察做足。5.2 哪些系统不适合一刀切关闭说了这么多“关掉它”但我也得实话实说不是所有系统都适合关闭。判断依据是每秒日志产生量以及写入路径的特性。如果一个系统的 redo 生成量极大单 LGWR 确实跟不上写入要求而存储又支持并发写那么保留自适应扩展、但把进程数限制在一个合理范围可能比彻底关闭更合适。可以用_lgwr_worker_count或_lgwr_pool_hwm_instances这类参数来控制扩展规模而不是消灭它。如果你的系统恰好是高并发小事务、提交频繁的典型 OLTP而自适应写进程带来的协调开销已经成为主要矛盾那就不要犹豫关闭扩展、回归单写进程模式回到 group commit 的主航道上来。这个取舍本质上是在“并行写盘的吞吐收益”和“多进程协调的延迟代价”之间做权衡。搞清楚这两者的关系我就不信你还会被 log file sync 的名字吓住。最后分享一个每次遇到这类问题我都会提醒自己的经验数据库参数只是表象存储特性和负载形态才是决定因素。你可以轻松改掉一个隐藏参数但改完之后系统是否真的变好取决于你对自己环境里“写入到底快在哪、慢在哪”的理解有多深。多花几分钟看数据比急着敲命令可靠得多。
