Oracle数据库如何通过AWR定位游标争用

直接查v$session_wait定位实时热点SQL：SELECT p1,p2,COUNT(*) FROM v$session_wait WHERE event='cursor: pin S' GROUP BY p1,p2 ORDER BY COUNT(*) DESC；p1为hash_value，高频p1对应高并发SQL，若同一p1对应大量不同p2，表明子游标严重分裂，需结合v$sqlarea.version_count>10及v$sql_shared_cursor.BIND_MISMATCH='Y'等确认绑定不匹配根因。

查 v$session_wait 里的 cursor: pin S 实时热点

“cursor: pin S”等待不是锁表，是多个会话在 CPU 层面争抢同一个子游标的共享 mutex，本质是 cmpxchg 原子操作排队。AWR 报告里它常藏在 “Top Events by Total Wait Time” 后几位，但实时争用往往比 AWR 汇总更剧烈。

别等 AWR 出报告，直接连库跑：

SELECT p1, p2, COUNT(*) FROM v$session_wait WHERE event = 'cursor: pin S' GROUP BY p1, p2 ORDER BY COUNT(*) DESC;

p1 是 hash_value，p2 是子游标地址低位；高频出现的 p1 就是当前最烫的 SQL。若同一 p1 对应多个 p2，说明子游标链已分裂严重。

1. 执行频次 > 100 次/秒的 p1，基本可判定为应用层绑定不稳或硬解析泛滥
2. p2 值高度离散（比如上百个不同值），说明该 SQL 的子游标数量远超正常范围（> 20 就危险）
3. Oracle 11g 中 v$session_wait.p1 和 v$sqlarea.hash_value 可直连，12c+ 请改用 sql_id 关联 v$sql

用 v$sqlarea 和 v$sql_shared_cursor 看游标分裂根因

拿到 p1（或 sql_id）后，立刻查共享池里这句 SQL 的健康度：

SELECT sql_id, sql_text, version_count, loaded_versions FROM v$sqlarea WHERE hash_value = &p1;

重点盯 version_count：超过 10 就要警觉，> 30 基本确认存在严重游标分裂。再查分裂原因：

SELECT * FROM v$sql_shared_cursor WHERE sql_id = '&sql_id' AND (reason IS NOT NULL OR unbound_cursor = 'Y');

常见真凶是这几列标 Y：

1. BIND_MISMATCH：绑定变量长度/类型未显式声明，比如 JDBC 中只用 setString(1, "abc")，没指定长度，Oracle 推断出 VARCHAR2(3) vs VARCHAR2(100)，强制生成新子游标
2. OPTIMIZER_MISMATCH：统计信息更新后未触发游标失效，或 optimizer_mode 在会话级被篡改
3. TRANSLATION_MISMATCH：SQL 文本看似相同，但空格、换行、注释位置有细微差异（尤其 ORM 自动生成语句时）

验证绑定变量是否真被复用

即使代码写了绑定变量，Oracle 也可能因隐式转换让它失效。查 v$sql_bind_capture 是最直接证据：

SELECT name, datatype_string, max_length, count(*) FROM v$sql_bind_capture WHERE sql_id = '&sql_id' GROUP BY name, datatype_string, max_length;

如果同一 name（如 :1）对应多个 datatype_string（VARCHAR2(1) / VARCHAR2(10)）或 max_length 差异大，就是绑定失控的铁证。

1. JDBC 必须用 setString(int, String, int) 显式传长度，不能依赖默认推断
2. PL/SQL 中用 DBMS_SQL.DEFINE_COLUMN 固定变量规格，避免 EXECUTE IMMEDIATE 动态拼接
3. cursor_sharing = FORCE 在 11g 中慎用——它把字面量强行替换成系统绑定变量，反而制造更多不可控子游标

为什么 AWR 的 Top SQL 列表帮不上忙

AWR 里 “SQL ordered by Parse Calls” 或 “SQL ordered by Version Count” 看似相关，但它们反映的是历史快照汇总值，无法定位正在发生的 mutex 争用。一个 SQL 可能 version_count 很高，但当前所有会话都命中了同一个子游标，实际无争用；反之，一个 version_count=2 的 SQL 若并发极高，也可能因两个子游标间频繁切换引发严重 cursor: pin S。

真正要盯的是实时 v$session_wait + v$sql_shared_cursor.reason 的组合证据链。任何脱离 reason 字段的优化（比如盲目加索引或调 shared_pool_size）都可能绕过问题本质。

最容易被忽略的是：子游标分裂后，哪怕后续所有执行都走软解析，每次执行仍需遍历整个子游标链来查找匹配项——链越长，持 mutex 时间越久，CPU 上的原子操作排队越明显。这不是内存不够的问题，是设计层面的绑定契约没守牢。