InfoSphere CDC for Microsoft SQL Server (Version 10.2)4 About InfoSphere CDC7 Capturing change data with single scrape10 System requirements for InfoSphere CDC for Microsoft SQL Server11 Hardware and software requirements12 Running InfoSphere CDC for Microsoft SQL Server in a virtualization environment13 Disk space requirements14 RAM requirements16 Port requirements17 Understanding how InfoSphere CDC interacts with your database18 Before you install InfoSphere CDC for Microsoft SQL Server20 Required database, user accounts, and schemas21 Enabling TCP/IP in Microsoft SQL Server22 Starting the Microsoft SQL Server services23 Creating a Windows account and granting privileges in Microsoft SQL Server24 Assessing disk space and memory requirements25 Understanding the importance of an appropriately configured disk subsystem27 Sizing considerations for the staging store28 Understanding the InfoSphere CDC memory footprint30 Enabling Microsoft SQL Server Replication31 Configuring the recovery model32 Configuring a remote target of InfoSphere CDC33 Backing up your database34 Creating a transaction log backup plan35 Calculating database connections required by InfoSphere CDC for Microsoft SQL Server36 Database partition changes38 Creating queues in JMS providers39 Installing or upgrading InfoSphere CDC for Microsoft SQL Server40 Installing InfoSphere CDC for Microsoft SQL Server41 To install InfoSphere CDC for Microsoft SQL Server42 Upgrading InfoSphere CDC for Microsoft SQL Server43 To upgrade InfoSphere CDC for Microsoft SQL Server45 Configuring InfoSphere CDC for Microsoft SQL Server46 Configuring InfoSphere CDC for Microsoft SQL Server instances47 To add a new instance of InfoSphere CDC for Microsoft SQL Server48 To edit an instance of InfoSphere CDC for Microsoft SQL Server55 To delete an instance of InfoSphere CDC for Microsoft SQL Server56 Configuring InfoSphere CDC for Microsoft SQL Server for a Microsoft SQL Server cluster57 Installing InfoSphere CDC for Microsoft SQL Server in a Microsoft SQL Server cluster58 Adding an instance and configuring the Microsoft SQL Server cluster59 Deleting an instance from a Microsoft SQL Server cluster60 Uninstalling InfoSphere CDC for Microsoft SQL Server from a Microsoft SQL Server cluster61 After you install and configure InfoSphere CDC for Microsoft SQL Server62 Starting InfoSphere CDC for Microsoft SQL Server63 To start InfoSphere CDC for Microsoft SQL Server (Windows)64 Stopping InfoSphere CDC for Microsoft SQL Server65 To stop InfoSphere CDC for Microsoft SQL Server (Windows)66 Performing an external refresh67 To perform an external refresh70 Maintaining active TCP connections in a network environment71 To maintain active TCP connections72 Enabling SQL statements in Management Console73 To enable SQL statements in Management Console74 Replication considerations75 Replicating data from a table without a primary key76 To replicate data from a table without a primary key77 Replicating computed columns78 Replicating data to a table with computed columns79 Replicating identity columns80 Replicating the rowversion data type81 Replicating columns with database defaults82 InfoSphere CDC for Microsoft SQL Server metadata tables83 Data types supported by InfoSphere CDC for Microsoft SQL Server84 System parameters for InfoSphere CDC for Microsoft SQL Server85 Commands for InfoSphere CDC for Microsoft SQL Server86 Using the InfoSphere CDC for Microsoft SQL Server commands87 Setting the TSINSTANCE environment variable88 Continuous Capture commands89 dmdisablecontinuouscapture - Disable Continuous Capture90 dmenablecontinuouscapture - Enable Continuous Capture91 Controlling replication commands92 dmendreplication - End replication93 dmrefresh - Refresh subscription97 dmstartmirror - Start mirroring99 Database transaction log commands102 dmdecodebookmark - Display verbose information bookmark103 dmsetbookmark - Set bookmark104 dmshowbookmark - Display bookmark information106 dmshowlogdependency - Show Log Dependency108 Exporting and importing configuration commands110 dmexportconfiguration - Export InfoSphere CDC Configuration111 dmimportconfiguration - Import InfoSphere CDC Configuration112 Managing tables for replication commands113 dmdescribe - Describe source tables114 dmflagforrefresh - Flag for Refresh115 dmmarktablecapturepoint - Mark a table capture point on a source table116 dmpark - Park table118 dmreaddtable - Update source table definition119 dmreassigntable - Update target table definition120 dmsetreplicationmethod - Set replication method121 Monitoring replication commands123 dmclearevents - Clear events124 dmgetsubscriptionstatus - Get subscription status125 dmshowevents - Display InfoSphere CDC events126 Single scrape and staging store commands128 dmclearstagingstore - Remove cached operations from the staging store129 dmgetstagingstorestatus - Retrieve Staging Store status130 Other commands131 dmbackupmd - Back up metadata132 dmconfigurets - Configure InfoSphere CDC133 dmcreateclusterservice - Create cluster service134 dmmarkexternalunloadend - End table data unload135 dmmarkexternalunloadstart - Start table data unload136 dmmdcommander137 dmmdconsole138 dmset - Set InfoSphere CDC system parameter139 dmshowversion - Show InfoSphere CDC version140 dmshutdown - Shut down InfoSphere CDC141 dmsupportinfo - Collect IBM Support information144 dmts32 - Start InfoSphere CDC146 dmts64 - Start InfoSphere CDC147 User exits for InfoSphere CDC for Microsoft SQL Server148 Stored procedure user exits for table and row level operations149 Defining a stored procedure user exit150 Stored procedure user exit database connections151 Retrieving data with a stored procedure user exit152 Retrieving system values using the s$ prefix153 Retrieving journal control fields using the j$ prefix156 Retrieving data values using b$, a$, k$, and d$ prefixes159 Example of a stored procedure user exit162 Sample Java class user exits for InfoSphere CDC for Microsoft SQL Server164 To compile the sample Java class user exits (Windows)165 InfoSphere CDC API reference - Javadocs166 Conflict resolution audit table167 Structure of the conflict resolution audit table168 Row image format171 Truncated images172 Unaudited data types173 Uninstalling InfoSphere CDC for Microsoft SQL Server174 To uninstall InfoSphere CDC for Microsoft SQL Server (Windows)175 Troubleshooting176 Using the IBM Support Assistant (ISA DC)177 To use ISA DC to collect data for a product problem (command line)178 To use ISA DC to collect data for a product problem (GUI)181 To use ISA DC to collect data for a question or an enhancement request (command line)183 To use ISA DC to collect data for a question or an enhancement request (GUI)185 Locating log files186 Troubleshooting and contacting IBM Support187 IBM InfoSphere Change Data Capture, Version 10.2 About InfoSphere CDC IBM®InfoSphere® Change Data Capture (InfoSphere CDC) is a replication solution that captures database changes as they happen and delivers them to target databases, message queues, or an ETL solution such as InfoSphere DataStage® based on table mappings configured in the InfoSphere CDCManagement Console GUI application. InfoSphere CDC provides low impact capture and fast delivery of data changes for key information management initiatives including dynamic data warehousing, master data management, application consolidations or migrations, operational BI, and enabling SOA projects. InfoSphere CDC also helps reduce processing overheads and network traffic by only sending the data that has changed. Replication can be carried out continuously or periodically. When data is transferred from a source server, it can be remapped or transformed in the target environment. The following diagram illustrates the key components of InfoSphere CDC.
The key components of the InfoSphere CDC architecture are described below: - Access Server—Controls all of the non-command line access to the replication environment. When you log in to Management Console, you are connecting to Access Server. Access Server can be closed on the client workstation without affecting active data replication activities between source and target servers. - Admin API—Operates as an optional Java™-based programming interface that you can use to script operational configurations or interactions. - Apply agent—Acts as the agent on the target that processes changes as sent by the source. - Command line interface—Allows you to administer datastores and user accounts, as well as to perform administration scripting, independent of Management Console. - Communication Layer (TCP/IP)—Acts as the dedicated network connection between the Source and the Target.
4 - Source and Target Datastore—Represents the data files and InfoSphere CDC instances required for data replication. Each datastore represents a database to which you want to connect and acts as a container for your tables. Tables made available for replication are contained in a datastore. - Management Console—Allows you to configure, monitor and manage replication on various servers, specify replication parameters, and initiate refresh and mirroring operations from a client workstation. Management Console also allows you to monitor replication operations, latency, event messages, and other statistics supported by the source or target datastore. The monitor in Management Console is intended for time-critical working environments that require continuous analysis of data movement. After you have set up replication, Management Console can be closed on the client workstation without affecting active data replication activities between source and target servers. - Metadata—Represents the information about the relevant tables, mappings, subscriptions, notifications, events, and other particulars of a data replication instance that you set up. - Mirror—Performs the replication of changes to the target table or accumulation of source table changes used to replicate changes to the target table at a later time. If you have implemented bidirectional replication in your environment, mirroring can occur to and from both the source and target tables. - Refresh—Performs the initial synchronization of the tables from the source database to the target. This is read by the Refresh reader. - Replication Engine—Serves to send and receive data. The process that sends replicated data is the Source Capture Engine and the process that receives replicated data is the Target Engine. An InfoSphere CDC instance can operate as a source capture engine and a target engine simultaneously. - Single Scrape—Acts as a source-only log reader and a log parser component. It checks and analyzes the source database logs for all of the subscriptions on the selected datastore. Not all InfoSphere CDC engines use Single Scrape. For InfoSphere CDC for DB2® for i, there is a Scraper job (that acts as a log reader) and a Mirror job that performs the function of mirroring (see Mirror above). - Source transformation engine—Processes row filtering, critical columns, column filtering, encoding conversions, and other data to propagate to the target datastore engine. - Source database logs—Maintained by the source database for its own recovery purposes. The InfoSphere CDC log reader inspects these in the mirroring process, but filters out the tables that are not in scope for replication. - Target transformation engine—Processes data and value translations, encoding conversions, user exits, conflict detections, and other data on the target datastore engine. There are two types of target-only destinations for replication that are not databases: - JMS Messages—Acts as a JMS message destination (queue or topic) for row- level operations that are created as XML documents. - InfoSphere DataStage—Processes changes delivered from InfoSphere CDC that can be used by InfoSphere DataStage jobs.
In this section, you will learn: 5
- Capturing change data with single scrape Related information: Supported sources and targets
6 IBM InfoSphere Change Data Capture, Version 10.2 About InfoSphere CDC IBM®InfoSphere® Change Data Capture (InfoSphere CDC) is a replication solution that captures database changes as they happen and delivers them to target databases, message queues, or an ETL solution such as InfoSphere DataStage® based on table mappings configured in the InfoSphere CDCManagement Console GUI application. InfoSphere CDC provides low impact capture and fast delivery of data changes for key information management initiatives including dynamic data warehousing, master data management, application consolidations or migrations, operational BI, and enabling SOA projects. InfoSphere CDC also helps reduce processing overheads and network traffic by only sending the data that has changed. Replication can be carried out continuously or periodically. When data is transferred from a source server, it can be remapped or transformed in the target environment. The following diagram illustrates the key components of InfoSphere CDC.
The key components of the InfoSphere CDC architecture are described below: - Access Server—Controls all of the non-command line access to the replication environment. When you log in to Management Console, you are connecting to Access Server. Access Server can be closed on the client workstation without affecting active data replication activities between source and target servers. - Admin API—Operates as an optional Java™-based programming interface that you can use to script operational configurations or interactions. - Apply agent—Acts as the agent on the target that processes changes as sent by the source. - Command line interface—Allows you to administer datastores and user accounts, as well as to perform administration scripting, independent of Management Console. - Communication Layer (TCP/IP)—Acts as the dedicated network connection between the Source and the Target.
7 - Source and Target Datastore—Represents the data files and InfoSphere CDC instances required for data replication. Each datastore represents a database to which you want to connect and acts as a container for your tables. Tables made available for replication are contained in a datastore. - Management Console—Allows you to configure, monitor and manage replication on various servers, specify replication parameters, and initiate refresh and mirroring operations from a client workstation. Management Console also allows you to monitor replication operations, latency, event messages, and other statistics supported by the source or target datastore. The monitor in Management Console is intended for time-critical working environments that require continuous analysis of data movement. After you have set up replication, Management Console can be closed on the client workstation without affecting active data replication activities between source and target servers. - Metadata—Represents the information about the relevant tables, mappings, subscriptions, notifications, events, and other particulars of a data replication instance that you set up. - Mirror—Performs the replication of changes to the target table or accumulation of source table changes used to replicate changes to the target table at a later time. If you have implemented bidirectional replication in your environment, mirroring can occur to and from both the source and target tables. - Refresh—Performs the initial synchronization of the tables from the source database to the target. This is read by the Refresh reader. - Replication Engine—Serves to send and receive data. The process that sends replicated data is the Source Capture Engine and the process that receives replicated data is the Target Engine. An InfoSphere CDC instance can operate as a source capture engine and a target engine simultaneously. - Single Scrape—Acts as a source-only log reader and a log parser component. It checks and analyzes the source database logs for all of the subscriptions on the selected datastore. Not all InfoSphere CDC engines use Single Scrape. For InfoSphere CDC for DB2® for i, there is a Scraper job (that acts as a log reader) and a Mirror job that performs the function of mirroring (see Mirror above). - Source transformation engine—Processes row filtering, critical columns, column filtering, encoding conversions, and other data to propagate to the target datastore engine. - Source database logs—Maintained by the source database for its own recovery purposes. The InfoSphere CDC log reader inspects these in the mirroring process, but filters out the tables that are not in scope for replication. - Target transformation engine—Processes data and value translations, encoding conversions, user exits, conflict detections, and other data on the target datastore engine. There are two types of target-only destinations for replication that are not databases: - JMS Messages—Acts as a JMS message destination (queue or topic) for row- level operations that are created as XML documents. - InfoSphere DataStage—Processes changes delivered from InfoSphere CDC that can be used by InfoSphere DataStage jobs.
In this section, you will learn: 8
- Capturing change data with single scrape Related information: Supported sources and targets
9 IBM InfoSphere Change Data Capture, Version 10.2 Capturing change data with single scrape Single scrape is a source-only component of InfoSphere® CDC that allows multiple subscriptions in an instance to share the same log reader and log parser thread. With single scrape, InfoSphere CDC only reads and parses the source database transaction log once to capture changes for all tables being mirrored for the instance. Single scrape improves performance by reducing the footprint on your source system since it only requires a single log reader thread and a single log parser thread to service multiple subscriptions. This reduces disk I/O and decreases CPU utilization by InfoSphere CDC processes.
Change data and the staging store After the InfoSphere CDC log reader captures the change data from the database logs and the data is parsed by the InfoSphere CDC log parser, change data is placed in the staging store. Each subscription retrieves the changes for mirroring tables from the staging store whenever possible. The data in scope for a given subscription is kept in the staging store until it is sent to the target database. After the data is sent to the target it is removed from the staging store. To improve performance when subscriptions are mirroring, InfoSphere CDC will keep the staging store data in memory whenever possible.
Related concepts: Sizing considerations for the staging store Assessing disk space and memory requirements About InfoSphere CDC
10 IBM InfoSphere Change Data Capture, Version 10.2 System requirements for InfoSphere CDC for Microsoft SQL Server Before you install InfoSphere® CDC, ensure that the system you choose meets the necessary operating system, hardware, software, communications, disk, and memory requirements. In this section, you will learn:
- Hardware and software requirements - Running InfoSphere CDC for Microsoft SQL Server in a virtualization environment - Disk space requirements - RAM requirements - Port requirements
11 IBM InfoSphere Change Data Capture, Version 10.2 Hardware and software requirements Click the following links to view hardware and software requirements for InfoSphere® CDC, Management Console, and Access Server: Linux, UNIX, Windows and System i® replication engines: https://ibm.biz/BdxyzE Mainframe replication engine: https://ibm.biz/Bdxyd5
Related concepts: Disk space requirements RAM requirements Port requirements
12 IBM InfoSphere Change Data Capture, Version 10.2 Running InfoSphere CDC for Microsoft SQL Server in a virtualization environment The InfoSphere® CDC products adhere to the Virtualization Policy for IBM® Software and can be run in any virtualization environment for only the supported operating systems and versions listed specifically within IBMInfoSphere Data Replication System Requirements. For more information on the policy, see http://www- 01.ibm.com/software/support/virtualization_policy.html
13 IBM InfoSphere Change Data Capture, Version 10.2 Disk space requirements
Disk space InfoSphere® CDC source system:100 GB—Default value for the Staging Store Disk Quota for each instance of InfoSphere CDC. The minimum is 1 GB. Although the minimum is 1 GB, prepare for more disk space since there is a staging store on the source. Use the InfoSphere CDC configuration tool to configure disk space for this quota.5 GB—For installation files, data queues, and log files.Global disk quota—Disk space is required on your source system for this quota which is used to store in-scope change data that has not been committed in your database. The amount of disk space required is determined by your replication environment and the workload of your source database. Use the mirror_global_disk_quota_gb system parameter to configure the amount of disk space used by this quota. InfoSphere CDC target system:1 GB—The minimum amount of disk space allowed for the disk quota for each instance of InfoSphere CDC. The minimum value for this quota is sufficient for all instances created on your target system. Use the InfoSphere CDC configuration tool to configure the disk space for this quota.5 GB—For installation files, data queues, and log files.Global disk quota—Disk space is required on your target system for this quota which is used to store LOB data received from your InfoSphere CDC source system. The amount of disk space required is determined by your replication environment and the amount of LOB data you are replicating. To improve performance, InfoSphere CDC will only persist LOB data to disk if RAM is not available on your target system. Use the mirror_global_disk_quota_gb system parameter to configure the amount of disk space used by this quota.
InfoSphere CDC may require additional disk space in the following situations: - You are running large batch transactions in the database on your source system. - You are configuring multiple subscriptions and one of your subscriptions is latent. In this type of scenario, InfoSphere CDC on your source system may persist transaction queues to disk if RAM is not available. - You are replicating large LOB data types. - You are replicating "wide" tables that have hundreds of columns. - You are performing regular back ups of your metadata with the dmbackupmd command-line utility.
Related concepts: Hardware and software requirements RAM requirements Port requirements Configuring InfoSphere CDC for Microsoft SQL Server 14
15 IBM InfoSphere Change Data Capture, Version 10.2 RAM requirements
RAM Each instance of InfoSphere® CDC requires memory for the Java™ Virtual Machine (JVM). The following default values for memory are assigned: 1024 MB of RAM —Default value for each 64-bit instance of InfoSphere CDC. 512 MB of RAM—Default value for each 32-bit instance of InfoSphere CDC.Use the InfoSphere CDC configuration tool to configure the memory for each instance of InfoSphere CDC. Note:InfoSphere CDC is predominantly a Java-based application. However, some portions of it are written in C. These portions of InfoSphere CDC are not subject to the memory limits specified for the JVM
Although InfoSphere CDC memory requirements will fluctuate, you must work with your system administrator to ensure the allocated memory for each instance of the product is available at all times. This may involve deployment planning since other applications with memory requirements may be installed on the same server with InfoSphere CDC. Using values other than the defaults or allocating more RAM than is physically available on your server should only be undertaken after considering the impacts on product performance. InfoSphere CDC source deployments may require additional RAM in the following scenarios: - You are replicating large LOB data types with your InfoSphere CDC source deployment. These data types are sent to target while being retrieved from the source database. The target waits until all LOBs (for each record) are received before applying a row. LOBs are stored in memory as long as there is adequate RAM, otherwise they are written to disk on the target. - You are replicating "wide" tables with hundreds of columns. - You are performing large batch transactions in your source database rather than online transaction processing (OLTP).
Related concepts: Hardware and software requirements Disk space requirements Port requirements Configuring InfoSphere CDC for Microsoft SQL Server
16 IBM InfoSphere Change Data Capture, Version 10.2 Port requirements InfoSphere® CDC requires that you allocate a port for communication with client workstations running Management Console and other servers. The port must be accessible through a firewall, although you do not require access to the Internet.
Protocol Default port Purpose TCP 10501 Accepts connections from:Management ConsoleOther installations of InfoSphere CDC as a source of replicationCommand line utilities
Related concepts: Maintaining active TCP connections in a network environment Hardware and software requirements Disk space requirements RAM requirements Configuring InfoSphere CDC for Microsoft SQL Server
17 IBM InfoSphere Change Data Capture, Version 10.2 Understanding how InfoSphere CDC interacts with your database When InfoSphere® CDC interacts with your database, by reading its logs or applying data to its tables, it creates a dependency on your database. This dependency manifests itself in several ways: - Log management - Resource utilization and availability - Change management Log management Log management requires that you keep the logs from which InfoSphere CDC reads until such time as InfoSphere CDC has replicated data from them. The dmshowlogdependency command, available for most InfoSphere CDC engines, informs you of those database logs on which InfoSphere CDC continues to depend. Database logs should not be removed until such time as they no longer appear in the list of logs displayed when the command is issued. The consequences of not adhering to this policy are that InfoSphere CDC will either end with an error or appear to hang as it waits for the log files to become available to read, depending on the database. If the log files have been deleted and are permanently unavailable then you will have no option but to refresh the data. InfoSphere CDC cannot skip logs while maintaining data integrity as it will never know what data would be missed in the log files so skipped. Similarly, the log files must have file system permissions sufficient for InfoSphere CDC to be able to read them. Should such permissions not be sufficient, InfoSphere CDC will fail with a message indicating that the specified log could not be opened for reading.
Resource utilization and availability InfoSphere CDC is frequently installed on the same server as the database from which it is replicating or to which it is replicating. For this reason, it is important to ensure that the memory allocated for use by InfoSphere CDC is actually physically available on the machine. By default, some databases can be configured to use all available memory on the machine. Such a configuration will not work for InfoSphere CDC, as it will have no memory with which to run. At least the amount of memory allocated to InfoSphere CDC will need to be set aside from the database to ensure that InfoSphere CDC will be able to run. Symptoms of resource starvation include many variations on InfoSphere CDC failing due to out of memory conditions, communications failures, very high latency, timeout errors, and others.
Change management Sometimes referred to as schema evolution, change management refers to the necessity of planning changes to the structure of database tables that InfoSphere CDC is replicating and coordinating those changes with the operation of InfoSphere CDC to ensure that the changes do not disrupt replication. The database and InfoSphere CDC must share the same understanding of the structure of the tables being replicated. Without a shared understanding, InfoSphere CDC will interpret the table data incorrectly, and thereby replicate that 18 data incorrectly. InfoSphere CDC endeavours to protect users from potential data loss or corruption resulting from uncoordinated table structure changes, but it is not always able to do. In order to minimize recovery efforts resulting from uncoordinated table structure changes, it is a best practice to follow the change management procedures appropriate to your database. Coordinating change management between the database and InfoSphere CDC will ensure smooth continuity of replication with minimal effort. Please note that change management practices apply to the tables in both source and target databases. Recognizing that some table structure changes are inadvertently performed, tech notes are also available to assist you in recovering from uncoordinated table structure changes.
19 IBM InfoSphere Change Data Capture, Version 10.2 Before you install InfoSphere CDC for Microsoft SQL Server This section contains information on the tasks that you must complete before installing InfoSphere® CDC. This section assumes that you have met all of the hardware, software, database, and port requirements. You must complete all of the tasks below before installing InfoSphere CDC. In this section, you will learn:
- Required database, user accounts, and schemas - Enabling TCP/IP in Microsoft SQL Server - Starting the Microsoft SQL Server services - Creating a Windows account and granting privileges in Microsoft SQL Server - Assessing disk space and memory requirements - Understanding the importance of an appropriately configured disk subsystem - Sizing considerations for the staging store - Understanding the InfoSphere CDC memory footprint - Enabling Microsoft SQL Server Replication - Configuring the recovery model - Configuring a remote target of InfoSphere CDC - Backing up your database - Creating a transaction log backup plan - Calculating database connections required by InfoSphere CDC for Microsoft SQL Server - Database partition changes - Creating queues in JMS providers
20 IBM InfoSphere Change Data Capture, Version 10.2 Required database, user accounts, and schemas Configuring a Microsoft SQL Server database When you configure InfoSphere® CDC, you are prompted for the name of the a Microsoft SQL Server database you want InfoSphere CDC to connect to and replicate data. Before installing InfoSphere CDC, ensure that this Microsoft SQL Server database exists and that you have created and set up a database user that has access to it.
Configuring a Microsoft SQL Server user account If you plan on using SQL authentication to allow InfoSphere CDC to connect to your Microsoft SQL Server database, you must create a user account with SQL authentication that has the following privileges for the Microsoft SQL Server instance: - If you are using InfoSphere CDC as a source of replicated data, you must specify sysadmin privileges for the user account. - If you are using InfoSphere CDC as a target of replicated data, at minimum you must specify db_owner privileges for the database and bulkadmin as the server role. If you prefer, you can also specify sysadmin privileges for the user account. When you configure InfoSphere CDC, you are prompted for the name of the Microsoft SQL Server database you want InfoSphere CDC to connect to and the user name and password of the Microsoft SQL Server user that has access to this database.
Setting up a Windows user account Create or choose an existing Windows account that you will use to install, configure, or upgrade InfoSphere CDC.
Configuring a Microsoft SQL Server schema, user name or database owner (dbo) Create or choose an existing schema, user name or dbo for your database metadata tables. You will have to specify this value when you configure InfoSphere CDC.
21 IBM InfoSphere Change Data Capture, Version 10.2 Enabling TCP/IP in Microsoft SQL Server Enable the TCP/IP network protocols in Microsoft SQL Server and specify a static port. You must also disable dynamic ports. You must specify a TCP/IP static port when you configure InfoSphere® CDC. If you need more information on how to perform this task in Microsoft SQL Server, see your database administrator or refer to your Microsoft SQL Server documentation.
22 IBM InfoSphere Change Data Capture, Version 10.2 Starting the Microsoft SQL Server services Microsoft SQL Server services usually start automatically but must be running during the installation and operation of InfoSphere® CDC. For information about working with the Microsoft SQL Server services, see your Microsoft SQL Server documentation.
23 IBM InfoSphere Change Data Capture, Version 10.2 Creating a Windows account and granting privileges in Microsoft SQL Server If you plan on using Windows authentication to allow InfoSphere® CDC to connect to your Microsoft SQL Server database, you must create a Windows user account that has the following privileges: - Full access (read, write, and execute) to the InfoSphere CDC installation directory. In addition, you must do the following in Microsoft SQL Server: - Give the Windows user access to the database where InfoSphere CDC is installed. - Grant the Windows user the following privileges for the Microsoft SQL Server instance: - If you are using InfoSphere CDC as a source of replicated data, you must specify sysadmin privileges for the user account. - If you are using InfoSphere CDC as a target of replicated data, at minimum you must specify db_owner privileges for the database and bulkadmin as the server role. If you prefer, you can also specify sysadmin privileges for the user account.
24 IBM InfoSphere Change Data Capture, Version 10.2 Assessing disk space and memory requirements InfoSphere® CDC requires disk space and memory when it processes change data from your source database. In order to process change data efficiently and replicate these changes to your target system, it is very important that InfoSphere CDC has adequate disk space and memory for each of the components described in this section.
Disk space requirements for the staging store The InfoSphere CDC staging store is located on your source system and is a cache of change data read from the database logs. The size of the staging store will increase as the product accumulates change data, and therefore you must plan your source environment accordingly, particularly disk space. The disk space allocated to the staging store is controlled by the Staging Store Disk Quota value that is set when you create an instance with the InfoSphere CDC configuration tool. In most cases, the default value is appropriate for InfoSphere CDC source systems. Since the staging store is only used on source systems, you can reduce this value to the minimum of 1 GB if you are configuring a target instance of InfoSphere CDC.
Note: You can also allocate disk space to the staging store with the staging_store_disk_quota_gb system parameter in Management Console.
Memory requirements for the JVM (Java Virtual Machine) As a Java-based product, InfoSphere CDC requires you to allocate the maximum amount of memory (RAM) to be used by the Java™ Virtual Machine (JVM). This prevents InfoSphere CDC from using all of the available memory on the system where it is installed. The Maximum Memory Allowed value is set on a per-instance basis for each instance you create for your source or target database. In most cases the default values are appropriate for 32-bit and 64-bit instances. However, if your database is processing an extremely heavy workload, you may have to adjust the default values. The RAM allocated must be physically available on your system.
Disk space requirements for the global disk quota The global disk quota on your source and target systems is used for all capture components including temporary files, transaction queues, and LOBs which are staged on the target before being applied. InfoSphere CDC will manage disk space utilization across all components as required. Most databases have a mechanism that allows you to roll back or undo changes to your database by storing uncommitted changes. Similarly, InfoSphere CDC uses this disk quota to store in-scope change data that has not been committed in your database. Once the database transaction is committed, the disk space used by the transaction is released. Long running open transactions will contribute to the amount of disk space used. You can configure the amount disk space that is allocated to this quota with the mirror_global_disk_quota_gb system parameter. The default setting of this system parameter is such that InfoSphere CDC will only stop replicating after this disk quota 25 exhausts all available disk space on your system. If you would prefer InfoSphere CDC to stop replicating after it uses a specific amount of disk space, you can specify the value with this system parameter in Management Console.
Related concepts: Sizing considerations for the staging store Configuring InfoSphere CDC for Microsoft SQL Server Disk space requirements RAM requirements
26 IBM InfoSphere Change Data Capture, Version 10.2 Understanding the importance of an appropriately configured disk subsystem There are many types of disk subsystems in use to meet either business or performance needs. Not all of these disk subsystems are suitable for use by databases or InfoSphere® Data Replication out of the box. Some may need to be tuned to ensure that appropriate input/output semantics are in place for reliable continuous operation. Symptoms of an unreliable disk subsystem Without appropriate disk subsystem configuration, both the database itself or InfoSphere Data Replication may exhibit any of a wide variety of input/output related errors, usually random in nature. Any one of them can stop replication. If the database transaction logs themselves become corrupted due to this kind of misconfiguration, then the database itself may become unrecoverable, putting the entire business at risk. Having an appropriately configured disk subsystem is therefore essential to the operation of both database and InfoSphere Data Replication. What makes a disk subsystem unreliable? Typically, disk mounting options that interfere with or modify the read visibility of write operations are the ones which will cause data to be read inaccurately, thereby causing applications such as databases and InfoSphere Data Replication to report errors and fail. The expectations of these semantics between the database and InfoSphere Data Replication must be compatible with those provided by the options used to mount the disk subsystem in order to avoid corruption issues. Some databases exhibit specific behaviors only with certain disk subsystem types, so proper care and attention is needed to properly configure the disk subsystem. Special notes regarding specific configurations Direct I/O on Linux—Due to the nature of the implementation of direct I/O (directio) on Linux, applications that read from files being written using direct I/O must employ exactly the same direct I/O options as the writing application. If this is not done, the reading application may not ever see the data written by the writing application and the reading application can therefore exhibit a stall. Linux versions of InfoSphere CDC prior to version 6.5.1 Interim Fix 17 for Oracle, version 6.5.2 Interim Fix 20 for Oracle, and InfoSphere Data Replication versions prior to 10.2 for Oracle and Sybase can exhibit this behaviour under certain conditions. The best resolution is to upgrade to the latest Interim Fix level for InfoSphere CDC or to version 10.2 or later for InfoSphere Data Replication.
27 IBM InfoSphere Change Data Capture, Version 10.2 Sizing considerations for the staging store This topic outlines scenarios that will increase the disk requirements for the staging store on your source system. All of these scenarios should be kept in mind when you are planning the disk space requirements for your replication environment. Latent subscriptions The amount of data within the staging store is related to the latency of your subscriptions. InfoSphere® CDC measures latency as the amount of time that passes between when data changes on a source table and when it changes on the target table. For example, if an application inserts and commits a row into the source table at 10:00 and InfoSphere CDC applies that row to the target table at 10:15, then the latency for the subscription is 15 minutes. When all of your subscriptions are mirroring and have very little latency, the volume of data that needs to be kept in the staging store will be relatively small. If all of your subscriptions are mirroring but some are latent, the staging store will contain all the data generated by the logs for the latent subscriptions during the entire time they are mirroring. For example, if the difference in latency between the least latent subscription and the most latent subscription is 3 hours, and your database generates 100 GB of log data per hour, the staging store will require approximately 300 GB of disk storage space.
Inactive subscriptions An inactive (not currently replicating) subscription that contains tables with a replication method of Mirror will continue to accumulate change data in the staging store from the current point back to the point where mirroring was stopped. For this reason, you should delete subscriptions that are no longer required, or change the replication method of all tables in the subscription to Refresh to prevent the accumulation of change data in the staging store on your source system.
Continuous Capture Continuous Capture is a product feature that is designed to accommodate those replication environments in which it is necessary to separate the reading of the database logs from the transmission of the logical database operations. This is useful when you want to continue processing log data even if replication and your subscriptions stop due to issues such as network communication failures over a fragile network, target server maintenance, or some other issue. You can enable or disable Continuous Capture without stopping subscriptions. Continuous Capture results in additional disk utilization on the source machine in order to accumulate change data from the database log file when these are not being replicated to the target machine. This change data is stored in the staging store. The additional disk utilization due to the accumulation of change data in the staging store should be evaluated and understood before deciding to use this feature in your replication environment.
Related concepts: Assessing disk space and memory requirements 28 Continuous Capture commands
29 IBM InfoSphere Change Data Capture, Version 10.2 Understanding the InfoSphere CDC memory footprint Current® versions of InfoSphere® CDC on Linux, UNIX, and Windows platforms are written in the Java™ programming language. The memory specified in the InfoSphere CDC configuration tool refers to the amount of memory that the Java Virtual Machine (JVM) will allocate to InfoSphere CDC to run. This memory is strictly enforced by the JVM itself and the JVM will ensure that it is not exceeded. The JVM itself also consumes some memory. The amount of this other memory varies considerably by Java version, bit length, and operating system. A simple Java program consumes 13212 KB of overhead when run in a 32-bit Java 1.5 JVM on AIX®, but 173509 KB of overhead when run in a 32-bit Java 1.5 JVM on Linux. In other words, the overhead on Linux is 13 times larger than the overhead on AIX, when controlling for the other variables. The amount of memory overhead consumed by the JVM itself can also change over time. This is especially true for Linux and UNIX systems. For those systems, once the operating system allocates memory to a process, it is not reclaimed until the process ends. Thus, the total amount of memory for any given process never goes down. Given these factors, you should expect that more memory is used by InfoSphere CDC than is allocated in the configuration tool. InfoSphere CDC has no control over this memory usage and cannot track or otherwise manage it.
30 IBM InfoSphere Change Data Capture, Version 10.2 Enabling Microsoft SQL Server Replication InfoSphere® CDC requires that you enable Microsoft SQL Server replication in your database to ensure the data required by InfoSphere CDC is available in the database transaction log. InfoSphere CDC for Microsoft SQL Server requires the log to contain full before and after images in an UPDATE operation in order to support database recovery; this information is not logged when replication is not enabled in Microsoft SQL server. InfoSphere CDC supports a local Distribution database (local Distributor) or a remote Distribution database (remote Distributor). If you are using a remote Distribution database, you are required to install InfoSphere CDC on your database server, not the Distribution database server. InfoSphere CDC for Microsoft SQL Server will configure subscriptions where all data is filtered out; in such cases, no data will end up in the Distribution database. After enabling SQL Server replication, SQL Server will create jobs that are used exclusively by SQL Server and are not used by InfoSphere CDC. Stopping any of the maintenance jobs may negatively affect SQL Server performance. If you need more information on how to perform this task, see your database administrator or refer to your Microsoft SQL Server documentation.
31 IBM InfoSphere Change Data Capture, Version 10.2 Configuring the recovery model In Microsoft SQL Server, configure your recovery model to be either Full or Bulk- Logged. The following example uses SQL statements to configure the pubs database: ALTER DATABASE pubs SET RECOVERY FULL If you need more information on how to perform this task, see your database administrator or refer to your Microsoft SQL Server documentation.
Related concepts: Backing up your database
32 IBM InfoSphere Change Data Capture, Version 10.2 Configuring a remote target of InfoSphere CDC If you are deploying InfoSphere® CDC for Microsoft SQL Server as a target, you have the option of installing the product on a system that is remote from the target database. To allow InfoSphere CDC to communicate with the target database, you must install Microsoft SQL Server connectivity tools on the server where you install InfoSphere CDC. Depending on your version of Microsoft SQL Server, you must install one of the following software packages on the server with InfoSphere CDC: - Microsoft SQL Server 2008—SQL Server 2008 Management Objects (SMO) - Microsoft SQL Server 2005—SQL Server 2005 Management Objects (SMO) For more information, see your Microsoft SQL Server documentation.
33 IBM InfoSphere Change Data Capture, Version 10.2 Backing up your database Perform a full database backup in SQL Server to start database logging in the Full or Bulk-Logged recovery model. The recovery model will remain ‘simple' until you perform a full database backup. The following example uses a SQL statement to perform a full backup for the ‘pubs' database: BACKUP DATABASE pubs TO DISK = 'c:\mssql\backup\pubs.bak' If you need more information on how to perform this task, see your database administrator or refer to your Microsoft SQL Server documentation.
34 IBM InfoSphere Change Data Capture, Version 10.2 Creating a transaction log backup plan InfoSphere® CDC requires backups of the transaction logs in Microsoft SQL Server. Your transaction log backup process must adhere to the following requirements: - Backups must be done with the Microsoft SQL Server Maintenance Plan or with a manual process in Microsoft SQL Server. Transaction log backups with third party tools are not supported. - Backups must create a new file and should not append or replace an existing file. Multiple transaction log backups to the same physical file are not supported. - Backups must not be compressed or encrypted. - InfoSphere CDC requires physical access to the transaction log backup files on disk. - You must retain transaction log backup files for as long as InfoSphere CDC is shut down or latent. InfoSphere CDC requires the transaction log backup files until all changes contained in the files are replicated to the target system. Use the dmshowlogdependency command to determine which backup files are still required. Note: It is beneficial for InfoSphere CDC performance if transaction log backups are kept to a size of 1 GB or less (if data volume permits). If you need more information on how to complete this task, see your database administrator or refer to your Microsoft SQL Server documentation.
Related reference: dmshowlogdependency - Show Log Dependency
35 IBM InfoSphere Change Data Capture, Version 10.2 Calculating database connections required by InfoSphere CDC for Microsoft SQL Server As an administrator, you may find it necessary to calculate how many database connections are needed before installing InfoSphere® CDC on either a source or a target database. Calculating the upper bound (both permanent and temporary) database connections will help you plan your environment so that it can accommodate InfoSphere CDC.
Calculating connections required by InfoSphere CDC on a source database (22 + G)*I + 4*S + L + CWhere: Note: Enter 0 for any value that does not apply to your deployment of InfoSphere CDC. - G = number of Management Console GUI and CHCCLP scripting applications that are connected to your instances of InfoSphere CDC. - I = number of InfoSphere CDC instances. - S = number of subscriptions in all of your InfoSphere CDC instances. - L = number of subscriptions that contain LOB columns. - C = number of InfoSphere CDC command line utilities that you plan to use.
Example: How to calculate required connections for a source database You want to set up InfoSphere CDC in the source environment as follows: - 1 instance of Management Console. - 2InfoSphere CDC instances. - 3 subscriptions. - 1 subscription that uses LOB columns. - You do not plan to use any InfoSphere CDC command line utilities. The number of connections required on the source database will be: (22+1)*2 + 4*3 + 1 = 59 You should plan for a maximum of 59 database connections before installing InfoSphere CDC on a source database.
Calculating connections required by InfoSphere CDC on a target database (4+G)*I + 3*SWhere: - G = number of Management Console GUI and CHCCLP scripting applications that are connected to your instances of InfoSphere CDC. - I = number of InfoSphere CDC instances. - S = number of subscriptions in all of your InfoSphere CDC instances.
Example: How to calculate required connections for a target database You want to set up InfoSphere CDC in the target environment as follows: - 1 installed Management Console GUI application. - 2InfoSphere CDC instances.
36 - 3 subscriptions.
The number of connections required on the target database will be: (4 + 1)*2 + 3*3 = 19 You should plan for a maximum of 19 database connections before installing InfoSphere CDC on the target database.
37 IBM InfoSphere Change Data Capture, Version 10.2 Database partition changes InfoSphere® CDC does not support database partition changes such as adding, removing, or moving except as documented for specific environments.
38 IBM InfoSphere Change Data Capture, Version 10.2 Creating queues in JMS providers If you choose to use a JMS provider as the communications protocol for InfoSphere® CDC, you will need to define the queues to be used by InfoSphere CDC before you attempt to configure an instance. The queues will need to be named in the format CDC_
39 IBM InfoSphere Change Data Capture, Version 10.2 Installing or upgrading InfoSphere CDC for Microsoft SQL Server Before attempting to install or upgrade InfoSphere® CDC, consult the database, operating system and hardware requirements for the specific version of the software that you want to install, to ensure that it is compatible with your system. If you are upgrading to a later version or installing a fix pack, an installation of InfoSphere CDC must already be present in order to successfully complete the process. In this section, you will learn:
- Installing InfoSphere CDC for Microsoft SQL Server - Upgrading InfoSphere CDC for Microsoft SQL Server You can upgrade InfoSphere CDC by installing a later version of the software over top of an existing installation.
40 IBM InfoSphere Change Data Capture, Version 10.2 Installing InfoSphere CDC for Microsoft SQL Server This section provides step-by-step instructions on how to install InfoSphere® CDC. Source deployments of InfoSphere CDC must be installed on the same server as your database. With target deployments of InfoSphere CDC, you have the option of installing the product on a different server from your target database. If you are installing a fix pack, you must already have an installation of InfoSphere CDC in order to successfully complete the installation. Note: Ensure that the installed version of the Management Console and Access Server applications are either the same version as the InfoSphere CDC replication engine or a later version. In this section, you will learn:
- To install InfoSphere CDC for Microsoft SQL Server
41 IBM InfoSphere Change Data Capture, Version 10.2 To install InfoSphere CDC for Microsoft SQL Server 1. Double-click on the installation executable. The IBM®InfoSphere® CDC installation wizard opens. 2. Click Next. 3. If you agree to the license terms, select I accept the terms in the license agreement and then click Next. 4. Select the folder where you want to install InfoSphere CDC and click Next. 5. If you already have an installation of InfoSphere CDC, the installation program will prompt you to upgrade the installation. Click OK to upgrade the installation. 6. Select the location for the product icons and click Next. 7. Review the installation summary and click Install. 8. Select Launch Configuration Tool to launch the configuration tool after the installation. The configuration tool allows you to add an instance of InfoSphere CDC. 9. Click Done to exit the installation.
42 IBM InfoSphere Change Data Capture, Version 10.2 Upgrading InfoSphere CDC for Microsoft SQL Server You can upgrade InfoSphere® CDC by installing a later version of the software over top of an existing installation. Interim fixes cannot be used to upgrade InfoSphere CDC to later versions. You must first install the general availability (GA) release of the software for the later version and accept the software license agreement, before applying any interim fixes. After the interim fix has been installed, you can start the InfoSphere CDC instances and complete the upgrade. Before attempting to upgrade the software, you should be aware of the following prerequisites: - All subscriptions in all InfoSphere CDC for Microsoft SQL Server instances associated with the installation to be upgraded must be stopped. - All InfoSphere CDC for Microsoft SQL Server instances associated with the installation must be stopped. - When logging in, you must use the same account that was used during the original installation of InfoSphere CDC for Microsoft SQL Server. - It is a best practice to backup the installation directory of the current InfoSphere CDC for Microsoft SQL Server installation. - It is a best practice to backup the InfoSphere CDC metadata tables (TS_AUTH, TS_BOOKMARK, TS_CONFAUD, and TS_DDLAUD) that are stored in the Microsoft SQL Server database instance that you are replicating to and from. In the event of a failure during the upgrade, having a backup of the metadata will allow you to revert to the point in time before the upgrade. In addition to the InfoSphere CDC metadata tables stored in your database, InfoSphere CDC maintains some other metadata in an internal database. It is a best practice to backup the InfoSphere CDC internal metadata at the same time as the InfoSphere CDC metadata tables in your database are backed up. The dmbackup command can be used to backup the internal InfoSphere CDC metadata tables. - Do not upgrade InfoSphere CDC as a root user. - The installation directory requires file system permissions of 700 to install the product, create and configure instances, or upgrade the product. When upgrading an InfoSphere CDC replication engine, you must also upgrade Management Console and Access Server to the same version or later to access the full range of functionality that was introduced in the later version of the engine. Management Console and Access Server are backward-compatible and will support the functionality available in earlier versions of the engines. CAUTION: You cannot export and import subscriptions across different versions of InfoSphere CDC. Do not attempt to import a subscription file from a previous version into an upgraded version. Once the upgrade is complete, you should create a new exported subscriptions xml file. See also:
- To upgrade InfoSphere CDC for Microsoft SQL Server
43
44 IBM InfoSphere Change Data Capture, Version 10.2 To upgrade InfoSphere CDC for Microsoft SQL Server 1. Ensure that all subscriptions in all InfoSphere® CDC instances are stopped. 2. Ensure that all InfoSphere CDC instances are stopped. 3. Ensure that you have a backup of the TS_AUTH, TS_BOOKMARK, TS_CONFAUD, and TS_DDLAUD metadata tables that are stored in the database instance that you are replicating to and from. In the event of a failure during the upgrade, having a backup of the metadata will allow you to revert to the point in time before the upgrade. In addition to the InfoSphere CDC metadata tables stored in your database, InfoSphere CDC maintains some other metadata in an internal database. It is a best practice to backup the InfoSphere CDC internal metadata at the same time as the InfoSphere CDC metadata tables in your database are backed up. The dmbackup command can be used to backup the internal InfoSphere CDC metadata tables. 4. Ensure that you have backed up your InfoSphere CDC installation directory. Important: The backup of the installation directory and the metadata tables should be from the same timeframe, so that they contain an identical snapshot of data. 5. Double-click on the installation executable. The IBM®InfoSphere CDC installation wizard opens. 6. Click Next. 7. If you agree to the license terms, select I accept the terms in the license agreement and then click Next. 8. Select the folder for the existing installation of InfoSphere CDC to be upgraded and click Next. 9. If you already have an installation of InfoSphere CDC, the installation program will prompt you to upgrade the installation. Click OK to upgrade the installation. 10. Select the location for the product icons and click Next. 11. Review the pre-upgrade summary and click Install. 12. After upgrading the software, you must start all the configured instances in order to complete the upgrade process. Depending on the number of tables and subscriptions configured, as well as the complexity of the mappings, the upgrade process can take anywhere from several minutes to hours. Once the upgrade process is complete, InfoSphere CDC will be ready for replication and will restart.
45 IBM InfoSphere Change Data Capture, Version 10.2 Configuring InfoSphere CDC for Microsoft SQL Server After installing InfoSphere® CDC, the installation program launches a configuration tool. The configuration tool allows you to configure one or more InfoSphere CDC instances for your environment. You must configure InfoSphere CDC before you can start replication. In this section, you will learn:
- Configuring InfoSphere CDC for Microsoft SQL Server instances
46 IBM InfoSphere Change Data Capture, Version 10.2 Configuring InfoSphere CDC for Microsoft SQL Server instances You can add, edit, or delete an instance of InfoSphere® CDC. Use the InfoSphere CDC configuration tool to work with instances. You do not have to start and stop instances. Before you add, edit, or delete an instance, ensure that the recovery mode has been set to Bulk or Full-Logged for each database from which you intend to capture data changes. After you complete the configuration, you can start InfoSphere CDC. Note: You can back up the metadata for your instance using the dmbackupmd command. See also:
- To add a new instance of InfoSphere CDC for Microsoft SQL Server - To edit an instance of InfoSphere CDC for Microsoft SQL Server - To delete an instance of InfoSphere CDC for Microsoft SQL Server
47 IBM InfoSphere Change Data Capture, Version 10.2 To add a new instance of InfoSphere CDC for Microsoft SQL Server 1. If you are configuring the first instance of InfoSphere® CDC after installation, you can proceed to Step 3 of this procedure. 2. At the command prompt, launch the configuration tool by issuing the following command in the specified directory:\
Option Description Name Enter a name for your InfoSphere CDC instance. This name must be unique. Server Port Enter the port number which InfoSphere CDC uses for communication with client workstations running Management Console and other servers.Note: This port number cannot be used by other applications installed on the same server. You will use this port number when specifying access parameters for your datastore in the Access Manager perspective in Management Console. InfoSphere CDC displays a default TCP/IP port of 10501. For more information, see your Management Console documentation. Auto-Discovery Port Bypass auto-discovery. This feature is disabled by default. Do not select the box or enter a port number. Staging Store Disk Quota Enter the maximum amount of (GB) disk space that will be utilized by the InfoSphere CDC staging store on your source system. The default value is 100 GB.Specify 1 GB if you are creating an instance that will be used as a target of replication. This reduces the disk resources that InfoSphere CDC requires on your target system.
48 Maximum Memory Allowed Enter the amount of physically (MB) available RAM that you want to allocate for this instance of InfoSphere CDC. By default, the configuration tool allocates 512 MB of RAM for each 32-bit instance and 1024 MB of RAM for each 64-bit instance.Note: Using values other than the defaults or allocating more RAM than is physically available on your server should only be undertaken after considering the impacts on product performance.
Bit Version Select the bit-version of your database by selecting one of the following options:32 bit64 bitThese options are not enabled if you are installing InfoSphere CDC on a 32-bit server. Note: You can use the select SERVERPROPERTY ('Edition' ) command to determine the bit version of your Microsoft SQL Server instance. 5. In the Windows Service area, you can specify the account that will be used to start InfoSphere CDC services. Select one of the following options:
Option Description Local System account Start InfoSphere CDC services through the local system administrator account.
49 This account Start InfoSphere CDC services through the specified user account. The account must be specified in the format
Option Description Host Enter the host name or IP address of your Microsoft SQL Server database. The default value is your local system, 127.0.0.1. Name Enter the name of the database that you want to replicate data to or from and contains all of the tables for replication. This is the database that you configured as part of the preinstallation tasks.Note: You cannot select a system database such as master, model, msdb, tempdb, or the distribution database.
50 Port Enter the TCP/IP port used by the instance of your Microsoft SQL Server that contains the database you specified above. You must configure the database to listen on a specific TCP/IP port to allow InfoSphere CDC to connect. InfoSphere CDC displays a default TCP/IP port of 1433. Metadata Schema Select the database schema used by InfoSphere CDC for metadata tables. You can specify any schema except those in use by other installed instances of InfoSphere CDC for the given database.Note:InfoSphere CDC metadata tables contain important configuration information and should be backed up as part of your database backup strategy. Note: Do not click the Advanced button and enter values unless directed by an IBM representative. 7. In the Authentication area, you can specify the type of authentication that will be used for connections to Microsoft SQL Server:
Option Description Windows Authentication User connections to Microsoft SQL Server will be authenticated through the Windows account under which InfoSphere CDC services will run. This account is specified in step 5. Indicates that InfoSphere CDC verifies that a SQL Server user exists. The password is not verified. With this type of authentication, you must specify a SQL Server user when you configure a datastore in the Access Manager perspective in Management Console.
51 SQL Authentication Indicates that user connections to Microsoft SQL Server will be authenticated through a specified Microsoft SQL Server login and password. In Microsoft SQL Server, make sure that SQL Server authentication is enabled for the server. For more information about enabling SQL Server authentication in Microsoft SQL Server, see the appropriate Microsoft publication. With this type of authentication, you will have to specify a SQL Server user name/password when configuring your datastore in the Access Manager perspective in Management Console. 8. In the Refresh Loader area, click Browse to specify the directory for Microsoft SQL Server BCP files for bulk inserts into the database. InfoSphere CDC requires write permission for this directory and your Microsoft SQL Server database requires read permissions for this directory.Notes: - Use a different directory for each instance of InfoSphere CDC. - This directory may contain information on the database tables that you are replicating. - If you are installing InfoSphere CDC as a target on a server that is different from your database server, you must specify UNC format for a shared directory on your database server. For example, \\databaseservername\mysharedirectory. InfoSphere CDC requires write privileges for this directory and SQL Server requires read privileges.
9. If you want to use a JMS provider as the method of communication between datastores, perform the following steps. Otherwise TCP/IP will be used exclusively as the communications protocol.A JMS provider should be used when characteristics of your network prevent the existence of a long term, stable TCP/IP connection. A. Ensure that a queue has been created by your system administrator and is named correctly. Each InfoSphere CDC instance that is to use a JMS message provider must have a queue named in the format CDC_
52 G. Enter a remote factory name. A connection factory encapsulates a set of connection configuration parameters that has been defined by an administrator. H. Enter a user name and password for JMS server authentication.This user name is defined by your JMS provider. Contact your system administrator for more information. I. Click the JNDI Server tab. J. Enter the constant that holds the local or remote connection factory name in the JNDI Initial Context box. Java™ Naming and Directory Interface (JNDI) is a programming interface from Oracle for connecting Java programs to naming and directory services. K. Enter the URL that is relative to the JNDI initial context in the JNDI URL box. In JNDI, all naming and directory operations are performed relative to a context. Therefore the JNDI defines an initial context that serves as a starting point for naming and directory operations. This value should be the fully- qualified class name of the factory class that will create the initial context. L. If the JNDI server to which you want to connect requires authentication, then you need to provide the user name and password to connect to that system. Contact your system administrator for information about the user name that you should specify. M. Click OK to save the connection. N. Click Test if you want to verify the connection.If the JMS Provider is not configured correctly, InfoSphere CDC will use TCP/IP as the communication protocol between datastores. O. Click OK. 10. Click OK to save your configuration settings for the InfoSphere CDC instance. 11. If InfoSphere CDC has detected an unsupported encoding, a dialog will open asking you to select an alternate encoding from a list.You can filter the list of alternate encodings by clicking one of the following buttons: - Closest match—Displays the alternated encodings that are the closest match to the data. - Comparable encodings byte length—Displays the alternate encodings in order of byte length. - All–Displays all alternate encodings. Select an encoding from the list and click OK. If you click Cancel, an error message will be displayed and the instance will not be created.
Related concepts: Starting InfoSphere CDC for Microsoft SQL Server Configuring a remote target of InfoSphere CDC Creating queues in JMS providers
Related reference: dmbackupmd - Back up metadata
53
54 IBM InfoSphere Change Data Capture, Version 10.2 To edit an instance of InfoSphere CDC for Microsoft SQL Server 1. In the Instances area, select the instance that you want to modify and click Stop if the instance is started. 2. In the Instances area, select an instance and click Edit.The InfoSphere® CDC Edit Instance dialog opens. 3. You can modify any of the values on this dialog box that you specified when adding an instance. 4. Click OK to save your changes and then click Close.The configuration tool will modify the instance. 5. In the Instances area, select the instance that you modified and click Start to start the instance.
55 IBM InfoSphere Change Data Capture, Version 10.2 To delete an instance of InfoSphere® CDC for Microsoft SQL Server 1. At the command prompt, launch the configuration tool by issuing the following command in the specified directory:\
56 IBM InfoSphere Change Data Capture, Version 10.2 Configuring InfoSphere CDC for Microsoft SQL Server for a Microsoft SQL Server cluster Note: The use of InfoSphere® CDC for Microsoft SQL Server is not supported in any AlwaysOn environment. You can configure InfoSphere CDC to operate and failover in a Microsoft SQL Server clustered environment. Clustering in Microsoft SQL Server provides continuous access to resources in the event of a hardware failure, software failure, or some other interruption. You must complete all of the tasks in this section to enable Active/Passive clustering support in InfoSphere CDC. This section also contains instructions for removing clustering support from InfoSphere CDC. In this section, you will learn:
- Installing InfoSphere CDC for Microsoft SQL Server in a Microsoft SQL Server cluster - Adding an instance and configuring the Microsoft SQL Server cluster - Deleting an instance from a Microsoft SQL Server cluster - Uninstalling InfoSphere CDC for Microsoft SQL Server from a Microsoft SQL Server cluster
57 IBM InfoSphere Change Data Capture, Version 10.2 Installing InfoSphere CDC for Microsoft SQL Server in a Microsoft SQL Server cluster You must install InfoSphere® CDC on the SQL Server cluster node that owns the shared disk array. The shared disk array is a collection of physical disks (SCSI RAID or Fibre Channel) that is accessed by the cluster.
Related concepts: Installing InfoSphere CDC for Microsoft SQL Server
58 IBM InfoSphere Change Data Capture, Version 10.2 Adding an instance and configuring the Microsoft SQL Server cluster After installing InfoSphere® CDC on the SQL Server cluster node that owns the shared disk array, you must add an instance using the configuration tool. 1. Start the configuration tool and add a new instance that specifies the port that the clustered SQL Server is listening on.Note: Do not start the instance after you add it. 2. Run the following command in the bin folder in your InfoSphere CDC installation directory:dmcreateclusterservice -I
Related concepts: Configuring InfoSphere CDC for Microsoft SQL Server
Related reference: dmcreateclusterservice - Create cluster service
59 IBM InfoSphere Change Data Capture, Version 10.2 Deleting an instance from a Microsoft SQL Server cluster 1. Use the Microsoft Cluster Administrator tool to take the cluster resource for the service offline. 2. Delete the cluster resource. 3. From the active node in the cluster, launch the InfoSphere® CDC configuration tool. 4. Delete the instance for the active node. 5. From the passive node in the cluster, delete the service using the following command:sc delete dmtssql_
Related tasks: Uninstalling InfoSphere CDC for Microsoft SQL Server from a Microsoft SQL Server cluster
60 IBM InfoSphere Change Data Capture, Version 10.2 Uninstalling InfoSphere CDC for Microsoft SQL Server from a Microsoft SQL Server cluster After deleting each instance from your clustered environment, you can uninstall InfoSphere® CDC for Microsoft SQL Server. From the active node in the cluster, navigate to the uninstall shortcut and uninstall InfoSphere CDC for Microsoft SQL Server.
Related tasks: Deleting an instance from a Microsoft SQL Server cluster
61 IBM InfoSphere Change Data Capture, Version 10.2 After you install and configure InfoSphere CDC for Microsoft SQL Server Once you have installed and configured InfoSphere® CDC, you can start using InfoSphere CDC. In this section, you will learn:
- Starting InfoSphere CDC for Microsoft SQL Server - Stopping InfoSphere CDC for Microsoft SQL Server - Performing an external refresh - Maintaining active TCP connections in a network environment - Enabling SQL statements in Management Console
62 IBM InfoSphere Change Data Capture, Version 10.2 Starting InfoSphere CDC for Microsoft SQL Server When you install InfoSphere® CDC on a supported Windows server, you can start it manually after the initial configuration. Starting InfoSphere CDC starts the services in Windows. The services will automatically start after a reboot. Note: If you are installing InfoSphere CDC on a different system from Microsoft SQL Server and are using the remote apply, you will have to manually stop and restart InfoSphere CDC when you restart Microsoft SQL Server. See also:
- To start InfoSphere CDC for Microsoft SQL Server (Windows)
63 IBM InfoSphere Change Data Capture, Version 10.2 To start InfoSphere CDC for Microsoft SQL Server (Windows) 1. At the command prompt, launch the configuration tool by issuing the following command in the specified directory:\
64 IBM InfoSphere Change Data Capture, Version 10.2 Stopping InfoSphere CDC for Microsoft SQL Server It may be necessary to stop InfoSphere® CDC when you want to change the configuration settings, take a server or database offline for maintenance purposes, or if you want to upgrade InfoSphere CDC. You can use the configuration tool or commands to stop InfoSphere CDC. See also:
- To stop InfoSphere CDC for Microsoft SQL Server (Windows)
65 IBM InfoSphere Change Data Capture, Version 10.2 To stop InfoSphere CDC for Microsoft SQL Server (Windows) 1. End replication on all subscriptions in Management Console. For more information on how to end replication on subscriptions, see your Management Console documentation. 2. Launch the configuration tool by issuing the following command in the specified directory:\
66 IBM InfoSphere Change Data Capture, Version 10.2 Performing an external refresh You can perform a refresh of one or more tables in a subscription using a third-party tool, and still integrate this activity into the refresh while active capability of InfoSphere® CDC. Such third-party tools might be a table unload at source and load at target, an application program that regenerates the content of a table being run against both the source and target tables, recovery of a table's content to a prior point in time at both the source and target, or even a refresh of the table using a subscription other than the one that will be mirroring the data. A refresh or reconstruction of a table by such a means is referred to as an external refresh. Note: An external refresh can only be performed when the target is database, not a message queue or an ETL solution. Performing an external refresh using the dmmarkexternalunloadstart and dmmarkexternalunloadend commands is not supported for the following replication engines: - InfoSphere CDC for InfoSphere DataStage® (either Direct Connect or Flat File) - InfoSphere CDC Event Server - InfoSphere Classic CDC for z/OS®
In order to integrate the activity of the external refresh into the mirroring activity of the subscription, new command capabilities have been added to the products. To understand what these commands do, how to provide usable data to them, and what to avoid so that they won't be misused, it is necessary to understand the mechanism of refresh while active processing. Understanding refresh while active When a table within a subscription is set to Method:Mirror and Status:Refresh, it is readied for a refresh while active. When the subscription is started, as viewed externally, the table is refreshed and then mirroring of the tables in the subscription starts. When the subscription starts, it must necessarily start scraping from the log at a place prior to the place when the refresh was performed. For the table that was refreshed at the start of mirroring, changes scraped from the log are discarded until scraping reaches the place where the refresh had started. From that point forward, changes scraped for that table are forwarded to the target for application to the target table. Between the place in the log where the refresh started and the place where the refresh ended, a change scraped from the log could either have been applied to the table or not yet have been applied to the table by the time that portion of the table was refreshed. Thus the change may or may not have been forwarded to the target and been applied to the target table during the refresh. For this reason, changes scraped from the log between the places where the refresh ran are applied at the target with an error mitigation filter that suppresses operational errors (INSERT of a preexisting row, UPDATE or DELETE of a nonexisting row). These changes are said to be sent with the "indefinitely refreshed" indicator set. Once scraping proceeds past the place in the log where the refresh ended, the indefinitely refreshed indicator is no longer set, and operational errors are treated as harshly as any other.It is possible that changes that have been logged before the place in the log when the refresh started were not yet committed when the refresh started. Such changes would appear in the table after the COMMIT was issued, but would be discarded when they were scraped from the log because they were logged prior to the refresh starting place in the log. The capture of the table's content during the 67 refresh could miss these changes, depending on how much time passes before the COMMIT is issued. This would cause the source and target tables to be unsynchronized. To avoid this, InfoSphere CDC uses methods based on the DBMS in use to establish a point of consistency for the table at the time that the refresh for a refresh while active is starting. For example, on the z/OS platform, before the refresh starts, a shared lock with a table scope is obtained on the table being refreshed. The current log write position is determined, then the lock is released. This forces any units of recovery that contain changes for the table being locked to complete (that is, a COMMIT). When the shared lock is released the refresh starts, and the log write position sampled while the lock was held will be used as the place for the start of the refresh. The shared lock is held for milliseconds at most, and should not be disruptive to normal application processing for the table.
Considerations for an external refresh When an external refresh occurs, it involves the capturing of the source table's content and the writing of that content to the target table. The period when the source table's content is being captured is equivalent to the period during a refresh while active when the source table is being read. Depending on how the source and target tables are being re-synchronized outside of the subscription, this period could be significantly long (for example, using unload and load) or effectively instantaneous (for example, point-in-time recovery at both source and target). For InfoSphere CDC for z/OS, this period needs to be converted to a starting place and an ending place in the log, expressed in terms of log positions in the DBMS's log. The two (possibly identical) log positions are then provided to InfoSphere CDC using the command interface, and InfoSphere CDC updates the metadata with them as though they had originated from the execution of the refresh of a refresh while active . When the subscription starts to mirror, these two log positions describe the scrape point when discarding of the table's data stops and marking changes as 'indefinitely refreshed starts, and when marking changes as indefinitely refreshed stops. For all other supported engines, the refresh while active period is determined by the current position of the log when the dmmarkexternalunloadstart and dmmarkexternalunloadend commands are issued.
In order for this update to the metadata to be effective and productive, the following have to be true: 1. The subscription must not be active, as is always the case when a subscription's attributes are being modified. 2. The first (earlier) of the two log positions must not be earlier than the log position where the subscription will start scraping. If this rule is not followed, the results are not predictable. 3. Neither of the two log positions should be for a place that has not yet been written to the log. If this rule is not followed, the results are not predictable. In addition to these considerations, there is also the issue of establishing a point of consistency at the start of capturing the source table for the external refresh. When performing a refresh while active, as explained above, a point of consistency for the table being refreshed is established by acquiring a shared lock with table scope. This method is unavailable when doing an external refresh, so other means of establishing a point of consistency should be employed. Sometimes, this will not be 68 possible, such as for a point-in-time recovery at both the source and target. If it is possible, such as when performing an unload and reload, then it is strongly recommended that a point of consistency be established. This can be done by quiescing activity against the table, or simply by stopping all updating application programs. Sometimes it may not be necessary, such as when a program is used to regenerate the entire table content at both the source and target (assuming such a program would, by its action, implicitly lock the entire table). Failure to take the steps to establish a point of consistency could produce operational errors later, under the scenario described above.
- To perform an external refresh
Related reference: dmmarkexternalunloadend - End table data unload dmmarkexternalunloadstart - Start table data unload
69 IBM InfoSphere Change Data Capture, Version 10.2 To perform an external refresh 1. Stop the subscription, if it is currently running. 2. Run the dmmarkexternalunloadstart command. 3. Use an external tool to unload the table data.You should determine if there are any limitations on transaction isolation levels by your external tool. 4. Wait for the unload to complete. 5. Run the dmmarkexternalunloadend command. 6. Use your external tool to load the table data on the target. 7. Start the subscription.InfoSphere® CDC will reconcile the differences corresponding to the changes made to the source table during the synchronization phase. InfoSphere CDC runs in the manner of Adaptive Apply during the range marked by the start and end commands.
Related reference: dmmarkexternalunloadend - End table data unload dmmarkexternalunloadstart - Start table data unload
70 IBM InfoSphere Change Data Capture, Version 10.2 Maintaining active TCP connections in a network environment If your deployment of InfoSphere® CDC is in a network environment that uses a firewall, VPN gateway, or local system tools to detect idle TCP connections, it may be necessary to configure the product to prevent these connections from being closed during periods of application inactivity between the source and target. By default, InfoSphere CDC sends a message over TCP connections every 20 seconds to ensure these connections remain active during periods of inactivity. If your network policies close TCP connections for idle periods of less than 20 seconds, you must change the configuration of each instance of InfoSphere CDC to ensure the TCP connections remain open. See also:
- To maintain active TCP connections
71 IBM InfoSphere Change Data Capture, Version 10.2 To maintain active TCP connections 1. For each instance of InfoSphere® CDC, navigate to the following directory:
72 IBM InfoSphere Change Data Capture, Version 10.2 Enabling SQL statements in Management Console InfoSphere® CDC lets you execute SQL statements after it applies a table-level clear or refresh operation to a target table. You can specify SQL statements in the Additional SQL dialog box in Management Console. By default, this feature is disabled in InfoSphere CDC for security reasons. You can enable this feature by creating a table called TS_SQL_EXECAUTH in the database where you installed InfoSphere CDC. The structure of the table is unimportant, and you must create the table using the same schema as the metadata tables during the configuration of InfoSphere CDC. For more information about specifying SQL statements in Management Console, see Specifying SQL to control refresh operations in your Management Console documentation. See also:
- To enable SQL statements in Management Console
73 IBM InfoSphere Change Data Capture, Version 10.2 To enable SQL statements in Management Console 1. Locate the database on the target server that you created for InfoSphere® CDC. Depending on how you are using InfoSphere CDC, this is the database you want InfoSphere CDC to replicate to or from.Note: During installation, InfoSphere CDC places metadata tables in the database necessary for InfoSphere CDC processes. 2. If you want to enable the specification of SQL statements, create a table named TS_SQL_EXECAUTH in the database.Note: The table can have any structure and must be created in the schema you specified when you configured InfoSphere CDC.
74 IBM InfoSphere Change Data Capture, Version 10.2 Replication considerations In this section, you will learn:
- Replicating data from a table without a primary key - Replicating computed columns - Replicating identity columns - Replicating the rowversion data type - Replicating columns with database defaults
75 IBM InfoSphere Change Data Capture, Version 10.2 Replicating data from a table without a primary key InfoSphere® CDC supports replication of data from a table without a primary key in SQL Server 2008. This feature is not supported in SQL Server 2005. The following task outlines the required steps to replicate data in a table without a primary key by using the Microsoft Change Data Capture feature in Microsoft SQL Server 2008. CAUTION: If you are using SQL Server 2008, replicating data in a table without a primary key will cause all the changed row data to be logged to a table in the SQL Server database. Depending on circumstances, this can result in a dramatic performance decrease and so should be undertaken with appropriate caution. Consult your Microsoft SQL Server documentation for further details on how the Change Data Capture feature is implemented and its likely performance impact on your database. See also:
- To replicate data from a table without a primary key
76 IBM InfoSphere Change Data Capture, Version 10.2 To replicate data from a table without a primary key 1. In SQL Server 2008, enable the Microsoft Change Data Capture for your database and for the table that does not have a primary key. For more information on how to do this, see your Microsoft SQL Server documentation. 2. Create a table mapping in Management Console and specify this table as the source table. The configuration of Microsoft Change Data Capture for the table will be verified when the mapping is saved and any errors will be reported.
77 IBM InfoSphere Change Data Capture, Version 10.2 Replicating computed columns InfoSphere® CDC can replicate data in computed columns. When replicating computed columns, consider the following: - Computed columns are read from the database at the time of replication. Therefore, only the current image of a computed column field in a source table will be sent at the time of replication. - You cannot reference computed columns in row-filtering expressions. - You cannot reference computed columns in an expression defined for a derived column. - If the computed column is a LOB, then all the LOB considerations apply. See also:
- Replicating data to a table with computed columns
78 IBM InfoSphere Change Data Capture, Version 10.2 Replicating data to a table with computed columns InfoSphere® CDC can replicate data from a source table to a target table that contains computed columns. If your target table contains computed columns, map the initial value as Database Default in Management Console. All the other columns can be mapped to source columns. When replicating data to tables containing computed columns, consider the following: - You cannot obtain the value of computed columns in the target database with InfoSphere CDC. InfoSphere CDC skips the column that is mapped to Database Default on the target when applying data. - You cannot define computed columns as key columns in a target table. - You cannot reference computed columns from the target in a derived expression. - User exits cannot access the data for any computed columns on the target. - isDataAvailable(int) in the InfoSphere CDC API can be used in a user exit to determine if there is data for a specific column. This method will return false for target computed columns. An exception is thrown if you attempt to retrieve the value from a column that is mapped to a target computed column.
79 IBM InfoSphere Change Data Capture, Version 10.2 Replicating identity columns Identity columns in source tables are handled similarly to columns without the identity property. The value of a source column is retained when mapped to a target identity column. Target identity columns will use the value provided by the database if you set the initial value of the column in Management Console to Database Default. When replicating data to or from tables containing identity columns, consider the following: - Any column which has the initial value of the mapping set to Database Default is not applied by InfoSphere® CDC. InfoSphere CDC skips the column when applying data and the database provides a value. - You cannot reference a target identity column that has the initial value set to Database Default in a derived expression. There is no restriction on the source columns in a similar scenario. - User exits cannot access the data for any target column that has an initial value set to Database Default in Management Console. - isDataAvailable(int) in the InfoSphere CDC API can be used in a user exit to determine if there is data for a specific column. This method will return false for a target column with an initial value set to Database Default in Management Console. An exception is thrown if you attempt to retrieve the value from a column that is mapped to a target identity column.
80 IBM InfoSphere Change Data Capture, Version 10.2 Replicating the rowversion data type InfoSphere® CDC supports source and target tables that contain the ROWVERSION data type. The ROWVERSION data type in Microsoft SQL Server cannot be modified externally. If you want to retain the ROWVERSION data type in your source table, map the column in Management Console to a BINARY(8) data type on the target. If you want the source table schema to be identical to the target table schema, set the target column to an initial value of Read Only in Management Console. When replicating data to tables containing the ROWVERSION data type, consider the following: - Replicating the rowversion data type from a source table when mapped to a binary data type on the target has similar restrictions to the replication of BINARY data types - ROWVERSION when present both in source and target table will contain different values when replicating values for other columns. - ROWVERSION data types in the target table are not applied by InfoSphere CDC. InfoSphere CDC skips the column when applying data and the database provides a value. - When mapping a column to ROWVERSION on the target, you cannot reference target ROWVERSION columns in a derived expression. There is no restriction on the source columns in a similar scenario. - User exits cannot access the data for any target ROWVERSION columns. There is no restriction on the source columns in a similar scenario. - isDataAvailable(int) in the InfoSphere CDC API can be used in a user exit to determine if there is data for a specific column. This method will return false for a target column having an initial value set to Read Only. isReadOnly(int) will return true for these columns. An exception is thrown if you attempt to retrieve the value from a column that is mapped to a target ROWVERSION column.
81 IBM InfoSphere Change Data Capture, Version 10.2 Replicating columns with database defaults Columns having a database default value in the target database can either be overwritten with values coming from the source table or be set to have the initial value of Database Default in Management Console. InfoSphere® CDC skips any column that is set to the initial value of Database Default when applying data on target. The column must be nullable or have a database default value defined in the target database, otherwise SQL exceptions may occur when InfoSphere CDC applies data on the target. When replicating data to tables containing columns having database defaults, consider the following: - All supported data types are supported with database defaults. - If you map a source column to a target column containing a database default, the source value will be inserted in the target column. - You cannot reference target Database Default columns from the target in a derived expression. - User exits cannot access the data for any target column that has an initial value set to Database Default in Management Console. - isDataAvailable(int) in the InfoSphere CDC API can be used in a user exit to determine if there is data for a specific column. This method will return false for a target column with an initial value set to Database Default in Management Console . An exception is thrown if you attempt to retrieve the value from a column that is mapped to a target database default column.
82 IBM InfoSphere Change Data Capture, Version 10.2 InfoSphere CDC for Microsoft SQL Server metadata tables InfoSphere® CDC maintains a set of metadata tables that represent data about your current replication configuration. These tables are created in the schema and database that you specify in the configuration tool and should be part of the backup strategy for your database. InfoSphere CDC will not replicate these tables. Do not modify the contents of these tables unless requested to do so by your IBM® representative. The names of the metadata tables created by InfoSphere CDC are as follows: - TS_AUTHNote: For all users you added in the Access Manager perspective in Management Console, make sure you give GRANT SELECT privileges to the TS_AUTH metadata table. - TS_BOOKMARK - TS_CONFAUD—The conflict resolution audit table records information about conflicts that were resolved using conflict detection and resolution.
Related concepts: Configuring InfoSphere CDC for Microsoft SQL Server
83 IBM InfoSphere Change Data Capture, Version 10.2 Data types supported by InfoSphere CDC for Microsoft SQL Server For information about data types supported by InfoSphere® CDC for Microsoft SQL Server, see Supported data types.
84 IBM InfoSphere Change Data Capture, Version 10.2 System parameters for InfoSphere CDC for Microsoft SQL Server For information about system parameters for InfoSphere® CDC for Microsoft SQL Server, see System parameters for InfoSphere CDC for Microsoft SQL Server.
85 IBM InfoSphere Change Data Capture, Version 10.2 Commands for InfoSphere CDC for Microsoft SQL Server This section discusses the commands available with InfoSphere® CDC. Using these commands you can control replication, manage your tables for replication, monitor replication, and perform various other tasks. In this section, you will learn:
- Using the InfoSphere CDC for Microsoft SQL Server commands - Setting the TSINSTANCE environment variable - Continuous Capture commands - Controlling replication commands - Database transaction log commands - Exporting and importing configuration commands - Managing tables for replication commands - Monitoring replication commands - Single scrape and staging store commands - Other commands
86 IBM InfoSphere Change Data Capture, Version 10.2 Using the InfoSphere CDC for Microsoft SQL Server commands You can issue InfoSphere® CDC commands at a command line prompt or as part of a batch file or shell script. Commands are located in the bin directory of your InfoSphere CDC installation directory. You must run the commands from this directory. Note: Use the -? flag to list the available parameters for a command and a short description of each parameter. For example, dmstartmirror -?. Command formats For each command, the following items of information are provided: - Syntax—Identifies the name of the command and lists the command parameters. - Parameters—Describes each parameter in the command and identifies the values that can be specified. - Result—Indicates the values that are returned by the command if it is successful. These values can be useful for scripting. This section also specifies the information that is displayed on the screen, if any, as a result of executing the command. - Examples—Provides one or more examples of invoking the command.
Parameter formats Note the following conventions in the definition of the command parameters: - Angle brackets ( < > ) indicate a mandatory parameter. - Square brackets ( [ ] ) indicate an optional parameter. If you omit the parameter, InfoSphere CDC uses a default value. - A vertical bar ( | ) separating one or more parameters indicate that only one of the parameters in the list can be used. When one or more vertical bars appear in a list of parameters that is enclosed by square brackets [ ], the choices are limited to the parameters in the list, but you have the option to not specify any of the parameters. - Ellipsis ( ... ) means that a parameter or option can be repeated more than once. - You can issue the commands in or Windows.
Windows Server 2012 and User Account Control (UAC) Due to the nature of the implementation of User Account Control (UAC) in Windows Server 2012, some InfoSphere CDC command-line programs run as a non- Administrator will require elevation and incur an elevation prompt. In these situations, the command will run and complete as normal. However, any output to the screen will be lost when the command completes.To avoid this behaviour, InfoSphere CDC command-line programs can be run as Administrator. Doing so will preserve the output of the command.
87 IBM InfoSphere Change Data Capture, Version 10.2 Setting the TSINSTANCE environment variable Before using InfoSphere® CDC commands, you can set the TSINSTANCE environment variable to the name of your InfoSphere CDC instance. After you set the TSINSTANCE environment variable, you no longer have to specify the instance name when issuing commands. Windows Issue the following command at the command prompt: SET TSINSTANCE=
88 IBM InfoSphere Change Data Capture, Version 10.2 Continuous Capture commands Continuous Capture is a product feature that is designed to accommodate those replication environments in which it is necessary to separate the reading of the database logs from the transmission of the logical database operations. This is useful when you want to continue processing log data even if replication and your subscriptions stop due to issues such as network communication failures over a fragile network, target server maintenance, or some other issue. You can enable or disable Continuous Capture without stopping subscriptions. Continuous Capture allows you to avoid spikes in your source system CPU resource utilization by continuing to process log data (and write to disk as necessary) even when subscriptions are stopped. This feature allows you to avoid situations where the product uses no CPU when subscriptions are stopped and high CPU when you start subscriptions after a prolonged target system outage. This functionality comes with the trade-off of additional disk utilization on the source machine in order to accumulate changes from the database log file when these are not being replicated to the target machine. These trade-offs should be evaluated and understood before deciding to use this feature in your replication environment. To use the commands in this section that are applicable to Continuous Capture, you must set the staging_store_can_run_independently system parameter to false. The default value for this parameter is true. See also:
- dmdisablecontinuouscapture - Disable Continuous Capture - dmenablecontinuouscapture - Enable Continuous Capture
89 IBM InfoSphere Change Data Capture, Version 10.2 dmdisablecontinuouscapture - Disable Continuous Capture Use this command to disable Continuous Capture for your staging store.
Syntax dmdisablecontinuouscapture [-I
Parameters - -I
Related reference: dmenablecontinuouscapture - Enable Continuous Capture dmgetstagingstorestatus - Retrieve Staging Store status
90 IBM InfoSphere Change Data Capture, Version 10.2 dmenablecontinuouscapture - Enable Continuous Capture Use this command to enable Continuous Capture for your staging store. Continuous Capture allows the InfoSphere® CDC log reader to continue operating when communication with the target datastore is interrupted due to network difficulties or other issues. Upon resumption of communication with the target, Continuous Capture will reduce the latency between the source and target datastores.
Syntax dmenablecontinuouscapture [-I
Parameters - -I
Related reference: dmdisablecontinuouscapture - Disable Continuous Capture dmgetstagingstorestatus - Retrieve Staging Store status
91 IBM InfoSphere Change Data Capture, Version 10.2 Controlling replication commands This section contains commands that control replication in InfoSphere® CDC. See also:
- dmendreplication - End replication - dmrefresh - Refresh subscription - dmstartmirror - Start mirroring
92 IBM InfoSphere Change Data Capture, Version 10.2 dmendreplication - End replication Use this command to end refresh or mirroring on the specified subscriptions. Ending replication allows you to prepare for transitional activities in your business environment and allows you to move to the next step in your business processes. Here are some examples of transitional activities in your business environment that may require an end to replication: - Initiating a database backup. - Performing a regularly scheduled reboot of your source database server. - Quiescing your database in preparation for an upgrade. - Weekly batch processing has just completed. - Preparing for off-line maintenance activities.
If you are replicating data continuously with Continuous mirroring and business reasons arise that require an end to replication, InfoSphere® CDC provides multiple options that suit most business needs. If your business requirements dictate that replication must end at a particular point in your source database log because the target database must be in a known state when replication ends, you can choose from the following Scheduled End to replication options: - -se parameter—When specified without –t or –p, this parameter ends replication at the current time in the source database log. - -t parameter—When specified with –se, this parameter ends replication at a user- specified date and time. - -p parameter—When specified with –se, this parameter ends replication at a user- specified log position.
An example of a scenario that might require these options is that you are populating a reporting instance and you need stable (non-changing) data in your reporting instance during the day. At the end of the day when you shut down your application, you can choose one of the Scheduled End (Net Change) options to update the reporting instance with data from the current day as well. If business requirements do not require a specific end point but do require a time frame for ending replication, InfoSphere CDC provides escalating options (Normal, Immediate, and Abort) that end replication more rapidly at the expense of a slower start when resuming replication. For example, a routine end to replication with no particular urgency may require the Normal option, whereas a sudden business need to end replication rapidly may require the Abort option. A routine reboot of a SAN might be appropriate for the Normal option, whereas a sudden and unexpected hardware or application failure may require the Abort option. If you initiate an end to replication and business reasons warrant a change in the time frame, you can reschedule the end of replication by specifying a new date and time, a new position in the database log, or choose another option for ending replication. Ending replication is also necessary if you want to update and make changes to your subscription by: - Adding a table mapping to the subscription. - Deleting a table mapping from the subscription.
93 - Temporarily removing a table mapping from the subscription (parking a table). - Modifying mapping details such as source and target column mappings, derived columns, data translations, row and column selections, user exits, and so on. - Updating the properties of a subscription when the structure of your source or target tables change.
This command also includes an asynchronous option for scripting (-nw parameter) that can be used with -se to allow your script to continue executing without waiting for the Scheduled End to replication. You can also start and end replication in Management Console. For more information, see Starting and ending replication. To stop an instance after ending replication on all subscriptions, use the dmshutdown command.
Syntax dmendreplication [-I
Parameters - -I
Note: As latency between the source and target increases, the amount of time required to end replication will also increase. - -t
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
Examples dmendreplication -I MYINSTANCE -c -s FINANCEInfoSphere CDC ends replication with the Normal option for the FINANCE subscription in the specified instance. dmendreplication -I MYINSTANCE –se –t “2010-02-05-00-00” FINANCE -nw InfoSphere CDC ends replication with the Scheduled End option for the FINANCE subscription at the specified time in the source database log. The command exits before Scheduled End processing is complete. dmendreplication -I MYINSTANCE –a –s SUBSCRIPTION1 SUBSCRIPTION2 InfoSphere CDC ends replication with the Abort option for SUBSCRIPTION1 and SUBSCRIPTION2 in the specified instance.
96 IBM InfoSphere Change Data Capture, Version 10.2 dmrefresh - Refresh subscription Use this command to refresh the specified subscriptions. When you refresh a subscription, InfoSphere® CDC ensures that the target tables are synchronized with the source tables. Typically, you would refresh target tables when you have set the replication method to Refresh on your tables. However, you can also refresh target tables that have a replication method set to Mirror and a status of Active or Refresh. When you refresh a table configured for mirroring, InfoSphere CDC refreshes the target table so that it is synchronized with the source table and then marks a table capture point as the starting point for mirroring. This command exits after it has successfully refreshed the specified subscriptions. If you terminate this program while it is still running, InfoSphere CDC ends replication immediately for the specified subscriptions.
Syntax dmrefresh [-I
Parameters - -I
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
Examples dmrefresh -I NEWINSTANCE -a -s FINANCEInfoSphere CDC refreshes all target tables in the Finance subscription.
97
98 IBM InfoSphere Change Data Capture, Version 10.2 dmstartmirror - Start mirroring Issue this command from your InfoSphere® CDC source to start mirroring on the specified subscriptions. This command starts mirroring for any table with a replication method of Mirror and a status of Refresh or Active. Tables with a replication method of Mirror and a status of Refresh are refreshed before mirroring begins. InfoSphere CDC provides two types of mirroring for source tables that are mapped to target tables: Continuous (-c parameter) and Scheduled End (Net Change) (-n parameter). The type of mirroring you select depends on your business needs. As its name implies, Continuous mirroring replicates changes to the target on a continuous basis. Use this type of mirroring when business requirements dictate that you need replication to be running continuously and you do not have a clearly defined reason to end replication at the present time. Scheduled End (Net Change) mirroring replicates changes (to the target) up to a user-specified point in the source database log and then ends replication. Use this type of mirroring when business requirements dictate that you only replicate your data periodically and you have a clearly defined end point for the state of your target database when replication ends. Scheduled End (Net Change) mirroring allows you to end replication at the following points in your source database log: - -n parameter—When specified without –tor –p, this parameter ends replication at the current time in the source database log. - -t parameter—When specified with –n, this parameter ends replication at a user- specified date and time. - -p parameter—When specified with –n, this parameter ends replication at a user- specified log position.
These user specified end points ensure that your target database is in a known state when replication ends. You can also start and end replication in Management Console. For more information, see Starting and ending replication.
Syntax dmstartmirror [-I
Parameters - -I
Note: As latency between the source and target increases, the amount of time required to end replication will also increase. - -t
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
100 Examples dmstartmirror -I MYINSTANCE -c -s FINANCEInfoSphere CDC starts continuous mirroring for the FINANCE subscription. dmstartmirror -I MYINSTANCE –n –p “000000FB:000001A4:0001” –nw –A InfoSphere CDC starts mirroring with the Scheduled End option for all subscriptions in the specified instance. Replication will end at the specified Microsoft SQL Server LSN in the source database log. The command will not wait for Scheduled End processing to complete. dmstartmirror -I MYINSTANCE –n –t “2010-02-05-00-00” FINANCE -nwInfoSphere CDC starts mirroring with the Scheduled End option for the FINANCE subscription in the MYINSTANCE instance. Replication will end at the specified time in the source database log. The command will exit before Scheduled End processing is complete.
101 IBM InfoSphere Change Data Capture, Version 10.2 Database transaction log commands This section contains commands that help you manage your database transaction log or bookmarks. See also:
- dmdecodebookmark - Display verbose information bookmark - dmsetbookmark - Set bookmark - dmshowbookmark - Display bookmark information - dmshowlogdependency - Show Log Dependency
102 IBM InfoSphere Change Data Capture, Version 10.2 dmdecodebookmark - Display verbose information bookmark Use this command to display verbose information about a bookmark.
Syntax dmdecodebookmark [-I
Parameters - -I
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
Examples dmdecodebookmark -f bookmark.txtInfoSphere CDC displays information about the bookmark stored in the bookmark.txt file.
103 IBM InfoSphere Change Data Capture, Version 10.2 dmsetbookmark - Set bookmark CAUTION: Improper use of this command can result in data loss or data duplication. You should only execute this command when directed by IBM Technical Support. Use this command on your InfoSphere® CDC source system to set the replication position (bookmark) in the stream of change data for a subscription. You can obtain the replication position for a subscription with the dmshowbookmark command, which is executed on your InfoSphere CDC target system.
Syntax dmsetbookmark [-I
Parameters - -I
- -a - Sets all tables in the subscriptions (except for parked tables) as active as of the new replication position (bookmark). If you do not specify this value, InfoSphere CDC will use -a by default. - -L
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails
Examples dmsetbookmark -I MYINSTANCE -b 6578616d706c65 -s FINANCEInfoSphere CDC sets a replication position (bookmark) for the Finance subscription for the specified instance. This command specifies that mirroring will resume at the indicated replication position in the database log. dmsetbookmark -I MYINSTANCE -f bookmark -s FINANCEInfoSphere CDC sets a replication position (bookmark) for the Finance subscription for the specified instance. This command specifies that mirroring will resume at the replication position (bookmark) contained in the bookmark file. InfoSphere CDC will auto-detect the XML or binary format of the file. The file is located in InfoSphere CDC installation directory since no absolute path is specified.
105 IBM InfoSphere Change Data Capture, Version 10.2 dmshowbookmark - Display bookmark information CAUTION: Improper use of this command in conjunction with the dmsetbookmark command can result in data loss or data duplication. You should only execute the dmsetbookmark command when directed by IBM Technical Support. Use this command on your InfoSphere® CDC target system to obtain the replication position (bookmark) in the stream of change data for a subscription. After generating the replication position information with this command, you can use the dmsetbookmark command on the source system to set the replication position for a subscription.
Syntax dmshowbookmark [-I
Parameters - -I
106 - -v - Displays verbose information about the replication position (bookmark), including a hexadecimal-encoded string. The amount of information displayed depends on the type and version of the source engine. The hexadecimal- encoded string is always displayed. This parameter displays a subset of what the dmdecodebookmark command displays. If not specified, only a hexadecimal-encoded string is displayed.Note: Use the -x parameter if you are issuing this command from the target of a DB2 LUW DPF source environment. - -L
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
Examples dmshowbookmark -I MYINSTANCE -s MASTER -f bookmarkInfoSphere CDC obtains the replication position (bookmark) information for the specified instance and the MASTER source ID. Replication position (bookmark) information is contained in the bookmark binary file which will be placed in the InfoSphere CDC installation directory since no absolute path has been specified. dmshowbookmark -I MYINSTANCE -s FINANCE -x mybookmarksInfoSphere CDC obtains the replication position (bookmark) information for the specified instance and the FINANCE source ID. Replication position (bookmark) information is contained in the mybookmarks XML file which will be placed in the InfoSphere CDC installation directory since no absolute path has been specified.
107 IBM InfoSphere Change Data Capture, Version 10.2 dmshowlogdependency - Show Log Dependency Use this command to display information about source database logs in order to implement a log retention policy. For a specified instance of InfoSphere® CDC, you can display: - A list of all the logs that are required for the specified instance. - The earliest open transaction in the log for the specified instance. - The logs which contain the position confirmed by the target database for the specified instance. - The logs which contain the position the specified instance is reading from.
You must issue this command on your InfoSphere CDC source system.
Syntax dmshowlogdependency [-I
Parameters - -I
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. The command can also print as NULL if there are no tables defined in the subscription.
Examples dmshowlogdependency -I MYINSTANCE -i -s MYSUBSCRIPTIONNAMEDisplays the complete list of required source database logs for the specified instance and subscription. dmshowlogdependency -I MYINSTANCE -ADisplays the complete list of required source database logs for all subscriptions in the specified instance.
109 IBM InfoSphere Change Data Capture, Version 10.2 Exporting and importing configuration commands This section contains commands that allow you to export and/or import your InfoSphere® CDC global configuration. See also:
- dmexportconfiguration - Export InfoSphere CDC Configuration - dmimportconfiguration - Import InfoSphere CDC Configuration
110 IBM InfoSphere Change Data Capture, Version 10.2 dmexportconfiguration - Export InfoSphere CDC Configuration Use this command to export the configuration details of an installed instance of InfoSphere® CDC. Configuration details are sent to an XML configuration file. You can use the dmimportconfiguration command to import the XML file that you create with this command into another instance of InfoSphere CDC. Note: This command does not export subscription-specific settings that are configured in Management Console. Subscription-specific settings can be exported to an XML file in Management Console. Note: This command is interactive and will prompt you for your password. You cannot script this command.
Syntax dmexportconfiguration
Parameters -
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
Examples dmexportconfiguration c:\configuration.xmlInfoSphere CDC exports the XML file to the specified absolute path.
Related reference: dmimportconfiguration - Import InfoSphere CDC Configuration
111 IBM InfoSphere Change Data Capture, Version 10.2 dmimportconfiguration - Import InfoSphere CDC Configuration Use this command to import the InfoSphere® CDC configuration settings from an XML file which you created with the dmexportconfiguration command.
Syntax dmimportconfiguration
Parameters -
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
Examples dmimportconfiguration c:\configuration.xml InfoSphere CDC imports the XML configuration file from the specified absolute path.
Related reference: dmexportconfiguration - Export InfoSphere CDC Configuration
112 IBM InfoSphere Change Data Capture, Version 10.2 Managing tables for replication commands This section contains commands that help you manage the tables that you want to replicate with InfoSphere® CDC. See also:
- dmdescribe - Describe source tables - dmflagforrefresh - Flag for Refresh - dmmarktablecapturepoint - Mark a table capture point on a source table - dmpark - Park table - dmreaddtable - Update source table definition - dmreassigntable - Update target table definition - dmsetreplicationmethod - Set replication method
113 IBM InfoSphere Change Data Capture, Version 10.2 dmdescribe - Describe source tables Use this command to send source table metadata changes over to the target. This command exits after it has successfully described the specified subscriptions.
Syntax dmdescribe [-I
Parameters - -I
Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
Examples dmdescribe -I NEWINSTANCE -s FINANCEInfoSphere CDC sends source metadata changes in the Finance subscription over to the target for the specified instance.
114 IBM InfoSphere Change Data Capture, Version 10.2 dmflagforrefresh - Flag for Refresh Use this command to flag a source table for refresh. When you flag a table for refresh, you are selecting the tables that you want to refresh at a future point in time.
Syntax dmflagforrefresh [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmflagforrefresh -I MYINSTANCE -s FINANCE -AInfoSphere CDC flags for refresh all source tables in the Finance subscription for the specified instance. 115 IBM InfoSphere Change Data Capture, Version 10.2 dmmarktablecapturepoint - Mark a table capture point on a source table Use this command to mark a table capture point on a source table and change the status of the table to Active. If you changed the table before executing this command, those changes will not be replicated. Mark a table capture point on a source table when you want to override an existing position in the stream of changed data. This is possible when you have already synchronized (refreshed) your source and target tables using an application other than InfoSphere® CDC (for example, using the import or export capabilities of your database platform) and you know the point in time your source and target are synchronized with each other. InfoSphere CDC mirrors changes to the target table from the current position in the stream of changed data. This position is set by InfoSphere CDC when you select Mirror (Change Data Capture) after mapping your tables in the Map Tables wizard. If you want to override the position set by InfoSphere CDC, then you can manually mark a table capture point in Management Console. When you decide to start mirroring on the subscription, InfoSphere CDC identifies the position you have set as the point in time from which to capture and replicate database changes to the target. Syntax dmmarktablecapturepoint [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples 116 dmmarktablecapturepoint -I MYINSTANCE -s FINANCE -AInfoSphere CDC sets the status of all tables in the Finance subscription to Active. dmmarktablecapturepoint -I MYINSTANCE -s ACCOUNTING -t myschema.mytable InfoSphere CDC sets the status of the specified table in the Accounting subscription to Active. 117 IBM InfoSphere Change Data Capture, Version 10.2 dmpark - Park table Use this command to park a source table. By parking a source table, you tell InfoSphere® CDC that you do not want to capture changes for that particular table in a subscription. When you park a table, InfoSphere CDC does not replicate any subsequent changes you make on the source table, which may result in inconsistent source and target tables. Note: Before you can park a source table, if you are mirroring the table to the target, then you need to end replication on the subscription. For more information, see the dmendreplication command. Syntax dmpark [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmpark -I MYINSTANCE -s FINANCE -AInfoSphere CDC parks all source tables in the Finance subscription. 118 IBM InfoSphere Change Data Capture, Version 10.2 dmreaddtable - Update source table definition Use this command to update the definition of one or more source tables in the InfoSphere® CDC metadata. Run this command after you have changed the definition of a source table using your relational database. Notes: - This command will set the table status to Parked after updating the source table definition in the InfoSphere CDC metadata. - This command is not the equivalent of the Management Console Update Source Table Definition dialog, which you access by selecting Configuration > Subscriptions > Note: Syntax dmreaddtable [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmreaddtable -I NEWINSTANCE -AInfoSphere CDC updates definitions for all source tables that are available for replication. The status for all tables will be set to Parked. 119 IBM InfoSphere Change Data Capture, Version 10.2 dmreassigntable - Update target table definition Use this command to update the definition of a target table in InfoSphere® CDC metadata after you change the definition of the target table in your database. Syntax dmreassigntable [-I Parameters - -I Result This command returns a value of 0 if the operation was successful. If it fails, this command returns a non-zero value. Example dmreassigntable -I NEWINSTANCE -s FINANCE -AInfoSphere CDC updates definitions for all target tables in the Finance subscription. dmreassigntable -I CDCINSTANCE -s FINANCE -t SCHEMA1.SRCTBL1 InfoSphere CDC updates the definition for the target table that is mapped to the SCHEMA1.SRCTBL1 source table in the Finance subscription. 120 IBM InfoSphere Change Data Capture, Version 10.2 dmsetreplicationmethod - Set replication method Use this command to change the replication method for tables in a subscription. When running this command, InfoSphere® CDC changes the status of any Active tables to Refresh. Note: Before you run this command, you must end replication on the subscription. Syntax dmsetreplicationmethod [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmsetreplicationmethod -I MYINSTANCE -r -s FINANCE -AAll tables in the Finance subscription will use Refresh as the replication method in the specified InfoSphere CDC instance. dmsetreplicationmethod -I NEWINSTANCE -m -s FINANCE -t acct.taxcodesThe source table acct.taxcodes in the Finance subscription will use Mirror as the replication method in the specified InfoSphere CDC instance. 121 122 IBM InfoSphere Change Data Capture, Version 10.2 Monitoring replication commands This section contains commands that help you monitor replication in InfoSphere® CDC. See also: - dmclearevents - Clear events - dmgetsubscriptionstatus - Get subscription status - dmshowevents - Display InfoSphere CDC events 123 IBM InfoSphere Change Data Capture, Version 10.2 dmclearevents - Clear events Use this command to delete events from the Event Log view in Management Console. Syntax dmclearevents [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmclearevents -I MYINSTANCE -S -AInfoSphere CDC clears events from the source for all subscriptions for the specified instance. dmclearevents -I MYINSTANCE -B -s FINANCE MARKETINGInfoSphere CDC clears events from both the source and target for the Finance and Marketing subscriptions for the specified instance. 124 IBM InfoSphere Change Data Capture, Version 10.2 dmgetsubscriptionstatus - Get subscription status Issue this command on the InfoSphere® CDC source engine to retrieve status information for one or more subscriptions and send the results to standard output. Please note that this command can be issued on Linux, UNIX and Windows source replication engines only, not on target replication engines. Syntax dmgetsubscriptionstatus [-I Parameters - -I Result This command returns one of the following statuses for each subscription: - Recovering—The subscription is in an undetermined state. - Idle—The subscription is not running. - Starting—The subscription is in start up mode and is not currently replicating data. - Running—The subscription is running and replicating data. Examples dmgetsubscriptionstatus -I MYINSTANCE -p -AInfoSphere CDC retrieves status information for all subscriptions and sends the results to standard output for the specified instance. 125 IBM InfoSphere Change Data Capture, Version 10.2 dmshowevents - Display InfoSphere CDC events Use this command to display InfoSphere® CDC events to standard output. You can use this command as an alternative to showing InfoSphere CDC events in the Event Log view in Management Console. The output of this command shows events in chronological order with the most recent event shown first in the list. Syntax dmshowevents [-I Parameters - -I Result This command returns a value of 0 if the operation was successful. If it fails, this 126 command returns a non-zero value. Examples dmshowevents -I NEWINSTANCE -s FINANCEInfoSphere CDC displays all events for the Finance subscription for the specified instance. dmshowevents -I MYINSTANCE –a –hInfoSphere CDC displays all events for all subscriptions. A header is displayed before the list of events for the specified instance. dmshowevents -I NEWINSTANCE –s FINANCE MARKETING –t ATLANTA –h –c 20InfoSphere CDC displays the most recent 20 events for the Finance and Marketing subscriptions and for the Atlanta source ID. A header is displayed before the list of events for the specified instance. Sample output TIME|AGENTTYPE|SUBSCRIPTION|EVENTID|SEVERITY|EVENTPROGRAM|EVENTTEXT 2006-04-21 17:23:08.817|T|ATLANTA|95|Information|class com.datamirror.ts.target. publication.c|IBM InfoSphere Change Data Capture Communications ending. 2006-04-21 17:23:08.614|T|ATLANTA|1538|Information|class com.datamirror.ts.target. publication.c|---IBM InfoSphere Change Data Capture for ATLANTA terminating normally. 2006-04-21 17:23:08.333|T|ATLANTA|1537|Information|class com.datamirror.ts.target. publication.c|Describe conversation with ATLANTA completed successfully. 2006-04-21 17:23:07.911|T|ATLANTA|1536|Information|class com.datamirror.ts.target. publication.c|Describe conversation started by ATLANTA. 2006-04-21 17:23:07.333|T|ATLANTA|1531|Information|class com.datamirror.ts.target. publication.c|Communication with ATLANTA successfully started on Data channel. 2006-04-21 17:23:06.973|T|ATLANTA|1534|Information|class com.datamirror.ts.engine.a |Code page conversation from the source database's code page 1252 to the target database's code page Cp1252 for ATLANTA will be performed by the Remote system Fields in each record are separated by vertical bars ( | ). These fields are identified in the first line of the output. In the AGENTTYPE field, S indicates source and T indicates target. 127 IBM InfoSphere Change Data Capture, Version 10.2 Single scrape and staging store commands The InfoSphere® CDC staging store is located on your source server and is a cache of change data read from the database logs. The size of the staging store will increase as the product accumulates change data, and therefore you must plan your source environment accordingly, particularly disk space. See also: - dmclearstagingstore - Remove cached operations from the staging store - dmgetstagingstorestatus - Retrieve Staging Store status 128 IBM InfoSphere Change Data Capture, Version 10.2 dmclearstagingstore - Remove cached operations from the staging store Use this command to remove all the contents from the InfoSphere® CDC staging store on your source system. The staging store is used to provide a cache of change data that is read from the database logs. There may be times when the contents of the staging store are no longer valid and InfoSphere CDC will give instructions to clear the staging store with this command. Syntax dmclearstagingstore [-I Parameters - -I Result This command returns a value of 0 if the operation was successful. If it fails, this command returns a non-zero value. 129 IBM InfoSphere Change Data Capture, Version 10.2 dmgetstagingstorestatus - Retrieve Staging Store status Use this command to retrieve status information for the InfoSphere® CDC staging store on your source system and the Continuous Capture feature. Syntax dmgetstagingstorestatus [-I Parameters - -I Related reference: dmenablecontinuouscapture - Enable Continuous Capture dmdisablecontinuouscapture - Disable Continuous Capture 130 IBM InfoSphere Change Data Capture, Version 10.2 Other commands This section contains miscellaneous commands that allow you to determine the version of InfoSphere® CDC, verify communications, stop InfoSphere CDC, set system parameters, and back up your metadata. See also: - dmbackupmd - Back up metadata - dmconfigurets - Configure InfoSphere CDC - dmcreateclusterservice - Create cluster service - dmmarkexternalunloadend - End table data unload - dmmarkexternalunloadstart - Start table data unload - dmmdcommander - dmmdconsole - dmset - Set InfoSphere CDC system parameter - dmshowversion - Show InfoSphere CDC version - dmshutdown - Shut down InfoSphere CDC - dmsupportinfo - Collect IBM Support information - dmts32 - Start InfoSphere CDC - dmts64 - Start InfoSphere CDC 131 IBM InfoSphere Change Data Capture, Version 10.2 dmbackupmd - Back up metadata Use this command to create a backup of the InfoSphere® CDC metadata database which contains information about your current replication configuration. You should always back up your metadata when there are changes to your subscription configuration and table status. You can only back up your metadata while InfoSphere CDC is running. The backup of the metadata database is created in Syntax dmbackupmd [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. 132 IBM InfoSphere Change Data Capture, Version 10.2 dmconfigurets - Configure InfoSphere CDC Use this command to launch the InfoSphere® CDC configuration tool. You can use this tool to create instances and configure your installation of InfoSphere CDC. If the DISPLAY environment variable has been set, the configuration tool will attempt to launch the graphical user interface (GUI) version of the configuration tool when this command is issued. If you do not have the graphical libraries installed to view the GUI, you will need to ensure that the DISPLAY environment variable has been cleared in order to launch the command line version. Syntax dmconfigurets [-L Parameters - -L Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. 133 IBM InfoSphere Change Data Capture, Version 10.2 dmcreateclusterservice - Create cluster service Run this command when configuring InfoSphere® CDC to run in a Microsoft SQL Server clustered environment. Syntax dmcreateclusterservice [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmcreateclusterservice -I MYINSTANCE mypassivenode The instance name and passive node in the clustered environment are specified. Related concepts: Installing InfoSphere CDC for Microsoft SQL Server Related tasks: Adding an instance and configuring the Microsoft SQL Server cluster 134 dmmarkexternalunloadend - End table data unload Use this command when you want to perform a refresh outside of InfoSphere® CDC while the tables are still active. dmmarkexternalunloadend will mark the ending point of the data unload for the external tool that will be used to load the data to the target replication engine. Syntax dmmarkexternalunloadend [-I Parameters - [-I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmmarkexternalunloadend -I MYINSTANCE -t SCHEMA1.MYTABLEInfoSphere CDC marks the unload end point in the table named MYTABLE in the specified schema for the specified instance. 135 dmmarkexternalunloadstart - Start table data unload Use this command when you want to perform a refresh outside of InfoSphere® CDC while the tables are still active. dmmarkexternalunloadstart will mark the starting point of the data unload for the external tool that will be used to load the data to the target replication engine. Syntax dmmarkexternalunloadstart [-I Parameters - [-I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmmarkexternalunloadstart -I MYINSTANCE -t SCHEMA1.MYTABLEInfoSphere CDC marks the unload start point in the table named MYTABLE in the specified schema for the specified instance. 136 IBM InfoSphere Change Data Capture, Version 10.2 dmmdcommander This command is for internal use only. 137 IBM InfoSphere Change Data Capture, Version 10.2 dmmdconsole This command is for internal use only. 138 IBM InfoSphere Change Data Capture, Version 10.2 dmset - Set InfoSphere CDC system parameter Use this command to view or change InfoSphere® CDC system parameters. You can also change system parameters in Management Console. Note: You can set any system parameter using this command. However, it will only display system parameters that are set to non-default values. Syntax dmset [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmset -I MYINSTANCEDisplays all of the system parameters that are set to non- default values. dmset -I MYINSTANCE events_max_retain=20000Sets the events_max_retain system parameter to 20000. dmset -I MYINSTANCE events_max_retainDisplays the current value of the specified parameter. dmset -I MYINSTANCE stop_replication=Deletes the stop_replication system parameter. 139 IBM InfoSphere Change Data Capture, Version 10.2 dmshowversion - Show InfoSphere CDC version Use this command to display the InfoSphere® CDC version and build number. Run this command before you contact your IBM® representative. Syntax dmshowversion [-L Parameters - -L Result This command returns a value of 0 if the operation was successful. If it fails, this command returns a non-zero value. 140 IBM InfoSphere Change Data Capture, Version 10.2 dmshutdown - Shut down InfoSphere CDC Use this command to stop an instance of InfoSphere® CDC and end replication on all subscriptions that use the instance as a source. This command is often used prior to taking a server or database offline for maintenance purposes or upgrading InfoSphere CDC. Note: As a best practice before you run this command and to ensure that it completes successfully, use the dmendreplication command to end replication on all subscriptions that use the specified instance as a source and as a target. This command will not complete successfully if target subscriptions are still running. To end replication on subscriptions that use the specified instance as a target, you can use the –a parameter which will generate an error when forcefully ending replication on subscriptions that use the specified instance as the target. If this command does not end InfoSphere CDC processes and stop the specified instance, use the dmterminate command on the UNIX and Linux platforms to force a complete shut down and on Windows, to stop the service. Syntax dmshutdown [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. 142 143 IBM InfoSphere Change Data Capture, Version 10.2 dmsupportinfo - Collect IBM Support information Note: You should only run this command when the Management ConsoleSupport Assistant cannot connect to your InfoSphere® CDC datastore because it is not running or it will not run. Use this command (when requested by IBM® Technical Support) to collect InfoSphere CDC environment information in a generated .zip file that is used to diagnose and troubleshoot your support issue. Once the command has completed collecting information and generating the .zip file, the output will display the full path and name of the .zip file. If you run this command multiple times, the generated .zip files are numbered randomly. Note that you are responsible for deleting the generated .zip files when they are no longer required. Syntax dmsupportinfo [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Example dmsupportinfo -I PRODUCTION -t "2009-12-03 08:00:00 to 2009-12-03 12:00:00" Retrieves support information for the Production instance from 8:00 AM to 12:00 PM on December 3, 2009. This is the time range when you experienced support issues with this instance of InfoSphere CDC. Related concepts: Troubleshooting and contacting IBM Support 144 145 IBM InfoSphere Change Data Capture, Version 10.2 dmts32 - Start InfoSphere CDC Use this command to start a 32-bit instance of InfoSphere® CDC. Syntax dmts32 [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmts32 -I -MYINSTANCEInfoSphere CDC starts for the specified instance. 146 IBM InfoSphere Change Data Capture, Version 10.2 dmts64 - Start InfoSphere CDC Use this command to start a 64-bit instance of InfoSphere® CDC. Syntax dmts64 [-I Parameters - -I Result This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmts64 -I MYINSTANCEInfoSphere CDC starts for the specified instance. 147 IBM InfoSphere Change Data Capture, Version 10.2 User exits for InfoSphere CDC for Microsoft SQL Server A user exit lets you define a set of actions that InfoSphere® CDC can run before or after a database event occurs on a specified table. User exits allow you to customize your environment to meet your business requirements. After compiling the user exit, you can specify the user exit in Management Console. InfoSphere CDC provides two types of user exits: - Stored procedure—This type of user exit is run directly by the database engine and is generally faster at processing database requests. - Java class—This type of user exit utilizes the InfoSphere CDC API. For more information, see the API reference Javadocs. Sample Java™ class user exits are also provided with InfoSphere CDC. You can extend or modify these samples to suit your environment. In this section, you will learn: - Stored procedure user exits for table and row level operations - Sample Java class user exits for InfoSphere CDC for Microsoft SQL Server - InfoSphere CDC API reference – Javadocs 148 IBM InfoSphere Change Data Capture, Version 10.2 Stored procedure user exits for table and row level operations A stored procedure is a program (or procedure) which is physically stored within a database. The advantage of a stored procedure is that when it is run, in response to a user request, it is run directly by the database engine, which usually runs on a separate database server and is generally faster at processing database requests. After writing and compiling user exit programs, you can specify at which user exit point you want to invoke the user exit (either before or after a row-level or before or after a table-level operation) on the User Exits tab of InfoSphere® CDC. See also: - Defining a stored procedure user exit - Stored procedure user exit database connections - Retrieving data with a stored procedure user exit - Example of a stored procedure user exit 149 IBM InfoSphere Change Data Capture, Version 10.2 Defining a stored procedure user exit When defining a stored procedure user exit in InfoSphere® CDC, consider the following: - Overloaded stored procedures are not supported. - Stored procedure user exits must have at least two parameters, which must be the first two defined in the following order: - result—An integer output parameter that returns '0' if the stored procedure user exit is successful or a non-zero value if the stored procedure user exit is not successful. - returnMsg—A character output parameter that returns error messages to the Event Log if the stored procedure user exit is not successful. 150 IBM InfoSphere Change Data Capture, Version 10.2 Stored procedure user exit database connections The stored procedure user exit program and InfoSphere® CDC use the same shared connection as the default method to connect to the database. This setting ensures that, by default, changes to tables made by InfoSphere CDC are visible to the stored procedure user exit program. 151 IBM InfoSphere Change Data Capture, Version 10.2 Retrieving data with a stored procedure user exit You can retrieve data from your source table by passing system parameters to your stored procedure. You can retrieve the following type of data: - Retrieve system values (s$)—when passed to a stored procedure, the s$ prefix makes system values available from the source database to your stored procedure. For example, s$entry identifies the entry point at which InfoSphere® CDC had run the user exit. - Retrieve journal control fields (j$)—when passed to a stored procedure, the j$ prefix makes journal control fields available from the source database to your stored procedure. For example, j$USER identifies the operating system user name of the person that made the update on the source table. This is useful if you are using the stored procedure to audit table or row-level operations that have occurred on the source table. - Retrieve data values—depending on the prefix you pass to the stored procedure, you can retrieve data from the source database and make it available to your stored procedure. For example, you can use b$ to retrieve the before image of the source column, or you can use k$ to access the target table to find the rows that need to be modified. Each of these values can be used as input parameters for the stored procedure user exit that you write. The format used to retrieve data is slightly different depending on the product that you are using: - For InfoSphere CDC, the format is - Retrieving system values using the s$ prefix - Retrieving journal control fields using the j$ prefix - Retrieving data values using b$, a$, k$, and d$ prefixes 152 IBM InfoSphere Change Data Capture, Version 10.2 Retrieving system values using the s$ prefix This prefix is used to retrieve system values. The table below presents and briefly describes these values. Prefix and Value Data Type Description 153 s$entry NUMBER Represents the entry point from where the stored procedure was invoked. You can invoke a stored procedure from the following entry points: 1—indicates that InfoSphere® CDC has invoked the stored procedure before a table clear (truncate) operation2—indicates that InfoSphere CDC has invoked the stored procedure after a table clear (truncate) operation3—indicates that InfoSphere CDC has invoked the stored procedure before a row insert operation4—indicates that InfoSphere CDC has invoked the stored procedure after a row insert operation5—indicates that InfoSphere CDC has invoked the stored procedure before a row update operation6—indicates that InfoSphere CDC has invoked the stored procedure after a row update operation7—indicates that InfoSphere CDC has invoked the stored procedure before a row delete operation8—indicates that InfoSphere CDC has invoked the stored procedure after a row delete operation9—indicates that InfoSphere CDC has invoked the stored procedure before a table refresh 154 operation10—indicat es that InfoSphere CDC has invoked the stored procedure after a table refresh operation s$srcSysId VARCHAR Identifies uniquely the location of the source data. s$srcTabId VARCHAR Represents the name of the source table in the source database that sends replicated data to the target. s$tgtTabId VARCHAR Represents the name of the target table in the target database that receives replicated data from the source. 155 IBM InfoSphere Change Data Capture, Version 10.2 Retrieving journal control fields using the j$ prefix This prefix is used to retrieve information about the operation that occurred on the source system. You can use jb$ with InfoSphere® CDC to retrieve the same information. Note: If you are replicating data using InfoSphere Change Data Capture for DB2® for i on the source system, then the value for j$ and jb$ with ENTT and SEQN journal control fields will be different. jb$ENTT generates 'UB' to indicate that the before image of a row has been updated on the source table, and generates 'UP' to indicate that the after image of a row has been updated on the source table. Also, if you are using InfoSphere Change Data Capture for DB2 for i on the source system, then jb$SEQN generates an internal ID for the row within a transaction. The available values are listed: Prefix and Value Data Type Description j$CCID VARCHAR Identifies the transaction with the insert, update, or delete operation. j$CODE VARCHAR Identifies the type of journal or log entry, either “U” for a refresh operation or “R” for mirroring. The IBM® i platform will send “F” for file or table-level entries. j$CTRR or VARCHAR Identifies the relative j$CNTRRN record number of the source table that recorded the journal/log entry.Note: CTRR or CNTRRN contains meaningful information when you invoke your stored procedure on the insert entries that make up the refresh. The IBM i platform will also fill this in on any insert, update, or delete operation. j$ENTT or j$ENTTYP VARCHAR Generates journal or log codes that identify the operation type on the source system. 156 j$JRN or j$JOURNAL VARCHAR The name of the journal/log where InfoSphere CDC is reading insert, update, or delete operations from. j$JOB VARCHAR Identifies the name of the job that made the insert, update, or delete on the source system. j$MBR or j$MEMBER VARCHAR Identifies the name of the source table or its alias. j$NBR or j$JOBNO VARCHAR Identifies the process ID of the program on the source table that is making the insert, update, or delete operation. j$PGM or VARCHAR Identifies the name of j$PROGRAM the program on the source system that made the insert, update or delete operation. j$SEQN or j$SEQNO VARCHAR Identifies the sequence number of the insert, update, or delete operation in the journal or log. j$SYNM or VARCHAR Identifies the host j$SYSTEM name of the source system. j$USER VARCHAR Identifies the operating system user name that made the insert, update, or delete operation on the source. j$USPF VARCHAR Identifies the database user name that made the insert, update, or delete operation on the source. 157 j$TSTP or VARCHAR Identifies the date j$TIMSTAMP and time of when the insert, update, or delete operation or refresh was made on the source. In environments that support microsecond precision, the date and time format of this journal control field is YYYY-MM- DD- HH:MM:SS.UUUUUU . Otherwise, InfoSphere CDC sets the microsecond component UUUUUU to zeroes or does not include it at all. 158 IBM InfoSphere Change Data Capture, Version 10.2 Retrieving data values using b$, a$, k$, and d$ prefixes Four prefixes are used to retrieve data: Prefix Mode Description b$ 159 a$ 160 161 IBM InfoSphere Change Data Capture, Version 10.2 Example of a stored procedure user exit The following code snippet is an example of a stored procedure user exit. Code Comments create procedure PROD.AUDIT_STPROC The parameters you declare and want to ( @result INT OUTPUT, @returnMsg VARCHAR(255) pass to your stored procedure must be OUTPUT, @s$entry INT, valid data types. @s$srcSysId VARCHAR, @s$srcTabId VARCHAR, The following parameters are mandatory @s$tgtTabId VARCHAR, @j$ENTT CHAR(2) @a$IDNO and must be declared in your stored INT, @a$PRICE DECIMAL(10,2), @a$DESC VARCHAR, procedure: @a$LONGDESC VARCHAR, @result—Returns a value of '0' if the @a$TRANSDATE DATETIME, @d$IDNO INT, @d$PRICE stored procedure user exit is successful. DECIMAL(10,2), @d$DESC VARCHAR, @d$LONGDESC If the stored procedure user exit is not VARCHAR, @d$TRANSDATE DATETIME ) successful it will return a non-zero value and a message will be sent to the Event Log.@returnMsg—Returns an error message to the Event Log if the stored procedure is not successful.The following parameters have been declared in this stored procedure: @s$entry—Retrieves the entry point at which the stored procedure was called. In this example, InfoSphere® CDC calls the user exit at every entry point.@s$srcSysId—Retrieves the location of source data.@s$srcTabId—Retrieves the name of the source table.@s$tgtTabId—Retrieves the name of the target table.@j$ENTT—Retrieves the journal code that indicates the type of operation on the source table.@a$—Retrieves the after image of the IDNO, PRICE, DESC, LONGDESC, and TRANSDATE source columns.@d$—Retrieves the transformed data of the IDNO, PRICE, DESC, LONGDESC, and TRANSDATA target columns. AS declare @ENTRYPOINT VARCHAR(50); This stored procedure user exit can be BEGIN invoked from these entry points. select @ENTRYPOINT = case @s$entry WHEN 3 THEN 'User Exit program called Before Insert' WHEN 4 THEN 'User Exit program called After Insert' WHEN 5 THEN 'User Exit program called Before Update' WHEN 6 THEN 'User Exit program called After Update' END 162 insert into PROD.AUDIT_TABLE1 values ( This stored procedure user exit will @s$entry, @s$srcSysId, @s$srcTabId, INSERT these values into @s$tgtTabId, PROD.AUDIT_TABLE1. @j$ENTT, @a$IDNO, @a$PRICE, @a$DESC, @a$LONGDESC, @a$TRANSDATE, @d$IDNO, @d$PRICE, @d$DESC, @d$LONGDESC, @d$TRANSDATE, @ENTRYPOINT) set @result = 0 set @returnMsg = 'OK' This stored procedure user exit is END successful and returns a '0' value. Note: If your stored procedure returns a non-zero value because the stored procedure is not successful, then an error message is sent to the Event Log. 163 IBM InfoSphere Change Data Capture, Version 10.2 Sample Java class user exits for InfoSphere CDC for Microsoft SQL Server InfoSphere® CDC provides sample user exits that you can extend or modify to suit your environment. The samples are found in samples.jar, which is located in the samples directory in your InfoSphere CDC installation directory. The Java™ file contains the following samples: - CRUserExitSample.java—A conflict resolution user exit that can be used with tables having a primary key column of any data type or a numeric column with any data type. This sample is located in com.datamirror.ts.target.publication.userexit.cdr. - DEUserExitSample.java—Used in expressions using the %USERFUNC column function. It calculates the sum of the user-supplied parameters (in the expression) and returns the sum incremented by 1. This sample is located in com.datamirror.ts.derivedexpressionmanager. - SPUserExitSample.java—Calls a stored procedure with the image coming from the source. This sample is located in com.datamirror.ts.target.publication.userexit.sample. - UserExitSample.java—Subscribes to replication events to retrieve the details of the events which took place. This sample is located in com.datamirror.ts.target.publication.userexit.sample. - UserExitSample1.java—Records new rows inserted into a table on the target and stores them in a text file. The user specifies the name of the text file as a parameter. This sample is located in com.datamirror.ts.target.publication.userexit.sample. Note the following: - To run the sample user exits without modifying them, you must specify the fully qualified path to the compiled user exit in Management Console. For example, com.datamirror.ts.target.publication.userexit.sample.UserExitSample. - Compiled sample user exits are located in the ts.jar file which is found in the lib directory in your InfoSphere CDC installation directory. Note that the compiled user exits in the ts.jar file have a *.class extension. - If you want to modify the sample user exits, you must compile the user exit after you make changes to the source code. - The user exit class must also be in the InfoSphere CDC runtime classpath. For more information on how to specify Java class or Stored Procedure user exits in Management Console, see your Management Console documentation. See also: - To compile the sample Java class user exits (Windows) 164 IBM InfoSphere Change Data Capture, Version 10.2 To compile the sample Java class user exits (Windows) 1. Stop InfoSphere® CDC. 2. Unzip the samples.jar file into the lib folder in your InfoSphere CDC installation folder. Make sure you maintain the folder structure when unzipping the jar file. After unzipping the jar file, you will have a folder structure like the following: 3. Make your changes to the sample user exit. 4. Compile the modified user exit. For example, if you want to compile UserExitSample.java, open a command window, navigate to the lib folder and issue the following command:javac -classpath ts.jar;. com\datamirror\ts\target\publication\userexit\sample \UserExitSample.java If this command runs successfully, there will be no output on your screen. Note: Your system must have the Java™ JDK to run this command. 5. After running the command successfully, navigate to the following directory and confirm that you have created a UserExitSample.class file: 165 IBM InfoSphere Change Data Capture, Version 10.2 InfoSphere CDC API reference – Javadocs The API reference is available in Javadoc format in your InfoSphere® CDC installation directory. To view the API reference, navigate to the api directory below and click the index.html file to open the Javadoc documentation in your browser: - Windows— 166 IBM InfoSphere Change Data Capture, Version 10.2 Conflict resolution audit table When InfoSphere® CDC resolves a conflict between the source and target tables, it records information about the resolution in the TS_CONFAUD table. InfoSphere CDC creates this table in the target metadata location that is specified during the configuration of InfoSphere CDC. Note:InfoSphere CDC will add data continuously to the audit table as conflicts occur, but will never purge data from the table. Depending on the number of conflicts, the audit table will to grow in size over time. It is the user's responsibility to schedule maintenance (such as using a DELETE FROM statement) on the conflict resolution audit table regularly. A good practice would be to remove the applicable information from the audit table after you have resolved each conflict. In this section, you will learn: - Structure of the conflict resolution audit table - Row image format - Truncated images - Unaudited data types 167 IBM InfoSphere Change Data Capture, Version 10.2 Structure of the conflict resolution audit table You can use the TS_CONFAUD table to track how conflict resolution affects your target table. For example, you can query the AFTERIMG column to see when a change was made to the target table. Then you can review the contents of the BEFOREIMG and AFTERIMG columns to see the change on the source table that resulted in the data on the target table. This can help in identifying issues in your conflict resolution strategy. Conflict detection and resolution is configured in Management Console. The structure of the TS_CONFAUD table is as follows: Column Description CNFTIME The date and time on the target when the conflict was detected. SRCTIME The time the conflicting data was applied to the source table. SRCSYSID The source ID of the subscription. SRCSCHEMA The schema or library name for the source table. SRCNAME The name of the source table. SRCMEMBER This field is blank. TGTSCHEMA The schema or library for the target table. TGTNAME The name of the target table. TGTMEMBER This column is only used for the IBM® i platform. OPTYPE The row-level operation on the source that caused the conflict. The value is one of: 1—Inserted into the source table.2—Updated on the source table.3—Deleted from the source table. CNFTYPE The type of conflict that was detected. The value is one of: 1—Inserted into the source table. The key for that row already exists in the target table.2—Updated or deleted on the source table. The key for that row does not exist in the target table.3—Updated or deleted on the source table. The images of the source and target tables do not match.4—Unexpected conflict was detected. 168 RESMTD The conflict resolution method that was used. The value is one of: 1—Source wins2—Target wins3—Largest value wins4—Smallest value wins5—User exitIf the resolution method was None, then a row will not be entered into this table. See your InfoSphere® CDC documentation for more information on these methods. CNFRES Indicates if the conflict was resolved. The value is one of: Y—Conflict was resolved.N—Conflict was not resolved. BEFORETRNC Indicates if the before image stored in BEFOREIMG was truncated. The value is one of: Y—Value was truncated.N—Value was not truncated. BEFOREIMG A representation of the row in the source table after it was changed. See Row Image Format for more information on the format of this column. AFTERTRNC Indicates if the after image stored in AFTERIMG was truncated. The value is one of: Y—Value was truncated.N—Value was not truncated. AFTERIMG A representation of the row in the source table after it was changed. See Row Image Format for more information on the format of this column. TGTIMG A representation of the row in the target table before replication occurred. See Row Image Format for more information on the format of this column. TGTTRNC Indicates if the after image stored in TGTIMG was truncated. The value is one of: Y—Value was truncated.N—Value was not truncated. WINIMG A representation of the final row in the target table after conflict resolution has occurred. See Row Image Format for more information on the format of this column. WINTRNC Indicates if the image stored in WINIMG was truncated. The value is one of: Y—Value was truncated.N—Value was not truncated. 169 Related concepts: Row image format 170 IBM InfoSphere Change Data Capture, Version 10.2 Row image format The BEFOREIMG, AFTERIMG, TGTIMG, and WINIMG columns in the audit table show representations of a row in either the source or target table. The images in these columns are limited by the maximum length of VARCHAR data on your target metadata database. The images contain all of the values in the row, except for data in raw, binary, or LOB columns. The data from each column is presented in the following format:(length:value) In the format above, value is the data in the column and length is the number of characters used to represent the data. The images display numeric data as character strings and NULL values as (null). The row images match the column order in the source table and the conflict resolution audit table. These images may be truncated if the image is longer than the maximum length of VARCHAR data in the target metadata database. If a table's key column is not the first column in the table, then it may be truncated. 171 IBM InfoSphere Change Data Capture, Version 10.2 Truncated images If a row image is longer than the maximum length of a VARCHAR column, then they will be truncated. There is a column in the audit table that indicates if each image column has been truncated. For example, if WINTRNC is Y, then the value of WINIMG was truncated. The format of the truncated column is:(-length:value) In the format above, value is the truncated value and length is the number of characters in the truncated string. 172 IBM InfoSphere Change Data Capture, Version 10.2 Unaudited data types The audit table does not include columns of the following data types in its images: - IMAGE - NTEXT - TEXT If the source or target table contains rows with these data types, then the image simply overlooks them. Binary data will appear in the images as hex-encoded characters. The image does not store any information from unsupported columns. 173 IBM InfoSphere Change Data Capture, Version 10.2 Uninstalling InfoSphere CDC for Microsoft SQL Server This section provides step-by-step instructions on how to uninstall InfoSphere® CDC. In this section, you will learn: - To uninstall InfoSphere CDC for Microsoft SQL Server (Windows) 174 IBM InfoSphere Change Data Capture, Version 10.2 To uninstall InfoSphere CDC for Microsoft SQL Server (Windows) 1. Go to Windows Control Panel > Add or Remove Programs. 2. Locate IBM®InfoSphere® Change Data Capture and click Change/Remove. 3. Click Uninstall on the uninstall wizard. This deletes your all your InfoSphere CDC instances under this installation. 4. Click Done after the uninstallation has completed. 175 IBM InfoSphere Change Data Capture, Version 10.2 Troubleshooting If you encounter issues while running InfoSphere® CDC, you have a number of options for tracking and troubleshooting issues to help with problem resolution. There are three methods that you can use in InfoSphere CDC for tracking and troubleshooting issues: - Data Collection with the IBM® Support Assistant (ISA DC) - Management Console Support Assistant - The dmsupportinfo command, which is executed on the replication engine If you are trying to troubleshoot issues with InfoSphere CDC version 10.2 or later on Linux, UNIX and Windows operating systems, you should use the ISA DC tool unless otherwise instructed by IBM Technical Support. In this section, you will learn: - Using the IBM Support Assistant (ISA DC) - Locating log files In addition to the Management Console event log, InfoSphere CDC produces other logs to help troubleshoot installation and replication errors. - Troubleshooting and contacting IBM Support 176 IBM InfoSphere Change Data Capture, Version 10.2 Using the IBM Support Assistant (ISA DC) You can use the IBM® Support Assistant Data Collection tool (ISA DC) to collect InfoSphere® CDC data to provide to IBM Technical Support to assist you in troubleshooting issues with InfoSphere CDC, to request a product enhancement or to ask a question about InfoSphere CDC. ISA DC can be used with InfoSphere CDC replication engines that are version 10.2 or later, except InfoSphere CDC for z/OS®. The ISA DC tool is included in the InfoSphere CDC installation process, and does not require configuration. The executable files are located in the isa folder in the InfoSphere CDC directory. Simply run the isadc.bat, isadc.sh or index.html file, as appropriate, to launch the tool. Prerequisites and considerations for using ISA DC Prerequisites: The following prerequisite must be satisfied on the machine on which ISA DC will be run, in order to successfully use the tool: - IBM JRE/JDK version 1.6 or later Considerations: The following issues should be taken into consideration before you attempt to use ISA DC: - ISA DC cannot be run remotely. It must be run on the machine where the instance is configured. - ISA DC cannot be used to collect data from InfoSphere CDC for z/OS. - If InfoSphere CDC is installed but you have not configured an instance or are unable to configure an instance, ISA DC can still be used to collect minimal data to assist IBM Technical Support in resolving the issue. See also: - To use ISA DC to collect data for a product problem (command line) - To use ISA DC to collect data for a product problem (GUI) - To use ISA DC to collect data for a question or an enhancement request (command line) - To use ISA DC to collect data for a question or an enhancement request (GUI) 177 IBM InfoSphere Change Data Capture, Version 10.2 To use ISA DC to collect data for a product problem (command line) 1. Launch the IBM® Support Assistant.Run the isadc.bat or isadc.sh file, located in the isa\isadc folder in the root directory of the InfoSphere® CDC instance. 2. Enter 1 to accept the license agreement and press Enter.After the license agreement has been accepted, it will not be shown again. 3. Provide a file name and press Enter.The name provided will be given to the .zip file containing the data collection results. If you do not want to assign a name to the data collection results, press Enter and a default name will be used. 4. Enter 1 to confirm your chosen file name and press Enter to continue. 5. Enter 1 to run the InfoSphere Change Data CaptureSupport Assistant Data Collector and press Enter.The Welcome page is displayed. 6. Read the Welcome page information and enter 1 to proceed. Press Enter. 7. Enter 1 to collect data for a product problem and press Enter. 8. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 9. Select the name of the InfoSphere CDC instance for which data will be collected. If you have multiple instances of InfoSphere CDC configured, you will be asked to select which instance for which you want to collect. Enter the corresponding number for the instance name and press Enter. If you have a single InfoSphere CDC instance configured, it will be selected automatically and this step will be skipped. Even if you do not have an instance configured, ISA DC will still collect what data is available. If no instance is configured, you can skip to Step 14. 10. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 11. If your selected instance is not running, you will be alerted by ISA DC. As only minimal data is available if the instance is stopped, it is preferable that the instance be running during data collection.Try to start your instance. When the instance is running, enter 1 and press Enter. If you cannot start your instance and want to continue the data collection process, enter 2 and press Enter. 12. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 13. If the instance is running, you will be asked for information regarding when the problem occurred. A. Enter the date and time when you think the problem began and press Enter. This information must be entered in the following format: yyyy-mm-dd hh:mm:ss 178 B. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. C. Determine the period of time for which the data will be collected and press Enter.The amount specified will be applied as a before value and an after value to the date and time specified previously. For example, if you select 1 Day as the time period, data will be collect for 24 hours before the specified date and time and for the 24 hours after the specified date and time. D. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 14. Select the method to transfer the data collection archive file and press Enter. Choose one of the following options: - Send using secure transfer to IBM Support (HTTPS)—Sends the .zip file to IBM Support using a secure protocol. - Send using FTP to IBM Support (unencrypted)—Sends the .zip file to IBM Support using an unencrypted protocol. - Send using FTP to another location (unencrypted)—Sends the .zip file to a recipient of your choice, using an unencrypted protocol. - End the collection without sending—Ends the data collection and creates the .zip file, but does not transfer it. 15. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 16. If you chose to end the collection without sending the output, ISA DC will notify your when the .zip file has been successfully created. Enter 1 and press Enter to exit the application. 17. If you chose to transfer the file using HTTPS, follow these steps: A. If you want to receive a confirmation email when the upload was successful, enter an email address and press Enter. If you do not want to receive confirmation, press Enter to continue. B. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. C. Enter the PMR number that was given to you by IBM Technical Support and press Enter. Ensure that the PMR number follows the required naming convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is entered, you will be asked to correct the PMR number and re-send the data. D. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 179 18. If you chose to transfer the file to IBM Technical Support using unencrypted FTP, follow these steps: A. Enter the PMR number that was given to you by IBM Technical Support and press Enter. Ensure that the PMR number follows the required naming convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is entered, you will be asked to correct the PMR number and re-send the data. B. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 19. If you chose to transfer the file using unencrypted FTP, follow these steps: A. Enter the FTP host name and press Enter. B. Enter the user name and press Enter. C. Enter the password for the user name and press Enter. D. Enter the path for the directory on the FTP server and press Enter. E. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 20. When you receive notice that the operation has completed successfully, enter 1 and press Enter to exit the application. 180 IBM InfoSphere Change Data Capture, Version 10.2 To use ISA DC to collect data for a product problem (GUI) 1. Launch the IBM® Support Assistant.Run the index.html file, located in the isa\isadc folder in the root directory of the InfoSphere® CDC instance. 2. Read the license agreement and click OK to accept it.After the license agreement has been accepted, it will not be shown again. 3. Click Start.The Welcome screen opens. 4. Click OK. 5. Select A product problem from the drop down box. 6. Click OK. 7. Select the name of an InfoSphere CDC instance from the drop down list and click OK.If you have multiple instances of InfoSphere CDC configured, you will be asked to select which instance for which you want to collect. If you have a single InfoSphere CDC instance configured, it will be selected automatically and this step will be skipped. 8. If your selected instance is not running, you will be alerted by ISA DC. As only minimal data is available if the instance is stopped, it is preferable that the instance be running during data collection.Try to start your instance. When the instance is running, select Yes, I have started the instance from the drop down box and click OK. If you cannot start your instance and want to continue the data collection process, select No, continue with minimal data collection from the drop down box and click OK. 9. If the instance is running, you will be asked for information regarding when the problem occurred. Enter the date and time when you think the problem began and click OK.This information must be entered in the following format: yyyy-mm- dd hh:mm:ss. 10. Determine the period of time for which the data will be collected and click OK. Choose one of the following values: - 6 hours - 12 hours - 1 Day - 2 Days - 7 Days The amount specified will be applied as a before value and an after value to the date and time specified previously. For example, if you select 1 Day as the time period, data will be collect for 24 hours before the specified date and time and for the 24 hours after the specified date and time. 11. If you chose to end the collection without sending the output, select Do not transfer data to IBM. ISA DC will notify you when the .zip file has been successfully created. 12. If you want to transfer the data to IBM using a secure transfer (HTTPS), select the Transfer to IBM option. A. Choose the HTTPS transfer type option. B. Enter the PMR number that was given to you by IBM Technical Support. Ensure that the PMR number follows the required naming convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is 181 entered, you will be asked to correct the PMR number and re-send the data. C. Enter your email address. D. Click Transfer. 13. If you want to transfer the data to IBM using unencrypted FTP, select the Transfer to IBM option. A. Choose the FTP transfer type option. B. Enter the PMR number that was given to you by IBM Technical Support. Ensure that the PMR number follows the required naming convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is entered, you will be asked to correct the PMR number and re-send the data. C. Click Transfer. 14. If you choose to send the data to a location other than IBM using unencrypted FTP, click Transfer to another server via FTP A. Enter the email address or IP address of the recipient in the Hotmail/IP Address field. B. Enter the user name. C. Enter the password. D. Enter the path for the directory on the FTP server. E. Click Transfer. 15. When you receive notice that the operation has completed successfully, click Browse directory if you want to see the file you created or click Start New Collection to collect more data.To exit the application, close your browser tab or window. 182 IBM InfoSphere Change Data Capture, Version 10.2 To use ISA DC to collect data for a question or an enhancement request (command line) 1. Launch the IBM® Support Assistant.Run the isadc.bat or isadc.sh file, located in the isa\isadc folder in the root directory of the InfoSphere® CDC instance. 2. Enter 1 to accept the license agreement and press Enter.After the license agreement has been accepted, it will not be shown again. 3. Provide a file name and press Enter.The name provided will be given to the .zip file containing the data collection results. If you do not want to assign a name to the data collection results, press Enter and a default name will be used. 4. Enter 1 to confirm your chosen file name and press Enter to continue. 5. Enter 1 to run the InfoSphere Change Data CaptureSupport Assistant Data Collector and press Enter.The Welcome page is displayed. 6. Read the Welcome page information and enter 1 to proceed. Press Enter. 7. Enter 2 to collect data for a question or an enhancement request and press Enter. 8. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 9. Select the method to transfer the data collection archive file and press Enter. Choose one of the following options: - Send using secure transfer to IBM Support (HTTPS)—Sends the .zip file to IBM Support using a secure protocol. - Send using FTP to IBM Support (unencrypted)—Sends the .zip file to IBM Support using an unencrypted protocol. - Send using FTP to another location (unencrypted)—Sends the .zip file to a recipient of your choice, using an unencrypted protocol. - End the collection without sending—Ends the data collection and creates the .zip file, but does not transfer it. 10. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 11. If you chose to end the collection without sending the output, ISA DC will notify your when the .zip file has been successfully created. Enter 1 and press Enter to exit the application. 12. If you chose to transfer the file using HTTPS, follow these steps: A. If you want to receive a confirmation email when the upload was successful, enter an email address and press Enter. If you do not want to receive confirmation, press Enter to continue. B. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. C. Enter the PMR number that was given to you by IBM Technical Support and press Enter. Ensure that the PMR number follows the required naming 183 convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is entered, you will be asked to correct the PMR number and re-send the data. D. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 13. If you chose to transfer the file to IBM Technical Support using unencrypted FTP, follow these steps: A. Enter the PMR number that was given to you by IBM Technical Support and press Enter. Ensure that the PMR number follows the required naming convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is entered, you will be asked to correct the PMR number and re-send the data. B. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 14. If you chose to transfer the file using unencrypted FTP, follow these steps: A. Enter the FTP host name and press Enter. B. Enter the user name and press Enter. C. Enter the password for the user name and press Enter. D. Enter the path for the directory on the FTP server and press Enter. E. Enter 1 to process your input and continue collecting data. Press Enter.If you want to cancel the collection, enter 2 and press Enter. If you want to go back and change your input for the previous step, enter 3 and press Enter. 15. When you receive notice that the operation has completed successfully, enter 1 and press Enter to exit the application. 184 IBM InfoSphere Change Data Capture, Version 10.2 To use ISA DC to collect data for a question or an enhancement request (GUI) 1. Launch the IBM® Support Assistant.Run the index.html file, located in the isa\isadc folder in the root directory of the InfoSphere® CDC instance. 2. Read the license agreement and click OK to accept it.After the license agreement has been accepted, it will not be shown again. 3. Click Start.The Welcome screen opens. 4. Click OK. 5. Select A question or enhancement request from the drop down box. 6. Click OK. 7. If you chose to end the collection without sending the output, select Do not transfer data to IBM. ISA DC will notify you when the .zip file has been successfully created. 8. If you want to transfer the data to IBM using a secure transfer (HTTPS), select the Transfer to IBM option. A. Choose the HTTPS transfer type option. B. Enter the PMR number that was given to you by IBM Technical Support. Ensure that the PMR number follows the required naming convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is entered, you will be asked to correct the PMR number and re-send the data. C. Enter your email address. D. Click Transfer. 9. If you want to transfer the data to IBM using unencrypted FTP, select the Transfer to IBM option. A. Choose the FTP transfer type option. B. Enter the PMR number that was given to you by IBM Technical Support. Ensure that the PMR number follows the required naming convention of PMRNumber.BranchNumber.CountryCode. If an unknown PMR number is entered, you will be asked to correct the PMR number and re-send the data. C. Click Transfer. 10. If you choose to send the data to a location other than IBM using unencrypted FTP, click Transfer to another server via FTP A. Enter the email address or IP address of the recipient in the Hotmail/IP Address field. B. Enter the user name. C. Enter the password. D. Enter the path for the directory on the FTP server. E. Click Transfer. 11. When you receive notice that the operation has completed successfully, click Browse directory if you want to see the file you created or click Start New Collection to collect more data.To exit the application, close your browser tab or window. 185 IBM InfoSphere Change Data Capture, Version 10.2 Locating log files In addition to the Management Console event log, InfoSphere® CDC produces other logs to help troubleshoot installation and replication errors. Review the log files in the 186 IBM InfoSphere Change Data Capture, Version 10.2 Troubleshooting and contacting IBM Support The following support page contains the latest troubleshooting information and details on how to open a service request with IBM® Support: - http://www.ibm.com/software/data/infosphere/support/change-data-capture/ For contact information in your region: - http://www.ibm.com/planetwide/ Related reference: dmsupportinfo - Collect IBM Support information 187 ...> [-L
- Specifies the name of a source table in the subscription that InfoSphere CDC flags for refresh. You must specify the table name in the format schema.table. To specify multiple tables, list the tables separated by a space. - -L
...> [-L
- Specifies the name of a source table in the subscription on which InfoSphere CDC marks a table capture point. You must specify the table name in the format schema.table. To specify multiple tables, list the tables separated by a space. - -L
...> [-L
- Specifies the name of a source table in the subscription that InfoSphere CDC parks. You must specify the table name in the format schema.table. To specify multiple tables, list the tables separated by a space. - -L
...> [-L
- Specifies the name of a source table in the subscription for which InfoSphere CDC updates the definition. You must specify the table name in the format schema.table. To specify multiple tables, list the tables separated by a space. - -L
...> [-L
- Specifies the name of a source table in the subscription that is mapped to the target table for which InfoSphere CDC updates the table definition in the metadata. You must specify the table name in the format schema.table. To specify multiple tables, list the tables separated by a space. - -L
...> [-L
- Specifies the name of a source table in the subscription that will use the indicated replication method. You must specify the table name in the format schema.table. To specify multiple tables, list the tables separated by a space. - -L
]
] - Specifies the name of a source table in the subscription on which InfoSphere CDC marks a table capture point. The tables must be named in the format
. To specify multiple tables, list the tables separated by a space. - To mark the table capture point on all the source tables in the specified subscription, omit this parameter.
]
] - Specifies the name of a source table in the subscription on which InfoSphere CDC marks a table capture point. The table must be named in the format
. To specify multiple tables, list the tables separated by a space. - To mark the table capture point on all the source tables in the specified subscription, omit this parameter.