6 Instantiating Oracle GoldenGate Replication
Topics:
- Overview of the Instantiation Process
In the instantiation procedure, you make a copy of the source data and load the copy to the target database. - Prerequisites for Instantiation
The following steps must be taken before starting any Oracle GoldenGate processes or native database load processes. - Configuring the Initial Load for Microservices Architecture
- Performing the Target Instantiation
This procedure instantiates the target tables while Oracle GoldenGate captures ongoing transactional changes on the source and stores them until they can be applied on the target. - Verifying Synchronization
To verify that the source and target data are synchronized, you can use the Oracle GoldenGate Veridata product or use your own scripts to select and compare source and target data. - Backing up the Oracle GoldenGate Environment
After you start Oracle GoldenGate processing, an effective backup routine is critical to preserving the state of processing in the event of a failure. Unless the Oracle GoldenGate working files can be restored, the entire replication environment must be re-instantiated, complete with new initial loads.
Overview of the Instantiation Process
In the instantiation procedure, you make a copy of the source data and load the copy to the target database.
The initial load captures a point-in-time snapshot of the data, while Oracle GoldenGate maintains that consistency by applying transactional changes that occur while the static data is being loaded. After instantiation is complete, Oracle GoldenGate maintains the synchronized state throughout ongoing transactional changes.
When you instantiate Oracle GoldenGate processing, it is recommended that you do so first in a test environment before deploying live on your production machines. This is especially important in an active-active or high availability configuration, where trusted source data may be touched by the replication processes. Testing enables you to find and resolve any configuration mistakes or data issues without the need to interrupt user activity for re-loads on the target or other troubleshooting activities. Testing also ensures that your instantiation process is configured properly. Parameter files can be copied to the production equipment after successful testing, and then you can perform a predictable instantiation with production data.
Parent topic: Instantiating Oracle GoldenGate Replication
Prerequisites for Instantiation
The following steps must be taken before starting any Oracle GoldenGate processes or native database load processes.
- Configuring and Adding Change Synchronization Groups
- Disabling DDL Processing
- Adding Collision Handling
- Preparing the Target Tables
Parent topic: Instantiating Oracle GoldenGate Replication
Configuring and Adding Change Synchronization Groups
To perform an instantiation of the target database and the replication environment, the online change capture and apply groups must exist and be properly configured. See:
Parent topic: Prerequisites for Instantiation
Disabling DDL Processing
You must disable DDL activities before performing an instantiation. You can resume DDL after the instantiation is finished.
Parent topic: Prerequisites for Instantiation
Adding Collision Handling
This prerequisite applies to the following instantiation methods:
This prerequisite does not
apply to the instantiation method described in Configuring a Load with an Oracle Data Pump.
If the source database will remain active during one of those initial load methods, collision-handling logic must be added to the Replicat parameter file. This logic handles conflicts that occur because static data is being loaded to the target tables while Oracle GoldenGate replicates transactional changes to those tables.
To handle collisions, add the HANDLECOLLISIONS
parameter to the Replicat parameter file to resolve these collisions:
-
INSERT
operations for which the row already exists -
UPDATE
andDELETE
operations for which the row does not exist
HANDLECOLLISIONS
should be removed from the Replicat parameter file
at the end of the instantiation steps (as prompted in the instructions).
To use the HANDLECOLLISIONS
function to reconcile incremental data
changes with the load, each target table must have a primary or unique key. If you
cannot create a key through your application, use the KEYCOLS
option of the TABLE
and MAP
parameters to specify
columns as a substitute key for Oracle GoldenGate to use. If you cannot create keys,
the affected source table must be quiesced for the load.
Parent topic: Prerequisites for Instantiation
Preparing the Target Tables
The following are suggestions that can make the load go faster and help you to avoid errors.
-
Data: Make certain that the target tables are empty. Otherwise, there may be duplicate-row errors or conflicts between existing rows and rows that are being loaded.
-
Indexes: Remove indexes from the target tables. Indexes are not necessary for the inserts performed by the initial load process and will slow it down. You can add back the indexes after the load is finished.
Parent topic: Prerequisites for Instantiation
Configuring the Initial Load for Microservices Architecture
Configuring initial load Extract can be performed from the Oracle GoldenGate MA web interface or Admin Client.
To configure from the Oracle GoldenGate MA web interface, see Instantiating with Initial Load Extract in Oracle GoldenGate Microservices Documentation.
Parent topic: Instantiating Oracle GoldenGate Replication
Performing the Target Instantiation
This procedure instantiates the target tables while Oracle GoldenGate captures ongoing transactional changes on the source and stores them until they can be applied on the target.
By the time you perform the instantiation of the target tables, the entire Oracle GoldenGate environment should be configured for change capture and delivery, as should the initial-load processes if using Oracle GoldenGate as an initial-load utility.
Note:
The first time that Extract starts in a new Oracle GoldenGate configuration, any open source transactions will be skipped. Only transactions that begin after Extract starts are captured.
- Performing Instantiation with Oracle Data Pump
- Performing Instantiation with Direct Bulk Load to SQL*Loader
- Performing Instantiation From an Input File to SQL*Loader
- Monitoring and Controlling Processing After the Instantiation
After the target is instantiated and replication is in effect, you can control processes and view the overall health of the replication environment.
Parent topic: Instantiating Oracle GoldenGate Replication
Performing Instantiation with Oracle Data Pump
To perform instantiation with Oracle Data Pump, see My Oracle Support document 1276058.1. To obtain this document, do the following:
- Go to
http://support.oracle.com
. - Under Sign In, select your language and then log in with your Oracle Single Sign-On (SSO).
- On the Dashboard, expand the Knowledge Base heading.
- Under Enter Search Terms, paste or type the document ID of
1276058.1
and then click Search. - In the search results, select Oracle GoldenGate Best Practices: Instantiation from an Oracle Source Database [Article ID 1276058.1].
- Click the link under Attachments to open the article.
Parent topic: Performing the Target Instantiation
Performing Instantiation with Direct Bulk Load to SQL*Loader
From this point forward, Oracle GoldenGate continues to synchronize data changes.
Parent topic: Performing the Target Instantiation
Performing Instantiation From an Input File to SQL*Loader
Note:
The SQL*Loader method is not recommended if the data has multibyte characters, especially when the character set of the operating system is different from the database character set.
From this point forward, Oracle GoldenGate continues to synchronize data changes.
Parent topic: Performing the Target Instantiation
Monitoring and Controlling Processing After the Instantiation
After the target is instantiated and replication is in effect, you can control processes and view the overall health of the replication environment.
If you configured Replicat in integrated mode, you can use the
STATS REPLICAT
command to view statistics on the number of
transactions that are applied in integrated mode as compared to those that are
applied in direct apply mode.
STATS REPLICAT group
The output of this command shows the number of transactions applied, the number of transactions that were redirected to direct apply, and the direct transaction ratio, among other statistics. The statistics help you determine whether integrated Replicat is performing as intended. If the environment is satisfactory and there is a high ratio of direct apply operations, consider using nonintegrated Replicat. You can configure parallelism with nonintegrated Replicat.
Note:
To ensure realistic statistics, view apply statistics only after you are certain that the Oracle GoldenGate environment is well established, that configuration errors are resolved, and that any anticipated processing errors are being handled properly.
You can also view runtime statistics for integrated Replicat in the
V$
views for each of the inbound server components.
-
The reader statistics are recorded in
V$GG_APPLY_READER
and include statistics on number of messages read, memory used, and dependency counts. -
The apply coordinator statistics are recorded in
V$GG_APPLY_COORDINATOR
and record statistics at the transaction level. -
The apply server statistics are recorded in
V$GG_APPLY_SERVER
. This view records information for each of the apply server processes (controlled byparallelism
andmax_parallelism
parameters) as separate rows. The statistics for each apply server are identified by theSERVER_ID
column. If aSERVER_ID
of0
exists, this represents an aggregate of any apply servers that exited because the workload was reduced. -
Statistics about the number of messages received by the database from Replicat are recorded in the
V$GG_APPLY_RECEIVER
table.
To control processes, see Controlling Oracle GoldenGate Processes in Administering Oracle GoldenGate.
To ensure that all processes are running properly and that errors are being handled according to your error handling rules, see Handling Processing Errors in Administering Oracle GoldenGate. Oracle GoldenGate provides commands and logs to view process status, lag, warnings, and other information.
To know more about querying the following views, see Oracle Database Reference.
-
V$GOLDENGATE_TABLE_STATS
to see statistics for DML and collisions that occurred for each replicated table that the inbound server processed. -
V$GOLDENGATE_TRANSACTION
to see information about transactions that are being processed by Oracle GoldenGate inbound servers.
Parent topic: Performing the Target Instantiation
Verifying Synchronization
To verify that the source and target data are synchronized, you can use the Oracle GoldenGate Veridata product or use your own scripts to select and compare source and target data.
Parent topic: Instantiating Oracle GoldenGate Replication
Backing up the Oracle GoldenGate Environment
After you start Oracle GoldenGate processing, an effective backup routine is critical to preserving the state of processing in the event of a failure. Unless the Oracle GoldenGate working files can be restored, the entire replication environment must be re-instantiated, complete with new initial loads.
As a best practice, include the entire Oracle GoldenGate home installation in your backup routines. There are too many critical sub-directories, as well as files and programs at the root of the directory, to keep track of separately. In any event, the most critical files are those that consume the vast majority of backup space, and therefore it makes sense just to back up the entire installation directory for fast, simple recovery.
Parent topic: Instantiating Oracle GoldenGate Replication