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。
