Redo size per second 超过 10 MB/s 就需排查，应基于 AWR 报告 Load Profile 中的每秒逻辑 redo 字节数（非 Instance Activity Stats 累计值），OLTP 下持续 >10 MB/s 或单日翻倍即属异常，须结合 Top 5 Timed Events 和 SQL Statistics 定位根因。
Redo size per second 超过 10 MB/s 就该查，不是看单次快照值，而是用连续快照差值除以真实时间间隔算平均速率；AWR 报告里直接显示的 Redo size 是累计值，不能拿来直接除——那是常见误操作。
怎么看 Redo size per second 是否异常偏高
这个指标藏在 AWR 报告的 Load Profile 子节里，不是“Instance Activity Stats”里的累计 Redo size。它反映的是每秒生成的逻辑 redo 字节数（未压缩、未加密前），单位是 bytes/sec，数值要自己换算成 MB/s 才好判断。
- OLTP 环境下持续 > 10 MB/s 就需警惕；> 50 MB/s 基本指向批量 DML、全表更新或低效索引更新
- 别只比绝对值——拿业务高峰时段（如上午 10–11 点）连续 3 天的报告对比，若某天该值翻倍，说明执行逻辑出问题，不是自然增长
- 注意单位陷阱：报告里写
12489231就是约 12.5 MB/s，不是 KB 或 MB 显示，别看错小数点
为什么不能直接用 Instance Activity Stats 的 Redo size
Redo size 在 Instance Activity Stats 里是实例启动以来的累计字节数，属于“总账”，不是“流水”。直接拿两个快照的差值除以快照间隔（比如 60 分钟），会因以下原因失真：
- 快照时间有分钟级漂移，
END_INTERVAL_TIME不是精确采集完成时刻 - 刚好跨日志切换点时，一次
log switch会强制刷满当前日志并归档，导致该区间Redo size突增但归档文件只 +1 - 部分 redo 还没触发归档就被覆盖（尤其在高频率切换下），所以差值略高于真实归档量
更稳的做法是用 DBA_HIST_SYSSTAT 查：
SELECT snap_id, value, end_interval_time<br>FROM dba_hist_sysstat s JOIN dba_hist_snapshot sn ON s.snap_id = sn.snap_id<br>WHERE stat_name = 'redo size'<br>AND snap_id IN (100, 101);再手动算差值 ÷ 实际秒数。
结合 Top 5 Timed Events 和 SQL Statistics 锁定根因
高 Redo size per second 只是现象，得往下挖谁在写、怎么写的：
- 查 Top 5 Timed Events：出现
log file switch (archiving needed)且占比 > 5%，说明 ARCH 进程跟不上，要么归档目标 I/O 慢，要么 redo 日志组太小；同时检查Redo log space requests非零，就是 LGWR 曾因无空闲日志而等待 - 翻 SQL Statistics：默认排序没用，必须手动筛
Rows Processed和Executions双高的语句；Rows Processed > 10000且Executions > 100的大概率是批处理脚本或未分页全表更新 - 注意漏网之鱼：AWR 可能不捕获短连接、JDBC 批量操作（如
addBatch()+executeBatch()），这时得切到DBA_HIST_ACTIVE_SESS_HISTORY查sql_opname IN ('INSERT', 'UPDATE')
别忽略全局临时表和 FORCE LOGGING 的干扰
有人以为用了 GLOBAL TEMPORARY TABLE 就万事大吉，其实 delete 操作照样产大量 redo（测试中删 1.8 万行产生 5 MB redo）；而开启 FORCE LOGGING 会让所有 DDL/DML 强制记 redo，Redo size 会上浮 15%~30%，但归档压力还取决于 ARCH 吞吐能力——这两项常被当作“合理开销”放过，实际却是压垮归档链路的最后一根稻草。
