Oracle RAC序列争用如何优化

Oracle RAC中enq: SQ-contention的根本原因是ORDER模式加小CACHE引发DFS锁争用；必须同时配置NOORDER、合理CACHE（50–500）及LMS实时调度，缺一不可。

Oracle RAC里enq: SQ - contention不是序列本身慢，是默认ORDER + 小CACHE触发跨节点DFS锁争用。必须同时改三件事：序列定义、CACHE值、LMS调度策略——少一个，高并发下照样卡。

为什么RAC中NEXTVAL会卡在enq: SQ - contention

根本不是磁盘IO或SQL解析慢，而是每个实例取完自己的CACHE号段后，必须通过全局队列（比如SVS或DFS）协调“下一个号段归谁”，这个协调走的是高开销的集群消息路径。

1. 现象：SELECT seq.NEXTVAL FROM DUAL偶发几百毫秒延迟，AWR里SQL执行时间毛刺明显
2. 等待事件集中在enq: SQ - contention或svs，v$enqueue_stat里SQ类等待飙升
3. 哪怕CACHE 20，每50次调用就要一次跨节点确认；节点越多，排队越长
4. gv$sequence能看到各实例LAST_NUMBER差几百——这不是异常，是争用正在发生的信号

CREATE SEQUENCE必须一步到位：NOORDER + CACHE 50–500

别ALTER已有序列——ALTER SEQUENCE ... CACHE 200不改变ORDER/NOORDER属性，旧序列照卡。新建序列必须直接带NOORDER。

1. NOORDER放弃全局递增保证，允许每个实例独立维护本地CACHE号段，彻底消除跨节点同步
2. CACHE设50–500：按业务QPS和批量规模算，例如每秒插入300行、每批50条，CACHE 200可撑1秒内无协调
3. 不要CACHE 10000 + ORDER：一个实例霸占整段，其他实例干等，反而放大单点压力
4. 示例：CREATE SEQUENCE s1 NOORDER CACHE 200;

LMS进程必须运行在SCHED_FIFO实时调度下

序列争用已导致GC请求排队，若LMS没跑RT模式，响应延迟会雪上加霜——重试、重复传输、CPU飙到90%+都可能。

1. 检查：ps -eo pid,comm,cls,pri,rtprio,%cpu | grep LMS，cls列必须是ff或rr（不是ts）
2. 确认_highest_priority_processes含LMS*，且/etc/security/limits.conf配了oracle soft rtprio 99
3. 改完必须kill -SIGUSR2 <lms_pid>重载调度策略，否则不生效

真正难的不是单独调某个参数，是把NOORDER、合理CACHE、LMS实时调度三者配齐——缺一不可。业务依赖严格递增编号（比如审计流水号排序）时，NOORDER就不能用，得换方案，比如应用层UUID或分段预分配。