提交太频繁需查 user commits 和 user rollbacks 每秒速率，若 AWR 中平均每秒超 200 次且 user calls / (user commits + user rollbacks)
怎么看是不是提交太频繁？
直接查 user commits 和 user rollbacks 的每秒速率，比看等待时间更准。如果 awr 报告里 “key instance activity stats” 图中平均每秒提交超过 200 次，尤其伴随 user calls / (user commits + user rollbacks)
- 用这个 SQL 快速算：
SELECT ROUND(SUM(CASE WHEN NAME = 'user commits' THEN VALUE END) / 3600, 2) AS commits_per_sec FROM v$sysstat WHERE NAME IN ('user commits', 'user rollbacks'); - 别只盯着单次
log file sync平均等待时间——它可能才 3ms，但每秒等 300 次，总延迟就压垮了响应。 - 容易踩的坑：把 PL/SQL 循环里每个
INSERT后跟COMMIT当成“安全写入”，其实是把 LGWR 变成高频打点器，彻底废掉组提交（Group Commit）。
怎么确认是 Redo I/O 瓶颈？
关键不是看磁盘忙不忙，而是看 log file parallel write 和 log file sync 的等待时间是否高度一致——如果两者平均值都卡在 8–15ms，且 log file parallel write 的 90% 分位也 >5ms，I/O 就是瓶颈。
- 查 LGWR 写日志的真实耗时：
SELECT event, wait_time_milli, wait_count FROM v$event_histogram WHERE event = 'log file parallel write';
- 检查存储是否被共享：Redo 日志文件千万别和数据文件、归档日志混放在同一 RAID 5 LUN 上——RAID 5 的写惩罚会把顺序小写变成随机大写，LGWR 直接瘫痪。
- 别只信 iostat 的 %util：有些 NVMe 盘 %util 95% 但延迟仍 await 或
r_await/w_await。
DBA 能临时缓解，但不能绕过应用层问题
Oracle 10g 起支持 commit_write 参数调成 BATCH,NOWAIT，前台不等 LGWR 写完就返回，能压低 log file sync 等待，但代价是实例崩溃时可能丢最近几毫秒事务——业务敢不敢接，得一起拍板。
- 在线生效，不用重启：
ALTER SYSTEM SET commit_write='BATCH,NOWAIT' SCOPE=BOTH;
- 副作用明显：开启后
log file parallel write的写次数下降，但单次写量变大，可能触发更大的 I/O 峰值；同时redo writinglatch 争用可能转移成redo allocationlatch 争用。 - 更隐蔽的坑：
NOLOGGING或临时表虽能减 redo，但会破坏 Data Guard 同步、闪回、RMAN 备份一致性——不是所有场景都能用。
别漏掉 RAC 和 DG 这两个“影子推手”
单机没异常，但 RAC 环境下 log file sync 高，先盯 gc cr grant 2-way 或 gc buffer busy acquire 是否伴生；DG 环境下则重点看 LGWR-LNS wait on channel ——备库网络延迟或重做 Apply 慢，会拖住主库 LGWR 的 SCN 同步，前台就卡在 log file sync。
- RAC 场景查私网延迟：
ping -s 8192 <private_ip></private_ip>
，如果抖动 >1ms 或丢包，log file sync就会毛刺化。 - DG 场景快速定位：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY WHERE PROCESS IN ('LNS','RFS','MRP0');若 LNS 的SEQUENCE#远超 RFS，说明主库在等备库 ACK。 - 最容易被忽略的一点：控制文件争用也会冒充
log file sync高——比如 RMAN 频繁备份控制文件，或 ASM 中控制文件所在磁盘 IO 满载，会引发大量control file sequential read，间接拖慢提交路径。
