In a multiple standby database configuration, you cannot assume that the database administrator (DBA) who set up the multiple standby database configuration is available to decide which standby database to fail over to in the event of a disaster. Therefore, it is imperative to have a disaster recovery plan at each standby site, as well as at the primary site. Each member of the disaster recovery team needs to know about the disaster recovery plan and be aware of the procedures to follow.
Example E-1 shows the kind of information that the person who is making the decision would need when deciding which standby database should be the target of the failover operation.
A ReadMe file is created and maintained by the DBA and should describe how to:
Example E-1 Sample Disaster Recovery ReadMe File
----------------Standby Database Disaster Recovery ReadMe File----------------
Warning:
********************************************************************************
Perform the steps in this procedure only if you are responsible for failing over
to a standby database after the primary database fails.
If you perform the steps outlined in this file unnecessarily, you might corrupt
the entire database system.
********************************************************************************
Multiple Standby Database Configuration:
No. Location Type IP Address
--- --------------- --------- --------------
1 San Francisco Primary 128.1.124.25
2 San Francisco Standby 128.1.124.157
3 Boston Standby 136.132.1.55
4 Los Angeles Standby 145.23.82.16
5 San Francisco Standby 128.1.135.24
You are in system No. 3, which is located in Boston.
Perform the following steps to fail over to the most up-to-date and available
standby database:
1. Log on to the local standby database as a DBA.
a) Log on with the following user name and password:
username: Standby3
password: zkc722Khn
b) Invoke SQL*Plus as follows:
% sqlplus
c) Connect as the DBA as follows:
CONNECT sys/s23LsdIc AS SYSDBA
2. Connect to as many remote systems as possible. You can connect to a maximum
of four systems. System 4 does not have a firewall, so you can connect to it
directly. Systems 1, 2, and 5 share the same firewall host. You need to go
to the firewall host first and then connect to each system. The IP address
for the firewall host is 128.1.1.100. Use the following user name and
password:
username: Disaster
password: 82lhsIW32
3. Log on to as many remote systems as possible with the following user names
and passwords:
Login information:
No. Location IP Address username password
--- --------------- ------------- ---------- ----------
1 San Francisco 128.1.124.25 Oracle9i sdd290Ec
2 San Francisco 128.1.124.157 Standby2 ei23nJHb
3 (L o c a l)
4 Los Angeles 145.23.82.16 Standby4 23HHoe2a
5 San Francisco 128.1.135.24 Standby5 snc#$dnc
4. Invoke SQL*Plus on each remote system you are able to log on to as follows:
% sqlplus
5. Connect to each remote database as follows:
CONNECT sys/password AS SYSDBA
The DBA passwords for each location are:
No. Location Password
--- --------------- -----------
1 San Francisco x2dwlsd91
2 San Francisco a239s1DAq
3 (L o c a l)
4 Los Angeles owKL(@as23
5 San Francisco sad_KS13x
6. If you are able to log on to System 1, invoke SQL*Plus and execute the
following statements:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP PFILE=PRMYinit.ora;
Note: If you are able to execute the STARTUP statement successfully, the
primary database has not been damaged. Do not continue with this
procedure.
7. Execute the following SQL statements on each standby database (including the
one on this system) that you were able to connect to:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> SELECT THREAD#, MAX(SEQUENCE#) FROM V$LOG_HISTORY GROUP BY THREAD#;
Compare the query results of each standby database. Fail over to the
standby database with the largest sequence number.
8. Fail over to the standby database with the largest sequence number.
On the standby database with the largest sequence number, invoke SQL*Plus
and execute the following SQL statements:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP PFILE=Failover.ora;
9. Update the other standby databases with the new primary database information
and ensure the log transport and apply services are working correctly.
------------End of Standby Database Disaster Recovery ReadMe File-------------
