ITPub博客

首页 > 应用开发 > IT综合 > 两条报警信息的分析(第一篇)

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

原创 IT综合 作者:jeanron100 时间:2015-09-26 22:25:52 0 删除 编辑
任何规则都是固定的,但是人是活的,很多时候把一些细节之处结合起来,还是能够发现一些潜在的问题。
早上收到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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
技术文章每天更新,阵地已转移到微信公众号端。 公众号:jianrong-notes

注册时间:2012-05-14

  • 博文量
    1498
  • 访问量
    14456137