应用系统生命周期是一个整体，除了最开始的需求调研、开发测试和上线，更长的时期是在运维方面。应用系统的价值体现也就是在运维阶段，一个经常报错故障的系统运维环境，是很难获得良好的用户体验的。
在实践中，软件开发商和运维方面如果没有完善的沟通交流，新系统是不容易融入原有的运维体系中的，更有甚者会引起很多其他故障。本篇就介绍一个由于备份策略冲突引起的磁盘空间故障。
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;
留存窗口策略是7天。现实bak目录中的内容显然是超过了这个范围。长期的备份留存会让bak占有的空间越来越多，这样即使/data目录有1.4T这么大的空间，也会被撑满的。
那么，确认到撑满的原因之后，就需要确认Oracle在执行应用程序RMAN脚本时候，为什么没有成功删除备份。寻找logs目录中每天的日志信息，可以找到答案。
[root@DB logs]# tail -n 20 db.full.20140307010102.log
Backup Piece 73678 27-FEB-14 c-1778314713-20140227-02
Backup Set 73679 27-FEB-14
Backup Piece 73679 27-FEB-14 a5p1mv7i_1_1
Backup Set 73680 27-FEB-14
Backup Piece 73680 27-FEB-14 a6p1mv8m_1_1
Backup Set 73681 27-FEB-14
Backup Piece 73681 27-FEB-14 c-1778314713-20140227-03
Backup Set 73684 28-FEB-14
Backup Piece 73684 28-FEB-14 /data/awpdb/rman/bak/20140228_full_PDB_115018_1_aap1ncc6.bak
Backup Set 73685 28-FEB-14
Backup Piece 73685 28-FEB-14 /home/oracle/app/product/11.2.0/db_1/dbs/c-1778314713-20140228-00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 03/07/2014 01:02:57
RMAN-06091: no channel allocated for maintenance (of an appropriate type)
在删除obsolete的时候出现问题，RMAN-06091表示分配channel出现了问题。于是，问题原因思路就出现了：根源在于删除obsolete的时候报错，长期以来脚本不能成功删除过期备份，最后备份文件撑满文件系统。
那么，究竟是为什么出现这个问题呢？
3、故障结果
经过沟通，笔者了解到系统上线之后，被纳入到公司整体的集中备份平台上。笔者其他手头系统也被纳入过其中，备份平台支持Oracle、SQL Server等多种主流数据库产品。对Oracle则是使用RMAN脚本进行操作，将备份数据存放在磁带介质上。
RMAN的备份数据是可以在磁盘和磁带双重介质上的。但是信息是作为一个整体存放在控制文件中的。那么一个猜想是：如果是进行obsolete，磁带和磁盘是相同的处理。Delete obsolete过程就需要尝试删除磁盘和磁带两个介质的备份。
问题是：RMAN脚本环境允许访问磁带吗？从脚本上，RMAN只是考虑了磁盘disk下的备份channel，而没有考虑到MML访问磁带。相信这也就是删除obsolete的原因。
访问RMAN，可以确定的确是DISK和SBT_TAPE混合的备份集合。
73768 B 1 A SBT_TAPE 06-MAR-14 1 1 NO TAG20140306T210708
73769 B F A SBT_TAPE 06-MAR-14 1 1 NO TAG20140306T211448
73770 B A A SBT_TAPE 06-MAR-14 1 1 NO TAG20140306T211508
73771 B F A SBT_TAPE 06-MAR-14 1 1 NO TAG20140306T211543
73772 B F A SBT_TAPE 06-MAR-14 1 1 NO TAG20140306T211547
73773 B F A DISK 07-MAR-14 1 1 NO FULL
73774 B F A DISK 07-MAR-14 1 1 NO FULL
73775 B F A DISK 07-MAR-14 1 1 NO FULL
73776 B F A DISK 07-MAR-14 1 1 NO TAG20140307T010201
73777 B A A DISK 07-MAR-14 1 1 NO TAG20140307T010203
73778 B A A DISK 07-MAR-14 1 1 NO TAG20140307T010203
73779 B F A DISK 07-MAR-14 1 1 NO TAG20140307T010204
备份集合信息如下：
RMAN> list backupset 73779
2> ;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
73779 Full 29.02M DISK 00:00:00 07-MAR-14
BP Key: 73779 Status: AVAILABLE Compressed: NO Tag: TAG20140307T010204
Piece Name: /home/oracle/app/product/11.2.0/db_1/dbs/c-1778314713-20140307-01
Control File Included: Ckp SCN: 32563623 Ckp time: 07-MAR-14
SPFILE Included: Modification time: 08-FEB-14
SPFILE db_unique_name: DB
RMAN> list backupset 73772;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
73772 Full 29.25M SBT_TAPE 00:00:03 06-MAR-14
BP Key: 73772 Status: AVAILABLE Compressed: NO Tag: TAG20140306T211547
Handle: c-1778314713-20140306-03 Media: 000031L5
Control File Included: Ckp SCN: 32544751 Ckp time: 06-MAR-14
SPFILE Included: Modification time: 08-FEB-14
SPFILE db_unique_name: DB
解决方法有如下几个：
ü 最简单的方法，如果确定要连带删除磁带上的备份，就需要额外分配加载MML驱动的channel；
ü 考虑到集中备份环境的特殊性。从应用程序角度反删除磁带备份是不合适的，有反客为主之意。所以RMAN备份脚本删除obsolete过程要求制定device type disk。语句为：delete noprompt obsolete device type disk；
查找MOS之后，发现Oracle对于RMAN的错误06091有专门的讨论，结果和笔者分析相同，文章号：ID 567555.1。推荐的解决策略也是上面两条。
4、“棋在局外”
两种策略都可以解决问题，删除当前冗余的备份集合文件。但是笔者觉得，一种更好的策略是“协调”。作为公司应用系统组成，运维机构已经对数据库采用了磁带备份策略，而且是RMAN策略。应用系统再采用RMAN策略，而且备份相同的内容，意义其实不是很大。
补充备份的重要性在于万一集中备份环境数据出现问题，能够一定程度上减少数据损失。而且应用系统数据丢失一天左右是可以接受的，完全可以人为后期补充。所以相对做一个额外的RMAN补充备份，采用数据泵每天作业抽取Schema数据也许是更好的选择。
这个案例还告诉我们一个教训，就是开发运维绝对不能分家。系统设计、开发测试和上线过程，系统开发和运维方一定要充分接触沟通，对系统整体进行测试实验。尽早的发现各种问题，形成成熟的解决方案，才能更好的做到系统平稳运行。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/17203031/viewspace-1128769/ ，如需转载，请注明出处，否则将追究法律责任。
