Library Cache Hit Ratio低于99%不必然需干预，因其仅反映软解析比例，不体现硬解析开销或争用；应结合GETHITRATIO与PINHITRATIO是否双低、Parse_Calls/Executions比值是否超0.1、以及是否出现library cache lock/pin等待综合判断。
软解析率异常不等于性能问题，关键看是否伴随 library cache lock/pin 等待或硬解析飙升
Library Cache Hit Ratio 低于 99% 时该不该干预
这个比率本身不是故障信号。Oracle 官方明确指出：Library Cache Hit Ratio 只反映 SQL 解析时能否从库缓存中直接找到执行计划，不体现硬解析开销、共享池争用或 mutex 冲突。
- 先查
V$LIBRARYCACHE的GETHITRATIO和PINHITRATIO：两者都持续低于 0.98 才值得深挖 - 若
GETHITRATIO低但PINHITRATIO高（>0.99），大概率是大量新 SQL 进入（比如绑定变量没用好），不是锁争用 - 别只盯 AWR 报告里的汇总值——它可能掩盖局部高峰；用
SELECT * FROM V$LIBRARYCACHE WHERE namespace = 'SQL AREA'查实时值更准
真正要盯的是 Parse Calls / Executions 比值和硬解析频率
软解析“多”不可怕，“新 SQL 多”才危险。核心判断依据是解析行为的构成，而非命中率数字。
- 查
V$SQLAREA：执行SELECT sql_id, parse_calls, executions, (parse_calls/executions) ratio FROM v$sqlarea WHERE executions > 100 AND parse_calls/executions > 0.1 ORDER BY ratio DESC - AWR 中重点翻 “SQL ordered by Parse Calls”，不是 “SQL ordered by Gets”——前者暴露未重用 SQL，后者只是逻辑读高
- 硬解析每秒超 100 次（
hard parse elapsed time在 Time Model Statistics 中占比突增）才是明确红灯，说明 shared_pool 不足或绑定变量缺失
Reloads 高但无等待？大概率是隐性 DDL 或 cascade invalidation
高 Reloads 本身不报错，但它常是对象失效链的末端表现，源头往往藏在依赖关系或自动任务里。
- 查最近一小时变更：
SELECT object_name, object_type, last_ddl_time FROM dba_objects WHERE last_ddl_time > SYSDATE - 1/24 ORDER BY last_ddl_time DESC - 顺藤摸瓜找依赖：
SELECT referenced_owner, referenced_name, referenced_type FROM dba_dependencies WHERE name = 'YOUR_OBJECT_NAME' - 临时禁用统计信息自动收集验证：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'auto optimizer stats collection', operation => NULL, window_name => NULL) - 确认是否有人执行过
ALTER SYSTEM FLUSH SHARED_POOL——AWR 不会记录该操作，但它必然引发大批 reloads
Shared Pool Size 加大会不会改善软解析率
盲目加大 shared_pool_size 可能适得其反。过大导致 LRU 链变长、hash bucket 查找效率下降，甚至诱发 library cache: mutex X 等争用。
- 先看
V$SHARED_POOL_ADVICE：如果 “Size Factor”=1.5 时estimated parse time saved是负数，说明当前 size 已足够 - 检查
V$SGASTAT中free memory是否长期低于 50MB；低于此值才真缺内存 - 对比相邻 AWR 快照的 shared pool 使用率曲线——突然跳升往往对应某次部署或
cursor_sharing参数变更
复杂点在于：软解析率异常常常是结果，不是原因。你看到的低命中率，背后可能是应用层绑定变量缺失、中间件连接池配置错误、或是某次未被记录的 DDL 引发的 cascade invalidation。必须结合 V$SQLAREA、V$LIBRARYCACHE 和 DBA_OBJECTS 三处动态视图交叉验证，才能避开“调参幻觉”。
