如何优化Oracle RAC环境下的Sequence序列争用问题

RAC下Sequence争用（enq: SQ-contention）几乎总是因CACHE太小（如默认20）且未配NOORDER；应调大CACHE（建议100–5000，依并发量定）并显式声明NOORDER，可消除跨节点DFS锁争用，使等待趋近于零。

直接结论：RAC下Sequence争用（enq: SQ - contention）几乎总是因为CACHE太小 + 没配NOORDER；调大CACHE并显式声明NOORDER，能解决95%以上的性能问题。

为什么CACHE=20在RAC里是性能雷区

Oracle默认CACHE 20，意味着每个RAC节点最多缓存20个号；高并发下几毫秒就用完，触发跨节点抢seq$表更新和DFS锁协调。这不是“偶尔慢”，而是enq: SQ - contention等待持续飙升的根因。

1. 实测双节点各取4万NEXTVAL：NOCACHE耗时2100秒，CACHE 1000仅55秒——差38倍
2. CACHE值写死在数据字典里，实例重启后未用完的号段直接丢弃（比如CACHE 100已用85，剩15，宕机后这15永远跳过）
3. CACHE过大（如>50000）虽提升吞吐，但异常重启时跳号肉眼可见（100000→150000），需权衡业务容忍度

NOORDER不是可选项，是RAC序列的生存前提

ORDER在RAC中不是“让ID更整齐”，而是强制所有节点串行化到一个实例（通常是第一个启动的）分配号码。代价是每次CACHE切段都得走全局队列，v$lock里SQ类锁激增，enq: SQ - contention直接卡死瓶颈节点。

1. 加了ORDER后，gv$sequence.LAST_NUMBER在各节点几乎一致——但这不是优化，是自废武功
2. NOORDER允许各节点独立维护本地号段，跨节点协调归零，enq: SQ - contention趋近于0
3. ALTER SEQUENCE不能修改ORDER/NOORDER属性，要改必须重建序列

怎么设CACHE才既稳又快

CACHE值本质是匹配业务批量节奏：让它撑过一次典型批量操作周期，避免中途刷新。别拍脑袋，看真实并发压力。

1. 每秒插入200行、每批50条 → CACHE 200起步，覆盖1秒内全部请求
2. 夜间批量导入峰值每秒5000行 → CACHE 5000 ~ 20000更稳妥，已有客户用到CACHE 50000
3. 新建序列务必一步到位：CREATE SEQUENCE seq_id START WITH 1 INCREMENT BY 1 CACHE 200 NOORDER;

跳号不是bug，是设计权衡；堵不如疏

跳号源于RAC节点各自预取号段后异常丢弃，NOCACHE也不能100%消除（事务回滚导致的NEXTVAL丢失依然存在），且性能暴跌。

1. 绝大多数业务只需唯一、单调递增、便于索引——跳号不影响主键约束、不影响查询、不影响应用逻辑
2. 真依赖严格递增（极少见），应改用应用层ID生成器（如Snowflake），而非硬扛数据库机制
3. 监控DBA_SEQUENCES.CACHE_SIZE和实际跳号频率：若CACHE 50却平均每次跳200+，说明有实例频繁重启，该查OS或CRS日志了