首页 / MYSQL / 一次AWR报告引发的自我反省
一次AWR报告引发的自我反省
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了一次AWR报告引发的自我反省，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2282字，纯文字阅读大概需要4分钟。
内容图文
AWR引发的血案昨天一早到公司，例行巡检数据库服务器，CRS正常，实例正常，ASM正常，各项服务正常，后台进程正常，RMAN备份正常，做了一个AWR报告，矮油，不对，
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点才解决，最终发现是表空间的问题，并且还重启了外网的数据库，最终我们会发现，往往问题都出现很小的地方，我们很不会留意到的地方，因此一次合理的规划很重要，这次错误感谢刘稳童鞋的技术支持和强强领导的信任与支持。
本文出自 “猫熊的幸福生活” 博客，请务必保留此出处
，香港服务器内容总结
以上是互联网集市为您收集整理的一次AWR报告引发的自我反省全部内容，希望文章能够帮你解决一次AWR报告引发的自我反省所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。