Multiple standby databases

Owned by KrupeshD (Deactivated)
Last updated: Jul 05, 2013 by Anna Macnaughtan (Deactivated)Version comment

Setting up for multiple standby databases

It is possible to run more than one standby database for the same primary database when using Dbvisit Standby.
These standby databases must all share the same db_name, but the instance name (or ORACLE_SID) and service_names may be different. The standby databases are normally located on different standby servers, but it is also possible to have multiple standby databases on the same standby server.
Each standby database must have its own unique Dbvisit Standby Database Configuration (DDC) file (dbv_<DDC>.env).
Because the database name (ORACLE_SID) will normally be the same for multiple standby databases, a unique number can be added to each DDC file to make it unique. For example to have 3 different standby databases for the same primary database called w112g:

  1. dbv_w112g.env (The original DDC file for primary database and first standby database).
  2. dbv_w112g2.env (A new DDC file for primary database and second standby database).
  3. dbv_w112g3.env (A new DDC file for primary database and third standby database)

etc.
To setup for multiple standby DDC files please follow the following steps:

1. Copy the DDC file and give it a new name.

Example: copy dbv_w112g.env dbv_w112g2.env
Where w112g is the name of the database.

2. Edit the new DDC file and change the DESTINATION variable. This must be set to the second standby server that is running the second standby database. Do not change the ORACLE_SID.

Example: DESTINATION=dbvisit13
Where dbvisit13 is the second standby server.

3. If any of the other standby database settings are different, these must be edited as well. The variables that can be changed are:

ORACLE_SID_DEST*
ORACLE_BASE_DR
LOGDIR_DR
ARCHDEST
MAX_TIMES_TRIED
LEAVE_COMPRESS_DEST
ADD_DATAFILE

    For a multiple standby database on the same node the ORACLE_SID_DEST must be different unique

4. Dbvisit Standby must be scheduled for each multiple standby database separately on the primary server.

5. It is possible to have a different schedule for each standby database. For example the disaster recovery standby database runs every 15 minutes, but the reporting standby database only runs every hour from 7pm to 7am.

6. On each standby server, Dbvisit Standby needs to be scheduled. Note that the correct DDC file needs to be specified.

Windows Only

The Dbvisit Standby software and SSH software must be installed on the second standby server. Dbvisit Standby for Windows includes the Bitvise SSH environment with public and private keys. In order to configure this successfully for all standby servers please follow the following steps.

  1. Install Dbvisit Standby on the second standby server.
  2. Unselect the "System Readiness Check" from the installer.
  3. Copy all the keys from the ssh2 directory on primary server to the same location on second standby server. This overwrites all the ssh2 keys from second standby with the keys from the primary server.
  4. Start the Dbvisit Standby console on the second standby server. Type in the command:
    dbv_functions -Y standby setupssh
  5. This loads the second standby server with the new ssh keys. All servers now have the same ssh keys, so that they can make contact with each other.
  6. The ssh setup can be tested by running the following command on both the primary and the second standby server: dbv_functions -a system_readiness

Creating multiple standby databases

When the DDC files have been copied and updated for the new standby databases, dbvisit_setup can be run to create the new standby databases. Each unique DDC file will be listed as a separate SID. In our example we assume that 3 DDC files have been created as shown above (dbv_w112g.env, dbv_w112g2.env and dbv_w112g3.env).

 

 dbvisit_setup 
 7) Create Standby Database 
 ------------------------------------------------------------------------------ 
 =>Creating Standby Database. 
 For which primary database do you want to create a standby database? 
 The following Oracle database(s) have a Dbvisit Database configuration (DDC) 
 file on this server: 

 SID 
 === 
 1) w112g 
 2) w112g2 
 3) w112g3 
 4) Return to menu 
 Please enter choice : 2

Choose the SID that corresponds to the new standby database. In the above example w112g2 and w112g3 represent the new standby databases. Choosing option 2 will create the new standby database that is represented by w112g2, and choosing option 3 creates the new standby database that is represented by w112g3.

Initially running Dbvisit Standby for multiple standby databases

The first time that Dbvisit Standby is executed for a new standby database, run Dbvisit Standby with the resynch option.

 

dbvisit -R w112g2

Where dbvisitp2 is the DDC for the new standby database.

This ensures that the Dbvisit Standby Database Configuration (DDC) file (and software if necessary) is copied over to the standby server. Subsequently run Dbvisit Standby as per normal.

Example - Configuring Dbvisit Standby for multiple standby databases

The following example will show how to configure Dbvisit Standby for 3 standby databases all being kept in synch from the same primary database.
Assuming that 3 DDC files have been created as shown above (dbv_w112g.env, dbv_w112g2.env and dbv_w112g3.env).
First standby database:
To run Dbvisit Standby on the primary server to keep a first standby database up to date.

 

dbvisit w112g
Where w112g is the DDC for the first standby database.

To run Dbvisit Standby on the standby server to keep a first standby database up to date.

 

dbvisit w112g
Where w112g is the DDC for the second standby database.

Second standby database:

To run Dbvisit Standby on the primary server to keep a second standby database up to date.

 

dbvisit w112g2
Where w112g2 is the DDC for the second standby database.

To run Dbvisit Standby on the standby server to keep a second standby database up to date.

 

dbvisit w112g2
Where w112g2 is the DDC for the second standby database.

Third standby database:
To run Dbvisit Standby on the primary server to keep a third standby database up to date.

 

dbvisit w112g3
Where w112g2 is the DDC for the third standby database.

To run Dbvisit Standby on the standby server to keep a third standby database up to date.

 

dbvisit w112g3
Where w112g2 is the DDC for the third standby database.

These commands can be scheduled in the appropriate scheduler to keep the standby databases in synch.

Graceful Switchover and multiple standby databases

Graceful switchover will change the role of the primary database to a standby database and one of the standby databases to a primary database.
Dbvisit Standby can still be used to keep all the standby databases in synch from the new primary database.
The following manual steps need to be performed to keep the other standby databases in synch with the new primary database.

  • Assuming that 3 DDC files have been created as shown above (dbv_w112g.env, dbv_w112g2.env and dbv_w112g3.env).
  • Assuming the first standby database has been converted to the new primary database (DDC file dbv_w112g.env).

Second standby database:
Copy the DDC file (dbv_w112g2.env) from the second standby server to the new primary server and edit the DDC file so that SOURCE= the new primary server
Schedule Dbvisit Standby on the new primary server with command:
dbvisit w112g2
Third standby database:
Copy the DDC file (dbv_w112g3.env) from the third standby server to the new primary server and edit the DDC file so that SOURCE= the new primary server.
Schedule Dbvisit Standby on the new primary server with command:
dbvisit w112g3
Dbvisit Standby will now keep all 3 standby databases in synch with the new primary database.

Multiple standby databases: setup guidance

Please follow these guide lines to ensure optimal performance of Dbvisit in a multiple standby databases scenarios:

  • Set separate locations for ARCHTMP for multiple DDC files (RAC and ASM primary)

  • If multiple standby databases reside on the same DESTINATION server, use separate ARCHDEST locations

  • If using compression, set COMPRESS to dbvisit or gzip (the latest on UNIX only) and leave KEEP_ORIG_FILE_BEFORE_COMPRESS at default value Y

  • Use the same Dbvisit repository (same DBUSER in all DDC files) for all standby databases related to a given primary. Setting separate repositories for multiple standby databases will disable Dbvisit functionality to obtain information about Dbvisit processes that transfer logs from the same primary database but use different DDC files