More Info
									Standby Database:

The standby database is supported officially by ORACLE as of Version 7.3. The ORACLE
documentation contains detailed information on this database configuration. The following
sections provide an overview of the main features of the disaster recovery configuration.

Standby Database Configuration:

When the primary (productive) database is duplicated on a standby database, this is referred to
as a standby database configuration. The aim of this configuration is to minimize downtime if the
primary database suffers an error, since the standby database can assume the role of the
productive database in a very short time. The following diagram illustrates the standby database

Two identically configured databases operate on two identically configured hosts.

       The primary (productive) ORACLE instance is located on the first host, the database is
        open and fully available for all SQL prompts of the R/3 System. The primary database
        system is also the system which directly executes all database requests.

       The standby database is a copy of the primary database and is only intended as a
        recovery system.

The standby ORACLE instance on the second host is in a mounted standby state (not opened!)
and is recovered constantly. This means that the standby instance incorporates all changes to the
data of the primary instance either immediately, or with a slight delay. To do this, the offline redo
log files created in the primary database system are imported (only the redo entries already
archived by ORACLE can be imported). The standby instance therefore ‘follows’ the state of the
primary instance.

If it is necessary to recover the primary database system (for example, after a media error), the
standby instance can assume the functions of the primary instance in very short time (‘takeover’).
The recovery mode of the standby instance is therefore ended, and the standby database opened
for online operation.

Since all data files are already located on the standby host, costly reloading of the files is
avoided. Some redo entries may still need to be applied to the files to enable all transactions to
be incorporated in the standby instance. This means that you must first import the missing offline
redo log files from the primary instance. You can then try to archive the current online redo log file
of the primary instance with the ORACLE command ALTER SYSTEM ARCHIVE LOG CURRENT
and also to import these redo entries in the standby instance. If this command fails, the current
online redo log file can be copied to the standby host. It may be possible to directly import the
redo entries from the online redo log file.

After the takeover, a standby database needs to be set up again (usually on what was the
primary host).

Changes to the physical structure of the primary database (creating new files, renaming files,
changes to online redo log and control files) are not automatically incorporated in the standby
database in every case. The DBA may need to intervene depending on the type of change.

If it is not possible to incorporate the changes automatically, the recovery process is stopped, and
the DBA needs to intervene manually to incorporate the structural change in the standby
database. After that, the recovery process needs to be started again.

Renaming of database files in the standby database is not supported by BRBACKUP. The
original names of the primary database need to be retained.

If commands are executed in the primary database with the UNRECOVERABLE option, these
changes do not appear in the redo log files. It is therefore not possible for the standby instance to
receive any information about such changes. In this case, no error messages appear during the
recovery process. They are, however, recorded in the standby database ALERT file. You should
therefore check the ALERT file regularly.

You will find more detailed information in the ORACLE documentation. The new and/or changed
SQL and SVRMGR commands are also described there as well as the necessary init.ora
parameters, which are required for working with a standby database.

Standby Database: Support by BRARCHIVE:

In the standby database scenario, transfer of the offline redo log files from the primary to the
standby instance can be controlled by the SAP utility BRARCHIVE. This is possible, since
BRARCHIVE is able to copy offline redo log files to a hard disk.
A BRARCHIVE process runs on the primary host. It copies the offline redo log files to a mounted
directory, which represents the archive directory (usually saparch ) on the standby host. The
copy process runs through the network, BRARCHIVE must therefore be used with the verify
option ( -w ).

A BRARCHIVE process also runs on the standby host. This process waits for the offline redo log
files created in the mounted archive directory. If a redo log file was copied completely,
BRARCHIVE assumes the task of importing these redo entries into the standby instance (option
-m|- modify ), backing up the redo log file and deleting it if necessary.
BRARCHIVE therefore initiates the recovery process of the standby database, in which the offline
redo log files are processed individually.

Importing the redo entries can be delayed by a few minutes (the delay is specified in the option -
m <Delay(Minutes)> ). If a logical error occurs in the primary instance (for example,
accidental deletion of a table), it is possible to prevent this error from being imported in the
standby instance.
The offline redo log files are imported with the following ORACLE command: RECOVER STANDBY

Input syntax: -m [<delay>]

Default value: No delay

Delay: The offline redo log files which are created are sent to the
standby database before they are processed. This could happen with a
delay time of <delay> minutes after creating the ORACLE offline redo
log file.
If there is a standby database, brarchive -m must be called in order to
transfer the offline redo log files.


To import the redo log files, the DB user (usually SYSTEM ) must have the SYSDBA authorization.

When redo entries are imported in which a structural change of the primary database is recorded,
the BRARCHIVE process is terminated with the following ORACLE errors:

ORA-01670: new datafile <file_id> needed for standby database recovery

ORA-01157: cannot identify data file <file_id> - file not found

ORA-01110: data file <file_id> : ‘ <file_name> ‘

The structural change now needs to be incorporated manually in the standby database. To do
this, you can use the command
BRARCHIVE can then be started again.

Standby Database: Backup with BRBACKUP:

One main advantage of the standby database scenario is that backups do not have to be
performed in the primary (production) database system. Instead it allows the datasets of the
standby database to be backed up. This means that the database backup does not add to the
load on the host of the primary database instance. Since online operation does not occur on the
standby database, all the host’s resources can therefore be made available for the database
backup. The SAP utility program BRBACKUP backs up the standby database data.

    1. The standby instance is in the recovery state and must not be opened. You can make an
       offline backup only. For the BRBACKUP backup of the standby data, you must set the
       init<DBSID>.sap parameter backup_type = offline_standby .

    2. Renaming of database files in the standby database is not supported by BRBACKUP.
       The original names of the primary database need to be retained.

    3. As for the OPS configuration, certain requirements must be satisfied for the connection to
       a remote host.

       BRBACKUP logs on to the primary database instance (entries for the instance string in
        the init<DBSID>.sap parameter primary_db ) and retrieves the information required
        on the database structure. This information is entered in the backup logs.

       The standby database instance is stopped.

       BRBACKUP backs up the standby data.

       After the backup has been made, the original state of the standby database instance is
        recovered. If the database was in a recovery state, this state is restored (ORACLE

To create and configure a standby database you can make a BRBACKUP backup
(backup_type = offline_stop) of the production database. This is not opened later:
Instead it is transferred directly into the mount standby mode, where it takes over the role of the
standby database. The backup becomes the production system.

To recreate a standby configuration, you can make a copy of the production database. You can
then use this as the standby database ( backup_dev_type=disk_standby ).


This parameter is only relevant if the disaster recovery configuration is being used. The connect
string to the primary database instance is defined with this parameter so that BRBACKUP can log
onto the primary host.
Default value: None

primary_db = <connect_string>

<connect_string>: Connect string (‘SQL*Net database specification
string’) from the standby host to the primary (production) database.

primary_db = C11

As for the OPS configuration, certain requirements must be satisfied for the connection to a
remote host.

Structure-Retaining Database Copy:

With BRBACKUP you can make a copy of the database files which has exactly the same
directory structure. You can use this type of database to

       generate a test system from a production system

       Set up a Standby Database Scenario.

       have a database backup available which saves you the restoration process during a
        recovery. In this case the Oracle Home directory will be renamed as the new Oracle
        Home directory of the database copy (set link). The copied files are then the current files
        and the offline redo log files can be imported directly.

       change the location of the database files (file system or raw device). Database copy is
        the only way of moving database files from one file system to raw devices (or vice versa)
        by means of BRBACKUP.


The following directories must be created on the target database:

       sapdata directories

       sapbackup directory

       origlogA , origlogB , mirrlogA , mirrlogB directories of the online redo log files

The corresponding subdirectories are created automatically during copying.
/oracle/c11/sapdata2/stabd_1/stabd.data1 is copied to

Since this type of copy is a 1:1 copy no software compression may take place.

To make the copy of the database you have to define the name of the new Database_Home
directory (of the database copy) in the init<SID>.sap profile parameter new_db_home. In
addition to this set the parameter backup_dev_type to disk_copy or call up BRBACKUP with
the relevant command option brbackup -d|-device disk_copy.

Under Windows NT, the sapdata directories can be distributed across several drives. When you
make the copy, you can retain this distribution by specifying the appropriate target drives. see
brbackup m|-mode).

Input syntax:
-m all|<tablespace_name>|all_data|incr|full|<file_ID>|<file_ID1>-

Default: all

You can perform a full database backup or back up specific tablespaces or files (whether part of
the database or not). You can create object lists.

You can specify what you want to back up:
       all : Back up the complete database

In a Structure Retaining Database Copy ( backup_dev_type = disk_copy or
disk_standby ) you can retain the distribution of the sapdata directories to different drives

(only for Windows NT).

The files of the drive d are copied to drive k , the files of the drive e are copied to the drive l and
the files of the drive f are copied to the drive m .

brbackup -m all,d:=k:,e:=l:,f:=m:

If you do not specify a target drive, the files will be copied to the directory defined in the

This parameter must be set if you want to make a database copy using BRBACKUP
(backup_dev_type = disk_copy). The name of the home directory of the database copy is
defined in new_db_home .

Default: none

new_db_home = <dir>

UNIX: <dir> is the new SAP database directory ( SAPDATA_HOME )

NT : <dir> is the new SAP database directory: <drive>\oracle\<SID>

This directory must also contain the sapbackup directory.

Under Windows NT, the sapdata directories can be distributed across several drives. When
making a database copy, a target drive can be specified for each drive (see m|-mode). If you do
not specify a target drive, the files will be copied to the directory defined in the parameter.

       <tablespace name> : Back up the files of one tablespace.

       all_data : Back up the files of all tablespaces, except for pure index tablespaces.

       incr: Incremental backup with RMAN.

       full : Incremental Backup

       <file_ID> : Back up a data file with the specified ORACLE file ID as file ID. Control
        files can be addressed with the file ID 0.
        Online redo log files can be addressed using the file ID 0<n>, <n> is the redo log group
        number. To address all the online redo log files, use file ID 00.

       <file_ID1>-<file_ID2> : Back up the files specified in the file ID interval. The
        specified file IDs must be known in the database.

       <generic_path> : Enter a complete path to back up the required database file, non-
        database file, or directory. Specify a generic path to back up all the database data files
        whose name starts with that path. In this case, the path must contain at least the
        ORACLE_HOME directory and an additional generic specification (for example,
        sapdata<n> ) in the path.

When you specify a directory to be backed up its contents and the names of the subdirectories
are backed up. However the directory structure and the content of the subdirectories are not
backed up.

       <object list> : You can specify a list of tablespaces or files, or combine the key word
        all with an object list. The individual objects are separated by commas (commas only, no

       sap_dir : With this option, you can automatically determine and save all the files of the
        SAP environment. This means that the following directory trees are saved:
        /sapmnt/<SAPSID> , /usr/sap/<SAPSID> and /usr/sap/trans . If possible,
        these directories should be backed separately. You can only use this option when saving
        to tape without verifying the backup.

       ora_dir : With this option, you can automatically determine and save all the non-
        database files of the ORACLE environment. This means that the directory trees are
        saved in <ORACLE_HOME> (except for the sapdata<n> and saplog- or
        origlog/mirrlog directories). If possible, save these directories in a separate backup
        run. You can only use this option when saving to tape without verifying the backup.

For UNIX systems: Start BRBACKUP to save the SAP/ORACLE environment ( brbackup -m
sap_dir | ora_dir ) under user root , as otherwise you will not have the authorizations
required for the directory to be saved.

Saving and restoring under root also has the advantage that you can be sure that the settings
for the user and authorizations for the files and directories will be kept after restoring.

Parameters in init<DBSID>.sap : backup_mode.

If you want to repeatedly back up several tablespaces and/or files, it may be more effective to
configure parameter backup_mode of the initialization profile accordingly.

This parameter is used by BRBACKUP and BRRESTORE to determine the scope of the
backup/restore activity.

Default: all

Possible values:

all : Back up the entire database using BRBACKUP or restore all tablespaces (without control
files or redo log files) using BRRESTORE.

To top