Differentiating physical standby to cascaded standby

cascadedataguardoracle-12cstandby

Why is it that for non-real time apply from cascading to cascaded standby that we have to mention as SYNC as the redo transport mode? Ideally we mention SYNC for real time apply right?

Also, should we mention as SYNC NOAFFIRM for non-real time apply?

Thanks!

Best Answer

Why is it that for non-real time apply from cascading to cascaded standby that we have to mention as SYNC as the redo transport mode?

Whether the Real-Time cascade feature is used or not, actually it depends on the attributes in the parameter LOG_ARCHIVE_DEST_n of the cascading standby that control how the redo stream is forwarded to the cascaded database. Beginning with Oracle 12c, the attributes LGWR and ARCH of the LOG_ARCHIVE_DEST_n parameters are deprecated. The only valid values are SYNC, ASYNC or none of them. In particular, for a cascading standby (thus, for a DB in Standby Role), the only valid attribute for the transport is ASYNC, meaning that synchronous transport from a standby database to another is not possible. If ASYNC is specified then Real-Time cascade is used, if no transport attribute is specified, Real-Time cascade is disabled and the redo stream from the cascading to the cascaded database is transported using the archived logs.

Ideally we mention SYNC for real time apply right?

Yes, when we are not using cascading and cascaded standby

should we mention as SYNC NOAFFIRM for non-real time apply?

Maximum Availability mode now allows the LOG_ARCHIVE_DEST_n attributes SYNC and NOAFFIRM to be used together. This enables a synchronous standby database to be deployed at a further distance from the primary site without increasing the impact on primary database performance. (In an Oracle Data Guard broker configuration, this is referred to as FASTSYNC mode.)

So, its not necessary.

Related Question