下午收到应用通知：杰哥，今天凌晨4到到5点，原来几分钟的任务跑了一个小时还没跑完，帮忙查下原因。
赶紧登录数据库主机，搜问题时间段的awr：
直接跳转到TOP 10
row cache mutex 是字典缓冲区中的某个对象等待
再看看sql 执行时间最长的几个：
dbms_scheduler 类型的sql引起了注意，这个是数据库的统计信息执行sql
这几个等待时间都和shared pool有关系。去查看解析情况：
硬解析很厉害，正确情况下硬解析每秒30次左右属于正常
查看数据字段缓冲区状态信息：
directiorary cache state：
看可以以下几个过高：
dc_histogram_data/defs: 申请获取直方图缓存（过高原因1、硬解析多 2、业务表中过多使用直方图信息，可以删除无用的直方图 3、手工做直方图统计）
dc_users:申请获取用户缓存（错误密码频繁连接、批量用户赋权、bug）
dc_objects:申请获取对象缓存（硬解析过高、手工编译对象、失效对象自动编译等等）
通过Active Session History (ASH) Report看能否发现蛛丝马迹：
这里row cache mutex 里的p1对应的对象可以通过以下命令查看：
select * from v$rowcache where cache# in (16,10);
和上面也能对应上。
sql area miss 96%,怪不得这么多硬解析
综上所述，我猜测根本原因是： SQL 的cursor失效导致命中不了SQL AREA，所以造成了大量的硬解析。游标失效的根本原因是每天凌晨4点有个统计分析的job
收集表统计信息后，cursor就会失效，执行计划会重新生成，就会造成硬解析。
扩展：搜集统计信息时有个参数决定游标是否立即失效-no_invalidate.数据库采集默认是auto，由数据库决定啥时候失效
-----------------------------------------------
淘宝店铺，欢迎咨询：
首页-oracle数据库专家-淘宝网
