备库mrp进程未运行或卡住是日志应用失败的主因，需查v$managed_standby中mrp0状态是否为applying_log且seq#/block#递增，若为空、wait_for_log或idle，则需检查srl配置、归档路径、磁盘空间及传输链路。
这不是日志没传过来，而是备库的恢复进程（MRP）根本没在跑，或者虽在运行但卡住了——SWITCHOVER_STATUS 显示 NOT ALLOWED 或 SWITCHOVER LATENT 时，V$ARCHIVED_LOG 里最新几条的 APPLIED 字段大概率是 NO。
查MRP是否真在应用日志
别只看 RECOVERY_MODE = MANAGED REAL TIME APPLY，它只是“声明要实时应用”，不代表正在干活。必须查 V$MANAGED_STANDBY：
-
SELECT PROCESS, STATUS, SEQ#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';——STATUS必须是APPLYING_LOG，且SEQ#和BLOCK#应随时间递增 - 如果返回空行或
STATUS是WAIT_FOR_LOG、IDLE，说明 MRP 没启动或被阻塞 - 常见阻塞点：
STANDBY REDO LOG缺失（尤其 RAC 环境下漏配THREAD）、standby_archive_dest和log_archive_dest_1路径重叠、ASM 磁盘组空间不足
确认归档是否真已落盘并可被MRP读取
MRP 启动后，得有东西可应用。如果 V$ARCHIVED_LOG 里最大 SEQUENCE# 比主库小，或 APPLIED = 'NO' 的记录持续堆积，问题往往出在归档传输链路上：
Personality Switcher
下载
创建并切换AI助手人格。使用 /personality 列出并激活已保存的人格；使用 /create-personality 设计新角色，自动填充 SOUL 与 IDENTITY。跨会话和对话压缩时人格持久化，自动恢复心跳。原子切换提供备份与回滚保护，切换前始终备份当前状态。
-
SELECT DEST_ID, STATUS, ERROR, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——STATUS必须是VALID，ERROR列为空，GAP_STATUS为NO GAP -
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;—— 返回空行才安全；若有结果，说明物理日志缺口存在，MRP 只能干等 - 19c 中
LOG_ARCHIVE_DEST_2若配置了多个 SERVICE 或路径指向同一备库，RFS 进程可能因重复接收拒绝写入，表现为日志“已传但未落盘”
Switchover前必须满足的三个硬性状态
Broker 不会帮你判断“差不多可以切了”，它只认这三条。任一不满足，SWITCHOVER_STATUS 就不会变成 TO STANDBY：
- 主库侧：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;必须返回TO STANDBY（不是SESSIONS ACTIVE或SWITCHOVER LATENT） - 备库侧：
SELECT DATABASE_ROLE, SWITCHOVER_STATUS FROM V$DATABASE;必须是PHYSICAL STANDBY+TO PRIMARY - 备库恢复进程：
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;必须返回MANAGED REAL TIME APPLY，且V$MANAGED_STANDBY中MRP0状态稳定为APPLYING_LOG
最常被忽略的是：RAC 环境下，备库的 STANDBY REDO LOG 必须按 THREAD 单独添加，缺一个线程的 SRL，对应实例产生的日志就永远进不了应用队列——此时 V$ARCHIVED_LOG 里全是 APPLIED = NO，但 V$ARCHIVE_GAP 却查不到缺口。
