BRARCHIVE :Central Scenario

There is a global archiving directory which normally is created on the host of the DDB instance. This directory can be accessed from the other hosts with NFS-Mount. All the archiving processes save the online redo log files in this global working directory in this manner (if necessary using the network).

Definition in init.ora :

log_archive_dest = /oracle/C11/saparch/C11arch

log_archive_format = %t_%s.dbf

%t - Thread number (for identifying the instance)

%s - Log sequence number

The ORACLE placeholder @ (for ORACLE_SID) may not appear in the name of an offline redo log file; this means that it may not appear in either log_archive_dest nor in log_archive_format .

BRARCHIVE is only started on the host of an ORACLE instance (generally the DDB instance since normally the archiving directory is available locally there and thus archiving is not necessary with the network) and archives the complete offline redo log files of all the ORACLE instances.

BRARCHIVE creates a separate summary log, arch.log , for every ORACLE instance. It is stored in the global archiving directory.

Advantages

• There is only one volume pool managed by BRARCHIVE.

• The entire BRARCHIVE functionality is available, even continuous archiving with the option
-f.

• Only the disk space in the global archiving directory must be provided.

Disadvantages

• If a network error occurs, it is possible that the online redo log files cannot be saved in the archiving directory by the ORACLE archiving process. This can cause an "archive stuck" and thus result in failure of a database instance.

• If a network error occurs, access to the NFS-mounted disks might be disturbed. This can cause corrupt offline redo log files to be created by the ORACLE archiving processes.

• SAP does not recommend this scenario. See
Special Features of BRARCHIVE.

Due to possible network problems, use of the central scenario is only acceptable for test systems with a very stable and reliable network.

Further Remarks

The offline redo log files are required if the database has to be recovered. Recovery measures should only be performed by a very experienced administrator, who is familiar with the OPS-specific behavior of the database system in this case.

Note the following if the offline redo log files have to be restored:

The required offline redo log files of all the instances can be restored in the global archiving directory (with SAPDBA or a BRRESTORE call). You can now start the recovery on the instance with the global archiving directory (generally the DDB instance, see the above graphic). Information about this can be found in the ORACLE documentation