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 concept. 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). NOTE: 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 DATABASE ; -m|-modify 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. NOTE: 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 ALTER DATABASE CREATE DATAFILE ‘<file_name>‘; BRARCHIVE can then be started again. Standby Database: Backup with BRBACKUP: Use 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. Prerequisites 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. Features 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 commands STARTUP NOMOUNT, ALTER DATABASE MOUNT STANDBY DATABASE). Activities 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 ). primary_db 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 NOTE: As for the OPS configuration, certain requirements must be satisfied for the connection to a remote host. Structure-Retaining Database Copy: Use 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. Prerequisites 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 /oracle/c12/sapdata2/stabd_1/stabd.data1 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). -m|-mode: Input syntax: -m all|<tablespace_name>|all_data|incr|full|<file_ID>|<file_ID1>- <file_ID2>|<generic_path>|<object_list>|sap_dir|ora_dir 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 parameter new_db_home 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 blanks!). 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. backup_mode 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.