Cascading Downstream Capture for Oracle XStream CDC Source Connector for Confluent Platform

Cascading downstream capture is a variant of Downstream Capture for Oracle XStream CDC Source Connector for Confluent Platform in which redo data reaches the downstream indirectly, through an Oracle Data Guard physical standby running Active Data Guard. Instead of shipping redo from the source primary directly to the downstream, the primary ships to a standby, and the standby cascades redo onward to the downstream.

The connector configuration and XStream capture setup are unchanged from base downstream capture. Only the redo transport path differs.

The supported Data Guard configuration is Physical Standby with Active Data Guard (ADG). Both real-time cascade and archived-log cascade are supported. Standard Data Guard, Logical Standby, Snapshot Standby, and chained cascading are not supported. See Restrictions.

For more information, see Oracle Database Data Guard Concepts and Administration 19c, Cascaded Redo Transport Destinations.

Cascading topology architecture

The cascading topology uses three Oracle databases: a source primary, a Physical Standby running Active Data Guard as the intermediate hop, and a downstream primary that hosts XStream capture. Redo travels from the source to the standby, and the standby forwards (cascades) redo to the downstream.

The downstream remains a PRIMARY database. XStream capture cannot run on a standby. Cascading describes only the redo transport path.

The metadata path—the DB link from the downstream to the source—is unchanged from base downstream capture and always points at the source primary, not the standby. The DB link uses the primary’s global name (for example, SRCCDB.EXAMPLE.COM), and any TNS alias resolving that name on the downstream must also resolve to the primary.

Source connection. The connector’s database.hostname and database.service.name must resolve to the source primary for the full lifetime of the connector. Schema extraction and DDL handling require operations that are not permitted on a read-only physical standby.

Cascade modes

Aspect	Real-time cascade	Archived-log cascade
Redo trigger from standby	RFS forwards redo as it lands in the standby redo logs	Standby archives the standby log, then ARCH forwards
Downstream redo storage	Standby redo logs	Foreign archived redo logs
Capture mode on downstream	Real-time downstream capture (downstream_real_time_mine=Y)	Archived-log downstream capture
Latency	Low. Comparable to direct real-time downstream.	Higher. Bounded by the standby log switch frequency.
VALID_FOR on standby cascade destination	(STANDBY_LOGFILES,STANDBY_ROLE)	(STANDBY_LOGFILES,STANDBY_ROLE)
Standby OPEN_MODE required	READ ONLY WITH APPLY (ADG)	READ ONLY WITH APPLY (ADG)

Both modes require Active Data Guard.

Redo transport configuration

Cascading adds one destination on the standby. The full three-role configuration is:

-- On the source PRIMARY: ship redo to the standby (DEST_2).
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=
  'SERVICE=standby_service ASYNC
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   DB_UNIQUE_NAME=SRCCDB_STBY' SCOPE=BOTH;

-- On the standby: real-time cascade to the downstream (DEST_3).
-- ASYNC forwards redo as it lands in the standby redo logs.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3=
  'SERVICE=downstream_service ASYNC NOREGISTER
   VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
   DB_UNIQUE_NAME=CAPCDB' SCOPE=BOTH;

-- On the standby: archived-log cascade variant (DEST_3).
-- TEMPLATE specifies the directory at the downstream where cascaded
-- archived logs land.
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3=
  'SERVICE=downstream_service NOREGISTER
   TEMPLATE=+RECO/arc_dest/SRCCDB/%t_%s_%r.arc
   VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
   DB_UNIQUE_NAME=CAPCDB' SCOPE=BOTH;

-- On the downstream: receive cascaded redo into standby logs (real-time)
-- or foreign archived logs (archived-log). Same as base downstream capture.

LOG_ARCHIVE_CONFIG=DG_CONFIG=(SRCCDB_DB,SRCCDB_STBY,CAPCDB) must list all three DB_UNIQUE_NAME values on the primary, standby, and downstream.

STANDBY_ROLE in VALID_FOR ensures the cascade destination is automatically suppressed if the standby is promoted to primary. Configure this LOG_ARCHIVE_DEST_3 on the primary database as well (with STANDBY_ROLE keeping it inactive while the primary role is in effect) to ensure the destination survives a role transition.

Database prerequisites

Before configuring cascading downstream capture, your Oracle database administrator must complete the base downstream capture prerequisites and the cascading-specific additional steps:

• Downstream capture database prerequisites

• Cascading downstream capture database prerequisites

Restrictions

In addition to Restrictions, the only supported Data Guard configuration is Physical Standby with Active Data Guard. Both real-time cascade and archived-log cascade are supported.

The following are not supported:

• Physical Standby with standard Data Guard. Standard Data Guard does not support real-time cascade.

• Logical Standby. Cascade is not possible from a logical standby.

• Snapshot Standby. The standby is not applying redo while in snapshot mode, so cascade does not flow.

• Chained cascading (for example, primary → standby A → standby B → downstream).

• Pointing database.hostname at the standby. The connector’s source connection must resolve to the primary; schema extraction and DDL handling require operations that a read-only standby does not permit.

Failure scenarios

In addition to Downstream-specific failure scenarios:

• Downstream offline while primary and standby continue to operate. The standby retains cascaded redo locally up to its archive retention limit. Capture catches up when the downstream returns online.

For health check queries and troubleshooting procedures, see Downstream capture monitoring and troubleshooting.