Commit Processing and Target Constraints with Applier Multi-Threaded Processing
Commit Processing and Target Constraints with Applier Multi-Threaded Processing
The Data Replication Applier can use multi-threaded processing to apply changes to the target. You can control whether the Applier uses a single transaction across all threads or a transaction for each main thread or each subtask on a main thread.
When the Applier uses multiple threads, target table constraints might cause the Applier to fail if some data must be committed before other data. For example, if you have two target tables with a primary key–foreign key relationship and add a row to the first table that references a nonexistent key in the second table, the Applier fails.
To configure commit processing across threads, use the following options:
To enable Applier multi-threaded processing, on the
Runtime Settings
tab >
General
view, enter a number greater than 1 in the
Applier threads
field. The Applier then commits data on each Applier thread.
For additional parallelism, on the
Runtime Settings
tab >
Advanced Settings
view, you can set the apply.subtasks_enabled parameter to 1 to enable subtask threads on each main Applier thread. The Applier then commits data in a transaction on each subtask. If you enable subtasks, the Applier distributes changes across threads by object rather than by row.
For Oracle targets, on the
Runtime Settings
tab >
Advanced Settings
view, you can use the apply.global_transaction_support parameter to control whether the Applier uses a global transaction. A global transaction contains all of the changes that are distributed across multiple Applier threads. Options are:
0
. Disable global transactions and commit data on each subtask thread or on each Applier thread if you do not use subtasks.
1
. Enable global transactions and perform a single commit for all Applier threads or subtask threads at the end of the apply cycle. This option might degrade performance.
2
. Enable global transactions and perform a commit on each Applier thread.
For Apache Kafka targets, do not set the
Applier threads
field to a number greater than 1 or specify the apply.subtasks_enabled or apply.global_transaction_support runtime parameters. The Kafka Apply process and Queue Adapter maintain the commit order when sending change data to the Kafka target message queue.
The following image summarizes the effects of the apply.global_transaction_support parameter options:
To handle target table constraints, use one of the following strategies:
For Oracle targets, define the table constraints as deferrable and set the Data Replication apply.global_transaction_support parameter to 1. This configuration forces the Applier to check the target table constraints at the end of the global transaction.
Disable constraints on the target tables.
Configure the Applier to use one thread without subtasks.
If you need to change Applier processing settings, such as the number of Applier threads and subtask threads, or change an algorithm for distributing change data across threads, stop the Applier task and wait for processing to complete normally. Then edit and save the configuration and restart the Applier task. If you force the Applier task to end, the Applier will process the applied changes again after you restart it.