oracle 12c中pdb的data guard同步由cdb级机制驱动，standbys子句是唯一控制开关：默认standbys=all（自动同步），创建时指定standbys=none可排除该pdb，且该设置不可修改；后续无法动态启用或禁用，验证需在主备库分别查询v$pdbs及v$datafile确认状态。
oracle 12c multitenant环境下，单pdb的data guard同步不是独立配置的——它由cdb级redo传输与应用机制驱动，standbys子句才是控制单个pdb是否参与dg的关键开关。默认所有pdb都同步，若需排除某个pdb，必须在创建时显式指定standbys=none，后续无法动态修改该属性。
CREATE PLUGGABLE DATABASE时必须指定STANDBYS子句
Oracle DG 12c不支持对已存在PDB单独开启/关闭同步；STANDBYS仅在CREATE PLUGGABLE DATABASE语句中生效，且只接受ALL或NONE两个值：
-
STANDBYS=ALL（默认）：PDB数据文件随CDB redo一起传输，在standby CDB中自动创建并保持online状态 -
STANDBYS=NONE：PDB在standby CDB中不被创建，对应数据文件标记为UNNAMED、状态为OFFLINE，不会参与日志应用 - 创建后无法用
ALTER PLUGGABLE DATABASE修改该设置，强行尝试会报错ORA-65128: cannot modify STANDBYS attribute for a pluggable database - 示例语句：
CREATE PLUGGABLE DATABASE pdb_exclude ADMIN USER pdb_adm IDENTIFIED BY pwd123 STANDBYS=NONE;
验证PDB是否实际参与DG同步
不能只看SHOW PDBS输出，需结合CDB和standby侧双重确认：
- 主库查PDB状态：
SELECT con_id, name, open_mode FROM v$pdbs WHERE name = 'PDB_EXCLUDE';—— 正常应为READ WRITE - standby库执行相同查询，若返回空行或
CON_ID为0，说明该PDB未被创建（即STANDBYS=NONE生效） - 检查standby数据字典：
SELECT name, status FROM v$datafile WHERE con_id = 0 AND name LIKE '%pdb_exclude%';—— 若有记录且status为UNNAMED，即为被排除状态 - 注意：即使PDB被排除，其元数据（如
CDB_PDB_HISTORY）仍存在于standby CDB中，不可据此误判同步状态
tnsnames.ora和服务名配置不影响DG同步范围
客户端连接使用的tnsnames.ora服务名（如PDB_EXCLUDE）与DG同步逻辑完全解耦：
- standby CDB是否包含某PDB，只取决于创建时的
STANDBYS设置，与监听器是否注册该服务无关 - 即便在standby上手动添加
PDB_EXCLUDE服务条目，也无法让被STANDBYS=NONE排除的PDB“复活”——缺少数据文件和控制文件信息，连接会直接失败 - 常见误操作：在standby上执行
ALTER PLUGGABLE DATABASE pdb_exclude OPEN READ ONLY，结果必报ORA-65105: unable to open pluggable database - 真正需要关注的是
log_archive_dest_n参数中的db_unique_name是否覆盖全部CDB，而非单个PDB的服务名
最易被忽略的一点：STANDBYS=NONE的PDB在standby上并非“不存在”，而是处于一种半残缺状态——数据文件路径保留但内容为空，控制文件里没有其SCN轨迹。一旦误删主库该PDB再尝试重建，若忘记重加STANDBYS=NONE，它就会意外进入standby，导致后续角色切换失败。这种状态差异不会在DG Broker界面高亮提示，只能靠脚本定期比对v$pdbs输出。
