在Oracle RAC集群中，服务的高可用性并不只是“能不能连上去”这么简单，它还涉及服务优先在哪些实例上运行、故障后又会由哪些实例接管。这个优先顺序就是通过Preferred实例和Available实例来定义的。理解两者的区别，是合理设计RAC服务分布和故障转移策略的基础。部分DBA在配置服务时只关注连接串和TAF参数，却忽略了这两个角色对故障切换行为的影响，结果出现节点切换不按预期、负载分布失衡等问题。下面先解释这两个概念，再通过配置和实际行为说明它们各自的作用。
简单来说，Preferred实例是服务正常运行时优先启动并对外提供服务的节点，而Available实例是备用节点。在一个四节点RAC环境中，如果服务app_svc的Preferred实例配置为racdb1和racdb2，Available实例配置为racdb3和racdb4，那么正常情况下该服务只在racdb1和racdb2上运行，racdb3和racdb4上的服务状态为OFFLINE。只有所有Preferred实例都发生故障或服务被手动迁移时，Available实例才会启动服务并开始接管连接。这种设计让DBA可以精确控制服务在集群中的运行位置和故障时的接管顺序。
一、Preferred与Available实例的底层角色关系
Oracle Clusterware管理RAC服务时，会把每个服务关联到一个实例列表。这个列表里区分了两类角色：Preferred和Available。Preferred实例是服务的“首选运行位置”，服务启动时会优先在这些实例上启动；Available实例是“可用运行位置”，只有在Preferred实例全部不可用时才会被激活。注意，这里的“全部不可用”是严格的，单位是实例，而不是节点。如果一个Preferred实例所在节点没有完全宕机，但实例崩溃，Oracle会尝试在该Preferred实例上重新启动服务，而不是立即切换到Available实例。
这种主备机制与操作系统层面的主备切换类似，但Oracle RAC的粒度更细。由于RAC本身是共享存储、多实例同时工作的架构，服务在多个实例上同时运行完全可行，为什么还要区分Preferred和Available？原因在于很多业务系统并不需要服务在所有节点上均匀分布。例如，某个报表服务可能只希望在两个计算能力更强的节点上运行，但为了高可用，另外两个节点需要随时能接管。Preferred和Available就提供了这种“指定运行位置+指定备用位置”的能力。
如果只配置了Preferred实例而没有配置Available实例，当所有Preferred实例都宕机后，服务将无法启动，客户端连接会失败。在有Available实例的情况下，服务会漂移到备用节点，连接可以继续。不过，这种漂移不是无缝的，客户端需要重新建立连接，或者依靠TAF、Application Continuity等机制来实现会话恢复。这也是为什么很多生产环境会同时配置Preferred和Available，并配合透明应用程序故障转移来降低影响。
二、使用srvctl配置Preferred与Available实例
Oracle提供了srvctl工具来创建和管理服务，其中-r参数用于指定Preferred实例列表，-a参数用于指定Available实例列表。下面是一个创建服务的示例，假设数据库名为racdb，服务名为app_svc，Preferred实例为racdb1和racdb2，Available实例为racdb3和racdb4：
srvctl add service -d racdb -s app_svc -r racdb1,racdb2 -a racdb3,racdb4 -P BASIC -e SELECT -m BASIC -z 5 -w 1
这条命令中，-r后面的实例名用英文逗号分隔，-a同理。-P BASIC表示使用基础TAF策略，-e SELECT指定故障转移类型为会话级SELECT，-m BASIC表示故障转移方法为基础模式，-z 5和-w 1分别控制重试次数和重试间隔。这些参数与Preferred、Available没有直接关系，但在创建服务时通常一并配置，因为它们共同决定了客户端的故障转移体验。
如果服务已经存在，需要调整Preferred或Available实例，可以使用srvctl modify service命令。例如，想把Available实例从两个缩减为一个，并将一个原Available实例提升为Preferred实例，可以执行：
srvctl modify service -d racdb -s app_svc -r racdb1,racdb2,racdb3 -a racdb4
修改完成后，需要重启服务或执行srvctl relocate service来让新配置生效。查看服务配置可以使用srvctl config service -d racdb -s app_svc，输出内容会明确显示Preferred实例和Available实例列表。建议在每次修改后都执行一次该命令进行核对，避免因实例名拼写错误导致服务无法启动。
需要注意的是，Preferred和Available实例列表不能重叠，即同一个实例不能同时出现在两个列表中。此外，如果列表为空，比如没有指定Available实例，那么这个服务就没有备用节点，高可用能力会打折扣。在RAC环境中，通常会为每个服务至少配置一个Available实例，并且尽量分布在不同节点上，防止单个节点故障导致服务完全不可用。
三、故障转移与负载均衡的行为差异
当Preferred实例发生故障时，Oracle Clusterware会检测到实例不可用，然后根据服务配置启动Available实例上的服务。这个切换过程并不一定瞬时完成，因为Clusterware需要等待实例被标记为OFFLINE，并且服务进程需要在备用节点上启动。具体的切换时间受多个因素影响，包括心跳检测时间、服务启动脚本执行时间等。在生产环境中，建议配合FAN（Fast Application Notification）事件，让客户端在切换发生时快速感知并重新连接。
负载均衡方面，Preferred实例和Available实例的行为有明显差异。默认情况下，只有Preferred实例上的服务会参与负载均衡，Available实例即使服务处于ONLINE状态，也不会自动接收新的连接，除非Preferred实例全部不可用。换句话说，可用实例是“被动待命”的角色，不会主动分担Preferred实例的负载。如果希望Available实例在正常运行时也参与负载均衡，那就不应该把它配置为Available，而应该把它也加入Preferred列表。这个误区很常见，需要特别留意。
当故障发生、服务迁移到Available实例后，如果原来的Preferred实例随后恢复，服务并不会自动切回Preferred实例。Oracle不会因为Preferred实例恢复就强行把服务迁移回去，因为这可能造成二次中断。如果需要让服务回到Preferred实例，DBA可以手动执行srvctl relocate service -d racdb -s app_svc -i racdb1 -t racdb2之类的命令，或者使用srvctl stop service后再启动。这种“不自动回切”的设计可以避免频繁切换对客户端造成影响，但也要求DBA在维护窗口中有意识地恢复服务到原定位置。
如果配置了服务器端负载均衡目标LONG或SHORT，Oracle会在Preferred实例之间根据会话数或连接数来路由新的连接，但这个路由范围仍然限于Preferred实例。Available实例只是在Preferred实例全部失效时的最后保障。因此，在设计服务分布时，要清楚地区分“日常负载节点”和“备用接管节点”，不要把两者混为一谈。
四、常见误区与最佳实践建议
第一个常见误区是认为Available实例会参与日常负载分担。事实上，可用实例在正常状态下不会主动接受任何连接，它只是等待故障发生。如果你希望某个实例既能处理业务，又能作为其他服务的备用节点，可以把它配置为服务A的Preferred实例，同时作为服务B的Available实例，这样不同的服务可以形成互备关系，提高整体资源利用率。
第二个误区是Preferred实例数量越多越好。虽然把更多实例设为Preferred可以提高服务的并发处理能力，但也会带来维护复杂性和故障转移时的不可控性。比如，五个Preferred实例中有一个出现性能抖动，客户端连接可能会被路由到这个慢节点，影响整体响应。合理的做法是根据业务实际负载和节点能力来指定Preferred实例，通常不要超过节点总数的一半，其余节点作为Available备用。
第三个误区是配置完成后不做故障切换演练。很多生产环境在真正发生节点故障时才发现Available实例上的服务无法正常启动，原因可能是权限不足、监听未配置、环境变量缺失等。因此，建议定期在测试环境模拟Preferred实例宕机，观察服务是否成功漂移到Available实例，并记录切换时间。同时，检查客户端TAF配置是否生效，连接是否能在合理时间内重新建立。
一个典型的最佳实践是：为每个核心服务配置两个Preferred实例和一个Available实例，并将Available实例放在与Preferred实例不同的物理节点或故障域上。对于非核心服务，可以采用两个Preferred、两个Available的对称布局，保证任意一个节点故障时服务仍然可用。配合Oracle Clusterware的server pool和策略管理，可以进一步自动化服务的启动与迁移，减少人工干预。
Oracle RACPreferred实例Available实例修改时间：2026-09-23 05:33:49