如何分析latch: shared pool_共享池碎片化与硬解析过高优化-Oracle-PHP中文网

shared pool latch争用高说明多个会话高频竞争同一把锁以访问shared pool内存结构，主因是硬解析暴增或未绑定变量导致hash冲突加剧、链表过长。

shared pool latch 争用高，说明什么

shared pool latch 争用高，不是“共享池太小”这么简单——它本质是多个会话在高频抢同一把锁，去访问 shared pool 中的内存结构（比如 hash bucket 链表头）。常见现象是 latch: shared pool 等待事件在 awr 或 ash 里排前几，v$latch 中该 latch 的 gets 和 misses 比值持续低于 99.5%（即 miss rate > 0.5%）。

真正触发点往往是硬解析暴增，或大量相似但未绑定变量的 SQL 反复入池，导致 shared pool 内部 hash 冲突加剧、链表过长，每次查找/插入都要竞争 latch。

不是所有硬解析都等价：SELECT * FROM t WHERE id = 1 和 SELECT * FROM t WHERE id = 2 在未绑定变量时，会被当作两条不同语句硬解析，各自生成独立 cursor，挤占 shared pool 空间并拉长 hash 链
Oracle 12c+ 默认启用 _kghdsidx_count（多子池），但若 SQL 模式高度集中（比如全走同一个 hash bucket），子池也救不了 latch 争用
注意 v$sgastat 中 free memory 是否持续低于 5MB —— 不是看总量，而是看“碎片化空闲块是否足够容纳新 cursor”，request_misses 升高才是碎片化的直接证据

怎么快速定位硬解析来源

别先翻 AWR 报告总硬解析数，那只是结果。要盯住「谁在反复硬解析」和「为什么不能重用」：

查 v$sql 中 EXECUTIONS = 1 且 PARSE_CALLS > 1 的语句（说明反复软解析失败，退化为硬解析）
重点关注 SQL_TEXT 高度相似、仅字面量不同的语句组，用 DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE 或正则提取谓词模板（如把数字/字符串替换成 ?）做聚类
检查 v$sql_shared_cursor，对疑似语句查 UNBOUND_CURSOR、EXPLAIN_PLAN_CURSOR、OPTIMIZER_MISMATCH 等列为 Y 的行——这是硬解析无法共享的根因，比如 optimizer_features_enable 设置不一致、NLS 参数漂移
应用端若用 JDBC，确认是否启用了 implicit caching 或设置了 statementCacheSize；Python cx_Oracle 则需检查是否重复调用 cursor.prepare() 而非复用已 prepare 的对象

shared_pool_size 设多大才不碎片化

没有固定公式。设大了可能让碎片更隐蔽（空闲块分散、单个不够用），设小了又频繁触发 LRU 清理和重解析。关键看实际使用模式：

观察 v$sgastat 中 free memory 的最小值，再加 20% 作为 baseline；但若发现 library cache + sql area 占比长期低于 60%，说明 pool 内存没被有效组织，优先调优而非扩容
避免盲目开大 shared_pool_size 后忽略 cursor_sharing 设置——cursor_sharing = FORCE 在 OLTP 场景可能引发隐式类型转换，反而增加 parse 失败率
Oracle 19c+ 推荐搭配 MEMORY_TARGET 或 SGA_TARGET 自动管理，但必须关掉 lock_sga，否则 shared pool 子区无法动态收缩，碎片会长期滞留
紧急缓解可用 ALTER SYSTEM FLUSH SHARED_POOL，但这是止痛药：它清空所有 cursor，下一次请求全变硬解析，可能瞬间压垮 latch —— 只在确认是某批异常 SQL 污染后才用，且配合 DBMS_SHARED_POOL.PURGE 精准清理

绑定变量没写对，照样硬解析

写了绑定变量，但没写对，等于白写。常见失效场景比想象中多：

字符串拼接中混入字面量：'WHERE status = ''' || v_status || '''' → 即使 v_status 是变量，拼出来仍是字面量 SQL，Oracle 看不到绑定点
PL/SQL 中用 EXECUTE IMMEDIATE 'SELECT ... WHERE id = ' || id → 必须改成 EXECUTE IMMEDIATE 'SELECT ... WHERE id = :id' USING id
JDBC PreparedStatement 的参数索引错位、或执行前未 setXXX（比如 setString(1, null) 但字段不允许 null，驱动可能 fallback 到字面量）
ORM 如 MyBatis 的 ${} 是字符串替换，#{} 才是绑定；Hibernate 的 @Query(nativeQuery = true) 若含拼接，同样绕过绑定

最稳的验证方式：查 v$sql 的 SQL_TEXT，如果看到具体数值（如 WHERE id = 123），而不是 :B1 或 :1，那就还没真正绑定。