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

Replication Considerations for Microsoft SQL Server Sources

Review the following information about Data Replication support for Microsoft SQL Server sources:
  • The Data Replication Extractor reads data directly from SQL Server transaction logs. It does not use the Microsoft SQL Server API.
  • For Data Replication to capture data from SQL Server logs, SQL Server Change Data Capture must be enabled for all of the mapped source tables.
  • Data Replication supports Microsoft SQL Server tables that do not have primary keys.
  • Data Replication can extract change data from tables that use row compression. However, Data Replication does not extract change data from tables that use page compression.
  • Data Replication can extract change data from sparse columns.
  • Data Replication does not extract change data from views.
  • To capture data from the online transaction logs, the Extractor must run on the same system as the SQL Server database. On Windows, ensure that the SQL Server database, Extractor, and Server Manager run under a Windows Administrator account that uses Windows Authentication. On Linux, the user account for the SQL Server database, Extractor, and Server Manager must be mssql or root.
  • Data Replication can capture change data from compressed or uncompressed backup transaction logs that are in SQL Server native format. To create backup logs in native format, you can run a Microsoft SQL Server Backup task under a Server Manager in the Data Replication Console or use a third-party tool.
    If you use a third-party tool to create backup logs, each time you create the backup logs, use a different media set and unique backup log file names. If you append backup logs to an existing media set or overwrite an existing backup log, the Extractor might process change data from the backup logs incorrectly.
  • To capture data from compressed backups of transaction logs, the system account under which the Extractor runs must have write permissions on the directory that is specified in the extractor.mssql.directory_for_decompressed_backup_logs runtime parameter. The Extractor decompresses the compressed log backups into temporary files in this subdirectory so that it can process the data from the log backups. The default value is
    DataReplication_installation
    /tmp subdirectory. If the specified directory does not exist, Data Replication creates it.
  • To capture data from backup logs, you can run the Extractor and Server Manager instance either on the SQL Server source system or on another system with the same operating system or a different type of operating system.
    If you run the Extractor and Server Manager on a system other than the SQL Server source system, make the backup logs available to the Extractor in one of the following ways:
    • If you run the Extractor and Server Manager instance on the source system, perform one of the following tasks:
      • Send the backup logs to the Server Manager on the system where the Extractor runs by using a Copy File task.
      • Schedule a Microsoft SQL Server Backup task to create backup logs in a shared directory that the Extractor can access over the network. The Extractor can then read the generated backup logs from the shared directory.
    • If you do not run the Extractor and Server Manager instance on the source system, schedule SQL Server to create backup logs in a shared directory that the Extractor can access.
    For the Extractor to read data from backup logs, ensure that you clear the
    Read from online transaction logs
     option on the
    Extract Range
     tab.
  • Data Replication can extract change data from an SQL Server database while SQL Server native transactional replication is active. In the Data Replication Console, on the
    Runtime Settings
     tab >
    General
     view, select the
    Disable secondary truncation checkpoint
     option. This option prevents conflicts between Data Replication and SQL Server truncation checkpoints in the transaction logs by causing Data Replication to use the SQL Server truncation checkpoints.
  • SQL Server 2008 R2 logs Update operations as a pair of Delete and Insert operations. By default, the Extractor tries to merge the Delete and Insert operations into a single Update operation and write that Update to the intermediate files. This Extractor behavior improves the performance of Applier processing of Updates in SQL Apply mode.
    If you use SQL Server 2008 R2 and either Merge Apply or Audit Apply mode to replicate change data, set the
    extract.mssql.process_updates_as_updates
     parameter to 0 to extract each Update as a pair of Delete and Insert operations.
    SQL Server versions later than 2008 R2 process Updates as Updates.
  • If you use the default value of 1 for the
    extract.mssql.process_updates_as_updates
     runtime parameter, Microsoft SQL Server does not log before images of LOB columns for Delete operations. Consequently, when you replicate LOB data from a Microsoft SQL source to flat file targets or target databases in Audit Apply or Merge Apply mode, the flat file rows or audit log table rows for the Delete operations contain null values in the before- and after-image columns that correspond to the source LOB columns.
  • Data Replication does not support virtual computed columns. If you map a virtual computed column to a target column, the target column receives null values during replication processing.
  • Data Replication does not support SQL Server database encryption.
  • Data Replication does not support the replication of triggers and stored procedures.
  • If you extract change data from online transaction logs, you must stop replication processing before using the DBCC SHRINKDATABASE or DBCC SHRINKFILE command to shrink the size of log files.
  • If you run the Extractor against SQL Server online transaction logs in Continuous mode, the Extractor starts each of its microcycles by issuing a SQL Server DBCC LOGINFO command. This command gets information about each virtual log file (VLF), including the file size, offset, and sequence number. If the online transaction log is large and contains many VLFs, this processing can increase CPU usage and the workload on the source database, particularly under the following conditions:
    • You use the continuous replication latency of 0.333 second or less, which causes the Extractor to start another microcycle after a minimal wait interval.
    • The source database is idle, which causes the Extractor to re-read the same VLFs each microcycle.
    To reduce the CPU usage and database workload, increase the value of the
    Continuous replication latency
     field on
    Runtime Settings
     tab >
    General
     view.
  • Data Replication does not support the following index types:
    • Spacial indexes
    • XML indexes
    • Full-text indexes
    Data Replication does not capture DDL changes to these indexes and cannot use them for accurate replication of Updates and Deletes.
  • Data Replication supports Transparent Data Encryption (TDE) of Microsoft SQL Server source databases. The Extractor can decrypt the data in the database log files that have been encrypted with either the Advanced Encryption Standard (AES) or Triple DES (3DES) encryption algorithm.
    To replicate change data from encrypted databases, you must first specify the required certificates in the replication configuration. For more information, see Enabling Replication from Microsoft SQL Server Databases That Use Transparent Data Encryption.
    When the Extractor loads the replication configuration, it loads all of the TDE certificates that were added to the replication configuration. The Extractor uses the certificates to decrypt the database encryption keys from virtual log file (VFL) headers. The Extractor then uses the keys to decrypt change data from the encrypted databases.
    The Extractor writes decrypted data to intermediate files. After the intermediate files are transmitted to the target, the Applier reads the decrypted values from the files and writes these values to the target.
    The decryption of data from encrypted Microsoft SQL Server databases can significantly degrade Extractor performance.
  • Data Replication can extract change data from Microsoft SQL Server sources that use Always On Availability Groups if the availability replicas in the group use synchronous-commit mode.
    Data Replication does not support availability replicas that use asynchronous-commit mode.
    If you extract change data from backup transaction logs, you must add backup log locations on the
    Extract Range
     tab for each availability replica. If you specify shared locations that might become temporarily unavailable, set the extract.mssql.ignore_inactive_backup_locations runtime parameter to 1 to ensure that the Extractor does not end with an error if it cannot access a backup log location.
  • Data Replication does not support Microsoft SQL Server source databases that use the Always Encrypted option.
0 COMMENTS
We’d like to hear from you!