log buffer过小会导致redo buffer allocation retries飙升，该值持续非零（如每小时上万）即表明缓冲区不足；需结合log file sync等待升高及awr报告对比验证。
看 redo buffer allocation retries 这个指标是否飙升
这个值直接反映 log buffer 不够用：每次用户进程想往重做缓冲区写日志，但发现没空间，就得等、再试一次——一次失败就是一次 redo buffer allocation retries。如果它在 AWR 报告里持续非零（比如每小时增长上万），基本可以断定 buffer 太小。
查法很简单，在报告的 Instance Efficiency Percentages 下方或单独执行：
SELECT name, value FROM v$sysstat WHERE name = 'redo buffer allocation retries';
注意对比两份 AWR 报告（正常 vs 异常时段）：若异常时段该值突增几十倍，而 log file sync 等待也同步升高，问题就闭环了。
结合 log file sync 和 log file parallel write 等待事件交叉验证
log file sync 高，常被误判为磁盘慢；但若同时 redo buffer allocation retries 也高，真实原因其实是 log buffer 频繁被填满、触发更密集的日志刷盘，进而拉高 sync 延迟。
-
log file sync平均等待时间 > 5ms 就值得警惕，> 10ms 很可能已受 buffer 限制拖累 -
log file parallel write的平均写入时间如果正常（ - 检查 AWR 中 Load Profile 的
Redo size per second：若稳定在 1–2 MB/s 以上，8 MB 的默认log_buffer很容易成为瓶颈
调整 log_buffer 时避开常见硬伤
Oracle 11g 对 log_buffer 的修改有隐性约束，不按规则来会报错或无效：
- 必须是操作系统块大小的整数倍（通常是 4KB 或 8KB），不能直接设
12M，得写成12582912（12×1024×1024）或确认对齐 - 不能在线动态修改：需重启数据库生效，且修改前建议先停业务或选维护窗口
- 别一步到位设太大——比如从 8MB 直跳到 64MB。Oracle 建议每次只增 50%，观察 AWR 中
redo buffer allocation retries是否归零再决定下一轮 - 注意和
_log_io_size隐含参数的潜在冲突（11g 中默认启用），过大 buffer 可能导致单次写入延迟上升，反而恶化log file sync
改完后必须验证的三件事
改完 log_buffer 并重启，不能只看参数生效了就认为搞定：
- 确认
v$parameter中log_buffer值已更新，且isdefault = 'FALSE' - 跑至少 30 分钟业务负载，再生成新 AWR 报告，重点盯
redo buffer allocation retries是否停止增长（不是变小，是“不再新增”） - 对比前后两份 AWR 的
log file sync平均等待时间，下降 30% 以上才算有效；若没变化，要回头查是不是应用层 commit 太频繁，或者 Redo Log 文件本身太小（引发频繁 switch，间接加剧 buffer 压力）
真正卡点不在参数值本身，而在 buffer 大小、redo 日志组容量、应用 commit 频率这三者的耦合关系——调 buffer 单独动一环，往往治标不治本。
