Create Cascade DR Database for Oracle
- Jan Klinke
1. Introduction
Casacade standby database is specific type of deployment in environments where it is required to have more than one standby database for primary database. In case of cascade standby database, 1st standby database is source of the archivelogs for the 2nd (cascade) standby database and so on. Number of cascading standby databases is theoretically unlimited, in real life however there won’t be usually more than 2 cascade standby databases.
Benefit of this deployment type is that primary database is unaffected by deployment of cascade standby database. The disadvantage is that if there’s anything wrong with 1st standby server / database the cascade database will have issues as well.
In this example we will describe how to create standby database step-by-step. The resources used are:
primary host: cc1
1st standby host: cc2
2nd (cascade) standby host: cc3
dbvcontrol host: cc2
DDC1 (non-cascade): TEST01
DDC2 (cascade): TEST01C
2. Prerequisites
Starting point for creating cascade standby database is to already have dbvisit deployed to primary and standby server and have working primary to standby replication, in our case cc1=>cc2 as seen here:
You can refer to following documents to establish this first replication:
Installing Standby Multiplatform
There were no special steps performed throughout creation and configuration of DDC1 TEST01.
It is not supported to create cascade standby database when source standby database (on cc2 host in example above) has password file on ASM. If this is the case, you must place password file for source standby database to filesystem.
3. Installing Dbvisit on Cascade standby host
There are no specific steps for installing Dbvisit on cascade standby host (in our case cc3). You can follow steps here to perform the installation:
Installing Standby Multiplatform
Everything is done “as usual” - there’s no difference from installation on primary or 1st standby host.
4. Creating Cascade Standby Configuration
4.1 Identifying 1st Standby ARCHDEST
Before we start with creating of cascade configruation, we need to find & remember directory on 1st standby server which receives archivelogs from primary (variable ARCHDEST of 1st DDC):
In our case, the directory which we need to take note of and remember is /u01/app/oracle/dbvisit_arch/TEST01.
4.2 Create Cascade DDC
Start by initiating new configuration process:
Select your 1st standby as primary (in our case cc2):
Continue by selecting source standby database (1), standby server (2) and modifying the DDC parameters (3,4,5,6):
The “Archivelog staging location on Source Host” (3) is the most important thing. Here you need to enter the value you remembered from previous step (1st standby ARCHDEST). In our case it’s /u01/app/oracle/dbvisit_arch/TEST01
We do recommend to change Oracle SID (4) and Unique database name (5) to differentiate cascade standby from 1st standby. It’s however possible to leave these two values as default. Although we support having different Oracle SID and Unique database name, we would recommend both to have same value.
If you changed SID and / or Database unique name, you should change the Dbvisit Archivelog Staging location on standby server (6) to contain the SID/Unique name string. In our case TEST01C.
Final step is to enter DDC name (1) - you need to differentiate it from 1st non-cascade DDC, that’s why we chose TEST01C. Enter License key (2) and create the configuration (3):
Once done, you should see both DDCs like so:
Note the state for TEST01C source database: RECOVERING. This indicates it’s a standby database.
4.3 Verify that cascade is set for 2nd DDC
Throughout the previous step, there was no indication that we actually setup cascade DDC. Let’s do sanity check for 2nd DDC:
If the DDC variable CASCADE is set to “Y” all is good and we can proceed with next step. The CASCADE variable is automatically set to Y if source database has standby role.
5. Creating Cascade Standby Database
When you initiate create standby database process for DDC which has CASCADE=Y, the source database will be bounced. Regardless if it’s primary or standby.
Keep this in mind when playing around and always double check the DDC and its CASACDE parameter before creating cascade standby to prevent any unwanted downtime for your production database.
In this case all is fine as we have CASCADE=Y for TEST01C DDC which has standby database as a source.
There’s no effect on production database when creating cascade standby. It’s not needed to disable automated standby update for DDC1.
Creating cascade standby database is no different from creation of normal standby. Full database backup will be created on source standby server and restored on cascade standby server. For full create standby documentation see:
We will show only simplified version in this guide:
Choose backup directories (1,2), modify oracle parameters is needed (3) and finally initiate the process (4). After the creation, the dashboard should look like so:
The RECOVERING => RECOVERING state of databases for DDC2 TEST01C indicates it’s cascade standby database.
6. Cascade Standby Database Considerations
Having cascade configuration like observed in this example with TEST01 and TEST01C, makes all three databases related and bound together: primary, standby and cascade standby. Actions such as switchover or failover are possible to perfom, but they will invalidate the cascade configuration and will require manual actions to make cascade configuration working again.
For example:
TEST01C configuration will be not working after you perform switchover of configuration TEST01. After you perform switchover again for TEST01, it will be necessary to run incremental backup sync for configuration TEST01C:
TEST01C configuration will be not working after you perform failover of configuration TEST01. You will need to recreate the cascade standby database from new primary. Because of new incarnation it won’t be possible to use the old cascade standby database.