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号错误怎么回事"有了一定的了解，如果想了解更多相关知识，欢迎关注行业资讯频道，感谢各位的阅读！