ORA-16853 表示 Data Guard Broker 检测不到 MRP 进程心跳，并非备库实际未应用日志；需直查 v$managed_standby 和 v$archive_dest_status，排查 dg_broker_start、db_unique_name 及数据库状态是否合规。
ORA-16853 是什么，为什么不能只看报错字面意思
ORA-16853 表示 “standby database is not applying redo”，但**这不等于备库真的没在应用日志**。它本质是 Data Guard Broker 检测不到 MRP（Managed Recovery Process）进程的活跃心跳，或发现其状态与预期不符。常见诱因不是数据库坏了，而是 broker 无法确认 MRP 是否真在跑 —— 可能是进程卡住、日志路径权限不对、归档传输中断后未自动恢复、甚至只是 broker 自身缓存状态过期。
检查 MRP 进程是否真实存活，而不是只信 SHOW DATABASE
Broker 的 SHOW DATABASE 输出可能滞后或误判。必须绕过 broker，直连备库查真实状态：
- 登录备库：
sqlplus / as sysdba - 运行：
SELECT process, status, thread#, sequence#, block# FROM v$managed_standby WHERE process = 'MRP0'; - 如果返回空行，说明 MRP 确实没启动；如果返回
status = WAIT_FOR_LOG或APPLYING_LOG，但 broker 仍报 ORA-16853，问题就在 broker 通信层 - 再查：
SELECT * FROM v$archive_dest_status WHERE dest_id = 2;（假设LOG_ARCHIVE_DEST_2指向主库），确认status是VALID，且error列为空
Broker 误报 ORA-16853 的三个高频原因和对应操作
真正导致 broker “看不见” MRP 的，往往是以下三类配置或状态不一致：
-
dg_broker_start在备库被设为FALSE：Broker 不会主动轮询，自然认为 MRP 失联。执行ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=BOTH;并重启监听（lsnrctl reload） - 主备库
db_unique_name不一致：Broker 用它做身份标识。查SHOW PARAMETER db_unique_name，确保主库和备库值完全匹配（注意大小写、空格） - 备库处于
READ ONLY WITH APPLY但 broker 期望的是MOUNT状态：ADG 模式下，broker 默认要求物理备库在MOUNT状态才能管理 MRP。若你启用了实时查询（ALTER DATABASE OPEN READ ONLY后再RECOVER MANAGED STANDBY DATABASE DISCONNECT），broker 会持续报 ORA-16853 —— 此时需接受该警告，或改用RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT并保持MOUNT
重置 broker 前必须验证的两个硬性条件
ORA-16853 本身不构成重置 broker 的理由。只有当确认 MRP 真实运行、所有参数正确、但 broker 状态仍顽固不更新时，才考虑干预配置。此时务必确认：
- 主备库
DG_BROKER_CONFIG_FILE1和DG_BROKER_CONFIG_FILE2指向的两个.dat文件，内容是否一致（可用cmp对比）；不一致说明 broker 配置已分裂，强行重置只会让问题更糟 - 备库 alert 日志里是否有
MRP0: Started log transport services之后紧跟MRP0: Media Recovery Waiting for thread—— 这才是 MRP 健康的铁证。如果没有，先解决归档传输（比如检查LOG_ARCHIVE_DEST_STATE_2是否为ENABLE、TNS 连接是否通、主库 ARC 进程是否正常归档）
Broker 的状态同步有延迟，有时等 2–3 分钟再 SHOW CONFIGURATION 就恢复正常。别在日志还没刷出来时就动手删配置。
