18. On the target, use the EDIT PARAMS command to create a parameter file for the Replicat group. Include the following parameters plus any others that apply to your database environment.
-- Identify the Replicat group:
REPLICAT <rep>
-- State whether or not source and target definitions are identical:
SOURCEDEFS <full_pathname> | ASSUMETARGETDEFS
-- Specify database login information as needed for the database:
[TARGETDB <dsn_2>][, USERID <user>][, PASSWORD <pw>
[<encryption options>]]
-- Specify decryption if input trail is encrypted:
DECRYPTTRAIL <encryption options>
-- Specify error handling rules:
REPERROR (<error>, <response>) -- Specify tables for delivery:
MAP <owner>.<table>, TARGET <owner>.<table>[, DEF <template name>];
Creating a cascading reporting configuration
Oracle GoldenGate supports cascading synchronization, where Oracle GoldenGate propagates data changes from the source database to a second database, and then on to a third database. In this configuration:
● A primary Extract on the source writes captured data to a local trail, and a data pump sends the data to a remote trail on the second system in the cascade.
● On the second system, Replicat applies the data to the local database.
● Another primary Extract on that same system captures the data from the local database and writes it to a local trail.
● A data pump sends the data to a remote trail on the third system in the cascade, where it is applied to the local database by another Replicat.
NOTE If you do not need to apply the replicated changes to a database on the secondary system, see “Creating a reporting configuration with a data pump on an
intermediary system” on page 50.
Creating a cascading reporting configuration
Use this configuration if:
● One or more of the target systems does not have a direct connection to the source, but the second system can connect in both directions.
● You want to limit network activity from the source system.
● You are sending data to two or more servers that are very far apart geographically, such as from Chicago to Los Angeles and then from Los Angeles to servers throughout China.
When considering this topology, take note of the following:
● This configuration can be used to perform data filtering and conversion if the character sets on all systems are identical. If character sets differ, a data pump cannot perform conversion between character sets, and you must configure Replicat to perform the conversion and transformation on the target.
● To use the data pump on the second system to perform data conversion and transformation, assuming character sets are identical, you must create a source definitions file on the first system with the DEFGEN utility and then transfer it to the second system. Additionally, you must create a source definitions file on the second system and transfer it to the third system. For more information about definitions files and conversion, see Chapter 13.
● On the second system, you must configure the Extract group to capture Replicat activity and to ignore local business application activity. The Extract parameters that control this behavior are IGNOREAPPLOPS and GETREPLICATES.
Figure 11 Cascading configuration
Creating a cascading reporting configuration
Source system
Refer to Figure 11 for a visual representation of the objects you will be creating.
To configure the Manager process on the source
1. On the source, configure the Manager process according to the instructions in Chapter 3.
2. In the Manager parameter file, use the PURGEOLDEXTRACTS parameter to control the purging of files from the trail.
To configure the primary Extract group on the source
3. On the source, use the ADD EXTRACT command to create the source Extract group. For documentation purposes, this group is called ext_1.
ADD EXTRACT <ext_1>, {TRANLOG | INTEGRATED TRANLOG}, BEGIN <time>
[, THREADS <n>]
❍ For TRANLOG and INTEGRATED TRANLOG, see the Oracle GoldenGate Windows and UNIX Reference Guide. INTEGRATED TRANLOG enabled integrated capture for an Oracle database.
4. On the source, use the ADD EXTTRAIL command to create a local trail.
ADD EXTTRAIL <local_trail_1>, EXTRACT <ext>
❍ Use the EXTRACT argument to link this trail to the ext_1 Extract group.
5. On the source, use the EDIT PARAMS command to create a parameter file for the ext_1 Extract group. Include the following parameters plus any others that apply to your database environment.
-- Identify the Extract group:
EXTRACT <ext_1>
-- Specify database login information as needed for the database:
[SOURCEDB <dsn_1>][, USERID <user>][, PASSWORD <pw>
[<encryption options>]]
-- Specify the local trail that this Extract writes to -- and specify encryption options:
ENCRYPTTRAIL <encryption options>
EXTTRAIL <local_trail_1>
-- Specify tables to be captured:
TABLE <owner>.<table>;
To configure the data pump on the source
6. On the source, use the ADD EXTRACT command to create a data pump group. For documentation purposes, this group is called pump_1.
ADD EXTRACT <pump_1>, EXTTRAILSOURCE <local_trail_1>, BEGIN <time>
Creating a cascading reporting configuration
❍ Use EXTTRAILSOURCE as the data source option, and specify the name of the local trail.
7. On the source, use the ADD RMTTRAIL command to specify a remote trail that will be created on the second system in the cascade.
ADD RMTTRAIL <remote_trail_1>, EXTRACT <pump_1>
❍ Use the EXTRACT argument to link the remote trail to the pump_1 data pump group.
The linked data pump writes to this trail.
8. On the source, use the EDIT PARAMS command to create a parameter file for the pump_1 data pump. Include the following parameters plus any others that apply to your database environment.
-- Identify the data pump group:
EXTRACT <pump_1>
-- Specify database login information if using NOPASSTHROUGH:
[SOURCEDB <dsn_1>][, USERID <user>][, PASSWORD <pw>
[<encryption options>]]
-- Specify decryption if input trail is encrypted:
DECRYPTTRAIL <encryption options>
-- Specify the name or IP address of second system in cascade -- and optional encryption of data over TCP/IP:
RMTHOST <target_1>, MGRPORT <portnumber>, ENCRYPT <encryption options>
-- Specify the remote trail and encryption options on the second system:
ENCRYPTTRAIL <encryption options>
RMTTRAIL <remote_trail_1>
-- Allow mapping, filtering, conversion or pass data through as-is.
[PASSTHRU | NOPASSTHRU]
-- Specify tables to be captured:
TABLE <owner>.<table>;
NOTE To use PASSTHRU mode, the names of the source and target objects must be identical. No column mapping, filtering, SQLEXEC functions, transformation, or other functions that require data manipulation can be specified in the parameter file. You can combine normal processing with pass-through processing by pairing PASSTHRU and NOPASSTHRU with different TABLE statements.