srvctl start service不生效主因是服务未绑定当前VIP或autostart未启用；需验证VIP在线性、local_listener指向公网VIP、服务failovertype配置及AUTO_START=always属性。
srvctl start service不生效，但VIP已切换
这说明服务资源（ora.<db_name>.svc</db_name>）虽然注册在CRS中，但未绑定到当前活跃节点的VIP。RAC服务依赖VIP存活，而VIP又依赖网络接口和子网配置。常见原因是：节点间心跳正常，但VIP所在网卡子网掩码不一致、DNS解析失败导致SCAN无法反向定位VIP，或服务资源配置里指定了错误的-serverpool或-failovertype参数。
检查步骤如下：
- 确认VIP是否真在线：
srvctl status vip -n <node_name></node_name>，再用ifconfig核对对应网卡IP和子网掩码是否与srvctl config vip输出一致 - 验证服务是否绑定到正确VIP：
srvctl config service -d <db_name></db_name>，重点看Preferred instances和Available instances是否包含当前节点，且Failover type为SESSION或SELECT而非NONE - 检查服务启动时是否被强制限制在某节点：
crsctl stat res -p ora.<db_name>.svc | grep SERVER_POOLS</db_name>，若返回SERVER_POOLS=Free，说明没绑定池，需用srvctl modify service显式指定
客户端连接报ORA-12514，但lsnrctl status显示服务已注册
这是典型的监听器未将服务名动态注册进远程SCAN监听器的现象。19c RAC默认启用动态注册，但若数据库实例的local_listener参数指向了私网地址（如rac1-priv），而SCAN监听器只监听公网或SCAN VIP，就会导致服务名“可见但不可达”。
必须确保每个实例的local_listener指向本节点的公网VIP或SCAN别名：
- 查当前设置：
show parameter local_listener，若返回(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-priv)(PORT=1521))，就是错的 - 修正为公网VIP：
alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))' scope=both; - 或更推荐用SCAN别名（需提前在
tnsnames.ora中定义）：alter system set local_listener='RAC_SCAN' scope=both; - 强制重注册：
alter system register;，然后在任意节点执行lsnrctl status LISTENER_SCAN1，确认Service "<service_name>" has 1 instance(s)</service_name>出现在输出中
srvctl relocate service执行后服务仍在原节点
srvctl relocate service不是强制迁移命令，它只是向CRS发起“建议迁移”请求。CRS是否执行，取决于服务配置中的-failovertype和-failovermethod，以及当前节点负载、资源可用性等策略判断。若服务配置为-failovertype NONE，该命令直接被忽略。
真正可控的迁移方式只有两种：
- 手动停启：
srvctl stop service -d <db_name> -s <svc_name> -i <old_inst></old_inst></svc_name></db_name>→srvctl start service -d <db_name> -s <svc_name> -i <new_inst></new_inst></svc_name></db_name> - 修改服务策略并触发自动故障转移：
srvctl modify service -d <db_name> -s <svc_name> -failovertype SESSION -failovermethod BASIC</svc_name></db_name>，再人为让原实例异常（如kill -9PMON进程），CRS会在60秒内自动拉起服务到另一节点
注意：srvctl relocate service仅在-failovertype为AUTO且-policy为MANUAL时才有效，但19c默认不启用该模式。
集群重启后服务未自动上线
服务默认不会随CRS启动而自动启动，除非显式设置了autostart属性。很多DBA以为srvctl add service后就万事大吉，其实漏掉了关键一步。
补救方法很简单：
- 查当前autostart状态：
crsctl stat res ora.<db_name>.svc -p | grep AUTO_START</db_name>，若返回AUTO_START=restore或never，即为问题根源 - 启用自动启动：
srvctl modify service -d <db_name> -s <svc_name> -autostart true</svc_name></db_name> - 验证：
crsctl stat res ora.<db_name>.svc -p | grep AUTO_START</db_name>应返回AUTO_START=always
这个AUTO_START属性容易被忽略，因为srvctl命令不直接显示它，必须用crsctl stat res -p深挖元数据。一旦设为always，下次crsctl start crs或主机重启，服务就会跟着VIP一起上线。
