netbackup7.0備份6號(hào)錯(cuò)誤怎么回事

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

在NBU的備份過(guò)程中是通過(guò)調(diào)用各種備份腳本的方式進(jìn)行備份數(shù)據(jù)庫(kù)的，執(zhí)行備份腳本的時(shí)候無(wú)論返回什么樣的錯(cuò)誤，都會(huì)返回給NBU的日志文件bphdb，然后NBU統(tǒng)一報(bào)出錯(cuò)誤,其中6號(hào)錯(cuò)誤是比較常見(jiàn)的典型錯(cuò)誤。我們?cè)赥roubleShooting的時(shí)候可以開(kāi)啟客戶端日志級(jí)別VERBOSE=5，并在/usr/openv/netbackup/logs下創(chuàng)建backint、bphdb等文件夾，通過(guò)查看bphdb下的log.060912、stdout.060912這樣形式的日志文件，來(lái)詳細(xì)了解備份出錯(cuò)的原因然后對(duì)癥下藥解決問(wèn)題.下面列舉NBU 6號(hào)錯(cuò)誤的幾種情況：

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

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

數(shù)據(jù)庫(kù)已更改。

SQL> alter database open;

數(shù)據(jù)庫(kù)已更改。

2、備份狀態(tài)已處于active導(dǎo)致6號(hào)錯(cuò)誤
通過(guò)查看日志發(fā)現(xiàn)如下信息：
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
這個(gè)一般是因?yàn)閭浞葸M(jìn)程意外終止造成的。在BEGIN BACKUP下達(dá)后,系統(tǒng)要對(duì)表空間執(zhí)行檢查點(diǎn),并將該檢查點(diǎn)前的所有事務(wù)應(yīng)用都固化到數(shù)據(jù)文件,然后凍結(jié)這個(gè)SCN,直到使用END BACKUP,使備份過(guò)程結(jié)束,再更新為新的SCN。如果備份過(guò)程意外終止，我們需要使用END BACKUP,使備份過(guò)程結(jié)束,再重新開(kāi)始。
解決辦法：
首先查看備份狀態(tài)
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       

確認(rèn)主機(jī)無(wú)其他任何在執(zhí)行的備份，然后結(jié)束已處于ACTIVE狀態(tài)的備份
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    
再查看狀態(tài)正常了，可以在NBU中重新運(yùn)行此備份任務(wù)了。
3、歸檔日志異常導(dǎo)致6號(hào)錯(cuò)誤
通過(guò)查看日志發(fā)現(xiàn)如下信息：
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

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

4 腳本本身錯(cuò)誤導(dǎo)致的6號(hào)錯(cuò)誤
排除以上問(wèn)題后，備份時(shí)仍然報(bào)6號(hào)錯(cuò)誤，看日志也無(wú)明顯征兆，那就需要結(jié)合具體問(wèn)題進(jìn)行具體分析并解決。
曾遇到一個(gè)案例：一臺(tái)SAP的生產(chǎn)機(jī)備份總是報(bào)6號(hào)錯(cuò)誤，排查了多次都無(wú)果。最后把這臺(tái)機(jī)器上的有關(guān)備份的腳本、日志和文件一一與生產(chǎn)線上能正常備份的機(jī)器進(jìn)行對(duì)比排查，終于發(fā)現(xiàn)是一個(gè)參數(shù)的問(wèn)題，修改參數(shù)后最終解決了這一問(wèn)題。
SAP上需要排查的文件：bp.conf  init.utl、init.ora、init.sap、spfile.ora   sap_online_backup  sap_redo_log_backup  log.071912、stdout.071912

看完了這篇文章，相信你對(duì)“netbackup7.0備份6號(hào)錯(cuò)誤怎么回事”有了一定的了解，如果想了解更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！