One of the great new features introduced in Dbvisit Standby Version 8 is the option to allow for cascading standby databases. So what does this really mean and how do you do this? In this post I will quickly show you how this works and how easy it is to configure.
...
What is a cascading standby database.
Think of it as It is creating a standby database, from a standby database. The concept is not that difficult, and yes to configure it using Dbvisit Standby Version 8 is really easy. There are a number of use cases for this type of configuration. You might need a A second standby database that is 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 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.
Now before Before getting into how easy it is to do this, there are a few things to highlight first:
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 environment I will be using in this example consist out of the followinglooks as follow:
4 servers running Oracle Linux 6:
...