Library Cache Hit Ratio低于99%未必异常，关键看是否伴随library cache lock/pin等待；官方指出该比率仅反映软解析比例，不体现硬解析开销或共享池争用。
Library Cache Hit Ratio 低于 99% 怎么看
这个比率不是越高越好，关键得看下降是否伴随 library cache lock 或 library cache pin 等等待。oracle 官方文档明确说：单纯看 library cache hit ratio 没意义，它只反映 sql 解析时从库缓存中直接找到执行计划的比例，不反映硬解析开销或共享池争用。
实操建议：
- 先查
V$LIBRARYCACHE的GETHITRATIO和PINHITRATIO，两者都低才值得深挖 - 若
GETHITRATIO低但PINHITRATIO高，说明是大量新 SQL 进入（比如绑定变量没用好），不是锁争用 - 检查
V$SQLAREA中PARSE_CALLS/EXECUTIONS比值，>0.1 就提示硬解析频繁 - AWR 报告里重点看 “SQL ordered by Parse Calls” 而不是 “SQL ordered by Gets”
Reloads 高意味着什么
Reloads 是对象失效后重新加载进库缓存的次数，不是错误，但高 reloads 往往暴露隐性问题：比如频繁 DDL、同义词/视图依赖链过长、或者 shared_pool 不足导致对象被挤出后反复重载。
常见错误现象：
- 应用日志里出现
ORA-04062: timestamp of procedure has been changed，但没做 DDL —— 实际是依赖对象被修改触发了 cascade invalidation - AWR 中
library cache load lock等待上升，且与Reloads峰值时间吻合 -
V$LIBRARYCACHE的RELOADS列持续 >100/s，尤其在业务低峰期也高
实操建议：
- 查
DBA_OBJECTS中LAST_DDL_TIME最近 1 小时内变动的对象，再顺藤摸瓜查依赖：SELECT * FROM DBA_DEPENDENCIES WHERE REFERENCED_NAME = 'xxx' - 禁用自动统计信息收集（
DBMS_AUTO_TASK_ADMIN.DISABLE）临时验证是否由gather_table_stats触发的 cascade invalidation - 确认是否用了
ALTER SYSTEM FLUSH SHARED_POOL—— 这个命令会清空所有缓存，必然引发大批 reloads，但 AWR 不会单独标出它是原因
Shared Pool Size 设置不当的典型表现
很多人以为加大 shared_pool_size 就能压低 reloads，结果反而更糟：过大导致 LRU 链变长，查找 hash bucket 效率下降，甚至引发 library cache: mutex X 等争用。
使用场景判断：
- 如果
V$SHARED_POOL_ADVICE显示 “Size Factor”=1.5 时 estimated parse time saved 是负数，说明当前 size 已足够，加大会拖慢 - 检查
V$SGASTAT中free memory是否长期 - 对比两个相邻 AWR 快照的
shared pool使用率变化趋势，突然跳升往往对应某次部署或配置变更
参数差异注意点：
-
shared_pool_size在 12c+ 若启用了MEMORY_TARGET，会被自动覆盖，此时应调MEMORY_TARGET而非单独设 shared_pool -
cursor_sharing设为FORCE可能降低 hard parse，但会让执行计划泛化，某些场景反而增加 reloads（如绑定变量类型不匹配）
如何定位具体是哪个 SQL 或对象在反复 reload
AWR 报告本身不提供 reload 源头，必须结合 V$SQL 和 V$OBJECT_DEPENDENCY 手动关联。难点在于 reload 是后台异步发生的，时间戳对不上。
实操建议：
- 抓取高 reloads 时间段的 ASH 数据：
SELECT SQL_ID, OBJECT_NAME, EVENT FROM V$ACTIVE_SESSION_HISTORY WHERE EVENT LIKE '%library%' AND SAMPLE_TIME BETWEEN ... - 查
V$SQL中LOADS字段（不是RELOADS！），筛选LOADS > 5且EXECUTIONS > 100的 SQL —— 这些是“反复进出共享池”的嫌疑对象 - 对高频 reload 对象，运行
DBMS_UTILITY.GET_DEPENDENCY('TABLE','SCHEMA','NAME')查完整依赖树，常会发现某个底层表被频繁TRUNCATE或ANALYZE
容易被忽略的是：DBA_TRIGGERS 中状态为 DISABLED 的触发器，只要其定义体里引用了某张表，这张表 DDL 仍会触发 trigger 无效化，进而波及所有依赖它的视图和包 —— 这类 reload 不会在 DDL 日志里留下痕迹。
