如何通过Oracle 19c DGMGRL配置备库的Delay应用延迟

DGMGRL 不能直接设置 DELAY 参数，因 DELAY 是 log_archive_dest_n 的传输层属性，须由主库在 ALTER SYSTEM 中配置，且仅对非实时应用生效；备库需显式启用 USING ARCHIVED LOGFILE 才能生效。

为什么 DGMGRL 不能直接设置 DELAY 参数

dgmgrl 本身不提供类似 alter database recover ... delay 的命令，也不允许在 edit database ... set property 中直接配置日志应用延迟时间。delay 是归档传输层（log_archive_dest_n）的属性，必须由主库控制，且仅对非实时应用模式生效。如果你在 dgmgrl 中执行 show database verbose，会发现所有与延迟相关的字段（如 delaymins）始终显示为 0 或 n/a —— 这不是 bug，而是设计限制。

主库 log_archive_dest_2 必须显式带 DELAY 且禁用 real-time apply

在主库上运行以下语句（注意替换实际的 SERVICE 名称和 DB_UNIQUE_NAME）：

ALTER SYSTEM SET log_archive_dest_2='SERVICE=standby_db LGWR ASYNC DELAY=1440 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db' SCOPE=BOTH;

关键点：

• DELAY=1440 表示延迟 1440 分钟（24 小时），单位是分钟，不能写成 DELAY 不带值（否则默认 30 分钟）
• 必须去掉 SYNC 或 AFFIRM（否则 LGWR 会等待备库确认，与延迟逻辑冲突）
• 不能含 REOPEN、MAX_FAILURE 等无关参数，避免语法解析失败
• 该设置只影响日志传输行为，不自动触发备库端的恢复模式切换

备库必须用 USING ARCHIVED LOGFILE 启动 MRP

即使主库已设 DELAY，如果备库当前是 real-time apply 模式（即启动时用了 USING CURRENT LOGFILE 或没指定任何 USING），DELAY 会被完全忽略，并在 alert 日志中出现警告：

WARNING: Managed Standby Recovery started with USING CURRENT LOGFILE DELAY 1440 minutes specified at primary ignored

正确做法是先停掉当前恢复，再以归档日志模式重启：

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;<br>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING ARCHIVED LOGFILE DISCONNECT FROM SESSION;

验证是否生效：

• 查 v$managed_standby：PROCESS 列应为 MRP0，STATUS 应为 APPLYING_LOG
• 看备库 alert.log：会出现类似 Media Recovery Delayed for 1440 minutes 的记录
• 主库切日志后，v$archived_log 中 next_time 和 completion_time 的差值应接近设定延迟

DG Broker 配置下如何安全切换并保留 Delay 设置

使用 DGMGRL 执行 SWITCHOVER 前，必须先取消延迟应用，否则会报 ORA-16653：

DGMGRL> EDIT DATABASE 'standby_db' SET PROPERTY 'LogXptMode'='ASYNC';<br>DGMGRL> EDIT DATABASE 'primary_db' SET PROPERTY 'LogXptMode'='ASYNC';<br>DGMGRL> DISABLE CONFIGURATION;<br>SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -- 在备库执行<br>SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; -- 重新启用无延迟恢复

切换完成后，需在新主库（原备库）上重新配置 log_archive_dest_2 并设 DELAY，再在新备库（原主库）上运行 USING ARCHIVED LOGFILE。Broker 不会自动同步或继承这个延迟设置 —— 它只管角色和状态，不管传输细节。

最容易被忽略的是：一旦启用 DELAY，就不能依赖 FAST_START Failover 自动故障转移，因为 Data Guard Broker 的健康检查基于实时同步延迟（ApplyLagThreshold），而延迟应用会让这个值长期超标，导致 Broker 主动禁用 FSFO。