oracle 11g 不支持 _redo_transport_compress 隐含参数和 compression=enable 语法，无原生redo压缩能力；带宽限制只能通过网络层限速（如tc）、改用arch模式、增大日志文件等外部手段实现。
Oracle 11g 不支持 _REDO_TRANSPORT_COMPRESS 或 COMPRESSION=ENABLE
直接说结论：_REDO_TRANSPORT_COMPRESS 隐含参数从 Oracle 12.1 才开始引入，11g 完全不识别该参数；LOG_ARCHIVE_DEST_n 中的 COMPRESSION=ENABLE 语法是 12c+ 新增特性，11g 解析会报错 ORA-00922。你执行 ALTER SYSTEM SET "_redo_transport_compress"=TRUE 或在归档目标里加 COMPRESSION=ENABLE，实例会拒绝启动或报语法错误。
这意味着：11g 没有原生的、由 Oracle 控制的 Redo 压缩传输能力。所谓“限制带宽”，不能靠压缩减体积，只能靠外部手段控速率或错峰。
可用的替代方案只有网络层限速或归档节奏干预
11g 的 Redo 传输依赖 LGWR 或 ARCH 进程推送归档日志文件（ARCH 模式下是完整日志文件，LGWR 模式下是实时块流但仍是明文）。要限制其带宽占用，只能绕过 Oracle 内部机制：
- 在操作系统层面用
tc（Traffic Control）对 Oracle 网络端口（如 1521 或自定义 Data Guard 专用端口）做出口带宽限速，例如限制eth0上源端口为 1521 的流量不超过 50Mbps - 改用
ARCH模式而非LGWR模式传输（即LOG_ARCHIVE_DEST_2中不设SYNC或ASYNC+LGWR），这样 Redo 会等日志切换后才批量传输，天然形成“脉冲式”而非“持续流”，可配合ARCHIVE_LAG_TARGET控制切换频率（如设为 900 秒，约每 15 分钟传一次） - 避免使用
DELAY属性——它只延迟应用，不减少传输量；反而可能因堆积导致后续爆发式传输
误用 LGWR 模式 + 小日志文件会加剧带宽毛刺
如果主库用了小 Redo 日志（比如 100MB），又配置了 LGWR ASYNC，那么高事务量下会频繁触发日志切换和连续块推送，网络流量呈现密集尖峰。这不是带宽“被占满”，而是“被打碎”。此时：
- 增大
LOG_FILE_SIZE（如升到 512MB 或 1GB）能显著降低切换频次，让 Redo 流更平滑，间接缓解瞬时带宽压力 - 确认
V$ARCHIVE_DEST_STATUS.TRANSMIT_MODE是ARCH而非LGWR——查这个视图比看参数更可靠，因为实际走哪个路径受VALID_FOR和角色状态影响 -
LOG_ARCHIVE_DEST_n若漏配VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，可能 fallback 到 ARCH 路径，你以为开了 LGWR 实际没生效
真正需要关注的是 Redo 生成率本身是否合理
与其花力气“限传输”，不如先看源头：SELECT (SUM(blocks)*block_size)/1024/1024/secs "MB/s" FROM v$archived_log, (SELECT 3600 secs FROM dual) WHERE first_time > SYSDATE-1/24 GROUP BY secs; 可粗略估算过去一小时峰值速率。若持续 > 20 MB/s，说明业务写入本身就高，此时限速只是掩耳盗铃——备库延迟必然上升，甚至出现 GAP。
常见放大 Redo 的操作：大量 INSERT /*+ APPEND */ + NOLOGGING 未关闭、索引重建未用 UNRECOVERABLE、物化视图快速刷新频繁。这些不是传输问题，是设计问题。
11g 没有压缩、没有带宽整形 API，所有“限制”都是妥协方案。最稳的做法是：算准带宽需求（按 (Redo rate / 0.75) * 8 / 1000000 公式），然后升级网络或优化 Redo 生成逻辑——别在传输层硬拧。
