oracle data guard无bandwidth_limit参数，因其日志传输基于底层tcp连接，非应用层可控流控通道；强行限速易致超时或连接中断，唯一稳定“限流”方式是控制源头日志生成量。
不能直接限速，但可通过控制日志生成量和传输行为间接实现。
为什么Oracle Data Guard没有bandwidth_limit参数
Oracle Net 层不提供类似bandwidth_limit的流量整形机制；Data Guard 日志传输走的是底层 TCP 连接，不是应用层可控的流控通道。强行在操作系统层面限速（如tc命令）会导致LNS/LGWR进程超时、归档失败或ORA-12537等连接中断错误。
- 主库LGWR或ARCH进程一旦开始发送redo，就按网络栈最大吞吐能力推，不受DBA手动带宽限制
-
LOG_ARCHIVE_DEST_n中所有参数均无限速字段，NET_TIMEOUT只管连接存活，不管速率 - 试图用防火墙或QoS策略压低TCP窗口，容易引发重传风暴，反而恶化传输延迟
真正有效的“限流”其实是控源头：减少日志产生
日志传输量由主库事务强度决定，所谓“限流”，本质是降低redo生成速率。这是唯一稳定、可预期、不破坏DG链路的方式。
- 关闭不必要的
FORCE LOGGING（仅在必须保证全库强制归档时启用） - 对大表批量操作改用
NOLOGGING（需评估备库同步一致性风险） - 压缩LOB字段存储、避免
UPDATE整行（尤其含BLOB/CLOB列），改用UPDATE ... SET col = col最小化redo - 检查AWR中
redo size per second指标，定位高redo会话，优化SQL（如减少索引维护、合并DML）
用ASYNC + NOAFFIRM组合降低瞬时压力
SYNC模式下LGWR必须等待备库ACK，网络抖动会直接卡住主库提交；ASYNC+NOAFFIRM虽不能减总量，但能削峰填谷，避免突发日志把网络打满。
- 配置示例：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC NOAFFIRM ...' - NOAFFIRM让备库RFS收到redo进内存即返回ACK，不等写盘，大幅降低主库等待时间
- 搭配
REOPEN=60防止单次超时导致归档停滞，比硬限速更健壮 - 注意：该组合下RPO（恢复点目标）不再为零，需业务接受几秒数据丢失风险
备库端反向节流：调低MRP应用速率
如果目标是“不让备库追得太快”（比如用于报表库需控制负载），可在备库限制日志应用速度，而非阻断传输本身。
- 设置
ALTER SYSTEM SET STANDBY_MAX_IO_RATE=10485760（单位bytes/sec，即10MB/s） - 该参数只影响MRP进程读SRL并apply的速度，不影响LNS→RFS的传输阶段
- 需12cR2+版本，且仅对物理备库生效；逻辑备库用
LOGSTDBY_MAX_IO_RATE - 副作用：transport lag不变，但apply lag会上升，
V$DATAGUARD_STATS中apply lag值变大
真正难处理的不是“怎么限”，而是“限了之后谁来承担后果”——主库性能、备库实时性、RPO/RTO目标，三者必舍其一。多数情况下，与其在传输链路上硬砍，不如回到业务侧查redo大户、删冗余索引、拆大事务。
