Oracle RAC服务无显式“首选实例”参数，其倾向性由srvctl的-preferred选项、CRS资源依赖（如RG_AFFINITIES）、CLB_GOAL设置及客户端TNS中INSTANCE_NAME共同决定。
Oracle RAC 服务的“首选实例”不是靠数据库参数或 SQL 命令直接设置的，而是由服务（Service）的 FAILOVER_TYPE、CLB_GOAL 和客户端连接方式共同决定的——默认情况下没有强制“首选”，只有负载均衡或故障转移策略下的倾向性行为。
服务创建时如何指定首选实例（srvctl + dbca）
Oracle 不提供类似 PRIMARY_INSTANCE 这样的显式配置项，但可通过服务定义中的 -preferred 参数在 srvctl 中声明倾向节点：
-
srvctl add service -d orcl -s app_svc -r orcl1,orcl2 -preferred orcl1 -available orcl2：表示正常情况下优先路由到orcl1，仅当orcl1不可用时才用orcl2 -
-preferred列表中的实例会成为服务的“首选成员”，-available是备选；两者必须是当前已注册的实例名（v$instance.instance_name） - 该设置只影响服务启动时的初始分配和故障恢复后的回切逻辑，不改变运行时的连接分发行为（除非配合
CLB_GOAL=SHORT或客户端 TNS 配置） - 若使用 DBCA 创建服务，默认不填
-preferred，服务会在所有启用实例间负载均衡
tnsnames.ora 中硬编码实例名会绕过负载均衡
当客户端连接串中显式指定 INSTANCE_NAME，就等于人工指定了“首选”：
APP_PREFERRED =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = app_svc)
(INSTANCE_NAME = orcl1) <-- 关键：强制连 orcl1
)
)
- 这种写法会让监听器忽略服务的负载均衡策略，直接将连接路由到指定实例
- 风险明显：若
orcl1意外宕机，客户端会报ORA-12514: TNS:listener does not currently know of service requested in connect descriptor - 仅适用于调试、维护窗口或有强亲和性要求（如绑定特定节点跑报表）的极少数场景
依赖 VIP 和资源依赖关系实现高可用前提下的倾向性
真正影响“首选”生效的前提，是底层集群资源的依赖与联机顺序：
- Oracle RAC 服务资源（
SUNW.oracle_rac_server）必须依赖SUNW.rac_framework资源（即rac-framework-rg），否则服务无法启动 - 若服务资源组设置了
RG_AFFINITIES=++rac-fmwk-rg，则其启动严格跟随框架资源组状态，而框架资源组通常按节点列表顺序尝试联机（如-n node1,node2） - 这意味着：如果
node1上的rac-framework-rg先联机成功，app_svc更大概率在orcl1上被拉起——这构成了隐式的“首选节点”效果 - 验证命令：
crsctl stat res -t | grep app_svc查看当前运行节点；clresourcegroup status看资源组实际主节点
复杂点在于：所谓“首选”从来不是孤立配置项，它始终嵌套在 CRS 资源依赖链、服务启停策略、监听器转发逻辑和客户端解析行为四层之中。漏掉任意一层（比如没配 RG_AFFINITIES，或客户端用了 SCAN 但没设 FAILOVER_MODE），所谓的“首选”就会失效或产生意外行为。
