Real-Time Apply需显式启动且依赖备库MOUNT状态、SRL存在、主库LGWR传输模式。先查v$database确认PHYSICAL STANDBY/MOUNTED，再验证SRL数量与大小、v$archive_dest_status中dest_id=2的recovery_mode为MANAGED REAL TIME APPLY。
Oracle 19c Data Guard 的实时日志应用（Real-Time Apply）不是默认开启的，必须显式启动，且依赖备库处于 MOUNT 状态、归档日志已传输到位、MRP 进程未被阻塞——否则你会看到日志堆积但 APPLY 状态始终为 NO。
如何确认备库已就绪并启用 Real-Time Apply
先检查备库是否满足基本前提：数据库必须在 MOUNT 状态（不能 OPEN），且主库已成功传输归档日志到备库。常见误操作是直接 ALTER DATABASE OPEN 后再尝试启动应用，这会导致 ORA-16136: standby database not in managed recovery mode 错误。
- 登录备库 SQL*Plus，执行
SELECT database_role, open_mode FROM v$database;—— 必须返回PHYSICAL STANDBY和MOUNTED - 运行
SELECT process, status, sequence# FROM v$managed_standby;，确认有ARCH进程接收日志，且SEQ#在增长 - 检查归档日志是否已到达备库：
SELECT name, applied FROM v$archived_log WHERE applied = 'NO' AND dest_id = 1 ORDER BY sequence# DESC;，若结果为空或只有少量未应用日志，说明传输基本正常
启动 Real-Time Apply 的正确命令与时机
Real-Time Apply 的本质是让 MRP（Managed Recovery Process）直接从 Standby Redo Log（SRL）读取并应用，跳过归档落盘环节，因此必须确保 SRL 已创建且大小/数量足够。如果没建 SRL 或数量不足，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 会报 ORA-01275: Operation not allowed if standby file management is automatic 或静默失败。
- 先确认 SRL 是否存在：
SELECT group#, bytes, status FROM v$standby_log;，至少要有 3 组，每组大小建议 ≥ 对应 Online Redo Log - 若无 SRL，需在备库
MOUNT状态下手动添加：ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/u01/app/oracle/oradata/ORCLCDBDG/srl04.log') SIZE 200M;（路径和大小按实际调整） - 执行启动命令：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;—— 注意必须带USING CURRENT LOGFILE，否则只是普通归档应用 - 验证是否生效：
SELECT recovery_mode FROM v$archive_dest_status WHERE dest_id = 2;应返回MANAGED REAL TIME APPLY
为什么 Real-Time Apply 有时“开了却没用”
最常被忽略的是主库未启用 LGWR ASYNC 或 LGWR SYNC 传输模式。如果主库 log_archive_dest_2 仍配置为 ARCH（归档进程传输），日志会先写归档文件再传，根本不会进入 Standby Redo Log，Real-Time Apply 就成了空转。
- 检查主库参数：
SHOW PARAMETER log_archive_dest_2，值中必须含LGWR，例如'SERVICE=ORCLCDBDG LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCLCDBDG' - 若仍是
ARCH，立刻修改：ALTER SYSTEM SET log_archive_dest_2='SERVICE=ORCLCDBDG LGWR ASYNC ...' SCOPE=BOTH;，然后ALTER SYSTEM SWITCH LOGFILE;触发新日志流 - 网络延迟 > 100ms 或带宽不足时，
LGWR可能超时退回到ARCH模式，查v$dataguard_stats中transport lag和apply lag是否持续增长
Real-Time Apply 下的只读访问限制
启用 Real-Time Apply 后，备库仍处于 MOUNT 状态，无法直接 OPEN READ ONLY。必须先停掉 MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再 ALTER DATABASE OPEN READ ONLY;。但此时日志应用暂停，不再是“实时”。ADG（Active Data Guard）许可允许你同时 OPEN READ ONLY 并保持 USING CURRENT LOGFILE，但前提是已购买对应许可且参数 ENABLE_PLUGGABLE_DATABASE 和 COMPATIBLE 设置合规。
- 未购 ADG 许可时，
OPEN READ ONLY+RECOVER是互斥的；强行操作会报ORA-01153: an incompatible media recovery is active - 已购许可且启用 ADG，需确认
SELECT value FROM v$parameter WHERE name = 'active_data_guard';返回TRUE - 即便支持 ADG，也建议避免在高并发查询场景下长期开启 Real-Time Apply + READ ONLY，SRL 写入和查询争抢 buffer cache 可能引发
read by other session等等待事件
Real-Time Apply 的核心不在命令本身，而在主备两端传输机制、SRL 配置、许可状态三者的咬合。漏掉任意一环，看起来像“开了”，实际日志还是走归档路径慢慢吞吞地 apply。
