7 Configuring Oracle GoldenGate Apply

This chapter contains instructions for configuring the Replicat apply process in either nonintegrated or integrated mode.


7.1 Prerequisites for Configuring Replicat

This topic provides the best practices for configuring Replicat.

The guidelines to follow before configuring Replicat are:

  1. Preparing the Database for Oracle GoldenGate.

  2. Establishing Oracle GoldenGate Credentials.

  3. Choosing Capture and Apply Modes.

  4. Create the Oracle GoldenGate instance on the target system by configuring the Manager process.

See How to Add a Replicat in Using the Oracle GoldenGate Microservices Architecture.


To switch an active Replicat configuration from one mode to the other, perform these configuration steps and then see Administering Oracle GoldenGate.

7.2 What to Expect from these Instructions

These instructions show you how to configure a basic Replicat parameter (configuration) file.

Your business requirements probably will require a more complex topology, but this procedure forms a basis for the rest of your configuration steps.

By performing these steps, you can:

  • get the basic configuration file established.

  • build upon it later by adding more parameters as you make decisions about features or requirements that apply to your environment.

  • use copies of it to make the creation of additional Replicat parameter files faster than starting from scratch.


These instructions do not configure Replicat to apply DDL to the target. To support DDL, create the basic Replicat parameter file and then see Configuring DDL Support for configuration instructions.

7.3 Creating a Checkpoint Table

The checkpoint table is a required component of Replicat.

A Replicat maintains its recovery checkpoints in the checkpoint table, which is stored in the target database. Checkpoints are written to the checkpoint table within the Replicat transaction. Because a checkpoint either succeeds or fails with the transaction, Replicat ensures that a transaction is only applied once, even if there is a failure of the process or the database. See Before Creating Replicat in the Using the Oracle GoldenGate Microservices Architecture to learn to create checkpoint tables from the Microservices web UI.


This procedure installs a default checkpoint table, which is sufficient in most cases. More than one checkpoint table can be used, such as to use a different one for each Replicat group. To use a non-default checkpoint table, which overrides the default table, use the CHECKPOINTTABLE option of ADD REPLICAT when you create Replicat processes in the steps in Instantiating Oracle GoldenGate Replication. .

7.3.1 Adding the Checkpoint Table to the Target Database

  1. From the Oracle GoldenGate directory on the target, run GGSCI and issue the DBLOGIN command to log into the target database.


    • alias specifies the alias of the database login credential of a user that can create tables in a schema that is accessible to Replicat. This credential must exist in the Oracle GoldenGate credential store. For more information, see Establishing Oracle GoldenGate Credentials.

  2. In GGSCI, create the checkpoint table in a schema of your choice (ideally dedicated to Oracle GoldenGate).
    ADD CHECKPOINTTABLE [container.]schema.table


    • container is the name of the container if schema.table is in a multitenant container database. This container can be the root container or a pluggable database that contains the table.

    • schema.table are the schema and name of the table. See Administering Oracle GoldenGate for instructions for specifying object names.

7.3.2 Specifying the Checkpoint Table in the Oracle GoldenGate Configuration

To specify the checkpoint table in the Oracle GoldenGate configuration:

  1. Create a GLOBALS file (or edit the existing one).


    EDIT PARAMS creates a simple text file. When you save the file after EDIT PARAMS, it is saved with the name GLOBALS in upper case, without a file extension. It must remain as such, and the file must remain in the root Oracle GoldenGate directory.

  2. In the GLOBALS file, enter the CHECKPOINTTABLE parameter.
    CHECKPOINTTABLE [container.]schema.table
  3. Save and close the GLOBALS file.

7.3.3 Disabling Default Asynchronous COMMIT to Checkpoint Table

When a nonintegrated Replicat uses a checkpoint table, it uses an asynchronous COMMIT with the NOWAIT option to improve performance. Replicat can continue processing immediately after applying this COMMIT, while the database logs the transaction in the background. You can disable the asynchronous COMMIT with NOWAIT by using the DBOPTIONS parameter with the DISABLECOMMITNOWAIT option in the Replicat parameter file.


When the configuration of a nonintegrated Replicat group does not include a checkpoint table, the checkpoints are maintained in a file on disk. In this case, Replicat uses COMMIT with WAIT to prevent inconsistencies in the event of a database failure that causes the state of the transaction, as in the checkpoint file, to be different than its state after the recovery.

7.4 Configuring Replicat

Configure a Replicat process to configure Replicat against a pluggable database. Replicat can operate in any mode within a pluggable database.

These steps configure the Replicat process.

  1. In GGSCI on the target system, create the Replicat parameter file.
    EDIT PARAMS name

    Where: name is the name of the Replicat group.

  2. Enter the Replicat parameters in the order shown, starting a new line for each parameter statement. See Table 7-* for descriptions.

    Basic parameters for the Replicat group in nonintegrated mode:

    REPLICAT financer
    USERIDALIAS tiger2
    MAP hr.*, TARGET hr2.*;

    Basic parameters for the Replicat group in integrated Replicat mode:

    REPLICAT financer
    USERIDALIAS tiger2
    MAP hr.*, TARGET hr2.*;
    Parameter Description
    REPLICAT group

    group is the name of the Replicat group.


    Applies to Replicat in nonintegrated mode. DEFERREFCONST sets constraints to DEFERRABLE to delay the enforcement of cascade constraints by the target database until the Replicat transaction is committed. See Reference for Oracle GoldenGate for additional important information.


    This parameter specification applies to Replicat in integrated mode. It specifies optional parameters for the inbound server.

    See Optional Parameters for Integrated Modesfor additional important information about these DBOPTIONS options.


    Specifies the alias of the database login credential of the user that is assigned to Replicat. This credential must exist in the Oracle GoldenGate credential store. For more information, see Establishing Oracle GoldenGate Credentials

    MAP [container.]schema.object, TARGET schema.object;

    Specifies the relationship between a source table or sequence, or multiple objects, and the corresponding target object or objects.

    • MAP specifies the source table or sequence, or a wildcarded set of objects.

    • TARGET specifies the target table or sequence or a wildcarded set of objects.

    • container is the name of a container, if the source database is a multitenant container database.

    • schema is the schema name or a wildcarded set of schemas.

    • object is the name of a table or sequence, or a wildcarded set of objects.

    Terminate this parameter statement with a semi-colon.

    To exclude objects from a wildcard specification, use the MAPEXCLUDE parameter.

    For more information and for additional options that control data filtering, mapping, and manipulation, see MAP in Reference for Oracle GoldenGate.

  3. If using integrated Replicat or parallel Replicat in integrated mode, add the following parameters to the Extract parameter file:
    • LOGALLSUPCOLS: This parameter ensures the capture of the supplementally logged columns in the before image. It's the default parameter and shouldn't be turned off or disabled. It is valid for any source database that is supported by Oracle GoldenGate. For Extract versions older than 12c, you can use GETUPDATEBEFORES and NOCOMPRESSDELETES parameters to satisfy the same requirement. The database must be configured to log the before and after values of the primary key, unique indexes, and foreign keys.

    • The UPDATERECORDFORMAT parameter set to COMPACT: This setting causes Extract to combine the before and after images of an UPDATE operation into a single record in the trail. This is the default option and it is recommended that you don't change the default setting.

  4. Enter any optional Replicat parameters that are recommended for your configuration. You can edit this file at any point before starting processing by using the EDIT PARAMS command in GGSCI. For more information, see the Reference for Oracle GoldenGate and Optional Parameters for Integrated Modes for additional configuration considerations..
  5. Save and close the file.


See Administering Oracle GoldenGate for important information about making configuration changes to Replicat once processing is started, if using integrated Replicat.

7.5 Next Steps

Once you have created a basic parameter file for Replicat, see the following for additional configuration steps.