oracle 11g data guard的redo transport services无直接性能指标参数，需通过statistics_level=typical/all启用v$视图统计，并结合log_archive_trace、等待事件及v$archive_dest_status等动态视图监控传输状态、延迟与错误。
oracle 11g data guard 的 redo transport services 本身不提供直接的“性能指标”配置项，它没有像 statistics_level 那样的开关式参数；所谓“配置性能指标”，实际是指启用并采集与重做传输相关的底层统计、等待事件和诊断数据，以便后续分析延迟、吞吐或瓶颈。
如何启用Redo Transport关键统计与等待事件
Oracle 11g 中 Redo Transport 的运行状态和性能数据主要依赖动态视图和隐式收集的等待事件，需确保基础诊断能力开启：
-
STATISTICS_LEVEL必须设为TYPICAL或ALL（不能是BASIC），否则V$ARCHIVE_DEST_STATUS、V$DATAGUARD_STATS等视图中部分字段（如VALUE、TIME_COMPUTED）会为空或不可靠 -
LOG_ARCHIVE_TRACE可临时开启详细跟踪（仅调试用），例如：ALTER SYSTEM SET LOG_ARCHIVE_TRACE=16 SCOPE=BOTH;（16 表示重做传输错误跟踪） - 确保
V$SESSION_WAIT和V$SYSTEM_EVENT能捕获到ARCH wait on ATTACH、LNS wait on ATTACH、LGWR wait on LNS等关键等待，这些是判断传输阻塞点的第一手依据
必须监控的核心动态视图及其含义
以下视图不是“配置出来”的，而是你必须定期查询以评估 Redo Transport 健康度——它们反映的是真实传输行为，不是采样结果：
-
V$ARCHIVE_DEST_STATUS：重点看STATUS（VALID/ERROR）、TRANSMIT_MODE（SYNC/ASYNC）、DELAY_MINS（是否人为延迟）、ERROR（最近错误文本） -
V$DATAGUARD_STATS：查看NAME = 'transport lag'和'apply lag'对应的VALUE（单位秒），注意该值每 5 秒刷新一次，且依赖STATISTICS_LEVEL设置 -
V$MANAGED_STANDBY：观察PROCESS列（ARCH、LNS、RFS、MRP0）的STATUS和SEQ#是否连续推进；若LNS卡在某SEQ#不动，大概率是网络或备库RFS进程异常
LogXptMode 和 NetTimeout 对传输行为的实际影响
这两个参数不直接输出“指标”，但会显著改变传输延迟表现和可观测性：
-
LogXptMode（DG Broker 属性）或等效的LOG_ARCHIVE_DEST_n中的SYNC/ASYNC设置，决定了主库LGWR是否等待网络 ACK。设为SYNC后，LGWR等待时间会直接计入log file sync等待事件，此时必须查V$SYSTEM_EVENT中该事件的平均等待时间（AVERAGE_WAIT），而非只看 DG 视图 -
NetTimeout（默认 30 秒）控制 LNS 连接空闲超时。若网络抖动频繁但小于 30 秒，LNS 不会断连重试，但可能累积小延迟；调低（如设为 10）会让连接更“敏感”，日志里出现更多ORA-12170: TNS:Connect timeout occurred，反而干扰问题定位——除非你明确在排查长连接假死 - 不要混淆
NetTimeout和REOPEN：REOPEN是归档目标失败后重试间隔（单位秒），影响的是DEFER→ENABLE的恢复节奏，不改变实时传输延迟
为什么你查不到“实时带宽”或“每秒redo字节数”
Oracle 11g 没有内置的 redo_bytes_per_second 性能计数器。你只能间接估算：
- 从
V$ARCHIVED_LOG查最近 5 分钟的BYTES和COMPLETION_TIME，手动算平均速率（注意BYTES是归档文件大小，非原始 redo 流量） - 启用
LOG_ARCHIVE_DEST_n的ALTERNATE+VALID_FOR组合，并配合操作系统级工具（如netstat -s | grep -i "segments sent"）粗略比对发送量 - 真正可靠的流量观测需依赖网络设备镜像或 Oracle 12c+ 的
DBA_HIST_IOSTAT_DETAIL（11g 不支持）
最易被忽略的一点：所有基于视图的“lag”值（包括 transport lag）都依赖主备库系统时间严格同步。NTP 微小漂移（>1 秒）会导致 V$DATAGUARD_STATS 中的 lag 值剧烈跳变，误判为网络问题。
