AWR引发的血案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文转自bear_cat51CTO博客，原文链接：http://blog.51cto.com/bearlovecat/860733 ，如需转载请自行联系原作者