log buffer space等待本质是LGWR I/O瓶颈而非缓冲区小；需优先检查log file parallel write平均等待是否>10ms及redo log space requests每秒是否>1，盲目调大LOG_BUFFER反而加剧log file sync等待。
log buffer space 等待直接拖慢 COMMIT
当 log buffer space 等待频繁出现时，commit 不是“慢”，而是被卡在等待日志缓冲区腾出空间——lgwr 还没把旧重做刷走，新重做就写不进去了。这不是应用层能靠改 sql 语句绕开的问题，必须从日志生成速率和 lgwr 刷盘效率两头堵。
检查 LGWR 是否真的被 I/O 卡住
先别急着调大 LOG_BUFFER，90% 的真实瓶颈其实在磁盘。关键看两个指标：
-
v$system_event中log file parallel write的AVERAGE_WAIT：若 > 10ms，说明 LGWR 写磁盘太慢，不是 buffer 小，是盘慢 -
v$session_wait里log buffer space的seconds_in_wait值持续 > 5s，基本可确认是 I/O 或 LGWR 被阻塞 - 查
v$sysstat的redo log space requests，该值每秒 > 1 就已异常，> 10 表明缓冲区几乎时刻告急
调大 LOG_BUFFER 反而可能加重 log file sync
盲目增大 LOG_BUFFER 是典型误区。因为 LGWR 触发刷盘的阈值之一是缓冲区 1/3 满（由隐含参数 _log_io_size 控制），buffer 从 8MB 调到 24MB 后，触发点变成 8MB —— 意味着 LGWR 更少、更晚地刷盘，导致 log file sync 等待飙升。实操中应遵循：
- 仅当
log file parallel write平均耗时 redo log space requests 仍高频时，才考虑小幅上调LOG_BUFFER - 每次调整不超过当前值的 25%，例如从 8MB → 10MB，而非翻倍
- 修改后必须重启实例，且要监控
log file sync的平均等待是否同步恶化
真正有效的三类落地动作
比调参更关键的是控制重做生成节奏和释放路径：
- 将联机重做日志文件放在独立 SSD 或裸设备上，严禁与数据文件共用 RAID5 卷；RAID10 是底线
- 批量 DML 改用
INSERT /*+ APPEND */+NOLOGGING（仅限非关键历史表），减少重做量 90% 以上 - 拆分长事务：把
UPDATE accounts SET balance = balance - 10 WHERE ...百万行循环，改成每 1000 行COMMIT一次，避免单次重做堆积
log buffer space 本质是系统级水位警报，不是孤立参数问题。最容易被忽略的是：它常在 log file switch (checkpoint incomplete) 高发时伴生出现——此时真正要查的是检查点推进是否受阻，而不是只盯着 buffer 大小。
