如何处理RAC数据库中表的分区与实例亲和性_数据分布与减少GC等待

RAC 中分区亲和性指通过 SERVICE+INSTANCE_AFFINITY+ 业务路由协同，使特定分区主要由固定实例服务以减少 GC 等待；仅对 RANGE/LIST/HASH 分区有效，需应用按分区键连接对应 service，否则仍触发跨实例请求。

什么是 RAC 中的分区亲和性（Partition Affinity）

rac 里表做了分区，不等于数据就自动“贴”在某个实例上；默认情况下，每个分区的数据可能被任意实例访问，gc（global cache）请求随之频繁——尤其是高并发 dml 场景下，gc buffer busy acquire 或 gc cr block busy 等等待会明显上升。

所谓“亲和性”，是指让特定分区主要由固定实例服务，减少跨实例块请求。它不是 Oracle 自动启用的功能，而是靠人为设计 + 配置实现的局部性控制。

• 只对范围（RANGE）、列表（LIST）、哈希（HASH）分区表有效，组合分区需看子分区类型
• 依赖于 SERVICE + INSTANCE AFFINITY + 分区键与业务路由逻辑协同，不是单靠 DDL 就能生效
• 12c 及以后支持 AUTO 模式（ALTER TABLE …… MODIFY PARTITION …… ONLINE SERVICE = 'xxx'），但底层仍需 service 绑定到单一实例

怎么用 SERVICE 和 INSTANCE AFFINITY 控制分区访问路径

Oracle 不提供“把分区绑定到实例”的直接语法，而是通过 service 的运行节点 + 应用连接路由来间接实现。关键在于：让某类 SQL 总是连到特定实例，且该实例恰好服务对应分区。

• 创建专用 service，并指定 INSTANCE_AFFINITY = TRUE 和 FAILOVER_TYPE = NONE（避免 failover 打乱亲和）
• 用 srvctl add service -d <code>db_name -s sales_us -r rac1 -a rac2 明确指定首选（-r）和可用（-a）实例
• 应用层必须按业务维度（如 region_code、tenant_id）选择对应 service 连接，不能全走 SERVICE_NAME = orcl 这种全局 service
• 分区键值需与 service 路由规则对齐，例如：所有 region_code = 'US' 的记录放在 P_US 分区，且只通过 sales_us service 访问

否则即使分区存在，SQL 还是可能被负载均衡到其他实例，触发远程 GC 请求。

为什么 HASH 分区 + SERVICE 亲和容易失效

HASH 分区本身是为均匀分布设计的，分区号由 MOD(HASH_VALUE(key), num_partitions) 决定，和实例无关。如果没配合应用路由，哪怕你把 P1 分区“倾向”给 rac1，只要应用连的是 rac2 并查 P1，照样产生 GC。

• 不要单独依赖 ALTER TABLE …… MODIFY PARTITION P1 ONLINE SERVICE = 'svc1' 就以为搞定——这仅影响 DDL 期间的 service 关联，不改变运行时的访问路径
• 若业务无法按分区键做连接路由（比如混合查询多个 region），亲和性收益极低，甚至因 service 切换引入额外延迟
• 19c 引入的 DBMS_PART.CONSOLIDATE 可重分布数据以匹配 service，但需停写、锁表，生产慎用

GC 等待没降？先检查这几个地方

加了 service、改了分区、应用也切了连接，GC 等待还是高——大概率卡在细节上。

• 确认 service 真正在目标实例运行：crsctl stat res -t | grep sales_us，别只看 srvctl config 配置
• 查 v$session 的 service_name 和 inst_id 是否一致，不一致说明连接没走对 service 或被 listener 转发了
• 检查是否用了绑定变量导致 cursor sharing 失效，让原本应走 sales_us 的语句被缓存进 sales_eu 实例的 shared pool
• 留意索引分区：如果本地索引没对齐分区键，或全局索引未按 service 拆分，DML 仍会触达多实例

亲和性不是开关，是端到端链路的对齐。少一个环节，GC 就照常等。