Perform the following steps for a cascade standby database:
v$archive_dest
as follows:ID STATUS DB_MODE TYPE RECOVERY_MODE PROTECTION_MODE SRLs ACTIVE ARCHIVED_SEQ# --- --------- --------------- ---- ----------------------- -------------------- ---- ------ --------------- 1 VALID OPEN ARCH IDLE MAXIMUM PERFORMANCE 0 0 731 2 VALID OPEN_READ-ONLY LGWR MANAGED REAL TIME APPLY MAXIMUM PERFORMANCE 6 1 731 3 VALID OPEN_READ-ONLY LGWR MANAGED REAL TIME APPLY MAXIMUM PERFORMANCE 6 1 731
All remote destinations are using real-time apply with read only for reporting purpose in the Maximum Performance mode. It is to ensure that the standby database has enough standby redo logfiles so that there would be no interruption while sending data to the cascade standby database.
LOG_ARCHIVE_MAX_PROCESSES
parameter on the standby database so that more archive processes will run frequently to send data to all remote destinations in parallel as follows:SQL> show parameter log_archive_max_processes NAME TYPE VALUE ---------------------------- ----------- ---------- log_archive_max_processes integer 5 SQL> alter system set log_archive_max_processes=30; System altered. SQL> show parameter log_archive_max_processes NAME TYPE VALUE ---------------------------- ----------- ----- log_archive_max_processes integer 30 SQL>
From the primary (TURKEY) database, you can configure as follows:
DB_UNIQUE_NAME=turkey_un LOG_ARCHIVE_CONFIG=DG_CONFIG=(TURKEY_UN,INDIA_UN,UK_UN) LOG_ARCHIVE_DEST_2=service=INDIA VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=INDIA_UN FAL_SERVER='INDIA_UN'
From the standby (INDIA) database, you can configure as follows:
DB_UNIQUE_NAME=india_un LOG_ARCHIVE_CONFIG=DG_CONFIG=(TURKEY_UN,INDIA_UN,UK_UN) LOG_ARCHIVE_DEST_2=service=UK VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=UK_UN FAL_SERVER='UK_UN'
From the cascade standby (UK) database, you can configure as follows:
DB_UNIQUE_NAME=uk_un LOG_ARCHIVE_CONFIG=DG_CONFIG=(TURKEY_UN,INDIA_UN,UK_UN)
Apart from these parameters, you can configure more destinations if your environment contains more standby databases that are either physical or logical.
Verify it from the primary (TURKEY) database as follows:
SQL> select db_unique_name,database_role from v$database; DB_UNIQUE_NA DATABASE_ROLE ------------ ---------------- turkey_un PRIMARY ID STATUS DB_MODE TYPE PROTECTION_MODE ---------- --------- --------------- ----------------------------- 1 VALID OPEN ARCH MAXIMUM PERFORMANCE 2 VALID OPEN_READ-ONLY LGWR MAXIMUM PERFORMANCE SQL> select max(sequence#) from v$archived_log; MAX(SEQUENCE#) -------------- 747
Verify it from the standby (INDIA) database as follows:
SQL> select db_unique_name,database_role from v$database; DB_UNIQUE_NA DATABASE_ROLE ------------ ---------------- INDIA_UN PHYSICAL STANDBY SQL> select max(sequence#) from v$archived_log where applied='YES'; MAX(SEQUENCE#) -------------- 747
Verify it from the cascade standby (UK) database as follows:
SQL> select db_unique_name,database_role from v$database; DB_UNIQUE_NA DATABASE_ROLE ------------ ---------------- uk_un PHYSICAL STANDBY ID STATUS DB_MODE TYPE RECOVERY_MODE SQL> select max(sequence#) from v$archived_log where applied='YES'; MAX(SEQUENCE#) --------------- 747
If we define a cascade physical standby database from a physical standby database, then initially the redo will be transmitted from the primary database to the physical standby database. Thus, once the standby redo logfile is archived, that archive will be transferred and applied on the cascade physical standby database. Hence, there is an expected delay in data between the primary database and the cascade standby database. From the earlier outputs, we know that the maximum sequence generated in the primary is 747
and an archive has been applied on the physical standby and also on the cascade physical standby database.