...
It is creating a standby database, from a standby database. The concept is not difficult, and to configure it using Dbvisit Standby Version 8 is really easy. There are a number of use cases for this type of configuration. A second standby database may be needed to be used for reporting and only update it once or twice a day, where the original standby database is kept up to date with the primary in case disaster strikes. Instead of sending logs from the primary to a second standby database, why not just send it from the first standby database. Using it this way you can also reduce the load on your primary and not double up on shipping archived redo multiple times to standby sites – but just ship it once, and then from the first standby ship the logs to the second or third standby.
...
1.) You cannot perform a Graceful Switchover (GS) between the primary and the secondary (cascading) standby databases. You will only be able to perform a GS between the primary and the first (primary) standby database.
2.) The second standby database can still be used for activation, reporting (if opened read only), backups or even DR testing.
3.) To configure the cascading standby database option in Dbvisit Standby Version 8, you must create a second DDC file. To create the DDC file you must select the primary (first) standby as your source or “Primary” database. Dbvisit Standby Version 8 will set a new parameter CASCADE=Y in this DDC file which indicates that the source – or primary as seen in this case, is actually a standby database.
4.) Once the DDC file is created, the Create Standby Database (CSD) process for the secondary standby is exactly the same as what you would be familiar with when creating the first standby database.
5.) The location used for the ARCHDEST and ARCSOURCE is crucial when using cascading standby databases. The ARCHDEST
location used for your first standby database MUST be the same location used for the ARCSOURCE for the cascading standby configuration. This is important as Dbvisit Standby will detect and pick up the archive logs that are located in the Dbvisit ARCHDEST location to be shipped to the secondary standby database.
6.) COMPRESS and UNCOMPRESS should be set to ’N’ (none) in the primary DDC file. The archive logs that are stored on the standby server must be in an uncompressed format. Note that by default compression is enabled in Dbvnet during network transfer and using COMPRESS option in Dbvisit Standby Version 8 is not recommended. The option is still provided – but the default option for a new configuration compression in the DDC file will be disabled and default Dbvnet compression will be used.
...
The first few images below, will provide a summary of the existing configuration, followed by the steps to create the secondary (cascading) standby database.
Main Menu:
In the screen below we can see the main Dbvisit Standby Version 8 Central Console.
...
The next step is to add the second standby host. Now it is important that the Dbvisit Standby Version 8 software core components (Dbvnet, Dbvagent and Standby Core) are already installed on this host and that Dbvnet and Dbvagent is running.
We navigate from the main screen to “MANAGE HOSTS”. From here the following screen will be displayed.
From the this screen we select “NEW” (2) as shown above to add a new host.
...
Creating the Cascading Standby DDC.
From the main Central Console screen navigate to “MANAGE CONFIGURATIONS”. The following screen will be displayed:
...
The key value I would like to highlight here is the new DDC parameter called CASCADE which is now set to a default value of “Y”. This is the key parameter that is set to indicate that we are dealing with Cascading Standby Databases here. Also note the ARCHDEST and ARCHSOURCE values. As mentioned earlier, it is important that the ARCSOURCE value of this configuration match the ARCHDEST location of the 1st standby database configuration.
...
From here we select our DDC (2) and then select the option to create a “NEW DATABASE” (3). The default settings for the new standby database is displayed.
Note that in this case the secondary standby database server has the exact same layout as the original standby server (dbv2) and the primary server (dbv1).
This page is split over two images to show all parameters.
Now in In the example as seen above, we do not select the use of transportable media (1). This is a useful option if you have a large database with low network bandwidth and you would like to use external media to transfer the backup to the secondary standby server. In this example, we will backup local to /usr/tmp from where the backup will be copied to the standby server /usr/tmp.
We now select the option to “Create Standby Database” (3) – which will now start the process. A new task will appear on the “Active Tasks” list and if selected, the details of the standby creation process is displayed – see image below:
...
Updating the new secondary standby database
Now that Once the new secondary standby database is created, we can start the process of shipping logs to the standby database. But at this stage it is important to note that the secondary standby database now running on dbv3, is reliant on the archive logs that is available on the first standby database running on dbv2. To ensure we have logs available on the first standby database, we first run the process to ship and apply logs from primary (dbv1) to the first standby (dbv2). Then once we have successfully sent and applied logs between these, we can now send logs from the first standby database running on dbv2 to the secondary standby on dbv3. The arrows and numbers in the image below show the order of the steps to be performed.
...
You should now have two standby databases, with the second one standby receiving its log files from the first standby.
The next step would be to either schedule a cron to send and apply logs to the secondary standby.
...