Redo size是实例启动至快照结束写入log_buffer的逻辑字节数，含block padding、SCN标记等开销，并非实际归档量；真实归档量需查v$archived_log.bytes加总，因其受ARCH进程吞吐、磁盘I/O及日志切换机制影响。
awr 里的 redo size 不是归档量，但它是诊断写入密集型负载最直接的起点——关键得用差值算速率，而不是看单个快照的累计值。
Redo size 是什么，为什么不能直接当归档量用
Redo size 统计的是从实例启动到快照结束期间，写入 log_buffer 的逻辑字节数，单位是字节。它包含 block padding、SCN 标记、checksum 等开销，并非实际落盘的归档文件大小。
真实归档量要看 v$archived_log.bytes 加总；而 Redo size 高，只说明“内存里刷出去的 redo 多”，不等于 ARCH 进程已成功归档。比如 FORCE LOGGING 开启时 Redo size 会明显上升，但归档速度还卡在磁盘 I/O 或归档路径满上。
- 同一事务在 Oracle 12c+ 启用 IMU 或 SecureFiles 时，Redo size 可能比 11g 高 20%～30%
- DDL（如
CREATE TABLE AS SELECT）会产生巨量 Redo size，但可能只触发一次日志切换 - 小事务因 512B/4KB 块对齐，也可能撑满一个 redo block，导致 Redo size “虚高”
怎么用 AWR 差值反推 Redo 生成速率
必须取两个连续快照的 Redo size 差值，再除以真实时间间隔（不是快照 ID 差，也不是 END_INTERVAL_TIME 直接相减）。
推荐用 SQL 查，更准：
SELECT snap_id,
stat_name,
value,
TO_CHAR(end_interval_time, 'yyyy-mm-dd hh24:mi') end_time
FROM dba_hist_sysstat s
JOIN dba_hist_snapshot sn ON s.snap_id = sn.snap_id
WHERE stat_name = 'redo size'
AND s.snap_id IN (12345, 12346)
ORDER BY snap_id;然后手动计算：(value_12346 - value_12345) / (real_seconds_between)。若结果持续 > 500 KB/s，就属于写入密集型负载；> 2 MB/s 通常已逼近 I/O 极限。
- 别用
DBA_HIST_SNAPSHOT.END_INTERVAL_TIME直接减——它只有分钟级精度，误差可达 60 秒 - 若差值区间刚好跨日志切换（
log switch），Redo size 会突增，但归档文件只 +1，此时需结合v$log_history时间分布验证 - 连续多个快照差值都稳定偏高，才可确认是常态写入压力，而非偶发大事务
Redo size 高但 Top SQL 没有 DML？查 DBA_HIST_ACTIVE_SESS_HISTORY 补漏
有些高频 DML 不走共享池缓存（比如 JDBC 批量插入开启 rewriteBatchedStatements=true 但未绑定变量），AWR 的 SQL 统计会完全漏掉它们。
这时要绕过 SQL_ID，直接从活动会话历史里捞操作类型和对象：
SELECT sql_opname, current_obj#, object_name, COUNT(*) cnt
FROM dba_hist_active_sess_history a
JOIN dba_objects o ON a.current_obj# = o.object_id
WHERE sample_time > SYSDATE - 1/24
AND sql_opname IN ('INSERT','UPDATE','DELETE')
AND o.owner NOT IN ('SYS','SYSTEM')
GROUP BY sql_opname, current_obj#, object_name
ORDER BY cnt DESC;-
current_obj#非 0 且object_name是业务表名 → 重点盯这个表的索引是否缺失、是否有无 WHERE 更新 -
sql_opname = 'UPDATE'但cnt极高 → 很可能是条件失效或全表更新 -
current_obj# = 0→ 操作对象不在数据字典缓存中（临时表、刚建的表），需查应用日志或 10046 trace
结合 Top 5 Timed Events 和 Physical Reads 定位根因
单纯 Redo size 高只是现象，真正要解决的是“为什么写这么多”。这时必须交叉验证等待事件和物理读：
- 如果
log file switch (archiving needed)占比高 → 归档跟不上，先查archive log list和归档路径空间 - 如果
log file sync高 → 提交太频繁，查应用是否每行都COMMIT，或批量提交间隔是否过短 - 如果
db file sequential read+SQL ordered by Physical Reads同时高 → 很可能是索引缺失导致 UPDATE 全表扫描，一行更新产生 MB 级 redo - 执行计划里出现
INDEX RANGE SCAN后接大量TABLE ACCESS BY INDEX ROWID+UPDATE→ 热点行争用，redo 无法合并写入
Redo 写入密集的本质，往往不是“写得多”，而是“写得散、写得慢、写得重复”——这些细节在 AWR 里藏得深，但只要盯住差值、补上 ASH、交叉等 待事件，基本不会漏。
