Oracle 12c中PDB不支持独立Failover，实际是CDB实例通过Data Guard切换；切换后需手动OPEN PDB、注册并启动其服务名，确保连接路径与读写模式正确。
Oracle 12c 多租户环境中 PDB 本身不支持独立 Failover —— 这是关键前提。所谓“PDB Failover”，实际是误称；真正发生故障切换的，是底层的 CDB 实例（即整个容器数据库），通常依托 Data Guard 配置实现物理或逻辑备库切换。PDB 作为 CDB 内部逻辑单元，随 CDB 一起切换，不单独参与角色转换。
因此，“PDB Failover 后重新同步”本质是：CDB 在 Data Guard 主备切换后，如何确保所有 PDB 的数据一致性与可用性。重点不在 PDB 自身操作，而在切换后对 PDB 状态、服务注册、用户连接路径的修复。
确认切换后 CDB 角色与 PDB 状态
主库切为备库、备库升为主库后，原 PDB 不会自动打开，且服务名可能未注册到新监听器。
- 先连新主库（即原备库实例），用
SYS用户查：SELECT database_role, open_mode FROM v$database—— 必须是PRIMARY且OPEN - 查 PDB 是否已自动打开：
SELECT name, open_mode, restricted FROM v$pdbs。若open_mode = MOUNTED，需手动ALTER PLUGGABLE DATABASE pdb_name OPEN - 特别注意：若 PDB 在切换前处于
READ ONLY模式，升主后默认仍为READ ONLY，必须显式执行ALTER PLUGGABLE DATABASE pdb_name OPEN READ WRITE才能写入
修复 PDB 服务名在监听器中的注册
切换后，新主库的监听器往往只注册了 CDB 服务名（如 ORCL），而未注册各 PDB 的服务名（如 XEPDB1），导致远程客户端报 ORA-12514。
- 在新主库上，以
SYS身份运行：EXEC DBMS_SERVICE.CREATE_SERVICE('XEPDB1', 'XEPDB1')（服务名与网络名一致） - 启动服务：
EXEC DBMS_SERVICE.START_SERVICE('XEPDB1') - 验证是否生效：
SELECT name FROM v$active_services WHERE name = 'XEPDB1'—— 有返回才表示监听器已识别 - 若使用静态监听配置（
listener.ora），需手动添加 SID_DESC 并 reload 监听器：lsnrctl reload
检查并重置 PDB 用户连接上下文
PDB 切换后，原有连接池、应用配置若仍指向旧服务名或 CDB 根服务，将无法登录本地用户。
- PDB 内本地用户（如
HR）不能通过 CDB 服务名连接，必须使用 PDB 对应的服务名（如tnsnames.ora中定义的XEPDB1） - 连接测试命令：
sqlplus hr/hr@XEPDB1；失败时优先排查tnsnames.ora中该服务名的HOST、PORT、SERVICE_NAME是否指向新主库地址 - 若用户密码过期或账户锁定（常见于切换后首次连接），执行：
ALTER USER hr ACCOUNT UNLOCK IDENTIFIED BY VALUES '...'（避免重置密码导致应用配置失效，优先用IDENTIFIED BY VALUES复用原哈希）
验证跨 PDB 数据一致性（仅限逻辑备库场景）
若使用的是逻辑备库（Logical Standby），因 SQL Apply 机制限制，PDB 级别 DDL 可能被跳过或失败，需人工干预。
- 查逻辑备库应用状态：
SELECT * FROM DBA_LOGSTDBY_LOG和SELECT * FROM DBA_LOGSTDBY_EVENTS，过滤error或skip记录 - 重点关注 PDB 创建/删除/重命名等 DDL 是否被跳过 —— 逻辑备库默认不传播
CREATE PLUGGABLE DATABASE类语句，需手动在备库重建对应 PDB 结构（但不恢复数据） - 业务表数据一致性建议用
DBMS_COMPARISON对比关键表，而非依赖日志事件判断
CDB 级别的 Failover 后，PDB 的“同步”不是数据块级拉取，而是服务可见性、运行状态和连接路径的快速就位。最容易被忽略的是：监听器未注册 PDB 服务名 + PDB 未显式 OPEN READ WRITE，这两点会导致应用看似“连得上”，实则写入失败或静默降级为只读。
