Oracle 12c 不支持单个 PDB 级 Data Guard 容灾，所有 DG 功能均绑定于 CDB 层级；PDB 内执行 ALTER PLUGGABLE DATABASE 相关 DG 命令必报 ORA-65040，且备库 PDB 默认 MOUNTED，需手动 CANCEL 恢复后 OPEN READ ONLY 并 CLOSE IMMEDIATE 才能切回同步。
ALTER PLUGGABLE DATABASE 命令在 PDB 内执行任何 Data Guard 相关操作都会失败，因为 Oracle 12c 根本不支持 PDB 级别的 Data Guard 容灾。所有 DG 功能（日志传输、归档应用、保护模式）都绑定在 CDB 层级，PDB 是被动容器，无法独立参与 DG 流程。
ORA-65040：在 PDB 中执行 DG 命令的必然报错
你如果在 PDB$SEED 或某个用户 PDB（如 PDB1）里运行：
ALTER PLUGGABLE DATABASE SET STANDBY DATABASE;
会立刻收到：
ORA-65040: operation not allowed from within a pluggable database
这是因为：
-
V$DATABASE、LOG_ARCHIVE_DEST_n、FORCE LOGGING等核心视图和参数只存在于CDB$ROOT - PDB 内部查不到这些对象，也无权修改
- DG 的日志流控制、角色切换、状态同步全部由 CDB 实例统一调度
所以，不要尝试在 PDB 中配置或启动 DG —— 不是权限问题，是架构限制。
LOG_ARCHIVE_DEST_2 必须指向备库 CDB，不是 PDB 服务名
主库 CDB 配置归档目标时，SERVICE 参数必须填备库 CDB 的监听名，例如：
LOG_ARCHIVE_DEST_2='SERVICE=stby_cdb SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_standby'
常见错误写法（会导致归档失败）：
-
SERVICE=pdb1_stby（PDB 服务名） -
SERVICE=stby_cdb:pdb1（非法语法） - 漏写
DB_UNIQUE_NAME或与备库实际值不一致
验证是否生效：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
只要 STATUS 不是 VALID，就说明网络、tnsnames.ora、监听器或 GLOBAL_DBNAME 配置有误。
备库 PDB 默认 MOUNTED，手动 OPEN READ ONLY 前必须 CANCEL 恢复
即使 CDB 级 DG 已正常运行，备库上所有 PDB 的状态仍是：
MOUNTED
这是 Oracle 明确设计，不是异常。要让某个 PDB 提供只读查询能力，必须：
- 先暂停日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
- 再打开指定 PDB：
ALTER PLUGGABLE DATABASE pdb1 OPEN READ ONLY;
- 切回同步前，必须先关闭该 PDB：
ALTER PLUGGABLE DATABASE pdb1 CLOSE IMMEDIATE;
- 最后重启恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
漏掉 CLOSE IMMEDIATE 是自动化脚本中最常踩的坑，会导致后续 START APPLY 报 ORA-65115。
不同 PDB 无法设置不同保护模式，混合 RPO 需求只能拆 CDB
MAXIMUM PROTECTION、MAXIMUM AVAILABILITY 这些模式由 LOG_ARCHIVE_DEST_2 的 SYNC/AFFIRM 属性决定，作用于整个 CDB。
你不能让 pdb1 走最大保护，pdb2 走最大性能。强行混用的结果是：
- 高 RPO 要求的 PDB 实际降级（因低要求 PDB 拖慢提交）
- 或低要求 PDB 被强制同步，事务延迟升高
真正需要“单 PDB 容灾”的场景，本质是业务隔离没被 CDB 架构满足 —— 此时应评估是否该用多个独立 CDB，各自配一套 DG，而不是在单个 CDB 内硬凑。
