最准方法是查v$sysmetric_history取最近1小时最大值，rac需各实例分别查后求和；带宽计算按传输模式选系数（async用0.7、sync用0.75），注意单位换算、压缩比及tcp缓冲区优化。
怎么看当前redo生成速率？别只信awr报告头
直接查 v$sysmetric_history 最准，尤其在业务高峰时段——awr报告里的“redo size per second”是采样均值，容易掩盖瞬时峰值。比如某次快照间隔15分钟，但真实压力集中在最后2分钟，均值就失真了。
- 执行
SELECT MAX(value) FROM v$sysmetric_history WHERE metric_name = 'Redo Generated Per Sec'，取最近1小时最大值（单位：bytes/sec） - 如果是RAC环境，必须对每个实例分别查，再求和；不能只看全局视图或DBA_HIST_SYSMETRIC_SUMMARY
- 如果数据库版本 ≥ 11.1.0.6，建议配合
oratcptest工具实测网络吞吐，避免理论带宽和实际可用带宽脱节
带宽公式里那个0.7或0.75，到底该用哪个？
不是选题，是看传输模式：异步传输（ASYNC）按0.7算，同步传输（SYNC）按0.75更稳妥。因为SYNC模式下LNS进程要等TCP确认，重传和延迟更高，网络开销实际更大。
- 通用公式：
((Redo_bytes_per_sec / 0.7) * 8) / 1000000→ 单位Mbps（保守起见，多数场景用这个） - 若主备间启用了
REDO_COMPRESSION=ENABLE，可先乘以压缩比（实测通常0.4~0.6），再代入公式，但注意压缩会增加CPU负载 - 别漏掉单位换算：Redo速率是字节/秒（B/s），带宽是兆比特/秒（Mbps），必须 ×8；除以1000000而非1024×1024，运营商和交换机都按十进制计
为什么按公式算了带宽，传输还是卡在30%？
常见真凶不是带宽不够，而是TCP缓冲区太小或网卡队列溢出。Linux默认 net.core.wmem_max 往往只有256KB，而高速链路（如1Gbps）需要至少4MB才能打满吞吐。
- 检查并调大发送缓冲：
sysctl -w net.core.wmem_max=4194304，并在/etc/sysctl.conf中固化 - Oracle侧确认
sqlnet.ora含有SQLNET.SEND_TIMEOUT=0和SQLNET.RECV_TIMEOUT=0，避免超时中断重试 - 用
ss -i观察重传率（retrans），>0.1% 就说明链路或驱动有问题，不是Oracle配置能解决的
要不要预留增长余量？怎么留才不浪费
必须留，但别拍脑袋翻3倍。真实增长取决于业务类型：OLTP系统redo增速常与事务数线性相关，而批量导入类任务可能造成单日突增10倍。
- 查过去3个月每周五峰值的
Redo Generated Per Sec，取P95而非MAX，避免被异常批处理拉高 - 在公式结果基础上 +20% 作为基线，再 +15% 作为冗余（合计+35%），比盲目×3更贴近运维实际
- 如果已启用Active Data Guard且备库开放只读查询，记得把这部分产生的redo也计入——它不会出现在主库常规指标里，但会走同一通道
网络瓶颈从来不在一个数字上，而在Redo速率、TCP栈、交换机QoS、Oracle传输进程这四层之间的咬合点。最容易被跳过的，是确认RAC各节点RFS进程是否真的在接收，而不是只看主库LNS有没有报错。
