“enq: sq - contention”在awr中不显眼却很致命，因oracle默认将其归入“other”类等待事件，仅在“wait events statistics”子节可见；漏看易误判为cpu或i/o问题，实际反映高并发序列争用。
为什么“enq: sq - contention”在awr里不显眼却很致命
因为oracle默认把序列号（sequence）争用归入“other”类等待事件，不会出现在top 5 timed events里；它只在ash或v$session_wait中高频出现，awr报告里得手动翻到“wait events statistics”子节才能看到。一旦漏掉，就可能把高并发下的响应延迟误判为cpu或i/o问题。
怎么在AWR报告里定位序列争用
打开AWR报告后，直接搜索enq: SQ - contention（注意空格和连字符）。它通常藏在以下两个位置：
- “Wait Events Statistics”表格中：看Total Waits是否显著高于正常时段（比如从每小时几百次跳到几万次）；Avg Wait(ms)若超过1–2ms，说明争用已开始影响响应
- “SQL Statistics → SQL ordered by Parse Calls”里：如果某条
SELECT seq_name.NEXTVAL FROM DUAL语句Parse Calls/Executions ≈ 1，且Executions极高，大概率是应用没缓存序列值，每次都在硬解析+争用
序列争用的典型表现和误判点
常见现象不是“慢”，而是“抖动”——TPS忽高忽低、平均响应时间拉长但P95/P99尖刺明显。容易踩的坑包括：
- 看到
DB CPU占比高，就去优化SQL，其实CPU是在spin等待mutex（latch: row cache objects常同步升高） - 发现Buffer Hit Ratio下降，就加
db_cache_size，实际是序列cache耗尽后频繁访问seq$基表引发逻辑读飙升 - 对比升级前后AWR时，忽略
enq: SQ - contention的%Diff：它可能从0.1%升到1.8%，看似不大，但绝对等待次数翻了20倍
快速验证和缓解动作
不用等下次AWR生成，立刻执行以下检查：
- 查当前争用强度：
SELECT event, total_waits, time_waited_micro/1000 wait_ms FROM v$system_event WHERE event = 'enq: SQ - contention'; - 查热点序列：
SELECT object_name, subobject_name FROM dba_hist_active_sess_history WHERE event = 'enq: SQ - contention' AND sample_time > SYSDATE-1/24 GROUP BY object_name, subobject_name ORDER BY COUNT(*) DESC; - 立刻生效的缓解：对高并发序列执行
ALTER SEQUENCE seq_name CACHE 1000 NOORDER;（注意NOORDER可避免RAC节点间同步开销）
真正难处理的不是争用本身，而是应用层把序列当唯一ID生成器、又没做批量预取——这种设计问题AWR只能暴露，不能修复。
