Oracle 12c Data Guard中PDB不同步的根本原因是其恢复状态独立控制，需显式执行ALTER PLUGGABLE DATABASE ENABLE RECOVERY并确保备库路径存在；CDB级日志同步不自动启用PDB恢复，否则MRP遇创建操作将报ORA-65169停摆。
oracle 12c data guard中pdb不同步，不是靠“cdb级别日志同步模式”能解决的——根本不存在这个配置项。 你看到的所谓“cdb级别同步模式”，其实是混淆了概念：data guard的日志传输和应用始终在cdb层面运行，但每个pdb的恢复状态是独立控制的。真正决定某个pdb是否同步的，是它的recovery_status和是否处于enable recovery状态。
为什么ALTER DATABASE RECOVER不自动同步所有PDB
物理备库上执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE，只启动MRP进程去应用归档/实时日志，但它不会强制打开或启用任何PDB的恢复。每个PDB必须显式启用恢复，否则即使日志已传到备库，MRP遇到创建该PDB的数据文件操作时就会报错停摆（如ORA-65169）。
常见错误现象包括：
- 备库
SHOW PDBS中某PDB显示MOUNTED而非READ ONLY -
SELECT name, recovery_status FROM v$pdbs返回DISABLED - MRP进程状态为
APPLYING_LOG但很快变为STOPPED，告警日志出现Automatic Copy of Standby datafiles for create pdb failed
如何检查并启用指定PDB的恢复
必须在备库上以SYS身份，逐个切换容器并启用恢复。不能跳过ALTER SESSION SET CONTAINER=xxx这一步，否则ALTER PLUGGABLE DATABASE语句会报错或作用于CDB$ROOT。
操作步骤如下：
- 先取消当前日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL - 确认目标PDB名（比如
CHECKPDB），然后切换容器：ALTER SESSION SET CONTAINER=CHECKPDB - 确保PDB处于
MOUNTED状态（若OPEN，先ALTER PLUGGABLE DATABASE CLOSE） - 启用恢复：
ALTER PLUGGABLE DATABASE ENABLE RECOVERY - 回到CDB根容器：
ALTER SESSION SET CONTAINER=CDB$ROOT - 重启日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION
注意：ENABLE RECOVERY本身不改变PDB的OPEN模式，它只是允许MRP在后续应用日志时自动创建数据文件、回放事务。PDB最终能否变成READ ONLY，取决于日志是否完整、路径是否存在、空间是否充足。
为什么DISABLE RECOVERY后不能直接DROP PDB
ADG备库是只读环境，DROP PLUGGABLE DATABASE命令在备库上被禁止执行，无论PDB是否DISABLED。这是Oracle硬性限制，不是权限问题。
如果真要清理一个长期不用且已DISABLE RECOVERY的PDB：
- 先查清它的数据文件位置：
SELECT file_name FROM cdb_data_files WHERE con_id = (SELECT con_id FROM v$pdbs WHERE name = 'XXX') - 确认这些文件未被其他PDB复用（尤其是共享表空间）
- 在操作系统层手动
rm对应文件（务必提前备份控制文件） - 最后在CDB$ROOT中执行
ALTER PLUGGABLE DATABASE XXX CLOSE IMMEDIATE，再DROP PLUGGABLE DATABASE XXX INCLUDING DATAFILES——但这一步只能在主库做，备库无法完成
实际运维中，更安全的做法是让该PDB保持DISABLED但留着元数据，避免误删或路径残留引发后续同步冲突。
最易被忽略的一点：PDB启用恢复后，若其数据文件所在路径在备库不存在，MRP仍会失败。不要只盯着SQL命令，必须提前在备库创建好对应目录结构，否则ENABLE RECOVERY只是“挂了个钩子”，等日志来时照样崩。
