先说明一个可能被很多DBA忽略的常识Oracle 12c 的 Adaptive Scalable Log Writer 是默认开启的而这个特性在某些高频小事务场景里恰恰可能成为 log file sync 等待飙升的推手。这不是说 Oracle 引入了错误的设计而是说在实际负载下面这种“自适应”和“可扩展”并不是免费的它需要额外的进程协调成本在特定条件下反而放大了提交路径上的延迟。这篇文章不打算绕弯子直接围绕“Oracle 12c Adaptive Scalable Log WriterASLW导致 log file sync 等待”这个现象展开。我会从问题现象开始讲说明 ASLW 的机制、为什么它会引发问题、怎么通过 AWR 和系统视图确认元凶以及最终的处理方案和参数调整思路。如果你是刚从11g 升级到12c 的 DBA或者正在排查一个“什么都正常但就是提交慢”的 OLTP 系统这篇内容值得仔细看一遍。1. 先把 log file sync 的现场看清楚1.1 什么是 log file sync它在等什么要理解 ASLW 为什么会导致 log file sync得先清楚这个等待事件本身在等什么。一个事务执行 commit 的时候前端会话需要把该会话产生的 redo 记录从 SGA 的 log buffer 里写进在线日志文件并且要等 Oracle 确认这部分 redo 已经落盘事务才算真正提交完成。前台会话等这个写入确认的过程等待事件就是 log file sync。可以把它理解为你去银行柜面办转账柜员确实受理了但必须等系统后台把流水真正记录到磁盘上、确认不会丢才会告诉你可以走了。你在柜台前面等着的那段时间就是 log file sync。如果后台系统经常卡顿银行会排长队Oracle 这边就是大量会话堆积在 log file sync 等待上。这里有一个容易混淆的地方后台进程 LGWR 实际写日志文件的等待事件是 log file parallel write而前台会话等提交确认的等待是 log file sync。如果 log file parallel write 的平均等待很低、吞吐正常但 log file sync 依然很高说明存储本身不是瓶颈问题出在“通知和调度”这条链路上ASLW 就是这条链路上一个新引入的变量。1.2 影响范围谁最容易踩中这个坑ASLW 引发的问题有明显的负载特征高频小事务、高并发提交、CPU 核数较多但单次事务产生的 redo 很小。这种负载形态在互联网支付类库、订单中心、会员积分系统里特别常见。事务本身处理只要几百微秒但 commit 要等一次日志写确认等待被放大到毫秒级整个系统的响应时间就上去了。升级到12c 之后有的系统会发现自己明明没有动存储、没有改应用业务高峰期却出现大量 log file sync 等待AWR 里 Top 5 事件中它名列前茅。这时候不要急着怀疑存储厂商也不要一上来就调库先搞清楚是不是 ASLW 这个默认开启的新特性在“帮倒忙”。2. Adaptive Scalable Log Writer 到底改了什么2.1 从单一 LGWR 到“可以扩容”的日志写进程在 Oracle 11g 及更早的版本里日志写入基本是单进程模型实例只有一个 LGWR所有会话提交产生的 redo 最终都由它统一写盘。这种模型的优点是简单可控、顺序写特性好缺点是当 CPU 核数非常多、redo 生成速率极高时LGWR 可能成为单点瓶颈redo buffer 空间被快速耗尽导致前台会话无法继续分配 redo 空间进而出现 log buffer space 等额外等待。Oracle 12c 引入 ASLW 的初衷就是解决这个扩展性问题让 LGWR 在特定条件下可以派遣多个从属写进程并行地帮忙把 log buffer 里的块刷进在线日志文件。对于一个几百核的大机器、redo 产生量极大的场景这种并行确实可能提升写吞吐。从属进程的数量不是写死的Oracle 会依据系统负载动态调整。12.1 里面从属进程最多可以扩展到 20 个左右具体数值视版本和平台而定。启用这一特性默认是通过控制参数_enable_adaptive_log_writer实现的如果不显式关闭引入12c 后它就是 true。2.2 看起来很美自适应与可扩展的代价问题就出在“动态调整”这几个字上。ASLW 的控制器需要频繁地采样、判断当前是否需要增加或减少从属进程这些决策涉及对日志写路径上加锁保护、对多个写进程的任务切分、以及写完之后汇总确认。这些开销在低并发时几乎可以忽略但在高频小事务场景里每次提交都要走一遍这套“增加协调环节”的路径延迟自然就上来了。另外还要考虑存储设备的物理特性。在线日志文件本质上是顺序写为主单一 LGWR 会尽量把多个会话产生的小块 redo 攒成较大的连续 I/O 再落盘对机械盘和阵列来说这是最友好的方式。启用了 ASLW 之后多个从属进程同时刷盘可能把原本连续的写入拆散成多个并行的 I/O 流刷盘顺序不再那么规整。如果底层存储恰恰是比较老派的机械盘或缓存较小的阵列写放大和寻道开销就抵消了并行带来的收益。有一种很常见的误判是看到“并行”就以为更快。实际上在数据库日志写这个场景下单进程顺序写的效率往往比多进程并行写更高因为日志写入的核心矛盾不是“写不过来”而是“确认链路太长”。ASLW 解决的是吞吐扩展问题不是延迟优化问题对以低延迟为目标的小事务 OLTP 来说它的收益不明显但协调成本是实打实地加在了每次提交路径上。2.3 为什么升级到12c 后反而更慢很多团队从 11g 迁移到 12c 时硬件和存储都是升级过的CPU 也更多了结果性能不升反降最终定位到 log file sync。原因并不神秘11g 时代 LGWR 单进程顺序刷盘路径短、开销小12c 默认打开 ASLW提交路径上多了一层“要不要叫从属进程、叫几个、怎么分任务”的判断即使最终没有真的派出从属进程这层判断本身已经增加了 CPU 和锁的开销。还有一类情况是 ASLW 确实派出了从属进程但多个进程之间需要协调共享的 redo 块边界协调锁竞争反而使得整体吞吐不如单一 LGWR。尤其是在事务很快、每次提交 redo 量都很小的系统里日志写的瓶颈根本不在磁盘吞吐而在进程间通讯和锁的获取释放这时候 ASLW 的优势完全发挥不出来反而加重了等待。所以面对“log file sync 居高不下”的12c 系统把 ASLW 列为重点怀疑对象是完全合理的它不是在极少数边缘环境才会出问题而是出现概率比想象中高得多。3. 怎么锁定 ASLW 就是元凶3.1 AWR 报告里的三个关键信号排查时最常用的入口还是 AWR 报告。不要光看 Top 5 事件那只能说明 log file sync 严重不能说明是 ASLW 引起的。真正需要对比的是下面这组信息Top 5 事件中 log file sync 排名靠前且平均等待时间偏高同时 log file parallel write 的平均等待时间很低比如在 2ms 以内事务提交次数高、单次 redo 量小比如每秒几千次 user commits但每次 commit 对应的 redo 只有几 KB。这三个信号同时出现ASLW 的嫌疑就非常大。传统排查文档会让你先看存储层也就是 log file parallel write 的响应时间。如果这个值也高先解决存储问题再回头看 log file sync。但在这个场景里存储大概率是正常的因为 ASLW 引发的是调度和确认链路问题不是物理写盘性能问题。这也是为什么不少人一开始走了弯路反复找存储团队要性能报告结果对方丢过来一堆“磁盘响应时间正常”的数据问题依然没有头绪。在 AWR 的 12c 版本中日志写进程部分会额外展示与可扩展日志写相关的统计信息比如当前活跃的从属写进程数、从属进程发起的写次数和写块数等。如果你看到这些从属进程统计数据有大量变动或者实际写盘次数明显多于单一 LGWR 模式下的写次数就更加坐实了 ASLW 在参与刷盘。3.2 用系统视图确认 ASLW 状态AWR 是事后的快照如果现场还在持续可以用 SQL 实时确认 ASLW 的状态。隐含参数可以通过x$ksppi和x$ksppcv查询SQL 如下select a.ksppinm as parameter, b.ksppstvl as session_value, c.ksppstvl as instance_value from x$ksppi a, x$ksppcv b, x$ksppcv c where a.indx b.indx and a.indx c.indx and a.ksppinm like _enable_adaptive_log_writer%;正常情况下12c 中你会看到这个参数值是 TRUE。如果确认是这个特性导致的问题后续把它改成 FALSE 就是修复手段。同时可以查看后台进程里是否存在多个日志写从属进程select pname, program, pid, spid, status from v$process where pname in (LGWR,LG00,LG01,LG02) or program like %LG%;如果查询结果里面出现了 LG00、LG01 之类的进程并且它们处于活跃状态说明 ASLW 已经实际派出从属写进程在参与刷盘。注意 LGWR 本身只看得到一条从属进程的出现数量和频率可以作为判断依据。3.3 把其他干扰项逐个排除在拍板之前还有几个必须排除的因素。第一log buffer是否设置合理。如果 log buffer 太小前台会话可能因为 log buffer space 等待而间接拖慢 log file sync这种情况调整 ASLW 没用应该增大 log buffer。第二redo 日志文件是否存在频繁切换log file switch 类等待如果很高说明日志文件太小或归档慢也会叠加到 log file sync。第三是否存在日志文件放在共享存储、跨网络文件系统上导致的写延迟这种场景下 log file parallel write 平均等待会很高ASLW 不是主因。另外可以用v$event_histogram看一下 log file sync 的等待分布。如果大量等待落在 8ms 甚至 16ms 以上的桶里说明不是偶发抖动而是常态性劣化。同时对比正常时段的v$sysstat中 redo size 和 user commits 数据计算平均每个事务的 redo 量。平均提交 redo 量越小、提交频率越高ASLW 开销占比就越大这也可以用来向团队解释为什么先禁用 ASLW 做验证是合理的。4. 处理方案关掉它还是调优它4.1 最直接有效的验证性调整当各种证据都指向 ASLW 之后最稳妥的下一步不是直接在生产上改参数而是在测试环境先做一轮对比。修改方式很简单设置如下参数并重启数据库alter system set _enable_adaptive_log_writerfalse scopespfile;注意这个参数属于隐藏参数实际平台和版本不同是否支持动态修改会有差异。在我的经验里绝大多数情况下需要重启实例才能完全生效RAC 环境里需要所有节点都设置相同的值并逐个滚动重启。这也是为什么要先在测试环境验证不然直接改生产就得安排维护窗口。重启之后采集同样业务时段的 AWR对比 log file sync 的平均等待时间和 Top 5 事件中的占比。正常情况下会发现 log file sync 明显回落事务响应时间跟着下降。这里我踩过的坑是禁用后不要只看第一天的数据最好连续观察三到五个业务周期确认没有出现其他等待事件的反弹。4.2 替代方向先优化日志文件分布和配置如果测试环境里禁用 ASLW 确实有效但团队对“关闭一个默认特性”存在顾虑可以尝试先做几项日志配置优化看看能否缓解。比如把 redo 日志文件从慢速存储全部迁移到延迟更低的位置确保日志组分布在不同的物理磁盘或高带宽路径上把过小的日志文件统一扩大到 4GB 或 8GB减少日志切换频率增加日志组成员数量来提高可用性但不要指望增加组数能提高写入性能因为日志写入的目标是当前组。还有一种思路是降低提交频率典型手段是应用层把多个独立小事务合并到一个事务里批量提交。这在代码改不动的时候不好推进但从根因上看高频小事务是最适合触发 ASLW 副作用的负载。如果业务允许可以设计一个短周期批量提交窗口用时间换性能。4.3 参数不是“一关了之”还要验证配套依赖有些系统里除了_enable_adaptive_log_writer之外还存在其他与 redo 写路径相关的隐藏参数比如部分版本有_use_vectorized_log_writer之类的开关。在做 ASLW 禁用实验时尽可能保持其他参数不变只改一个变量这样出来的对比结果才是可靠的。数据证明是哪个参数的影响后再把变更纳入配置基线管理。我在实际项目中见过一种处理方式供了 ASLW 的利弊评估但最终没有盲目关闭而是在升级补丁之后先在测试环境用高并发提交脚本模拟压测发现新补丁版本里 ASLW 的表现比旧版本稳定很多于是保留了 ASLW 开启状态只是把 log buffer 调大了 50%bottleneck 就解掉了。这说明一个问题ASLW 并不是一定不能碰关键是每个版本的实现细节不同行为差异很大下单结论之前必须先测。4.4 修改后的回归测试清单无论选择关闭还是保留改了之后都要做一套完整的回归验证避免“按下葫芦浮起瓢”。我的实践清单包括对比 AWR 里 log file sync 和 log file parallel write 的趋势监控 v$session_wait 里 log file sync 的实时会话数是否出现高峰堆积检查 redo size、user commits、redo writes 是否明显变化观察存储侧写响应时间有没有异常最后跑一遍核心交易链路的回归用例确认业务响应时间达标。有一个容易被忽略的点关闭 ASLW 后如果系统曾经的瓶颈是 LGWR 单进程写不过来那么 log file parallel write 或 log file switch 等待可能上升。如果出现这种情况说明该环境原本确实依赖 ASLW 的扩展写能力需要回退参数再考虑从应用层优化提交模式这条路。说白了ASLW 对某些系统是蜜糖对另一些系统是砒霜不能拿药方直接套人。5. 常见问题速查与经验沉淀5.1 判断与处理速查表下面这张表是我遇到这类问题时快速定位用的放在这儿供参考观察项正常/健康状态疑似ASLW问题状态建议动作log file sync 平均等待远低于 5ms高于 5ms且频繁出现在 Top 等待事件进入排查流程log file parallel write 平均等待2~3ms 以内较低但仍存在前台 sync 高优先怀疑 ASLWuser commits 频率与业务形态匹配每秒几千次甚至上万次关注每次提交的 redo 量单次事务 redo 量相对稳定很小且提交极频ASLW 协调成本占比高后台日志写进程数LGWR 单进程出现多个从属进程LG00 等检查_enable_adaptive_log_writerredo 日志切换等待无持续 log file switch 等待无此等待排除日志切换因素不必调整日志大小log buffer space 等待几乎为 0明显且持续先增大 log_buffer 再观察表格里的数值不是硬性标准不同硬件平台和存储差异会很大关键是通过 log file parallel write 和 log file sync 的差值来判断“问题到底出在写还是出在等”。5.2 几次实战复盘后的心得处理过一次比较典型的 12.1.0.2 系统问题之后我对 ASLW 的认知变了不少。那是某公司的核心交易库从 11g 升级到 12c 后业务方反馈“偶尔会有提交延迟尖刺”AWR 里 log file sync 平均等待 9ms但 log file parallel write 平均等待不到 1ms。一开始我们换了存储链路、调大了 log buffer效果都不明显。后来查询x$ksppi发现_enable_adaptive_log_writertrue在测试环境压测对比后最终设置该参数为 false提交延迟尖刺消失了。复盘时有一个细节值得强调当时我们拉取了一段时间的v$event_histogram发现 log file sync 的等待分布有两个峰一个在 1ms 内一个在 8ms 左右这说明一部分提交被拖进了一个“慢路径”。后来追踪慢路径对应的会话发现它们大多发生在从属写进程被派出、进行任务交接的瞬间。这让我意识到用平均等待值来判断问题很容易被稀释看直方图才能发现这种“双峰”的异常。另一次是在 12.2 版本的某批处理器系统里ASLW 表现正常压测下比单 LGWR 模式吞吐高约 20%。这再次验证了版本和负载形态对 ASLW 的影响远比理论讨论复杂不能带着“关闭它”的思维走天下而是要回到数据本身。5.3 最后的补充建议如果你正在排查“Oracle 12c Adaptive Scalable Log Writer 导致 log file sync”的问题我的建议是先把 AWR 的第二个报告周期拉出来对比 log file sync 和 log file parallel write 的趋势线再看一下v$session_wait里 log file sync 的实时会话是否成批出现然后花十分钟查一下_enable_adaptive_log_writer的当前值顺手看一下后台有没有多出来的日志写从属进程。三件事做完大概就能判断方向。测试环境压测时建议直接用生产业务的高并发提交脚本不要用单纯的大量 insert 代替因为 commit 频率、redo 大小分布对 ASLW 行为影响极大。脚本里最好模拟“每个事务只更新几行、提交间隔小于 1ms”这种形态压出来的结果才有参考意义。压测时同时开启 AWR 和实时会话等待捕捉分析参数修改前后的数据差异。我个人在实际操作中的体会是ASLW 这类“自动化”特性在引入生产环境时都应该多留一个心眼尤其是数据库这种对延迟极度敏感的组件。默认开启不代表适合你的系统官方推荐也不代表每个负载都能受益。遇到 log file sync 高位等待时多看一眼这个参数也许就能帮团队省下一整周的排查时间。