AWR引发的血案

昨天一早到公司,例行巡检数据库服务器,CRS正常,实例正常,ASM正常,各项服务正常,后台进程正常,RMAN备份正常,做了一个AWR报告,矮油,不对,怎么snap_id只显示到5点就没再有了呢,算了,先不管他,忙东忙西的也没在意。

下午快下班的时候,测试部要测试数据库压力情况,希望抓一个15点到18点的报告,OK,easy,看熊熊来搞定,到了数据库里执行命令

clip_image001

一路走下去,唉,不对,为啥还是只有5点之前的snap_id,这时候冷汗已经下来了。

clip_image002

执行AWR的运行周期看了一下,没问题啊,使用的是默认配置的,每小时抓取一次,保留七天数据,没错啊,那是为啥呢? 诡异了。

clip_image003

为了搞定,手工生成了一下快照试了一下,卡住了,一直半个多小时都没反应(其实这时候熊熊应该找到问题所在了,但是由于着急回家就忽略了)

clip_image005

到家以后,从远程连接到数据,查找了一下最大的snap_id,发现一直处在凌晨5点那个snap_id就没更改过

又做了一次报告,按最长7天收集,发现只有100条snap_id,不算多啊,可是为什么呢?

clip_image007

想运行删除命令删除一些快照,却发现卡住不动了,我靠,XXD,不会让我删都删不了吧。

clip_image008

执行了一下后台进程查看,mmon和mmnl进程都正常使用ing啊,没有问题啊,见鬼了。

clip_image010

这时候忽然想到了,是不是空间不够了,使用命令查看了一下,确实,SYSAUX表空间使用率达到了92%左右,这是一个很尴尬的值,既不到自动扩展的时候,也因为预留的10%政策导致无法再写入数据(AWR报告的快照信息都写在这个表空间里),于是对这个表空间进行了一些简单的收缩工作,可是还是不行,TMD,真奇怪了。

clip_image012

通过上图命令可以查到表空间是否可以自动扩展。

继续执行快照删除命令,还是死在那里,XX,怎么会这样,忽然想起,还有一个该死的表空间忘记了,临时表空间。

clip_image014

查询临时表空间,4个临时表空间都满了(当初设置的太小),我晕死,问题就在这里了,删除了原有的临时表空间,并重建了新的临时表空间,同时为一些空间较小的表空间增加了数据文件,重启数据库后,该死的AWR终于又正常运作了。

clip_image016

正常登录以后,更改了AWR的收集阀值

clip_image018

重新查询,时间间隔已经为2小时一次,收集依然是保留7天,至此,AWR问题全部解决。

这个问题,从9点折腾到11点才解决,最终发现是表空间的问题,并且还重启了外网的数据库,最终我们会发现,往往问题都出现很小的地方,我们很不会留意到的地方,因此一次合理的规划很重要,这次错误感谢刘稳童鞋的技术支持和强强领导的信任与支持。