How to set up a standby database
(Oracle 8i/9i - Solaris/Mac OS X).
Note: More specific information is contained within
file#39
which is created during the file generation process. File#39
contains the actual file names of the scripts which have been custom-generated
for a particular database instance.
1) Open the Installgen application and fill in the database
parameters as would be done to create any new database. It is important
for the Standby SID to be different from the primary database SID in
order for the databases to be accessed via different tnsnames.ora entries.
2) If a media manager is being used for RMAN backups,
the standby server will need access to the tape drive through the media
manager software. The RMAN
Channel type field is used for the media manager device specifier.
Otherwise, the backup location on each server will need to be large
enough to store a full database backup of the primary database.
3) Press the Generate button to create the installation
scripts.
4) Change the IP Address, and hostname parameters, but
leave the tablespaces and pathnames the same. Save this configuration
for the standby database, then generate a set of scripts which will
be used for installing the Oracle software and building an instance
on the standby server. The standby server must use the same Oracle version,
patchlevel, OS and directory structure as the primary database. Edit
the scripts if needed to change the default patchlevel which will be
installed. Use the scripts generated for the standby databse to create
an instance on the standby server and apply the latest patchset to the
instance. This instance will be replaced during the creation of the
standby instance - it is only created in order to install and patch
the software. The remainder of these instructions make use of the first
set of scripts which were created with info for the primary database.
5) The following files are used for the standby database
setup after Oracle software has been installed and patched on the standby
server:
File#77
File#78
File#79
File#80
File#70
File#71
File#72
File#75
File#49
File#74
File#76
File#81
File#73
File#10
File#11
File#46
File#86
File#28
File#88
File#89
(It is generally recommended that all of the generated
files be copied to the primary
server in case they are needed.)
6) Run the File#77
Perl script on the primary server. Follow the prompts.
7) You will be prompted to copy File#78
to the user_unix_path directory on the standby server. Run the File#78
Perl script, and follow the prompts.
8) An RMAN backup will be done on the primary server,
if requested. RMAN will limit its I/O consumption to a rate of 1500K
per second in order to allow the backup to be performed with the primary
database operating in production mode. This parameter can be modified
within script File#77 if necessary. The primary server's init.ora parameters
are modified dynamically without bouncing the instance.
9) Once the RMAN backup has completed, the configuration,
standby controlfile, backup and archived redo log files are copied to
the standby server via a network share. This shared folder on the standby
server needs to correspond to the directory where RMAN backed up the
primary database - unless a media manager was used to back the database
directly to tape.
10) On the standby server, the archived redo log files
will be copied to the short_archivelog_location directory so that they
will be available for the RMAN duplicate standby database process. The
primary and standby versions of the tnsnames.ora, listener.ora and other
configuration files will be copied into the appropriate locations. The
File#81
script will be installed on the standby server.
The File#81 script renames the Oracle Alert log for the instance every
time the server is restarted. This task is done during system startup
because the file is in use while the database is running.
The File#81 script automatically starts up the standby instance in managed
recovery mode every time the server is restarted.
The OracleStandbyStartupStandbySID.log file is written to the short_scripts_directory
directory each time the File#81 script runs.
11) The standby server is started in nomount mode in preparation
for the RMAN duplicate standby database procedure.
12) RMAN is run on the primary server via an auxiliary
channel with a connection to the standby server. RMAN creates standby
controlfiles on the standby server with the same names and locations
as the primary server. RMAN then creates datafiles with the same names
and paths as the tablespaces in the primary database. RMAN then applies
all of the archivelog files up to the point in time when the standby
controlfile was created.
Note: If RMAN fails with an ORA-6025 error, the File#80 Perl program
may be used to copy and apply missed archivelog files from the primary
server to the standby server.
13) The standby server instance is then started in managed
recovery mode.
14) During the standby server setup process the File#13
script will be configured to run via a CRON job at 11:55PM. This script
removes old logfiles, archivelog and backup files to prevent the disk
from filling up. (Since the standby database is identical to the primary
database, it may be configured for RMAN backups to reduce the impact
on the primary database. RMAN backups done in this manner must use the
controlfile to store backup information without using an RMAN repository
within an OEM/OMS server.)
15) Install the File#72
file as tnsnames.ora on each client computer which will be connecting
to the primary database. This tnsnames.ora file is configured with transparent
application failover to allow the client to automatically attempt to
connect to the standby database if the primary database has failed.
16) Use the renamed_File#80 perl script to manage the
standby configuration.
The renamed_File#80 perl script provides the following features:
primary to standby switchover
primary to standby failover
standby switchover to primary
standby failover to primary
standby to read-only
read-only to standby
