srvctl add service 必须指定 -r 和 -a 参数，否则仅注册元数据而不启动服务；需手动执行 srvctl start service 启动，并用 lsnrctl services 验证监听器识别，业务必须通过 SERVICE_NAME 连接以启用 RAC 全部高可用特性。
srvctl add service 必须配 -r 和 -a，否则服务起不来
很多人执行 srvctl add service 后发现客户端连不上、lsnrctl services 里看不到 service_name、crsctl stat res -t 里也没有对应资源——这不是配置写错了，是压根没启动。因为 srvctl add service 只注册元数据，不启动服务。
必须手动执行 srvctl start service -d 才算真正上线。启动前先确认实例在线：srvctl status instance -d ；启动后验证监听器识别：lsnrctl services （默认是 LISTENER）。
参数 -r（preferred）和 -a（available）决定服务在哪跑、故障时往哪切。配错会导致服务起不来、切不动、或永远卡死在单点：
- administrator-managed 数据库（最常见）：直接填实例名，如
-r rac1,rac2 -a rac3 - policy-managed 数据库（用 server pool）：-r 必须填 server pool 名，填实例名会报
PRKO-2002: Invalid instance name - 只设
-r rac1不设-a：rac1 挂了，服务直接 offline，不会 failover
业务模块必须用 SERVICE_NAME 连接，别碰 INSTANCE_NAME
Oracle RAC 里业务隔离的载体是 SERVICE_NAME，不是 INSTANCE_NAME 或 SID。监听器按 SERVICE_NAME 路由，集群按 SERVICE_NAME 做负载均衡与故障转移。
客户端 tnsnames.ora 中必须写 SERVICE_NAME=，不能写 INSTANCE_NAME=rac1 或 SID=rac1。写 INSTANCE_NAME 会绕过 service 机制，直接连到指定实例，失去所有 RAC 能力：TAF、CLB、动态重定位、FAN 通知全失效。
典型场景举例：
- A 应用高可用：-r rac1,rac2 → 两个节点都作为首选，负载自动分摊
- B 应用轻量级：-r rac1 -a rac2 → 默认只在 rac1 跑，rac1 故障才切到 rac2
- C 应用强隔离：单独建 service + 单独配
-r rac3，再通过DBMS_SERVICE.MODIFY_SERVICE动态调整运行实例，避免和其他业务争抢资源
19c 起 service_names 参数已弃用，srvctl 是唯一推荐方式
Oracle 19c 开始，数据库初始化参数 service_names 已被官方弃用。试图用 alter system set service_names='xxx' sid='*' 来“补救”服务不可见问题，不仅无效，还会干扰 srvctl 管理逻辑，导致状态混乱。
所有服务生命周期管理必须走 srvctl：
- 添加：
srvctl add service -d db19c -s app_finance -r rac1,rac2 -a rac3 -P basic -e session -w 60 - 启动：
srvctl start service -d db19c -s app_finance - 查看配置：
srvctl config service -d db19c -s app_finance - 动态修改运行实例：
srvctl modify service -d db19c -s app_finance -i rac1 -r（把 rac1 设为首选）
注意：19c 新增的 -failback yes 参数（2026年6月5日发布）目前仅限特定补丁集支持，生产环境未打补丁前不要启用，否则可能触发 CRS 资源状态异常。
不同业务线用不同 service_name，才是真实隔离
一个数据库可以同时运行多个 service，每个 service 可绑定不同实例集合、不同 TAF 策略、不同连接池行为。这才是业务模块级隔离的实质。
比如金融核心交易模块用 svc_core，报表分析模块用 svc_report，它们可以：
- 分别设置
-r/-a实例，避免报表跑满 CPU 影响交易响应 - 为
svc_core配-P basic -e session -w 60启用 TAF，为svc_report不配，降低开销 - 通过
DBMS_SERVICE.STOP_SERVICE临时下线报表服务，不影响交易链路 - 后续还能配合 Resource Manager，给
svc_core分配更高 CPU 资源组
容易被忽略的一点：service 的故障转移不是“瞬间完成”的。从实例宕机到 PMON 通知监听器、再到客户端重连新实例，中间有几秒空窗期。如果应用没做连接重试或 TAF 配置错误，就会暴露 ORA-12514 或 ORA-03113。所以，service 策略必须和应用侧容错能力对齐，不能只靠 DBA 单方面配置。
