應用系統生命週期是一個整體，除了最開始的需求調研、開發測試和上線，更長的時期是在運維方面。應用系統的價值體現也就是在運維階段，一個經常報錯故障的系統運維環境，是很難獲得良好的使用者體驗的。

在實踐中，軟體開發商和運維方面如果沒有完善的溝通交流，新系統是不容易融入原有的運維體系中的，更有甚者會引起很多其他故障。本篇就介紹一個由於備份策略衝突引起的磁碟空間故障。

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資料也許是更好的選擇。

這個案例還告訴我們一個教訓，就是開發運維絕對不能分家。系統設計、開發測試和上線過程，系統開發和運維方一定要充分接觸溝通，對系統整體進行測試實驗。儘早的發現各種問題，形成成熟的解決方案，才能更好的做到系統平穩執行。

由於不同備份策略不相容引起的磁碟空間故障一例

相關文章