Oracle Zero Downtime Migration（ZDM）是实现零停机迁移的核心工具，依赖Active Data Guard（ADG）提供实时同步与只读分流；ZDM自动化配置Data Guard、管理迁移流程并清理环境，而ADG本身仅为底层高可用机制，并非独立迁移工具。
Active Data Guard 本身不是迁移工具，它不直接“实现零停机迁移”——它是在迁移过程中维持业务连续性的关键组件。真正完成零停机迁移的，是像 Oracle Zero Downtime Migration (ZDM) 这类工具，而 Active Data Guard 是其底层依赖的同步与只读分流机制。
如果你手头只有 Oracle 19c 环境、没有 ZDM 许可或不想用云服务，那所谓“零停机迁移”实际是指：主库持续提供写服务，备库通过 ADG 实时同步并分担只读负载，最终在极短切换窗口内完成角色转换。这个过程仍需计划停机（通常 < 30 秒），但业务影响被压缩到最小。
为什么不能直接用 ALTER DATABASE OPEN READ ONLY 启动物理备库？
物理备库默认处于 MOUNT 状态，且 REDO APPLY（MRP 进程）必须运行才能保持同步。一旦执行 ALTER DATABASE OPEN READ ONLY，MRP 就会停止，同步中断，后续无法再无缝切回实时应用模式。
正确做法是启用 Active Data Guard：它允许数据库在 OPEN READ ONLY 的同时，后台继续应用归档日志（即启动 MRP 并保持运行）。这需要：
- 企业版许可（
Active Data Guard是单独选件，非标准版自带） - 主库已开启
FORCE LOGGING和归档模式 - 备库已配置足够数量的
standby redo log（组数 ≥ 主库v$log组数 + 1） -
DB_UNIQUE_NAME、LOG_ARCHIVE_CONFIG、LOG_ARCHIVE_DEST_2等参数已在主备库正确设置
验证是否生效：SELECT database_role, open_mode, protection_mode FROM v$database; —— 备库应返回 PHYSICAL STANDBY + READ ONLY WITH APPLY。
ADG 同步延迟大，查询结果明显滞后怎么办？
延迟不是网络或硬件单方面问题，而是由日志传输、写入、应用三个环节叠加导致。常见根因和对应操作：
- 主库
ARCH进程慢于LGWR：改用SYNC或ASYNC的LGWR传输（log_archive_dest_2 = 'SERVICE=orcldg LGWR SYNC/ASYNC'），避免归档文件级传输瓶颈 - 备库 I/O 能力不足：检查
standby redo log是否频繁switch（查v$standby_log的STATUS），若常为ACTIVE，说明写入跟不上，需增大每组大小（建议 ≥ 主库redo log单组大小） - MRP 进程卡住：查
v$managed_standby中PROCESS = 'MRP0'的STATUS和SEQ#，对比v$archived_log最新SEQUENCE#；若落后超过 3–5 组，优先检查归档传输是否被阻塞（如log_archive_dest_state_2 = DEFER） - 启用了
STANDBY_FILE_MANAGEMENT=AUTO但主库新增数据文件失败：备库会挂起应用，直到手动修复（ALTER DATABASE CREATE DATAFILE ... AS COPY）
临时缓解查询延迟：在应用层加 SELECT /*+ RESULT_CACHE */ ...，但仅适用于静态数据；生产环境应优先定位并消除同步链路瓶颈。
切换前必须清理 DG Broker 配置吗？
不一定，但强烈建议在非 Broker 管理场景下禁用它。原因很实际：
-
DG Broker会接管log_archive_dest_n参数控制权，与手工配置冲突，容易导致归档传输静默失败（现象：主库ARCHIVE LOG LIST显示VALID，但备库v$archived_log无新记录） - ZDM 或手动 switchover 脚本若检测到
dg_broker_start=TRUE，可能拒绝执行或报错ORA-16664: unable to receive the result from a database - RAC 主库环境下，Broker 配置文件（
dg_broker_config_file1）若未在所有节点共享存储上一致，会导致节点间状态分裂
安全做法（切换前执行）：
ALTER SYSTEM SET dg_broker_start=FALSE SCOPE=BOTH; ALTER SYSTEM RESET dg_broker_config_file1 SCOPE=SPFILE; ALTER SYSTEM RESET dg_broker_config_file2 SCOPE=SPFILE; SHUTDOWN IMMEDIATE; STARTUP;
之后再确认 log_archive_config 仅含当前主备库的 DB_UNIQUE_NAME，例如：'dg_config=(ORCL,ORCLDG)'。
最后一步：switchover 命令执行后卡在 WAITING FOR GAP RESOLUTION
这不是超时，是备库发现归档序列有缺口（gap），主动暂停切换流程。此时不能强行中止，否则破坏 DataGuard 一致性。
先查缺口位置：SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
若返回结果非空，说明主库有未传到备库的归档日志。解决方式只有两种：
- 主库手动拷贝缺失归档（
cp /u01/arch/1_*.arc /tmp/），再在备库注册：ALTER DATABASE REGISTER PHYSICAL LOGFILE '/tmp/1_100.arc'; - 更稳妥的做法：在主库执行
ALTER SYSTEM ARCHIVE LOG CURRENT;若干次，触发重传；再查V$ARCHIVE_GAP是否清空
注意：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; + 重启 MRP 不会自动补缺，必须显式注册或重传。
真实环境中，gap 往往源于网络抖动或监听配置错误（比如备库 tnsnames.ora 指向了旧 IP），这类细节比命令本身更容易被忽略。
