srvctl添加服务时必须显式指定所有目标RAC实例，-r参数需完整列出如-r "CDB11,CDB12"，漏写则对应节点无法响应连接，导致ORA-12514或部分节点连通失败。
srvctl 添加服务时必须显式指定所有 RAC 实例
oracle rac 中 pdb 的“独立路由”不是靠数据库内部自动分发，而是靠 srvctl 注册的服务绑定到具体实例来实现的。漏写某个实例名，该节点就无法响应这个服务的连接请求。
常见错误现象：客户端偶尔连不上、ORA-12514、或只在 rac1 上能连通而 rac2 报错“service not registered”。
-
srvctl add service的-r参数必须列出所有目标实例，例如-r "CDB11,CDB12"，不能只写一个 - 实例名必须与
srvctl config database -d CDB1输出的一致，大小写敏感 - 若新增节点，必须重新执行
srvctl add service并启动，旧服务不会自动扩展
tnsnames.ora 里 SERVICE_NAME 必须匹配 dba_services.network_name
客户端连接走的是监听器注册的服务名，不是 PDB 名本身。很多用户直接用 PDB1 当 service name，但实际注册的可能是 PDB1.taryartar.com，导致连接失败。
使用场景：应用部署在不同网络区，或通过负载均衡器转发连接时，network_name 不一致会直接断连。
- 查真实注册名：
SELECT name, network_name, pdb FROM dba_services WHERE pdb = 'PDB1'; - tnsnames.ora 条目中
SERVICE_NAME值必须和network_name完全一致（含域名） - 不要依赖默认生成的
network_name；创建服务时可用-e指定，例如srvctl add service ... -e "PDB1.prod"
ALTER PLUGGABLE DATABASE OPEN INSTANCES=ALL 是硬性要求
PDB 在 RAC 下默认只在当前连接的实例打开，不加 INSTANCES=ALL 就等于只开了半扇门——监听器虽然注册了服务，但另一个节点上 PDB 是 MOUNTED 状态，无法接受会话。
性能影响：如果某节点 PDB 未打开，连接请求会被监听器转发过去，然后立刻被拒绝，造成超时和重试，拖慢整体响应。
- 检查状态用：
SELECT inst_id, open_mode FROM gv$pdbs WHERE name = 'PDB1';，确保每行都是READ WRITE - 打开命令必须在
CDB$ROOT下执行，且不能省略INSTANCES=ALL - 开机自启要配：
ALTER PLUGGABLE DATABASE PDB1 SAVE STATE;，否则重启后又变单点
SCAN 地址 + SERVICE_NAME 才构成真正高可用路由
只配 VIP 或单节点地址，就失去了 RAC 的故障转移能力。客户端必须通过 SCAN（Single Client Access Name）+ SERVICE_NAME 组合才能触发 Oracle 的透明应用故障转移（TAF）。
容易踩的坑：开发测试环境常直连 rac1:1521，上线后一出故障就全挂，因为没走 SCAN 和服务层路由逻辑。
- tnsnames.ora 中
ADDRESS必须指向 SCAN IP 或 SCAN hostname，不是某个节点的 VIP - 确保 DNS 或 hosts 能解析 SCAN，
nslookup your-scan-name应返回三个 IP - 服务注册后，
lsnrctl status输出里每个Service "xxx"下要有对应实例数的instance(s)行
