Redo Size在AWR中反映每秒生成的未压缩未加密前原始重做日志字节数，受LOG_BUFFER、事务密度、DML类型及FORCE LOGGING影响，是容量规划关键指标但非网络实际流量。
Redo Size在AWR里到底反映什么
awr报告中的 redo size 是每秒生成的重做日志字节数（单位通常是bytes/sec），但它**不是dbwr写盘量，也不是网络实际传输量**，而是oracle在内存中构造redo record后、未压缩未加密前的原始体积。它受 log_buffer 大小、事务密集度、dml类型（update比insert更易膨胀）、是否启用 force logging 影响显著。
常见错误现象：DBA看到AWR里 Redo Size 峰值 20MB/s，就按此估算DG网络带宽，结果备库延迟飙升——因为没算上网络开销、LNS进程排队、ARCn归档竞争、以及Data Guard Broker的控制流干扰。
- 真实网络流量 ≈
Redo Size× 1.15 ~ 1.4（含TCP/IP头、RFS写入前校验、部分加密/压缩开销） - 如果启用了
COMPRESSION=ENABLE（需Enterprise Edition + Data Guard配置），实际网络流量可能降至60%~75%，但CPU使用率上升10%~20% -
Redo Size在AWR中是“平均采样值”，若业务有秒级脉冲（如批处理启动瞬间），它会平滑掉峰值，必须结合ASH查log file sync和log file parallel write等待事件确认压力点
怎么从AWR准确提取Redo生成速率
别只看“Instance Efficiency Percentages”或“Top 5 Timed Events”页里的模糊汇总。要定位到 Redo size 的原始统计项，得进“Load Profile”子节——那里才是每秒/每事务的真实基线。
实操建议：
- 用
awrrpti.sql或OEM导出完整AWR报告，搜索关键词Redo size（注意大小写和空格），找到形如Redo size: 12,482,912 bytes/sec的行 - 对比多个时间段（如业务高峰 vs 低谷），取连续3天同一时段的95分位值，而非平均值——容量规划必须扛住P95压力
- 若数据库启用了多租户（CDB），
Redo Size是整个CDB的汇总；想看单个PDB，需用DBA_HIST_PDB_METRIC_HISTORY视图查PDB_REDO_BYTES_PER_SEC
Data Guard网络带宽到底要留多少余量
不能简单用 Redo Size × 1.3 就定带宽。真实链路瓶颈常在中间环节：防火墙吞吐限制、交换机QoS策略、跨AZ专线MTU不一致导致分片重传、甚至备库主机网卡中断合并设置不合理。
关键判断依据：
- 主库LNS进程等待
log file sync超过3ms（默认阈值）且RFS在备库端出现control file sequential read高等待 → 表明网络或备库I/O已成瓶颈 - 用
netstat -s | grep -i "retransmit"在主库查TCP重传率，>0.1% 就需检查链路质量 - 备库
V$DATAGUARD_STATS中transport lag和apply lag持续 >30秒，且apply rate明显低于主库Redo Size→ 带宽或备库CPU/IO不足 - 预留带宽 = P95
Redo Size× 1.4 × 1.2（安全系数），最低不低于1Gbps物理接口（即使当前流量仅200MB/s，避免突发时队列溢出丢包）
为什么用AWR看Redo Size容易误判容量
AWR快照粒度默认60分钟，而redo生成是毫秒级波动。一次AWR采样周期内，可能包含3分钟静默+57分钟高压，但报告只显示一个均值——这会让容量评估严重偏低。
更隐蔽的问题：
- 归档模式下，
Redo Size包含所有归档日志生成量，但DG仅传输在线日志；若主库频繁切日志（LOG_SWITCH_WAIT高），AWR会高估DG流量 - 启用
STANDBY_FILE_MANAGEMENT=AUTO后，主库新建表空间会触发额外redo，这部分在AWR中无法单独剥离 - 某些第三方备份工具（如ZDLRA）直连主库读取archivelog，也会被计入
Redo Size统计口径，但它和DG无关
真正要盯的是 V$ARCHIVED_LOG 里 DELIVERY_TIME 和 DEST_ID=2（对应DG目标）的日志生成速率，再结合 V$MANAGED_STANDBY 的 BYTES_PER_SEC 实时流速交叉验证。
