system表空间不足的问题分析(r6笔记第66天)

很多事情见多了也就有了麻木的感觉,报警短信就是如此,每天总能收到不少的报警短信,可能很多时候就扫一眼,如果没有严重的问题自己是不会情愿打开电脑处理的。 对于此,有些朋友说是不是阀值太低了,调高一些报警就少了,如果那样做,监控的意义也就大大不同了。很多时候硬件错误或者系统错误不是突然出现问题,而是在一些异常的情况下运行,时间长了,难免出错,打个比方,如果两个配置一模一样的系统,一个内核参数有问题,资源使用有异常,总是CPU满负荷空跑,产生了大量的IO浪费,而另外一台,就是真正的空闲,负载不高,各项指标正常,那么在时间的检验下,负载高的服务器出错的概率就要大的多,可能CPU坏掉,磁盘坏掉。这种情况其实就不是偶然而是必然了。 对于报警短信,我的理念就是既然设定了一个相对统一的阀值,那么对于OLTP和OLAP的系统都应该基本遵守这个规则,既然它报出了那么多的错误,那肯定后台在进行什么样的操作,有什么改进的地方,或者潜在的问题,目前根据我的实践,绝大多数的报警信息中,如果抓住某一条报警信息去分析,都能或多或少分析出点东西来,有些是资源使用不合理,有些是sql语句的问题,有些是历史遗留问题,有些甚至正在酝酿成为大问题。 分析了,解决了,报警短信就会少一些,这样工作量也会大大减少。如果单纯为了提高阀值而减少报警,那也是自欺欺人。 我可以举个例子来佐证。 比如一条常规的报警短信,提示表空间不足。 收到的报警短信内容如下: 监控项目: showtsps:-->TS_NAME:SYSTEM :10% Free ------------------------------------ 报警时间:2015.09.21-04:32:49

这个信息充分说明SYSTEM表空间不足了,需要扩充。 而查看表空间的使用情况,发现系统表空间确实只剩余26M了,空间使用算是非常紧张了。 Tablespace Total MB Free MB Used MB -------------------- --- - - ---- ------------ ---------- ------

SYSAUX 1,040 78 962 SYSTEM 29,530 26 29,504 TEMP 29 28 1 UNDOTBS1 3,315 3,241 74 USERS 5,963 285 5,678 对于这类问题,一般的思路就是扩充表空间,当前表空间已经试29G左右了。再扩充,这个数据文件还能再扩几个G。 但是反过来想,系统表空间怎么会消耗这么多的空间呢,就算一个库再大,数据字典的信息也多不了太多,而且还有SYSAUX的辅助,不至于那么紧张。 空间都消耗在哪儿了呢,第一个反应就是可能其他的用户创建了一些临时表,由于没有遵守规则导致表数据都放在了SYSTEM表空间里。 但是查看之后,欣慰的是不是这个问题导致的。 那么空间的消耗从哪儿来呢,一个最直接的思想就是审计日志。 在11g的库中,审计的级别默认是DB会产生不少的审计日志信息,那么这些信息主要存放在哪儿呢,就是au$里面。 这是一个基表,很多审计相关的视图,数据字典都会参考这个基表。 SEGMENT_TYPE SIZE_MB SEGMENT_NAME --------------- ---------- ------------------------------ TABLE 28785 AUD$

结果一看还确实,这个表占用了绝大多数的系统表空间。 那么处理方法似乎就很简单了。直接清理掉这个基表即可。 思路很简单,但是这是在线应用,我还是希望自己能够佐证一些,如果为了调优结果造成了系统故障就是得不偿失了。 首先查看清理aud$这个基表是否有一些bug,结果还真查到一个。Deadlock Problem On Sys.Aud$ Table. (文档 ID 1199416.1),仔细查看之后发现这个问题的版本要早一些, 问题已经在新的版本修复,所以这个问题目前不大可能出现在我目前的环境中,那么接着查看是否有一些官方的说法呢。 How to Truncate, Delete, or Purge Rows from the Audit Trail Table AUD$ (文档 ID 73408.1)

对于清理这个基表,思路还是很简单,简单的评估检查之后,最关键的还是运行truncate table au$. 查看了官方文档,自己也有底了,当然这部分审计信息需要确认为不需要的。因为目前还没有定制更多的审计级别和审计信息。

SQL> truncate table aud$; Table truncated.

这个时候再次查看空间使用情况,其实system表空间使用了总共720M,剩下的空间都得到了释放。

Tablespace Total MB Free MB Used MB -------------------- --- - - ---- ------------ ---------- ------

SYSAUX 1,040 78 962 SYSTEM 29,530 28,811 720 TEMP 29 28 1 UNDOTBS1 3,315 3,241 74 USERS 5,963 285 5,678

这样这个问题就基本修复了,至少在很长的一段时间里都不会在有类似的问题。 都说前人栽树后人乘凉,我还是不希望成为前人埋雷后人踩,毕竟这种问题摊到自己身上还是很郁闷的。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-09-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏塔奇克马敲代码

Windows平台下源码分析工具

2293
来自专栏架构之路

超清晰的makefile解释、编写与示例

Makefile范例教学 Makefile和GNU make可能是linux世界里最重要的档案跟指令了。编译一个小程式,可以用简单的command来进行编译;稍...

4098
来自专栏我是攻城师

图形数据库之Neo4j学习(一)

3775
来自专栏塔奇克马敲代码

Windows平台下源码分析工具

1753
来自专栏Cloud Native - 产品级敏捷

微服务架构 (五): 获取微服务数据, 生成报表

2016.8.17, 深圳, Ken Fang 架构师在设计从多个微服务取数据, 而生成报表的架构设计方案时, 往往面临著需在边界上下文 (Bounded Co...

20710
来自专栏java一日一条

Python爬虫爬取美剧网站

一直有爱看美剧的习惯,一方面锻炼一下英语听力,一方面打发一下时间。之前是能在视频网站上面在线看的,可是自从广电总局的限制令之后,进口的美剧英剧等貌似就不在像以前...

1592
来自专栏铭毅天下

干货 |《从Lucene到Elasticsearch全文检索实战》拆解实践

1、题记 2018年3月初,萌生了一个想法:对Elasticsearch相关的技术书籍做拆解阅读,该想法源自非计算机领域红火已久的【樊登读书会】、得到的每天听本...

2K6
来自专栏视频咖

如何写出一手好的小程序代码,从架构说起

? 作为微信小程序底层 API 维护者之一,经历了风风雨雨、各种各样的吐槽。为了让大家能更好的写一手小程序,特地梳理一篇文章介绍。如果有什么吐槽的地方,欢迎去...

4132
来自专栏Aloys的开发之路

Python第三方常用工具、库、框架等

       Python ImagingLibrary(PIL):它提供强大的图形处理的能力,并提供广泛的图形文件格式支持,该库能进行图形格式的转换、打印和显...

40210
来自专栏hbbliyong

JAVA试练塔之试炼技能图

1.计算机基础: 1.1数据机构基础: 主要学习: 1.向量,链表,栈,队列和堆,词典。熟悉 2.树,二叉搜索树。熟悉 3.图,有向图,无向图,基本概念 4.二...

3747

扫码关注云+社区