BRARCHIVE :Mixed Scenario

BRARCHIVE is started on all ORACLE instance hosts. However, its activities differ depending on whether or not it is the DDB instance host.

· On non-DDB instance hosts, there are relatively small archive directories, which can temporarily contain the respective offline redo log files.

· On the DDB instance host, there is, locally, a relatively large (central) archiving directory that can contain the offline redo log files of all ORACLE instances.

Every non-DDB instance can access the central archiving directory via NFS-mount.

Name of the R/3 System: C11

Large local archiving directory on the DDB instance: /loracle/saparchglobal

Directory /oracle/C11/saparch refers to this large archiving directory using a link.

Small, local archiving directories on the non-DDB instances: /oracle/C11/saparch

The large archiving directory is added to every non-DDB instance using an NFS-mount under: /oracle/saparchglobal

Definitions in init.sap

Parameter archive_copy_dir on all ORACLE instances
archive_copy_dir = /oracle/saparchglobal

Definitions 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; that is, it may not appear in either log_archive_dest nor in log_archive_format .

Archiving of the offline redo log files of the non-DDB instances executes as follows:

Archiving on the Disk

On every non-DDB instance, BRARCHIVE is started regularly or with the -f option. BRARCHIVE copies the offline redo log files for each instance from the local archiving directory into the NFS mounted central archiving directory (BRARCHIVE call to archive the offline redo log files on disk, option -d disk ). To check the success of the operation, you should use the -w option to verify the backup (see above graphic).

This BRARCHIVE run should be terminated with brarchive -f stop and then restarted every day (for performance reasons).

Archiving on Tape

The BRARCHIVE running on the DDB instance host archives the offline redo log files found in the central archiving directory (BRARCHIVE call to archive the offline redo log files on tape, option d tape ). The offline redo log files of all ORACLE instances are continuously archived to the volumes (tapes) via this backup device connected to the DDB host.

Advantages

• Local backups of the offline redo log files can be stored in relatively small archiving directories on the hosts of all non-DDB instances.

• There is only one volume pool managed by BRARCHIVE.

• Normally SAP installs this scenario for OPS databases.

Disadvantages

· On all non-DDB instances, BRARCHIVE must either be started regularly or started with the option -f so that the relatively small archiving directories do not overflow.

SAP normally installs this scenario. It should generally be used in production systems, especially if offline redo log files occur relatively frequently on all instances (and you are therefore working with option -f to avoid an "Archive Stuck").

Further Remarks

The offline redo log files are required if the database has to be recovered. Recovery measures should only be preformed by an 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 which were archived on tape can be restored in the central working directory (generally residing on the DDB instance) (with SAPDBA or a BRRESTORE call). It is essential that you now check whether there are offline redo log files in the archiving directories of the other instances which were not yet copied to the directory of the central instance by BRARCHIVE (this means that archiving on disk did not yet execute). If necessary, BRARCHIVE has to be started on the indiivdual instances, in order to copy missing offline redo log files into the central archiving directory. You can then start the recovery on the central instance (information about this can be found in the ORACLE documentation).