DG Cascade Standby

SUMMARY

1. Logical standby does not support cascading standby

2.11.2.0.2 Previous version cascading standby does not support RAC

3.11.2.0.3 previous version of the DG Broker Environment does not support cascaded standby

DETAILS

To reduce the primary system load and reduce bandwidth requirements, cascade standby can be used when multiple standby need to be configured.

Supported cascading standby modes:

1. Primary db > Physical Standby db with cascaded destination > physical Standby db

2. Primary db > Physical Standby db with cascaded destination > Logical Standby db

Before 11.2.0.2, the physical standby supported up to 9 remote destination,11.2.0.2 and supported up to 30 at a later. When the physical standby is configured with cascaded destination, the standby received from primary to the second redo are transferred when the physical standby standby log is full or archived. There must be a lag between the second standby and the primary. cascaded standby can be used as a non-real-time reporting system.

Configuring cascaded Destination

1. Create standby redo logfile in standby

2. Set the Log_archive_dest_n parameter in primary, set physical standby forward redo to cascaded destination.

Define transfer mode: LGWR async or LGWR SYNC

Set the Valid_for property to enable redo forwarding

3. Forwarding Redo physical standby turn on archive mode

4. Configure the physical standby log_archive_dest_n parameter of the forwarding redo

Parameter configuration case:

Boston Database (Primary Role):

Db_unique_name=boston

standby_archive_dest=/arch1/boston/

Remote_login_passwordfile=exclusive

Log_archive_config= ' dg_config= (chicago,boston,denver) '

Log_archive_dest_1= ' location=/arch1/boston/valid_for= (online_logfiles,primary_role) DB_UNIQUE_NAME=boston '

Log_archive_dest_2= ' Service=denver valid_for= (standby_logfiles,standby_role) Db_unique_name=denver '

Log_archive_dest_3= ' Service=chicago valid_for= (online_logfiles,primary_role) Db_unique_name=chicago '

Chicago Database (Standby Role):

Db_unique_name=chicago

Log_archive_config= ' dg_config= (chicago,boston,denver) '

standby_archive_dest=/arch1/chicago/

Remote_login_passwordfile=exclusive

Log_archive_dest_1= ' location=/arch1/chicago/valid_for= (online_logfiles,all_roles) DB_UNIQUE_NAME=chicago '

Log_archive_dest_2= ' Service=denver valid_for= (standby_logfiles,standby_role) Db_unique_name=denver '

Log_archive_dest_3= ' Service=boston valid_for= (online_logfiles,primary_role) Db_unique_name=boston '

Denver Database (Standby Role):

Db_unique_name=denver

Log_archive_config= ' dg_config= (chicago,boston,denver) '

standby_archive_dest=/arch2/denver/<====for Logical STANDBY

Remote_login_passwordfile=exclusive

Log_archive_dest_1= ' location=/arch1/denver/valid_for= (online_logfiles,all_roles) DB_UNIQUE_NAME=denver '

Log_archive_dest_2= ' location=/arch2/denver/valid_for= (standby_logfiles,standby_role) DB_UNIQUE_NAME=denver '

Role change

Oracle recommends that backup databases that are primarily used for disaster recovery receive the redo data directly from the primary database, and that data protection reaches the best possible level. Cascade standby can be used as the second line of defense, but it is always more delayed than primary.

DG Cascade Standby