Shared Pool碎片化不能靠Free Memory百分比判断，AWR中显示80% free memory不等于健康，可能全是小碎块（如4096/8192字节），导致parse heap分配失败、游标频繁老化重载；需结合v$sgastat中free memory chunk分布及SQL ordered by Parse Calls中PARSE_CALLS > EXECUTIONS且EXECUTIONS = 1的语句定位未绑定变量引发的硬解析暴增，并注意与Row Cache低命中率并发诊断。
Shared Pool碎片化不能靠Free Memory百分比判断，AWR里看到80% free不等于健康——它可能全是
看v$sgastat里free memory的字节分布，不是总量
AWR报告里的“Shared Pool Free %”是障眼法。真正要查的是v$sgastat中free memory的实际chunk大小分布：
- 运行
SELECT bytes, COUNT(*) FROM v$sgastat WHERE pool = 'shared pool' AND name = 'free memory' GROUP BY bytes ORDER BY bytes - 如果大量出现
4096、8192、16384这类小尺寸记录，就是典型碎片——新SQL parse heap需要≥64KB，但找不到连续空闲块 - 同时查
SELECT * FROM v$sgastat WHERE pool = 'shared pool' AND name = 'free memory'，确认总free量是否真低（shared_pool_size反而恶化问题
盯住request_misses和reload率，不是gets/misses比值
很多人查v$latch中latch: shared pool的misses/gets，但这个比值滞后且掩盖本质。更直接的碎片证据是内存分配失败：
-
request_misses来自v$sgastat，代表因找不到足够大空闲chunk而被迫触发LRU清理的次数；该值持续升高（尤其伴随硬解析上涨），就是碎片在咬人 -
library cache reloads在AWR的“Instance Efficiency Percentages”页，若>1%，说明游标频繁老化重载，背后常是碎片导致空间不足 - 别只看
shared pool latch等待时间占比——等不到latch只是表象，根源是parse heap分配失败后反复重试
用AWR中SQL ordered by Parse Calls交叉验证硬解析模式
碎片化往往由硬解析暴增触发，而硬解析暴增又多源于未绑定变量。AWR里不能只扫总硬解析数，得定位“谁在反复造新cursor”：
- 打开AWR报告的“SQL ordered by Parse Calls”，找
PARSE_CALLS > EXECUTIONS且EXECUTIONS = 1的SQL——说明每次执行都重新硬解析，无法重用 - 对这些SQL做文本聚类：用正则把数字/字符串替换成
?，比如WHERE id = 123→WHERE id = ?；同一模板下SQL数量越多，越说明应用拼接SQL - 结合
v$sql_shared_cursor查具体原因：对SQL_ID执行SELECT * FROM v$sql_shared_cursor WHERE sql_id = 'xxx' AND UNBOUND_CURSOR = 'Y'，确认是否因未绑定变量导致无法共享
碎片化诊断最易被忽略的一点：它常和Row Cache问题并发。如果dc_objects或dc_segments缓存命中率
