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 2
  • 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

Preparing DB2 for Linux, UNIX, and Windows Source Systems

Preparing DB2 for Linux, UNIX, and Windows Source Systems

To prepare a DB2 for Linux, UNIX, and Windows source system for data replication, use the appropriate DB2 commands to complete the following steps.
  1. Verify that Version 10.5 of either the DB2 Client or DB2 Connect is installed.
    If the Extractor task extracts data from a remote DB2 database server, the DB2 Fix Pack version of the DB2 Client or DB2 Connect must be equal to or later than the DB2 Fix Pack version of the DB2 database.
  2. Back up the DB2 database before you configure it for data replication.
  3. Set the overflowlogpath parameter to specify the location that each DB2 source database searches for the log files that the db2Readlog API needs to access. Use the following command: 
    db2 update db cfg for 
    database_name
     using overflowlogpath 
    overflow_log_path
    The Extractor interacts with the db2Readlog API to extract data for replication.
  4. Set the logarchmeth1 or logarchmeth2 parameter to specify the directory in which DB2 stores the archive log files. Use the following command: 
    db2 update db cfg for 
    database_name
     using {logarchmeth1|logarchmeth2} DISK:
    archive_log_path
    Setting a log archive method turns on archive logging in the database.
  5. If you plan to perform bidirectional replication or cascade replication, or if you want to view additional information about DB2 transactions in the
    Transactions of configuration <configuration_name>
     dialog box in the Data Replication Console, perform one of the following actions:
    • If you use DB2 9.7, run the following command to set the DB2_LOGGING_DETAIL registry variable for the source database instance to APPLINFO: 
      db2set -i <varname>instance_name</varname> DB2_LOGGING_DETAIL=APPLINFO
    • If you use DB2 10.1 or later, run the following command to set the log_appl_info parameter for the source database to yes: 
      db2 update db cfg for 
      database_name
       using log_appl_info yes
    These commands support loopback avoidance by causing DB2 to write an additional log record that contains information about DB2 transactions. If you skip this step, the Server Manager cannot retrieve the following information for DB2 transactions: database transaction status, application ID, database user name, system user, and host. Also, the Extractor cannot distinguish the transactions that originally occurred on the database from the transactions that the Applier applied. As a result, the Extractor captures all of the change data.
    Skip this step if you do not plan to use bidirectional or cascade replication and if you do not need to view the additional information about DB2 transactions in the Data Replication Console.
  6. If you changed the DB2_LOGGING_DETAIL registry variable or log_appl_info parameter in step 5, restart the database instance so that the new parameter settings take effect. Use the following commands: 
    db2stop
db2start
  7. Back up the DB2 database before you start data replication.
  8. Archive the current database log. Use the following command: 
    db2 archive log for database 
    database_name
  9. Ensure that the DATA CAPTURE CHANGES option is enabled for the source tables for which you want to replicate data in one of the following ways:
    • If you plan to define replication configurations and run InitialSync and the Extractor from the Data Replication Console, when you save a configuration in the Console later, the Console will prompt you to enable DATA CAPTURE CHANGES. Click
      Yes
       to enable this option.
    • If you plan to run InitialSync and the Extractor outside of the Data Replication Console, manually run the following command for each source table: 
      db2 alter table 
      table_name
       data capture changes
      If the source tables include LONG VARCHAR or LONG VARGRAPHIC columns, use the following command: 
      db2 alter table 
      table_name
       data capture changes include longvar columns
    After you create and save a new configuration, you can manage the DATA CAPTURE settings for the source tables on the
    Map Tables
     tab. For more information, see Managing DB2 DATA CAPTURE Settings.
  10. Grant DBADM authority to the user ID that Data Replication uses to connect to the DB2 source. Use the following command: 
    db2 grant dbadm on database to user 
    datarep_user
  11. Ensure that the DB2INSTANCE environment variable is set to the DB2 Client instance name on the system where the Extractor runs.
  12. Ensure that the library path environment variable includes the directory that contains the DB2 client libraries. Use one of the following library path environment variables, depending on the type of operating system where the Extractor runs:
    • LD_LIBRARY_PATH on HP-UX and Linux
    • LD_LIBRARY_PATH_64 on Solaris
    • LIBPATH on AIX
    • PATH on Windows
    For example, use the following command on Linux: 
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/db2inst1/sqllib/lib32:/home/db2inst1/sqllib/lib64
  13. For DB2 sources that use accented and non-Latin characters, set the DB2CODEPAGE environment variable to an encoding that is compatible with the source character set on the computer where InitialSync runs. For example, set DB2CODEPAGE to 1208 for UTF-8 encoding.
  14. If you want to connect to a remote DB2 database by using a database alias, perform the following substeps:
    1. To provide TCP/IP access to a remote DB2 server node that was not previously cataloged, issue the following DB2 catalog tcipip node command on the computer where the Extractor runs: 
      db2 catalog tcpip node 
      new_node_name
       remote 
      source_server_ip
       server 
      source_db2_port
      The
      new_node_name
       variable value must be unique in the DB2 node catalog.
      The default DB2 port number is 50000.
      To issue this command, you must have sysadm or sysctrl authority.
    2. To store the location of a DB2 database on a remote node that was not previously cataloged in the system database directory, issue the following DB2 catalog database command on the computer where the Extractor runs: 
      db2 catalog database 
      source_db2_database
       as 
      new_db2_database_alias
       at node 
      new_node_name
       authentication server
      The
      new_db2_database_alias
       variable value must be unique in the DB2 database catalog.
      To issue this command, you must have sysadm or sysctrl authority.
  15. Add the operating system user that runs the Extractor to a user group with DB2 SYSADM authority.
    1. Determine the SYSADM group name:
      • On Linux and UNIX, use the following command: 
        db2 get dbm cfg | grep -i SYSADM_GROUP
      • On Windows, use the following command: 
        db2 get dbm cfg | findstr SYSADM_GROUP
      If the
      SYSADM_GROUP
       parameter is not defined, DB2 sets SYSADM authority to the following groups and accounts:
      • On Linux and UNIX, SYSADM authority is granted to the primary group of the instance owner.
      • On Windows, SYSADM authority is granted to the local Administrators group, Administrators group, DB2ADMNS group, and LocalSystem account.
    2. Add the operating system user to the group that is specified by the
      SYSADM_GROUP
       parameter.
0 COMMENTS
We’d like to hear from you!