19.7 rac for aix 7.1 row cache mutex 等待

最新推荐文章于 2024-01-10 15:48:33 发布

ty_tarena_pger

最新推荐文章于 2024-01-10 15:48:33 发布

阅读量1.2k

点赞数

分类专栏： Oracle 文章标签： oracle

本文链接：https://blog.csdn.net/ty_tarena_pger/article/details/122275361

版权

6 篇文章 2 订阅

订阅专栏

下午收到应用通知：杰哥，今天凌晨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，由数据库决定啥时候失效

-----------------------------------------------

本人淘宝店铺，欢迎咨询：

关注

专栏目录