Source and Destination Database

These changes can be either DML changes or DDL changes.  If it is a DML operation, each LCR encapsulates a row change resulting from the DML operation to a shared table at the source database. If the change was a DDL operation, a LCR encapsulates the DDL change that was made to a shared database object at a source database. This process is basically a staging operation.

The Propagation process propagates the stages of the LCR to the queue of the destination database.  At the destination database, an Apply process consumes the change by applying the LCR to the shared database object. An Apply process may dequeue the LCR and apply it directly, or it may dequeue the LCR and send it to an apply handler.

Sometimes the Propagation process can be optional. This is because an application can create and enqueue an LCR directly into a queue at a destination database. In addition, in a heterogeneous replication environment in which an Oracle database shares information with a non-Oracle database, an Apply process may apply changes directly to a non-Oracle database without propagating LCRs.

Local and Down Streams Capture

Typically, the capture is configured and executed at the source database where the actual database changes are effected. However, for the performance or administrative reasons, the Capture process can also be configured to run on an intermediate database, which is different from the source database where actual changes occur. The intermediate database acts as the host for the Capture process. This capture configuration is known as Down Streams Capture. This feature was made available in the 10g database release.