Initial loading using GoldenGate - Part 1

The files being converted ranged from several hundred megabytes to over 10 gigabytes for the primary file. Adding more alternate keys automatically called for a larger alternate key file, in some cases larger than the primary file, due to the nature, size and number of keys contained within.
Sizing studies were done to estimate, design and create the correct file type (Type 2 in this case) size and extent specifications.

Once these tasks were complete the files were created on the Primary or Source system and available for data loads. GoldenGate replication immediately created identical files on the Target or DR site.

Initial load was accomplished by configuring a GoldenGate Extract/Replicat Data Pump to read directly from the Source file(s) and write to the new primary and alternate key files. This method used Enscribe to generate the new alternate keys as the new primary file was being loaded.

GoldenGate provides the ability to load files unattended or "no wait" and provides restart capabilities if the load stops or fails to complete. Two big advantages while loading multiple large files concurrently, since the data load can be setup to run at times of low system activity i.e. evening or overnight.
Additionally, the ability of GoldenGate to use TMF Audit Buffers by turning on the Audit flag for the target files, greatly speeds up the process of loading using the direct data pump method.

Previous loads using FUP were subject to failure in the event a dynamic terminal session window closed unexpectedly or a file extent allocation failure, and since FUP doesn't possess restart capability on a file load, GoldenGate was the better choice.

Data pump loads were performed from the Source files to the new Source files on the Primary system first, to avoid any contention or locking the Target files were initialized after all of the source files had completed initial loads.

While the loads were executing, no user impact was observed. Performance of the primary systems was normal and not impacted by the file loading.

During the file loads, database operations were always being captured and replicated to the Target site, this these changes captured during the load were then applied to the new primary and alternate key files after the initial load was finished. At this point both the source/new source and the target/new target files were all in sync, the differences at this point involved the alternate key files for each database file, in that source and target alternate key files only contained 2 alternate keys values and new source and new target alternate key files had 8 values. Success.

Next I'll examine verification and validation procedures before performing the file switch.