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 (22.214.171.124). Releases prior to 126.96.36.199 have several limitations for this feature that are not present in release 188.8.131.52.
***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