range-hash组合分区通过两层打散缓解rac下gc buffer busy acquire：先按时间切片避免索引右边界热块，再按user_id哈希分散写入；但要求range键单调递增、hash键高基数、子分区数为2的幂，且需合理设置边界粒度。
oracle 11g 的组合分区（如 range-hash）本身不能直接“消除”热点块竞争，但它能通过两层数据打散机制，把原本集中在单一分区/单个索引叶块的写入压力，分摊到多个物理段上——前提是范围键和哈希键都选得对、分区数设得准。
为什么 RANGE-HASH 能缓解 RAC 下的 gc buffer busy acquire？
高并发写入时出现 gc buffer busy acquire，本质是多个实例反复争抢同一数据块（比如按时间递增的 create_time 写入导致的索引右边界热块）。RANGE-HASH 把这个问题拆成两步解决：
- 第一层（RANGE）按时间切片，避免全表索引叶块集中增长；
- 第二层（HASH）在每个时间分区内再按业务主键（如
user_id）哈希打散，让同一批时间窗口内的写入落到不同子分区，从而分散 buffer cache 和 undo 段争用。
注意：如果范围键选的是单调递增序列（如 seq.nextval），那第一层就失效了——所有新数据仍挤在最新一个 range 分区里，HASH 层再怎么分也救不回来。
建表时 RANGE-HASH 的语法与关键约束
Oracle 11g 支持 PARTITION BY RANGE (range_col) SUBPARTITION BY HASH (hash_col)，但必须满足三个硬性条件：
-
SUBPARTITIONS数量必须是 2 的幂（如SUBPARTITIONS 8），否则哈希分布严重倾斜——底层用hash_value & (n-1)定位子分区，非 2 的幂会丢失高位信息； - 范围分区键（
range_col）必须有明确、可预测的边界，不能是表达式或函数（如TRUNC(create_time)不合法，需先建虚拟列）； - 哈希子分区键（
hash_col）必须高基数且唯一性强，禁用status、is_valid这类低基数列，否则所有数据扎堆进前几个子分区。
示例（正确）：
CREATE TABLE order_events ( event_id NUMBER, user_id NUMBER, create_time DATE, payload CLOB ) PARTITION BY RANGE (create_time) SUBPARTITION BY HASH (user_id) SUBPARTITIONS 8 ( PARTITION p_202604 VALUES LESS THAN (DATE '2026-05-01'), PARTITION p_202605 VALUES LESS THAN (DATE '2026-06-01'), PARTITION p_max VALUES LESS THAN (MAXVALUE) );
已有范围分区表如何升级为 RANGE-HASH？
Oracle 11g 不支持在线将普通范围分区表直接转为组合分区。必须重建，但可避开停机全量导出导入：
- 用
DBMS_REDEFINITION.START_REDEF_TABLE启动在线重定义：先建新表（带SUBPARTITION BY HASH），再映射原表数据；期间原表可读写，只在最后切换瞬间锁表； - 若允许短停机，更推荐
CREATE TABLE AS SELECT+RENAME+ 重建索引/约束，比重定义更可控； - 切勿尝试
ALTER TABLE ... ADD SUBPARTITION—— Oracle 11g 明确不支持该语法，执行报错ORA-14006: invalid SUBPARTITION name。
子分区数量设 4、8 还是 16？看写入吞吐与 key 基数
没有通用最优值，但有明确取舍逻辑：
- 写入峰值每秒超 5000 行，且
user_id基数 > 100 万 → 优先SUBPARTITIONS 16，进一步降低单个子分区的 buffer cache 争用概率； - 若
user_id实际只有几万唯一值，设 16 会导致大量子分区为空，浪费空间和管理开销，此时SUBPARTITIONS 8更稳； - 所有子分区必须落在不同表空间（尤其 RAC 环境），避免 I/O 层面的磁盘争用——这点常被忽略，但直接影响
gc cr grant 2-way等等待事件。
真正容易被忽略的不是语法或参数，而是：范围分区边界的粒度要匹配业务写入节奏。比如按天分区却每小时涌入百万订单，最新分区仍会成为瓶颈；这时就得切到按小时，再配合 HASH 子分区，才能把压力真正摊薄。
