共計 3750 個字符，預計需要花費 10 分鐘才能閱讀完成。
丸趣 TV 小編給大家分享一下 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 號錯誤怎么回事”有了一定的了解，如果想了解更多相關知識，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！
