One question we are often asked is whether it is possible to run multiple standby databases off the same primary database. The good news is that the answer is yes, and with Dbvisit Standby this is actually very easy to configure. In the following we will walk through the steps required to do this.
There are many reasons you may want to run multiple standby databases off a single primary. A few includes things such as:
- For extra data protection and safety.
- Having a quick switch local copy of the database in addition to another at a remote location specifically for DR purposes.
- Using a secondary copy for testing or read-only reporting.
The basic steps to add another standby database to an existing configuration with Dbvisit Standby are:
- On the primary server, copy and modify the existing DDC file.
- Make sure the servers can communicate with each other.
- Transfer the new DDC file to the DR server location.
- Run Dbvisit Standby’s CSD operation to create the new standby database.
Depending on the Operating System (OS) in use, and location for this new standby (ie: is there another Dbvisit Standby configuration already running through to this) there may be some different parameters to set, such as
db_unique_name. We will discuss this in further detail.
For my example I am going to add a second standby database configuration to an existing configuration between two Windows 2003 servers: wintest-01 (primary) and wintest-02 (DR). My existing primary and standby database is called w111g. In this example I will take you through the process using Dbvisit Standby’s web based GUI, but all of these operations can equally be performed using the command line interface (CLI). Here you can see an overview of my environment:
So, first things first. What I need to do is copy the Dbvisit Standby Database Configuration file (DDC) file for this existing configuration, which is called
dbv_w111g.env, and is located under:
To keep things simple I will refer to this second standby configuration as w111g2, with a DDC file named
dbv_w111g2.env, though you can change this to whatever makes best sense to you.
Opening up this file what needs to be edited depends on the intended location of the new standby database. If it is to be added to an existing configuration (same primary and standby servers) then you need to make sure that it is uniquely identifiable and so we adjust
ORACLE_SID_DEST here, and will also modify the new standby database parameter
db_unique_name during the CSD process later. So, just to clarify this, when setting up multiple standby databases on the same server the
ORACLE_SID_DEST must be unique. Other parameters can, of course, also be adjusted according to your requirements, and those that I have changed are as below:
ORACLE_SID_DEST = w111g2 LOGDIR_DR = C:\app\oracle\admin\w111g2\dbvisit ARCHDEST = C:\app\oracle\oraarch\w111g2 ARCHTMP = C:\app\oracle\oratmp\w111g2
If you are creating a secondary standby database on a server separate to your initial configuration then you do not need to change these parameters, and the easiest thing to do would be to run with the same settings as for the primary server. What you do need to adjust, however, is
DESTINATION under the
Standby Server Settings section to reflect the name of this new end point. For this to work the servers must be able to communicate with each other, and have an established password-less SSH channel, as was required for your initial configuration. You can find out more information about this here.
Once I have created and edited my new DDC file it needs to be transferred to the DR server, and here you can see the result, for me on wintest-02:
On the primary server, in the web based GUI, we then go to:
Home > Setup > Create Standby Database > 1. Create New Standby Database
And you will be able select the new configuration (in my case w111g2) from the dropdown:
Next you let Dbvisit Standby know if ASM will be used by the new standby, and in my case it isn’t, so I hit continue. At this point a Precondition Check is executed, and when it completes, unless there are issues to address, you will be presented with a screen like the following:
For those unfamiliar with Dbvisit Standby’s CSD functionality, this screen provides you with an overview of how long the transfers for the standby database creation will take, and offers options to configure this, along with the standby database parameters. Because my database is relatively small I select the Direct Copy method, but this may not be the most appropriate choice for your environment, and you can read more on the options available, here. I have also elected to allow Dbvisit Standby to create any new folders on the DR server it requires, but if you prefer you can choose to do this yourself and select No for this option.
Moving down the screen we come to a couple of sections, which allow you to modify parameters for the standby database about to be created. As you can see in the
control_files and dispatchers rows I have adjusted W111G to W111g2. Clicking on the plus sign at the bottom of this table brings up a new row and a dropdown which enables you to modify a number of additional parameters. In my case because I am going to be running 2 standby databases on the same DR server, both with the same
db_name, it is crucial that I uniquely identify the new standby I am creating, otherwise they will not be able to run at the same time. You do this by setting
db_unique_name, for which I have entered w111g2.
You can also adjust file and online log locations, which I have done as you can see below, to separate them out from those for the existing standby database w111g. And finally I select to Save Template, which is optional, so that this particular configuration can be easily re-run in future, before hitting the Create Standby Database button.
Once this process is underway you will see feedback in relation to its progress output to screen, detailing the transfer of datafiles, creation of spfile and restore of the standby control files. If it completes successfully then receive this confirmation, and see that the standby database itself has been started in mount mode on the DR server.
From here you begin working with this new standby database, setting a log transfer and apply schedule, and tuning its operation according to your needs and requirements. In the following screen you can see that this new configuration is operational, and in sync, as indicated by the output of the Log Gap report:
You can also find more information on running multiple standby databases with Dbvisit Standby in our online user guide here.
This article was originally posted on the Dbvisit blog.
For more information on Running Multiple Standby databases with Dbvisit Standby V7, please refer to the following online documentation link: https://dbvisit.atlassian.net/wiki/display/UGDS7/Multiple+Standby+Databases
Mike Donovan June 21, 2013 12:55