ash可直接定位高频争用sequence：先查gv$active_session_history中enq: sq - contention事件的sql_id和current_obj#，再通过dba_objects反查sequence名；重点验证cache是否≥1000且order_flag='n'，结合时间线分析争用爆发点，并检查p1=147、p2确认锁对象，改后需验证事件数降90%+及等待时间微秒级。
查ASH里哪个sequence在高频争用
enq: SQ - contention本质是多个会话抢同一个sequence的号段，ASH能直接暴露谁在抢、抢得多、抢得急。别先去翻DBA_SEQUENCES，先看实时采样数据：
- 执行：
SELECT sql_id, current_obj#, event, count(*) FROM gv$active_session_history WHERE event = 'enq: SQ - contention' AND sample_time > SYSDATE - 1/24 GROUP BY sql_id, current_obj#, event ORDER BY 3 DESC; -
current_obj#就是sequence对象编号，用它反查名字：SELECT object_name FROM dba_objects WHERE object_id = ¤t_obj#; - 如果
sql_id为空，说明是隐式调用（比如INSERT ... VALUES (seq.NEXTVAL)），重点盯current_obj#
确认CACHE和ORDER设置是否踩坑
Oracle默认建sequence时CACHE 20 NOORDER，RAC下这等于埋雷——每个实例只缓20个号，一并发就光。ASH看到争用后，立刻验证参数：
- 查当前值：
SELECT sequence_name, cache_size, order_flag FROM dba_sequences WHERE sequence_name = 'YOUR_SEQ_NAME'; CACHE 且<code>ORDER_FLAG = 'N'（即NOORDER）是安全底线；若ORDER_FLAG = 'Y'，必须改NOORDER，否则跨实例序列号强制有序会锁死DFS同步- RAC环境严禁
ORDER，哪怕业务要求“连续号”，也该用应用层生成或UUID替代
用ASH时间线定位争用爆发点
单纯看总量没用，要锁定“哪一分钟突然炸了”。ASH按秒采样，能还原时间线：
- 执行：
SELECT TRUNC(sample_time,'MI') ts, COUNT(*) waits FROM gv$active_session_history WHERE event = 'enq: SQ - contention' AND sample_time BETWEEN SYSDATE-1/48 AND SYSDATE GROUP BY TRUNC(sample_time,'MI') ORDER BY ts; - 如果某分钟wait数陡增10倍以上，立刻查那分钟的完整ASH记录：
SELECT sql_id, session_id, blocking_session, event, p1, p2 FROM gv$active_session_history WHERE event = 'enq: SQ - contention' AND sample_time BETWEEN TO_DATE('2026-10-02 14:22:00','YYYY-MM-DD HH24:MI:SS') AND TO_DATE('2026-10-02 14:23:00','YYYY-MM-DD HH24:MI:SS'); -
p1是锁类型（SQ=147），p2是sequence对象号，可交叉验证
改完CACHE后验证是否真缓解
ALTER SEQUENCE改完不是立刻生效——旧缓存号段用完才切新策略。ASH里要盯两个信号：
- 争用事件数量下降：改完后跑10分钟，再执行第一段SQL，对比
count(*)是否降90%+ - 等待时间变短：查
gv$session_event里enq: SQ - contention的time_waited_micro，应从毫秒级降到微秒级 - 注意：如果仍高，检查是否还有其他sequence未调整，或应用代码里存在循环调用
NEXTVAL（比如for loop里每次insert都取新值）
最易被忽略的是：改CACHE后不清理共享池，老执行计划可能还带着旧sequence元数据；生产环境建议在窗口期执行ALTER SYSTEM FLUSH SHARED_POOL;，但需评估对硬解析的影响。
