Shulou(Shulou.com)06/01 Report--

Editor to share with you how netbackup7.0 backup No. 6 error is going on, I hope you have something to gain after reading this article, let's discuss it together!

In the backup process of NBU, the database is backed up by calling various backup scripts. No matter what kind of error is returned when executing the backup script, it will be returned to the log file bphdb of NBU, and then NBU will report the error uniformly, of which error No. 6 is a common typical error. When we are in TroubleShooting, we can open the client log level VERBOSE=5 and create backint, bphdb and other folders under / usr/openv/netbackup/logs. By viewing the log files in the form of log.060912 and stdout.060912 under bphdb, we can learn more about the cause of the backup error and solve the problem accordingly. The following is a list of several cases of NBU 6 error:

1. The archiving mode is turned off, resulting in error 6.

By looking at the log, you find the following information:

Assigned channel: ORA_DISK_1

Channel ORA_DISK_1: sid=157 devtype=DISK

Channel ORA_DISK_1: starts the backup set of all data files

Channel ORA_DISK_1: specifying data files in the backup set

MAN-03009: the backup command (on the ORA_DISK_1 channel, at 11:15:32 on 06 / 03 / 2012) failed

ORA-19602: active files cannot be backed up or copied in NOARCHIVELOG mode

Solution:

SQL > shutdown immediate

The database has been closed.

The database has been uninstalled.

The ORACLE routine has been closed.

SQL > startup mount

The ORACLE routine has been started.

Total System Global Area 293601280 bytes

Fixed Size 1248600 bytes

Variable Size 163578536 bytes

Database Buffers 121634816 bytes

Redo Buffers 7139328 bytes

The database is loaded.

SQL > alter database archivelog

The database has changed.

SQL > alter database open

The database has changed.

2. The backup status is already in active, which causes error 6.

By looking at the log, you find the following information:

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

This is usually caused by the unexpected termination of the backup process. After the BEGIN BACKUP is issued, the system performs a checkpoint on the tablespace, solidifies all transaction applications before the checkpoint to the data file, and then freezes the SCN until END BACKUP is used to finish the backup process, and then update to the new SCN. If the backup process terminates unexpectedly, we need to use END BACKUP to finish the backup process and start again.

Solution:

First check the backup status

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

Verify that the host does not have any other backups in progress, and then end the backup that is already in the ACTIVE state

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

Check again that the status is normal, and you can rerun this backup task in NBU.

3. Error No. 6 caused by abnormal archive log

By looking at the log, you find the following information:

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

When the oracle archive log file delete is dropped or changed abnormally, the archivelog information is still recorded in the controlfile file. After we manually erase or change the files in the archive directory, these records are not erased from the controlfile, that is, the database does not know that these files no longer exist. At this time, it usually causes the failure of the rman backup, because the Rman backup will detect the missing logs. As a result, it is impossible to continue the implementation.

In order to restore a normal backup of RMAN, we usually manually execute two commonly used commands in the database.

The function of RMAN > crosscheck archivelog all; is to check the difference between the control file and the actual physical file.

The function of RMAN > delete expired archivelog all; is to synchronize the information of the control file with the information of the actual physical file.

If you execute crosscheck alone without delete, then the backup fails because the information that controls the file is still different from the actual information. Generally, we can try to CROSSCHECK first, then execute crosscheck archivelog all after delete expired archivelog all, and then restart the backup task in NBU to run normally.

Alternatively, if the archive log is full of disk space, Oracle does not recognize that there is free space if you delete the archive log using the operating system's command. You can also try these two commands when using the delete archivelog all command in rman cannot be solved.

RMAN > crosscheck archivelog all

RMAN > delete expired archivelog all

4 error 6 caused by the error of the script itself

After eliminating the above problems, the No. 6 error is still reported during the backup, and there is no obvious sign when looking at the log, so we need to analyze and solve the specific problems.

Once encountered a case: a SAP production machine backup always reported No. 6 error, troubleshooting many times to no avail. Finally, the scripts, logs and files about backup on this machine are compared with the machines that can be backed up normally on the production line, and it is found that it is a parameter problem, and this problem is finally solved after modifying the parameters.

Files to be checked on SAP: bp.conf init.utl, init.ora, init.sap, spfile.ora sap_online_backup sap_redo_log_backup log.071912, stdout.071912

After reading this article, I believe you have a certain understanding of "what's wrong with netbackup7.0 backup No. 6". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.