本文共 3894 字，大约阅读时间需要 12 分钟。
在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/arch1_16829_732047568.dbf deletedBR0280I BRARCHIVE time stamp: 2012-04-17 17.01.23
#ARCHIVE.. /oracle/QAS/oraarch/arch1_16830_732047568.dbf deletedBR0280I BRARCHIVE time stamp: 2012-04-17 17.01.23
BR0015I Offline redo log file /oracle/QAS/oraarch/arch1_16830_732047568.dbf deletedBR0280I BRARCHIVE time stamp: 2012-04-17 17.01.23
#ARCHIVE.. /oracle/QAS/oraarch/arch1_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转载地址：http://hqiox.baihongyu.com/