Enterprise-class Disaster Recovery for Oracle SE that prioritizes database integrity, disaster resiliency, recovery speed, and ease of use.
Find out how Standby™'s Cascade Standby Database feature works. The feature was introduced in early 2017 with the release of Standby™ version 8.
What is a Cascading Standby database?
The idea is to create a Standby database from a Standby database. The obvious question would be, what would you use it for?
- The 2nd Standby database can be used for Reporting where it's only required to be updated once or twice a day. The 1st Standby is kept up-to-date according to RPO/RTO requirements for real disasters.
- Another benefit of running a cascading standby instead of two standby databases is that archived logs are only shipped once from the Primary thus reducing load. Instead of having to ship logs from the Primary database to multiple standby sites.
Before we jump right in and start configuring a Cascading Standby Database, there are as usual a couple of important rules to take note of:
- You can only perform a Graceful Switchover between the Primary and the 1st Standby database. It will fail if you try to perform a Graceful Switchover between the Primary and the 2nd (Cascading) Standby database.
- The 2nd (Cascading) Standby database can be used for Activation, Reporting, Backups or DR Testing.
- To create a Cascading Standby database, a 2nd DDC file has to be created where the Source will be the 1st Standby database. This is achieved through a parameter CASCADE=Y which will be set when it picks up the Primary is in fact the 1st Standby database.
- The creation of the Cascading Standby database process is no different to the normal CSD (Create Standby Database) process
- Another very important thing is the location you are going to specify for ARCHDEST and ARCHSOURCE for the Cascade Standby database. Here the rule is the ARCHDEST location used for your 1st Standby database MUST always be the same location that you are going to specifying for the ARCSOURCE of the Cascading Standby database. The reason is, Standby™ will identify the archived logs in the ARCHDEST location which needs to be shipped to the 2nd Standby database (Cascading Standby database).
- Both COMPRESS and UNCOMPRESS should be set to ‘N’ (none) in the Primary DDC config file to ensure the archived logs stored on the Standby Host are in an uncompressed format.
I decided to demonstrate the Cascading Standby database feature in 2 parts.
In Part 1 we will look at:
- Recap of my initial Primary and Standby configuration
- Adding the thirdserver
- Creating the second DDC, note CASCADE=Y
- Create the Cascading Standby database
In Part 2 we will look at:
- Sending and Applying archived logs in the first DDC
- Run a Log Gap Report
- Sending and Applying of archived logs in the second DDC (Cascading Standby)
- Run a Log Gap Report
- Options to schedule send and apply for the second DDC
As you can see configuring and creating a Cascading Standby database is really easy and not that different to creating a normal standby database. If you stick to the rules, you should really be able to do this without too much effort. The possibilities are endless, download a 10 day free software trial and see for yourself. Till next time! Take care.