Row Cache与Shared Pool问题常被忽视，实则会引发解析链雪崩；dc_*缓存命中率
awr报告里“row cache”和“shared pool”相关指标没人点，不是因为不重要，而是很多人根本没意识到它们正在悄悄拖垮系统——尤其是当dc_*缓存命中率跌破95%、library cache reloads突增、或shared pool free memory长期低于50mb时，数据库已经在用硬解析、递归sql和频繁内存分配来“硬扛”业务压力了。
Row Cache低命中率：不只是字典查询慢，是整个解析链在雪崩
Row Cache（数据字典缓存）命中率低，表面看是dc_users、dc_objects这类dc_*项缓存未命中多，但真实影响远不止“查用户/对象慢”。每次未命中都会触发一次递归SQL访问obj$、user$等基表，而这些递归SQL本身又要走library cache、row cache、buffer cache三重路径。一旦并发上来，就形成“查字典→触发递归SQL→递归SQL再查字典”的循环放大效应。
- 检查方法：在AWR报告的“Instance Efficiency Percentages”页，盯住
Row Cache Hit %；若低于95%，立刻跳转到“Row Cache Activity”明细表，重点关注GETS与MISSES比值高的dc_*项（如dc_segments、dc_constraints） - 常见诱因：
SHARED_POOL_SIZE过小导致dc_*条目被挤出；大量DDL操作（如频繁建临时表、物化视图刷新）持续刷脏缓存；19c中启用ENABLE_DDL_LOGGING=TRUE且日志表未分区，导致dc_logstdby类缓存反复失效 - 不要直接调大
shared_pool_size：先确认是否真缺内存——查v$sgastat中row cache占用是否稳定在几MB内；若free memory充足但命中率仍低，问题大概率在应用层（如动态拼接CREATE TABLE t_||sysdate）
Shared Pool碎片化：Free Memory高≠健康，要看Chunk分布
AWR报告里Shared Pool Free %显示80%，你以为很宽裕？错。19c中shared_pool的内存管理已转向Automatic Shared Memory Management (ASMM)，但底层仍是chunk链表。真正致命的是“大块空闲内存找不到”，即v$sgastat里free memory总量高，但v$shared_pool_advice建议的shared_pool_size却比当前值还大——这说明内存被切成无数的碎块，无法满足新SQL的parse heap需求。
- 验证碎片：运行
SELECT * FROM v$sgastat WHERE name = 'free memory' AND pool = 'shared pool'，再对比SELECT bytes, count(*) FROM v$sgastat WHERE pool = 'shared pool' GROUP BY bytes ORDER BY bytes DESC，若出现大量4096、8192字节的free memory记录，就是典型碎片 - 根因常被忽略：游标未绑定（
WHERE id = 123vsWHERE id = 456生成不同child cursor）、PL/SQL匿名块未使用CREATE OR REPLACE PROCEDURE固化、19c中optimizer_adaptive_plans开启后plan变更频繁触发cursor invalidation - 临时缓解：执行
ALTER SYSTEM FLUSH SHARED_POOL能清掉碎片，但只是止痛药；长期解法是收缩cursor_sharing范围（设为FORCE而非SIMILAR），并强制应用层改用绑定变量
为什么ADDM建议“Increase shared_pool_size”不能照单全收
19c AWR报告里ADDM在“Memory Statistics”页给出Consider increasing shared_pool_size，Impact值标着1.2分钟——这个数字只代表“如果扩容后所有未命中都消失，理论上能省1.2分钟DB Time”，但它完全没告诉你：这1.2分钟是不是由1000次dc_objects未命中贡献的？而其中900次来自同一个硬编码的SELECT * FROM emp WHERE deptno = 10语句？
- 必须交叉验证：回到“SQL Statistics”页，按
Parse Calls排序，找出Executions低但Parse Calls极高的SQL；再点进详情，看SQL Profile是否为空、Child Cursors数是否>50——这才是真正的碎片源头 - 注意19c特有陷阱：启用
INMEMORY后，inmemory area从shared pool切走固定内存，但ADDM分析时可能仍按旧模型估算，导致建议失真；需手动检查v$inmemory_area确认实际占用 - 更准的判断依据：看
v$librarycache中RELOADS与PINS比值，若>0.01，说明即使shared_pool_size够大，也存在无效cursor争抢资源；此时优先清理INVALID状态的cursor（SELECT sql_id FROM v$sql WHERE status = 'INVALID'）
Row Cache和Shared Pool的问题从来不是孤立存在的——dc_segments未命中会触发segment-level递归SQL，这些SQL又需要library cache空间来缓存执行计划，而计划缓存失败又迫使数据库反复硬解析，进一步加剧row cache压力。所以别只盯着一个百分比，得把AWR里“Row Cache Activity”、“Library Cache Activity”、“SQL Statistics”三页的数据像齿轮一样咬合着看。
