dgmgrl convert to snapshot standby 会hang或报ora-16139，根本原因是物理备库状态不合规：mrp0进程未取消、fra未配置或已满、数据库未处于mounted状态，三者缺一不可。
不能“一键”转换，DGMGRL 的 CONVERT 命令只是触发器，背后必须满足三重前置条件，否则会卡住或报错。
为什么 DGMGRL CONVERT TO SNAPSHOT STANDBY 会 hang 或报 ORA-16139
根本原因不是命令本身有问题，而是物理备库状态不合规。DGMGRL 执行该命令前，不会自动校验 FRA 空间、MRP 进程状态或数据库挂载模式 —— 它只发指令，不兜底。
-
MRP0进程仍在APPLYING_LOG：必须先执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL，再查V$MANAGED_STANDBY确认STATUS = 'IDLE'或无记录 - FRA 未配置或已满：
db_recovery_file_dest必须指向本地文件系统或 ASM（不能是 NFS），且SPACE_USED / SPACE_LIMIT > 0.85时大概率失败 - 数据库未处于
MOUNTED状态：如果当前是READ ONLY WITH APPLY，DGMGRL 不会帮你 shutdown + startup mount —— 你得手动做：SHUTDOWN IMMEDIATE→STARTUP MOUNT
DGMGRL 转换前必须手动完成的三步检查
跳过任何一步，CONVERT 都可能卡在 “please wait” 或抛出 ORA-38705（flashback database not enabled）—— 实际上不是闪回没开，而是 FRA 不可用导致还原点无法创建。
- 查 FRA 空间：
SELECT NAME, SPACE_LIMIT, SPACE_USED FROM V$RECOVERY_FILE_DEST;，若不足，先清理归档或扩容：ALTER SYSTEM SET db_recovery_file_dest_size=50G SCOPE=BOTH; - 查 MRP 状态：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';，返回空或STATUS = 'IDLE'才安全 - 确认挂载状态：
SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;，必须是MOUNTED+PHYSICAL STANDBY
执行 DGMGRL CONVERT 后必须立刻做的两件事
命令返回 converted successfully 只代表控制文件标记已改，数据库仍停在 MOUNTED 状态，无法连接。
- 必须手动执行：
ALTER DATABASE OPEN;，否则客户端连sqlplus / as sysdba都会报ORA-01033 - 验证是否生效：
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;，正确结果是SNAPSHOT STANDBY+READ WRITE
切回物理备库时最易忽略的隐性依赖
快照备库期间主库产生的所有归档日志，必须完整保留在主库和传输队列中。一旦丢失某一个归档（比如被 DELETE ARCHIVELOG 清掉），切回时会卡在“applying archived log”并最终报 ORA-16055 或 ORA-16664。
这不是 DGMGRL 的问题，而是快照备库恢复机制决定的：它靠应用全部中断期间的归档来重建物理一致性。所以哪怕你只有一个备库，也别在快照期清理主库归档 —— 这个约束比 FRA 空间还硬。
