ITPub博客

首页 > 数据库 > Oracle > 由于不同备份策略不兼容引起的磁盘空间故障一例

由于不同备份策略不兼容引起的磁盘空间故障一例

原创 Oracle 作者:realkid4 时间:2014-03-24 23:30:09 0 删除 编辑

 

应用系统生命周期是一个整体,除了最开始的需求调研、开发测试和上线,更长的时期是在运维方面。应用系统的价值体现也就是在运维阶段,一个经常报错故障的系统运维环境,是很难获得良好的用户体验的。

在实践中,软件开发商和运维方面如果没有完善的沟通交流,新系统是不容易融入原有的运维体系中的,更有甚者会引起很多其他故障。本篇就介绍一个由于备份策略冲突引起的磁盘空间故障。

 

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

 

注意:备份片中的时间日期是在其中的,从20137月开始,一直备份集合就存在。数据总量是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、故障结果

 

经过沟通,笔者了解到系统上线之后,被纳入到公司整体的集中备份平台上。笔者其他手头系统也被纳入过其中,备份平台支持OracleSQL Server等多种主流数据库产品。Oracle则是使用RMAN脚本进行操作,将备份数据存放在磁带介质上。

RMAN的备份数据是可以在磁盘和磁带双重介质上的。但是信息是作为一个整体存放在控制文件中的。那么一个猜想是:如果是进行obsolete,磁带和磁盘是相同的处理。Delete obsolete过程就需要尝试删除磁盘和磁带两个介质的备份。

问题是:RMAN脚本环境允许访问磁带吗?从脚本上,RMAN只是考虑了磁盘disk下的备份channel,而没有考虑到MML访问磁带。相信这也就是删除obsolete的原因。

访问RMAN,可以确定的确是DISKSBT_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博客 ” ,链接:http://blog.itpub.net/17203031/viewspace-1128769/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
求道~

注册时间:2010-11-30

  • 博文量
    545
  • 访问量
    7677540