Oracle Data Guard 11g - Overview Cascaded Redo Transport Destinations

To use the Oracle Data Guard cascading redo transport destination feature described in this video, you should be using Oracle Database 11g Release 2 ( Releases prior to have several limitations for this feature that are not present in release
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
Mahir M. Quluzade

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