Oracle Consulting Oracle Training Oracle Support Development
Home
Catalog
Oracle Books
SQL Server Books
IT Books
Job Interview Books
eBooks
Rampant Horse Books
911 Series
Pedagogue Books

Oracle Software
image
Write for Rampant
Publish with Rampant
Rampant News
Rampant Authors
Rampant Staff
 Phone
 800-766-1884
Oracle News
Oracle Forum
Oracle Tips
Articles by our Authors
Press Releases
SQL Server Books
image
image

Oracle 11g Books

Oracle tuning

Oracle training

Oracle support

Remote Oracle

STATSPACK Viewer

Privacy Policy

 

   
 

Streams downstream capture

Oracle Tips by Burleson 

Oracle Streams
Chapter 8 -
Down Streams Capture

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.

 


The above text is an excerpt from:

Oracle Streams
High Speed Replication and Data Sharing

ISBN 0-9745993-5-2

by Madhu Tumma
 


Download your Oracle scripts now:

www.oracle-script.com

The definitive Oracle Script collection for every Oracle professional DBA

Linux Oracle commands syntax poster

ION Oracle tuning software

Oracle data dictionary reference poster



Oracle Forum

BC Oracle consulting support training

BC remote Oracle DBA   

 

   

 Copyright © 1996 -2016 by Burleson. All rights reserved.


Oracle® is the registered trademark of Oracle Corporation. SQL Server® is the registered trademark of Microsoft Corporation. 
Many of the designations used by computer vendors to distinguish their products are claimed as Trademarks