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 实时同步并分担只读负载，最终在极短切换窗口内完成角色转换。这个过程仍需计划停机（通常
为什么不能直接用 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），这类细节比命令本身更容易被忽略。
