Bring the Standby Server online
This document describes the procedure necessary to create a Standby Exchange Server in the event that a Production Exchange Server is temporarily or permanently damaged. These procedures are for an environment with at least two servers, a Production Server, which runs the Oracle Database, and a Standby Server.
QR Agent takes a snapshot of the running instance. All tablespaces of the database are put in backup mode before taking the snapshot (Point-In-Time-Image) of the data partitions; as soon as the snapshot is taken, all the tablespaces are put back in open mode, then, after archiving the online redo logs, a snapshot of the archive log partition(s) is taken. This ensures that any transactions happening during the backup mode of the tablespaces are archived. This archived redo logs can be used for later Quick Recovery.
The Production Server contains the source (Primary) volumes, which are copied and updated incrementally via the LAN Copy Manager to QR Volumes on the Standby Server. The data is therefore physically ready to use (no lengthy recovery from tape or other media is necessary) on the Standby Server. The Standby Server should have the same version of the Operating system and the same version of Oracle installed on the same path as in the Production Server.
In cases where the Production Server suffers a failure, or requires downtime, the system administrator can remove the Production Server from the network and then add the Standby Server to the network (with the same name and configuration as the disconnected Production Server).
The key to a successful QR Agent recovery is properly configuring the Production and Standby Servers. This ensures that the database(s) can quickly and easily be run from the QR volumes on the Standby Server.
This procedure is written for bringing up one instance on the Standby Server. If multiple instances are present on one client we strongly recommend creating a separate subclient for each instance and following the same procedure for each instance individually.
The following sections discuss preparing the Production and Standby Servers as well as configuring the QR Agent. The basic workflow is described below. For detailed instructions on installation and configuration options, see Quick Recovery Agent.
The Quick Recovery Agent supports Oracle 9.2 and Oracle 10g. The database must be in “archive log mode” for QR Volume Creation. We recommend that data files, archive logs, control files, and online redo logs each reside on different partitions (different mount points), and that none of these four types of files reside on a partition with any of the others.
Following is a sample configuration of an Oracle 9.2 installation on a Windows 2000 machine, which has running an Oracle instance, “CV”. Oracle requires that the Standby database to be on the same OS level as that on the Production Server.
Mount Point | Description |
V:\oracle92 | Contains the Oracle 9.2 installed binaries |
V:\oracle92 | Is the ORACLE_HOME of instance CV |
W:\cv_data | Contains all the data files of instance CV |
X:\cv_archlog | Contains all the archived logs of instance CV |
Y:\cv_control | Contains current control file of instance CV |
Z:\cv_redologs | Contains online redo logs of instance CV |
The redo logs and control files are not backed up since they are constantly changing. In order to take a consistent control file backup, Oracle provides specific commands to back up online control files. It is strongly recommended to have each database's data and archived logs on different volumes exclusively for each instance. (Example: W:\cv_data or X:\cv_archlog is exclusively for instance CV. It should not have data or archive logs of any other instance running on that machine).
Before installing any software on the Standby Server, consider the following:
Install the same version of Oracle as is installed on the Production Server. You must have the same Oracle user ID, Oracle group ID, and the same installation path of Oracle as the Production Server.
NOTE: It is very important to follow Step 1 precisely. These files are used for bringing up the database on the Standby Server in the event the Production Server goes down. Failure to properly configure the Standby Server will result in not being able to bring up the Standby Server successfully.
From the QR Volume Creation Advanced Options dialog box, assign each volume on the Production Server to its corresponding destination volume on the Standby Server. The mount path of each standby volume must be same as its counterpart production volume.
In cases where the Production Server suffers a failure, or requires downtime, the Standby Server can quickly be brought on-line to host the database from the QR Volumes you have created. The following steps must be taken to add the Standby Server into the network.
After bringing up the Standby Server, verify that the destination volumes are mounted. These are the volumes that were present in the scratch volume pool while creating QR volumes. Also verify Oracle user is an owner of all mount points, directories and files. If necessary change the ownership to the appropriate Oracle user and group; otherwise your instance might fail to access the files.
NOTE: Do not try to detect volumes in Volume Explorer on either the Production or the Standby Server at this time. The Oracle recovery procedure is manual, and is not accomplished with Volume Explorer, the QR Agent, or the Oracle iDataAgent.
Copy the
backup.ctl.galaxy file to all the control
file location as in “Prepare the Standby Server”.
Example:
copy backup.ctl.galaxy Y:\cv_control\control01.ctl
copy backup.ctl.galaxy Y:\cv_control\control02.ctl
copy backup.ctl.galaxy Y:\cv_control\control03.ctl
NOTE: Before proceeding to Step 4, set up the Oracle environment (such as
ORACLE_HOME and ORACLE_SID)
on the destination machine to match that of the Production Server.
(Example: export ORACLE_HOME=/oracle901 and
ORACLE_SID=CV)
SQL> startup mount
SQL> set autorecovery on
SQL> recover database until cancel using backup controlfile;
SQL> alter database open resetlogs;
After the successful completion of Step 5, the database is in OPEN mode and ready
to use.
NOTES:
If you receive any messages that files cannot be accessed or access is denied during the startup process, check again that you have mounted all volumes, copied the files and set the ownership to Oracle user.