Documentation
Advanced Search


Administering Oracle GoldenGate for Windows and UNIX

9 Configuring Oracle GoldenGate for Active-Active High Availability

This chapter describes how to configure Oracle GoldenGate for active-active high availability.

This chapter includes the following sections:

9.1 Overview of an Active-active Configuration

Oracle GoldenGate supports an active-active bi-directional configuration, where there are two systems with identical sets of data that can be changed by application users on either system. Oracle GoldenGate replicates transactional data changes from each database to the other to keep both sets of data current.

Description of simple_config_bidirectional.jpg follows
Description of the illustration simple_config_bidirectional.jpg

In a bi-directional configuration, there is a complete set of active Oracle GoldenGate processes on each system. Data captured by an Extract process on one system is propagated to the other system, where it is applied by a local Replicat process.

This configuration supports load sharing. It can be used for disaster tolerance if the business applications are identical on any two peers. Bidirectional synchronization is supported for all database types that are supported by Oracle GoldenGate.

Oracle GoldenGate supports active-active configurations for:

  • DB2 on z/OS, LUW, and IBM i

  • MySQL

  • Oracle

  • SQL/MX

  • SQL Server

  • Sybase

  • Teradata

Oracle GoldenGate supports DDL replication in an Oracle active-active configuration. DDL support is available for Oracle and Teradata databases.

9.2 Considerations for an Active-Active Configuration

The following considerations apply in an active-active configuration. In addition, review the Oracle GoldenGate installation and configuration document for your type of database to see if there are any other limitations or requirements to support a bi-directional configuration.

9.2.1 TRUNCATES

Bi-directional replication of TRUNCATES is not supported, but you can configure these operations to be replicated in one direction, while data is replicated in both directions. To replicate TRUNCATES (if supported by Oracle GoldenGate for the database) in an active-active configuration, the TRUNCATES must originate only from one database, and only from the same database each time.

Configure the environment as follows:

  • Configure all database roles so that they cannot execute TRUNCATE from any database other than the one that is designated for this purpose.

  • On the system where TRUNCATE will be permitted, configure the Extract and Replicat parameter files to contain the GETTRUNCATES parameter.

  • On the other system, configure the Extract and Replicat parameter files to contain the IGNORETRUNCATES parameter. No TRUNCATES should be performed on this system by applications that are part of the Oracle GoldenGate configuration.

9.2.2 Application Design

When using Active-Active replication, the time zones must be the same on both systems so that timestamp-based conflict resolution and detection can operate.

Active-active replication is not recommended for use with commercially available packaged business applications, unless the application is designed to support it. Among the obstacles that these applications present are:

  • Packaged applications might contain objects and data types that are not supported by Oracle GoldenGate.

  • They might perform automatic DML operations that you cannot control, but which will be replicated by Oracle GoldenGate and cause conflicts when applied by Replicat.

  • You probably cannot control the data structures to make modifications that are required for active-active replication.

9.2.3 Keys

For accurate detection of conflicts, all records must have a unique, not-null identifier. If possible, create a primary key. If that is not possible, use a unique key or create a substitute key with a KEYCOLS option of the MAP and TABLE parameters. In the absence of a unique identifier, Oracle GoldenGate uses all of the columns that are valid in a WHERE clause, but this will degrade performance if the table contains numerous columns.

To maintain data integrity and prevent errors, the following must be true of the key that you use for any given table:

  • contain the same columns in all of the databases where that table resides.

  • contain the same values in each set of corresponding rows across the databases.

9.2.4 Triggers and Cascaded Deletes

Triggers and ON DELETE CASCADE constraints generate DML operations that can be replicated by Oracle GoldenGate. To prevent the local DML from conflicting with the replicated DML from these operations, do the following:

  • Modify triggers to ignore DML operations that are applied by Replicat. If the target is an Oracle database, Replicat handles triggers without any additional configuration when in integrated mode. Parameter options are available for a nonintegrated Replicat for Oracle. See Installing and Configuring Oracle GoldenGate for Oracle Database.

  • Disable ON DELETE CASCADE constraints and use a trigger on the parent table to perform the required delete(s) to the child tables. Create it as a BEFORE trigger so that the child tables are deleted before the delete operation is performed on the parent table. This reverses the logical order of a cascaded delete but is necessary so that the operations are replicated in the correct order to prevent "table not found" errors on the target. (Note: For Oracle targets, if Replicat is in integrated mode, constraints are handled automatically without special configuration.)

    Note:

    IDENTITY columns cannot be used with bidirectional configurations for Sybase. See other IDENTITY limitations for SQL Server in Installing and Configuring Oracle GoldenGate for SQL Server.

9.2.5 Database-Generated Values

Do not replicate database-generated sequential values, such as Oracle sequences, in a bi-directional configuration. The range of values must be different on each system, with no chance of overlap. For example, in a two-database environment, you can have one server generate even values, and the other odd. For an n-server environment, start each key at a different value and increment the values by the number of servers in the environment. This method may not be available to all types of applications or databases. If the application permits, you can add a location identifier to the value to enforce uniqueness.

9.2.6 Database Configuration

One of the databases must be designated as the trusted source. This is the primary database and its host system from which the other database is derived in the initial synchronization phase and in any subsequent resynchronizations that become necessary. Maintain frequent backups of the trusted source data.

9.3 Preventing Data Looping

In a bidirectional configuration, SQL changes that are replicated from one system to another must be prevented from being replicated back to the first system. Otherwise, it moves back and forth in an endless loop, as in this example:

  1. A user application updates a row on system A.

  2. Extract extracts the row on system A and sends it to system B.

  3. Replicat updates the row on system B.

  4. Extract extracts the row on system B and sends it back to system A.

  5. The row is applied on system A (for the second time).

  6. This loop continues endlessly.

To prevent data loopback, you may need to provide instructions that:

  • prevent the capture of SQL operations that are generated by Replicat, but enable the capture of SQL operations that are generated by business applications if they contain objects that are specified in the Extract parameter file.

  • identify local Replicat transactions, in order for the Extract process to ignore them.

9.3.1 Preventing the Capture of Replicat Operations

Depending on which database you are using, you may or may not need to provide explicit instructions to prevent the capture of Replicat operations.

9.3.1.1 Preventing the Capture of Replicat Transactions (Oracle)

To prevent the capture of SQL that is applied by Replicat to an Oracle database, there are different options depending on the Extract capture mode:

  • When Extract is in classic or integrated capture mode, use the TRANLOGOPTIONS parameter with the EXCLUDETAG tag option. This parameter directs the Extract process to ignore transactions that are tagged with the specified redo tag. See Section 9.3.2 to set the tag value.

  • When Extract is in classic capture mode, use the Extract TRANLOGOPTIONS parameter with the EXCLUDEUSER or EXCLUDEUSERID option to exclude the user name or ID that is used by Replicat to apply transactions. Multiple EXCLUDEUSER statements can be used. The specified user is subject to the rules of the GETREPLICATES or IGNOREREPLICATES parameter. See Section 9.3.1.3 for more information.

9.3.1.2 Preventing Capture of Replicat Transactions (Teradata)

To prevent the capture of SQL that is applied by Replicat to a Teradata database, set the Replicat session to override Teradata replication. Use the following SQLEXEC statements at the root level of the Replicat parameter file:

SQLEXEC 'SET SESSION OVERRIDE REPLICATION ON;'
SQLEXEC 'COMMIT;'

These SQLEXEC statements execute a procedure that sets the Replicat session automatically at startup.

9.3.1.3 Preventing Capture of Replicat Transactions (Other Databases)

To prevent the capture of SQL that is applied by Replicat to other database types (including Oracle, if Extract operates in classic capture mode), use the following parameters:

  • GETAPPLOPS | IGNOREAPPLOPS: Controls whether or not data operations (DML) produced by business applications except Replicat are included in the content that Extract writes to a specific trail or file.

  • GETREPLICATES | IGNOREREPLICATES: Controls whether or not DML operations produced by Replicat are included in the content that Extract writes to a specific trail or file.

9.3.2 Identifying Replicat Transactions

To configure Extract to identify Replicat transactions, follow the instructions for the database from which Extract will capture data.

9.3.2.1 DB2 on z/OS, LUW, IBM i, and Informix

Identify the Replicat user name by using the following parameter statement in the Extract parameter file.

TRANLOGOPTIONS EXCLUDEUSER user

This parameter statement marks all data transactions that are generated by this user as Replicat transactions. The user name is included in the transaction record that is read by Extract.

Note:

With Informix, Oracle GoldenGate Replicat processes always perform a DELETE operation on the target database when the source operation (in the trail) is TRUNCATE.

9.3.2.2 MySQL and NonStop SQL/MX

Identify the name of the Replicat checkpoint table by using the following parameter statement in the Extract parameter file.

TRANLOGOPTIONS FILTERTABLE table_name

Replicat writes a checkpoint to the checkpoint table at the end of each of its transactions as part of its checkpoint procedure. (This is the table that is created with the ADD CHECKPOINTTABLE command.) Because every Replicat transaction includes a write to this table, it can be used to identify Replicat transactions in a bi-directional configuration. FILTERTABLE identifies the name of the checkpoint table, so that Extract ignores transactions that contain any operations on it.

Note:

PURGEDATA is not supported for NonStop SQL/MX in a bidirectional configuration. Because PURGEDATA/TRUNCATE operations are DDL, they are implicit transactions, so Oracle GoldenGate cannot update the checkpoint table within that transaction.

9.3.2.3 Oracle

There are multiple ways to identify Replicat transaction in an Oracle environment. When Replicat is in classic or integrated mode, you use the following parameters:

  • Use DBOPTIONS with the SETTAG option in the Replicat parameter file. Replicat tags the transactions being applied with the specified value, which identifies those transactions in the redo stream. The default SETTAG value is 00. Valid values are a single TAG value consisting of hexadecimal digits. For more information about tags, see Reference for Oracle GoldenGate for Windows and UNIX.

  • Use the TRANLOGOPTIONS parameter with the EXCLUDETAG option in the Extract parameter file. The logmining server associated with that Extract excludes redo that is tagged with the SETTAG value.

    The following shows how SETTAG can be set in the Replicat parameter file:

    DBOPTIONS SETTAG 0935
    

    The following shows how EXCLUDETAG can be set in the Extract parameter file:

    TRANLOGOPTIONS EXCLUDETAG 0935
    

    If you are excluding multiple tags, each must have a separate TRANLOGOPTIONS EXCLUDETAG statement specified.

You can also use the transaction name or userid of the Replicat user to identify Replicat transactions. You can choose which of these to ignore when you configure Extract. See Section 9.3.1.1.

For more information, see Reference for Oracle GoldenGate for Windows and UNIX.

9.3.2.4 SQL Server

Identify the Replicat transaction name by using the following parameter statement in the Extract parameter file.

TRANLOGOPTIONS EXCLUDETRANS transaction_name

This parameter statement is only required if the Replicat transaction name is set to something other than the default of ggs_repl.

9.3.2.5 Sybase

Do any of the following:

  • Identify a Replicat transaction name by using the following parameter statement in the Extract parameter file.

    TRANLOGOPTIONS EXCLUDETRANS transaction name
    
  • Identify the Replicat user name by using the following parameter statement in the Extract parameter file.

    TRANLOGOPTIONS EXCLUDEUSER user name
    

    EXCLUDEUSER marks all transactions generated by this user as Replicat transactions. The user name is included in the transaction record that is read by Extract.

  • Do nothing and allow Replicat to use the default transaction name of ggs_repl.

9.3.2.6 Teradata

You do not need to identify Replicat transactions that are applied to a Teradata database.

9.3.3 Replicating DDL in a Bi-directional Configuration

Additional consideration must be taken when replicating DDL, currently supported for Oracle and Teradata. For more information, see the following:

9.4 Managing Conflicts

Uniform conflict-resolution procedures must be in place on all systems in an active-active configuration. Conflicts should be identified immediately and handled with as much automation as possible; however, different business applications will present their own unique set of requirements in this area.

Because Oracle GoldenGate is an asynchronous solution, conflicts can occur when modifications are made to identical sets of data on separate systems at (or almost at) the same time. Conflicts occur when the timing of simultaneous changes results in one of these out-of-sync conditions:

  • A uniqueness conflict occurs when Replicat applies an insert or update operation that violates a uniqueness integrity constraint, such as a PRIMARY KEY or UNIQUE constraint. An example of this conflict type is when two transactions originate from two different databases, and each one inserts a row into a table with the same primary key value.

  • An update conflict occurs when Replicat applies an update that conflicts with another update to the same row. Update conflicts happen when two transactions that originate from different databases update the same row at nearly the same time. Replicat detects an update conflict when there is a difference between the old values (the before values) that are stored in the trail record and the current values of the same row in the target database.

  • A delete conflict occurs when two transactions originate at different databases, and one deletes a row while the other updates or deletes the same row. In this case, the row does not exist to be either updated or deleted. Replicat cannot find the row because the primary key does not exist.

For example, UserA on DatabaseA updates a row, and UserB on DatabaseB updates the same row. If UserB's transaction occurs before UserA's transaction is synchronized to DatabaseB, there will be a conflict on the replicated transaction.

A more complicated example involves three databases and illustrates a more complex ordering conflict. Assume three databases A, B, and C. Suppose a user inserts a row at database A, which is then replicated to database B. Another user then modifies the row at database B, and the row modification is replicated to database C. If the row modification from B arrives at database C before the row insert from database A, C will detect a conflict.

Where possible, try to minimize or eliminate any chance of conflict. Some ways to do so are:

  • Configure the applications to restrict which columns can be modified in each database. For example, you could limit access based on geographical area, such as by allowing different sales regions to modify only the records of their own customers. As another example, you could allow a customer service application on one database to modify only the NAME and ADDRESS columns of a customer table, while allowing a financial application on another database to modify only the BALANCE column. In each of those cases, there cannot be a conflict caused by concurrent updates to the same record.

  • Keep synchronization latency low. If UserA on DatabaseA and UserB on DatabaseB both update the same rows at about the same time, and UserA's transaction gets replicated to the target row before UserB's transaction is completed, conflict is avoided. See Chapter 19, "Tuning the Performance of Oracle GoldenGate" for suggestions on improving the performance of the Oracle GoldenGate processes.

To avoid conflicts, replication latency must be kept as low as possible. When conflicts are unavoidable, they must be identified immediately and resolved with as much automation as possible, either through the Oracle GoldenGate Conflict Detection and Resolution (CDR) feature, or through methods developed on your own. Custom methods can be integrated into Oracle GoldenGate processing through the SQLEXEC and user exit functionality. See Chapter 10, "Configuring Conflict Detection and Resolution" for more information about using Oracle GoldenGate to handle conflicts.

9.5 Additional Information

The following documentation provides additional information of relevance to configuring Oracle GoldenGate.

9.6 Creating an Active-Active Configuration

Refer to Figure 9-1 for a visual representation of the objects you will be creating.

Figure 9-1 Oracle GoldenGate Configuration for Active-active Synchronization

Description of Figure 9-1 follows
Description of "Figure 9-1 Oracle GoldenGate Configuration for Active-active Synchronization"

9.6.1 Prerequisites on Both Systems

Perform these prerequisite tasks on both systems:

  1. Create a Replicat checkpoint table (unless using Oracle integrated Replicat). See Section 14.3, "Creating a Checkpoint Table" for instructions.

  2. Configure the Manager process. See Chapter 3, "Configuring Manager and Network Communications" for instructions.

9.6.2 Configuration from Primary System to Secondary System

These steps add the processes necessary to send data from the primary system to the secondary database.

To configure the primary Extract group

Perform these steps on the primary system.

  1. Use the ADD EXTRACT command to create a primary Extract group. For documentation purposes, this group is called ext_1.

    ADD EXTRACT ext_1, {TRANLOG | INTEGRATED TRANLOG}, BEGIN time
    

    See Reference for Oracle GoldenGate for Windows and UNIX for detailed information about these and other ADD EXTRACT options that may be required for your installation.

  2. Use the ADD EXTTRAIL command to add a local trail. For documentation purposes, this trail is called local_trail_1.

    ADD EXTTRAIL local_trail_1, EXTRACT ext_1
    

    For EXTRACT, specify the ext_1 group to write to this trail

  3. Use the EDIT PARAMS command to create a parameter file for the ext_1 group. Include the following parameters plus any others that apply to your database environment. For possible additional required parameters, see the Oracle GoldenGate installation and setup guide for your database.

    -- Identify the Extract group:
    EXTRACT ext_1
    -- Specify database login information as needed for the database:
    [SOURCEDB dsn_1][, USERIDALIAS alias]
    -- Specify the local trail that this Extract writes to
    -- and the encryption algorithm:
    ENCRYPTTRAIL algorithm
    EXTTRAIL local_trail_1
    -- Exclude Replicat transactions. Uncomment ONE of the following:
    -- DB2 z/OS, DB2 LUW, DB2 IBM i, Oracle (classic capture), and 
    -- Sybase:
    -- TRANLOGOPTIONS EXCLUDEUSER Replicat_user
    -- Oracle (classic capture) alternative to EXCLUDEUSER:
    -- EXCLUDEUSERID Oracle_uid
    -- Oracle integrated capture:
    -- EXCLUDETAG tag
    -- SQL Server and Sybase:
    -- TRANLOGOPTIONS EXCLUDETRANS transaction_name
    -- SQL/MX:
    -- TRANLOGOPTIONS FILTERTABLE checkpoint_table_name
    -- Teradata:
    -- SQLEXEC 'SET SESSION OVERRIDE REPLICATION ON;'
    -- SQLEXEC 'COMMIT;'
    -- Specify API commands if Teradata:
    VAM library name, PARAMS ('param' [, 'param'] [, ...])
    -- Capture before images for conflict resolution:
    GETBEFORECOLS (ON operation {ALL | KEY | KEYINCLUDING (col_list) | ALLEXCLUDING (col_list)})
    -- Log all scheduling columns for CDR and if using integrated Replicat
    LOGALLSUPCOLS
    -- Specify tables to be captured and (optional) columns to fetch:
    TABLE [container.|catalog.]owner.* [, FETCHCOLS cols | FETCHCOLSEXCEPT cols];
    

To configure the data pump

Perform these steps on the primary system.

  1. 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
    

    For EXTTRAILSOURCE, specify local_trail_1 as the data source.

  2. Use the ADD RMTTRAIL command to add a remote trail that will be created on the secondary system. For documentation purposes, this trail is called remote_trail_1.

    ADD RMTTRAIL remote_trail_1, EXTRACT pump_1
    

    For EXTRACT, specify the pump_1 data pump to write to this trail.

    See Reference for Oracle GoldenGate for Windows and UNIX for additional ADD RMTTRAIL options.

  3. Use the EDIT PARAMS command to create a parameter file for the pump_1 group. 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 as needed for the database:
    [SOURCEDB dsn_1][, USERIDALIAS alias]
    -- Decrypt the data only if the data pump must process it.
    -- DECRYPTTRAIL
    -- Specify the name or IP address of the secondary system
    -- and optional encryption of data over TCP/IP:
    RMTHOSTOPTIONS system_2, MGRPORT port_number, ENCRYPT encryption_options
    -- Specify remote trail and encryption algorithm on secondary system:
    ENCRYPTTRAIL algorithm
    RMTTRAIL remote_trail_1
    -- Pass data through without mapping, filtering, conversion:
    PASSTHRU
    -- Specify tables to be captured:
    TABLE [container.|catalog.]owner.*;
    

    Note:

    Because data structures are usually identical in a bi-directional configuration, PASSTHRU mode improves performance.

To configure the Replicat group

Perform these steps on the secondary system.

  1. Use the ADD REPLICAT command to create a Replicat group. For documentation purposes, this group is called rep_1.

    ADD REPLICAT rep_1
    [, INTEGRATED | COORDINATED [MAXTHREADS number]]
    , EXTTRAIL remote_trail_1, BEGIN time
    

    For EXTTRAIL, specify remote_trail_1 as the trail that this Replicat reads.

    See Reference for Oracle GoldenGate for Windows and UNIX for detailed information about these and other options that may be required for your installation.

  2. Use the EDIT PARAMS command to create a parameter file for the rep_1 group. Include the following parameters plus any others that apply to your database environment. For possible additional required parameters, see the Oracle GoldenGate installation and setup guide for your database.

    -- Identify the Replicat group:
    REPLICAT rep_1
    -- State that source and target definitions are identical:
    ASSUMETARGETDEFS
    -- Specify database login information as needed for the database:
    [TARGETDB dsn_2][, USERIDALIAS alias]
    -- Specify error handling rules:
    REPERROR (error, response)
    -- Set non-default Replicat redo tag (if Extract is in integrated mode)
    -- Default is 00.
    SETTAG tag_value
    -- Specify tables for delivery, threads if coordinated Replicat 
    -- and conflict-resolution:
    MAP [container.|catalog.]owner.*, TARGET owner.*, COMPARECOLS (ON operation {ALL | KEY | KEYINCLUDING (col_list) | ALLEXCLUDING (col_list)}), RESOLVECONFLICT (conflict type (resolution_name, resolution_type COLS (col[,...]))
    [, THREAD (thread_ID)]
    [, THREADRANGE (thread_range[, column_list])]
    ;
    -- Specify mapping of exceptions to exceptions table:
    MAP [container.|catalog.]owner.*, TARGET owner.exceptions, EXCEPTIONSONLY;
    

9.6.3 Configuration from Secondary System to Primary System

These steps add the processes necessary to send data from the secondary system to the primary database.

To configure the primary Extract group

Perform these steps on the secondary system.

Note:

This is a reverse image of the configuration that you just created.

  1. Use the ADD EXTRACT command to create a primary Extract group. For documentation purposes, this group is called ext_2.

    ADD EXTRACT ext_2, {TRANLOG | INTEGRATED TRANLOG}, BEGIN time
    

    See Reference for Oracle GoldenGate for Windows and UNIX for detailed information about these and other ADD EXTRACT options that may be required for your installation.

  2. Use the ADD EXTTRAIL command to add a local trail. For documentation purposes, this trail is called local_trail_2.

    ADD EXTTRAIL local_trail_2, EXTRACT ext_2
    

    For EXTRACT, specify the ext_2 group to write to this trail.

  3. Use the EDIT PARAMS command to create a parameter file for the ext_2 group. Include the following parameters plus any others that apply to your database environment. For possible additional required parameters, see the Oracle GoldenGate installation and setup guide for your database.

    -- Identify the Extract group:
    EXTRACT ext_2
    -- Specify database login information as needed for the database:
    [SOURCEDB dsn_2][, USERIDALIAS alias]
    -- Specify the local trail that this Extract writes to
    -- and the encryption algorithm:
    ENCRYPTTRAIL algorithm
    EXTTRAIL local_trail_2 
    -- Exclude Replicat transactions. Uncomment ONE of the following:
    -- DB2 z/OS, DB2 LUW, DB2 IBM i, Oracle, and Sybase:
    -- TRANLOGOPTIONS EXCLUDEUSER Replicat_user
    -- Oracle alternative to EXCLUDEUSER:
    -- EXCLUDEUSERID Oracle_uid
    -- Oracle integrated capture:
    -- EXCLUDETAG tag
    -- SQL Server and Sybase:
    -- TRANLOGOPTIONS EXCLUDETRANS transaction_name
    -- SQL/MX:
    -- TRANLOGOPTIONS FILTERTABLE checkpoint_table_name
    -- Teradata:
    -- SQLEXEC 'SET SESSION OVERRIDE REPLICATION ON;'
    -- SQLEXEC 'COMMIT;'
    -- Oracle:
    -- TRACETABLE trace_table_name
    -- Log all scheduling columns for CDR and if using integrated Replicat
    LOGALLSUPCOLS
    -- Capture before images for conflict resolution:
    GETBEFORECOLS (ON operation {ALL | KEY | KEYINCLUDING (col_list) | ALLEXCLUDING (col_list)})
    -- Specify tables to be captured and (optional) columns to fetch:
    TABLE [container.|catalog.]owner.* [, FETCHCOLS cols | FETCHCOLSEXCEPT cols];
    

    Note:

    To replicate Oracle DBFS data, specify the internally generated local read-write DBFS tables in the TABLE statement on each node. For more information on identifying these tables and configuring DBFS for propagation by Oracle GoldenGate, see Installing and Configuring Oracle GoldenGate for Oracle Database.

To configure the data pump

Perform these steps on the secondary system.

  1. Use the ADD EXTRACT command to create a data pump group. For documentation purposes, this group is called pump_2.

    ADD EXTRACT pump_2, EXTTRAILSOURCE local_trail_2, BEGIN time
    

    For EXTTRAILSOURCE, specify local_trail_2 as the data source.

  2. Use the ADD RMTTRAIL command to add a remote trail that will be created on the primary system. For documentation purposes, this trail is called remote_trail_2.

    ADD RMTTRAIL remote_trail_2, EXTRACT pump_2
    

    For EXTRACT, specify the pump_2 data pump to write to this trail.

    See Reference for Oracle GoldenGate for Windows and UNIX for additional ADD RMTTRAIL options.

  3. Use the EDIT PARAMS command to create a parameter file for the pump_2 group. Include the following parameters plus any others that apply to your database environment.

    -- Identify the data pump group:
    EXTRACT pump_2
    -- Specify database login information as needed for the database:
    [SOURCEDB dsn_2][, USERIDALIAS alias]
    -- Decrypt the data only if the data pump must process it.
    -- DECRYPTTRAIL
    -- Specify the name or IP address of the primary system
    -- and optional encryption of data over TCP/IP:
    RMTHOSTOPTIONS system_1, MGRPORT port_number, ENCRYPT encryption_options
    -- Specify the remote trail and encryption algorithm on the primary system:
    ENCRYPTTRAIL algorithm
    RMTTRAIL remote_trail_2 
    -- Pass data through without mapping, filtering, conversion:
    PASSTHRU
    -- Specify tables to be captured:
    TABLE [container.|catalog.]owner.*;
    

    Note:

    To replicate Oracle DBFS data, specify the internally generated local read-write DBFS tables in the TABLE statement on each node. For more information on identifying these tables and configuring DBFS for propagation by Oracle GoldenGate, see Installing and Configuring Oracle GoldenGate for Oracle Database.

To configure the Replicat group

Perform these steps on the primary system.

  1. Use the ADD REPLICAT command to create a Replicat group. For documentation purposes, this group is called rep_2.

    ADD REPLICAT rep_2
    [, INTEGRATED | COORDINATED [MAXTHREADS number]]
    , EXTTRAIL remote_trail_2, BEGIN time
    

    For EXTTRAIL, specify remote_trail_2 as the trail that this Replicat reads.

    See Reference for Oracle GoldenGate for Windows and UNIX for detailed information about these and other options that may be required for your installation.

  2. Use the EDIT PARAMS command to create a parameter file for the rep_2 group. Include the following parameters plus any others that apply to your database environment. For possible additional required parameters, see the Oracle GoldenGate installation and setup guide for your database.

    -- Identify the Replicat group:
    REPLICAT rep_2
    -- State that source and target definitions are identical:
    ASSUMETARGETDEFS
    -- Specify database login information as needed for the database:
    [TARGETDB dsn_1][, USERIDALIAS alias]
    -- Specify error handling rules:
    REPERROR (error, response)
    -- Specify tables for delivery, threads if coordinated Replicat 
    -- and conflict-resolution:
    MAP [container.|catalog.]owner.*, TARGET owner.*, COMPARECOLS (ON operation {ALL | KEY | KEYINCLUDING (col_list) | ALLEXCLUDING (col_list)}), RESOLVECONFLICT (conflict type (resolution_name, resolution_type COLS (col[,...]))
    [, THREAD (thread_ID)]
    [, THREADRANGE (thread_range[, column_list])]
    ;
    -- Specify mapping of exceptions to exceptions table:
    MAP [container.|catalog.]owner.*, TARGET owner.exceptions, EXCEPTIONSONLY;
    

    Note:

    To replicate Oracle DBFS data, specify the internally generated local read-write DBFS tables in the TABLE statement on each node. For more information on identifying these tables and configuring DBFS for propagation by Oracle GoldenGate, see Installing and Configuring Oracle GoldenGate for Oracle Database.

Close Window

Table of Contents

Administering Oracle GoldenGate for Windows and UNIX

Expand | Collapse