srvctl add service仅注册服务元数据，不启动服务，必须手动执行srvctl start service；否则crsctl stat res -t不可见、lsnrctl services无service_name、应用报ora-12514。
srvctl add service 只注册元数据，不启动服务 —— 这是绝大多数人连不上、查不到、报 ora-12514 的根本原因。
srvctl add service 后服务没起来，查什么？
执行完 srvctl add service，crsctl stat res -t 里看不到对应资源，lsnrctl services 里也没有 service_name，应用一连就报 ORA-12514: TNS:listener does not know service requested —— 这不是配置错了，是压根没启动。
- 先确认服务是否已启动：
srvctl status service -d <db_name> -s <service_name></service_name></db_name> - 如果显示 “not running”，必须手动启动：
srvctl start service -d <db_name> -s <service_name></service_name></db_name> - 再检查监听器是否识别该服务：
lsnrctl services <listener_name></listener_name>（默认监听器名通常是LISTENER） - 注意：服务启动依赖实例在线，用
srvctl status instance -d <db_name></db_name>确认目标实例状态
preferred 和 available 实例怎么配才不翻车？
参数 -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 - 典型隔离场景：A 应用高可用 →
-r rac1,rac2；B 应用轻量级 →-r rac1 -a rac2，默认只在 rac1 跑，rac1 故障才切到 rac2
业务连接必须用 SERVICE_NAME，别碰 INSTANCE_NAME
Oracle RAC 里业务隔离的载体是 service_name，不是 instance_name 或 SID。监听器按 service_name 路由，集群按 service_name 做负载均衡与故障转移。
- 客户端 tnsnames.ora 中必须写
SERVICE_NAME=<your_service></your_service>，不能写INSTANCE_NAME=rac1或SID=rac1 - 写
INSTANCE_NAME会绕过 service 机制，失去故障转移、TAF、CLB、动态重定位等所有 RAC 能力 - 不同业务线用不同
service_name，再配合DBMS_SERVICE.MODIFY_SERVICE动态调整运行实例，才是真实隔离 - 19c 起
service_names参数已弃用，改用srvctl add service是唯一推荐方式
19c 新增 failback=yes 要不要开？
Oracle 19c 引入 -failback yes，让服务在原首选实例恢复后自动迁回。但这个“自动”有前提，且容易被忽略：
- 只有显式加了
-failback yes，srvctl config service才会显示Failback: YES；没加就是 no，且不提示 - failback 触发需满足：原
preferred实例已 online、health OK、且当前服务不在其上运行 - 它不保证秒级回切，也不干预人工
srvctl relocate service操作，只是增加一层策略选项 - 生产环境建议开启，但必须配合监控确认回切成功，不能假定“加了就一定回来”
真正容易被忽略的是：service 配置本身不生效于已建立的连接，所有变更（增删实例、修改 failover 类型、启用 failback）都只影响新连接。老连接仍留在原实例，直到断开重建。
