共计 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 行业资讯频道，感谢各位的阅读！
