netbackup7.0備份6號錯誤怎么回事

小編給大家分享一下netbackup7.0備份6號錯誤怎么回事，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

在NBU的備份過程中是通過調用各種備份腳本的方式進行備份數據庫的，執行備份腳本的時候無論返回什么樣的錯誤，都會返回給NBU的日志文件bphdb，然后NBU統一報出錯誤,其中6號錯誤是比較常見的典型錯誤。我們在TroubleShooting的時候可以開啟客戶端日志級別VERBOSE=5，并在/usr/openv/netbackup/logs下創建backint、bphdb等文件夾，通過查看bphdb下的log.060912、stdout.060912這樣形式的日志文件，來詳細了解備份出錯的原因然后對癥下藥解決問題.下面列舉NBU 6號錯誤的幾種情況：

1、歸檔模式被關閉導致6號錯誤
通過查看日志發現如下信息：
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=157 devtype=DISK
通道 ORA_DISK_1: 啟動全部數據文件備份集
通道 ORA_DISK_1: 正在指定備份集中的數據文件
MAN-03009: backup 命令 (ORA_DISK_1 通道上, 在 06/03/2012 11:15:32 上) 失敗
ORA-19602: 無法按 NOARCHIVELOG 模式備份或復制活動文件
解決辦法：
SQL> shutdown immediate;
數據庫已經關閉。
已經卸載數據庫。
ORACLE 例程已經關閉。
SQL> startup mount;
ORACLE 例程已經啟動。

Total System Global Area  293601280 bytes
Fixed Size                  1248600 bytes
Variable Size             163578536 bytes
Database Buffers          121634816 bytes
Redo Buffers                7139328 bytes
數據庫裝載完畢。
SQL> alter database archivelog;

數據庫已更改。

SQL> alter database open;

數據庫已更改。

2、備份狀態已處于active導致6號錯誤
通過查看日志發現如下信息：
BR0328E Database file /oracle/PRD/data4/sr3.data25 of tablespace PSAPSR3 is already in backup status
BR0328E Database file /oracle/PRD/data1/sr3.data26 of tablespace PSAPSR3 is already in backup status
BR0328E Database file /oracle/PRD/data2/sr3.data27 of tablespace PSAPSR3 is already in backup status
BR0328E Database file /oracle/PRD/data3/sr3.data29 of tablespace PSAPSR3 is already in backup status
BR0280I BRBACKUP time stamp: 2012-04-11
BR0054I BRBACKUP terminated with errors
這個一般是因為備份進程意外終止造成的。在BEGIN BACKUP下達后,系統要對表空間執行檢查點,并將該檢查點前的所有事務應用都固化到數據文件,然后凍結這個SCN,直到使用END BACKUP,使備份過程結束,再更新為新的SCN。如果備份過程意外終止，我們需要使用END BACKUP,使備份過程結束,再重新開始。
解決辦法：
首先查看備份狀態
SQL> select * from v$backup;

     FILE# STATUS                CHANGE# TIME
---------- ------------------ ---------- ---------------
         1 ACTIVE             1.2262E+10 11-Apr-12
         2 ACTIVE             1.2262E+10 11-Apr-12
         3 ACTIVE             1.2262E+10 11-Apr-12
         4 ACTIVE             1.2262E+10 11-Apr-12
         5 ACTIVE             1.2262E+10 11-Apr-12
         6 ACTIVE             1.2262E+10 11-Apr-12
         7 ACTIVE             1.2262E+10 11-Apr-12
         8 ACTIVE             1.2262E+10 11-Apr-12       

確認主機無其他任何在執行的備份，然后結束已處于ACTIVE狀態的備份
SQL> alter database end backup;
SQL> select * from v$backup;

     FILE# STATUS                CHANGE# TIME
---------- ------------------ ---------- ---------------
         1 NOT ACTIVE             1.2262E+10 11-Apr-12
         2 NOT ACTIVE             1.2262E+10 11-Apr-12
         3 NOT ACTIVE             1.2262E+10 11-Apr-12
         4 NOT ACTIVE             1.2262E+10 11-Apr-12
         5 NOT ACTIVE             1.2262E+10 11-Apr-12
         6 NOT ACTIVE             1.2262E+10 11-Apr-12
         7 NOT ACTIVE             1.2262E+10 11-Apr-12
         8 NOT ACTIVE             1.2262E+10 11-Apr-12    
再查看狀態正常了，可以在NBU中重新運行此備份任務了。
3、歸檔日志異常導致6號錯誤
通過查看日志發現如下信息：
BR0280I BRARCHIVE time stamp: 2012-04-17 17.01.23
BR0015I Offline redo log file /oracle/QAS/oraarch/arch2_16829_732047568.dbf deleted

BR0280I BRARCHIVE time stamp: 2012-04-17 17.01.23
#ARCHIVE.. /oracle/QAS/oraarch/arch2_16830_732047568.dbf deleted

BR0280I BRARCHIVE time stamp: 2012-04-17 17.01.23
BR0015I Offline redo log file /oracle/QAS/oraarch/arch2_16830_732047568.dbf deleted

BR0280I BRARCHIVE time stamp: 2012-04-17 17.01.23
#ARCHIVE.. /oracle/QAS/oraarch/arch2_16831_732047568.dbf deleted

當oracle的歸檔日志文件delete掉或異常變動后，在controlfile文件中仍然記錄著這些archivelog的信息，在我們手工清除或改動archive目錄下的文件后，這些記錄并沒有被我們從controlfile中清除掉，也就是說數據庫并不知道這些文件已經不存在了，在這個時候通常會造成rman備份的失敗，因為Rman備份會檢測到日志缺失，從而無法進一步繼續執行下去。
這時為恢復RMAN的正常備份，我們通常會在數據庫里手工執行兩條常用的命令。
RMAN>crosscheck archivelog all；作用是檢查控制文件和實際物理文件的差別。
RMAN>delete expired archivelog all;作用是同步控制文件的信息和實際物理文件的信息。
如果單獨執行crosscheck而沒有執行delete那么備份還是失敗的，原因是那些控制文件的信息和實際的信息還是不同。一般我們可以試著先CROSSCHECK一下，如果不行執行delete expired archivelog all后再執行一下crosscheck archivelog all，最后再在NBU中重啟備份任務即可正常運行。
另外一種情況：如果歸檔日志寫滿磁盤空間，如果是使用操作系統的命令刪除歸檔日志，Oracle并不能識別出有空閑的空間。在rman中使用delete archivelog all命令還不能解決時，也可以嘗試這兩個命令。
RMAN>crosscheck archivelog all;
RMAN>delete expired archivelog all;

4 腳本本身錯誤導致的6號錯誤
排除以上問題后，備份時仍然報6號錯誤，看日志也無明顯征兆，那就需要結合具體問題進行具體分析并解決。
曾遇到一個案例：一臺SAP的生產機備份總是報6號錯誤，排查了多次都無果。最后把這臺機器上的有關備份的腳本、日志和文件一一與生產線上能正常備份的機器進行對比排查，終于發現是一個參數的問題，修改參數后最終解決了這一問題。
SAP上需要排查的文件：bp.conf  init.utl、init.ora、init.sap、spfile.ora   sap_online_backup  sap_redo_log_backup  log.071912、stdout.071912

看完了這篇文章，相信你對“netbackup7.0備份6號錯誤怎么回事”有了一定的了解，如果想了解更多相關知識，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！