QR Disaster Recovery Solution for Building a Windows Standby Oracle Server


Overview

Configuration

Bring the Standby Server online


Overview

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.


Configuration

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.

Prepare the Production Server

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

  1. If the Production Server is not already installed with Oracle, install the desired version of Oracle and apply any required patches.
  2. Create the required Oracle database.
    NOTE: When creating the instances or when installing Oracle, record your Oracle database configuration and storage locations so that Oracle can be installed identically on the Standby Server.
  3. Install the QR Agent, Oracle iDataAgent, and MediaAgent. If the installation detects that you have not already installed the File System iDataAgent prior to installing the QR Agent, you will be prompted to install it.

Prepare the Standby Server

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.

  1. Set up the Oracle instance with the same instance name and configuration as that of the Production Server:
    1. Verify the required directories (admin, cdump, bdump, udump, and pfile) for the instance in the Standby Server match the Production Server.
      (Example location: %Install Dir%\admin\%ORACLE_SID\cdump)
    2. Oracle database may be using spfile or init file for storing the initialization parameters. Copy the init\spfile (init<ORACLE_SID>.ora or spfile<ORACLE_SID>) from the Production Server to the Standby Server.
      (Example location of these files: %Install Dir%\database)
    3. Copy the password file (example: orapw<ORACLE_SID>) of the instance from the Production Server to the Standby Server.
      (Example location of this file: %Install Dir%\database)
    4. On the Production Server, note the name and location of each control file. This step is required to copy back the backup control file to each control file location when bringing up the Standby Serve.
      Example:
      %Install Dir%\cv_control\control01.ctl
      %Install Dir%\cv_control\control02.ctl
      %Install Dir%\cv_control\control03.ctl

    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.

  2. Install the MediaAgent and Quick Recovery Agent software on the Standby Server. If the installation detects that you have not already installed the File System iDataAgent prior to installing the QR Agent, you will be prompted to install it.
  3. Use Volume Explorer to configure all volumes you are planning to use in the Volume Scratch Pool on the Standby Server.

Configure the Quick Recovery Agent

  1. Configure the scratch volume pool. The scratch volume pool for this recovery scenario should consist only of the disk resources attached to the Standby Server. These volumes must have the same mount point as the source volumes on the Production Server. The QR volumes and incremental updates will be written to these volumes.
  2. Create a QR Policy. Select the LAN Copy Manager (LANVolCopy) on the Standby Server as the copy manager, and associate this QR Policy with the scratch volume pool that was created in the previous step. Multiple QR Policies may be associated with a given scratch volume pool.
  3. Select the Authentication tab in the QR Agent Properties dialog box and add the Oracle instance.
  4. Create the QR Agent subclient(s) on the Production Server. Please note the following:
  5. Schedule the QR Volume creation job. In this particular scenario, incremental updates should be selected. Please note that we do not support archive logs backup with the Standby Server. The QR incremental updates already take care of archive logs that were created after the last QR update.

    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.


Bring the Standby Server online

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.

  1. Shut down the Production Server and/or remove it completely from the network.
  2. Rename the Standby Server to match the name of the Production Server that has been removed from the network. (Please refer to Windows user documentation for renaming the machine.) If necessary, change the IP Address to match the one on the Production Server. Add the Standby Server to the network, and configure any other applicable network settings.

    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.

  3. There is a backup.ctl.galaxy (Backup Controlfile) file located in one of the archive log destinations of the instance on the Standby Server. (Example location: \ora_logs\admin\sid\arch)

    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)

  4. Start the database in the mount mode after connecting as the sysdba user (Example: sys/password as sysdba):

    SQL> startup mount

  5. Recover the database as follows:

    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.

Back to Top