pdb本身无独立高可用能力，因其是逻辑容器，依赖cdb实例和rac服务；需通过srvctl add service绑定服务并配置故障转移策略才能实现跨节点自动切换。
Oracle 19c RAC 中 PDB 本身不提供独立的高可用机制——它的高可用完全依赖于底层 CDB 实例和集群服务的调度。想让某个 PDB “故障自动切走”或“跨节点重启”，不能靠 PDB 自身，必须通过 srvctl add service 显式绑定服务 + 配置故障转移策略。
为什么 PDB 没有独立的高可用能力
PDB 是逻辑容器，没有自己的后台进程、内存结构或监听端口。它运行在 CDB 实例之上，共享同一套 SGA/PGA 和 Oracle 进程。RAC 的高可用粒度最小是实例（instance）或服务（service），不是 PDB。
常见误解：以为 alter pluggable database pdb1 save state 就能实现 PDB 级别容错——它只控制启动时是否自动 OPEN，不解决运行中实例崩溃后的服务接管问题。
- PDB 在节点1上 OPEN，节点2上仍是 MOUNTED，不代表它具备跨节点运行能力
- 若节点1宕机，PDB1 不会自动在节点2上 OPEN 并接管连接——除非你提前注册了服务并启用 TAF 或 LOAD_BALANCE
- 默认情况下，PDB 的服务名（如
pdb1）只注册到当前活跃实例，不会自动漂移到其他节点
srvctl add service 配置跨节点服务
这是实现 PDB 级别高可用的核心操作：把 PDB 绑定为一个可被 SCAN 监听器识别、支持故障转移的集群服务。
执行前确保：
- PDB 当前处于
READ WRITE状态（show pdbs验证） - CDB 已在所有 RAC 节点上正常运行（
crsctl stat res -t | grep ora.cdb） - 目标服务名未被占用（如
pdb1_svc，避免与 PDB 名直接重名）
典型命令：
srvctl add service -db orcl -service pdb1_svc -pdb pdb1 \ -preferred "p19c01,p19c02" \ -available "" \ -failover_type SELECT \ -failover_method BASIC \ -failover_retries 180 \ -failover_delay 5 \ -edition default
关键参数说明：
-
-preferred：指定该服务优先运行在哪几个实例上（不是“仅限”，而是首选） -
-failover_type SELECT：支持 SELECT 类型会话的透明应用故障转移（TAF） -
-failover_method BASIC：连接断开后自动重连新实例（非 PRECONNECT） - 服务注册后需手动启动：
srvctl start service -db orcl -service pdb1_svc
客户端连接必须用 SERVICE_NAME，不能用 SID
即使你在 tnsnames.ora 里配了类似 (SERVICE_NAME = pdb1) 的条目，如果没通过 srvctl 注册，监听器根本不知道这个服务存在，连接会报 ORA-12514: TNS:listener does not currently know of service requested in connect descriptor。
正确 tnsnames.ora 示例（指向 SCAN）：
PDB1_SVC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = p19c-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = pdb1_svc)
(FAILOVER_MODE = (TYPE = SELECT)(METHOD = BASIC)(RETRIES = 180)(DELAY = 5))
)
)
- 必须使用
SERVICE_NAME，不是SID—— PDB 没有 SID -
FAILOVER_MODE客户端配置要和服务端srvctl参数对齐，否则 TAF 不生效 - Java 应用 JDBC URL 中也必须写
service_name=pdb1_svc，不能写sid=pdb1
验证服务是否真正具备高可用能力
配置完别急着上线，必须实测故障场景：
- 用
sqlplus user/pass@pdb1_svc连接，查select instance_name from v$instance;确认当前落在哪个节点 - 在该节点上执行
srvctl stop instance -db orcl -i p19c01模拟实例宕机 - 立刻在原会话执行一条新查询（如
select sysdate from dual;），观察是否自动重连成功且返回结果 - 检查
srvctl status service -db orcl，确认服务已自动迁移到另一节点
容易忽略的一点：如果 PDB 内部对象依赖本地临时表空间或特定数据文件路径（比如用了非 ASM 的绝对路径），故障切换后可能因文件不可达而 OPEN 失败——务必确保所有数据文件、tempfile、redo 均在共享存储（ASM 或 NFS）上，且路径在所有节点一致。
