oracle 12c不支持在data guard同步状态下安全执行pdb拔插操作，因db_file_name_convert无法动态覆盖新pdb的guid路径，导致备库mrp进程卡住报ora-19504等错；且备库pdb默认mounted，强行open会触发ora-65115，必须先cancel恢复、open read only再close immediate。
Oracle 12c 不支持在运行中的 Data Guard 同步状态下安全执行 PDB 拔插操作，这是设计限制，不是配置错误。
ALTER PLUGGABLE DATABASE OPEN/PLUG/UNPLUG 在 DG 环境中会触发归档路径不匹配
主库执行 CREATE PLUGGABLE DATABASE 或 ALTER PLUGGABLE DATABASE ... UNPLUG 时，会生成新的数据文件路径（如 +DATADG/SPDB/93BFEF75138BC79EE053E300A8C08BA1/DATAFILE），这些路径默认不会被 DB_FILE_NAME_CONVERT 覆盖——除非你提前手动补全所有可能的 PDB GUID 路径映射。漏配一项，备库就无法自动创建对应目录或重命名文件，导致 MRP 进程卡住并报错 ORA-19504、ORA-17627 或直接挂起恢复。
- 常见现象：备库 alert 日志出现
ORA-19504: failed to create file '/data/spdbstb/kdlxpdb/datafile/system01.dbf' - 根本原因：
DB_FILE_NAME_CONVERT是静态参数，只在数据库启动或 ALTER SYSTEM 时生效；新增 PDB 的路径不会“动态追加”进转换规则 - 验证方式：在备库 CDB$ROOT 执行
SELECT NAME FROM V$DATAFILE，对比主库新 PDB 的实际路径是否已正确映射
备库 PDB 默认 MOUNTED，且无法自动 OPEN，拔插后状态更难收敛
即使主库成功创建并 OPEN 了新 PDB，备库上该 PDB 仍处于 MOUNTED 状态，且 Oracle 明确禁止在 DG 同步进行中执行 ALTER PLUGGABLE DATABASE ... OPEN。强行操作会触发 ORA-65115: cannot open pluggable database in a physical standby database while managed recovery is active。
- 必须先
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL，再ALTER PLUGGABLE DATABASE ... OPEN READ ONLY，最后CLOSE IMMEDIATE——漏掉CLOSE IMMEDIATE会导致后续恢复失败 - 如果脚本里只写 OPEN 没写 CLOSE，下次启动同步时 MRP 会拒绝接管，因为 PDB 处于非标准打开态
- RAC 环境下还要注意：不同节点的 PDB OPEN 状态可能不一致，加剧同步断裂风险
归档日志 GAP 往往是拔插操作的间接后果
PDB 拔插本身不产生大量 redo，但会触发控制文件更新、数据字典刷新、临时段重建等隐式操作，这些操作若遇上备库文件路径缺失或恢复中断，就会导致归档日志堆积在主库却无法传到备库，最终形成 GAP。
- 典型信号：
V$ARCHIVE_GAP查出断档，V$ARCHIVE_DEST_STATUS.STATUS显示ERROR或INACTIVE - 错误常被误判为网络问题，实则根源是
LOG_ARCHIVE_DEST_2.SERVICE指向了错误的服务名（比如填了 PDB 服务名而非 CDB 服务名） - 修复 GAP 时若用
RECOVER ... FROM SERVICE，必须确保主库监听能解析该 SERVICE 名，并且备库 TNSNAMES.ORA 中对应条目指向的是 CDB，不是某个 PDB
真正麻烦的地方在于：PDB 拔插引发的问题往往延迟暴露——同步可能维持数小时才彻底卡死，而日志里混杂着路径错误、恢复中断、GAP 报告等多种线索，需要交叉比对 V$ARCHIVE_DEST_STATUS、V$DATAFILE 和 alert 日志才能准确定位。不要依赖“重启同步”来掩盖问题，先确认 DB_FILE_NAME_CONVERT 是否全覆盖、LOG_ARCHIVE_DEST_2.SERVICE 是否指向 CDB、以及每个新 PDB 在备库是否都经历过完整的 CANCEL → OPEN READ ONLY → CLOSE IMMEDIATE 流程。
