SAP Note 24594 - Backup of raw disks and Oracle parallel server

Symptom:

Topic:
Backup of databases on raw devices and Oracle parallel server configuration.

Other terms

Raw Disk, OPS
Oracle Real Application Server (RAC) - the new implementation of the Oracle Parallel Server in Release 9i or higher.

Reason and Prerequisites

Extract from the 3.0 documentation.

Solution

ORACLE Databases on Raw Devices
------------------------------------------------------
An ORACLE database can be operated from raw devices. The SAP
utilities for database backup support this configuration. The following
sections describe the special features for the SAP utilities if you
make a backup to raw devices.

1.) ORACLE Databases on Raw Devices: Overview
2.) SAPDBA Support for Raw Device Configuration
3.) Supporting the Raw Device Configuration with BRBACKUP and
BRRESTORE

---------------------------------------------
1.) ORACLE Databases on Raw Devices: Overview

Application programs such as database management systems
frequently avoid the file management of the UNIX system and the
data is written directly on a partition. In this case, the partition is
used as a raw device. No file system exists in such a partition. Using
this type of storage might bring certain advantages regarding the
speed when accessing the data, but requires its own file
management.
You can operate an ORACLE database on raw devices.

Advantages
Working with raw devices brings considerable performance gains for
the following reasons:
* The overhead for maintenance for a file system can be
neglected.
* Since the usual buffer cache for a file system can be neglected,
less main memory is required.
* Since no management information has to be stored on the disk,
less disk space is required.
* Since the accesses do not have to be synchronized and the
management information does not have to be recorded, the load
on the CPU is reduced.
If you operate the ORACLE database system on raw devices, you
can use the Parallel Server option.

Disadvantages
Working with raw devices makes administration more difficult for the
following reasons:
* There is no description of the files residing on the raw devices
in the system.
* The configuration of the storage space is quite inflexible
because only one database file is permitted per raw device (and
therefore per partition). The sizes of the individual partitions
must be adjusted to the sizes of the database files. This makes
later relocation of the database files to other partitions more
difficult.
* It is possible to save raw devices with the dd command, but its
complicated syntax must be accepted.

SAPDBA can only carry out limited checks on raw devices.
This has to do with the fact that SAPDBA only checks the raw
devices that belong to the database user ora.
Raw devices are recognized only if they are allocated to this
database SAPSID (SAPDBA does not check whether there
are also objects from other applications in these raw
devices). Therefore the database administrator has to work
carefully here.

----------------------------------------------------------------------
2.) SAPDBA Support for Raw Device Configuration

The following information is important for you if you intend to use
SAPDBA for ORACLE database administration on raw devices:
* The data for a tablespace can be stored either in raw devices or
in files. Be sure to observe the SAP naming convention for
tablespaces on raw devices:
/sapraw/_ -> / : Sequentially assigned number for files)
: Specifies the central directory containing
the devices. This directory may also be specified in the
rawdev_dir parameter.
: _

Each tablespace "file" (held on a raw device) visible to ORACLE
is a symbolic link to a raw device. SAPDBA checks that the
naming convention has been observed.

Example: Tablespace PSAPDOCUD
/oracle/C11/sapraw/docud_1 -> /dev/rdsk/C11docud_1

* The database link structure is one of things recorded in the
structure log struct.log.
If the database check is done using SAPDBA, SAPDBA uses
this structure log to check whether the link structure is still
complete and immediately repairs it if not. If a tablespace is
extended, a new tablespace is created or a tablespace is
reorganized with data files then SAPDBA updates the
structure log.
* Each raw device can contain only one tablespace "file"
(requirement of ORACLE). SAPDBA can set the size of this
partition. Therefore, in the case of tablespace extension (adding
a "file" from a raw device), for example, the size of the raw
device is determined automatically and is used for the size of
the file.
* It may be a good idea to specify the rawdev_dir
and blkdev_dir parameters in the init.dba profile.

-----------------------------------------------------
3.) Supporting the Raw Device Configuration with BRBACKUP and
BRRESTORE

The BRARCHIVE utility remains unchanged in a raw device
configuration because offline redo log files must always reside in a
file system.
There are some changes in the BRBACKUP and BRRESTORE
programs in a raw device configuration, but these changes have no
effect on the function scope of the programs. The known
functionality of BRBACKUP and BRRESTORE for backing up and
restoring file systems remains unchanged.

Use the dd command to access raw devices.
* With dd, you can write directly from/to the raw device to/from
tape (backup/restore to/from tape)
* With dd, you can copy directly from/to the raw device to/from
disk with file system (backup/restore to/from disk)
* In case of a backup with software compression, output of the
command dd is sent directly to the compress. In case of a
restore with decompression, output of uncompress is sent to dd.
* In case of a backup on a remote computer, output of dd is sent
for example directly to remsh (/rsh etc.). In case of a restore
from a remote computer, it is sent from remsh (/rsh etc.) to the
dd command.
* There are new init.sap parameters for defining the
options for the dd command: dd_flags and dd_in_flags.

Since the dd command does not support a dd
continuation tape (in this case an I/O error is reported), a
method which is similar to the cpio continuation method is not
supported. This means that each individual database file
residing on the raw devices must completely fit onto one
tape. This restriction does not refer to the BRBACKUP
continuation tape management, which means that the
BRBACKUP utility can request continuation tapes if they
should be necessary for backup of the next database files.



ORACLE Databases and Parallel Server Option
---------------------------------------------------------
If an ORACLE database is operated from raw devices, it is possible
to use the Parallel Server option of the ORACLE-RDBMS. The SAP
utilities for backing up the database support this configuration. In
the following sections, the special features of the SAP utilities for
backing up when using the Parallel Server option are explained.

1.) ORACLE Databases and Parallel Server Option: Overview
2.) Parallel Server Configuration for Using SAPDBA
3.) Parallel Server Configuration when Using BRBACKUP,
BRARCHIVE and BRRESTORE

---------------------------------------------------
1.) ORACLE Databases and Parallel Server Option: Overview

The ORACLE Parallel Server option (OPS) is described in the
corresponding ORACLE documentation. Only the most important
features of the OPS configuration when using the SAP utility
programs will be discussed here:
* All control files, online redo log files and database data files are
on raw devices, which can be accessed from all hosts in a
cluster (the raw devices are shared).
* On the hosts in the cluster, there are several ORACLE
instances, which can access the database files (normally one
instance per host).
* Every ORACLE instance has a unique name (this is a SAP
standard) - the so-called ORACLE system ID. When setting up a
connection to the database, the ORACLE instance is determined
by the environment variable ORACLE_SID (abbreviated,
DBSID) or by a connect string.
* Every ORACLE instance uses separate online redo log groups
which can also contain mirrored online redo log files. All groups
in one instance set up a so-called online redo thread which is
identified by a number.
* Every ORACLE instance writes separate offline redo log files
which are identified by the thread number and the sequential log
sequence number. The offline redo log files are stored in a file
system as normal files. You can normally only access this file
system locally, that is, from the host on which the instance runs.

• * Every ORACLE instance has a separate init.ora profile which, among other things, determines the thread number (parameter thread) and the name format of the offline redo log files (parameter log_archive_format). The corresponding character strings can contain the usual placeholders ? () and @ (). To avoid problems, this is only allowed in the following form:

log_archive_dest = ?/saparch/arch
In the standard installation, all the instances should have the same . If they have different values, the question mark must be replaced directly: log_archive_dest = /oracle//saparch/arch
- log_archive_format = %t_%s.dbf
* One of the ORACLE instances (for SAP installations normally
the instance with thread number 1) is the so-called dedicated
database instance (DDB instance). All administration tasks in the
database (for example database backup, tablespace extension,
reorganization) are carried out from this instance.
* The standard assignment instance (ORACLE_SID or DBSID)
and thread look like this in an SAP System C11:

Instance (DBSID) Thread
C11 1 (DDB instance)
C11_002 2
C11_003 3
... ...

Before you work with your OPS database, you should become
familiar with the concrete installation. Use all the available
information, such as the installation guidelines.
* All the ORACLE instances must be administrable from the DDB
instance, that is, you must be able to start and stop them from
the DDB instance. You should be able to perform these
operations from a local SQLDBA session. In order to do this, the
following requirements must be met:
- Create an ORACLE password file:
orapwd file=/dbs/orapw
password= entries=100
Create softlinks to this file for all other database instances:
cd /dbs
ln -s orapw orapw
- The parameter remote_login_passwordfile =
exclusive must be entered in all the init.ora
profiles or in a common Include file (which is then linked into
all the profiles with the IFILE parameter). If the parameter
was only entered after an instance(s) was started, the
corresponding instances should be started so that it takes effect.
- User system must have SYSOPER (SYSDBA)
authorization on the DDB instance. Start SQLDBA as user
internal and perform the following ORACLE command:
sqldba> grant sysoper to system;
- It might be necessary to change the password for
user system:
sqldba> alter user system identified by ;

-------------------------------------------------------------
2.) Parallel Server Configuration for Using SAPDBA

SAPDBA should normally only be started from the DDB instance. In
exceptions (for example when looking for freespace in local
archiving directories), SAPDBA can also be started from another
instance.
Please read the information about setting up user system (in Topic 1).
User system has the authorization to start and stop
the database instances remotely. You can therefore
call SAPDBA in the usual manner.
The following functions were extended or introduced especially for
databases with OPS configuration:
* Startup/Shutdown instance, to start/stop single instances or all
instances.
* Instance information, to obtain status information about the
individual instances.
* Archive mode, to obtain information about archiving for the local
instance or for any parallel instance or to set the archiving
parameters.

Recovery measures on an OPS database should only be
performed by an experienced administrator. It is essential
that you read the ORACLE documentation. The
restore/recovery functionality of SAPDBA is only available
with some restrictions. (See topic "Special Features during
Restore/Recovery").

------------------------------------------------------------------------
Information in the init.dba Profile

There are a number of OPS-specific parameters in the
init.dba profile. These are:
* ops, to set the working mode of SAPDBA
specifically for the OPS
* parallel_instance, to define the parallel instances

There are also some parameters for special purposes, but these
should only be used by an experienced administrator.
* index_instances, to create indices on the individual
instances in parallel
* recovery_instances, to perform recoveries on the
individual instances in parallel

SAPDBA can also call the SAP utilities BRBACKUP, BRARCHIVE
and BRRESTORE. The init.sap profile for these
programs also contains a number of OPS-specific
parameters (see topic Information in the Profile
init.sap).

------------------------------------------------------------
Special Features during Restore/Recovery

SAPDBA will only provide restricted support of Release 3.0C in
order to be able to recover the OPS database as fast as possible in
a recovery situation. Due to the complex installation (for possible
scenarios see topic "Special Features of BRARCHIVE), there can
be no general recommendation. Due to its syntax,
the BRRESTORE program permits you to manually restore
the files which are relevant for the recovery (for example,
specification of the name of the parallel instance).
SAPDBA helps you to obtain the necessary information
about the status of the database system (also in mount status).
In special cases, individual objects can be
restored using SAPDBA.

Information about the Redo Log Files of the Individual Threads

* Use the SAPDBA menu option Archive mode -> Show all
archive information/Show complete archive history.
* Check (and repair) database -> Check database : If this check
finds that some files have an old status, SAPDBA displays the
redo log files of the different threads necessary for a recovery.

Support in Case of File Loss

1.) If SAPDBA finds that some files are missing with Check (and
repair) database -> Check database, these must be restored. If
only links were lost, SAPDBA tries to reconstruct them.
2.) The missing files can then be restored from a backup copy with
Check (and repair) database -> Restore backup files. The
subsequent actions, such as automatic restoring of the
corresponding offline redo log files, are not yet supported.
3.) If you start Check (and repair) database -> Check database
again, SAPDBA displays the redo log files of the different
threads necessary for a recovery.
4.) These redo log files can now be restored manually with
BRRESTORE.
5.) Now start the recovery with SQLDBA (sqldba> recover
database...). Read about this in the corresponding ORACLE
documentation.

Support when Restoring a Full Backup or Single Files

* The SAPDBA option Restore/Recovery -> Full restore is
completely supported, also for an OPS installation. See
Resetting the Databasesora10e.doc016>howto.
* The SAPDBA option Restore/Recovery -> Full restore and
recovery is not yet supported. If you want to perform for
example a point in time recovery, you should perform the
necessary preparations for the subsequent recovery with
Restore/Recovery -> Full restore -> Restore database and
startup mount (for manual recovery (using backup controlfile).
Then start the recovery with SQLDBA (sqldba> recover
database until using backup controlfile).
Read the corresponding ORACLE documentation. In this case,
you would yourself have to perform the necessary safety control
measures (for example, whether there was a change in the
structure of the database in the meantime). Use the information
in the master log and in the structure log.
* Single Objects (for example also archived redo log files) can be
restored with Restore/Recovery -> Restore individual files.

Note the following restriction: You can only use SAPDBA to
automatically restore the offline redo log files belonging to the
thread of the local instance for which SAPDBA was started. It is
essential that you check whether it is sufficient for your recovery
situation. Also read the comments about the scenarios in topic
"Special Features of BRARCHIVE".

---------------------------------------------------------------
3.) Parallel Server Configuration when Using BRBACKUP, BRARCHIVE
and BRRESTORE

BRBACKUP and BRRESTORE are normally started in the DDB
instance only, as well as BRARCHIVE in the case of the central
scenario. The following requirements must be fulfilled:
* Read the general remarks in topic "ORACLE Databases
and Parallel Server Option: Overview".
* The necessary executables (br*) must exist on the DDB instance
host in directory /usr/sap//SYS/exe/run.
* The init.ora profiles for the individual instances
(init.ora for all instances) must exist on the DDB
instance host in directory /dbs.
Make sure that the profiles of all instances are actually stored in
the directory of the DDB instance. All profile files that may have
been included using the parameter IFILE must also exist there.
BRBACKUP/BRARCHIVE save all profiles as a cpio archive file.
* The backup devices (tape units or hard disks) are normally
connected locally to the DDB instance host.
* If you have read the remarks in topic 1 "ORACLE Databases
and Parallel Server Option: Overview", user system now has
the authorization to start and stop the database
instances remotely. You can therefore call BRBACKUP and
BRARCHIVE in the usual manner, for example
brbackup/brarchive -u system/...

BRBACKUP, BRARCHIVE and BRRESTORE can manage up to
255 parallel instances.

-----------------------------------------------------------------------
Information in the Profile init.sap

* dd_flags, dd_in_flags
A requirement for using the Parallel Server option is that the
database is installed on raw devices. The backup then runs via
the dd command. Therefore make sure that the
parameters dd_flags and dd_in_flags, which specify the required
dd command, are set.
* parallel_instances
This parameter defines the instances running in parallel to the
DDB instance. The local (DDB) instance must not appear in the list of
instance descriptions.
* archive_copy_dir
A BRARCHIVE archivation on the hard disk is required when
archiving according to the mixed scenario.

------------------------------------------------------------------
Special Features of BRBACKUP

The parameter parallel_instances must be set in the
init.sap profile used by BRBACKUP in order that
BRBACKUP be able to access all the ORACLE instances.
The backup of a database with the Parallel Server configuration
using the SAP utility BRBACKUP runs as follows:
1. All ORACLE instances which are stopped are restarted in
parallel by BRBACKUP with the appropriate SQLDBA
commands.
2. BRBACKUP logs on to the local (DDB) instance and carries out
the common actions in the database (determination of the
database structure, the volumes used ...).
3. If an offline backup is to be carried out, all instances are
stopped. In all other cases, they continue running during the
backup.
4. The required backup is started.
5. If an offline backup was carried out, all database instances are
restarted in parallel at the end of the backup.
6. BRBACKUP updates the tables SDBAH and SDBAD.
7. The status of all instances before the start of the backup with
BRBACKUP is recovered. That is, the instances which were
stopped before the backup are now stopped again.
During the entire backup, BRCONNECT monitors all database
instances and checks them constantly to see that the required status
of the instances stays unchanged. If the status of an instance
changes during the backup, BRCONNECT interrupts the entire
backup.
In the BRBACKUP log, both before and after the actual backup, a
log is made of the parameters relevant to the online redo log files
that are being archived for all database instances in question (output
of the ARCHIVE LOG LIST command).
If you run an offline backup of the entire database, a file of all
online redo log groups for the ORACLE instances is saved in each case.
The functionality of BRBACKUP is available (in particular, the
support of software and hardware compression) with one exception
concerning the dd command: when using the dd command, there is
no continuation mechanism.

-------------------------------------------------------------------
Special Features of BRARCHIVE

There are three ways to archive the offline redo log files using BRARCHIVE in the case of a Parallel Server configuration of the database:
1. Distributed Scenario
2. Central Scenario
3. Mixed Scenario

Normally the SAP System is installed so that the mixed
scenario is used for archiving for a Parallel Server
configuration. SAP recommends this scenario for archiving
the offline redo log files in production systems.
The distributed and especially the central scenario should
only be used with some restrictions and then only for test
systems.

Offline redo log files of different instances can be stored in a
local archiving directory of an instance. This can occur if the
online redo log files of instance X were not saved in the
archiving directory for a long time (either the instance is
closed or it is open but not active. Therefore a redo log file
change is not forced and thus ORACLE archivation is not
activated). One of the "active" instances notices this status
and ensures that the current online redo log file of instance X
is saved in its own archiving directory.
Parameter parallel_instances must therefore be set
in the init.sap profiles used by BRARCHIVE
in all three scenarios, so that BRARCHIVE can find
and archive the offline redo log files of the other
ORACLE instances.

------------------------------------------------------------------
Distributed Scenario

Each ORACLE instance has its own local archive directory. This
directory should not reside on a mounted disk.
BRARCHIVE is started locally on the hosts of all ORACLE instances.
In this case, BRARCHIVE works similarly to a configuration without
the Parallel Server option. In each case, BRARCHIVE saves the
offline redo log files of the local instance. BRARCHIVE can
determine these by means of the thread number
(init.ora parameter thread), which is allocated to
every local instance.
If offline redo log files of other instances occur in the local
archiving directory, BRARCHIVE also archives these.
Every ORACLE instance has its own volume management controlled by BRARCHIVE. The offline redo log files which were found in the local archiving directory of the corresponding instance are saved on every tape (in exceptions these can be offline redo log files of different instances). The assignment of the offline redo log files to the individual instances can be seen in the file names. The name conventions are defined by the init.ora parameters log_archive_dest and log_archive_format.

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.
The offline redo log files can be archived either to local tape units
(connected to the host of the instance, backup_dev_type =
tape) or to tape units connected to the host of the DDB
(backup_dev_type = pipe).

Advantages
* The use of BRARCHIVE in this case is similar to its use during a
non-OPS configuration.

Disadvantages
* Free disk space must be made available on all instance hosts,
so that a local ORACLE backup can be made of the offline redo
log files in the archiving directory.
* BRARCHIVE must be started once per ORACLE instance.
* For every instance, a separate BRARCHIVE volume pool must
be managed.
* SAP does not recommend this scenario.

The use of BRARCHIVE in the distributed scenario is useful if a
large number of offline redo log files are created on every ORACLE
instance, which would nearly fill a volume (tape).

Further Remarks
The offline redo log files are required if the database has to be
recovered. Recovery measures should only be performed 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 are to be restored:
The required offline redo log files must be restored separately on
each instance (using SAPDBA or a BRRESTORE call). The offline
redo log files must then be copied to the archiving directory of the
instance from which the database system recovery is to be started.
Then start the recovery (information about this can be found in the
ORACLE documentation and in topic "SAPDBA Special Features during
Restore/Recovery").

------------------------------------
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 consequently archiving through the
must not take place) 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.

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 and in topic "SAPDBA Special Features during
Restore/Recovery".

------------------------------------
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.

Example: Name of the SAP systems: 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:
1. Step - 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.

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

2. Step - 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 and in topic "SAPDBA- Special Features
during Restore/Recovery".

--------------------------------------------------------------------
Special Features of BRRESTORE

BRRESTORE uses the dd command to restore files that were saved on a volume (tape, hard disk,...) with this command. You should therefore make sure that the init.sap parameter dd_in_flags is set accordingly.

BRRESTORE for Restoring Database Files

There are no special features of BRRESTORE concerning the
functionality of the utility programs.

BRRESTORE for Restoring the Archived Offline Redo Log Files

* Distributed Scenario: BRRESTORE must be started on every
ORACLE instance in order to restore the corresponding archived
redo log files into the local archiving directory. If required, the
restored redo log files can be copied onto the DDB instance
using operating system resources or be made available via
several NFS-mounts. (This is necessary, for example, if a
SQLDBA recovery session is to be started, which is normally
done on the DDB instance). See also "Further Remarks " in
topic "Distributed Scenario".
* Central and Mixed Scenario: The required archived redo log
files of all ORACLE instances can be restored with one
BRRESTORE call. To do this, the syntax of BRRESTORE was
extended with the options -a|-a1|-a2 to specify the instance
ID . See -a|-archive|a1|archive1sora35e.doc038>howto
or -a2|-archive2sora35e.doc039>howto. See also "Further
Remarks " in topic "Central Scenario" and "Mixed Scenario".

Example:
brrestore -a 110-120,C11_002,70-80,C11_003,85-95
The archived offline redo log files with log sequence numbers
110-120 of the local ORACLE instance, those with log
sequence numbers 70-80 of ORACLE instance C11_002 and
those with log sequence numbers 85-95 of instance C11_003
are restored.