delay参数仅在非实时应用时生效：若备库启用实时应用（using current logfile），则主库log_archive_dest_n中配置的delay值（单位分钟）会被忽略；必须先取消实时应用，再通过alter database recover managed standby database disconnect启动传统归档应用模式，且主库需配置lgwr async传输并执行日志切换才能使delay生效。
DELAY参数只在非实时应用时生效
Oracle 11g中，DELAY参数（单位：分钟）必须配合「非实时日志应用」才能起作用。如果备库启用了实时应用（USING CURRENT LOGFILE），则无论主库LOG_ARCHIVE_DEST_n里是否配置DELAY=120，该参数都会被忽略——这是官方明确的行为，不是bug。
常见错误现象：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='... DELAY=120 ...'执行成功，但v$dataguard_stats里apply lag始终为0或极小值，alert日志中出现TT00: Setting 'active' archival for destination提示，说明LGWR已绕过DELAY直接推送。
- 确认当前是否实时应用：查
v$managed_standby，若存在MRP0且STATUS为APPLYING_LOG，但PROCESS列没有MRP0而只有RFS和ARCH，大概率是未启用实时应用 - 停掉实时应用：先执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL，再用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT启动传统归档日志应用模式 - 主库设置后必须触发一次日志切换：
ALTER SYSTEM SWITCH LOGFILE，否则新DELAY值不会生效到后续传输的日志中
主库log_archive_dest_n中DELAY的写法与验证
DELAY必须写在主库的LOG_ARCHIVE_DEST_n（通常是_2）参数值内部，不能单独设为独立参数；且仅对异步传输（ASYNC）有效，同步模式（SYNC）下不支持延迟。
正确示例（主库执行）：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=sbdb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=sbdb DELAY=60' SCOPE=BOTH;
-
DELAY=60表示延迟60分钟，即备库收到归档后，等满60分钟才开始应用（前提是此时未被人工干预） - 必须带
LGWR（非ARCH），因为ARCH进程传输本身就有天然延迟，无法精确控制 - 修改后立即查
SHOW PARAMETER LOG_ARCHIVE_DEST_2确认字符串中含DELAY=60，避免空格或引号导致截断 - 验证是否生效：在备库查
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME LIKE '%apply%';，apply lag应稳定趋近于设置的分钟数（如60），而非持续波动或归零
备库端如何手动触发/跳过延迟
延迟不是“锁死”，而是默认策略；DBA可随时干预应用节奏。关键在于区分两种命令：
- 想立刻应用所有已接收但未处理的归档（跳过剩余延迟）：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY—— 这会强制MRP进程立即处理队列中所有归档，包括那些还没到DELAY时限的 - 想恢复延迟策略（比如刚跳过之后又想重新启用）：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY—— 注意这里不带数值，它只是重载主库定义的DELAY值 - 如果误执行了
NODELAY后发现应用太快，不能靠再执行DELAY回退已应用的日志；已应用的SCN不可逆，只能靠重建备库或闪回数据库（前提开启）
为什么v$archived_log里applied=NO但first_time很老
这是非实时+DELAY模式下的典型表现：备库RFS进程早把归档写入本地LOG_ARCHIVE_DEST_1目录，但MRP进程按DELAY规则压着不应用，所以v$archived_log.APPLIED='NO'，且FIRST_TIME可能是几小时甚至几天前——这不代表传输失败，只代表“还没轮到它被应用”。
容易踩的坑：
- 用SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'判断同步进度，会严重低估实际接收能力
- 直接删备库LOG_ARCHIVE_DEST_1下的旧归档，可能删掉尚未应用但仍在DELAY窗口内的日志，导致gap
- 依赖v$dataguard_stats的transport lag（通常≈0）判断整体延迟，而忽略apply lag才是关键指标
真正要看的是：SELECT NAME, VALUE, TIME_COMPUTED FROM V$DATAGUARD_STATS WHERE NAME IN ('apply lag', 'transport lag'); —— 其中apply lag值应与主库设置的DELAY基本一致，波动超过±5分钟才需排查网络或I/O瓶颈。
