dgmgrl需先启用broker配置并注册主备库才能查看同步状态，关键检查项包括data_guard_broker=true、dg_broker_config_file路径一致、tnsnames解析正常；show database verbose可查transport lag、apply lag等真实同步指标，但须结合v$archive_dest_status中applied_scn与主库current_scn比对验证。
用 DGMGRL 连上配置就能看同步状态，但必须先确保 broker 已启用且配置已注册
很多 DBA 试了 DGMGRL 却看不到主备状态，根本原因是没在主库执行过 ENABLE CONFIGURATION，或者备库没成功注册进 broker 配置。Broker 不是装完就自动工作的——它依赖 DATA_GUARD_BROKER=TRUE 参数、有效的 dg_broker_config_file 路径，以及主备双方都能通过 tnsnames.ora 解析对方服务名。常见错误现象包括：ORA-16532: Data Guard broker configuration does not exist 或 DGM-17017: unable to connect to database。
实操建议：
- 检查主库是否开启 broker：
SHOW PARAMETER DATA_GUARD_BROKER，输出应为TRUE - 确认 broker 配置文件路径可写：
SHOW PARAMETER dg_broker_config_file，两个节点的路径最好一致（如都设为+DATA/DBNAME/dr1db_name.dat） - 用
sqlplus / as sysdba在主库运行CREATE CONFIGURATION 'my_dg_config' AS PRIMARY DATABASE IS 'prim_db' CONNECT IDENTIFIER IS prim_db;，再ADD DATABASE 'stdby_db' AS CONNECT IDENTIFIER IS stdby_db; - 最后执行
ENABLE CONFIGURATION，否则所有SHOW命令都只返回空或报错
SHOW DATABASE VERBOSE 是最直接的实时同步指标查看方式
它比 SHOW CONFIGURATION 细得多，能暴露传输延迟、应用延迟、归档 GAP、redo 应用状态等关键细节。重点看三列：Transport Lag（日志从主库传到备库磁盘的时间）、Apply Lag（备库重做应用落后主库 SCN 的时间）、Estimated Startup Time（如果备库宕机重启，预估多久能追平）。
实操建议：
- 在
DGMGRL中连接后直接输入：SHOW DATABASE 'stdby_db' VERBOSE（注意单引号不能省） - 若
Transport Lag显示0 seconds但Apply Lag持续增长，说明网络传输没问题，但备库 I/O 或 CPU 瓶颈导致日志应用慢 - 若
Log Xpt Status是ERROR，立刻查主库ALERT.LOG和V$DATAGUARD_STATUS，常见原因包括归档目标空间满、LOG_ARCHIVE_DEST_2权限失效、监听未响应 - Oracle 12c 默认使用 LGWR SYNC 模式时，
Transport Lag通常 ≤ 1 秒；若用 ARCH 模式，可能达数分钟，这属于设计行为，不是故障
别信 STATUS = SUCCESS，要盯住 PROTECTION MODE 和 TRANSPORT ON/OFF
SHOW CONFIGURATION 输出里 STATUS = SUCCESS 只代表 broker 配置本身没语法错误，不代表数据正在同步。真正决定 RPO 的是保护模式和传输开关状态。比如最大可用性（MAXIMUM AVAILABILITY）下，主库会等备库确认接收 redo 才提交；而最大性能（MAXIMUM PERFORMANCE）则完全异步，主库不等备库。
实操建议：
- 运行
SHOW CONFIGURATION后，务必核对两行：Protection Mode: MAXIMUM AVAILABILITY和Members: prim_db (primary) stdby_db (physical standby)下的Transport On是否为YES - 如果
Transport On是NO，即使数据库都开着，日志也不会传输——需手动执行EDIT DATABASE 'stdby_db' SET PROPERTY TransportOn='ON'; - 修改保护模式必须在主库执行：
EDIT CONFIGURATION SET PROTECTION MODE AS MAXIMUM AVAILABILITY;，且要求备库处于 MOUNT 状态、日志传输正常、无 GAP - 12c 中
MAXIMUM PROTECTION模式已不推荐用于生产，因主库会因备库不可用而强制 shutdown，实际中极少启用
DGMGRL 的延迟值是估算值，真实同步进度得结合 V$ARCHIVE_DEST_STATUS 和 APPLIED_SCN
SHOW DATABASE VERBOSE 里的 Apply Lag 是基于时间戳推算的，受系统时钟偏差影响；而 Transport Lag 依赖主备之间 NTP 同步质量。更可靠的判断方式是比对主备的 SCN：主库查 SELECT CURRENT_SCN FROM V$DATABASE;，备库查 SELECT APPLIED_SCN FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;（假设备库是 DEST_ID=2），差值换算成秒才接近真实延迟。
实操建议：
- 不要只依赖 DGMGRL 的“秒数”，尤其跨时区或 NTP 不稳的环境。定期跑脚本对比
CURRENT_SCN和APPLIED_SCN更准 - 备库若处于
MANAGED STANDBY RECOVER状态，APPLIED_SCN才持续更新；若停在 MOUNT，该值会冻结 - 12c 引入了
STANDBY_BECAME_PRIMARY_SCN字段，切换后可用于验证是否真没丢事务，但日常监控用不上 - 当
APPLIED_SCN长期不更新，优先检查备库 alert log 里是否有MRP0: Background Managed Standby Recovery process started，没有就说明恢复进程根本没启
