oracle 19c 不支持 pdb 级别独立 data guard，因其为物理复制机制，作用于整个 cdb 实例层面；pdb 共享 cdb 的重做日志、控制文件和归档路径，无法单独产生或应用 redo，唯一官方支持方案是全 cdb adg。
Oracle 19c 不支持 PDB 级别独立 Data Guard
因为 Data Guard 是物理复制机制，作用于整个 CDB 实例层面，不是逻辑对象层。PDB 只是 CDB 内部的可插拔容器，没有独立的重做日志流、控制文件或归档路径——它共享 CDB 的 ONLINE REDO LOG、ARCHIVELOG 和物理结构。你无法让一个 PDB 单独产生、传输或应用 redo，也就谈不上为单个 PDB 配置独立的 standby。
试图“只保护某个 PDB”会触发哪些错误
常见误操作包括：在主库上只对某个 PDB 执行 ALTER PLUGGABLE DATABASE ... OPEN READ ONLY 后就以为隔离了；或试图用 RMAN 备份单个 PDB 并还原到另一台库当“standby”。这些都会失败，典型现象有：
-
ORA-65096: invalid common user or role name—— 在备库尝试创建与主库同名 PDB 时权限或命名空间冲突 -
ORA-65139: mismatched file name in XML metadata—— 使用RMAN DUPLICATE TARGET DATABASE TO ... PLUGGABLE DATABASE时控制文件不匹配 - MRP 进程报
ORA-01110或跳过某些数据文件，因为备库缺少对应 PDB 的表空间文件头一致性
真正可行的替代方案只有两种
如果业务需要某几个 PDB 具备容灾能力，必须拉通整个 CDB 架构来设计：
-
全 CDB ADG：主库是 CDB（含多个 PDB），备库也是完整 CDB，所有 PDB 自动同步。这是唯一被 Oracle 官方支持的模式，要求主备 CDB 的
DB_NAME相同、DB_UNIQUE_NAME不同，并启用FORCE LOGGING和归档 -
PDB-Level Logical Standby（不推荐）：理论上可用
DBMS_LOGSTDBY做逻辑复制，但 19c 中已弃用且不支持多租户场景下的 DDL 自动传播，维护成本极高，实际生产中几乎无人使用
容易被忽略的关键细节
即使走全 CDB ADG 路线，PDB 特性也会带来额外约束：
- 备库上所有 PDB 默认处于
MOUNTED状态，不能单独OPEN某个 PDB —— 必须先ALTER DATABASE OPEN整个 CDB，再逐个ALTER PLUGGABLE DATABASE ... OPEN - Switchover 后，原主库 CDB 中所有 PDB 的状态会被重置为
MOUNTED，需手动打开，否则应用连不上 -
STORAGE(MAXSIZE)等 PDB 级限制参数在备库生效，但不会参与 redo 传输判断；若主库 PDB 写满触发ORA-65001，备库同步会卡在对应 SCN，MRP 停滞
