僅僅只備份是不夠的

　　是不是我們的數據庫，加上一套成熟可靠的備份軟件(比如NBU、DP、TSM等)，以及購置了可靠的大容量的帶庫就足夠了?或者下面一個案例能夠給我們一些啟示。

　　案例來自于一個老客戶，一套重要系統的Oracle RAC數據庫，由于硬件問題，一個包含關鍵業務數據的文件被離線(在歸檔模式下，寫文件出錯會導致文件被置為離線狀態，而不是庫宕掉)。在嘗試 recover datafile的時候，提示缺少一個歸檔日志。歸檔日志已經被備到帶庫上，本地磁盤上已經沒有了這個歸檔日志文件。

　　這套庫是用TSM備份的，使用rman還原歸檔日志，稱找不到這個歸檔日志?？雌饋沓鰡栴}了，在rman中用下面的命令：

　　list backup of archivelog sequence 18884 thread 2;

　　返回的結果說沒有找到這個歸檔日志的備份。甚至于用命令：

　　list backup of archivelog all;

　　發現好些歸檔日志沒有了備份。但是這些文件又不在本地磁盤上。那么，這里有幾種可能：

　　歸檔日志被人為地刪除，根本沒有備份

　　歸檔日志的備份已經被刪除，通過delete backup命令

　　第1種情況，可以從v$archived_log視圖判斷歸檔日志到底有沒有備份(通過BACKUP_COUNT列)。我們可以從備份保留的日志中判斷第2種情況是否存在。

　　檢查備份操作的日志，發現恢復所需要的歸檔日志文件是成功備份了的。那備份怎么消失了?在備份操作的日志目錄中，還發現一個日志文件有 crosscheck backup然后delete expired backup的記錄，而被刪除的備份正好有恢復所需要的歸檔日志所在的備份。所以，這里可以知道，出現了上述說的第2種情況，備份被刪除了。

　　為什么會出現備份在crosscheck backup之后成為expired狀態，這個結果就來源于在rman中進行crosscheck backup時，備份服務器返回的結果表明這個備份不可訪問了，或許是權限問題，或者是配置不當，或者是備份文件真的不能訪問了。從目前的情況來看，備份都是成功的，看上去帶庫、備份服務器都是好的。不過這里值得注意的是，這是一套RAC數據庫，歸檔日志是在節點1上完成的，在節點1上也進行了 crosscheck backup，并且是先進行crosscheck，而其結果表明備份是available狀態的。但是隨后節點2的crosscheck的結果是 expired，那只能說明由于權限或配置問題，導致節點2不能訪問到節點1所做的備份(當然不排除在這個時間窗口內備份在帶庫上或備份服務端刪除的可能，但是可能性較小，所以分析問題得先從可能性更大的入手)。

　　是不是沒救了?答案在于，備份到底還在不在帶庫上?

　　節點1先crosscheck正常，隨后節點2 crosscheck稱備份文件沒有或不可訪問，然后節點2刪除了備份。只不過這里要注意的是：既然crosscheck不能訪問不到備份，那么 delete操作也應當不會真正刪除備份(備份都訪問不到怎么能物理刪除呢?)，只是把備份信息從catalog里面刪除掉而已。所以這里的結論是真正的備份還在帶庫上?？梢哉覀浞莨芾韱T或通過TSM命令來檢查，不過客戶說，搞TSM的人找不到了。

　　接下來，嘗試找找看，有沒有在備份歸檔日志之后，但在刪除備份之前的備份控制文件存在?？上]有，如果有，可以用這個控制文件來還原歸檔日志。

　　或許可以通過手工在catalog庫里面添加記錄，然后同步到控制文件來進行恢復。

　　不過我們還有另一個方法，就是直接使用dbms_backup_restore包：

　　幸運的是，歸檔日志成功還原，然后數據文件成功recover。

　　從這個案例中，我們獲得的是：

　　并不是說，備份沒有報錯，備份正常運行就足夠了。在備份的時候，為了避免備份出錯而失敗，在備份之前進行crosscheck archivelog，把人為刪除掉的歸檔從catalog中去掉從而不備份，也就在備份時不報錯;或者是備份時skip inaccessible;實際上這有點類似于掩耳盜鈴，備份可能是殘缺的，根本不可用。

　　rman中的crosscheck backup，使得backup成為expired狀態，這本身說明可能存在問題，而不僅僅是從catalog中刪除備份了事。針對這個案例來說，backup成為expired，本身就是一種異常，就應該要去檢查備份服務器的配置等。

　　所有涉及備份相關的操作，包括備份，刪除備份，crosscheck備份，保留詳細的rman日志是非常有用的。

　　應該在每次備份后，對控制文件進行一次備份;打開控制文件的AUTO BACKUP也是有必要的。

原文轉自：http://blogread.cn/it/article/5922