Oracle Data Guard 11g - Overview Cascaded Redo Transport Destinations

Note: To use the Oracle Data Guard cascading redo transport destination feature described in this video, you should be using Oracle Database 11g Release 2 (11.2.0.2). Releases prior to 11.2.0.2 have several limitations for this feature that are not present in release 11.2.0.2.

***

We are know usually in data guard configurations standby databases receives primary database generated redo indirectly from  primary.

A cascaded redo transport destination receives primary database redo indirectly from a standby database rather than directly from a primary database.

A standby database that cascades primary database redo to one or more cascaded destinations is known as a cascading standby database.

Cascading offloads the overhead associated with performing redo transport from a primary database to a cascading standby database.

A cascading standby database can cascade primary database redo to up to 30 cascaded destinations, each of which can be a physical, logical, or snapshot standby database.

Primary database redo is written to the standby redo log as it is received at a cascading standby database. The redo is not immediately cascaded however. It is cascaded after the standby redo log file that it was written to has been archived locally. A cascaded destination will therefore always have a greater redo transport lag, with respect to the primary database, than the cascading standby database.

Cascading has the following restrictions:

• A physical standby database is the only standby database type that can cascade redo
  
• The Data Guard broker does not support cascaded destinations

 
Regards
Mahir M. Quluzade


p.s. Watch video with 720 HD quality on youtube : Oracle Data Guard 11g - Overview Cascaded Redo Transport Destinations