In this chapter, information will be
presented on the details about Down Streams capture. The nature
of the configuration will be covered as well as details on the
set up and the pros and cons of this capture method.
Down Streams
Capture
Down Streams Capture involves the execution
of the Capture process on a database other than the source
database. The archive log files from the source database are
copied to the remote database. The Capture process running on
this remote database scans and processes the archived log files
for the database changes and enqueues the Logical Change Record
(LCR) into the queue. Down Streams capture is used when the goal
is to shift the capture activity to another database, thereby
enhancing the performance of the Capture process as well as
freeing up resources at the source database.
This remote database is also known as the
Down Streams database. The queue also resides on the Down
Streams database. The archive log files are copied from the
source database, where the transactions are taking place, to the
intermediate or Down Streams database. This is accomplished by
using the log transport services, a file transfer protocol
(FTP), or by using the package dbms_ftp_transfer
mechanism.
A typical scenario of Streams data flow
involving Down Streams Capture is shown in Figure 8.1.
A Down Streams database can receive redo
log files from multiple source databases where the transactional
activity occurs and propagate the LCR events to the desired
destination database. In addition, a single database may have
one or more Capture processes that capture local changes and
other Capture processes that capture changes from the redo log
files of a remote source database. In this way, a single
database can be configured to perform both local capture and
Down Streams capture.
The first time a Down Streams capture
process is started at the Down Stream database, Oracle uses data
dictionary information in the redo log to create a LogMiner data
dictionary at the Down Streams database. The dbms_capture_adm.build
procedure is executed at the source database to extract the
source data dictionary information to the redo log at the source
database.
Figure 8.1 Down Streams Capture and the
Data Flow
In a Down Streams capture environment, the
source database can be a single instance database or a
multi-instance Real Application Clusters (RAC) database. The Down
Streams database can be a single instance database or a
multi-instance RAC database, regardless of whether the source
database is single instance or multi-instance.
Advantages of the Down Streams process include:
-
It uses fewer resources on the
source database.
-
When there is a scenario where
multiple source database changes are to be processed, one Down
Streams database can act as the central location for hosting the
Capture process which obtains database changes from multiple
sources.
-
At the same time, from one source
database, multiple targets can be serviced.
-
Copying redo log files to one or
more Down Streams databases provides improved protection against
data loss. For example, the redo log files at the Down Streams
database may be used for recovery of the source database in some
situations.
Disadvantages
Because the Down Streams Capture process needs
to wait for log switching of the redo log file and then subsequent
copy of archive log files from the source database to the Down
Steams database, there will be an unavoidable delay in capturing the
database changes. This delay may not be acceptable for some
situations.
The Down Streams capture configuration also
requires an intermediate host as well as the database system, which
is an additional expense that must be considered.
Using the Database Link
When a Down Streams Capture process uses a
database link connecting to the source database, it performs
certain administrative functions at the source database. They
are as follows:
-
When a Capture process is
created, it automatically runs the dbms_capture_adm.build
procedure at the source database in order to extract the data
dictionary at the source database to the redo log.
-
It prepares source database
objects for instantiation. It obtains the first_scn for
the Down Streams Capture process if the first_scn is not
specified during Capture process creation. The first_scn
is needed to create a Capture process.
-
If a Down Streams Capture
process does not use a database link, the above actions need to
be carried out manually.
Requirements
The Oracle10g release is required for
configuring Down Streams capture. In addition, 10g is required
on both the source and destination sides. This is because the
Down Streams feature is available only in the 10g version.
The operating system on the source and Down
Streams capture sites must be the same, but the operating system
releases need not be the same. In addition, the Down Streams
sites can use a different directory structure from the source
site.
Another requirement is that the hardware
architecture on the source and Down Streams capture sites need
to be the same but in a limited way. For example, a Down Streams
capture configuration with a source database on a 32-bit Solaris
must have a Down Streams database that is configured on a 32-bit
Solaris system. The other hardware components like the number of
CPUs, memory size, and storage configuration, can be different
between the source and Down Streams sites.
The configuration of Down Streams capture
can be achieved with either of two broadly defined methods.
These methods are Implicit Log Assignment capture and Explicit
Log Assignment capture. The Implicit method is the more common
method because the explicit method involves more manual tasks.
Log assignment by SQL command is a cumbersome procedure.
As shown in Figure 8.2, one method is where
log files are assigned implicitly to the Capture process running
at Down Streams database, and the second one is to assign the
redo log files explicitly by using the command ALTER DATABASE
REGISTER LOGICAL LOGFILE. In the implicit method, the log
transport service must be configured to transfer the archived
log files to the Down Streams database. The explicit method
involves the transfer of the archived redo log files using the
FTP method or any other copy method.
Figure 8.2 Methods of Down Streams
Capture Configuration
In the case of the implicit method, the
Down Streams database may or may not use the database link to
the source. Depending on whether or not the database link is
used, certain additional steps may be required. These steps
include manual instantiation and running dbms_capture_adm.build
procedure at the source database in order to extract the data
dictionary at the source database to the redo log.
Creating a database link from the Down
Streams capture database to the source database is optional.
However, creating the database link to source database
simplifies the configuration and management of the Down Streams
database.
