Redo size是AWR中Instance Activity Stats里累计写入redo log buffer的总字节数，反映实例启动至快照结束的逻辑redo量，非实际归档量；其值受block对齐、SCN标记、IMU/SecureFiles等影响，估算归档速率须用连续快照差值除以真实时间间隔。
Redo size指标在AWR中到底代表什么
redo size 是 oracle awr 报告里 instance activity stats 部分的一个累计统计值，单位是字节，反映的是从实例启动到快照结束期间写入 redo log buffer 的总字节数（经 log_buffer 写入后，最终落盘量会略小，因存在部分未刷盘或重用）。
它不等于归档日志生成量，但常被误当作归档量估算依据。真实归档量受多个压缩、复用、延迟写入机制影响，比如：ARCH 进程读取的是已写入磁盘的 redo 日志文件，而 Redo size 统计的是逻辑写入 buffer 的量，中间夹着 log writer 的批量写、block padding、checksum、SCN标记等开销。
- 同一事务在不同版本 Oracle 中产生的
Redo size可能差异明显（如 12c+ 启用IMU或SecureFiles会改变 redo 格式） - DDL 操作（如
CREATE TABLE AS SELECT）会产生远高于 DML 的Redo size，但未必对应等量归档——因为日志文件按块（512B/4KB）对齐，小事务也可能“撑满”一个 block - 如果数据库启用了
FORCE LOGGING，Redo size会上升，但归档速度还受限于ARCH进程吞吐和归档目标 I/O 能力
如何用AWR差值反推平均归档速率
要估算归档日志生成速率，不能直接拿单个 AWR 快照里的 Redo size 值除以时间，必须用两个连续快照的差值，再结合实际时间间隔计算。
例如：快照 ID 100 的 Redo size 是 1234567890 字节，快照 ID 101 是 2345678901 字节，间隔 3600 秒，则平均速率为 (2345678901 - 1234567890) / 3600 ≈ 308.6 KB/s。这个值接近但通常略高于真实归档速率（因部分 redo 尚未触发归档，或被覆盖）。
- 优先使用
DBA_HIST_SYSSTAT查询，过滤stat_name = 'redo size'，比直接扒 AWR HTML 报告更可靠 - 注意快照时间是否跨日志切换（
log switch），若刚好卡在日志切换前后，差值可能失真——一次切换会强制写满当前日志并归档，导致该区间Redo size突增但归档文件数只+1 - 避免用
DBA_HIST_SNAPSHOT的END_INTERVAL_TIME直接减，应取SNAP_ID对应的真实采集完成时刻（DBA_HIST_SNAPSHOT表中END_INTERVAL_TIME是近似值，有分钟级漂移）
为什么Redo size和v$archived_log.bytes差异大
v$archived_log.bytes 是每个归档文件的实际大小（字节），加总后是真实归档量；而 Redo size 是内存 buffer 级别的逻辑写入量。两者差异来自三类损耗/放大：
-
log_buffer到磁盘的写入不是 1:1 映射：Oracle 会填充 block（如 512B 对齐）、添加 header/footer、插入 checkpoint info，导致物理日志文件比Redo size多出 3%–10% - 归档进程（
ARCH）读取的是完整 online redo log file，哪怕只用了其中 10%，也会归档整个文件（默认 50MB/100MB），造成严重高估 - 如果开启
LOG_ARCHIVE_DEST_n的DELAY或ALTERNATE，归档可能滞后，v$archived_log记录的是“已完成归档”的时间点，而Redo size是实时累加的
典型现象：某小时 Redo size 差值为 2.1 GB，但 v$archived_log 显示该小时只归档了 1.7 GB（含 3 个 50MB 文件 + 1 个 20MB 文件），差额就是日志文件未用满 + block 对齐开销。
归档压力评估时真正该盯的指标
单看 Redo size 容易误判归档瓶颈。更关键的是观察归档链路各环节的等待与延迟：
- 查
v$session_event中log file sync和log file parallel write的平均等待时间，超过 5ms 说明 LGWR 写盘慢，会拖慢所有事务提交，间接抑制 redo 生成速率 - 查
v$archive_dest_status的STATUS和ERROR列，确认归档路径是否VALID；TRANSMIT_MODE是否为SYNC（同步归档会卡住主库） - 对比
v$log_history的FIRST_TIME和v$archived_log的COMPLETION_TIME，差值持续 > 60s 表示归档积压，此时即使Redo size不高，也需干预
归档不是纯“量”的问题，而是“时效性+可靠性”组合判断。Redo size 只是上游水龙头的刻度，真正堵在哪，得顺着管道一段段摸过去。
