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等待持续飙升的根因。
- 实测双节点各取4万
NEXTVAL：NOCACHE耗时2100秒，CACHE 1000仅55秒——差38倍 -
CACHE值写死在数据字典里，实例重启后未用完的号段直接丢弃（比如CACHE 100已用85，剩15，宕机后这15永远跳过） -
CACHE过大（如>50000）虽提升吞吐，但异常重启时跳号肉眼可见（100000→150000），需权衡业务容忍度
NOORDER不是可选项，是RAC序列的生存前提
ORDER在RAC中不是“让ID更整齐”，而是强制所有节点串行化到一个实例（通常是第一个启动的）分配号码。代价是每次CACHE切段都得走全局队列，v$lock里SQ类锁激增，enq: SQ - contention直接卡死瓶颈节点。
- 加了
ORDER后，gv$sequence.LAST_NUMBER在各节点几乎一致——但这不是优化，是自废武功 -
NOORDER允许各节点独立维护本地号段，跨节点协调归零，enq: SQ - contention趋近于0 -
ALTER SEQUENCE不能修改ORDER/NOORDER属性，要改必须重建序列
怎么设CACHE才既稳又快
CACHE值本质是匹配业务批量节奏：让它撑过一次典型批量操作周期，避免中途刷新。别拍脑袋，看真实并发压力。
- 每秒插入200行、每批50条 →
CACHE 200起步，覆盖1秒内全部请求 - 夜间批量导入峰值每秒5000行 →
CACHE 5000 ~ 20000更稳妥，已有客户用到CACHE 50000 - 新建序列务必一步到位：
CREATE SEQUENCE seq_id START WITH 1 INCREMENT BY 1 CACHE 200 NOORDER;
跳号不是bug，是设计权衡；堵不如疏
跳号源于RAC节点各自预取号段后异常丢弃，NOCACHE也不能100%消除（事务回滚导致的NEXTVAL丢失依然存在），且性能暴跌。
- 绝大多数业务只需唯一、单调递增、便于索引——跳号不影响主键约束、不影响查询、不影响应用逻辑
- 真依赖严格递增（极少见），应改用应用层ID生成器（如Snowflake），而非硬扛数据库机制
- 监控
DBA_SEQUENCES.CACHE_SIZE和实际跳号频率：若CACHE 50却平均每次跳200+，说明有实例频繁重启，该查OS或CRS日志了
