rac中nextval响应慢的根本原因是order模式加默认cache引发dfs锁争用；应改用noorder+合理cache（50–500）并确保lms运行在rt调度模式下。
为什么rac里nextval响应变慢？
根本不是序列本身慢，而是order模式+默认cache在多节点下触发dfs锁争用。哪怕cache 20，每个号段用完都要跨节点确认“下一个值谁来分配”，等待事件会集中在enq: sq - contention或svs上。现象是select seq.nextval from dual偶尔卡顿、awr里sql执行时间毛刺明显。
RAC序列必须加NOORDER和合理CACHE
ORDER对OLTP几乎无意义——订单号、流水号只要唯一不重复即可，不要求全局严格递增。加了NOORDER后，各实例独立维护自己的CACHE号段，彻底消除跨节点同步开销。
-
CACHE设50–500：按每秒插入量估算，比如QPS 300、批量50条/次，CACHE 200可撑1秒内无协调 - 绝对不要
ALTER SEQUENCE ... CACHE N单独改CACHE：它不改变ORDER/NOORDER属性，旧序列仍卡 - 新建序列必须一步到位：
CREATE SEQUENCE s1 NOORDER CACHE 200 - 查
gv$sequence能看到各节点LAST_NUMBER差几百甚至上千——这是正常现象，不是数据错乱
IDENTITY列不能替代显式序列
想INSERT前拿到ID（比如写日志、生成关联外键）、要跨表复用编号、需CYCLE或MAXVALUE、DBA要监控调整——这些场景IDENTITY全不支持。它背后隐藏的序列不可见、不可重置、不可共享。
- 查下一个值？别试
s1.NEXTVAL，得查USER_TAB_IDENTITY_COLS.LAST_NUMBER - 批量插入要连续ID？
IDENTITY在直接路径加载（INSERT /*+ APPEND */）中行为受限，SEQUENCE更可控 -
GENERATED BY DEFAULT AS IDENTITY允许手动插值，但应用漏传字段可能意外覆盖自增逻辑
LMS进程没跑RT模式会让序列问题雪上加霜
序列争用本身已导致GC请求排队，若LMS进程没运行在SCHED_FIFO实时调度下，响应延迟进一步放大，引发重试和重复传输，CPU飙升到90%以上。
- 检查
ps -eo pid,comm,cls,pri,rtprio,%cpu | grep LMS：cls列必须是ff或rr，不是ts - 确认
_highest_priority_processes含LMS*，且/etc/security/limits.conf配了oracle soft rtprio 99 - 改完必须
kill -SIGUSR2 <lms_pid></lms_pid>重载调度策略，否则不生效
真正难的是把NOORDER、CACHE、LMS RT三者配齐——少一个，序列在RAC高并发下就稳不住。
