两条报警信息的分析（第一篇)

任何规则都是固定的，但是人是活的，很多时候把一些细节之处结合起来，还是能够发现一些潜在的问题。

早上收到zabbix的报警，是两条看似很平常的短信。
一封邮件内容如下，这是一封报警邮件
报警内容: Free disk space is less than 20% on volume /U01
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: Free disk space on /U01 (percentage)：7.42 % 
------------------------------------ 
报警时间:2015.09.26-03:06:21
另外一封的内容如下，这是一封报警恢复邮件，证明状态已经正常了。
监控项目: Free disk space on /U01 (percentage)_50.19 %
------------------------------------
主机名称：db2_s@10.127.xxxxxx
------------------------------------
恢复时间:2015.09.26-03:07:21
从这两封邮件来看，似乎在3点左右的时间段有什么特定的操作，消耗了大量的空间，最后又恢复了正常。
查看文件系统的使用情况如下：
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda9             6.0G  681M  5.0G  12% /
tmpfs                  48G   25G   24G  51% /dev/shm
/dev/sda3             485M   36M  424M   8% /boot
/dev/sda10            151G   71G   72G  50% /U01
/dev/sda5              32G  176M   30G   1% /tmp
/dev/sda8             9.9G  1.5G  7.9G  16% /usr
/dev/sda7              15G  564M   14G   4% /var
/dev/sdb1             2.0T  846G 1008G  46% /U02
经过查看，发现这是一个备库，同时备份库也定期做一个全备以备不时之需。备份目录在/U01下面，而/U02下面是数据文件的目录。通过这些信息不知道大家能够发现什么。我们先放下看。
查看了/U01下面的空间情况，得知在3点左右的时候数据库做了一个全备，做完备份之后会清理掉两天前的备份。
全备是通过rman来做的，备份集的大小为60G左右。每天都会生成一次全备，这样备份目录下就有两天内的备份，大概是130G左右。如果按照这个公式来看。
?SQL> select (60+71)/151 from dual;
(60+71)/151
-----------
 .867549669
确实很容易触发报警阀值，这个时候要么就是默然接受这个现实，因为备份也确实需要，旧备份也确实需要删除。当然我们也可以适当的清理一些额外的空间，最后分析来分析去，发现有些冗余
日志还是可以删除的。比如这个库开了几个端口，常年下来就会有大量的登录日志。这些目前没有特别的审计还是不需要的，可以删除。
$ ll
total 16
drwxr-xr-x 13 oracle oinstall 4096 Jun  5  2013 listener_1522
drwxr-xr-x 13 oracle oinstall 4096 Jun  5  2013 listener_1523
drwxr-xr-x 13 oracle oinstall 4096 Feb 17  2014 listener_1531
drwxr-xr-x 13 oracle oinstall 4096 Jun  5  2013 listener_1532
$ cd *1531
$ du -sh ./*
402M    ./alert
176M    ./trace
但是这么下来，也只是清理近2G的空间，还是起不了太大的作用。这个时候仔细查看问价系统的使用情况发现了奇怪的地方。
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda10            151G   71G   72G  50% /U01
/dev/sdb1             2.0T  846G 1008G  46% /U02
rman备份是基于数据块，没有启用压缩，备份集才60G左右，那么这个库本身就不大，但是数据目录/U02却又近2T的空间，如果说数据文件的冗余也可以理解，而且我们一般不会给数据库给太大
的空间范围。像这个情况下，数据库使用近800多G，但是备份集才60G左右，悬殊有点太大了。
查看表空间的使用情况发现只占用了近70G，那么剩下的空间都被贪污了？
进一步分析发现，在一个目录下存在着一个很就的备份，占用了近769G的空间。
$ du -sh .
769G    .
$ ll
total 806290444
-rw-r----- 1 oracle oinstall 130758828032 Apr  3  2014 full_DB_20140402_3574
-rw-r----- 1 oracle oinstall 120367751168 Apr  3  2014 full_DB_20140402_3575
-rw-r----- 1 oracle oinstall  75769864192 Apr  3  2014 full_DB_20140402_3576
-rw-r----- 1 oracle oinstall  96318881792 Apr  3  2014 full_DB_20140402_3577
-rw-r----- 1 oracle oinstall  96617996288 Apr  4  2014 full_DB_20140402_3578
-rw-r----- 1 oracle oinstall  89356836864 Apr  4  2014 full_DB_20140402_3579
...
明白了这点之后，再次查看发现空间就大大减少了。剩余了近1.8T，真是太富有了。
Filesystem            Size  Used Avail Use% Mounted on?
/dev/sdb1             2.0T   77G  1.8T   5% /U02?
这个时候就需要简单修改一下脚本，把备份路径挪过来，这个问题就彻底解决了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1810021/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-1810021/