IBM InfoSphere Change Data Capture Version 6.5.2
InfoSphere Change Data Capture for Oracle databases, Version 6.5.2 End-User Documentation
IBM InfoSphere Change Data Capture Version 6.5.2
InfoSphere Change Data Capture for Oracle databases, Version 6.5.2 End-User Documentation
Note Before using this information and the product it supports, read the information in “Notices” on page 119.
First edition, third revision This edition applies to version 6, release 5, modification 2 of IBM InfoSphere Change Data Capture (product number 5724-U70) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 2008, 2011. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents
About InfoSphere CDC and InfoSphere Preparing for a failover of InfoSphere CDC....32 CDC Management Console ...... 1 Capturing change data with single scrape ....3 Installing InfoSphere CDC ...... 35 To install InfoSphere CDC (UNIX and Linux) . . . 35 What’s new ...... 5 To override the locale for the installation (UNIX and Linux) ...... 36 System requirements ...... 7 Installing InfoSphere CDC using a silent installation 36 To perform a silent installation of InfoSphere Supported operating systems and processors . . . 7 CDC (UNIX and Linux) ...... 36 Supported databases...... 8 Disk space requirements ...... 9 Upgrading Transformation Server for RAM requirements ...... 10 Tablespace requirements ...... 11 Oracle to InfoSphere CDC for Oracle Port requirements ...... 11 databases ...... 39 To upgrade from Transformation Server for Oracle Before you install ...... 13 to InfoSphere CDC for Oracle databases .....39 Required database, user accounts, and schemas . . 13 Assessing disk space and memory requirements . . 14 Configuring InfoSphere CDC (UNIX and Allocating sufficient disk space for database log files 15 Linux) ...... 41 Sizing considerations for the staging store ....16 Configuring InfoSphere CDC instances (UNIX and Enabling supplemental logging ...... 17 Linux) ...... 41 Enabling InfoSphere CDC to use a bulk load refresh 18 To add a new instance of InfoSphere CDC for Setting the database instance to ARCHIVELOG Oracle databases (UNIX and Linux) .....41 mode ...... 19 To edit an instance of InfoSphere CDC (UNIX InfoSphere CDC and Automatic Storage and Linux) ...... 43 Management (ASM) ...... 19 To delete an instance of InfoSphere CDC (UNIX Starting the Oracle listener ...... 19 and Linux) ...... 44 Setting up a remote connection ...... 19 To setup a remote connection ...... 20 Configuring InfoSphere CDC for Oracle Understanding Index Organized Tables (IOT) databases for log shipping ...... 45 support...... 20 Replicating DDL changes ...... 21 To configure InfoSphere CDC for log shipping. . . 45 Calculating database connections required by To ship logs using custom scripts ...... 46 InfoSphere CDC ...... 21 To ship logs using Oracle's Data Guard .....46 Clustered tables ...... 23 Interval partitions ...... 23 After you install and configure ....49 Replicating XA transactions ...... 23 Granting required privileges to Oracle users using SQL scripts in /samples directory ...... 49 Understanding InfoSphere CDC in an Privileges for Oracle users ...... 49 Oracle Real Application Clusters (RAC) Starting InfoSphere CDC ...... 53 To start InfoSphere CDC (UNIX and Linux) . . 53 environment ...... 25 Stopping InfoSphere CDC ...... 53 Configuring InfoSphere CDC in a RAC environment 26 To stop InfoSphere CDC (UNIX and Linux). . . 53 Configuring tnsnames.ora for InfoSphere CDC in a Maintaining active TCP connections in a network RAC environment ...... 28 environment ...... 54 Oracle ASM considerations ...... 28 To maintain active TCP connections .....54 Creating an InfoSphere CDC failover script for a Enabling SQL statements in Management Console 55 RAC environment ...... 29 To enable SQL statements in Management NFS lockd utility considerations ...... 30 Console...... 55
Configuring InfoSphere CDC for OS Metadata tables ...... 57 (operating system) clustering (UNIX and Linux) ...... 31 Data types supported by InfoSphere Performing a forced or manual failover of CDC...... 59 InfoSphere CDC ...... 32
© Copyright IBM Corp. 2008, 2011 iii Commands for InfoSphere CDC ....61 dmsetreplicationmethod - Set replication method 89 Using the InfoSphere CDC commands .....61 Monitoring replication commands ...... 90 Setting the TSINSTANCE environment variable . . 62 dmclearevents - Clear events ...... 90 Continuous Capture commands ...... 62 dmgetsubscriptionstatus - Get subscription status 91 dmdisablecontinuouscapture - Disable dmshowevents - Display InfoSphere CDC events 92 Continuous Capture ...... 63 Other commands ...... 94 dmenablecontinuouscapture - Enable Continuous dmbackupmd - Backup Metadata ...... 94 Capture ...... 63 dmconfigurets - Configure InfoSphere CDC . . 95 Controlling replication commands ...... 63 dmmdcommander ...... 95 dmendreplication - End replication .....64 dmmdconsole ...... 95 dmrefresh - Refresh subscription ...... 67 dmset - Set InfoSphere CDC system parameter 95 dmstartmirror - Start mirroring ...... 68 dmshowversion - Show InfoSphere CDC version 96 Database transaction log commands ...... 71 dmshutdown - Shut down InfoSphere CDC . . 96 dmarchivelogavailable - Mark archive log as dmsupportinfo - Collect IBM Support available ...... 71 information ...... 99 dmarchivelogremoved - Mark archive log as dmterminate - Terminate InfoSphere CDC removed ...... 72 processes ...... 100 dmdecodebookmark - Display verbose dmts32 - Start InfoSphere CDC ...... 100 information bookmark...... 73 dmts64 - Start InfoSphere CDC ...... 101 dmsetbookmark - Set bookmark ...... 74 dmverifycommunications ...... 101 dmshowbookmark - Display bookmark information ...... 75 User exits for InfoSphere CDC ....103 dmshowlogdependency - Show Log Dependency 78 Stored procedure user exits for table and row level Supplemental logging commands ...... 80 operations ...... 103 dmshowsupplementalloggingdependency - Show Defining a stored procedure user exit ....103 supplemental logging dependency...... 80 Stored procedure user exit database connections 104 dmreducesupplementalloggingdependency - Retrieving data with a stored procedure user Reduce supplemental logging dependency . . . 81 exit ...... 104 Single scrape and staging store commands ....81 Example of a stored procedure user exit . . . 110 dmclearstagingstore - Remove cached operations Sample Java class user exits for InfoSphere CDC 111 from the staging store ...... 81 To compile the sample Java class user exits dmgetstagingstorestatus - Retrieve Staging Store (UNIX and Linux) ...... 111 status ...... 82 InfoSphere CDC API reference – Javadocs ....112 Exporting and importing configuration commands 82 dmexportconfiguration - Export InfoSphere CDC Conflict resolution audit table ....113 Configuration ...... 82 Structure of the conflict resolution audit table . . 113 dmimportconfiguration - Import InfoSphere CDC Row image format...... 115 Configuration ...... 83 Truncated images ...... 115 Managing tables for replication commands ....84 Unaudited data types...... 115 dmdescribe - Describe source tables .....84 dmflagforrefresh - Flag for Refresh .....85 Troubleshooting and contacting IBM dmmarktablecapturepoint - Mark a table capture point on a source table ...... 85 Support ...... 117 dmpark - Park table ...... 87 dmreaddtable - Update source table definition. . 87 Notices ...... 119 dmreassigntable - Update target table definition 88 Trademarks ...... 121
iv InfoSphere Change Data Capture: End-User Documentation About InfoSphere CDC and InfoSphere CDC Management Console
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 CDC Management 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: v 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. v Admin API—Operates as an optional Java-based programming interface that you can use to script operational configurations or interactions. v Apply agent—Acts as the agent on the target that processes changes as sent by the source. v Command line interface—Allows you to administer datastores and user accounts, as well as to perform administration scripting, independent of Management Console.
© Copyright IBM Corp. 2008, 2011 1 v Communication Layer (TCP/IP)—Acts as the dedicated network connection between the Source and the Target. v 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. v 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. v Metadata—Represents the information about the relevant tables, mappings, subscriptions, notifications, events, and other particulars of a data replication instance that you set up. v 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. v Refresh—Performs the initial synchronization of the tables from the source database to the target. This is read by the Refresh reader. v 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. v 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. v Source transformation engine—Processes row filtering, critical columns, column filtering, encoding conversions, and other data to propagate to the target datastore engine. v 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. v 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: v JMS Messages—Acts as a JMS message destination (queue or topic) for row-level operations that are created as XML documents. v InfoSphere DataStage—Processes changes delivered from InfoSphere CDC that can be used by InfoSphere DataStage jobs.
For more information on how to install Management Console and Access Server, see Access Server and Management Console - Installation Guide. For information on how to install your source and target replication engines, see the end-user documentation for your replication engine platform.
2 InfoSphere Change Data Capture: End-User Documentation In this section, you will learn: “Capturing change data with single scrape”
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” on page 16 “Assessing disk space and memory requirements” on page 14 “About InfoSphere CDC and InfoSphere CDC Management Console” on page 1
About InfoSphere CDC and InfoSphere CDC Management Console 3 4 InfoSphere Change Data Capture: End-User Documentation What’s new
A large number of features and enhancements have been added to InfoSphere CDC for Oracle databases version 6.5, version 6.5.1 and version 6.5.2. The following table lists the major feature changes:
Item For more information, see: XA support “Replicating XA transactions” on page 23 Single scrape “Capturing change data with single scrape” on page 3 Staging store “Disk space requirements” on page 9
“Assessing disk space and memory requirements” on page 14 Replicating Data Definition “Replicating DDL changes” on page 21 Language (DDL) operations Indexed Organized Tables “Understanding Index Organized Tables (IOT) support” (IOT) support on page 20 New command “dmshowsupplementalloggingdependency - Show supplemental logging dependency” on page 80 New command “dmreducesupplementalloggingdependency - Reduce supplemental logging dependency” on page 81
© Copyright IBM Corp. 2008, 2011 5 6 InfoSphere Change Data Capture: End-User Documentation System requirements
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: “Supported operating systems and processors” “Supported databases” on page 8 “Disk space requirements” on page 9 “RAM requirements” on page 10 “Tablespace requirements” on page 11 “Port requirements” on page 11
Supported operating systems and processors
Operating system and processor One of the following: v AIX®, version 5.3.0.8 or later—POWER® processor v AIX, version 6.1—POWER processor v AIX, version 7.1—POWER processor v HP-UX, 11i v3 (11.23)—Itanium processor (Not applicable for Oracle 11gR2) v HP-UX, 11i v3 (11.31)—Itanium processor (Not applicable for Oracle 11gR2) v HP-UX, 11i v2 (11.11)—PA-RISC processor (Not applicable for Oracle 11gR2) v HP-UX, 11i v3 (11.23)—PA-RISC processor (Not applicable for Oracle 11gR2) v Linux Red Hat version 4—x86/x64 processors (Not applicable for Oracle 11gR2) v Linux Red Hat version 5—x86/x64 processors (Not applicable for Oracle 11gR2) v Linux Red Hat version 5.4—x86/x64 processors (Not applicable for Oracle 10g or Oracle 11gR2) v Novell SUSE Linux (SLES) 10.0 Enterprise Server—x86/x64 processors v Novell SUSE Linux (SLES) 11.0 Enterprise Server—x86/x64 processors (Not applicable for Oracle 9i or Oracle 10g) v Linux Red Hat on System z® version 5 (Not applicable for Oracle 9i) v Novell SUSE Linux (SLES) on System z version 10 (Not applicable for Oracle 9i) v Novell SUSE Linux (SLES) on System z version 11 (Not applicable for Oracle 9i) v Sun Solaris, version 2.9—SPARC processor v Sun Solaris, version 2.10—SPARC processor
Note: If you are upgrading your operating system to a more recent version, you should also consider upgrading InfoSphere CDC to the latest version to ensure support for the upgraded operating system.
© Copyright IBM Corp. 2008, 2011 7 Related concepts “Supported databases” “Disk space requirements” on page 9 “RAM requirements” on page 10 “Tablespace requirements” on page 11 “Port requirements” on page 11
Supported databases
Database Install Oracle Client software and one of the following versions of the Oracle database: v Oracle 9i (release 9.2.0.5 or later) v Oracle 10g (release 10.1.0.4 or later) v Oracle 11g (release 11gR1 and 11gR2)
If you are configuring InfoSphere CDC for an Oracle RAC environment, the following versions of Oracle are supported: v Oracle 9i (release 9.2.0.5 or later) v Oracle 10g (release 10.2 or later) v Oracle 11g (release 11gR1 and 11gR2)
Note: The following Oracle 11g features are not supported with InfoSphere CDC: v LOBs in IOTs v LOBs in partitioned IOTs v IGNORE_ROW_ON_DUPKEY_INDEX hint v DML with error logging table v DBMS_PARALLEL_EXECUTE (for RAC and non-RAC environments) v Oracle XA in non-RAC v Flashback table (with focus on replicating DML following its recovery) v Flashback table (with focus on DDL replication) v ASM restricted mode v Auto failover or failback for user SQL sessions v Oracle RAC one node (that is, single-node RAC) v Oracle XA in RAC v Auto degree of parallelism (for RAC and non-RAC environments) v Zero downtime patching v OCFS for Solaris v 4KB sector size drives v Encrypted tablespaces v Recovering database blocks v Edition-based redefinition v Flashback data archive for DDL (such as adding columns or truncating tables)
Note: If you are upgrading your database to a more recent version, you should also consider upgrading InfoSphere CDC to the latest version to ensure support for the upgraded database.
8 InfoSphere Change Data Capture: End-User Documentation Related concepts “Supported operating systems and processors” on page 7 “Disk space requirements” “RAM requirements” on page 10 “Tablespace requirements” on page 11 “Port requirements” on page 11
Disk space requirements
Disk space InfoSphere CDC source system: v 100 GB—Default value for the Staging Store Disk Quota for each instance of InfoSphere CDC. Use the InfoSphere CDC configuration tool to configure disk space for this quota. v 5GB—For installation files, data queues, and log files. v 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: v 1GB—The minimum amount of disk space allowed for the Staging Store 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. v 5GB—For installation files, data queues, and log files. v 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: v You are running large batch transactions in the database on your source system. v 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. v You are replicating large LOB data types. v You are replicating "wide" tables that have hundreds of columns. v You are performing regular back ups of your metadata with the dmbackupmd command-line utility.
System requirements 9 Related concepts “Supported operating systems and processors” on page 7 “Supported databases” on page 8 “RAM requirements” “Tablespace requirements” on page 11 “Port requirements” on page 11 “Configuring InfoSphere CDC (UNIX and Linux)” on page 41
RAM requirements
RAM Each instance of InfoSphere CDC requires memory for the Java Virtual Machine (JVM). The following default values for memory are assigned: v 1024 MB of RAM —Default value for each 64-bit instance of InfoSphere CDC. v 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: v 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. v You are replicating "wide" tables with hundreds of columns. v You are performing large batch transactions in your source database rather than online transaction processing (OLTP).
10 InfoSphere Change Data Capture: End-User Documentation Related concepts “Supported databases” on page 8 “Supported operating systems and processors” on page 7 “Disk space requirements” on page 9 “Tablespace requirements” “Port requirements” “Configuring InfoSphere CDC (UNIX and Linux)” on page 41
Tablespace requirements
Oracle tablespace for InfoSphere CDC metadata 25 MB—This is only an estimate and depends on the size of your replication configuration.
Related concepts “Supported databases” on page 8 “Supported operating systems and processors” on page 7 “Disk space requirements” on page 9 “RAM requirements” on page 10 “Port requirements”
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 11111 Accepts connections from: v Management Console v Other installations of InfoSphere CDC as a source of replication v Command line utilities
For more information on how to install Management Console, see Management Console and Access Server - Installation Guide.
Related concepts “Maintaining active TCP connections in a network environment” on page 54 “Disk space requirements” on page 9 “Supported operating systems and processors” on page 7 “Supported databases” on page 8 “RAM requirements” on page 10 “Tablespace requirements” “Configuring InfoSphere CDC (UNIX and Linux)” on page 41
System requirements 11 12 InfoSphere Change Data Capture: End-User Documentation Before you install
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” “Assessing disk space and memory requirements” on page 14 “Allocating sufficient disk space for database log files” on page 15 “Sizing considerations for the staging store” on page 16 “Enabling supplemental logging” on page 17 “Enabling InfoSphere CDC to use a bulk load refresh” on page 18 “Setting the database instance to ARCHIVELOG mode” on page 19 “InfoSphere CDC and Automatic Storage Management (ASM)” on page 19 “Starting the Oracle listener” on page 19 “Setting up a remote connection” on page 19 “Understanding Index Organized Tables (IOT) support” on page 20 “Replicating DDL changes” on page 21 “Calculating database connections required by InfoSphere CDC” on page 21 “Clustered tables” on page 23 “Interval partitions” on page 23 “Replicating XA transactions” on page 23
Required database, user accounts, and schemas Configuring an Oracle database
When you configure InfoSphere CDC, you are prompted for the name of the Oracle database from which you want InfoSphere CDC to replicate data. Before installing InfoSphere CDC, ensure that this Oracle database exists and that you have created and set up a database user that has access to it. Setting up a UNIX user account
When you are installing InfoSphere CDC on a UNIX machine, you must set up a new, or decide on an existing UNIX account that you will use to install, configure, or upgrade InfoSphere CDC. You can install InfoSphere CDC in the directory of your choice, however, it must be owned by the UNIX account. As well, the UNIX account must belong to the Oracle DBA group. Setting up an Oracle user account
Create a user account for the Oracle database. When you configure a new instance of InfoSphere CDC, you are prompted for the name of the Oracle database you want InfoSphere CDC to connect to, the user name and password of the Oracle user that has access to this database. Unless your Oracle database is version 11g, neither the user name or password are case sensitive.
© Copyright IBM Corp. 2008, 2011 13 Setting up an Oracle user with a read-only connection to the database
You can also create a user account that has a read-only connection to the Oracle database. This type of connection allows a user to read or query data from the database and does not allow a user to write or make any modifications. As an administrator, you can specify a read-only connection for a user when installing and configuring InfoSphere CDC. If you decide to create a read-only database user, you must ensure the following before installing and configuring InfoSphere CDC: v You have enabled supplemental logging for the Oracle database. v The DBMS_FLASHBACK Oracle package is installed. By default, this package is installed when you create an Oracle database and run the CATPROC.SQL script. No further action is required for this package. For more information, refer to your Oracle documentation. Reviewing required privileges for Oracle users
Before installing and configuring InfoSphere CDC, you should review the list of privileges required by Oracle users. You are required to grant these privileges to users by running SQL scripts which are located in the /samples directory of your installation folder. You must grant privileges after installing InfoSphere CDC so that you can access the necessary SQL script. Configuring an Oracle schema
Create a schema or choose an existing schema for your database metadata tables. You will have to specify this schema when you configure InfoSphere CDC. Related concepts “Enabling supplemental logging” on page 17 “Privileges for Oracle users” on page 49
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.
14 InfoSphere Change Data Capture: End-User Documentation 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 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” on page 16 “Configuring InfoSphere CDC (UNIX and Linux)” on page 41 “Disk space requirements” on page 9 “RAM requirements” on page 10
Allocating sufficient disk space for database log files Allocate sufficient disk space for your database online and archive logs. InfoSphere CDC requires access to archive database logs to read and send accumulated data changes for several scenarios. InfoSphere CDC requires the archive logs any time the log position that InfoSphere CDC is replicating falls outside of the online logs. This can occur when there is a backlog of changes, or InfoSphere CDC has been shut down. When InfoSphere CDC exceeds the memory quota allocated, or shuts down, the changes in the staging store and transaction queue will be persisted to disk.
Before you install 15 InfoSphere CDC is shut down for maintenance
InfoSphere CDC requires the archive logs to capture changes when replication has stopped on a subscription for maintenance activities. You require sufficient disk space for the archive logs. For example, if you decide to restart mirroring on a subscription that stopped for one week, InfoSphere CDC must read through all the log volume that was generated in this time period and capture accumulated changes. The database may have generated many archived log files while the subscription was inactive.
After time, also assess whether you want to keep the logs or refresh after a lengthy period of time with no replication. This would depend on the number of and types of changes and the amount of data in the archive logs. Sometimes, it is more efficient to clean out the logs to prevent maintaining unnecessary data.
While subscriptions are inactive for a period of time, the database generates many archive log files which need to be retained. Use the dmshowlogdependency command to indicate which log files to keep. For example, to display the complete list of database logs that are required for the MYINSTANCE instance and MYSUBSCRIPTIONNAME subscription, run this command: dmshowlogdependency -I MYINSTANCE -i -s MYSUBSCRIPTIONNAME
Mirroring is run intermittently for a subscription
When you set a subscription with a scheduled end to Now, InfoSphere CDC captures the data from the earliest marked log position up until the current log position. The earliest marked log position is set by the oldest open transaction or Unit of Recovery (UR) in the database when InfoSphere CDC was last run or when you set a subscription to use mirroring in Management Console. When you start mirroring on the subscription in Management Console, InfoSphere CDC marks the current position in the log and only those changes that InfoSphere CDC accumulated between these log positions (earliest and current) are sent to the target table. Because of the time period that may have elapsed between the earliest and current log positions, there may be many archive log files that need to be retained until InfoSphere CDC has processed them. A subscription experiences latency while continuously mirroring changes to the target database
During continuous mirroring, your subscription may begin to lag and may even be unable to keep up with current changes the database is writing to your archive logs. This is what happens when your subscription experiences latency. InfoSphere CDC requires access to the archive logs so that it can continue to read the accumulated changes from the log files and eventually catch up to the current position in the archive log files. For very latent subscriptions, this can be log files that are hours, days, or even weeks old. To determine latency, use the Management Console Monitoring perspective. The Monitoring perspective contains the Subscriptions view and the Performance view. These views allow you to initiate replication and monitor your replication activity.
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.
16 InfoSphere Change Data Capture: End-User Documentation 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” on page 14 “Continuous Capture commands” on page 62
Enabling supplemental logging Oracle supplemental logging simply means that all columns or selected columns are specified for extra logging. InfoSphere CDC requires supplemental logging on the source database at both the database level and table level. v Database level supplemental logging—This is an Oracle requirement that ensures that the Oracle redo log contains the information required to describe all
Before you install 17 data changes completely. The appropriate setting for database level supplemental logging (by database version) is: – Oracle 9i—Enable minimal supplemental logging. This is the default level of supplemental logging in this version of Oracle. – Oracle 10g or later—Enable minimal database level supplemental logging. You must set this value explicitly in this version of Oracle because the default level of supplemental logging is not sufficient. To check if minimal supplemental logging has been enabled at the database level, run the following SQL statement: select supplemental_log_data_min from v$database;. If supplemental logging is enabled, the returned value will be YES or IMPLICIT. v Table level supplemental logging—InfoSphere CDC also requires full supplemental logging at the table level for those tables you have selected for InfoSphere CDC to replicate using the mirroring replication method. This supplemental logging is typically handled by InfoSphere CDC, unless you are using a read-only database connection to the source database. For a read-only database environment, before configuring subscriptions that involve tables for mirroring, ensure that you have sufficient supplemental logging enabled for those tables. During InfoSphere CDC subscription configuration, the application checks to see if the required logging is enabled. If sufficient table supplemental logging is not enabled, then InfoSphere CDC will return errors and does not complete the configuration. The appropriate setting for table level supplemental logging (by database version) is: – Oracle 9i—Enable full supplemental logging with conditional supplemental log groups. – Oracle 10g or later—Enable full supplemental logging with conditional or unconditional supplemental log groups.
To enable supplemental logging at the database level and table level, contact your Oracle database administrator. For more information on the command that enables supplemental logging, see your Oracle documentation. Related reference “dmshowlogdependency - Show Log Dependency” on page 78 “dmshowsupplementalloggingdependency - Show supplemental logging dependency” on page 80 “dmreducesupplementalloggingdependency - Reduce supplemental logging dependency” on page 81
Enabling InfoSphere CDC to use a bulk load refresh If you want InfoSphere CDC to use a bulk load refresh when applying data to the target database, then you must do the following: 1. Install an Oracle Client on the same server where you have installed and configured InfoSphere CDC. The Oracle Client must be able to connect to the Oracle database. 2. Add the same TNS names entry for your database to the tnsnames.ora file and select this database when configuring InfoSphere CDC.
18 InfoSphere Change Data Capture: End-User Documentation Setting the database instance to ARCHIVELOG mode InfoSphere CDC requires uninterrupted access to Oracle redo logs. Therefore, you must enable the archiving of Oracle redo logs. Make sure that the source database instance is operating in ARCHIVELOG mode. This lets InfoSphere CDC read data from archived Oracle redo logs instead of online redo logs, in the event that excessive latency occurs during mirroring. To set the source database instance to ARCHIVELOG mode, contact your database administrator. You can also verify if archive logging is enabled for the source database by issuing the following SQL statement: select log_mode from v$database; If archive logging is enabled, the returned value will be instance to ARCHIVELOG mode. For more information, see your Oracle documentation. CAUTION: If you do not set the database instance to ARCHIVELOG mode, you may experience data loss.
InfoSphere CDC must have direct access to the archive log files. You can install InfoSphere CDC on the same node that has access to the archive log files. However, if your database instance is managed by Oracle Automatic Storage Manager (ASM), then you can install InfoSphere CDC any node. Please be aware that reading archive and redo logs from ASM can be significantly slower than reading the logs through the file system. If the database produces high volumes of logs, you should consider multiplexing the logs by configuring a log destination outside ASM.
InfoSphere CDC and Automatic Storage Management (ASM) If you are using ASM to manage your Oracle redo log files, the InfoSphere CDC configuration tool requires a user name and password for the ASM instance. The ASM user must have SYSDBA or SYSASM privileges to log in to ASM.
InfoSphere CDC requires that ASM is not configured for automatic rebalance. Automatic rebalance is typically used when disks are added or dropped. If an automatic rebalancing occurs while InfoSphere CDC is reading the database logs, InfoSphere CDC will stop replication.
If you are deploying InfoSphere CDC in a RAC environment that uses ASM, there are additional considerations. For more information, see the related topic below. Related concepts “Oracle ASM considerations” on page 28
Starting the Oracle listener InfoSphere CDC requires the Oracle listener to connect to the database. You must start the Oracle listener before installing InfoSphere CDC. For more information on starting the Oracle listener, see your Oracle documentation.
Setting up a remote connection If you want to install InfoSphere CDC and the Oracle database on different machines, then you must setup a connection to the remote machine (where the Oracle database is installed) using SQL*Net.
See also: “To setup a remote connection” on page 20
Before you install 19 To setup a remote connection 1. Ensure you have installed an Oracle client on the local server and have added the TNS names entry to the tnsnames.ora file. 2. Ensure you have installed and configured an instance of InfoSphere CDC on the local server. When configuring InfoSphere CDC, you must specify the same TNS names entry. 3. Ensure you have started InfoSphere CDC. 4. At the command line on the local server, mount the archive log path from the remote server: mount
Understanding Index Organized Tables (IOT) support InfoSphere CDC supports a subset of Oracle IOT operations starting with Oracle 10g (release 10.1.0.4 or later). Examples of supported operations are individual inserts, updates, and deletes. The operations must be done one at a time on the source database and not as part of a parallel or bulk operation such as INSERT INTO SELECT * FROM or a merge statement.
InfoSphere CDC does not support the following IOT operations: v An IOT comprised of character data. v Populating an IOT using SQL*Loader v LOB columns with IOTs
20 InfoSphere Change Data Capture: End-User Documentation Replicating DDL changes SQL statements are divided into two categories: Data Definition Language (DDL) and Data Manipulation Language (DML). DDL statements are used to describe a database, to define its structure, to create its objects and to create the table's sub-objects. The following list provides some examples of types of DDL statements: v Creating tables (CREATE command) v Modifying the structure of a table (ALTER command) without deleting and recreating it, such as adding columns, removing columns or changing column definitions (for example, length or default values) v Removing objects (such as tables) from the database (DROP command) v Partitioning tables (PARTITION command)
DML statements are used to control the information contained within the database. The following lists provides some examples of types of DML statements: v Adding records to a table (INSERT command) v Modifying information in a table (UPDATE command) v Removing records from a table (DELETE command)
While all InfoSphere CDC replication engines can replicate DML changes, InfoSphere CDC for Oracle databases version 6.5.1 also includes support for replicating DDL changes, enabling simplified and more automated change management. Data changes continue to be replicated, but you no longer have to manually update subscription information when the structure of a table changes. For example, new tables and columns are added according to the DDL statement.
Although a wide array of DDL operations exist, InfoSphere CDC replicates only those that are related to tables and characteristics of tables; it does not replicate the larger context of the database.
DDL replication is configured in Management Console. For more information, see the Management Console Administration guide.
Calculating database connections required by InfoSphere CDC
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.
This topic includes the formulae and examples to help you calculate the number of connections required by InfoSphere CDC versions 6.5.x or 6.3.x. Calculating connections required by InfoSphere CDC on a source database
For InfoSphere CDC version 6.5.x:
(22+G)*N+(4+A)*T+3*R+B+C
For InfoSphere CDC version 6.3.x:
Before you install 21 20*P+A*S+G+3*R+B+C
Where:
Note: Enter 0 for any value that does not apply to your deployment of InfoSphere CDC. v T = number of InfoSphere CDC 6.5.x subscriptions (source datastore in Management Console is version 6.5.x) in all of your InfoSphere CDC 6.5.x instances. v S = number of InfoSphere CDC 6.3.x subscriptions (source datastore in Management Console is version 6.3.x) in all of your InfoSphere CDC 6.3.x instances. v N = number of InfoSphere CDC 6.5.x instances. v P = number of InfoSphere CDC 6.3.x instances. v G = number of Management Console GUI applications that are connected to your instances of InfoSphere CDC. v R = number of RAC nodes if you are using ASM with Oracle RAC. v A = number of RAC nodes if you are not using ASM with Oracle RAC. v B = number of subscriptions that contain LOB columns. v C = number of InfoSphere CDC command line utilities that you plan to use. Example: How to calculate required connections for a source database (InfoSphere CDC version 6.5)
You want to setup InfoSphere CDC in the source environment as follows: v 3 InfoSphere CDC 6.5.x subscriptions. v 2 InfoSphere CDC 6.5.x instances. v 1 subscription that uses LOB columns. v 1 instance of Management Console. v 2 RAC nodes and you are not using ASM. v 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+2)*3+1=65
You should plan for a maximum of 65 database connections before installing InfoSphere CDC on a source database. Calculating connections required by InfoSphere CDC version 6.5.x or 6.3.x on a target database
For InfoSphere CDC version 6.5.x or 6.3.x:
(4+G)*N + 3*T
Where: v T = number of InfoSphere CDC subscriptions (target datastore in Management Console is version 6.5.x or 6.3.x). v G = number of Management Console GUI applications that are connected to your instances of InfoSphere CDC. v N = number of InfoSphere CDC 6.5.x instances.
22 InfoSphere Change Data Capture: End-User Documentation Example: How to calculate required connections for a target database
You want to setup InfoSphere CDC in the target environment as follows: v 3 subscriptions. v 2 InfoSphere CDC 6.5.x instances. v 1 installed Management Console GUI application.
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.
Clustered tables InfoSphere CDC does not support Oracle clustered tables.
Interval partitions The replication of tables with interval partitions is supported by InfoSphere CDC for Oracle databases only when the tables are part of a Rules-based mapping for DDL Replication.
Tables with interval partitions cannot be replicated as part of Direct mappings.
For more information on Rule-based mappings and Direct mappings, see “Working with rule sets” in the Management Console Administration Guide.
Replicating XA transactions InfoSphere CDC will replicate transactions involved in XA. InfoSphere CDC will maintain any data dependencies between individual branches. Oracle's DTP facility must be used in RAC environments when multiple branches of a single XA transaction will occur in that database
Replication of XA transactions is supported on the following database versions: v Oracle 10g and later
Before you install 23 24 InfoSphere Change Data Capture: End-User Documentation Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC) environment
To deploy InfoSphere CDC in an Oracle RAC environment, you can install the product on one node in the cluster or on a system outside of the cluster. In both scenarios you must install InfoSphere CDC on the mount point of a SAN (Storage Area Network) or NFS (Network File System). InfoSphere CDC must have access to all archived and online redo log files generated by all nodes in the cluster. Installing the product on a system outside of your RAC environment is the optimum configuration for failover scenarios where a node may fail.
To integrate InfoSphere CDC into your RAC environment, you must first define an Oracle service for the RAC environment in the tnsnames.ora file for each RAC node. You can then select this service when creating an instance of InfoSphere CDC for your RAC environment with the InfoSphere CDC configuration tool. To complete the integration, you can create an InfoSphere CDC failover script that automates the failover process.
An overview of InfoSphere CDC configuration in a RAC environment (with Active-Passive configuration) is provided in the following diagram:
© Copyright IBM Corp. 2008, 2011 25 Behavior of InfoSphere CDC in a RAC environment
InfoSphere CDC queries the v$archived_log and v$log Oracle views to locate the database log files and attempts to access the files in the first log destination as defined in your Oracle database. If the log files are unavailable in the first destination, InfoSphere CDC proceeds to the next destination until it finds the required log files. To avoid latency, configure your Oracle database so that the first destination contains the required log files.
InfoSphere CDC replicates data from all RAC nodes at once and the stream of data from individual nodes is sorted (to account for data that is scrambled by log parallelism) and merged together for transaction consistency. InfoSphere CDC does not replicate data if the main node is closed. While replicating data, InfoSphere CDC opens connections to the source database and if these connections are closed for any reason, InfoSphere CDC ends replication.
InfoSphere CDC detects failed nodes in approximately 21 seconds. After the node fails, InfoSphere CDC continues to replicate data if the Oracle Cluster Ready Services (CRS) is running and recovers and finalizes the online logs from the failed node. InfoSphere CDC ensures data integrity when replicating data from all other nodes in your RAC environment. Once the node is restored, InfoSphere CDC automatically starts replicating from the restored node. If the nodes in your RAC environment have an unbalanced load, InfoSphere CDC may experience a latency of several times the Oracle checkpoint interval (3 seconds).
In this section, you will learn: “Configuring InfoSphere CDC in a RAC environment” “Configuring tnsnames.ora for InfoSphere CDC in a RAC environment” on page 28 “Oracle ASM considerations” on page 28 “Creating an InfoSphere CDC failover script for a RAC environment” on page 29 “NFS lockd utility considerations” on page 30 Related concepts “Configuring InfoSphere CDC (UNIX and Linux)” on page 41 “Installing InfoSphere CDC” on page 35 Related reference “dmconfigurets - Configure InfoSphere CDC” on page 95
Configuring InfoSphere CDC in a RAC environment
InfoSphere CDC can be installed in a node which is part of the Oracle RAC, or it might be installed on a node outside of the RAC environment. In either case, you must install InfoSphere CDC on the mount point of a SAN. This configuration assures that, in the case of a failure of one of the nodes of the Oracle RAC, InfoSphere CDC will not require any configuration changes to continue to work.
If InfoSphere CDC is running on another node from the failed one, no user intervention is required. Instead, InfoSphere CDC will detect the node failure in approximately 21 seconds and if Oracle Cluster Ready Services is running and recovers, InfoSphere CDC will continue to replicate data (including the online logs from the failed node).
26 InfoSphere Change Data Capture: End-User Documentation If InfoSphere CDC was running on the failed node, then it must be restarted from a different node. No changes are needed because the same binaries and configuration metadata is accessible from all nodes. If this is the case, to achieve an optimal configuration to perform failover of InfoSphere CDC, consider three possible scenarios: v Active source RAC node failure. In this case, the RAC node where the active InfoSphere CDC source instance fails. v Active target RAC node failure. In this case, the RAC node where the active InfoSphere CDC target instance fails. v Both active RAC nodes (source and target) fail.
In addition, the following needs to be satisfied: v Ability to restart InfoSphere CDC from a different location (that is, InfoSphere CDC binaries and configuration, and operational metadata need to be accessible). v Reachability of InfoSphere CDC by external clients or processes (for example, for subscriptions targeting the failed InfoSphere CDC instance).
With shared location configuration, restarting InfoSphere CDC requires no special configuration changes.
With respect to reachability, consider both the accessibility of the host where InfoSphere CDC is running, and accessibility of the database. To ensure accessibility of the host, create an entry in the /etc/hosts file for each node involved in the environment using a common host name pointing to the IP address of the current node. For example, in case of a two-node RAC environment, the /etc/hosts file in the first node should have the following entry: #cdc_host
In the second node, the /etc/hosts file should have the following entry: #cdc_host
Thus, the cdc_host host name is invariable, but is actually pointing to the proper physical IP address, depending on which node InfoSphere CDC is running. To ensure accessibility to the database is to follow a similar strategy. A special entry in tnsnames.ora file should be created using the common host name: SID_CDC= (DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=cdc_host)(PORT=1521)) (CONNECT_DATA=(server=DEDICATED) (SERVICE_NAME=SID) ) )
Using this configuration method, when InfoSphere CDC tries to connect to the database it will connect to the Oracle instance listening in port 1521 on host cdc_host, and cdc_host will point to the proper IP address depending on the node where it is running.
With the this approach, regardless which node fails, and which InfoSphere CDC source or target have to failover, no changes in configuration are needed. All that is required is restarting InfoSphere CDC from the new location and perform some cleanup such as removing transaction queues, and cleaning staging store after restarting the instance from the new location.
Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC) environment 27 The same approach should be used to ensure accessibility from clients such as Management Console. When defining datastores in Access Server, use host names that, in case of failovers, can be easily changeable to the new real physical location. Once the IP switch is complete, restart Access Server. No other configuration change is needed to operate InfoSphere CDC.
Configuring tnsnames.ora for InfoSphere CDC in a RAC environment
If you are using Oracle RAC without ASM, InfoSphere CDC requires an identical TNS entry in the tnsnames.ora file on each RAC node. InfoSphere CDC uses the TNS entry to connect to your RAC environment on the current active node. For example, your TNS entry may look something like this: CDC_SID = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = racsystemvip)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = racsid.racsystem.com) (INSTANCE_NAME = instancesid) ) )
Where: v racsystemvip—virtual IP for your RAC system. v racsid.racsystem.com—global service name for your RAC system. v instancesid—unique name of this instance in your RAC system.
When you are ready to create an InfoSphere CDC instance for your RAC environment with the InfoSphere CDC configuration tool, select the global service name that you defined in the tnsnames.ora file for InfoSphere CDC when prompted to select a TNS name. You must select a single node (considered the main node by InfoSphere CDC), not the entire RAC instance. Related concepts “Creating an InfoSphere CDC failover script for a RAC environment” on page 29 “Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC) environment” on page 25 “Configuring InfoSphere CDC (UNIX and Linux)” on page 41 “Installing InfoSphere CDC” on page 35 Related tasks “To add a new instance of InfoSphere CDC for Oracle databases (UNIX and Linux)” on page 41 Related reference “dmconfigurets - Configure InfoSphere CDC” on page 95
Oracle ASM considerations If you are using ASM in your RAC environment to manage your Oracle redo log files, the InfoSphere CDC configuration tool requires that you specify the Oracle SID of the local node where InfoSphere CDC is installed. The configuration tool can be launched from the command line by issuing the dmconfigurets command.
28 InfoSphere Change Data Capture: End-User Documentation The local Oracle SID is required because ASM does not allow remote connections from Oracle client software such as SQL*NET. You must be logged in to the same host where ASM is installed to connect to ASM.
You should also note that in Oracle version 11g, the ORACLE_HOME environment variable for ASM is different from ORACLE_HOME for the database. You should take this into consideration when configuring your RAC environment and creating an instance of InfoSphere CDC. Related concepts “Configuring InfoSphere CDC (UNIX and Linux)” on page 41 “InfoSphere CDC and Automatic Storage Management (ASM)” on page 19 Related reference “dmconfigurets - Configure InfoSphere CDC” on page 95
Creating an InfoSphere CDC failover script for a RAC environment If an Oracle RAC node fails but the system containing the node is still responsive, you can use a recovery script for InfoSphere CDC that automates the following tasks: v Stop replication on all subscriptions with the dmendreplication command. v Shut down all InfoSphere CDC processes with the dmshutdown command. v Modify the INSTANCE_NAME parameter in the tnsnames.ora file to point to the next available RAC node. v If required, restart the Oracle service listener. v Delete the following staging area files in the InfoSphere CDC installation directory: –
Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC) environment 29 Related concepts “Configuring tnsnames.ora for InfoSphere CDC in a RAC environment” on page 28 “Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC) environment” on page 25 “Configuring InfoSphere CDC (UNIX and Linux)” on page 41 Related reference “dmendreplication - End replication” on page 64 “dmshutdown - Shut down InfoSphere CDC” on page 96 “dmts32 - Start InfoSphere CDC” on page 100 “dmts64 - Start InfoSphere CDC” on page 101 “dmstartmirror - Start mirroring” on page 68
NFS lockd utility considerations If you have installed InfoSphere CDC on a NFS share and you are using the lockd utility (network lock daemon) that is part of the NFS lock manager, InfoSphere CDC may be adversely affected by the locking semantics used by this utility. An abnormal shut down of the active node may result in a lack of synchronization between the NFS daemon and the network lock daemon. This situation may affect the ability of InfoSphere CDC to acquire file locks during start up on the new active node. To resolve this issue, you must ensure that both daemons are synchronized and delete the TSLOCK file in the InfoSphere CDC
30 InfoSphere Change Data Capture: End-User Documentation Configuring InfoSphere CDC for OS (operating system) clustering (UNIX and Linux)
InfoSphere CDC supports Active/Passive two-node clusters on the UNIX and Linux platforms. Clustering provides continuous access to resources in the event of a hardware failure, software failure, or some other interruption.
To implement InfoSphere CDC clustering support in your environment, you must complete all of the following prerequisite tasks.
Note: Prerequisites that only apply to InfoSphere CDC as a clustered source or a clustered target are specified. v Install InfoSphere CDC on the shared drive of the cluster. v Add a new instance of InfoSphere CDC. v Ensure that the server port you specify during configuration of the instance is available and persistent on both nodes of the cluster. InfoSphere CDC listens on this port. v Ensure that InfoSphere CDC connects to the database in the same way on both nodes of the cluster. In other words, database connection parameters such as the path to the database and services must be identical on both nodes of the cluster. v Ensure that all of the database logs required for replication are available. This prerequisite only applies to InfoSphere CDC as a clustered source. v Ensure that the path to the database logs required for replication is identical on both nodes of the cluster. This prerequisite only applies to InfoSphere CDC as a clustered source. v Ensure that every InfoSphere CDC source that connects to the target sees the target in the same way. The target must have a clustered IP address or use the same host name for both nodes of the cluster. This prerequisite only applies to InfoSphere CDC as a clustered target. v Optionally, schedule a regular backup of your InfoSphere CDC metadata and event log messages. Note that metadata will only change when you add or modify subscriptions. You can find more information about this prerequisite in the failover procedure for InfoSphere CDC in this section.
Note: You can run the dmshowlogdependency command with the –i flag to list the database logs required for replication.
In this section, you will learn: “Performing a forced or manual failover of InfoSphere CDC” on page 32 “Preparing for a failover of InfoSphere CDC” on page 32
© Copyright IBM Corp. 2008, 2011 31 Related concepts “Configuring InfoSphere CDC instances (UNIX and Linux)” on page 41 Related tasks “To install InfoSphere CDC (UNIX and Linux)” on page 35
Performing a forced or manual failover of InfoSphere CDC
A forced or manual failover is often necessary in a clustered environment for software upgrades, maintenance, or other reasons. The tasks in the following steps must be included in your manual failover script. 1. Stop all instances of InfoSphere CDC on the current active node with the following command: dmshutdown -I
Preparing for a failover of InfoSphere CDC
To prepare for a failover such as a hardware or software failure, your clustering environment will require a script that performs InfoSphere CDC tasks on the new active node. The tasks in the following steps must be included in your failover script. 1. Clean the transaction queues for each instance by removing all files that begin with txqueue* in the
32 InfoSphere Change Data Capture: End-User Documentation 5. Run the dmclearstagingstore command on the new active node for all instances. 6. Start all subscriptions on the new active node with the dmstartmirror command. Related concepts “Starting InfoSphere CDC” on page 53 Related tasks “Performing a forced or manual failover of InfoSphere CDC” on page 32 Related reference “dmclearstagingstore - Remove cached operations from the staging store” on page 81 “dmstartmirror - Start mirroring” on page 68
Configuring InfoSphere CDC for OS (operating system) clustering (UNIX and Linux) 33 34 InfoSphere Change Data Capture: End-User Documentation Installing InfoSphere CDC
This section provides step-by-step instructions on how to install InfoSphere CDC.
If you are installing a fix pack, you must already have an installation of InfoSphere CDC in order to successfully complete the installation.
Note: When upgrading to InfoSphere CDC version 6.5, you must also upgrade both Management Console and Access Server to version 6.5.
In this section, you will learn: “To install InfoSphere CDC (UNIX and Linux)” “To override the locale for the installation (UNIX and Linux)” on page 36 “Installing InfoSphere CDC using a silent installation” on page 36 Related concepts “Before you install” on page 13
To install InfoSphere CDC (UNIX and Linux)
Note the following before you install or upgrade InfoSphere CDC on Linux or UNIX: v Do not install or upgrade InfoSphere CDC as a root user. v The installation directory requires file system permissions of 600 if you plan on using the same user account to install the product, create and configure instances, or upgrade the product. v The installation directory requires file system permissions of 660 if you plan on using different user accounts to install the product, create and configure instances, or upgrade the product. 1. Log on to the account you set up for InfoSphere CDC. 2. Copy the InfoSphere CDC installation file for your UNIX or Linux platform from the InfoSphere CDC CD-ROM or download it from the InfoSphere CDC web site. 3. Make the installation binary file executable. 4. Run the installation program by typing the following command: ./
Note: The directory that you specify must be owned by the account you are using for the installation. If the installation program cannot create the directory, you are prompted to specify a different directory. 8. Review the installation summary. Press Enter to start the installation.
© Copyright IBM Corp. 2008, 2011 35 9. After completing the installation, InfoSphere CDC gives you the option of launching the configuration tool for InfoSphere CDC. 10. Enter 1 to launch the configuration tool.
Note: If you have X-Windows installed, the installation program will launch the configuration tool in a graphical environment. Related concepts “Configuring InfoSphere CDC (UNIX and Linux)” on page 41
To override the locale for the installation (UNIX and Linux)
Use the following procedure to override the locale for the installer. English and Japanese are supported. 1. Navigate to the directory that contains the InfoSphere CDC installation file. 2. Start the installer with the following flags to override the locale of the installation: v English—
After the installation is complete, you have the option of launching the InfoSphere CDC configuration tool. The configuration tool will use the locale settings for your system.
Installing InfoSphere CDC using a silent installation A silent installation allows you to automatically install InfoSphere CDC by specifying a command with various parameters. You can use this type of installation method for large-scale deployments of InfoSphere CDC by embedding the silent installation command in a script.
See also: “To perform a silent installation of InfoSphere CDC (UNIX and Linux)” To perform a silent installation of InfoSphere CDC (UNIX and Linux) 1. Log on to the account you set up for InfoSphere CDC. 2. Copy the InfoSphere CDC installation binary from the InfoSphere CDC CD-ROM or download it from the InfoSphere CDC Web site. 3. Make the installation binary executable. 4. Install InfoSphere CDC and generate a response file with the following command:
36 InfoSphere Change Data Capture: End-User Documentation v
Installing InfoSphere CDC 37 38 InfoSphere Change Data Capture: End-User Documentation Upgrading Transformation Server for Oracle to InfoSphere CDC for Oracle databases
There is no direct upgrade from Transformation Server® for Oracle version 6.0 (Service Pack 3 TFE 28 and later) to InfoSphere CDC for Oracle databases version 6.5. You must install InfoSphere CDC for Oracle databases version 6.5 on the same database server where your existing installation of Transformation Server resides. The database server must be the same so that you can transfer existing subscriptions from Transformation Server to InfoSphere CDC instance. After a successful installation of InfoSphere CDC for Oracle databases version 6.5, you can transfer and upgrade subscriptions in Management Console.
Earlier versions of the software must first be upgraded to Transformation Server for Oracle version 6.0 Service Pack 3 TFE 28 before attempting a migration to InfoSphere CDC for Oracle databases version 6.5.
In this section, you will learn: “To upgrade from Transformation Server for Oracle to InfoSphere CDC for Oracle databases”
To upgrade from Transformation Server for Oracle to InfoSphere CDC for Oracle databases 1. Ensure you have an existing installation of Transformation Server for Oracle version 6.0 (Service Pack 3 and later) on a database server. 2. Install InfoSphere CDC for Oracle databases version 6.5 on the same database server where you have installed Transformation Server for Oracle version 6.0 (Service Pack 3 TFE 28 and later). 3. Ensure both instances of Transformation Server for Oracle and InfoSphere CDC are started. 4. End any active replication. 5. Upgrade existing subscriptions and transfer existing bookmarks from Transformation Server for Oracle version 6.0 (Service Pack 3 TFE 28 and later) to InfoSphere CDC for Oracle databases version 6.5 in Management Console. For more information, see Upgrading existing Transformation Server subscriptions to InfoSphere CDC in your Management Console documentation. Related reference “dmts64 - Start InfoSphere CDC” on page 101 “dmts32 - Start InfoSphere CDC” on page 100 “dmendreplication - End replication” on page 64
© Copyright IBM Corp. 2008, 2011 39 40 InfoSphere Change Data Capture: End-User Documentation Configuring InfoSphere CDC (UNIX and Linux)
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 instances (UNIX and Linux)”
Configuring InfoSphere CDC instances (UNIX and Linux) 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 logging is turned on for each database from which you intend to capture data changes.
See also: “To add a new instance of InfoSphere CDC for Oracle databases (UNIX and Linux)” “To edit an instance of InfoSphere CDC (UNIX and Linux)” on page 43 “To delete an instance of InfoSphere CDC (UNIX and Linux)” on page 44 To add a new instance of InfoSphere CDC for Oracle databases (UNIX and Linux) 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: \
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. For more information, see your Management Console documentation. 6. If you are using the auto-discovery feature in Access Manager, then enable the this feature by typing the UDP port number that you set in Access Server. InfoSphere CDC uses this UDP port number for auto-discovery broadcasts sent from Access Server. Otherwise, press Enter to disable this feature.
© Copyright IBM Corp. 2008, 2011 41 7. Enter the maximum amount of 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. 8. Enter the amount of physically available RAM that you want to allocate for this instance of InfoSphere CDC and press Enter. 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. 9. Depending on the bit version of your server, enter 32 or 64 and press Enter. 10. If you have configured a read-only connection to the Oracle database, then enter y. For Oracle databases with read and write access, enter n.
Note: Once you have created an instance of InfoSphere CDC with a connection to a read-only database, then this option is set and you cannot connect to the Oracle database with read and write access. 11. Enter the path of the Oracle database (ORACLE_HOME environment variable) 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. Press Enter. 12. Select the TNS name for your Oracle database that you defined for InfoSphere CDC in the tnsnames.ora file. If you are configuring an instance for an Oracle RAC environment, consider the following: v If you are using Oracle ASM to manage your Oracle redo log files, select the Oracle SID of the local node where InfoSphere CDC is installed. Additional ASM information is required in step 13 of this procedure. v If you are not using Oracle ASM to manage your Oracle redo log files, select the Oracle global service name that you defined for InfoSphere CDC in the tnsnames.ora file. 13. If you are using ASM to manage your Oracle redo logs, perform the following steps. Otherwise enter n, press Enter and proceed to step 19 on page 43. a. Enter y and press Enter b. Enter the path information for the ASM instance (ASM ORACLE_HOME environment variable) that is installed on the local node and press Enter. c. Enter your ASM user name and press Enter. d. Enter your ASM password and press Enter. 14. If you want to specify extra JDBC parameters, perform the following steps. Otherwise, enter n and press Enter. a. Enter y and press Enter. b. Enter the extra JDBC parameters in a semicolon delimited list and press Enter. 15. Enter the user name for the specified database and press Enter. If you have configured an Oracle database with a read-only connection, then specify the user for that database. 16. Enter the case-sensitive password for the specified database and press Enter.
42 InfoSphere Change Data Capture: End-User Documentation The configuration tool will now search the database for schemas. 17. Enter the number that corresponds to the database schema used by InfoSphere CDC for metadata tables and press Enter. You can specify any schema except those in use by other installed instances of InfoSphere CDC for the given database. If the number of detected schemas is large, you will be offered the option of entering the schema name directly or you can press Enter to view the pages of schema names. You will not be asked for this information if you choose a read-only database.
Note: InfoSphere CDC metadata tables contain important configuration information and should be backed up as part of your database backup strategy. 18. If InfoSphere CDC detects an unsupported encoding, an error message will be displayed and you will be asked to choose an alternate encoding. a. Enter y to proceed.
Note: If you enter n and press Enter to cancel, the instance will not be created. b. Enter a value to choose how the alternate encodings will be displayed: v 1—Displays the available alternate encodings that are the closest match to the database. v 2—Displays the available alternate encodings in order of byte length. v 3—Displays all available alternate encodings. c. Enter the number for the encoding to be used and press Enter. 19. The configuration tool creates the InfoSphere CDC instance and prompts you to start the instance. Enter y to start the instance.
Note: The configuration tool will prompt you if your configuration is about to overwrite the metadata for an existing instance. Related concepts “Port requirements” on page 11 Related reference “dmconfigurets - Configure InfoSphere CDC” on page 95 “dmbackupmd - Backup Metadata” on page 94 To edit an instance of InfoSphere CDC (UNIX and Linux) 1. Stop InfoSphere CDC if it is started by using the dmshutdown command. You cannot edit an instance that is running. 2. At the command prompt, launch the configuration tool by issuing the following command from the
Configuring InfoSphere CDC (UNIX and Linux) 43 To delete an instance of InfoSphere CDC (UNIX and Linux) 1. Stop InfoSphere CDC if it is started by using the dmshutdown command. 2. At the command prompt, launch the configuration tool by issuing the following command from the
44 InfoSphere Change Data Capture: End-User Documentation Configuring InfoSphere CDC for Oracle databases for log shipping
You can configure InfoSphere CDC for Oracle databases to use copies of complete Oracle archive logs that are shipped to a secondary system that is accessible to InfoSphere CDC. If you decide to ship your logs, InfoSphere CDC latency is affected by the Oracle log switch frequency and the amount of time required to physically ship the logs to the remote destination. Latency may increase if the log switch interval and the log shipping time increase.
Once you have configured InfoSphere CDC for Oracle databases for log shipping, you ship the logs using one of two methods: by custom scripts or by Oracle's Data Guard component. If you send logs by developing a custom script (or set of scripts), the latency of InfoSphere CDC depends on when your scripts make these logs available to InfoSphere CDC. If you want to ship the log files using Oracle's Data Guard component, then Oracle will ship the logs for you and you will have to query the database to verify if the logs have been made available to the correct destination.
Once you have completed the configuration and shipping, ensure you restart theInfoSphere CDC instance installed on the source database.
See also: “To configure InfoSphere CDC for log shipping” “To ship logs using custom scripts” on page 46 “To ship logs using Oracle's Data Guard” on page 46
To configure InfoSphere CDC for log shipping 1. Set archive log mode to ON in your Oracle database. 2. Enable the oracle_archive_logs_only system parameter to true. InfoSphere CDC can only read archive logs if you want to ship your logs. 3. Enable the oracle_log_shipping system parameter to true so that InfoSphere CDC uses remote log shipping. 4. Modify the oracle_archive_dir system parameter to identify the local machine where you want to ship the logs. This is the machine where InfoSphere CDC is installed. Specify the full path of the destination. 5. If you want to override the default location where the archive logs will be read, then specify the fully qualified path to the Oracle archive log when you are shipping your archive logs. InfoSphere CDC only uses this value if you do not specify a Java class user exit in the oracle_log_path_userexit system parameter. 6. Ship the logs either using custom scripts or using Oracle's Data Guard component. 7. Restart the InfoSphere CDC instance installed on the source database so that the changes take effect. The system parameters that were used to configure log shipping are not dynamic.
© Copyright IBM Corp. 2008, 2011 45 Related tasks “To ship logs using custom scripts” “To ship logs using Oracle's Data Guard”
To ship logs using custom scripts 1. Enable the oracle_using_transport_services system parameter to true. 2. Modify the oracle_archive_destination_id by specifying the destination ID that Oracle Data Guard will use ship the logs. This destination must be in stand-by mode. 3. Query your database to verify if the logs were shipped to the correct database. Related tasks “To ship logs using Oracle's Data Guard”
To ship logs using Oracle's Data Guard 1. Physically ship the logs to the location specified by the oracle_archive_dir system parameter or the user exit. 2. Make the logs available to InfoSphere CDC by having the script issue the dmarchivelogavailable and dmarchivelogremoved commands. 3. Indicate which logs are no longer required by InfoSphere CDC by issuing the dmshowlogdependancy command. 4. Unregister the logs for InfoSphere CDC by issuing the dmarchivelogremoved command. 5. Purge the logs from the InfoSphere CDC system using a purge or cleanup application of your choice. Note that InfoSphere CDC does not clean up the logs from your system.
You can use this sample script as a guideline to check and remove archived logs from the InfoSphere CDC archived directory: # This script can check and remove archived logs from the InfoSphere CDC archived directory # Instructions: Need to maintain argument file "sub.lst" # All subscription name have to be listed in sub.lst file. # ./cdc_fil_remove.ksh > archived_log.lst
# ------
cdc_home=
46 InfoSphere Change Data Capture: End-User Documentation aan=’echo $aa | awk ’{print(substr($1,3))}’ | sed ’s/_..*//’’ if [ $aan -lt $nfl ] then echo "rm $cdc_arc$aa" else echo "No need to remove any files" fi done
You can use this sample script as a guideline to check and add archived logs to InfoSphere CDC: # This script can check and add the archived log into InfoSphere CDC. # Instructions:
# ------cdc_home=
Configuring InfoSphere CDC for Oracle databases for log shipping 47 48 InfoSphere Change Data Capture: End-User Documentation After you install and configure
Once you have installed and configured InfoSphere CDC, you can start using InfoSphere CDC.
In this section, you will learn: “Granting required privileges to Oracle users using SQL scripts in /samples directory” “Starting InfoSphere CDC” on page 53 “Stopping InfoSphere CDC” on page 53 “Maintaining active TCP connections in a network environment” on page 54 “Enabling SQL statements in Management Console” on page 55
Granting required privileges to Oracle users using SQL scripts in /samples directory After installing and configuring InfoSphere CDC, you must grant privileges to Oracle users created with your database. You must run the ora-createuser.sql script located in the /samples directory of your installation of InfoSphere CDC. If you have created a read-only user with your Oracle database, then you must grant required privileges for this user by running the ora-createuser-readonly.sql script.
See also: “Privileges for Oracle users” Privileges for Oracle users Use this chart to review the types of permissions that are required by Oracle users. After reviewing the permissions, you can proceed to install InfoSphere CDC and locate the required scripts that will grant these permissions in the /samples directory of your installation folder.
Permissions required by Permissions required by InfoSphere CDC for an Permissions InfoSphere CDC for an Oracle user with a Oracle user read-only connection to the source database Basic Roles grant connect to cdc_user; UU grant resource to cdc_user; UU grant select_catalog_role to UU cdc_user; Table DDL Permissions grant create any table to cdc_user; U grant alter any table to cdc_user; U grant drop any table to cdc_user; U grant lock any table to cdc_user; UU
© Copyright IBM Corp. 2008, 2011 49 Permissions required by Permissions required by InfoSphere CDC for an Permissions InfoSphere CDC for an Oracle user with a Oracle user read-only connection to the source database Table DML Permissions grant select any table to cdc_user; UU grant insert any table to cdc_user; U grant update any table to cdc_user; U grant delete any table to cdc_user; U Index and View DML Permissions grant create any index to cdc_user; U grant alter any index to cdc_user; U grant drop any index to cdc_user; U grant create any view to cdc_user; U grant drop any view to cdc_user; U Trigger DDL and DML Permissions grant create any trigger to cdc_user; U grant alter any trigger to cdc_user; U grant drop any trigger to cdc_user; U Sequence DDL and DML Permissions grant create any sequence to U cdc_user; grant select any sequence to U cdc_user; Procedure Permissions grant create any procedure to U cdc_user; grant execute any procedure to UU cdc_user; grant execute on UU sys.dbms_flashback to cdc_user; Procedure to perform v_$ on tables grant select any dictionary to UU cdc_user; General system views grant select on sys.v_$database to UU cdc_user with grant option; grant select on sys.v_$controlfile to UU cdc_user with grant option; grant select on sys.v_$version to UU cdc_user with grant option; grant select on UU sys.nls_database_parameters to cdc_user with grant option; Archive and redo logs
50 InfoSphere Change Data Capture: End-User Documentation Permissions required by Permissions required by InfoSphere CDC for an Permissions InfoSphere CDC for an Oracle user with a Oracle user read-only connection to the source database grant select on sys.v_$log to UU cdc_user with grant option; grant select on sys.v_$logfile to UU cdc_user with grant option; grant select on sys.v_$archived_log UU to cdc_user with grant option; grant select on sys.v_$log_history to UU cdc_user with grant option; Sessions and transactions grant alter session to cdc_user; UU grant select on sys.v_$session to UU cdc_user with grant option; grant select on sys.gv_$session to UU cdc_user with grant option; grant select on sys.v_$transaction to UU cdc_user with grant option; grant select on sys.v_$mystat to UU cdc_user with grant option; Tables, indexes, columns, and related views grant select on sys.all_coll_types to UU cdc_user with grant option; grant select on sys.all_type_attrs to UU cdc_user with grant option; grant select on sys.dba_tables to UU cdc_user with grant option; grant select on UU sys.dba_tab_comments to cdc_user; grant select on sys.dba_tab_columns UU to cdc_user with grant option; grant select on UU sys.dba_col_comments to cdc_user; grant select on UU sys.dba_tab_subpartitions to cdc_user; grant select on sys.dba_indexes to UU cdc_user with grant option; grant select on sys.dba_ind_columns UU to cdc_user with grant option; grant select on sys.all_constraints to UU cdc_user with grant option; grant select on sys.dba_constraints UU to cdc_user with grant option; grant select on sys.all_cons_columns UU to cdc_user with grant option;
After you install and configure 51 Permissions required by Permissions required by InfoSphere CDC for an Permissions InfoSphere CDC for an Oracle user with a Oracle user read-only connection to the source database grant select on UU sys.dba_cons_columns to cdc_user with grant option; grant select on sys.tab$ to cdc_user UU with grant option; grant select on sys.ind$ to cdc_user UU with grant option; grant select on sys.lob$ to cdc_user UU with grant option; grant select on sys.col$ to cdc_user UU with grant option; grant select on sys.icol$ to cdc_user UU with grant option; grant select on sys.coltype$ to UU cdc_user with grant option; grant select on sys.attrcol$ to UU cdc_user with grant option; grant select on sys.ccol$ to cdc_user UU with grant option; grant select on sys.cdef$ to cdc_user UU with grant option; Miscellaneous other objects grant select on sys.obj$ to cdc_user UU with grant option; grant select on sys.dba_mviews to UU cdc_user with grant option; grant select on sys.dba_objects to UU cdc_user with grant option; grant select on sys.dba_sequences to UU cdc_user with grant option; grant select on sys.hist_head$ to UU cdc_user with grant option; grant select on sys.resource_cost to UU cdc_user with grant option; Storage grant select on sys.dba_tablespaces U to cdc_user with grant option; grant select on U sys.dba_rollback_segs to cdc_user with grant option; Permissions grant select on sys.dba_users to UU cdc_user with grant option; grant select on sys.dba_sys_privs to UU cdc_user;
52 InfoSphere Change Data Capture: End-User Documentation Permissions required by Permissions required by InfoSphere CDC for an Permissions InfoSphere CDC for an Oracle user with a Oracle user read-only connection to the source database grant select on sys.dba_tab_privs to UU cdc_user; grant select on sys.dba_profiles to UU cdc_user with grant option; grant select on sys.dba_roles to UU cdc_user with grant option; grant select on sys.user$ to cdc_user UU with grant option; grant select on user_role_privs to UU cdc_user with grant option; grant flashback any_table to U cdc_user with grant option;
Starting InfoSphere CDC After you install InfoSphere CDC on a supported UNIX or Linux server, you can issue a command to start it so that you can create a datastore for the instance in Management Console. You can also start the instance by using the configuration tool.
See also: “To start InfoSphere CDC (UNIX and Linux)” To start InfoSphere CDC (UNIX and Linux)
Depending on the operating system you are running, issue one of the following start commands: v dmts32-I
Stopping InfoSphere CDC 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 (UNIX and Linux)” To stop InfoSphere CDC (UNIX and Linux) 1. End replication on all subscriptions in Management Console. For more information on how to end replication on subscriptions, see your Management Console documentation.
After you install and configure 53 2. Depending on how you want to stop InfoSphere CDC, issue one of the following stop commands in the bin directory in your InfoSphere CDC installation directory:
Option Description dmshutdown [-I
If you have multiple active InfoSphere CDC installations on the same UNIX or Linux server, and you want to shut them all down, run this command from the installation directory for each InfoSphere CDC instance. dmterminate [-L
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” To maintain active TCP connections 1. For each instance of InfoSphere CDC, navigate to the following directory: UNIX or Linux:
InfoSphere CDC will now send messages over the TCP connection every 10 seconds.
54 InfoSphere Change Data Capture: End-User Documentation 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” 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. Related concepts “Metadata tables” on page 57
After you install and configure 55 56 InfoSphere Change Data Capture: End-User Documentation 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: v DRSESSIONHISTORY v TS_AUTH
Note: 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. For more information on how to add users in the Access Manager perspective in Management Console. For more information, see your Management Console documentation. v TS_BOOKMARK v TS_CONFAUD—The conflict resolution audit table records information about conflicts that were resolved using conflict detection and resolution. Related concepts “Configuring InfoSphere CDC (UNIX and Linux)” on page 41
© Copyright IBM Corp. 2008, 2011 57 58 InfoSphere Change Data Capture: End-User Documentation Data types supported by InfoSphere CDC
For information about data types supported by InfoSphere CDC, see Supported data types in the Management Console Administration Guide.
© Copyright IBM Corp. 2008, 2011 59 60 InfoSphere Change Data Capture: End-User Documentation Commands for InfoSphere CDC
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 commands” “Setting the TSINSTANCE environment variable” on page 62 “Continuous Capture commands” on page 62 “Controlling replication commands” on page 63 “Database transaction log commands” on page 71 “Supplemental logging commands” on page 80 “Single scrape and staging store commands” on page 81 “Exporting and importing configuration commands” on page 82 “Managing tables for replication commands” on page 84 “Monitoring replication commands” on page 90 “Other commands” on page 94
Using the InfoSphere CDC commands You can issue InfoSphere CDC commands at a command line prompt or as part of a batch file or shell script. Commands are case-sensitive in UNIX environments and 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: v Syntax—Identifies the name of the command and lists the command parameters. v Parameters—Describes each parameter in the command and identifies the values that can be specified. v 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. v Examples—Provides one or more examples of invoking the command. Parameter formats
Note the following conventions in the definition of the command parameters: v Angle brackets(<>)indicate a mandatory parameter. v Square brackets([])indicate an optional parameter. If you omit the parameter, InfoSphere CDC uses a default value.
© Copyright IBM Corp. 2008, 2011 61 v 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. v Ellipsis ( ... ) means that a parameter or option can be repeated more than once. v You can issue the commands in UNIX or Linux.
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. UNIX or Linux
The following command is for kshell. You can run similar commands in other shells: export TSINSTANCE=
where: v
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” on page 63 “dmenablecontinuouscapture - Enable Continuous Capture” on page 63
62 InfoSphere Change Data Capture: End-User Documentation dmdisablecontinuouscapture - Disable Continuous Capture
Use this command to disable Continuous Capture for your staging store. Syntax dmdisablecontinuouscapture [-I
Parameters -I
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
Controlling replication commands This section contains commands that control replication in InfoSphere CDC.
See also: “dmendreplication - End replication” on page 64 “dmrefresh - Refresh subscription” on page 67 “dmstartmirror - Start mirroring” on page 68
Commands for InfoSphere CDC 63 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: v Initiating a database backup. v Performing a regularly scheduled reboot of your source database server. v Quiescing your database in preparation for an upgrade. v Weekly batch processing has just completed. v 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: v -se parameter—When specified without –t or –p, this parameter ends replication at the current time in the source database log. v -t parameter—When specified with –se, this parameter ends replication at a user-specified date and time. v -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 desired 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: v Adding a table mapping to the subscription. v Deleting a table mapping from the subscription. v Temporarily removing a table mapping from the subscription (parking a table).
64 InfoSphere Change Data Capture: End-User Documentation v Modifying mapping details such as source and target column mappings, derived columns, data translations, row and column selections, user exits, and so on. v 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 Management Console – Administration Guide.
To stop an instance after ending replication on all subscriptions, use the dmshutdown command. Syntax dmendreplication [-I
Parameters -I
Attention: Use this option if business reasons require replication to end faster than -c at the expense of a slower start when you resume replication on the specified subscriptions. -a Specifies that InfoSphere CDC ends replication on the specified subscriptions with the Abort option.
Commands for InfoSphere CDC 65 This option stops all in progress work and then ends replication rapidly. Starting replication after using this option can be much slower than using -c. A refresh in progress will be interrupted and the target will stop processing any data that has not been committed before replication ends. You should ensure that all dependent source database logs are available before ending replication using the Abort option. InfoSphere CDC may need to reprocess all the dependent source logs when you restart the subscription. If InfoSphere CDC is currently processing a long running transaction when you end replication with Abort, InfoSphere CDC may have to resume replication from the earliest open transaction in the database logs. Use the dmshowlogdependency command to determine which logs are required.
Attention: Use this option if your business reasons require a rapid end to replication and you are willing to tolerate a much slower start when you resume replication on the specified subscriptions. A sudden business requirement for an unplanned shutdown of your source system may require this option for ending replication. -se Specifies that InfoSphere CDC will end replication normally at the current source system time in the source database log with the Scheduled End option. The source system time when replication will end is set when you issue this command. If you specify the following parameters with -se, replication will end at a specific date and time or log position: v –t—End replication at a specific date and time in your source database log. v –p—End replication at a specific log position in your source database log.
Note: As latency between the source and target increases, the amount of time required to end replication will also increase. -t
Note: This parameter does not apply if you specify –c, -i,or–a. InfoSphere CDC will always wait if you specify –c, -i,or–a when ending replication.
66 InfoSphere Change Data Capture: End-User Documentation -nw Indicates that this command will not wait for replication to end if you specify -se. If you are scripting this command, this parameter allows your script to continue executing (asynchronous) if -se processing is not complete. -A Indicates that InfoSphere CDC ends replication on all subscriptions. Use –s to end replication on one or more subscriptions. -s
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 FINANCE
InfoSphere 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. 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.
Commands for InfoSphere CDC 67 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
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 FINANCE
InfoSphere CDC refreshes all target tables in the Finance subscription. 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.
68 InfoSphere Change Data Capture: End-User Documentation 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: v -n parameter—When specified without –tor –p, this parameter ends replication at the current time in the source database log. v -t parameter—When specified with –n, this parameter ends replication at a user-specified date and time. v -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.
For more information about starting and ending replication in InfoSphere CDC, see InfoSphere CDC – Administration Guide. 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
Commands for InfoSphere CDC 69 -p
This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples
dmstartmirror -I MYINSTANCE -c -s FINANCE
InfoSphere 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 -nw
70 InfoSphere Change Data Capture: End-User Documentation InfoSphere 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.
Database transaction log commands This section contains commands that help you manage your database transaction log or bookmarks.
See also: “dmarchivelogavailable - Mark archive log as available” “dmarchivelogremoved - Mark archive log as removed” on page 72 “dmdecodebookmark - Display verbose information bookmark” on page 73 “dmsetbookmark - Set bookmark” on page 74 “dmshowbookmark - Display bookmark information” on page 75 “dmshowlogdependency - Show Log Dependency” on page 78 dmarchivelogavailable - Mark archive log as available
Note: You do not need to run this command if you are using Oracle Data Guard to ship your archived logs. This command is only necessary if you are using scripts or some other method to ship your archived logs to a secondary system that is accessible to InfoSphere CDC.
Use this command only after the complete Oracle archive log file has been shipped from the system where your Oracle database is installed. By issuing this command, you are indicating to InfoSphere CDC that the shipped Oracle archive log file is complete and can now be used for replication.
If your production database is in an Oracle RAC environment and the thread ID is not included in the archive log file name, you must do the following: v Specify the thread ID in the -t
Note: This command will return a warning message if you add a file out of order, but will still mark the log as available. Syntax dmarchivelogavailable [-I
Parameters -I
Commands for InfoSphere CDC 71 -f
This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples
dmarchivelogavailable -t 1 -f /archivelog/arch_1_22781.arc
Indicates to InfoSphere CDC that archive log arch_1_22781.arc with thread ID 1 is now available for replication.
dmarchivelogavailable -t 1 -f /archivelog/arch_1_22782.arc
Indicates to InfoSphere CDC that archive log arch_1_22782.arc with thread ID 1 is now available for replication. Related reference “dmarchivelogremoved - Mark archive log as removed” “dmshowlogdependency - Show Log Dependency” on page 78 dmarchivelogremoved - Mark archive log as removed
Note: You do not need to run this command if you are using Oracle Data Guard to ship your archived logs. This command is only necessary if you are using scripts or some other method to ship your archived logs to a secondary system that is accessible to InfoSphere CDC.
Use this command to specify the shipped Oracle archive logs that are no longer used by InfoSphere CDC. You should run this command before removing a shipped Oracle archive log. Syntax dmarchivelogremoved [-I
Parameters -I
72 InfoSphere Change Data Capture: End-User Documentation Result
This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Example
dmarchivelogremoved -f /archivelog/arch_1_22781.arc -a
Indicates that archive log arch_1_22781.arc and all previous logs are no longer required by InfoSphere CDC for replication and can be removed from the directory for shipped archive logs. Related reference “dmarchivelogavailable - Mark archive log as available” on page 71 “dmshowlogdependency - Show Log Dependency” on page 78 dmdecodebookmark - Display verbose information bookmark
Use this command to display verbose information about a bookmark. Syntax dmdecodebookmark [-I
Parameters -I
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.txt
InfoSphere CDC displays information about the bookmark stored in the bookmark.txt file.
Commands for InfoSphere CDC 73 dmsetbookmark - Set bookmark
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. More information on the InfoSphere CDC stream of change data is provided in the following paragraphs.
InfoSphere CDC parses the data from your database logs and creates a stream of change data to process on the source and eventually apply on the target. The stream of change data is sorted in the order in which the data was committed in the source database, whereas the data in your database logs is sorted in the order in which the individual action was done in the source database.
For example, two transactions named T1 and T2 may be ordered like this in your source database log: T1: Insert1 T2: Insert1 T2: Insert2 T2: Commit T1: Commit
As you can see, data is sorted in the database log according to when the individual action was done in your source database.
However, the InfoSphere CDC stream of change data will order the two transactions like this: T2: Insert1 T2: Insert2 T2: Commit T1: Insert1 T1: Commit
Data is sorted according to when the data is committed in your source database. Syntax dmsetbookmark [-I
Parameters -I
74 InfoSphere Change Data Capture: End-User Documentation indicated replication position. The replication position is a hexadecimal-encoded string that is obtained from the dmshowbookmark command. -l
Note: If your source database is DB2® for LUW and is configured for DPF, you can generate the XML file used by this parameter by using the dmshowbookmark command on your InfoSphere CDC target with the -x parameter. -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
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 FINANCE
InfoSphere 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 FINANCE
InfoSphere 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. dmshowbookmark - Display bookmark information
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
Commands for InfoSphere CDC 75 the dmsetbookmark command on the source system to set the replication position for a subscription. More information on the InfoSphere CDC stream of change data is provided in the following paragraphs.
InfoSphere CDC parses the data from your database logs and creates a stream of change data to process on the source and eventually apply on the target. The stream of change data is sorted in the order in which the data was committed in the source database, whereas the data in your database logs is sorted in the order in which the individual action was done in the source database.
For example, two transactions named T1 and T2 may be ordered like this in your source database log: T1: Insert1 T2: Insert1 T2: Insert2 T2: Commit T1: Commit
As you can see, data is sorted in the database log according to when the individual action was done in your source database.
However, the InfoSphere CDC stream of change data will order the two transactions like this: T2: Insert1 T2: Insert2 T2: Commit T1: Insert1 T1: Commit
Data is sorted according to when the data is committed in your source database.
Note: This command may be temporarily unable to return a value if it is issued while InfoSphere CDC is applying a DDL change. The command will return an error code when this occurs. Syntax dmshowbookmark [-I
Parameters -I
76 InfoSphere Change Data Capture: End-User Documentation You can specify an absolute path for the location where you want to create the file. If you do not specify an absolute path, the file is created in the InfoSphere CDC installation directory. Use the -f parameter in the dmsetbookmark command to read the binary file generated by this parameter.
Note: Use the -x parameter if you are issuing this command from the target of a DB2 for LUW DPF source environment. -x
Note: Use the -x parameter if you are issuing this command from the target of a DB2 LUW DPF source environment. -L
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 bookmark
InfoSphere 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 mybookmarks
InfoSphere 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.
Commands for InfoSphere CDC 77 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: v A list of all the logs that are required for the specified instance. If you are shipping your archive logs, a log status is also displayed. v A list of the required logs that are missing and are required by the specified instance. If you are shipping your archive logs, a log status is also displayed. v The earliest open transaction in the log for the specified instance. v The logs which contain the position confirmed by the target database for the specified instance. v 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
78 InfoSphere Change Data Capture: End-User Documentation -l Displays the source database log which contains the position InfoSphere CDC is reading from. If you specify -A, the command considers all subscriptions and displays the oldest log. If you specify -s, the command displays the log for the specified subscription. If you decide to use-a, then the command displays one log for each subscription. Each log contains the position for the corresponding subscription. -m Displays a list of source database logs that are missing for the specified instance and are required for replication. These logs must be restored before you can start replication. If no logs are missing, the output will display 'OK' which you can parse with a script or batch file. If you specify -A, the command considers all subscriptions and displays a list of logs that are missing for at least one of the subscriptions. If you specify -s, the command displays a list of logs that are missing for the specified subscription. If you decide to use -a, then the command displays a list of logs that are missing for each individual subscription. Each list contains logs that are missing for the corresponding subscription. The path to the archive log will be displayed if you are shipping your archive logs. This parameter will display the following log status information if you are shipping your archive logs: v Available/Not Available—Status that indicates whether or not the archive log file is available. You must run the dmarchivelogavailable command to make archive logs available to InfoSphere CDC. v Exists/Missing—Status that indicates whether the log file exists or is missing. If a log file is missing, you will have to adjust your log shipping process. -s
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 MYSUBSCRIPTIONNAME
Displays the complete list of required source database logs for the specified instance and subscription. dmshowlogdependency -I MYINSTANCE -m -A
Commands for InfoSphere CDC 79 Displays the complete list of source database logs that are missing for all subscriptions in the specified instance. Related reference “dmarchivelogavailable - Mark archive log as available” on page 71 “dmarchivelogremoved - Mark archive log as removed” on page 72
Supplemental logging commands This section contains commands that help you understand the database supplemental logging level required by InfoSphere CDC for Oracle databases
These commands are useful if you are planning to replicate Data Definition Language (DDL) changes.
See also: “dmshowsupplementalloggingdependency - Show supplemental logging dependency” “dmreducesupplementalloggingdependency - Reduce supplemental logging dependency” on page 81 dmshowsupplementalloggingdependency - Show supplemental logging dependency
Use this command to display information about the supplemental logging level currently required by InfoSphere CDC for Oracle databases.
Supplemental logging must be enabled at the database level if you are planning to replicate DDL changes.
With this command, you can view the following information: v The dependency that the instance has on supplemental logging v If the supplemental logging level dependency can or cannot be reduced
You must issue this command on your InfoSphere CDC for Oracle databases source system. Syntax dmshowsupplementalloggingdependency [-I
Parameters -I
80 InfoSphere Change Data Capture: End-User Documentation dmreducesupplementalloggingdependency - Reduce supplemental logging dependency
Use this command to reduce the supplemental logging levels required by InfoSphere CDC.
This command is useful if you are no longer planning to replicate DDL changes and you wish to reduce your database supplemental logging level.
Do not reduce the database supplemental logging before you reduce the supplemental logging dependency in InfoSphere CDC.
Note: this command will not reduce the database level of supplemental logging, but will enable you to do so without impact on InfoSphere CDC.
You must issue this command on your InfoSphere CDC source system. Syntax dmreducesupplementalloggingdependency [-I
Parameters -I
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” on page 82 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
Commands for InfoSphere CDC 81 Parameters -I
This command returns a value of 0 if the operation was successful. If it fails, this command returns a non-zero value. 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
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” on page 83 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. For more information, see your Management Console documentation.
82 InfoSphere Change Data Capture: End-User Documentation Note: This command is interactive and will prompt you for your password. You cannot script this command. Syntax dmexportconfiguration
Parameters
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.xml
InfoSphere CDC exports the XML file to the specified absolute path. Related reference “dmimportconfiguration - Import InfoSphere CDC Configuration” 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.
Note: You can script this command and use an InfoSphere CDC silent installation to deploy InfoSphere CDC on multiple systems. Syntax dmimportconfiguration
Parameters
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
Commands for InfoSphere CDC 83 InfoSphere CDC imports the XML configuration file from the specified absolute path. Related reference “dmexportconfiguration - Export InfoSphere CDC Configuration” on page 82
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” on page 85 “dmmarktablecapturepoint - Mark a table capture point on a source table” on page 85 “dmpark - Park table” on page 87 “dmreaddtable - Update source table definition” on page 87 “dmreassigntable - Update target table definition” on page 88 “dmsetreplicationmethod - Set replication method” on page 89 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
This command returns a value of 0 if the command was successful and a non-zero value if the command fails.
84 InfoSphere Change Data Capture: End-User Documentation Examples
dmdescribe -I NEWINSTANCE -s FINANCE
InfoSphere CDC sends source metadata changes in the Finance subscription over to the target for the specified instance. 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 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 -A InfoSphere CDC flags for refresh all source tables in the Finance subscription for the specified instance. 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. Commands for InfoSphere CDC 85 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 This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmmarktablecapturepoint -I MYINSTANCE -s FINANCE -A InfoSphere CDC sets the status of all tables in the Finance subscription to Active. dmmarktablecapturepoint -I MYINSTANCE -s ACCOUNTING -A -t myschema.mytable InfoSphere CDC sets the status of the specified table in the Accounting subscription to Active. 86 InfoSphere Change Data Capture: End-User Documentation 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 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 -A InfoSphere CDC parks all source tables in the Finance subscription. Related reference “dmendreplication - End replication” on page 64 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. Commands for InfoSphere CDC 87 Note: This command will set the table status to Parked after updating the source table definition in the InfoSphere CDC metadata. With an InfoSphere CDC for Oracle databases source, you can use the -a parameter to preserve the Active status for your tables. Syntax dmreaddtable [-I Parameters -I 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 -A InfoSphere CDC updates definitions for all source tables that are available for replication. The status for all tables will be set to Parked. dmreaddtable -I NEWINSTANCE -A -a InfoSphere CDC updates definitions for all source tables that are available for replication and all tables will retain an Active status. 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. 88 InfoSphere Change Data Capture: End-User Documentation Syntax dmreassigntable [-I Parameters -I 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 -A InfoSphere 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. 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 Commands for InfoSphere CDC 89 Parameters -I 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 -A All 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.taxcodes The source table acct.taxcodes in the Finance subscription will use Mirror as the replication method in the specified InfoSphere CDC instance. Monitoring replication commands This section contains commands that help you monitor replication in InfoSphere CDC. See also: “dmclearevents - Clear events” “dmgetsubscriptionstatus - Get subscription status” on page 91 “dmshowevents - Display InfoSphere CDC events” on page 92 dmclearevents - Clear events Use this command to delete events from the Event Log view in Management Console. 90 InfoSphere Change Data Capture: End-User Documentation Syntax dmclearevents [-I Parameters -I 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 -A InfoSphere CDC clears events from the source for all subscriptions for the specified instance. dmclearevents -I MYINSTANCE -T -s FINANCE MARKETING InfoSphere CDC clears events from both the source and target for the Finance and Marketing subscriptions for the specified instance. dmgetsubscriptionstatus - Get subscription status Issue this command on the InfoSphere CDC source to retrieve status information for one or more subscriptions and send the results to standard output. Syntax dmgetsubscriptionstatus [-I Parameters -I Commands for InfoSphere CDC 91 -p Specifies that InfoSphere CDC sends status information to standard output. -A Specifies that InfoSphere CDC retrieves status information for all subscriptions. -s This command returns one of the following statuses for each subscription: v Recovering—The subscription is in an undetermined state. v Idle—The subscription is not running. v Starting—The subscription is in start up mode and is not currently replicating data. v Running—The subscription is running and replicating data. Examples dmgetsubscriptionstatus -I MYINSTANCE -p -A InfoSphere CDC retrieves status information for all subscriptions and sends the results to standard output for the specified instance. 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 or dmshowevents -I Parameters -I 92 InfoSphere Change Data Capture: End-User Documentation -t This command returns a value of 0 if the operation was successful. If it fails, this command returns a non-zero value. Examples dmshowevents -I NEWINSTANCE -s FINANCE InfoSphere CDC displays all events for the Finance subscription for the specified instance. dmshowevents -I MYINSTANCE –a –h InfoSphere 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 20 InfoSphere 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. Commands for InfoSphere CDC 93 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. 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 - Backup Metadata” “dmconfigurets - Configure InfoSphere CDC” on page 95 “dmmdcommander” on page 95 “dmmdconsole” on page 95 “dmset - Set InfoSphere CDC system parameter” on page 95 “dmshowversion - Show InfoSphere CDC version” on page 96 “dmshutdown - Shut down InfoSphere CDC” on page 96 “dmsupportinfo - Collect IBM Support information” on page 99 “dmterminate - Terminate InfoSphere CDC processes” on page 100 “dmts32 - Start InfoSphere CDC” on page 100 “dmts64 - Start InfoSphere CDC” on page 101 “dmverifycommunications” on page 101 dmbackupmd - Backup 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 Parameters -I 94 InfoSphere Change Data Capture: End-User Documentation -L This command returns a value of 0 if the command was successful and a non-zero value if the command fails. 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. Syntax dmconfigurets [-L Parameters -L This command returns a value of 0 if the command was successful and a non-zero value if the command fails. dmmdcommander This command is for internal use only. dmmdconsole This command is for internal use only. 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. For more information, see your Management Console documentation. 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 Commands for InfoSphere CDC 95 This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmset -I MYINSTANCE Displays all of the system parameters that are set to non-default values. dmset -I MYINSTANCE global_unicode_as_char=false Sets the global_unicode_as_char system parameter to false. dmset -I MYINSTANCE global_unicode_as_char Displays the current value of the specified parameter. dmset -I MYINSTANCE stop_replication= Deletes the stop_replication system parameter. 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 This command returns a value of 0 if the operation was successful. If it fails, this command returns a non-zero value. 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. 96 InfoSphere Change Data Capture: End-User Documentation 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. Syntax dmshutdown [-I Parameters -I Attention: Use this option if business reasons require replication to end faster than -c at the expense of a slower start when you resume replication on the specified subscriptions. -a Specifies that InfoSphere CDC stops the specified instance and ends replication on all subscriptions that use the instance as a source or target with the Abort option. Subscriptions that use the specified instance as a target will end replication with an error. This option stops all in progress work and then ends replication rapidly. Starting replication after using this option can be much slower than using -c. A refresh in progress will be interrupted and the target will stop processing any data that has not been committed before replication ends. Commands for InfoSphere CDC 97 Attention: Use this option if your business reasons require a rapid end to replication and you are willing to tolerate a much slower start when you resume replication on the specified subscriptions. A sudden business requirement for an unplanned shutdown of your source system may require this option for ending replication. Note: As a best practice, use the dmendreplication command to end replication on all subscriptions that use the instance specified in this command as a source or target. -se Specifies that InfoSphere CDC will stop the specified instance and end replication normally at the current source system time in the source database log with the Scheduled End option. Replication will end on subscriptions that use the specified instance as a source. The source system time when replication will end is set when you issue this command. You can use the following parameters with this option to end replication at a specific date and time or log position: v –t—Stop the instance and end replication at a specific date and time in your source database log. v –p—Stop the instance and end replication at a specific log position in your source database log. Note: As latency between the source and target increases, the amount of time required to end replication will also increase. -t This command returns a value of 0 if the command was successful and a non-zero value if the command fails. 98 InfoSphere Change Data Capture: End-User Documentation Related reference “dmterminate - Terminate InfoSphere CDC processes” on page 100 dmsupportinfo - Collect IBM Support information Note: You should only run this command when the Management Console Support Assistant cannot connect to your InfoSphere CDC datastore because it is not running or it will not run. For more information on the Support Assistant, see Management Console - Administration Guide. 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 Note: As a best practice, specify a date and time range that only captures the time period when you experienced problems. This allows for easier problem diagnosis and reduces the size of the files retrieved. -L 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 Commands for InfoSphere CDC 99 issues with this instance of InfoSphere CDC. Related concepts “Troubleshooting and contacting IBM Support” on page 117 dmterminate - Terminate InfoSphere CDC processes Note: This command is only supported on the UNIX and Linux platforms. Use this command to terminate all InfoSphere CDC processes for all instances running on a UNIX or Linux server that you cannot completely shut down with the dmshutdown command. InfoSphere CDC terminates only processes that are started by the UNIX account used to run this command. You can use this command prior to taking a server or database offline for maintenance purposes or upgrading InfoSphere CDC to the latest version. Use the dmshutdown command to gracefully shut down InfoSphere CDC. If dmshutdown is unable to completely shut down InfoSphere CDC, then use dmterminate to terminate any active InfoSphere CDC processes that still remain after issuing dmshutdown. Syntax dmterminate [-L Parameters -L This command returns a value of 0 if the command was successful and a non-zero value if the command fails. dmts32 - Start InfoSphere CDC Use this command to start a 32-bit instance of InfoSphere CDC. Syntax dmts32 [-I Parameters -I This command returns a value of 0 if the command was successful and a non-zero value if the command fails. 100 InfoSphere Change Data Capture: End-User Documentation Examples dmts32 -I -MYINSTANCE InfoSphere CDC starts for the specified instance. dmts64 - Start InfoSphere CDC Use this command to start a 64-bit instance of InfoSphere CDC. Syntax dmts64 [-I Parameters -I This command returns a value of 0 if the command was successful and a non-zero value if the command fails. Examples dmts64 -I MYINSTANCE InfoSphere CDC starts for the specified instance. dmverifycommunications This command is for internal use only. Commands for InfoSphere CDC 101 102 InfoSphere Change Data Capture: End-User Documentation User exits for InfoSphere CDC 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. For more information, see your Management Console documentation. InfoSphere CDC provides two types of user exits: v Stored procedure—This type of user exit is run directly by the database engine and is generally faster at processing database requests. v Java class—This type of user exit utilizes the InfoSphere CDC API. Javadocs with interface and class specifications for the API are installed with the product. The Javadocs are located in / 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” on page 111 “InfoSphere CDC API reference – Javadocs” on page 112 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” on page 104 “Retrieving data with a stored procedure user exit” on page 104 “Example of a stored procedure user exit” on page 110 Defining a stored procedure user exit When defining a stored procedure user exit in InfoSphere CDC, consider the following: v Overloaded stored procedures are not supported. v Stored procedure user exits must have at least two parameters, which must be the first two defined in the following order: © Copyright IBM Corp. 2008, 2011 103 – 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. Related reference “Example of a stored procedure user exit” on page 110 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. 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: v 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. v 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. v 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: v For InfoSphere CDC, the format is where See also: “Retrieving system values using the s$ prefix” “Retrieving journal control fields using the j$ prefix” on page 106 “Retrieving data values using b$, a$, k$, and d$ prefixes” on page 108 Retrieving system values using the s$ prefix This prefix is used to retrieve system values. The table below presents and briefly describes these values. 104 InfoSphere Change Data Capture: End-User Documentation Prefix and Value Data Type Description 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: v 1—indicates that InfoSphere CDC has invoked the stored procedure before a table clear (truncate) operation v 2—indicates that InfoSphere CDC has invoked the stored procedure after a table clear (truncate) operation v 3—indicates that InfoSphere CDC has invoked the stored procedure before a row insert operation v 4—indicates that InfoSphere CDC has invoked the stored procedure after a row insert operation v 5—indicates that InfoSphere CDC has invoked the stored procedure before a row update operation v 6—indicates that InfoSphere CDC has invoked the stored procedure after a row update operation v 7—indicates that InfoSphere CDC has invoked the stored procedure before a row delete operation v 8—indicates that InfoSphere CDC has invoked the stored procedure after a row delete operation v 9—indicates that InfoSphere CDC has invoked the stored procedure before a table refresh operation v 10—indicates that InfoSphere CDC has invoked the stored procedure after a table refresh operation User exits for InfoSphere CDC 105 Prefix and Value Data Type Description 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. 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 j$CNTRRN VARCHAR Identifies the relative 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. 106 InfoSphere Change Data Capture: End-User Documentation Prefix and Value Data Type Description j$ENTT or j$ENTTYP VARCHAR Generates journal or log codes that identify the operation type on the source system. 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 j$PROGRAM VARCHAR Identifies the name of 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 j$SYSTEM VARCHAR Identifies the host 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. j$TSTP or j$TIMSTAMP VARCHAR Identifies the date 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. User exits for InfoSphere CDC 107 Retrieving data values using b$, a$, k$, and d$ prefixes Four prefixes are used to retrieve data: Prefix Mode Description b$ For example, you may have made the following UPDATE to your source table: UPDATE source_table set MYCOLUMN = 2 where MYCOLUMN = 1; This will set 2 on all rows where MYCOLUMN was 1 before the execution of this SQL statement. When you define a stored procedure and decide that you want the stored procedure to retrieve the before image of MYCOLUMN, you would specify the following: b$MYCOLUMN; This returns a value of 1. 108 InfoSphere Change Data Capture: End-User Documentation Prefix Mode Description a$ For example, you may have made the following UPDATE to your source table: UPDATE source_table set MYCOLUMN = 2 where MYCOLUMN = 1; This will set 2 on all rows where MYCOLUMN was 1 before the execution of this SQL statement. When you define a stored procedure and decide that you want the stored procedure to retrieve the after image of MYCOLUMN, you would specify the following: a$MYCOLUMN; This returns a value of 2. k$ User exits for InfoSphere CDC 109 Example of a stored procedure user exit The following code snippet is an example of a stored procedure user exit. Code Comments create or replace procedure The parameters you declare and want to pass to your PROD.AUDIT_STPROC ( stored procedure must be valid data types. result OUT INT, returnMsg OUT CHAR, The following parameters are mandatory and must be s$entry IN NUMBER, declared in your stored procedure: s$srcSysId IN CHAR, v s$srcTabId IN CHAR, result—Returns a value of '0' if the stored procedure user s$tgtTabId IN CHAR, exit is successful. If the stored procedure user exit is not j$ENTT IN CHAR, successful it will return a non-zero value and a message a$IDNO IN NUMBER, will be sent to the Event Log. a$PRICE IN NUMBER, v returnMsg—Returns an error message to the Event Log a$DESC IN CHAR, if the stored procedure is not successful. a$LONGDESC IN CHAR, a$TRANSDATE IN DATE, The following parameters have been declared in this stored d$IDNO IN NUMBER, d$PRICE IN NUMBER, procedure: d$DESC IN CHAR, v s$entry—Retrieves the entry point at which the stored d$LONGDESC IN CHAR, procedure was called. In this example, InfoSphere CDC d$TRANSDATE IN DATE calls the user exit at every entry point. ) v s$srcSysId—Retrieves the location of source data. v s$srcTabId—Retrieves the name of the source table. v s$tgtTabId—Retrieves the name of the target table. v j$ENTT—Retrieves the journal code that indicates the type of operation on the source table. v a$—Retrieves the after image of the IDNO, PRICE, DESC, LONGDESC, and TRANSDATE source columns. v d$—Retrieves the transformed data of the IDNO, PRICE, DESC, LONGDESC, and TRANSDATA target columns. IS This stored procedure user exit can be invoked from these ENTRYPOINT VARCHAR(50); entry points. BEGIN CASE s$entry WHEN 16 THEN ENTRYPOINT := ’User Exit program called Before Insert’; WHEN 1048576 THEN ENTRYPOINT := ’User Exit program called After Insert’; WHEN 64 THEN ENTRYPOINT := ’User Exit program called Before Update’; WHEN 4194304 THEN ENTRYPOINT := ’User Exit program called After Update’; END CASE; insert into PROD.AUDIT_TABLE1 This stored procedure user exit will INSERT these values values ( into PROD.AUDIT_TABLE1. s$entry, s$srcSysId, s$srcTabId, s$tgtTabId, j$ENTT, a$IDNO, a$PRICE, a$DESC, a$LONGDESC, a$TRANSDATE, d$IDNO, d$PRICE, d$DESC, d$LONGDESC, d$TRANSDATE, ENTRYPOINT); result := 0; This stored procedure user exit is successful and returns a returnMsg := ’OK’; '0' value. END AUDIT_STPROC; 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. 110 InfoSphere Change Data Capture: End-User Documentation Sample Java class user exits for InfoSphere CDC 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: v ArchiveLogPathUserExitSample.java—returns the fully qualified path (including file name and extension) to the Oracle archive log file. This sample is located in com.datamirror.ts.target.publication.userexit.sample. v 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. v 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. v 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. v 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. v 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: v 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. v 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. v If you want to modify the sample user exits, you must compile the user exit after you make changes to the source code. v The user exit class must also be in your 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 (UNIX and Linux)” To compile the sample Java class user exits (UNIX and Linux) 1. Stop InfoSphere CDC. 2. Unzip the samples.jar file into the lib directory in your InfoSphere CDC installation directory. Make sure you maintain the directory structure when unzipping the jar file. After unzipping the jar file, you will have a directory structure like the following: User exits for InfoSphere CDC 111 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: Note: Do not specify the .class extension. For more information on how to specify Java class user exits in Management Console, see your Management Console documentation. Note: If you plan to use the sample user exits in production environments, you will have to test the samples before they are deployed. IBM does not assume responsibility for adverse results caused by modified or customized user exit classes. 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: v UNIX and Linux— 112 InfoSphere Change Data Capture: End-User Documentation 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. In this section, you will learn: “Structure of the conflict resolution audit table” “Row image format” on page 115 “Truncated images” on page 115 “Unaudited data types” on page 115 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. For more information, see your Management Console documentation. 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: v 1—Inserted into the source table. v 2—Updated on the source table. v 3—Deleted from the source table. © Copyright IBM Corp. 2008, 2011 113 Column Description CNFTYPE The type of conflict that was detected. The value is one of: v 1—Inserted into the source table. The key for that row already exists in the target table. v 2—Updated or deleted on the source table. The key for that row does not exist in the target table. v 3—Updated or deleted on the source table. The images of the source and target tables do not match. v 4—Unexpected conflict was detected. RESMTD The conflict resolution method that was used. The value is one of: v 1—Source wins v 2—Target wins v 3—Largest value wins v 4—Smallest value wins v 5—User exit If 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: v Y—Conflict was resolved. v N—Conflict was not resolved. BEFORETRNC Indicates if the before image stored in BEFOREIMG was truncated. The value is one of: v Y—Value was truncated. v 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: v Y—Value was truncated. v 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: v Y—Value was truncated. v 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. 114 InfoSphere Change Data Capture: End-User Documentation Column Description WINTRNC Indicates if the image stored in WINIMG was truncated. The value is one of: v Y—Value was truncated. v N—Value was not truncated. Related concepts “Row image format” 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. 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. Unaudited data types The audit table does not include columns of the following data types in its images: v IMAGE v NTEXT v 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. Conflict resolution audit table 115 116 InfoSphere Change Data Capture: End-User Documentation 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: v http://www.ibm.com/software/data/infosphere/support/change-data-capture/ For contact information in your region: v http://www.ibm.com/planetwide/ Related reference “dmsupportinfo - Collect IBM Support information” on page 99 © Copyright IBM Corp. 2008, 2011 117 118 InfoSphere Change Data Capture: End-User Documentation Notices This information was developed for products and services offered in Canada. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. © Copyright IBM Corp. 2008, 2011 119 IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Canada Limited Office of the Lab Director 8200 Warden Avenue Markham, Ontario L6G 1C7 CANADA Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, 120 InfoSphere Change Data Capture: End-User Documentation modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: © (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rights reserved. If you are viewing this information softcopy, the photographs and color illustrations may not appear. Trademarks IBM, the IBM logo, and ibm.com® are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Other company, product, or service names may be trademarks or service marks of others. Notices 121 122 InfoSphere Change Data Capture: End-User Documentation Printed in USA ...> [-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
...> [-a] [-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. -a Specifies that the InfoSphere CDC for Oracle databases source will preserve the Active table status after updating the definition of the source tables in the InfoSphere CDC metadata. By using this optional parameter, the table status will not be set to Parked, you will not lose the bookmark, and the tables will not require a refresh after you run the command. -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