Oracle RAC集群的优势在于多实例共享计算资源，但很多DBA在实际运维中发现一个尴尬的现象：明明集群有四个节点，一条并行查询却几乎把所有并行进程都压在了一个实例上，其他节点CPU利用率不到20%。这个问题的根源通常不在并行度设置本身，而在于并行执行进程的分配机制没有配合好Service。默认情况下，并行执行会尽量在发起查询的本地实例启动并行从属进程，跨实例的并行分发需要通过Service和并行实例组来引导。
Service与并行查询的底层关系
要理解Service在并行查询中的作用，首先要弄清楚Oracle并行执行的架构。当一条SQL被判定为可并行执行时，会话所在实例成为并行协调者，它负责把工作切成多个粒度，再分配给并行从属进程处理。在单实例中，这些从属进程只能在本地启动；而在RAC环境中，从属进程可以分布到多个实例上，通过集群内部的高速互联网络交换数据，这就是跨实例并行。
控制从属进程分布范围的关键参数是PARALLEL_INSTANCE_GROUP。这个参数的值对应一个Service名，如果设置了某个Service，并行从属进程只会在运行该Service的实例上启动。举个例子，假设有一个叫DWARE的服务，它通过首选拘认只运行在节点1和节点2上，那么所有设置了该实例组的并行查询都只会使用这两个节点的资源，节点3和节点4完全不参与。这种机制一方面可以隔离数据仓库负载，另一方面也要求服务的节点分布必须和业务负载规划一致，否则就会出现前面提到的资源倾斜问题。
需要注意的是，如果不设置PARALLEL_INSTANCE_GROUP，默认行为在不同版本中略有差异，较新的版本（19c之后）已经有了基于服务名自动路由的改进，但传统版本中默认仍然是本地实例优先。这也是为什么很多老库升级后并行查询分布突然变化，DBA需要格外留意这一点。
Service的创建与并行实例组配置
配置跨实例并行查询的第一步是规划Service。假设集群有四个节点，其中节点1和节点2内存充裕、专门服务于报表统计类查询，那么可以创建一个名为dwsvc的服务，只在这两个实例上启动。使用srvctl命令操作如下：
srvctl add service -db ractest -service dwsvc -preferred ractest1,ractest2 \ -available ractest3 -clbgoal LONG srvctl start service -db ractest -service dwsvc
这里-clbgoal LONG表示长连接型负载均衡目标，适合数据仓库的长时查询会话。服务启动后，应用连接串中要指向这个Service，而不是直接连实例名，这样才能保证会话落在目标节点范围内。
第二步是设置并行实例组参数。可以在系统级别设置，也可以只针对特定会话：
-- 系统级设置，所有并行查询限定在dwsvc服务的节点上 ALTER SYSTEM SET parallel_instance_group = 'dwsvc'; -- 或者仅针对当前会话 ALTER SESSION SET parallel_instance_group = 'dwsvc'; -- 设置并行度后执行查询 ALTER SESSION FORCE PARALLEL QUERY PARALLEL 8; SELECT /*+ PARALLEL(t 8) */ count(*), channel_id FROM sales t GROUP BY channel_id;
执行后可以通过V$PX_SESSION视图验证并行从属进程的实际分布情况，重点看SADDR对应的会话是否跨越了多个实例的INST_ID。如果发现所有从属进程都在同一个实例，通常有两个原因：一是服务实际只在一个节点上运行，二是全局缓冲区的数据本地性优化把工作集中到了数据所在的节点。前者需要检查srvctl配置，后者属于正常行为，可以通过PARALLEL_DEGREE_POLICY和缓冲区命中率综合判断。
三种配置策略的对比与选型建议
围绕Service规划并行负载，常见的有三种策略。第一种是独占式，即DW专用服务只跑在部分节点，OLTP服务跑在其余节点，两类负载物理隔离互不干扰。这种方式适合报表任务时间集中、资源消耗巨大的场景，缺点是节点利用率可能不均衡，需要在业务低峰期手动或定时调整服务分布。
- 独占式：负载隔离彻底，规划简单，但硬件利用率上限受限于服务覆盖的节点数
- 全节点共享式：服务覆盖所有节点，并行从属进程可在全集群调度，吞吐量最大，但容易和OLTP争抢IO
- 分层混合式：配置两个Service，重查询走大内存节点组，轻查询走全节点组，兼顾隔离与利用率
从实践经验看，混合式策略在多数中等规模集群中表现最好。可以为重查询服务设置较高的并行度上限，配合资源管理器（Resource Manager）对并行服务器池做限制，防止某个大查询把集群拖垮。另外要提醒一点，跨实例并行的代价是私有网络流量，如果互联网络带宽只有1Gbps而并行度开到64，缓存融合很可能成为瓶颈，这种情况下的优化方向是降低跨实例并行度或者升级互联硬件，而不是一味追求全集群并行。
最后做一次整体验证时，建议用V$SERVICE_STATS结合AWR报告观察各服务的DB Time分布和并行等待事件，等待事件中如果PX qref latch或互联相关等待明显偏高，说明服务节点的数据分布与查询模式不匹配，需要重新评估哪个服务承载哪类查询。把Service、并行实例组和资源管理器三者配合起来，RAC集群的多节点算力才能真正转化为查询性能的提升。
Oracle RACService并行查询修改时间：2026-09-15 17:48:34