Modes of Change Data Capture

Change Data Capture provides synchronous and asynchronous modes for capturing
change data. The following sections summarize how each mode of Change Data
Capture is performed, and the change source associated with each mode of Change
Data Capture


Synchronous Change Data Capture

The synchronous mode uses triggers on the source database to capture change data. It
has no latency because the change data is captured continuously and in real time on
the source database. The change tables are populated when DML operations on the
source table are committed.

There is a single, predefined synchronous change source, SYNC_SOURCE, that
represents the source database. This is the only synchronous change source. It cannot
be altered or dropped.

While the synchronous mode of Change Data Capture adds overhead to the source
database at capture time, this mode can reduce costs (as compared to attempting to
extract change data using table differencing or change-value section) by simplifying
the extraction of change data.

Change tables for this mode of Change Data Capture must reside locally in the source
database.

Following figure illustrates the synchronous configuration. Triggers executed after DML operations occur on the source tables populate the change tables in the change sets within the SYNC_SOURCE change source.




Asynchronous Change Data Capture

The asynchronous modes capture change data from the database redo log files after
changes have been committed to the source database.
The asynchronous modes of Change Data Capture are dependent on the level of
supplemental logging enabled at the source database. Supplemental logging adds redo
logging overhead at the source database, so it must be carefully balanced with the
needs of the applications or individuals using Change Data Capture. See
"Asynchronous Change Data Capture and Supplemental Logging" on page 16-68 for
information on supplemental logging.

The three modes of capturing change data are described in the following sections:

■ Asynchronous HotLog Mode
■ Asynchronous Distributed HotLog Mode
■ Asynchronous AutoLog Mode

Asynchronous HotLog Mode
In the asynchronous HotLog mode, change data is captured from the online redo log
file on the source database. There is a brief latency between the act of committing
source table transactions and the arrival of change data.
There is a single, predefined HotLog change source, HOTLOG_SOURCE, that represents
the current online redo log files of the source database. This is the only HotLog change source. It cannot be altered or dropped.

Change tables for this mode of Change Data Capture must reside locally in the source
database.

Following figure illustrates the asynchronous HotLog configuration. The Logwriter Process(LGWR) records committed transactions in the online redo log files on the source database. Change Data Capture uses Oracle Streams processes to automatically
populate the change tables in the change sets within the HOTLOG_SOURCE change
source as newly committed transactions arrive.




Asynchronous Distributed HotLog Mode

In the asynchronous Distributed HotLog mode, change data is captured from the
online redo log file on the source database.

There is no predefined Distributed HotLog change source. Unlike other modes of
Change Data Capture, the Distributed HotLog mode splits change data capture
activities and objects across the source and staging database. Change sources are
defined on the source database by the staging database publisher.

A Distributed HotLog change source represents the current online redo log files of he
source database. However, staging database publishers can define multiple
Distributed HotLog change sources, each of which contains change sets on a different
staging database. The source and staging database can be on different hardware
platforms and be running different operating systems, however some restrictions
apply.

Following figure illustrates the asynchronous Distributed HotLog configuration. The
change source on the source database captures change data from the online redo log
files and uses Streams to propagate it to the change set on the staging database. The
change set on the staging database populates the change tables within the change set.

There are two publishers required for this mode of Change Data Capture, one on the
source database and one on the staging database. The source database publisher
defines a database link on the source database to connect to the staging database as the staging database publisher. The staging database publisher defines a database link on the staging database to connect to the source database on the source database
publisher. All publishing operations are performed by the staging database publisher.




Asynchronous AutoLog Mode

In the asynchronous AutoLog mode, change data is captured from a set of redo log
files managed by redo transport services. Redo transport services control the
automated transfer of redo log files from the source database to the staging database.
Using database initialization parameters the publisher configures redo
transport services to copy the redo log files from the source database system to the
staging database system and to automatically register the redo log files. Asynchronous AutoLog mode can obtain change data from either the source database online redo log or from source database archived redo logs. These options are known as asynchronous AutoLog online and asynchronous AutoLog archive.

With the AutoLog online option, redo transport services is set up to copy redo data
from the online redo log at the source database to the standby redo log at the staging database. Change sets are populated after individual source database transactions commit. There can only be one AutoLog online change source on a given staging database and it can contain only one change set.

With the AutoLog archive option, redo transport services is set up to copy archived
redo logs from the source database to the staging database. Change sets are populated
as new archived redo log files arrive on the staging database. The degree of latency
depends on the frequency of redo log file switches on the source database. The
AutoLog archive option has a higher degree of latency than the AutoLog online
option, but there can be as many AutoLog archive change sources as desired on a
given staging database.

Following shows a Change Data Capture asynchronous AutoLog online
configuration in which the LGWR process on the source database copies redo data to
both the online redo log file on the source database and to the standby redo log files on the staging database as specified by the LOG_ARCHIVE_DEST_2 parameter. (Although the image presents this parameter as LOG_ARCHIVE_DEST_2, the integer value can be any value between 1 and 10.)

Note that the LGWR process uses Oracle Net to send redo data over the network to the
remote file server (RFS) process. Transmitting redo data to a remote destination
requires uninterrupted connectivity through Oracle Net.

On the staging database, the RFS process writes the redo data to the standby redo log
files. Then, Change Data Capture uses Oracle Streams downstream capture to
populate the change tables in the change sets within the AutoLog change source.
The source database and the staging database must be running on the same hardware,
operating system, and Oracle version.

Posted in: Change Data Capture