
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
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<DBSID>.log , for every ORACLE instance. It is stored in the global archiving directory.Advantages
Disadvantages
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.