srvctl add service仅注册服务元数据，不启动服务，必须手动执行srvctl start service；常见问题包括crsctl stat res -t看不到资源、ORA-12514报错、lsnrctl services无对应service_name。
srvctl 是 Oracle 12c RAC 中管理数据库服务（service）的核心工具，它不操作数据库内部对象，而是控制 CRS 注册的服务资源生命周期和分布策略。直接用 SQL 创建的服务不会被集群识别，必须通过 srvctl 添加、启动、配置才能参与高可用调度。
添加 service 前必须确认的三件事
很多失败源于前置条件缺失，不是命令写错：
-
srvctl add service要求数据库已注册到集群（srvctl config database -d <db_name></db_name>能返回结果），否则报PRCR-1070 : Failed to check if resource ora.<db_name>.db is registered</db_name> - 服务名不能含下划线或特殊字符（如
my_service合法，my-service或my@service会触发PRKO-2002 : Invalid service name） - 指定的运行节点（
-r）必须是当前数据库实例实际运行的节点；若实例未在该节点启动，srvctl start service会卡住并最终超时
srvctl add service 的关键参数组合
Oracle 12c 对参数校验更严格，尤其在 RAC One Node 和多实例场景下：
- 基础添加（两节点负载均衡）：
srvctl add service -d orcl -s app_svc -r "orcl1,orcl2" -a "PRIMARY"——-a指定故障转移角色，非可选 - 只在特定实例上运行（避免跨节点连接）：
srvctl add service -d orcl -s report_svc -i orcl1 -a "PRIMARY"——-i比-r更精确，但仅适用于单实例绑定场景 - 启用 TAF（透明应用故障转移）：
srvctl add service -d orcl -s taf_svc -r "orcl1,orcl2" -a "PRIMARY" -e SESSION -m BASIC -z 180 -w 5—— 其中-e（failover type）、-m（method）、-z（delay）、-w（retry）缺一不可，漏掉任一将导致客户端 TAF 不生效
srvctl start/stop service 的隐含行为
看似简单，但实际影响连接路由和故障恢复逻辑：
-
srvctl start service -d orcl -s app_svc不会立即让服务对客户端可见；需等待监听器刷新服务注册（通常 10–30 秒），期间lsnrctl services可能仍不显示该服务 -
srvctl stop service默认执行 graceful shutdown：等待现有会话自然结束，不中断活跃事务；加-f才强制终止所有关联会话（类似ALTER SYSTEM KILL SESSION） - 服务停止后，其监听端口（如 1521）仍被 LISTENER 占用，只是不再响应该服务名的连接请求；无需重启监听器
检查 service 状态时容易忽略的细节
srvctl status service 返回的信息有限，真正排障要交叉验证：
-
srvctl status service -d orcl -s app_svc只告诉你“running”或“not running”，不说明在哪台节点运行；需配合srvctl config service -d orcl -s app_svc查看Preferred instances和Available instances - 即使状态为 running，客户端仍连不上？立刻查
lsnrctl status输出中的SERVICE_NAME列是否包含该服务名，以及status是否为READY（非UNKNOWN） - 服务自动 failover 失败？确认
srvctl config service中的Failover type和Failover method与客户端连接字符串中(FAILOVER_MODE=(...))完全一致，大小写敏感
srvctl 的异步特性（如监听器延迟注册、CRS 资源状态同步延迟）最容易被当成“命令没生效”。与其反复重试，不如先看 crsctl stat res -t | grep app_svc 和 tail -f $GRID_HOME/log/<node>/client/ohasd.log</node>。
