4 Deploying New Features of Version 12.1.2

4.3.1 Procedure Overview

This procedure makes use of the EVENTACTIONS parameter with a STOP action, which enables all of the Replicat processes to stop at the same point in the trail. The EVENTACTIONS action is triggered by a transaction that contains an INSERT to a dummy table. The INSERT causes each process to finish processing everything up to, and including, the event transaction and then stop cleanly. An additional event action of IGNORE is specified for Replicat to prevent the parallel Replicat processes from attempting to insert the same record to the target. The result of this procedure is that all processes stop at the same point in the data stream: after completing the INSERT transaction to the dummy table.

After the processes stop, you move all of the TABLE statements to one primary Extract group. You move the same TABLE statements to the data pump that reads the trail of the Extract group that you retained. You move all of the MAP statements to a new coordinated Replicat group that reads the remote trail that is associated with the retained data pump. Once all of the MAP statements are in one parameter file, you edit them to add the thread specifications to support a coordinated Replicat. (This can be done ahead of time.) Then you drop the Replicat group and add it back in coordinated mode with the same name.

4.3.2 Performing the Switch to Coordinated Replicat

To perform the switch to coordinated Replicat:

1. Review the configuration requirements for using a coordinated Replicat in Administering Oracle GoldenGate for Windows and UNIX. Do not create the Replicat group until prompted by these instructions.

2. Back up the current parameter files of all of the Extract groups, data pumps, and Replicat groups. You will be editing them.

3. Create a working directory outside the Oracle GoldenGate directory. You will use this directory to create and stage new versions of the parameter files. If needed, you can create a working directory on the source and target systems.

4. In the working directory, create a parameter file for a coordinated Replicat. Copy the MAP parameters from the active parameter files of all of the Replicat groups to this parameter file, and then add the thread specifications and any other parameters that support your required coordinated Replicat configuration

5. If using parallel primary Extract groups, select one to keep, and then save a copy of its current parameter file to the working directory.

6. Copy all of the TABLE statements from the other Extract groups to the new parameter file of the primary Extract that you are keeping.

7. In the working directory, save a copy of the parameter file of the data pump that is linked to the primary Extract that you are keeping.

8. Copy all of the TABLE statements from the other data pumps to the copied parameter file of the kept data pump.

9. In the source database, create a simple dummy table on which a simple INSERT statement can be performed. For this procedure, the name schema.event is used.

10. Edit the active parameter files (not the copies) of all primary and data-pump Extract groups to add the following EVENTACTIONS parameter to each one.

    TABLE schema.event, EVENTACTIONS(STOP);
    

11. Edit the active parameter files (not the copies) of all of the Replicat groups to add the following EVENTACTIONS parameter to each one.

    MAP schema.event, TARGET schema.event, EVENTACTIONS(IGNORE, STOP);
    

12. Stop the Oracle GoldenGate processes gracefully in the following order:

    • Stop all Replicat processes.

    • Stop all data pumps.

    • Stop all Extract processes.

13. Restart the Oracle GoldenGate processes in the following order so that the EVENTACTIONS parameters take effect:

    • Start all Extract processes.

    • Start all data pumps.

    • Start all Replicat processes.

14. On the source system, issue a transaction on the schema.event table that contains one INSERT statement. Make certain to commit the transaction.

15. In GGSCI, issue the STATUS command for all of the primary Extract and data pump processes on the source system, and issue the same command for all of the Replicat processes on the target system, until the commands show that all of the processes are STOPPED.

    STATUS EXTRACT *
    STATUS REPLICAT *
    

16. Replace the active parameter files of the primary Extract and data pump that you kept with the new parameter files from the working directory.

17. Delete the unneeded Extract and data pump groups and their parameter files.

18. Log into the target database by using the DBLOGIN command.

    GGSCI> DBLOGIN {USERID {/ | userid}[, PASSWORD password]   [algorithm ENCRYPTKEY {keyname | DEFAULT}] |USERIDALIAS alias [DOMAIN domain]} 
    

19. Delete all of the Replicat groups and their active parameter files.

20. Copy or move the new coordinated Replicat parameter file from the working directory to the Oracle GoldenGate directory.

21. In GGSCI, issue the INFO EXTRACT command for the data pump and make note of its write checkpoint position in the output (remote) trail.

    INFO EXTRACT pump, DETAIL
    

22. Add a new coordinated Replicat group with the following parameters.

    ADD REPLICAT group, EXTTRAIL trail, EXTSEQNO sequence_number, EXTRBA rba, COORDINATED MAXTHREADS number [, CHECKPOINTTABLE owner.table]
    

    where:

    • group is the name of the coordinated Replicat group. The name must match that of the new parameter file created for this group.

    • EXTTRAIL trail is the name of the trail that the data pump writes to.

    • EXTSEQNO sequence_number is the sequence number of the trail as shown in the write checkpoint returned by the INFO EXTRACT that you issued for the data pump.

    • EXTRBA rba is the relative byte address in the trail as shown in the write checkpoint returned by INFO EXTRACT. Together, these position Replicat to resume processing at the correct point in the trial.

    • MAXTHREADS number specifies the maximum number of threads allowed for this group. This value should be appropriate for the number of threads that are specified in the parameter file.

    • CHECKPOINTTABLE owner.table provide the option to specify a checkpoint table specifically for this Replicat group, rather than use the checkpoint table specified with the GLOBALS parameter CHECKPOINTTABLE.

23. Start the primary Extract group.

24. Start the data pump group.

25. Start the coordinated Replicat group.