Oracle7 Server Administrator's Guide

Contents Index Home Previous Next

Preparing for Disaster Recovery

This section describes how to plan for and implement disaster recovery procedures for your primary database, and includes the following topics:

Planning and Creating a Standby Database

A standby database maintains a duplicate, or standby copy of your primary (also known as production) database and provides continued primary database availability in the event of a disaster (when all media is destroyed at your production site). A standby database is constantly in recovery mode. If a disaster occurs, you can take the standby database out of recovery mode and activate it for online use. A standby database is intended only for recovery of the primary database; you cannot query or open it for any purpose other than to activate disaster recovery. Once you activate your standby database, you cannot return it to standby recovery mode unless you re-create it as another standby database.

Warning: Activating a standby database resets the online logs of the standby database. Hence, after activation, the logs from your standby database and production database are incompatible.

You must place the data files, log files, and control files of your primary and standby databases on separate physical media. Therefore, it is impossible to use the same control file for both your primary and standby databases.

Creating a Standby Database

This section lists the steps and rules to follow when creating a standby database.

To Create a Standby Database

1. Back up (either online or offline) the data files from your primary database.

2. Create the control file for your standby database by issuing the ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'filename' command, which creates a modified copy of the primary database's control file.

3. Archive the current online logs of the primary database by issuing the ALTER SYSTEM ARCHIVE LOG CURRENT command. Issuing the ALTER SYSTEM ARCHIVE LOG CURRENT command also ensures consistency among the data files in step 1, the control file in step 2, and the log files.

4. Transfer the standby database control file, archived log files, and backed up data files to the remote (standby) site using operating system commands or utilities. Use an appropriate method if transferring binary files.

Warning: Oracle encourages you to use a datafile naming scheme that keeps the datafile names the same at both the primary and standby databases. If this is not possible, then you can use the datafile name conversion parameters. If you do not use either of these suggested datafile naming schemes, you may end up crashing your standby database.

See Also: For information about setting name conversion parameters when you create your standby database, see "Converting Data File and Log File Names."

Maintaining a Standby Database

This section provides the tasks for maintaining your standby database, including information about clearing standby logfiles.

To Maintain Your Standby Database in Recovery Mode

1. Start up the Oracle instance at the standby database using the NO MOUNT clause.

2. Issue the ALTER DATABASE MOUNT STANDBY DATABASE [EXCLUSIVE / PARALLEL] command.

3. Transfer the archived redo logs from the primary database to the remote (standby) site. Use an appropriate operating system utility for transferring binary data.

4. Place the standby database in recovery mode by issuing the RECOVER [FROM 'location'] STANDBY DATABASE command.

Note: As the archived logs are generated, you must continually transfer and apply them to the standby database. Also, you can only apply logs that have been archived at the primary database to the standby database.

Clearing Online Logfiles You can clear standby database online logfiles to optimize performance as you maintain your standby database. If you prefer not to perform this operation during maintenance, the online logfiles will be cleared automatically during activation. You can clear logfiles using the following statement:

ALTER DATABASE CLEAR LOGFILE GROUP integer;

Converting Data File and Log File Names

You can set the following initialization parameters so that all filenames from your primary database control file are converted for use by your standby database:

If your primary and standby databases exist on the same machine (of course, they should not, but if they are), setting these parameters is advisable, because they allow you to make your standby database filenames distinguishable from your primary database filenames.

The DB_FILE_STANDBY_NAME_CONVERT and LOG_FILE_STANDBY_NAME_CONVERT parameters must have two strings. The first string is a sequence of characters to be looked for in a primary database filename. If that sequence of characters is matched, it is replaced by the second string to construct the standby database filename.

Figure 24 - 1 shows how the filename conversion parameters work:

Figure 24 - 1. Setting Filename Conversion Parameters

Note: If you perform a data file (or log file) RENAME at the standby database, or use the AS clause with the ALTER DATABASE CREATE FILE command, then the conversion parameters will not apply to that file.

Activating a Standby Database

In the event of a disaster, you should (if possible) archive your primary database logs (ALTER SYSTEM ARCHIVE LOG CURRENT), transfer them to your standby site, and apply them before activating your standby database. This makes your standby database current to the same point in time as your primary database (before the failure). If you cannot archive your current online logs, then you must activate the standby database without recovering the transactions from the unarchived logs of the primary database.

After you activate your standby database, its online redo logs are reset. Note that this makes the logs from the standby database and primary database incompatible. Also, the standby database is dismounted when activated, therefore, you are unable to look at tables and views immediately after activation.

To Activate a Standby Database

1. Ensure that your standby database is mounted in EXCLUSIVE mode.

2. Issue the ALTER DATABASE ACTIVATE STANDBY DATABASE command.

3. Shut down your standby instances.

4. As soon as possible, back up your new production database. At this point, the former standby database is now your production database. This task, while not required, is a recommended safety measure, because you cannot recover changes made after activation without a backup.

5. Startup the new production instance.

Note: After you activate your standby database, all transactions from unarchived logs at your original production database are lost.

Altering the Physical Structure of the Primary Database

Altering the physical structure of your primary database can have an impact on your standby database. The following sections describe the effects of primary database structural alterations on a standby database.

Adding Data Files

Adding a data file to your primary database generates redo information that, when applied at your standby database, automatically adds the data file name to the standby control file. If the standby database locates the new file with the new filename, the recovery process continues. If the standby database is unable to locate the new data file, the recovery process will stop.

If the recovery process stops, then perform either of the following procedures before resuming the standby database recovery process:

If you don't want the new data file in the standby database, you can take it offline using the DROP option.

See Also: For more information on offline data file alterations, see "Taking Data Files in the Standby Database Offline" [*].

Renaming Files

Data file renames on your primary database do not take effect at the standby database until the standby database control file is refreshed. If you want the data files at your primary and standby databases to remain in sync when you rename primary database data files, then perform analogous operations on the standby database.

Altering Log Files

You can add log file groups or members to the primary database without affecting your standby database. Likewise, you can drop log file groups or members from the primary database without affecting your standby database. Similarly, enabling and disabling of threads at the primary database has no effect on the standby database.

You may want to keep the online log file configuration the same at the primary and standby databases. If so, when you enable a log file thread with the ALTER DATABASE ENABLE THREAD at the primary database, you should create a new control file for your standby database before activating it. See "Refreshing the Standby Database Control File" [*] for refresh procedures.

If you clear log files at the primary database by issuing the ALTER DATABASE CLEAR UNARCHIVED LOGFILE command, or open the primary database using the RESETLOGS option, you invalidate the standby database. Because the standby database recovery process will not have the archived logs it requires to continue, you will need to re-create the standby database.

Altering Control Files

If you use the CREATE CONTROLFILE command at the primary database to perform any of the following, you may invalidate the standby database's control file:

If you've invalidated the standby database's control file, you must re-create it using the procedures in "Refreshing the Standby Database Control File" [*].

Using the CREATE CONTROLFILE command with the RESETLOGS option on your primary database will force the next open of the primary database to reset the online logs, thereby invalidating the standby database.

Configuring Initialization Parameters

Most initialization parameters at your primary and standby databases should be identical. Specific initialization parameters such as CONTROL_FILES and DB_FILE_STANDBY_NAME_CONVERT should be changed. Differences in other initialization parameters may cause performance degradation at the standby database, and in some cases, bring standby database operations to a halt.

The following initialization parameters play a key role in the standby database recovery process:

See Also: For more information on initialization parameters, see the Oracle7 Server Reference.

Taking Data Files in the Standby Database Offline

You can take standby database datafiles offline as a means to support a subset of your primary database's datafiles. For example, you decide it is undesirable to recover the primary database's temporary tablespaces on the standby database. So you take the datafiles offline using the ALTER DATABASE DATAFILE 'fn' OFFLINE DROP command on the standby database. If you do this, then the tablespace containing the offline files must be dropped after opening the standby database.

Performing Direct Path Operations

When you perform a direct load originating from either direct path load, table create via subquery, or index create on the primary database, the performance improvement applies only to the primary database; there is no corresponding recovery process performance improvement on the standby database. The standby database recovery process still sequentially reads and applies the redo information generated by the unrecoverable direct load.

Primary database processes using the UNRECOVERABLE option are not propagated to the standby database. Why? Because these processes do not appear in the archived redo logs. If you want to propagate such processes to your standby database, perform any one of the following tasks.

To Propagate UNRECOVERABLE Processes to a Standby Database

1. Take the affected datafiles offline in the standby database, and drop the tablespace after activation.

2. Re-create the standby database from a new database backup.

3. Back up the affected tablespace and archive the current logs in the primary database. Transfer the datafiles to the standby database. Then resume standby recovery. This is the same procedure that you would perform to guarantee ordinary database recoverability after an UNRECOVERABLE operation.

If you perform an unrecoverable operation at the primary database, and attempt to recover at the standby database, you will not receive error messages during recovery. Such error messages appear in the standby database alert log. Thus, you should check the standby database alert log periodically.

See Also: For more details, see "Taking Datafiles in the Standby Database Offline" [*].

Refreshing the Standby Database Control File

The following steps describe how to refresh, or create a copy of changes you've made to the primary database control file.

To Refresh the Standby Database Control File

1. Issue the CANCEL command on the standby database to halt its recovery process.

2. Shut down the standby instances.

3. Issue the ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'filename' statement on the primary database to create the control file for the standby database.

4. Issue the ALTER SYSTEM ARCHIVE LOG CURRENT statement on the primary database to archive the current online logs of your primary database.

5. Transfer the standby control file and archived log files to the standby site.

6. Restart and mount (but do not open) the standby database by issuing the ALTER DATABASE MOUNT STANDBY DATABASE [EXCLUSIVE/PARALLEL] statement.

7. Restart the recovery process on the standby database by issuing the RECOVER [FROM 'location'] STANDBY DATABASE statement.

Contents Index Home Previous Next