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

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