log buffer space等待严重表明LOG_BUFFER容量不足，必须扩容；需通过v$system_event和v$sysstat确认等待时长与重试次数，redo buffer allocation retries＞100即需干预；LOG_BUFFER为静态参数，调整后须重启，且值须为OS块大小整数倍；建议从8–16MB起步，每次增50%，并同步评估SGA分配与LGWR写入效率。
直接结论：log buffer space 等待严重，说明重做日志缓冲区（LOG_BUFFER）已成瓶颈，必须扩容，且不能靠“微调”解决——这是硬容量问题。
查证是否真由 log buffer space 引发性能问题
别只看告警或感觉慢，先确认等待事件占比和重试次数：
- 运行
SELECT event, time_waited_micro/1000000 AS sec FROM v$system_event WHERE event = 'log buffer space'，若单次等待累计超 1–2 秒/分钟，已属异常 - 关键指标是
redo buffer allocation retries：执行SELECT name, value FROM v$sysstat WHERE name = 'redo buffer allocation retries'，值 > 100 就需干预，> 1000 表明缓冲区长期吃紧 - 注意排除干扰：如果同时存在大量
latch: redo copy等待，可能是 CPU 或并发争用导致 LGWR 响应延迟，而非单纯LOG_BUFFER太小
调整 LOG_BUFFER 参数的实操要点
LOG_BUFFER 是静态参数，修改后必须重启数据库，且大小受操作系统块大小约束：
- 值必须是操作系统块大小（通常是 4KB 或 8KB）的整数倍，否则启动报错
ORA-00823: specified value of log_buffer is too small - Oracle 11g 官方建议起点为 8 MB，高并发 DML 系统（如 Hyperion、ERP）建议从 16 MB 起步
- 每次调整幅度建议增加 50%，例如从 8 MB → 12 MB → 18 MB，避免一步调得过大浪费内存
- 执行命令：
ALTER SYSTEM SET log_buffer = 12582912 SCOPE=SPFILE（12 MB = 12 × 1024 × 1024），切勿用SCOPE=BOTH—— 该参数不支持动态生效
LGWR 写入效率低也会放大 log buffer space 等待
即使 LOG_BUFFER 合理，若 LGWR 写磁盘太慢，缓冲区照样积压。常见瓶颈点：
- 重做日志文件放在慢盘（如 SATA 盘、NFS 共享存储）上：优先迁移到本地 SSD 或高性能 SAN LUN
- 重做日志组过小（如每组仅 50 MB），导致频繁日志切换，触发 LGWR 频繁刷盘：建议单组 ≥ 500 MB，减少切换频次
- 归档模式下 ARCH 进程跟不上 LGWR（尤其在大批量 DML 后）：可临时关闭归档测试，或检查归档目标 I/O 是否饱和（
v$archive_dest_status中STATUS为ERROR或DELAYED）
容易被忽略的关联影响
调大 LOG_BUFFER 不是孤立操作，需同步检查 SGA 分配是否合理：
-
LOG_BUFFER占用的是 SGA 中的固定区域，不参与 ASMM 自动管理，所以增大它会直接挤占shared_pool_size或db_cache_size的可用空间 - 若使用 ASMM（
SGA_TARGET已设），增大LOG_BUFFER后，务必重新评估shared_pool_size和db_cache_size的最小值，防止共享池频繁 aging 导致硬解析上升 - 特别注意：
LOG_BUFFER过大会增加实例崩溃后的恢复时间（因为更多未写盘的 redo 需重放），生产环境不建议无限制堆高，16–32 MB 已覆盖绝大多数 OLTP 场景
