ORA-16855 是 Data Guard Broker 检测到备库未启用实时应用（RECOVERY_MODE ≠ MANAGED REAL TIME APPLY）的状态提示，非故障本身，需通过查询 V$ARCHIVE_DEST_STATUS 和 V$MANAGED_STANDBY 确认 MRP 进程状态及 SRL 配置、FAL 连通性等根本原因。
ORA-16855 不是独立错误，它只是 Data Guard Broker 检测到备库“未启用实时应用”时抛出的状态提示，不是故障本身，也不能靠 EDIT DATABASE 修复。
查清备库是否真在实时应用
ORA-16855 的本质是 Broker 发现备库的 V$ARCHIVE_DEST_STATUS 中对应主库归档目标（通常是 DEST_ID = 2）的 RECOVERY_MODE 字段不等于 MANAGED REAL TIME APPLY。这说明日志接收和应用没跑在一条流水线上——要么压根没启 MRP，要么启了但卡住了。
- 在备库执行：
SELECT DEST_ID, RECOVERY_MODE, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2—— 如果RECOVERY_MODE是IDLE或空，或STATUS是ERROR，就坐实问题 - 再查 MRP 进程状态：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'—— 若无返回，或STATUS是WAIT_FOR_LOG/APPLYING_LOG但SEQUENCE#长期不动，就是应用层阻塞 - 别只信 DGMGRL 的
SHOW DATABASE VERBOSITY，它缓存状态；真实情况永远以 SQL 查询为准
常见阻塞点：SRL 缺失或大小不匹配
即使归档文件能传过去，没有足够且规格匹配的 Standby Redo Log（SRL），LGWR 实时传输就会失败，MRP 无法启动 REAL TIME APPLY 模式，Broker 就报 ORA-16855。
- 主库执行：
SELECT GROUP#, BYTES, BLOCKSIZE FROM V$LOG，记下最大日志组数和单组大小 - 备库必须在
MOUNT状态下，为每个 thread 显式创建 SRL，数量 ≥ 主库 online redo log 组数 + 1，大小完全一致，例如：ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 512M - SRL 文件路径不能是 NFS、不能跨文件系统、权限必须为
oracle:oinstall；否则 MRP 启动时静默失败，V$MANAGED_STANDBY里看不到 MRP0 进程 - 切忌依赖自动创建——19c 虽支持，但生产环境首次配置或角色切换后极易漏掉，必须手动验证
检查 FAL 和网络连通性是否隐性中断
ORA-16855 常伴随 ORA-16055 出现，根源可能是 FAL 机制失效导致 gap 无法补齐，MRP 卡在等待日志上，从而降级为普通归档应用而非实时应用。
- 查备库告警日志，找
FAL client failed to request gap sequence或ORA-16055，再顺藤摸瓜看其背后的底层错误（如ORA-12154、ORA-01017、ORA-16191） - 在主库用
tnsping <FAL_SERVER值>和sqlplus /@<FAL_SERVER值>测试连接——注意：必须用SYS AS SYSBACKUP，仅CONNECT权限不够 - 确认备库
listener.ora中服务配置含SERVER=DEDICATED；FAL 不支持共享服务器模式 - 网络层面：即使
tnsping通，也要检查 TCP 重传率、时钟漂移（尤其跨 AZ 场景），SCN 校验失败会导致 FAL 拒绝补传但不报显性错误
真正麻烦的从来不是 ORA-16855 这个代码本身，而是它背后那个“看起来一切正常、实际已断流”的静默状态——MRP 进程存在但不推进，归档目录有新文件但 APPLIED=NO，Broker 状态栏显示绿色却拒绝 switchover。盯住 V$ARCHIVE_DEST_STATUS 和 V$MANAGED_STANDBY 两个视图，比任何 DGMGRL 命令都管用。
