昨天接到了同事的一个电话，说有一个数据库无法访问了，希望能够让我来看看，赶紧连过去，发现错误还是一个看似很简单的ora错误。
$ sqlplus / as sysdba
Copyright (c) 1982, 2011, Oracle. All rights reserved.
ERROR:
ORA-09817: Write to audit file failed.
Linux-x86_64 Error: 28: No space left on device
Additional information: 12
ORA-01075: you are currently logged on
这种问题想必大家都或多或少碰到过，从错误日志来看还是因为审计日志写不进去了，再进一步来说，就是空间不足了。
无论怎么判断，一个df -h命令足以说明，可以看到空间确实是不够了。
Filesystem Size Used Avail Use% Mounted on
/dev/sda7 5.9G 633M 4.9G 12% /
...
/dev/sdb1 3.1T 3.0T 0 100% /data
这个时候还是有个小诀窍，数据库无法登录，那么就查看不了审计日志的地方。我们可以直接到$ORACLE_HOME/dbs下的参数文件里面来看，多多少少能发现一些相关的信息。
简单评估之后，发现有一个临时文件大概有100M可以先挪到其它的目录下，然后再次尝试tns连接就没有问题了。
问题其实在这个时候看似已经基本解决了。但是过了不到一分钟，自己再次尝试，似乎又登录不了了。再次查看，几百M的空间已经用完了。马上做了处理，问题的处理暂时告一段落。
但是我们的分析和解释才刚刚开始。
首先这个问题为什么会发生，空间问题导致的数据库无法登录还是不应该犯的错误。对于这个问题，查看前几天的空间使用情况，可以看到还剩下好几百M的空间。
按照一个阀值来参考，还是基本够用的。
那就说明数据库层面还是有一些和平常不同的地方，简单查看，得到了下面的报告。这个能够看出一个数据库的负载情况，能够看到在一个小时内redo的切换频率。
可以看到在问题发生的时间段内，redo的切换频率极高，数据库负载是在近两天才可以上升的，但是对于数据库redo切换如此频繁，是否从应用层面有一些大的变更目前还没有相关的通知，但是可以看到问题问题就是这么积累下来，结果导致近两天的redo切换极为频繁，归档一下子撑爆了磁盘空间。
关于是否应用有大的变更，还需要进一步确认，但是对于DBA来说，着实需要结合这些信息作为检查的一个基准。
目前的环境使用中dataguard还是使用比较频繁，所以在11g的环境中，有了active dataguard,数据的变更到备库还是很快的，所以对于归档的保留也就采用了一些延时。目前的归档延时删除是保留在2天，也就是删除两天之前的归档，但是可以从归档的删除情况可以看到，偏偏就是这两天内归档频率极高，最后还是把空间给占满了。简单修改一些crontab中的删除策略就可以了。
所以对于这个问题的反思如下：
归档路径还是最好在fast_recovery_area_dest下，在11g中，会有一个空间阀值，超过了80%会自动删除，详细请看之前的博文。
对于文件系统的监控，采用OEM监控还是没有zabbix那么直接，系统级的监控在zabbix中还是能够更加统一，而在gc中监控系统级的情况还是有一定的欠缺，至少没有zabbix针对性更强。
对于归档的删除，还是需要最好能够做些前瞻性的处理，比如对于归档产生较多，但是又不希望直接删除归档的情况，对归档进行定时压缩，然后定时删除过期的归档就是一个相对来说可行的方案，即节省了空间又能够保留尽可能多的归档。
最后也是最重要的，数据库级的变更和应用关系极为紧密，如果有什么大的变更或者批量处理还是能够让DBA知晓，在这种问题上DBA还是能够做到先知先觉，把问题都解决在还没发生之前。