Communities
A collaborative platform to connect and grow with like-minded Informaticans across the globe
Product Communities
Connect and collaborate with Informatica experts and champions
Discussions
Have a question? Start a Discussion and get immediate answers you are looking for
User Groups
Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
Get Started
Community Guidelines
Knowledge Center
Troubleshooting documents, product guides, how to videos, best practices, and more
Knowledge Base
One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
Support TV
Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
Documentation
Information library of the latest product documents
Velocity (Best Practices)
Best practices and use cases from the Implementation team
Learn
Rich resources to help you leverage full capabilities of our products
Trainings
Role-based training programs for the best ROI
Certifications
Get certified on Informatica products. Free, Foundation, or Professional
Product Learning Paths
Free and unlimited modules based on your expertise level and journey
Resources
Library of content to help you leverage the best of Informatica products
Tech Tuesdays Webinars
Most popular webinars on product architecture, best practices, and more
Product Availability Matrix
Product Availability Matrix statements of Informatica products
SupportFlash
Monthly support newsletter
Support Documents
Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
Product Lifecycle
End of Life statements of Informatica products
Ideas
Events
Change Request Tracking
Marketplace
English
  • Data Replication 9.8.0 HotFix 1
  • All Products

Table of Contents

Search

  1. Preface
  2. Data Replication Overview
  3. Understanding Data Replication
  4. Sources - Preparation and Replication Considerations
  5. Targets - Preparation and Replication Considerations
  6. Starting the Server Manager
  7. Getting Started with the Data Replication Console
  8. Defining and Managing Server Manager Main Servers and Subservers
  9. Creating and Managing User Accounts
  10. Creating and Managing Connections
  11. Creating Replication Configurations
  12. Materializing Targets with InitialSync
  13. Scheduling and Running Replication Tasks
  14. Implementing Advanced Replication Topologies
  15. Monitoring Data Replication
  16. Managing Replication Configurations
  17. Handling Replication Environment Changes and Failures
  18. Troubleshooting
  19. Data Replication Files and Subdirectories
  20. Data Replication Runtime Parameters
  21. Command Line Parameters for Data Replication Components
  22. Updating Configurations in the Replication Configuration CLI
  23. DDL Statements for Manually Creating Recovery Tables
  24. Sample Scripts for Enabling or Disabling SQL Server Change Data Capture
  25. Glossary

User Guide

User Guide

Back Next

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 CDC Publisher 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:
Effects of the apply.global_transaction_support parameters
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.
0 COMMENTS
We’d like to hear from you!