Configure CDC for the Replicated Tables

Oracle GoldenGate 29-9 ■ Initial Load Method ■ Tuning Replication Performances ■ One Source Multiple Staging Configuration

29.4.1 Initial Load Method

The staging tables contain a replica of the structure and data from the source tables. The Oracle GoldenGate processes capture changes on the source tables and apply them to the target. Yet the staging tables must be initially loaded with the original content of the source tables. You can use the following methods to perform the initial load: ■ Using Oracle GoldenGate: A specific GoldenGate process loads the whole content of the source tables into the staging tables. ■ Using Oracle Data Integrator: The Generate Interfaces IN option of Oracle Data Integrators Common Format Designer. This method uses ODI interfaces to transfer the data. ■ Using database backuprestore tools to copy data and structures.

29.4.2 Tuning Replication Performances

The following KM options can be used to improve replication performances: ■ COMPATIBLE: This Oracle-specific option affects the use of the PURGE key word and the way statistics using DBMS_STATS or ANALYZE are collected. Set this value to the database version of your staging server. ■ NB_APPLY_PROCESS: Number of Oracle GoldenGate Apply processes created on the staging server. ■ TRAIL_FILE_SIZE: Size of the Oracle GoldenGate trail file in Megabytes. For the NB_APPLY_PROCESS and TRAIL_FILE_SIZE parameters, see the Oracle GoldenGate Documentation on OTN for more information on performance tuning.

29.4.3 One Source Multiple Staging Configuration

It is possible to set up a configuration where changes are captured on a single source and replicated to several staging servers. The example below illustrates how to set this up in a typical configuration. Replication should source from source server SRC and replicate in both STG1 and STG2 staging servers. 1. Configure CDC for STG1 with the following configuration: ■ SRC_OGG_OBJECT_GROUP = SRC ■ SRC_SETUP_OGG_PROCESSES = YES ■ STG_OGG_OBJECT_GROUP = STG1 ■ STG_SETUP_OGG_PROCESSES = YES ■ ENABLE_ODI_CDC= YES 2. Start the journal and follow the instructions in the readme to set up the Oracle GoldenGate processes in SRC and STG1. 3. Configure CDC for STG2 with the following configuration: 29-10 Oracle® Fusion Middleware Connectivity and Knowledge Modules Guide for Oracle Data Integrator ■ SRC_OGG_OBJECT_GROUP = SRC Use the same name as for STG1 ■ SRC_SETUP_OGG_PROCESSES = NO The processes have been set up with STG1 ■ STG_OGG_OBJECT_GROUP = STG2 ■ STG_SETUP_OGG_PROCESSES = YES ■ ENABLE_ODI_CDC= YES Start the journal and follow the instructions in the readme to set up the Oracle GoldenGate processes in SRC and STG2. Note that playing the configuration on SRC again will not recreate a capture process, trail files, or definition files. It will simply create a new Oracle GoldenGate Datapump process to push data to STG2. 30 Oracle SOA Suite Cross References 30-1 30 Oracle SOA Suite Cross References This chapter describes how to work with Oracle SOA Suite cross references in Oracle Data Integrator. This chapter includes the following sections: ■ Section 30.1, Introduction ■ Section 30.2, Installation and Configuration ■ Section 30.3, Working with XREF using the SOA Cross References KMs ■ Section 30.4, Knowledge Module Options Reference

30.1 Introduction

Oracle Data Integrator features are designed to work best with Oracle SOA Suite cross references, including integration interfaces that load a target table from several source tables and handle cross references.

30.1.1 Concepts

Cross-referencing is the Oracle Fusion Middleware Function, available through the Oracle BPEL Process Manager and Oracle Mediator, previously Enterprise Service Bus ESB, and leveraged typically by any loosely coupled integration built on the Service Oriented Architecture. It is used to manage the runtime correlation between the various participating applications of the integration.

30.1.1.1 General Principles

The cross-referencing feature of Oracle SOA Suite enables you to associate identifiers for equivalent entities created in different applications. For example, you can use cross references to associate a customer entity created in one application with native id Cust_100 with an entity for the same customer in another application with native id CT_001. Cross-referencing XREF facilitates mapping of native keys for entities across applications. For example, correlate the same order across different ERP systems. The implementation of cross-referencing uses a database schema to store a cross reference information to reference records across systems and data stores. For more information about cross references, see Working with Cross References in the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite. The optional ability to update or delete source table data after the data is loaded into the target table is also a need in integration. This requires that the bulk integration