最近接收一个系统，上线运维一年余。交接时候，业务部门反映曾经出现磁盘空间占满故障。当时引起整个系统瘫痪，最后联系开发商介
应用系统生命周期是一个整体，除了最开始的需求调研、开发测试和上线，更长的时期是在运维方面。应用系统的价值体现也就是在运维阶段，一个经常报错故障的系统运维环境，是很难获得良好的用户体验的。
在实践中，软件开发商和运维方面如果没有完善的沟通交流，新系统是不容易融入原有的运维体系中的，更有甚者会引起很多其他故障。本篇就介绍一个由于备份策略冲突引起的磁盘空间故障。
1、环境介绍和故障
笔者最近接收一个系统，上线运维一年余。交接时候，业务部门反映曾经出现磁盘空间占满故障。当时引起整个系统瘫痪，最后联系开发商介入才解决问题。但是当时反馈也没有彻底解决，只能定时找开发商进行处理。
由于资料信息渠道有限，笔者只能实地观察分析。数据库服务器版本为红帽linux 6.2，数据库版本为11.2.0.3。
[root@db ~]# cat /etc/redhat-release
red hat enterprise linux server release 6.1 (santiago)
sql> select * from v$version;
banner
---------------------------------------------
oracle database 11g enterprise edition release 11.2.0.3.0 - 64bit production
pl/sql release 11.2.0.3.0 - production
core 11.2.0.3.0 production
tns for linux: version 11.2.0.3.0 - production
nlsrtl version 11.2.0.3.0 - production
故障是从磁盘空间相关的，所以当前磁盘状态df如下。
[root@db ~]# df -h
filesystem size used avail use% mounted on
/dev/sda3 59g 8.4g 48g 15% /
tmpfs 3.9g 288k 3.9g 1% /dev/shm
/dev/sda2 194m 41m 143m 23% /boot
/dev/sda1 200m 256k 200m 1% /boot/efi
/dev/sda8 1.4t 351g 976g 27% /data
/dev/sda4 59g 23g 34g 40% /home
/dev/sda5 59g 180m 56g 1% /tmp
/dev/sda6 59g 5.9g 50g 11% /var
系统空间分布比较典型，资源相对来说是比较富裕的。最大容量分区/data目录将近1.4t数据量，使用了351g。从oracle用户环境变量上，数据库软件是安装在/home文件夹下，而数据文件是在/data里面。
[oracle@db]/home/oracle>env | grep ora
oracle_base=/home/oracle/app
oracle_home=/home/oracle/app/product/11.2.0/db_1
oracle_owner=oracle
oracle_sid=db
业务系统数据shema数据量极小，只有77m。根据业务分析，系统的业务数据只保存在数据库中，而且没有删除的机制。这种情况下，由于业务数据突然膨胀引发的磁盘空间爆满的机率是很低的。
分析重点在于，/data中超过300g的空间消耗是如何出现的？
2、问题分析
进入/data目录，我们发现应用程序在这个目录中进行rman备份。
[root@db rman]# pwd
/data/db/rman
[root@db rman]# ls -l
total 1312
drwxr-xr-x. 2 oracle oinstall 409600 mar 7 01:02 bak
-rw-r--r--. 1 oracle oinstall 0 aug 21 2013 get
drwxr-xr-x. 2 oracle oinstall 921600 mar 7 01:01 logs
-rwxr-x---. 1 oracle oinstall 1037 jul 1 2013 rman_full.sh
显然，，/data/db/rman目录是应用系统内部的备份机制。目前很多系统都有自带的数据库备份模块，从现在看，系统是计划使用rman程序进行备份。
目录中的rman_full.sh脚本是主要执行脚本。
[root@db rman]# cat rman_full.sh
#!/bin/ksh
#set env
（篇幅原因，有省略……）
$bin/rman log $backup_log/$target_sid.full.$date_3.log
connect target /
run{
allocate channel c1 type disk ;
allocate channel c2 type disk ;
backup full database format '$backup_path/${date_2}_full_%d_%s_%p_%u.bak'
tag='full' include current controlfile;
sql 'alter system archive log current';
backup archivelog all format '$backup_path/${date_2}_archivelog_%d_%s_%p_%u.bak';
delete noprompt expired backupset of archivelog all ;
release channel c1 ;
release channel c2 ;
}
crosscheck backup;
delete noprompt expired backup;
delete noprompt obsolete;
exit;
eof
从公允的角度看，这个脚本是看不出什么问题的。设置环境变量、目录位置、对数据库和归档文件进行备份。之后进行crosscheck检查expired backup信息，最后依据obsolete retention原则将过期日志进行删除。
目录结构中的bak是存放备份集合的地方（虽然控制文件还是遗留在$oracle_home/dbs中），logs目录为文本日志。进入bak目录之后，检查备份情况。
[root@db bak]# ls | more
20130719_archivelog_db_109189_1_k5of3j4s.bak
20130719_archivelog_db_109190_1_k6of3j4t.bak
20130719_full_db_109180_1_jsof3j1b.bak
20130719_full_db_109186_1_k2of3j4d.bak
20130720_archivelog_db_109258_1_maof64d1.bak
20130720_archivelog_db_109259_1_mbof64d2.bak
20130720_full_pdb_109255_1_m7of64cn.bak
（篇幅原因，有省略）
20140307_full_db_115107_1_d3p2ho2g.bak
20140307_full_db_115108_1_d4p2ho2g.bak
20140307_full_db_115109_1_d5p2ho47.bak
201401171422.dmp
full_20130720.tar.gz
rm
注意：备份片中的时间日期是在其中的，从2013年7月开始，一直备份集合就存在。数据总量是300g。
[root@db bak]# du -h
301g .
这个显然是有问题，在rman备份脚本中，有明确的delete obsolete语句，将不需要的备份集合删除。确定obsolete的规则是可以从show all中看到。
rman> show all;
rman configuration parameters for database with db_unique_name db are:
configure retention policy to recovery window of 7 days;
configure backup optimization off; # default
configure default device type to disk; # default
configure controlfile autobackup on;