Setup for multiple standby databases

[Mike Donovan]

It is possible to run multiple standby databases off the same primary database with Dbvisit Standby. To setup for multiple standby databases please follow the steps outlined below (which assume that Dbvisit Standby has already been installed and configured to work with a standby database - called w120 in this example):

1. Copy the DDC file on the primary server and give it a new name.
Example:
copy dbv_w120.env dbv_w1202.env
or
cp dbv_w120.env dbv_w1202.env

Where w120 is the name of the database.

2. Edit the new DDC file and change the DESTINATION variable. This must be set to the new 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.

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

Then schedule Dbvisit Standby with this command on both the primary and new standby servers:
/usr/local/dbvisit/dbvisit w1202

A step by step guide to this process is also available here:
http://www.dbvisit.com/docs/Dbvisit_UserGuide5.2.htm#_Toc232239409

[ckolik]

Great information. Reading through the documentation I see, "but it is also possible to have a standby database on the same node as the primary database". Does Dbvisit Standby work with local standby databases (standby on same server as primary)? If so, are there any particular settings or tricks to getting this to work as I thought that the scripts check that SOURCE and DESTINATION are different before proceeding.

Thanks!

[Mike Donovan]

Hi Ckolik,

Thanks for your question. Yes, it is possible to have a local standby database.

Standby databases are normally located on different standby servers, but it is also possible to have a standby database on the same node as the primary database, called a shadow environment. This shadow database can be used to investigate issues like database bugs or inconsistencies that arise on the primary database. This allows the primary database to continue to run risk free while the issues are investigated on the shadow database.

The approach outlined above is the best way to go about setting up one of these environments. The third step in the documentation referenced above for this process says that 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

The key point for a shadow (local standby) environment - a standby database on the same node as the primary database - is that the ORACLE_SID_DEST must be different to the ORACLE_SID - so you must alter this accordingly.

[Arjen Visser]

Further to the information from Mike, the following needs to be set for a local standby database (on the same server as the primary database):

SOURCE=set_to_dummy
DESTINATION=actual_server_name
ORACLE_SID=sid
ORACLE_SID_DEST=standby_sid
ARCHDEST=<location of oracle primary archive log files>

The ORACLE_SID_DR is set to the standby database name and this needs to be different from the actual ORACLE_SID of the primary database otherwise you will not be able to create another instance.

With these settings, when Dbvisit Standby is scheduled it will apply archive logs to the standby database. Dbvisit Standby will not try to transfer any log files. To ensure that it works, it is important to ensure that ARCHDEST is set to the location where Oracle writes the archive log files for the primary archive log files.

SOURCE is set to a dummy value. It does not matter what this is.
DESTINATION is set to the actual server name.

[ckolik]

Excellent. Thank you both for your quick response!!