InfoSphere CDC for Oracle databases (Version 10.2.

1) 5
About InfoSphere CDC 8
Capturing change data with single scrape 11
What's new 12
System requirements for InfoSphere CDC for Oracle databases 13
Hardware and software requirements 14
Running in a virtualization environment 15
Disk space requirements 16
RAM requirements 18
Tablespace requirements 19
Port requirements 20
Before you install InfoSphere CDC for Oracle databases 21
Required database, user accounts, and schemas 22
Assessing disk space and memory requirements 23
Understanding the importance of an appropriately configured disk subsystem 25
Allocating sufficient disk space for database log files 26
Sizing considerations for the staging store 28
Understanding the InfoSphere CDC memory footprint 30
Enabling supplemental logging 31
Enabling InfoSphere CDC for Oracle databases to use a bulk load refresh 33
Setting the database instance to ARCHIVELOG mode 34
InfoSphere CDC and Automatic Storage Management (ASM) 35
Starting the Oracle listener 36
Setting up a remote connection 37
To set up a remote connection 38
Replicating DDL changes 39
Calculating database connections required by InfoSphere CDC for Oracle databases 40
Clustered tables 42
Interval partitions 43
Replicating XA transactions 44
Database partition changes 45
Creating queues in JMS providers 46
Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC) environment 47
Configuring InfoSphere CDC for Oracle databases in a RAC environment 49
Configuring [Link] for InfoSphere CDC in a RAC environment 51
Oracle ASM considerations in a RAC environment 53
Creating an InfoSphere CDC for Oracle databases failover script for a RAC environment 54
NFS lockd utility considerations 55
Configuring InfoSphere CDC for Oracle databases for OS (operating system) clustering (UNIX and
Linux) 56
Performing a forced or manual failover of InfoSphere CDC for Oracle databases 57
Preparing for a failover of InfoSphere CDC for Oracle databases 58
Installing or upgrading InfoSphere CDC for Oracle databases 59
Installing InfoSphere CDC for Oracle databases 60
To install InfoSphere CDC for Oracle databases (UNIX and Linux) 61
To override the locale for the installation (UNIX and Linux) 62
Installing InfoSphere CDC for Oracle databases using a silent installation 63
To perform a silent installation of InfoSphere CDC for Oracle databases (UNIX and Linux) 64
Upgrading InfoSphere CDC for Oracle databases 65
To upgrade InfoSphere CDC for Oracle databases (UNIX and Linux) 66
Configuring instances of InfoSphere CDC for Oracle databases 68
Configuring InfoSphere CDC for Oracle databases instances for local log reading 69
To add a new instance of InfoSphere CDC for Oracle databases that reads logs locally 70
Configuring InfoSphere CDC for Oracle databases for remote log reading 74
To add a new instance of InfoSphere CDC for Oracle databases that reads logs remotely 75
Configuring InfoSphere CDC for Oracle databases for log shipping 79
To add a new instance of InfoSphere CDC for Oracle databases with log shipping using Data
Guard 80
To add a new instance of InfoSphere CDC for Oracle databases with manual log shipping 84
To ship logs using custom scripts 87
Editing an instance of InfoSphere CDC for Oracle databases 89
To edit an instance of InfoSphere CDC for Oracle databases 90
Deleting an instance of InfoSphere CDC for Oracle databases 91
To delete an instance of InfoSphere CDC for Oracle databases 92
After you install and configure InfoSphere CDC for Oracle databases 93
Granting required privileges to Oracle users using SQL scripts in /samples directory 94
Privileges for Oracle users 95
Starting InfoSphere CDC for Oracle databases 100
To start InfoSphere CDC for Oracle databases (UNIX and Linux) 101
Stopping InfoSphere CDC for Oracle databases 102
To stop InfoSphere CDC for Oracle databases (UNIX and Linux) 103
Performing an external refresh 104
To perform an external refresh 107
Maintaining active TCP connections in a network environment 108
To maintain active TCP connections 109
Enabling SQL statements in Management Console 110
To enable SQL statements in Management Console 111
InfoSphere CDC for Oracle databases metadata tables 112
Data types supported by InfoSphere CDC 113
System parameters for InfoSphere CDC for Oracle databases 114
Commands for InfoSphere CDC for Oracle databases 115
Using the InfoSphere CDC for Oracle databases commands 116
Setting the TSINSTANCE environment variable 117
Continuous Capture commands 118
dmdisablecontinuouscapture - Disable Continuous Capture 119
dmenablecontinuouscapture - Enable Continuous Capture 120
Controlling replication commands 121
dmendreplication - End replication 122
dmrefresh - Refresh subscription 126
dmstartmirror - Start mirroring 128
Database transaction log commands 131
dmarchivelogavailable - Mark archive log as available 132
dmarchivelogremoved - Mark archive log as removed 134
dmdecodebookmark - Display verbose information bookmark 135
dmsetbookmark - Set bookmark 136
dmshowbookmark - Display bookmark information 138
dmshowlogdependency - Show Log Dependency 140
Supplemental logging commands 142
dmshowsupplementalloggingdependency - Show supplemental logging dependency 143
dmreducesupplementalloggingdependency - Reduce supplemental logging dependency 144
dmsupplementallogevallist - Supplemental logging evaluation list 145
Single scrape and staging store commands 146
dmclearstagingstore - Remove cached operations from the staging store 147
dmgetstagingstorestatus - Retrieve Staging Store status 148
Exporting and importing configuration commands 149
dmexportconfiguration - Export InfoSphere CDC Configuration 150
dmimportconfiguration - Import InfoSphere CDC Configuration 151
Managing tables for replication commands 152
dmdescribe - Describe source tables 153
dmflagforrefresh - Flag for Refresh 154
dmmarktablecapturepoint - Mark a table capture point on a source table 155
dmpark - Park table 157
dmreaddtable - Update source table definition 158
dmreassigntable - Update target table definition 159
dmsetreplicationmethod - Set replication method 160
Monitoring replication commands 162
dmclearevents - Clear events 163
dmgetsubscriptionstatus - Get subscription status 164
dmshowevents - Display InfoSphere CDC events 165
Other commands 167
dmbackupmd - Back up metadata 168
dmconfigurets - Configure InfoSphere CDC 169
dmmarkexternalunloadstart - Start table data unload 170
dmmarkexternalunloadend - End table data unload 171
dmmdcommander 172
dmmdconsole 173
dmset - Set InfoSphere CDC system parameter 174
dmshowversion - Show InfoSphere CDC version 175
dmshutdown - Shut down InfoSphere CDC 176
dmsupportinfo - Collect IBM Support information 179
dmterminate - Terminate InfoSphere CDC processes 181
dmts32 - Start InfoSphere CDC 182
dmts64 - Start InfoSphere CDC 183
User exits for InfoSphere CDC for Oracle databases 184
Stored procedure user exits for table and row level operations 185
Defining a stored procedure user exit 186
Stored procedure user exit database connections 187
Retrieving data with a stored procedure user exit 188
Retrieving system values using the s$ prefix 189
Retrieving journal control fields using the j$ prefix 192
Retrieving data values using b$, a$, k$, and d$ prefixes 195
Example of a stored procedure user exit 198
Sample Java class user exits for InfoSphere CDC for Oracle databases 200
To compile the sample Java class user exits (UNIX and Linux) 201
InfoSphere CDC API reference - Javadocs 202
Conflict resolution audit table 203
Structure of the conflict resolution audit table 204
Row image format 206
Truncated images 207
Unaudited data types 208
Uninstalling InfoSphere CDC for Oracle databases 209
To uninstall InfoSphere CDC for Oracle databases (UNIX and Linux) 210
Troubleshooting 211
Using the IBM Support Assistant (ISA DC) 212
To use ISA DC to collect data for a product problem (command line) 213
To use ISA DC to collect data for a product problem (GUI) 216
To use ISA DC to collect data for a question or an enhancement request (command line) 218
To use ISA DC to collect data for a question or an enhancement request (GUI) 220
Locating log files 222
Troubleshooting and contacting IBM Support 223
About InfoSphere CDC
IBM®InfoSphere® Change Data Capture (InfoSphere CDC) is a replication solution
that captures database changes as they happen and delivers them to target
databases, message queues, or an ETL solution such as InfoSphere DataStage®
based on table mappings configured in the InfoSphere CDCManagement Console
GUI application.
InfoSphere CDC provides low impact capture and fast delivery of data changes for
key information management initiatives including dynamic data warehousing, master
data management, application consolidations or migrations, operational BI, and
enabling SOA projects. InfoSphere CDC also helps reduce processing overheads
and network traffic by only sending the data that has changed. Replication can be
carried out continuously or periodically. When data is transferred from a source
server, it can be remapped or transformed in the target environment.
The following diagram illustrates the key components of InfoSphere CDC.

The key components of the InfoSphere CDC architecture are described in the
following list:
- Access Server—Controls all of the non-command line access to the replication
environment. When you log in to Management Console, you are connecting to
Access Server. Access Server can be closed on the client workstation without
affecting active data replication activities between source and target servers.
- Admin API—Operates as an optional Java™-based programming interface that
you can use to script operational configurations or interactions.
- Apply agent—Acts as the agent on the target that processes changes as sent by
the source.
- Command line interface—Allows you to administer datastores and user
accounts, as well as to perform administration scripting, independent of
Management Console.
- Communication Layer (TCP/IP)—Acts as the dedicated network connection
between the Source and the Target.

5
- Source and Target Datastore—Represents the data files and InfoSphere CDC
instances required for data replication. Each datastore represents a database to
which you want to connect and acts as a container for your tables. Tables made
available for replication are contained in a datastore.
- Management Console—Allows you to configure, monitor and manage replication
on various servers, specify replication parameters, and initiate refresh and
mirroring operations from a client workstation. Management Console also allows
you to monitor replication operations, latency, event messages, and other statistics
supported by the source or target datastore. The monitor in Management Console
is intended for time-critical working environments that require continuous analysis
of data movement. After you have set up replication, Management Console can be
closed on the client workstation without affecting active data replication activities
between source and target servers.
- Metadata—Represents the information about the relevant tables, mappings,
subscriptions, notifications, events, and other particulars of a data replication
instance that you set up.
- Mirror—Performs the replication of changes to the target table or accumulation of
source table changes used to replicate changes to the target table at a later time. If
you have implemented bidirectional replication in your environment, mirroring can
occur to and from both the source and target tables.
- Refresh—Performs the initial synchronization of the tables from the source
database to the target. This is read by the Refresh reader.
- Replication Engine—Serves to send and receive data. The process that sends
replicated data is the Source Capture Engine and the process that receives
replicated data is the Target Engine. An InfoSphere CDC instance can operate as
a source capture engine and a target engine simultaneously.
- Single Scrape—Acts as a source-only log reader and a log parser component. It
checks and analyzes the source database logs for all of the subscriptions on the
selected datastore. Not all InfoSphere CDC engines use Single Scrape. For
InfoSphere CDC for DB2® for i, there is a Scraper job (that acts as a log reader)
and a Mirror job that performs the function of mirroring.
- Source transformation engine—Processes row filtering, critical columns, column
filtering, encoding conversions, and other data to propagate to the target datastore
engine.
- Source database logs—Maintained by the source database for its own recovery
purposes. The InfoSphere CDC log reader inspects these in the mirroring process,
but filters out the tables that are not in scope for replication.
- Target transformation engine—Processes data and value translations, encoding
conversions, user exits, conflict detections, and other data on the target datastore
engine.
There are two types of target-only destinations for replication that are not
databases:
- JMS Messages—Acts as a JMS message destination (queue or topic) for row-
level operations that are created as XML documents.
- InfoSphere DataStage—Processes changes delivered from InfoSphere CDC that
can be used by InfoSphere DataStage jobs.

In this section, you will learn:

6
- Capturing change data with single scrape
Related information:
Supported sources and targets

7
About InfoSphere CDC
IBM®InfoSphere® Change Data Capture (InfoSphere CDC) is a replication solution
that captures database changes as they happen and delivers them to target
databases, message queues, or an ETL solution such as InfoSphere DataStage®
based on table mappings configured in the InfoSphere CDCManagement Console
GUI application.
InfoSphere CDC provides low impact capture and fast delivery of data changes for
key information management initiatives including dynamic data warehousing, master
data management, application consolidations or migrations, operational BI, and
enabling SOA projects. InfoSphere CDC also helps reduce processing overheads
and network traffic by only sending the data that has changed. Replication can be
carried out continuously or periodically. When data is transferred from a source
server, it can be remapped or transformed in the target environment.
The following diagram illustrates the key components of InfoSphere CDC.

The key components of the InfoSphere CDC architecture are described in the
following list:
- Access Server—Controls all of the non-command line access to the replication
environment. When you log in to Management Console, you are connecting to
Access Server. Access Server can be closed on the client workstation without
affecting active data replication activities between source and target servers.
- Admin API—Operates as an optional Java™-based programming interface that
you can use to script operational configurations or interactions.
- Apply agent—Acts as the agent on the target that processes changes as sent by
the source.
- Command line interface—Allows you to administer datastores and user
accounts, as well as to perform administration scripting, independent of
Management Console.
- Communication Layer (TCP/IP)—Acts as the dedicated network connection
between the Source and the Target.

8
- Source and Target Datastore—Represents the data files and InfoSphere CDC
instances required for data replication. Each datastore represents a database to
which you want to connect and acts as a container for your tables. Tables made
available for replication are contained in a datastore.
- Management Console—Allows you to configure, monitor and manage replication
on various servers, specify replication parameters, and initiate refresh and
mirroring operations from a client workstation. Management Console also allows
you to monitor replication operations, latency, event messages, and other statistics
supported by the source or target datastore. The monitor in Management Console
is intended for time-critical working environments that require continuous analysis
of data movement. After you have set up replication, Management Console can be
closed on the client workstation without affecting active data replication activities
between source and target servers.
- Metadata—Represents the information about the relevant tables, mappings,
subscriptions, notifications, events, and other particulars of a data replication
instance that you set up.
- Mirror—Performs the replication of changes to the target table or accumulation of
source table changes used to replicate changes to the target table at a later time. If
you have implemented bidirectional replication in your environment, mirroring can
occur to and from both the source and target tables.
- Refresh—Performs the initial synchronization of the tables from the source
database to the target. This is read by the Refresh reader.
- Replication Engine—Serves to send and receive data. The process that sends
replicated data is the Source Capture Engine and the process that receives
replicated data is the Target Engine. An InfoSphere CDC instance can operate as
a source capture engine and a target engine simultaneously.
- Single Scrape—Acts as a source-only log reader and a log parser component. It
checks and analyzes the source database logs for all of the subscriptions on the
selected datastore. Not all InfoSphere CDC engines use Single Scrape. For
InfoSphere CDC for DB2® for i, there is a Scraper job (that acts as a log reader)
and a Mirror job that performs the function of mirroring.
- Source transformation engine—Processes row filtering, critical columns, column
filtering, encoding conversions, and other data to propagate to the target datastore
engine.
- Source database logs—Maintained by the source database for its own recovery
purposes. The InfoSphere CDC log reader inspects these in the mirroring process,
but filters out the tables that are not in scope for replication.
- Target transformation engine—Processes data and value translations, encoding
conversions, user exits, conflict detections, and other data on the target datastore
engine.
There are two types of target-only destinations for replication that are not
databases:
- JMS Messages—Acts as a JMS message destination (queue or topic) for row-
level operations that are created as XML documents.
- InfoSphere DataStage—Processes changes delivered from InfoSphere CDC that
can be used by InfoSphere DataStage jobs.

In this section, you will learn:

9
- Capturing change data with single scrape
Related information:
Supported sources and targets

10
Capturing change data with single scrape
Single scrape is a source-only component of InfoSphere® CDC that allows multiple
subscriptions in an instance to share the same log reader and log parser thread.
With single scrape, InfoSphere CDC only reads and parses the source database
transaction log once to capture changes for all tables being mirrored for the
instance.
Single scrape improves performance by reducing the footprint on your source
system since it only requires a single log reader thread and a single log parser
thread to service multiple subscriptions. This reduces disk I/O and decreases CPU
utilization by InfoSphere CDC processes.

Change data and the staging store

After the InfoSphere CDC log reader captures the change data from the database
logs and the data is parsed by the InfoSphere CDC log parser, change data is
placed in the staging store. Each subscription retrieves the changes for mirroring
tables from the staging store whenever possible. The data in scope for a given
subscription is kept in the staging store until it is sent to the target database. After
the data is sent to the target it is removed from the staging store. To improve
performance when subscriptions are mirroring, InfoSphere CDC will keep the
staging store data in memory whenever possible.

Related concepts:
Sizing considerations for the staging store
Assessing disk space and memory requirements
About InfoSphere CDC

11
What’s new
A large number of features and enhancements have been added to InfoSphere®
CDC for Oracle databases version 10.2.1. The following table lists the major feature
changes:

Item For more information, see:

Simplified configuration of a physical To add a new instance of InfoSphere
standby database. CDC for Oracle databases with log
shipping using Data Guard

12
System requirements for InfoSphere CDC for Oracle
databases
Before you install InfoSphere® CDC, ensure that the system you choose meets the
necessary operating system, hardware, software, communications, disk, and
memory requirements.
In this section, you will learn:

- Hardware and software requirements

- Running in a virtualization environment
- Disk space requirements
- RAM requirements
- Tablespace requirements
- Port requirements

13
Hardware and software requirements
Click the following links to view hardware and software requirements for
InfoSphere® CDC, Management Console, and Access Server:
Linux, UNIX, Windows and System i® replication engines: [Link]
Mainframe replication engine: [Link]

14
Running in a virtualization environment
The InfoSphere® CDC products adhere to the Virtualization Policy for IBM®
Software and can be run in any virtualization environment for only the supported
operating systems and versions listed specifically within IBMInfoSphere Data
Replication System Requirements.
For more information on the policy, see [Link]
[Link]/software/support/virtualization_policy.html

15
Disk space requirements
Disk space
InfoSphere® CDC source system:100 GB—Default value for the
Staging Store Disk Quota for each instance of InfoSphere CDC.
The minimum is 1 GB. Although the minimum is 1 GB, prepare for
more disk space since there is a staging store on the source. Use
the InfoSphere CDC configuration tool to configure disk space for
this quota.5 GB—For installation files, data queues, and log
[Link] disk quota—Disk space is required on your source
system for this quota which is used to store in-scope change data
that has not been committed in your database. The amount of disk
space required is determined by your replication environment and
the workload of your source database. Use the
mirror_global_disk_quota_gb system parameter to configure the
amount of disk space used by this quota.
InfoSphere CDC target system:1 GB—The minimum amount of
disk space allowed for the disk quota for each instance of
InfoSphere CDC. The minimum value for this quota is sufficient for
all instances created on your target system. Use the InfoSphere
CDC configuration tool to configure the disk space for this quota.5
GB—For installation files, data queues, and log [Link] disk
quota—Disk space is required on your target system for this quota
which is used to store LOB data received from your InfoSphere
CDC source system. The amount of disk space required is
determined by your replication environment and the amount of
LOB data you are replicating. To improve performance, InfoSphere
CDC will only persist LOB data to disk if RAM is not available on
your target system. Use the mirror_global_disk_quota_gb system
parameter to configure the amount of disk space used by this
quota.

InfoSphere CDC may require additional disk space in the following situations:
- You are running large batch transactions in the database on your source system.
- You are configuring multiple subscriptions and one of your subscriptions is latent.
In this type of scenario, InfoSphere CDC on your source system may persist
transaction queues to disk if RAM is not available.
- You are replicating large LOB data types.
- You are replicating "wide" tables that have hundreds of columns.
- You are performing regular back ups of your metadata with the dmbackupmd
command-line utility.

Related concepts:
Hardware and software requirements
RAM requirements
Tablespace requirements
Port requirements
Configuring instances of InfoSphere CDC for Oracle databases
16
17
RAM requirements
RAM
Each instance of InfoSphere® CDC requires memory for the
Java™ Virtual Machine (JVM). The following default values for
memory are assigned:
1024 MB of RAM —Default value for each 64-bit instance of
InfoSphere CDC. 512 MB of RAM—Default value for each 32-bit
instance of InfoSphere [Link] the InfoSphere CDC
configuration tool to configure the memory for each instance of
InfoSphere CDC.
Note:InfoSphere CDC is predominantly a Java-based application.
However, some portions of it are written in C. These portions of
InfoSphere CDC are not subject to the memory limits specified for
the JVM

Although InfoSphere CDC memory requirements will fluctuate, you must work with
your system administrator to ensure the allocated memory for each instance of the
product is available at all times. This may involve deployment planning since other
applications with memory requirements may be installed on the same server with
InfoSphere CDC. Using values other than the defaults or allocating more RAM than
is physically available on your server should only be undertaken after considering
the impacts on product performance.
InfoSphere CDC source deployments may require additional RAM in the following
scenarios:
- You are replicating large LOB data types with your InfoSphere CDC source
deployment. These data types are sent to target while being retrieved from the
source database. The target waits until all LOBs (for each record) are received
before applying a row. LOBs are stored in memory as long as there is adequate
RAM, otherwise they are written to disk on the target.
- You are replicating "wide" tables with hundreds of columns.
- You are performing large batch transactions in your source database rather than
online transaction processing (OLTP).

Related concepts:
Hardware and software requirements
Disk space requirements
Tablespace requirements
Port requirements
Configuring instances of InfoSphere CDC for Oracle databases

18
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:
Hardware and software requirements
Disk space requirements
RAM requirements
Port requirements

19
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 10901 Accepts connections
from:Management
ConsoleOther
installations of
InfoSphere CDC as a
source of
replicationCommand
line utilities

Related concepts:
Maintaining active TCP connections in a network environment
Disk space requirements
Hardware and software requirements
RAM requirements
Tablespace requirements
Configuring instances of InfoSphere CDC for Oracle databases

20
Before you install InfoSphere CDC for Oracle
databases
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 before installing InfoSphere CDC.
In this section, you will learn:

- Required database, user accounts, and schemas

- Assessing disk space and memory requirements
- Understanding the importance of an appropriately configured disk subsystem
- 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.
- Sizing considerations for the staging store
- Understanding the InfoSphere CDC memory footprint
- Enabling supplemental logging
- Enabling InfoSphere CDC for Oracle databases to use a bulk load refresh
- Setting the database instance to ARCHIVELOG mode
- InfoSphere CDC and Automatic Storage Management (ASM)
- Starting the Oracle listener
- Setting up a remote connection
- Understanding Index Organized Tables (IOT) support
- Replicating DDL changes
- Calculating database connections required by InfoSphere CDC for Oracle
databases
- Clustered tables
- Interval partitions
- Replicating XA transactions
- Database partition changes
- Creating queues in JMS providers

21
Required database, user accounts, and schemas
Configuring database
When you configure InfoSphere® CDC, you are prompted for the name of the
database to which you want InfoSphere CDC to replicate data. Before installing
InfoSphere CDC, ensure that this 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.

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.

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 that you have enabled supplemental logging for the Oracle database
before installing and configuring InfoSphere CDC.

Reviewing required privileges for Oracle users

Before 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
Privileges for Oracle users

22
Assessing disk space and memory requirements
InfoSphere® CDC requires disk space and memory when it processes change data
from your source database. In order to process change data efficiently and replicate
these changes to your target system, it is very important that InfoSphere CDC has
adequate disk space and memory for each of the components described in this
section.

Disk space requirements for the staging store

The InfoSphere CDC staging store is located on your source system and is a cache
of change data read from the database logs. The size of the staging store will
increase as the product accumulates change data, and therefore you must plan your
source environment accordingly, particularly disk space.
The disk space allocated to the staging store is controlled by the Staging Store Disk
Quota value that is set when you create an instance with the InfoSphere CDC
configuration tool. In most cases, the default value is appropriate for InfoSphere
CDC source systems. Since the staging store is only used on source systems, you
can reduce this value to the minimum of 1 GB if you are configuring a target
instance of InfoSphere CDC.

Note: You can also allocate disk space to the staging store with the
staging_store_disk_quota_gb system parameter in Management Console.

Memory requirements for the JVM (Java Virtual Machine)

As a Java-based product, InfoSphere CDC requires you to allocate the maximum
amount of memory (RAM) to be used by the Java™ Virtual Machine (JVM). This
prevents InfoSphere CDC from using all of the available memory on the system
where it is installed.
The Maximum Memory Allowed value is set on a per-instance basis for each
instance you create for your source or target database. In most cases the default
values are appropriate for 32-bit and 64-bit instances. However, if your database is
processing an extremely heavy workload, you may have to adjust the default values.
The RAM allocated must be physically available on your system.

Disk space requirements for the global disk quota

The global disk quota on your source and target systems is used for all capture
components including temporary files, transaction queues, and LOBs which are
staged on the target before being applied. InfoSphere CDC will manage disk space
utilization across all components as required.
Most databases have a mechanism that allows you to roll back or undo changes to
your database by storing uncommitted changes. Similarly, InfoSphere CDC uses
this disk quota to store in-scope change data that has not been committed in your
database. Once the database transaction is committed, the disk space used by the
transaction is released. Long running open transactions will contribute to the amount
of disk space used.
You can configure the amount disk space that is allocated to this quota with the
mirror_global_disk_quota_gb system parameter. The default setting of this system
parameter is such that InfoSphere CDC will only stop replicating after this disk quota
exhausts all available disk space on your system. If you would prefer InfoSphere
23
CDC to stop replicating after it uses a specific amount of disk space, you can specify
the value with this system parameter in Management Console.

Related concepts:
Sizing considerations for the staging store
Configuring instances of InfoSphere CDC for Oracle databases
Disk space requirements
RAM requirements

24
Understanding the importance of an appropriately
configured disk subsystem
There are many types of disk subsystems in use to meet either business or
performance needs. Not all of these disk subsystems are suitable for use by
databases or InfoSphere® Data Replication out of the box. Some may need to be
tuned to ensure that appropriate input/output semantics are in place for reliable
continuous operation.
Symptoms of an unreliable disk subsystem
Without appropriate disk subsystem configuration, both the database itself or
InfoSphere Data Replication may exhibit any of a wide variety of input/output related
errors, usually random in nature. Any one of them can stop replication. If the
database transaction logs themselves become corrupted due to this kind of
misconfiguration, then the database itself may become unrecoverable, putting the
entire business at risk. Having an appropriately configured disk subsystem is
therefore essential to the operation of both database and InfoSphere Data
Replication.
What makes a disk subsystem unreliable?
Typically, disk mounting options that interfere with or modify the read visibility of
write operations are the ones which will cause data to be read inaccurately, thereby
causing applications such as databases and InfoSphere Data Replication to report
errors and fail. The expectations of these semantics between the database and
InfoSphere Data Replication must be compatible with those provided by the options
used to mount the disk subsystem in order to avoid corruption issues. Some
databases exhibit specific behaviors only with certain disk subsystem types, so
proper care and attention is needed to properly configure the disk subsystem.
Special notes regarding specific configurations
Direct I/O on Linux—Due to the nature of the implementation of direct I/O (directio)
on Linux, applications that read from files being written using direct I/O must employ
exactly the same direct I/O options as the writing application. If this is not done, the
reading application may not ever see the data written by the writing application and
the reading application can therefore exhibit a stall. Linux versions of InfoSphere
CDC prior to version 6.5.1 Interim Fix 17 for Oracle, version 6.5.2 Interim Fix 20 for
Oracle, and InfoSphere Data Replication versions prior to 10.2 for Oracle and
Sybase can exhibit this behaviour under certain conditions. The best resolution is to
upgrade to the latest Interim Fix level for InfoSphere CDC or to version 10.2 or later
for InfoSphere Data Replication.

25
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.
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 [Link] 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
26
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.

27
Sizing considerations for the staging store
This topic outlines scenarios that will increase the disk requirements for the staging
store on your source system. All of these scenarios should be kept in mind when
you are planning the disk space requirements for your replication environment.
Latent subscriptions
The amount of data within the staging store is related to the latency of your
subscriptions. InfoSphere® CDC measures latency as the amount of time that
passes between when data changes on a source table and when it changes on the
target table. For example, if an application inserts and commits a row into the source
table at 10:00 and InfoSphere CDC applies that row to the target table at 10:15, then
the latency for the subscription is 15 minutes.
When all of your subscriptions are mirroring and have very little latency, the volume
of data that needs to be kept in the staging store will be relatively small. If all of your
subscriptions are mirroring but some are latent, the staging store will contain all the
data generated by the logs for the latent subscriptions during the entire time they are
mirroring. For example, if the difference in latency between the least latent
subscription and the most latent subscription is 3 hours, and your database
generates 100 GB of log data per hour, the staging store will require approximately
300 GB of disk storage space.

Inactive subscriptions
An inactive (not currently replicating) subscription that contains tables with a
replication method of Mirror will continue to accumulate change data in the staging
store from the current point back to the point where mirroring was stopped. For this
reason, you should delete subscriptions that are no longer required, or change the
replication method of all tables in the subscription to Refresh to prevent the
accumulation of change data in the staging store on your source system.

Continuous Capture
Continuous Capture is a product feature that is designed to accommodate those
replication environments in which it is necessary to separate the reading of the
database logs from the transmission of the logical database operations. This is
useful when you want to continue processing log data even if replication and your
subscriptions stop due to issues such as network communication failures over a
fragile network, target server maintenance, or some other issue. You can enable or
disable Continuous Capture without stopping subscriptions.
Continuous Capture results in additional disk utilization on the source machine in
order to accumulate change data from the database log file when these are not
being replicated to the target machine. This change data is stored in the staging
store. The additional disk utilization due to the accumulation of change data in the
staging store should be evaluated and understood before deciding to use this
feature in your replication environment.

Related concepts:
Assessing disk space and memory requirements
Continuous Capture commands
28
29
Understanding the InfoSphere CDC memory
footprint
Current® versions of InfoSphere® CDC on Linux, UNIX, and Windows platforms are
written in the Java™ programming language. The memory specified in the
InfoSphere CDC configuration tool refers to the amount of memory that the Java
Virtual Machine (JVM) will allocate to InfoSphere CDC to run. This memory is strictly
enforced by the JVM itself and the JVM will ensure that it is not exceeded.
The JVM itself also consumes some memory. The amount of this other memory
varies considerably by Java version, bit length, and operating system. A simple Java
program consumes 13212 KB of overhead when run in a 32-bit Java 1.5 JVM on
AIX®, but 173509 KB of overhead when run in a 32-bit Java 1.5 JVM on Linux. In
other words, the overhead on Linux is 13 times larger than the overhead on AIX,
when controlling for the other variables.
The amount of memory overhead consumed by the JVM itself can also change over
time. This is especially true for Linux and UNIX systems. For those systems, once
the operating system allocates memory to a process, it is not reclaimed until the
process ends. Thus, the total amount of memory for any given process never goes
down.
Given these factors, you should expect that more memory is used by InfoSphere
CDC than is allocated in the configuration tool. InfoSphere CDC has no control over
this memory usage and cannot track or otherwise manage it.

30
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.
Database level supplemental logging is an Oracle requirement that ensures that the
Oracle redo log contains the information required to describe all data changes
completely. You must set this value explicitly in 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.
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. As with previous versions of the product, you can rely on
InfoSphere CDC to handle the supplemental logging. However, you can now
manage your own supplemental logging requirements and if sufficient, InfoSphere
CDC will use them. As before, in 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.
- For Direct Mappings InfoSphere CDC will require supplemental logging to be set to
at least one of the following levels if you choose to manage your own supplemental
logging:
- Minimum level supplemental logging and table level supplemental logging on all
columns
- Minimum level supplemental logging and table level supplemental logging with
conditional or unconditional log groups
- Database-level supplemental logging on all columns
- For Rules-based mappings, InfoSphere CDC requires:
- Database-level supplemental logging on keys and changes
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.
InfoSphere CDC will not disable supplemental logging, whether or not it was
enabled through InfoSphere CDC. It is the user's responsibility to disable
supplemental logging when they deem it necessary.

Related reference:
dmshowlogdependency - Show Log Dependency
dmshowsupplementalloggingdependency - Show supplemental logging dependency
dmreducesupplementalloggingdependency - Reduce supplemental logging
dependency
dmsupplementallogevallist - Supplemental logging evaluation list

31
32
Enabling InfoSphere CDC for Oracle databases 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 [Link] file and
select this database when configuring InfoSphere CDC.

33
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.

34
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 both SYSDBA and SYSASM privileges to log in to ASM.
ASM rebalancing, when adding or dropping disks, can be configured to occur
automatically or you can perform it manually. It is important to note that InfoSphere
CDC cannot replicate while an ASM rebalancing is taking place. If an automatic
rebalancing occurs while InfoSphere CDC is reading the database logs, InfoSphere
CDC will stop replication. If possible, you should plan your ASM rebalancing and
stop InfoSphere CDC accordingly.
If you are deploying InfoSphere CDC in a RAC environment that uses ASM, there
are additional considerations. For more information, see the related topic listed
below.

Related concepts:
Oracle ASM considerations in a RAC environment

35
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.
Single Client Access Name (SCAN) configurations are supported.

36
Setting up a remote connection
If you want to install InfoSphere® CDC and the Oracle database on different
machines, then you must set up a connection to the remote machine (where the
Oracle database is installed) using SQL*Net.
See also:

- To set up a remote connection

37
To set up a remote connection
Procedure
1. Ensure you have installed an Oracle client on the local server and have added the
TNS names entry to the [Link] 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.
5. If the absolute paths of the directories containing the archive logs differ between
the local server and the remote server, then you will need to override the mount
point during instance [Link] you are running in archive mode only
InfoSphere CDC needs access to at least one archive log destination. Please
make sure you specified a mount point override for at least one archive
destination if the local path is different from the original path.
If you are not running on archive mode only, InfoSphere CDC needs access to at
least one online and one archive destination. If paths on the remote server are
different from the ones on the local server, please provide appropriate overrides.
6. At the command line on the local server, mount the redo log path from the remote
server.
7. If the absolute paths of the directories containing the online logs differ between
the local server and the remote server, then you will need to override the mount
point during instance configuration.

Related concepts:
Configuring InfoSphere CDC for Oracle databases for remote log reading

38
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:
- Creating tables (CREATE command)
- Modifying the structure of a table (ALTER command) without deleting and re-
creating it, such as adding columns, removing columns or changing column
definitions (for example, length or default values)
- Removing objects (such as tables) from the database (DROP command)
- 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:
- Adding records to a table (INSERT command)
- Modifying information in a table (UPDATE command)
- 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 and later 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 if
you are using the DDL replication feature. 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
Replicating Data Definition Language (DDL) changes.

39
Calculating database connections required by
InfoSphere CDC for Oracle databases
As an administrator, you may find it necessary to calculate how many database
connections are needed before installing InfoSphere® CDC on either a source or a
target database. Calculating the upper bound (both permanent and temporary)
database connections will help you plan your environment so that it can
accommodate InfoSphere CDC.

Calculating connections required by InfoSphere CDC on a

source database
(22 + G)*I + (4 + A)*S + 3*R + L + CWhere:
Note: Enter 0 for any value that does not apply to your deployment of InfoSphere
CDC.
- G = number of Management Console GUI and CHCCLP scripting applications that
are connected to your instances of InfoSphere CDC.
- I = number of InfoSphere CDC instances.
- A = number of RAC nodes if you are not using ASM with Oracle RAC.
- S = number of subscriptions in all of your InfoSphere CDC instances.
- R = number of RAC nodes if you are using ASM with Oracle RAC.
- L = number of subscriptions that contain LOB columns. Note that LOB columns for
the InfoSphere CDC for Oracle databasesand InfoSphere CDC for DB2® for LUW
refer to non-inline LOBS.
- C = number of InfoSphere CDC command line utilities that you plan to use.

Example: How to calculate required connections for a

source database
You want to set up InfoSphere CDC in the source environment as follows:
- 1 instance of Management Console.
- 2InfoSphere CDC instances.
- 2 RAC nodes and you are not using ASM.
- 3 subscriptions.
- 1 subscription that uses non-inline LOB columns.
- You do not plan to use any InfoSphere CDC command line utilities.
The number of connections required on the source database will be:
(22+1)*2 + (4+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 on a

target database
(4+G)*I + 3*SWhere:
- G = number of Management Console GUI and CHCCLP scripting applications that
are connected to your instances of InfoSphere CDC.
- I = number of InfoSphere CDC instances.
- S = number of subscriptions in all of your InfoSphere CDC instances.

Example: How to calculate required connections for a target

database 40
You want to set up InfoSphere CDC in the target environment as follows:
- 1 installed Management Console GUI application.
- 2InfoSphere CDC instances.
- 3 subscriptions.

The number of connections required on the target database will be:

(4 + 1)*2 + 3*3 = 19 You should plan for a maximum of 19 database connections
before installing InfoSphere CDC on the target database.

41
Clustered tables
InfoSphere® CDC does not support Oracle clustered tables.

42
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.

43
Replicating XA transactions
InfoSphere® CDC will replicate transactions involved in XA. InfoSphere CDC will
maintain any data dependencies between individual branches.
Replication of XA transactions is supported on the following database versions:
- IBM® DB2® LUW version 9.7 and later

44
Database partition changes
InfoSphere® CDC does not support moving database partition changes except as
documented for specific environments such as DDL replication.

45
Creating queues in JMS providers
If you choose to use a JMS provider as the communications protocol for
InfoSphere® CDC, you will need to define the queues to be used by InfoSphere
CDC before you attempt to configure an instance.
The queues will need to be named in the format CDC_<port>, where <port> is the
five digit TCP listening port number of the instance. You can left-pad the number
with zeroes if necessary to ensure five digits (example, CDC_00123).
Each InfoSphere CDC instance will require its own queue. Instances cannot share a
queue.
When you create the queue, you must ensure that they are defined to hold
messages of the type BytesMessage.

46
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 [Link] 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:

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
47
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 for Oracle databases in a RAC environment

- Configuring [Link] for InfoSphere CDC in a RAC environment
- Oracle ASM considerations in a RAC environment
- Creating an InfoSphere CDC for Oracle databases failover script for a RAC
environment
- NFS lockd utility considerations
Related concepts:
Configuring instances of InfoSphere CDC for Oracle databases
Installing InfoSphere CDC for Oracle databases

Related reference:
dmconfigurets - Configure InfoSphere CDC

48
Configuring InfoSphere CDC for Oracle databases
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).
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:
- Active source RAC node failure. In this case, the RAC node where the active
InfoSphere CDC source instance fails.
- Active target RAC node failure. In this case, the RAC node where the active
InfoSphere CDC target instance fails.
- Both active RAC nodes (source and target) fail.

In addition, the following needs to be satisfied:

- Ability to restart InfoSphere CDC from a different location (that is, InfoSphere CDC
binaries and configuration, and operational metadata need to be accessible).
- 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 <IP address of first node>

In the second node, the /etc/hosts file should have the following entry: #cdc_host<IP

address of second node>

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
[Link] file should be created using the common host name: SID_CDC=
(DESCRIPTION=

(ADDRESS=(PROTOCOL=TCP)(HOST=cdc_host)(PORT=1521))

(CONNECT_DATA=(server=DEDICATED)
49
 (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.
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.

50
Configuring [Link] for InfoSphere CDC in a
RAC environment
If you are using Oracle RAC without ASM, InfoSphere® CDC requires an identical
TNS entry in the [Link] 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 = [Link])

(INSTANCE_NAME = instancesid)

Where:
- racsystemvip—virtual IP for your RAC system.
- [Link]—global service name for your RAC system.
- 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 [Link] 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 for Oracle databases failover script for a RAC
environment
Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC)
environment
Configuring instances of InfoSphere CDC for Oracle databases
Installing InfoSphere CDC for Oracle databases

Related tasks:
To add a new instance of InfoSphere CDC for Oracle databases with log shipping
using Data Guard
To add a new instance of InfoSphere CDC for Oracle databases that reads logs
locally
To add a new instance of InfoSphere CDC for Oracle databases with manual log
shipping
To add a new instance of InfoSphere CDC for Oracle databases that reads logs
remotely

Related reference:
dmconfigurets - Configure InfoSphere CDC
51
52
Oracle ASM considerations in a RAC environment
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.
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 instances of InfoSphere CDC for Oracle databases
InfoSphere CDC and Automatic Storage Management (ASM)

Related reference:
dmconfigurets - Configure InfoSphere CDC

53
Creating an InfoSphere CDC for Oracle databases
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:
- Stop replication on all subscriptions with the dmendreplication command.
- Shut down all InfoSphere CDC processes with the dmshutdown command.
- Modify the INSTANCE_NAME parameter in the [Link] file to point to the
next available RAC node.
- If required, restart the Oracle service listener.
- Delete the following staging area files in the InfoSphere CDC installation directory:
- <instance_name>/txnstore/txq*
- <instance_name>/stagingstore/*
- <instance_name>/tmp/*
- Restart the InfoSphere CDC instance on a different RAC node with the dmts32 or
dmts64 commands.
- Restart replication on all subscriptions with the dmstartmirror command.

Related concepts:
Configuring [Link] for InfoSphere CDC in a RAC environment
Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC)
environment
Configuring instances of InfoSphere CDC for Oracle databases

Related reference:
dmendreplication - End replication
dmshutdown - Shut down InfoSphere CDC
dmts32 - Start InfoSphere CDC
dmts64 - Start InfoSphere CDC
dmstartmirror - Start mirroring

54
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<instance name>/var directory.

55
Configuring InfoSphere CDC for Oracle databases
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.
- Install InfoSphere CDC on the shared drive of the cluster.
- Add a new instance of InfoSphere CDC.
- 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.
- Ensure that all of the database logs required for replication are available. This
prerequisite only applies to InfoSphere CDC as a clustered source.
- 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.
- 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 for Oracle databases

- Preparing for a failover of InfoSphere CDC for Oracle databases
Related concepts:
Configuring InfoSphere CDC for Oracle databases instances for local log reading

Related tasks:
To install InfoSphere CDC for Oracle databases (UNIX and Linux)

56
Performing a forced or manual failover of
InfoSphere CDC for Oracle databases
About this task
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.

Procedure
1. Stop all instances of InfoSphere® CDC on the current active node with the
following command:dmshutdown -I <instance_name>
2. Manually failover your clustered environment with the scripts or procedures that
are specific to your environment.
3. Restart all instances on the new active node with the following commands for 32-
bit and 64-bit operating systems:dmts32 - I <instance_name> or dmts64
- I <instance_name>
4. Start all subscriptions on the new active node with the dmstartmirror command.

Related concepts:
Starting InfoSphere CDC for Oracle databases
Stopping InfoSphere CDC for Oracle databases

Related tasks:
Preparing for a failover of InfoSphere CDC for Oracle databases

Related reference:
dmstartmirror - Start mirroring

57
Preparing for a failover of InfoSphere CDC for
Oracle databases
About this task
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.

Procedure
1. Clean the transaction queues for each instance by removing all files that begin
with txqueue* in the <InfoSphere CDC installation directory>/instance/<instance
name>/txnstore directory.
2. Back up your metadata for each instance by archiving all files that begin with md*
in the <InfoSphere CDC installation directory>/instance/<instance name>/conf
directory. If the metadata database does not recover after a failover, restore these
files to the same directory on the new active node. This task is optional.
3. Back up your Event Log messages for each instance by archiving all files in the
<InfoSphere CDC installation directory>/instance/<instance name>/events
directory. If the events database does not recover after a failover, restore these
files to the same directory on the new active node. This task is optional.
4. Start each instance on the new active node with the following commands for 32-
bit and 64-bit operating systems:dmts32 - I <instance_name> or dmts64
- I <instance_name>
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 for Oracle databases

Related tasks:
Performing a forced or manual failover of InfoSphere CDC for Oracle databases

Related reference:
dmclearstagingstore - Remove cached operations from the staging store
dmstartmirror - Start mirroring

58
Installing or upgrading InfoSphere CDC for Oracle
databases
Before attempting to install or upgrade InfoSphere® CDC, consult the database,
operating system and hardware requirements for the specific version of the software
that you want to install, to ensure that it is compatible with your system.
If you are upgrading to a later version or installing a fix pack, an installation of
InfoSphere CDC must already be present in order to successfully complete the
process.
In this section, you will learn:

- Installing InfoSphere CDC for Oracle databases

- Installing InfoSphere CDC for Oracle databases using a silent installation
- Upgrading InfoSphere CDC for Oracle databases
You can upgrade InfoSphere CDC by installing a later version of the software over
top of an existing installation.

59
Installing InfoSphere CDC for Oracle databases
Note the following before you install or upgrade InfoSphere® CDC on Linux or UNIX
:
- Do not install or upgrade InfoSphere CDC as a root user.
- The installation directory requires file system permissions of 700 if you plan to use
the same user account to install the product, create and configure instances, or
upgrade the product.
- The installation directory requires file system permissions of 770 if you plan to use
different user accounts to install the product, create and configure instances, or
upgrade the product.
Note: Ensure that the installed version of the Management Console and Access
Server applications are either the same version as the InfoSphere CDC replication
engine or a later version.
See also:

- To install InfoSphere CDC for Oracle databases (UNIX and Linux)

- To override the locale for the installation (UNIX and Linux)

Related concepts:
Before you install InfoSphere CDC for Oracle databases

60
To install InfoSphere CDC for Oracle databases
(UNIX and Linux)
Procedure
1. Log on to the account you set up for InfoSphere® CDC.
2. Copy the InfoSphere CDC installation file for your UNIXor Linux platform from
the InfoSphere CDC DVD or the download file.
3. Make the installation binary file executable.
4. Run the installation program by typing the following command:./
<installation_binary_name>.bin
If you already have InfoSphere CDC installed, the installation program will
prompt you to upgrade.
5. Press Enter on the Introduction screen to display the license agreement. Follow
the instructions on the screen to navigate through the license agreement.
6. To accept the license agreement, type 1.
7. Enter the absolute path to your installation directory or press Enter to accept the
[Link]: 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.
9. After completing the installation, InfoSphere CDC gives you the option of
launching the configuration tool for InfoSphere CDC.
10. Type 1 to launch the configuration tool.
What to do next
Note: If you have X-Windows installed, the installation program will launch the
configuration tool in a graphical environment.

Related concepts:
Configuring instances of InfoSphere CDC for Oracle databases

61
To override the locale for the installation (UNIX and
Linux)
About this task
Use the following procedure to override the locale for the installer. English,
Japanese and Simplified Chinese are supported.

Procedure
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:
- English—<installation_file_name>.bin -l en
- Japanese—<installation_file_name>.bin -l ja
- Korean—<installation_file_name>.bin -l ko
- Simplified Chinese—<installation_file_name>.bin -l zh_CN

where:
- <installation_file_name> is the name of the installation file.
What to do next
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.

62
Installing InfoSphere CDC for Oracle databases
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 for Oracle databases (UNIX and
Linux)

63
To perform a silent installation of InfoSphere CDC
for Oracle databases (UNIX and Linux)
Procedure
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:
<installation_binary_name> -r <response-file>
where:
- <response-file> is the full path to the installation response file.
5. On another system, perform the silent installation by running the following
command:<installation_binary_name> -i silent -f <response-file>
where:
- <response-file> is the full path to the installation response file.

Related tasks:
To install InfoSphere CDC for Oracle databases (UNIX and Linux)

64
Upgrading InfoSphere CDC for Oracle databases
You can upgrade InfoSphere® CDC by installing a later version of the software over
top of an existing installation.
- All subscriptions in all InfoSphere CDC for DB2® for LUW instances associated
with the installation to be upgraded must be stopped.
- All InfoSphere CDC for DB2 for LUW instances associated with the installation
must be stopped.
- When logging in, you must use the same account that was used during the original
installation of InfoSphere CDC for DB2 for LUW.
- It is a best practice to backup the installation directory of the current InfoSphere
CDC for DB2 for LUW installation.
- It is a best practice to backup the InfoSphere CDC metadata tables (TS_AUTH,
TS_BOOKMARK, TS_CONFAUD, and TS_DDLAUD) that are stored in the DB2
database instance that you are replicating to and from. In the event of a failure
during the upgrade, having a backup of the metadata will allow you to revert to the
point in time before the upgrade. In addition to the InfoSphere CDC metadata
tables stored in your database, InfoSphere CDC maintains some other metadata in
an internal database. It is a best practice to backup the InfoSphere CDC internal
metadata at the same time as the InfoSphere CDC metadata tables in your
database are backed up. The dmbackup command can be used to backup the
internal InfoSphere CDC metadata tables.
- Do not upgrade InfoSphere CDC as a root user.
- The installation directory requires file system permissions of 700 to install the
product, create and configure instances, or upgrade the product.
When upgrading an InfoSphere CDC replication engine, you must also upgrade
Management Console and Access Server to the same version or later to access the
full range of functionality that was introduced in the later version of the engine.
Management Console and Access Server are backward-compatible and will support
the functionality available in earlier versions of the engines.
CAUTION:
You cannot export and import subscriptions across different versions of InfoSphere
CDC. Do not attempt to import a subscription file from a previous version into an
upgraded version. Once the upgrade is complete, you should create a new exported
subscriptions xml file.
See also:

- To upgrade InfoSphere CDC for Oracle databases (UNIX and Linux)

65
To upgrade InfoSphere CDC for Oracle databases
(UNIX and Linux)
Procedure
1. Ensure that all subscriptions in all InfoSphere® CDC instances are stopped.
2. Ensure that all InfoSphere CDC instances are stopped.
3. Ensure that you have a backup of the TS_AUTH, TS_BOOKMARK,
TS_CONFAUD, and TS_DDLAUD metadata tables that are stored in the
database instance that you are replicating to and from. In the event of a failure
during the upgrade, having a backup of the metadata will allow you to revert to
the point in time before the upgrade. In addition to the InfoSphere CDC
metadata tables stored in your database, InfoSphere CDC maintains some other
metadata in an internal database. It is a best practice to backup the InfoSphere
CDC internal metadata at the same time as the InfoSphere CDC metadata
tables in your database are backed up. The dmbackup command can be used to
backup the internal InfoSphere CDC metadata tables.
4. Ensure that you have backed up your InfoSphere CDC installation directory.
Important: The backup of the installation directory and the metadata tables
should be from the same timeframe, so that they contain an identical snapshot
of data.
5. Log on to the account you set up for InfoSphere CDC.
6. Copy the InfoSphere CDC installation file for the version to which you want to
upgrade. This file is available on the InfoSphere CDC DVD or you can download
the desired version from the IBM® web site. Ensure that you have copied the
installation file for the applicable operating system.
7. Make the installation binary file executable.
8. Run the installation program by typing the following command:./
<installation_binary_name>.bin
If you already have InfoSphere CDC installed, the installation program will
prompt you to upgrade.
9. Press Enter on the Introduction screen to display the license agreement. Follow
the instructions on the screen to navigate through the license agreement.
10. To accept the license agreement, type 1.
11. Enter the absolute path to your installation directory or press Enter to accept the
[Link]: 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.
12. Confirm the absolute path. If it is correct, type Y and press Enter.
13. Type 1 to confirm that you want to upgrade the existing installation and press
Enter.
14. Review the pre-upgrade summary. Press Enter to start the upgrade.
15. After upgrading the software, you must start all the configured instances in order
to complete the upgrade process. Depending on the number of tables and
subscriptions configured, as well as the complexity of the mappings, the upgrade
process can take anywhere from several minutes to hours. Once the upgrade
process is complete, InfoSphere CDC will be ready for replication and will
restart.
66
67
Configuring instances of InfoSphere CDC for Oracle
databases
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.
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.
In this section, you will learn:

- Configuring InfoSphere CDC for Oracle databases instances for local log reading
- Configuring InfoSphere CDC for Oracle databases for remote log reading
- Configuring InfoSphere CDC for Oracle databases for log shipping
- Editing an instance of InfoSphere CDC for Oracle databases
- Deleting an instance of InfoSphere CDC for Oracle databases

68
Configuring InfoSphere CDC for Oracle databases
instances for local log reading
You can configure InfoSphere® CDC for Oracle databases to use Oracle archive
and redo logs that reside locally to the database.
By default, the product is configured to read both online redo log files and archived
log files. This provides for low latency replication as the online log is continuously
written by Oracle and read by the InfoSphere CDC for Oracle databases log reader.
However, the product can also be configured for reading archive log files only.
See also:

- To add a new instance of InfoSphere CDC for Oracle databases that reads logs
locally

69
To add a new instance of InfoSphere CDC for Oracle
databases that reads logs locally
Procedure
1. If you are configuring the first instance of InfoSphere® CDC for Oracle
databases after installation, you can proceed to Step 4 of this procedure.
2. At the command prompt, launch the configuration tool by issuing the following
command in the specified directory:\<InfoSphere CDC Installation Directory>\bin\dmconfigurets
3. If you are configuring instances subsequent to the first instance, enter 2 and
press [Link] to Step 5 of this procedure.
4. At the welcome message, press Enter to continue.
5. Enter the name of the instance you want to add and press [Link] instance
name must be unique.
6. Enter the port number which InfoSphere CDC uses for communication with client
workstations running Management Console and other servers. InfoSphere CDC
displays a default port of 10901. Press [Link] 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.
7. Press Enter to bypass auto-discovery. This feature is disabled by default.
8. 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 [Link]
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.
9. 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 [Link] 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.
10. Depending on the bit version of your server, enter 32 or 64 and press Enter.
11. 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. 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.
12. If you want InfoSphere CDC for Oracle databases to read only archived logs,
enter y and press Enter.
13. If you want to use TCP/IP as the exclusive method of communication between
datastores, enter n and press Enter. If you want to have the option to use either
a JMS provider or TCP/IP as the communications protocol, perform the following
steps:A JMS provider should be used when characteristics of your network
prevent the existence of a long-term, stable TCP/IP connection.
A. Ensure that a queue has been created by your system administrator and is
named correctly. Each InfoSphere CDC instance that is to use a JMS
message provider must have a queue named in the format CDC_<port>,
where <port> is the five digit TCP listening port number of the instance. You
70
 can left-pad the number with zeroes if necessary to ensure five digits
(example, CDC_00123).
B. Enter y and press Enter.
C. Enter 2 to add a JMS provider.
D. Enter the fully qualified path to your JMS provider .jar file and press Enter.
E. Enter 4 and press Enter to complete the configuration of the JMS providers.
F. Enter 1 to add a JMS connection.
G. Enter a JMS remote connection factory name and press Enter. For example,
jms/ConnectionFactory. A connection factory encapsulates a set of
connection configuration parameters that has been defined by an
administrator. InfoSphere CDC uses this to create a connection with your
JMS provider.
H. Enter the user name and press Enter.
I. Enter the password to authenticate to the JMS server and press Enter.
J. Enter the password a second time to confirm and press Enter.
K. Enter the JNDI initial context and press Enter.
L. Enter the URL that is relative to the JNDI Initial Context and press Enter.
M. Enter the user name for the JNDI Principal and press Enter.
N. Enter the JNDI credentials password and press Enter.
O. Enter the password a second time to confirm and press Enter.
P. Press Enter again to return to the Engine Communication Connection menu.
Q. Press 5 if you want to verify the connection and then press Enter to return to
the Engine Communication Connection [Link] the JMS Provider is not
configured correctly, InfoSphere CDC will use TCP/IP as the communication
protocol between datastores.
R. Enter 7 to complete the configuration of the engine communication
connection.
14. 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 [Link] you are configuring an instance for an Oracle RAC environment,
consider the following:
- 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 21 of this procedure.
- 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
[Link] file.
15. Enter the number that corresponds to the TNS name for your Oracle database
that you defined for InfoSphere CDC in the [Link] file and press Enter.
You can specify any TNS name except those in use by other installed instances
of InfoSphere CDC for the given [Link] the number of detected TNS names
is large, you will be offered the option of entering the TNS name directly or you
can press Enter to view the pages of TNS names.
16. If you want to specify extra JDBC parameters, perform the following steps.
Otherwise, enter n and press Enter.
A. Enter y and press Enter.
71
 B. Enter the extra JDBC parameters in a semicolon delimited list and press
Enter.
17. Enter the user name for the specified database and press [Link] you have
configured an Oracle database with a read-only connection, then specify the
read-only user for that database.
18. Enter the password for the specified database and press Enter. The
configuration tool will now search the database for schemas.
19. 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
[Link] 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.
20. Enter 1 to choose Local log reading as your configuration mode and press Enter
.
21. If you are using ASM exclusively to manage your Oracle redo logs, InfoSphere
CDC will detect it automatically and request the following information. If ASM is
not being used exclusively, you will be asked if you want to provide ASM
connection details. Enter y and press Enter to provide details or enter n and
press Enter to continue to the next step.
A. Enter the path information for the ASM instance (ASM ORACLE_HOME
environment variable) that is installed on the local node and press Enter.
B. Enter your ASM user name and press Enter.
C. Enter your ASM password and press Enter.
D. Enter the ASM ORCL path and press [Link] path should include the
machine where ORCL is mounted, and /disks folder.
For assistance in determining your ASM ORCL path, contact your database
administrator.
22. 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. 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:
- 1—Displays the available alternate encodings that are the closest match to
the database.
- 2—Displays the available alternate encodings in order of byte length.
- 3—Displays all available alternate encodings.
C. Enter the number for the encoding to be used and press Enter.
23. The configuration tool creates the InfoSphere CDC instance and prompts you to
start the instance. Enter y to start the [Link] configuration tool will prompt
you if your configuration is about to overwrite the metadata for an existing
instance.

Related concepts:
72
Port requirements
Creating queues in JMS providers

Related reference:
dmconfigurets - Configure InfoSphere CDC
dmbackupmd - Back up metadata

73
Configuring InfoSphere CDC for Oracle databases
for remote log reading
You can configure InfoSphere® CDC for Oracle databases for environments where
a source deployment of InfoSphere CDC for Oracle databases does not have direct
access to the Oracle online redo log files and archived log files because the product
is installed on a different machine from your source database.
The InfoSphere CDC for Oracle databases log reader supports only direct access to
the Oracle redo log files with a shared Storage Area Network (SAN) file system or
remote access with a shared Network File System (NFS) mount. There is no support
for custom options such as manually copying files.
By default, the product is configured to read both online redo log files and archived
log files. This provides for low latency replication as the online log is continuously
written by Oracle and read by the InfoSphere CDC for Oracle databases log reader.
However, the product can also be configured for reading archive log files only.
See also:

- To add a new instance of InfoSphere CDC for Oracle databases that reads logs
remotely

Related tasks:
To set up a remote connection

74
To add a new instance of InfoSphere CDC for Oracle
databases that reads logs remotely
Procedure
1. If you are configuring the first instance of InfoSphere® CDC for Oracle
databases after installation, you can proceed to Step 4 of this procedure.
2. At the command prompt, launch the configuration tool by issuing the following
command in the specified directory:\<InfoSphere CDC Installation Directory>\bin\dmconfigurets
3. If you are configuring instances subsequent to the first instance, enter 2 and
press [Link] to Step 5 of this procedure.
4. At the welcome message, press Enter to continue.
5. Enter the name of the instance you want to add and press [Link] instance
name must be unique.
6. Enter the port number which InfoSphere CDC uses for communication with client
workstations running Management Console and other servers. InfoSphere CDC
displays a default port of 10901. Press [Link] 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.
7. Press Enter to bypass auto-discovery. This feature is disabled by default.
8. 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 [Link]
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.
9. 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 [Link] 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.
10. Depending on the bit version of your server, enter 32 or 64 and press Enter.
11. 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. 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.
12. If you want InfoSphere CDC for Oracle databases to read only archived logs,
enter y and press Enter.
13. If you want to use TCP/IP as the exclusive method of communication between
datastores, enter n and press Enter. If you want to have the option to use either
a JMS provider or TCP/IP as the communications protocol, perform the following
steps:A JMS provider should be used when characteristics of your network
prevent the existence of a long-term, stable TCP/IP connection.
A. Ensure that a queue has been created by your system administrator and is
named correctly. Each InfoSphere CDC instance that is to use a JMS
message provider must have a queue named in the format CDC_<port>,
where <port> is the five digit TCP listening port number of the instance. You
75
 can left-pad the number with zeroes if necessary to ensure five digits
(example, CDC_00123).
B. Enter y and press Enter.
C. Enter 2 to add a JMS provider.
D. Enter the fully qualified path to your JMS provider .jar file and press Enter.
E. Enter 4 and press Enter to complete the configuration of the JMS providers.
F. Enter 1 to add a JMS connection.
G. Enter a JMS remote connection factory name and press Enter. For example,
jms/ConnectionFactory. A connection factory encapsulates a set of
connection configuration parameters that has been defined by an
administrator. InfoSphere CDC uses this to create a connection with your
JMS provider.
H. Enter the user name and press Enter.
I. Enter the password to authenticate to the JMS server and press Enter.
J. Enter the password a second time to confirm and press Enter.
K. Enter the JNDI initial context and press Enter.
L. Enter the URL that is relative to the JNDI Initial Context and press Enter.
M. Enter the user name for the JNDI Principal and press Enter.
N. Enter the JNDI credentials password and press Enter.
O. Enter the password a second time to confirm and press Enter.
P. Press Enter again to return to the Engine Communication Connection menu.
Q. Press 5 if you want to verify the connection and then press Enter to return to
the Engine Communication Connection [Link] the JMS Provider is not
configured correctly, InfoSphere CDC will use TCP/IP as the communication
protocol between datastores.
R. Enter 7 to complete the configuration of the engine communication
connection.
14. 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 [Link] you are configuring an instance for an Oracle RAC environment,
consider the following:
- 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 21 of this procedure.
- 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
[Link] file.
15. Enter the number that corresponds to the TNS name for your Oracle database
that you defined for InfoSphere CDC in the [Link] file and press Enter.
You can specify any TNS name except those in use by other installed instances
of InfoSphere CDC for the given [Link] the number of detected TNS names
is large, you will be offered the option of entering the TNS name directly or you
can press Enter to view the pages of TNS names.
16. If you want to specify extra JDBC parameters, perform the following steps.
Otherwise, enter n and press Enter.
A. Enter y and press Enter.
76
 B. Enter the extra JDBC parameters in a semicolon delimited list and press
Enter.
17. Enter the user name for the specified database and press [Link] you have
configured an Oracle database with a read-only connection, then specify the
read-only user for that database.
18. Enter the password for the specified database and press Enter. The
configuration tool will now search the database for schemas.
19. 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
[Link] 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.
20. Enter 2 to choose Remote log reading as your configuration mode and press
Enter.
21. If you are using ASM exclusively to manage your Oracle redo logs, InfoSphere
CDC will detect it automatically and request the following information. If ASM is
not being used exclusively, you will be asked if you want to provide ASM
connection details. Enter y and press Enter to provide details or enter n and
press Enter to continue to the next step.
A. Enter the path information for the ASM instance (ASM ORACLE_HOME
environment variable) that is installed on the local node and press Enter.
B. Enter your ASM user name and press Enter.
C. Enter your ASM password and press Enter.
D. Enter your ASM SID and press Enter.
E. Enter the ASM ORCL path and press [Link] path should include the
machine where ORCL is mounted, and /disks folder.
For assistance in determining your ASM ORCL path, contact your database
administrator.
22. Enter 2 to add a mount point override and press [Link] mount point is the
location of the log in the local host where the InfoSphere CDC instance is
installed. For remote log reading, you need to override this value if the
directories for the local and remote host are different.
23. Enter the mount point path and press Enter.
24. Enter the mount point override path and press Enter.
25. Enter 5 and press Enter to complete the configuration of mount point overrides.
You should test the mount point override before proceeding with the creation of
the instance. Configuration will not complete successfully if the overrides are not
properly defined.
26. 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. 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:
- 1—Displays the available alternate encodings that are the closest match to
77
 the database.
- 2—Displays the available alternate encodings in order of byte length.
- 3—Displays all available alternate encodings.
C. Enter the number for the encoding to be used and press Enter.
27. The configuration tool creates the InfoSphere CDC instance and prompts you to
start the instance. Enter y to start the [Link] configuration tool will prompt
you if your configuration is about to overwrite the metadata for an existing
instance.

Related concepts:
Port requirements
Creating queues in JMS providers

Related reference:
dmconfigurets - Configure InfoSphere CDC
dmbackupmd - Back up metadata

78
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.
When shipping logs using Data Guard, you have the option of enabling InfoSphere
CDC to access the physical standby database to gather log location and availability
information. The following requirements exist for log shipping using Data Guard:
- InfoSphere CDC must be installed on the same machine as the physical standby
database.
- The physical standby database should be in mounted mode or opened mode.
- The physical standby database must have a TNS name entry defined in
[Link].
- The archive logs shipped to the standby database should not be ASM managed
logs.
Consider the following prerequisites and requirements when configuring InfoSphere
CDC for Oracle databases for log shipping:
- You must use either manual log shipping using custom scripts or the Data Guard
component, not a combination of both methods.
- The Endianess of both the InfoSphere CDC server and the origin of the archive
logs must be the same. That is to say, InfoSphere CDC installed on a Little Endian
machine cannot read logs that are shipped from a Big Endian machine.
See also:

- To add a new instance of InfoSphere CDC for Oracle databases with log shipping
using Data Guard
- To add a new instance of InfoSphere CDC for Oracle databases with manual log
shipping
- To ship logs using custom scripts

79
To add a new instance of InfoSphere CDC for Oracle
databases with log shipping using Data Guard
Procedure
1. If you are configuring the first instance of InfoSphere® CDC for Oracle
databases after installation, you can proceed to Step 4 of this procedure.
2. At the command prompt, launch the configuration tool by issuing the following
command in the specified directory:\<InfoSphere CDC Installation Directory>\bin\dmconfigurets
3. If you are configuring instances subsequent to the first instance, enter 2 and
press [Link] to Step 5 of this procedure.
4. At the welcome message, press Enter to continue.
5. Enter the name of the instance you want to add and press [Link] instance
name must be unique.
6. Enter the port number which InfoSphere CDC uses for communication with client
workstations running Management Console and other servers. InfoSphere CDC
displays a default port of 10901. Press [Link] 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.
7. Press Enter to bypass auto-discovery. This feature is disabled by default.
8. 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 [Link]
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.
9. 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 [Link] 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.
10. Depending on the bit version of your server, enter 32 or 64 and press Enter.
11. 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. 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.
12. If you want InfoSphere CDC for Oracle databases to read only archived logs,
enter y and press Enter.
13. If you want to use TCP/IP as the exclusive method of communication between
datastores, enter n and press Enter. If you want to have the option to use either
a JMS provider or TCP/IP as the communications protocol, perform the following
steps:A JMS provider should be used when characteristics of your network
prevent the existence of a long-term, stable TCP/IP connection.
A. Ensure that a queue has been created by your system administrator and is
named correctly. Each InfoSphere CDC instance that is to use a JMS
message provider must have a queue named in the format CDC_<port>,
where <port> is the five digit TCP listening port number of the instance. You
80
 can left-pad the number with zeroes if necessary to ensure five digits
(example, CDC_00123).
B. Enter y and press Enter.
C. Enter 2 to add a JMS provider.
D. Enter the fully qualified path to your JMS provider .jar file and press Enter.
E. Enter 4 and press Enter to complete the configuration of the JMS providers.
F. Enter 1 to add a JMS connection.
G. Enter a JMS remote connection factory name and press Enter. For example,
jms/ConnectionFactory. A connection factory encapsulates a set of
connection configuration parameters that has been defined by an
administrator. InfoSphere CDC uses this to create a connection with your
JMS provider.
H. Enter the user name and press Enter.
I. Enter the password to authenticate to the JMS server and press Enter.
J. Enter the password a second time to confirm and press Enter.
K. Enter the JNDI initial context and press Enter.
L. Enter the URL that is relative to the JNDI Initial Context and press Enter.
M. Enter the user name for the JNDI Principal and press Enter.
N. Enter the JNDI credentials password and press Enter.
O. Enter the password a second time to confirm and press Enter.
P. Press Enter again to return to the Engine Communication Connection menu.
Q. Press 5 if you want to verify the connection and then press Enter to return to
the Engine Communication Connection [Link] the JMS Provider is not
configured correctly, InfoSphere CDC will use TCP/IP as the communication
protocol between datastores.
R. Enter 7 to complete the configuration of the engine communication
connection.
14. 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 [Link] you are configuring an instance for an Oracle RAC environment,
consider the following:
- 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.
- 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
[Link] file.
15. Enter the number that corresponds to the TNS name for your Oracle database
that you defined for InfoSphere CDC in the [Link] file and press Enter.
You can specify any TNS name except those in use by other installed instances
of InfoSphere CDC for the given [Link] the number of detected TNS names
is large, you will be offered the option of entering the TNS name directly or you
can press Enter to view the pages of TNS names.
16. 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.
81
17. Enter the user name for the specified database and press [Link] you have
configured an Oracle database with a read-only connection, then specify the
read-only user for that database.
18. Enter the password for the specified database and press Enter. The
configuration tool will now search the database for schemas.
19. 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
[Link] 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.
20. Enter 4 to choose Log shipping with Data Guard as your configuration mode and
press Enter.
21. Enter the archive log directory and press [Link] is the directory where the
logs are shipped by DataGuard to the machine where InfoSphere CDC is
installed. Specify the full path of the destination.
22. Enter the log name pattern from the standby database to identify the logs and
press [Link] log name pattern must contain the %t (thread id) variable and
%s (sequence number) variable in order to identify which logs are associated
with each node. InfoSphere CDC will fail with an error if those variables are not
specified.
23. Enter the number that corresponds to the transport ID and press [Link] the
number of detected transport IDs is large, you will be offered the option of
entering the transport ID directly or you can press Enter to view the pages of
transport IDs.
24. If you want to specify a physical standby connection, perform the following
steps. To use the primary database connection, enter n and press Enter.
A. Enter y and press Enter.
B. Enter the path for the ORACLE_HOME variable for the physical standby
database and press Enter.
C. Enter the number that corresponds to the TNS name for your physical
standby database that you defined for InfoSphere CDC in the [Link]
file and press Enter. You can specify any TNS name except those in use by
other installed instances of InfoSphere CDC for the given [Link] the
number of detected TNS names is large, you will be offered the option of
entering the TNS name directly or you can press Enter to view the pages of
TNS names.
D. Enter the user name for the physical standby database and press [Link]
user must have SYSDBA privileges.
E. Enter the password for the physical standby database user and press Enter.
25. 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. If you enter n and press Enter to cancel, the instance will
not be created.
82
 B. Enter a value to choose how the alternate encodings will be displayed:
- 1—Displays the available alternate encodings that are the closest match to
the database.
- 2—Displays the available alternate encodings in order of byte length.
- 3—Displays all available alternate encodings.
C. Enter the number for the encoding to be used and press Enter.
26. The configuration tool creates the InfoSphere CDC instance and prompts you to
start the instance. Enter y to start the [Link] configuration tool will prompt
you if your configuration is about to overwrite the metadata for an existing
instance.

Related concepts:
Port requirements
Creating queues in JMS providers

Related reference:
dmconfigurets - Configure InfoSphere CDC
dmbackupmd - Back up metadata

83
To add a new instance of InfoSphere CDC for Oracle
databases with manual log shipping
Procedure
1. If you are configuring the first instance of InfoSphere® CDC for Oracle
databases after installation, you can proceed to Step 4 of this procedure.
2. At the command prompt, launch the configuration tool by issuing the following
command in the specified directory:\<InfoSphere CDC Installation Directory>\bin\dmconfigurets
3. If you are configuring instances subsequent to the first instance, enter 2 and
press [Link] to Step 5 of this procedure.
4. At the welcome message, press Enter to continue.
5. Enter the name of the instance you want to add and press [Link] instance
name must be unique.
6. Enter the port number which InfoSphere CDC uses for communication with client
workstations running Management Console and other servers. InfoSphere CDC
displays a default port of 10901. Press [Link] 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.
7. Press Enter to bypass auto-discovery. This feature is disabled by default.
8. 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 [Link]
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.
9. 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 [Link] 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.
10. Depending on the bit version of your server, enter 32 or 64 and press Enter.
11. 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. 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.
12. If you want InfoSphere CDC for Oracle databases to read only archived logs,
enter y and press Enter.
13. If you want to use TCP/IP as the exclusive method of communication between
datastores, enter n and press Enter. If you want to have the option to use either
a JMS provider or TCP/IP as the communications protocol, perform the following
steps:A JMS provider should be used when characteristics of your network
prevent the existence of a long-term, stable TCP/IP connection.
A. Ensure that a queue has been created by your system administrator and is
named correctly. Each InfoSphere CDC instance that is to use a JMS
message provider must have a queue named in the format CDC_<port>,
where <port> is the five digit TCP listening port number of the instance. You
84
 can left-pad the number with zeroes if necessary to ensure five digits
(example, CDC_00123).
B. Enter y and press Enter.
C. Enter 2 to add a JMS provider.
D. Enter the fully qualified path to your JMS provider .jar file and press Enter.
E. Enter 4 and press Enter to complete the configuration of the JMS providers.
F. Enter 1 to add a JMS connection.
G. Enter a JMS remote connection factory name and press Enter. For example,
jms/ConnectionFactory. A connection factory encapsulates a set of
connection configuration parameters that has been defined by an
administrator. InfoSphere CDC uses this to create a connection with your
JMS provider.
H. Enter the user name and press Enter.
I. Enter the password to authenticate to the JMS server and press Enter.
J. Enter the password a second time to confirm and press Enter.
K. Enter the JNDI initial context and press Enter.
L. Enter the URL that is relative to the JNDI Initial Context and press Enter.
M. Enter the user name for the JNDI Principal and press Enter.
N. Enter the JNDI credentials password and press Enter.
O. Enter the password a second time to confirm and press Enter.
P. Press Enter again to return to the Engine Communication Connection menu.
Q. Press 5 if you want to verify the connection and then press Enter to return to
the Engine Communication Connection [Link] the JMS Provider is not
configured correctly, InfoSphere CDC will use TCP/IP as the communication
protocol between datastores.
R. Enter 7 to complete the configuration of the engine communication
connection.
14. 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.
15. Enter the number that corresponds to the TNS name for your Oracle database
that you defined for InfoSphere CDC in the [Link] file and press Enter.
You can specify any TNS name except those in use by other installed instances
of InfoSphere CDC for the given [Link] the number of detected TNS names
is large, you will be offered the option of entering the TNS name directly or you
can press Enter to view the pages of TNS names.
16. 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.
17. Enter the user name for the specified database and press [Link] you have
configured an Oracle database with a read-only connection, then specify the
read-only user for that database.
18. Enter the password for the specified database and press Enter. The
configuration tool will now search the database for schemas.
85
19. 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
[Link] 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.
20. Enter 3 to choose Manual log shipping as your configuration mode and press
Enter.
21. 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. 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:
- 1—Displays the available alternate encodings that are the closest match to
the database.
- 2—Displays the available alternate encodings in order of byte length.
- 3—Displays all available alternate encodings.
C. Enter the number for the encoding to be used and press Enter.
22. The configuration tool creates the InfoSphere CDC instance and prompts you to
start the instance. Enter y to start the [Link] configuration tool will prompt
you if your configuration is about to overwrite the metadata for an existing
instance.

Related concepts:
Port requirements
Creating queues in JMS providers

Related reference:
dmconfigurets - Configure InfoSphere CDC
dmbackupmd - Back up metadata

86
To ship logs using custom scripts
Procedure
1. Make the logs available to InfoSphere® CDC by having the script issue the
dmarchivelogavailable command.
2. Indicate which logs are no longer required by InfoSphere CDC by issuing the
dmshowlogdependancy command.
3. Unregister the logs for InfoSphere CDC by issuing the dmarchivelogremoved
command.
4. Purge the logs from the InfoSphere CDC system using a purge or cleanup
application of your [Link] that InfoSphere CDC does not clean up the logs
from your system.
Example
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 "[Link]"

# All subscription name have to be listed in [Link] file.

# ./cdc_fil_remove.ksh > archived_log.lst

# -------------------------------------------------------------------

cdc_home=<CDC_install_path>

#echo $cdc_home cdc_arc=<archive_log_directory_path>

#echo $cdc_arc

rm [Link]

touch [Link]

while read aa

do

eflnm='$cdc_home/bin/dmshowlogdependency -I cdcdevsrc -i -s $aa

| grep ,Available,Exists | awk

'{print(substr($1,22))}' | sed 's/,Available,Exists//''

#echo "$eflnm"

echo "$eflnm" >>[Link]

done<[Link]

cat [Link] | awk '{print(substr($1,3))}'|sed 's/_..*//' > [Link]

sort -n [Link] > [Link] nfl=`cat [Link]| head -1'

#echo "$nfl"

ls -ltr $cdc_arc/* | awk '{print(substr($9,22))}' > [Link]

#echo "$arclst"

while read aa

do

aan='echo $aa | awk '{print(substr($1,3))}' | sed 's/_..*//''

if [ $aan -lt $nfl ]

then

echo "rm $cdc_arc$aa"

87
else

echo "No need to remove any files"

fi

done<[Link]

cat archvied_log.lst | grep **.arc > rm_arch_log.ksh#./rm_arch_log.ksh

#./rm_arch_log.ksh

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: <script_name> <file_name>

# For example: cdc_fil_avail.ksh newflnlst

# -------------------------------------------------------------------

cdc_home=<CDC_install_path>

arc_f=<archive_log_path>

#echo $cdc_home

#echo $arc_f

fnm1='ls -ltr $arc_f/* | awk '{print(substr($9,3))}''

echo "$fnm1" > oldflnlst

#echo "$fnm1"

nof='cat oldfln'

#echo $nof

while read aa

do

aan='echo $aa | awk '{print(substr($1,22))}' | sed 's/_..*//''

#echo $aan

if [ $aan -gt $nof ]

then

aann='echo $aa | awk '{print(substr($1,20))}''

echo "$cdc_home/bin/dmarchivelogavailable -I cdcdevsrc -f $aann"

else

echo "There is no new file"

fi done <oldflnlst

fnm='ls -ltr $arc_f | awk '{print(substr($9,3))}'|tail -1 | sed 's/_..*//''

echo "$fnm" > oldfln

cat newflnlst | grep dmarchivelogavailable > [Link]

./[Link]

88
Editing an instance of InfoSphere CDC for Oracle
databases
InfoSphere® CDC for Oracle databases allows you to edit a number of values that
you specified when adding an instance.
See also:

- To edit an instance of InfoSphere CDC for Oracle databases

89
To edit an instance of InfoSphere CDC for Oracle
databases
Procedure
1. Stop InfoSphere® CDC 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 <InfoSphere CDC Installation Directory>/bin directory:
./dmconfigurets
3. Enter 1 and press Enter to list the installed instances of InfoSphere CDC. Record
the name of the instance you want to modify.
4. Enter 3 and press Enter to modify an instance of InfoSphere CDC.
5. Enter the number of the instance that you want to modify and press [Link]
configuration tool allows you to edit a number of values that you specified when
adding an instance.
6. After making your changes, enter 5 and press Enter to apply your changes and
return to the main menu. Enter 6 and press Enter to discard your changes.

90
Deleting an instance of InfoSphere CDC for Oracle
databases
You can delete your instance of InfoSphere® CDC for Oracle databases.
See also:

- To delete an instance of InfoSphere CDC for Oracle databases

91
To delete an instance of InfoSphere CDC for Oracle
databases
Procedure
1. Stop InfoSphere® CDC by using the dmshutdown command.
2. At the command prompt, launch the configuration tool by issuing the following
command from the <InfoSphere CDC installation directory>/bin directory:
./dmconfigurets
3. Enter 1 and press Enter to list the installed instances of InfoSphere CDC. Record
the name of the instance you want to delete.
4. Enter 4 and press Enter to delete an instance of InfoSphere CDC.
5. Enter the instance name that you want to delete and press Enter.

92
After you install and configure InfoSphere CDC for
Oracle databases
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 for Oracle databases
- Stopping InfoSphere CDC for Oracle databases
- Performing an external refresh
- Maintaining active TCP connections in a network environment
- Enabling SQL statements in Management Console

93
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-
[Link] script located in the /samples directory of your installation of InfoSphere
CDC.
See also:

- Privileges for Oracle users

94
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.
Table 1. Oracle user permissions required by InfoSphere CDC

Permissions Permissions required by Permissions required by

InfoSphere CDC for an InfoSphere CDC for an
Oracle user Oracle user with a read-
only connection to the
source database
Basic Roles
grant connect to cdc_user; ✓ ✓
grant resource to ✓ ✓
cdc_user;
grant select_catalog_role ✓ ✓
to cdc_user;
Table DDL Permissions
grant create any table to ✓
cdc_user;
grant alter any table to ✓
cdc_user;
grant drop any table to ✓
cdc_user;
grant lock any table to ✓
cdc_user;
Table DML Permissions
grant select any table to ✓ ✓
cdc_user;
grant insert any table to ✓
cdc_user;
grant update any table to ✓
cdc_user;
grant delete any table to ✓
cdc_user;
Index and View DML Permissions
grant create any index to ✓
cdc_user;
grant alter any index to ✓
cdc_user;
grant drop any index to ✓
cdc_user;
grant create any view to ✓
cdc_user;
grant drop any view to ✓
cdc_user;
95
Trigger DDL and DML Permissions
grant create any trigger to ✓
cdc_user;
grant alter any trigger to ✓
cdc_user;
grant drop any trigger to ✓
cdc_user;
Sequence DDL and DML Permissions
grant create any sequence ✓
to cdc_user;
grant select any sequence ✓
to cdc_user;
Procedure Permissions
grant create any procedure ✓
to cdc_user;
grant execute any ✓
procedure to cdc_user;
Procedure to perform v_$ on tables
grant select any dictionary ✓ ✓
to cdc_user;
General system views
grant select on ✓ ✓
sys.v_$database to
cdc_user ;
grant select on ✓ ✓
sys.v_$controlfile to
cdc_user ;
grant select on ✓ ✓
sys.v_$version to
cdc_user;
grant select on ✓ ✓
sys.nls_database_paramet
ers to cdc_user ;
Archive and redo logs
grant select on sys.v_$log ✓ ✓
to cdc_user;
grant select on ✓ ✓
sys.v_$logfile to cdc_user;
grant select on ✓ ✓
sys.v_$archived_log to
cdc_user ;
grant select on ✓ ✓
sys.v_$log_history to
cdc_user ;
Sessions and transactions
grant alter session to ✓ ✓
cdc_user;
96
grant select on ✓ ✓
sys.v_$session to
cdc_user;
grant select on ✓ ✓
sys.gv_$session to
cdc_user ;
grant select on ✓ ✓
sys.v_$transaction to
cdc_user ;
grant select on ✓ ✓
sys.v_$mystat to cdc_user;
Tables, indexes, columns, and related views
grant select on ✓ ✓
sys.all_coll_types to
cdc_user ;
grant select on ✓ ✓
sys.all_type_attrs to
cdc_user ;
grant select on ✓ ✓
sys.dba_tables to
cdc_user;
grant select on ✓ ✓
sys.dba_tab_comments to
cdc_user;
grant select on ✓ ✓
sys.dba_tab_columns to
cdc_user ;
grant select on ✓ ✓
sys.dba_col_comments to
cdc_user;
grant select on ✓ ✓
sys.dba_indexes to
cdc_user ;
grant select on ✓ ✓
sys.dba_ind_columns to
cdc_user ;
grant select on ✓ ✓
sys.all_constraints to
cdc_user ;
grant select on ✓ ✓
sys.dba_constraints to
cdc_user ;
grant select on ✓ ✓
sys.all_cons_columns to
cdc_user ;
grant select on ✓ ✓
sys.dba_cons_columns to
cdc_user ;

97
grant select on [Link]$ to ✓ ✓
cdc_user;
grant select on [Link]$ to ✓ ✓
cdc_user;
grant select on [Link]$ to ✓ ✓
cdc_user;
grant select on [Link]$ to ✓ ✓
cdc_user;
grant select on [Link]$ to ✓ ✓
cdc_user;
grant select on ✓ ✓
[Link]$ to cdc_user;
grant select on [Link]$ ✓ ✓
to cdc_user;
grant select on [Link]$ to ✓ ✓
cdc_user;
grant select on [Link]$ ✓ ✓
to cdc_user;
Miscellaneous other objects
grant select on [Link]$ to ✓ ✓
cdc_user;
grant select on ✓ ✓
sys.dba_mviews to
cdc_user;
grant select on ✓ ✓
sys.dba_objects to
cdc_user ;
grant select on ✓ ✓
sys.dba_sequences to
cdc_user ;
grant select on ✓ ✓
sys.hist_head$ to
cdc_user;
grant select on ✓ ✓
sys.resource_cost to
cdc_user ;
Storage
grant select on ✓ ✓
sys.dba_tablespaces to
cdc_user ;
grant select on ✓ ✓
sys.dba_rollback_segs to
cdc_user ;
Permissions
grant select on ✓ ✓
sys.dba_users to
cdc_user;

98
grant select on ✓ ✓
sys.dba_sys_privs to
cdc_user;
grant select on ✓ ✓
sys.dba_tab_privs to
cdc_user;
grant select on ✓ ✓
sys.dba_profiles to
cdc_user ;
grant select on ✓ ✓
sys.dba_roles to cdc_user;
grant select on [Link]$ ✓ ✓
to cdc_user;
grant select on ✓ ✓
user_role_privs to
cdc_user ;
grant flashback any_table ✓
to cdc_user;

99
Starting InfoSphere CDC for Oracle databases
After you install InfoSphere® CDC for Oracle databases 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 for Oracle databases (UNIX and Linux)

100
To start InfoSphere® CDC for Oracle databases
(UNIX and Linux)
Procedure
Depending on the operating system you are running, issue one of the following start
commands:
- dmts32 - I <instance_name>
- dmts64 - I <instance_name>

101
Stopping InfoSphere CDC for Oracle databases
It may be necessary to stop InfoSphere® CDC when you want to change the
configuration settings, take a server or database offline for maintenance purposes,
or if you want to upgrade InfoSphere CDC. You can use the configuration tool or
commands to stop InfoSphere CDC.
See also:

- To stop InfoSphere CDC for Oracle databases (UNIX and Linux)

102
To stop InfoSphere CDC for Oracle databases (UNIX
and Linux)
Procedure
1. End replication on all subscriptions in Management Console. For more
information on how to end replication on subscriptions, see your Management
Console documentation.
2. 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 Use this command to gracefully
<instance_name>] shut down InfoSphere CDC. 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 <locale>] Use this command to terminate
all processes for all instances
running on a UNIXor Linux
server.
Use this command when you
cannot completely shut down
InfoSphere CDC using the
dmshutdown command.

103
Performing an external refresh
You can perform a refresh of one or more tables in a subscription using a third-party
tool, and still integrate this activity into the refresh while active capability of
InfoSphere® CDC. Such third-party tools might be a table unload at source and
load at target, an application program that regenerates the content of a table being
run against both the source and target tables, recovery of a table's content to a prior
point in time at both the source and target, or even a refresh of the table using a
subscription other than the one that will be mirroring the data. A refresh or
reconstruction of a table by such a means is referred to as an external refresh.
Note: An external refresh can only be performed when the target is database, not a
message queue or an ETL solution. Performing an external refresh using the
dmmarkexternalunloadstart and dmmarkexternalunloadend commands is not
supported for the following replication engines:
- InfoSphere CDC for InfoSphere DataStage® (either Direct Connect or Flat File)
- InfoSphere CDC Event Server
- InfoSphere Classic CDC for z/OS®

In order to integrate the activity of the external refresh into the mirroring activity of
the subscription, new command capabilities have been added to the products. To
understand what these commands do, how to provide usable data to them, and
what to avoid so that they won't be misused, it is necessary to understand the
mechanism of refresh while active processing.
Understanding refresh while active
When a table within a subscription is set to Method:Mirror and Status:Refresh, it is
readied for a refresh while active. When the subscription is started, as viewed
externally, the table is refreshed and then mirroring of the tables in the subscription
starts. When the subscription starts, it must necessarily start scraping from the log at
a place prior to the place when the refresh was performed. For the table that was
refreshed at the start of mirroring, changes scraped from the log are discarded until
scraping reaches the place where the refresh had started. From that point forward,
changes scraped for that table are forwarded to the target for application to the
target table. Between the place in the log where the refresh started and the place
where the refresh ended, a change scraped from the log could either have been
applied to the table or not yet have been applied to the table by the time that portion
of the table was refreshed. Thus the change may or may not have been forwarded
to the target and been applied to the target table during the refresh. For this reason,
changes scraped from the log between the places where the refresh ran are applied
at the target with an error mitigation filter that suppresses operational errors
(INSERT of a preexisting row, UPDATE or DELETE of a nonexisting row). These
changes are said to be sent with the "indefinitely refreshed" indicator set. Once
scraping proceeds past the place in the log where the refresh ended, the indefinitely
refreshed indicator is no longer set, and operational errors are treated as harshly as
any [Link] is possible that changes that have been logged before the place in the
log when the refresh started were not yet committed when the refresh started. Such
changes would appear in the table after the COMMIT was issued, but would be
discarded when they were scraped from the log because they were logged prior to
the refresh starting place in the log. The capture of the table's content during the
refresh could miss these changes, depending on how much time passes before the
104
COMMIT is issued. This would cause the source and target tables to be
unsynchronized. To avoid this, InfoSphere CDC uses methods based on the DBMS
in use to establish a point of consistency for the table at the time that the refresh for
a refresh while active is starting. For example, on the z/OS platform, before the
refresh starts, a shared lock with a table scope is obtained on the table being
refreshed. The current log write position is determined, then the lock is released.
This forces any units of recovery that contain changes for the table being locked to
complete (that is, a COMMIT). When the shared lock is released the refresh starts,
and the log write position sampled while the lock was held will be used as the place
for the start of the refresh. The shared lock is held for milliseconds at most, and
should not be disruptive to normal application processing for the table.

Considerations for an external refresh

When an external refresh occurs, it involves the capturing of the source table's
content and the writing of that content to the target table. The period when the
source table's content is being captured is equivalent to the period during a refresh
while active when the source table is being read. Depending on how the source and
target tables are being re-synchronized outside of the subscription, this period could
be significantly long (for example, using unload and load) or effectively
instantaneous (for example, point-in-time recovery at both source and target). For
InfoSphere CDC for z/OS, this period needs to be converted to a starting place and
an ending place in the log, expressed in terms of log positions in the DBMS's log.
The two (possibly identical) log positions are then provided to InfoSphere CDC using
the command interface, and InfoSphere CDC updates the metadata with them as
though they had originated from the execution of the refresh of a refresh while active
. When the subscription starts to mirror, these two log positions describe the scrape
point when discarding of the table's data stops and marking changes as 'indefinitely
refreshed starts, and when marking changes as indefinitely refreshed stops.
For all other supported engines, the refresh while active period is determined by the
current position of the log when the dmmarkexternalunloadstart and
dmmarkexternalunloadend commands are issued.

In order for this update to the metadata to be effective and productive, the following
have to be true:
1. The subscription must not be active, as is always the case when a subscription's
attributes are being modified.
2. The first (earlier) of the two log positions must not be earlier than the log position
where the subscription will start scraping. If this rule is not followed, the results
are not predictable.
3. Neither of the two log positions should be for a place that has not yet been written
to the log. If this rule is not followed, the results are not predictable.
In addition to these considerations, there is also the issue of establishing a point of
consistency at the start of capturing the source table for the external refresh. When
performing a refresh while active, as explained above, a point of consistency for the
table being refreshed is established by acquiring a shared lock with table scope.
This method is unavailable when doing an external refresh, so other means of
establishing a point of consistency should be employed. Sometimes, this will not be
possible, such as for a point-in-time recovery at both the source and target. If it is
105
possible, such as when performing an unload and reload, then it is strongly
recommended that a point of consistency be established. This can be done by
quiescing activity against the table, or simply by stopping all updating application
programs. Sometimes it may not be necessary, such as when a program is used to
regenerate the entire table content at both the source and target (assuming such a
program would, by its action, implicitly lock the entire table). Failure to take the steps
to establish a point of consistency could produce operational errors later, under the
scenario described above.

- To perform an external refresh

Related reference:
dmmarkexternalunloadend - End table data unload
dmmarkexternalunloadstart - Start table data unload

106
To perform an external refresh
Procedure
1. Stop the subscription, if it is currently running.
2. Run the dmmarkexternalunloadstart command.
3. Use an external tool to unload the table [Link] should determine if there are
any limitations on transaction isolation levels by your external tool.
4. Wait for the unload to complete.
5. Run the dmmarkexternalunloadend command.
6. Use your external tool to load the table data on the target.
7. Start the [Link]® CDC will reconcile the differences
corresponding to the changes made to the source table during the
synchronization phase. InfoSphere CDC runs in the manner of Adaptive Apply
during the range marked by the start and end commands.

Related reference:
dmmarkexternalunloadend - End table data unload
dmmarkexternalunloadstart - Start table data unload

107
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

108
To maintain active TCP connections
Procedure
1. For each instance of InfoSphere® CDC, navigate to the following directory:UNIX
or Linux:
<CDC_installation_directory>/instance/<instance_name>/conf

2. Open the [Link] file in a text editor.

3. Change the KEEP_ALIVE_TIMEOUT parameter to a value that is less than the
time used to detect idle connections in your network. For example, if your
network disables idle TCP connections after 15 seconds, you can change the
KEEP_ALIVE_TIMEOUT parameter to a value of 10 seconds:KEEP_ALIVE_TIMEOUT=10
4. Save the [Link] file.
5. For the changes to take effect, use the configuration tool to restart all instances of
InfoSphere CDC.
What to do next
InfoSphere CDC will now send messages over the TCP connection every 10
seconds.

109
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

110
To enable SQL statements in Management Console
Procedure
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 [Link]: 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 [Link]: The table can have any structure
and must be created in the schema you specified when you configured
InfoSphere CDC.

Related concepts:
InfoSphere CDC for Oracle databases metadata tables

111
InfoSphere CDC for Oracle databases metadata
tables
InfoSphere® CDC maintains a set of metadata tables that represent data about your
current replication configuration. These tables are created in the schema and
database that you specify in the configuration tool and should be part of the backup
strategy for your database. InfoSphere CDC will not replicate these tables. Do not
modify the contents of these tables unless requested to do so by your IBM®
representative.
The names of the metadata tables created by InfoSphere CDC are as follows:
- TS_AUTHNote: For all users you added in the Access Manager perspective in
Management Console, make sure you give GRANT SELECT privileges to the
TS_AUTH metadata table.
- TS_BOOKMARK
- TS_CONFAUD—The conflict resolution audit table records information about
conflicts that were resolved using conflict detection and resolution.
- TS_DDLAUD—The DDL replication audit table.

Related concepts:
Configuring instances of InfoSphere CDC for Oracle databases

112
Data types supported by InfoSphere CDC
For information about data types supported by InfoSphere® CDC for Oracle
databases, see Supported datatypes.

113
System parameters for InfoSphere CDC for Oracle
databases
For information about system parameters for InfoSphere® CDC for Oracle
databases, see System parameters for InfoSphere CDC for Oracle databases.

114
Commands for InfoSphere CDC for Oracle
databases
This section discusses the commands available with InfoSphere® CDC. Using these
commands you can control replication, manage your tables for replication, monitor
replication, and perform various other tasks.
In this section, you will learn:

- Using the InfoSphere CDC for Oracle databases commands

- Setting the TSINSTANCE environment variable
- Continuous Capture commands
- Controlling replication commands
- Database transaction log commands
- Supplemental logging commands
- Single scrape and staging store commands
- Exporting and importing configuration commands
- Managing tables for replication commands
- Monitoring replication commands
- Other commands

115
Using the InfoSphere CDC for Oracle databases
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 and Linux
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:
- Syntax—Identifies the name of the command and lists the command parameters.
- Parameters—Describes each parameter in the command and identifies the values
that can be specified.
- Result—Indicates the values that are returned by the command if it is successful.
These values can be useful for scripting. This section also specifies the information
that is displayed on the screen, if any, as a result of executing the command.
- Examples—Provides one or more examples of invoking the command.

Parameter formats
Note the following conventions in the definition of the command parameters:
- Angle brackets ( < > ) indicate a mandatory parameter.
- Brackets ( [ ] ) indicate an optional parameter. If you omit the parameter,
InfoSphere CDC uses a default value.
- A vertical bar ( | ) separating one or more parameters indicate that only one of the
parameters in the list can be used. When one or more vertical bars appear in a list
of parameters that is enclosed by brackets [ ], the choices are limited to the
parameters in the list, but you have the option to not specify any of the parameters.
- Ellipsis ( ... ) means that a parameter or option can be repeated more than once.
- You can issue the commands in UNIX or Linuxor Windows.

116
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=<instance_name>

where:
- <instance_name> is the name of your InfoSphere CDC instance.

117
Continuous Capture commands
Continuous Capture is a product feature that is designed to accommodate those
replication environments in which it is necessary to separate the reading of the
database logs from the transmission of the logical database operations. This is
useful when you want to continue processing log data even if replication and your
subscriptions stop due to issues such as network communication failures over a
fragile network, target server maintenance, or some other issue. You can enable or
disable Continuous Capture without stopping subscriptions.
Continuous Capture allows you to avoid spikes in your source system CPU resource
utilization by continuing to process log data (and write to disk as necessary) even
when subscriptions are stopped. This feature allows you to avoid situations where
the product uses no CPU when subscriptions are stopped and high CPU when you
start subscriptions after a prolonged target system outage.
This functionality comes with the trade-off of additional disk utilization on the source
machine in order to accumulate changes from the database log file when these are
not being replicated to the target machine. These trade-offs should be evaluated
and understood before deciding to use this feature in your replication environment.
To use the commands in this section that are applicable to Continuous Capture, you
must set the staging_store_can_run_independently system parameter to false.
The default value for this parameter is true.
See also:

- dmdisablecontinuouscapture - Disable Continuous Capture

- dmenablecontinuouscapture - Enable Continuous Capture

118
dmdisablecontinuouscapture - Disable Continuous
Capture
Use this command to disable Continuous Capture for your staging store.

Syntax
dmdisablecontinuouscapture [-I <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere® CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Related reference:
dmenablecontinuouscapture - Enable Continuous Capture
dmgetstagingstorestatus - Retrieve Staging Store status

119
dmenablecontinuouscapture - Enable Continuous
Capture
Use this command to enable Continuous Capture for your staging store.
Continuous Capture allows the InfoSphere® CDC log reader to continue operating
when communication with the target datastore is interrupted due to network
difficulties or other issues. Upon resumption of communication with the target,
Continuous Capture will reduce the latency between the source and target
datastores.

Syntax
dmenablecontinuouscapture [-I <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Related reference:
dmdisablecontinuouscapture - Disable Continuous Capture
dmgetstagingstorestatus - Retrieve Staging Store status

120
Controlling replication commands
This section contains commands that control replication in InfoSphere® CDC.
See also:

- dmendreplication - End replication

- dmrefresh - Refresh subscription
- dmstartmirror - Start mirroring

121
dmendreplication - End replication
Use this command to end refresh or mirroring on the specified subscriptions.
Ending replication allows you to prepare for transitional activities in your business
environment and allows you to move to the next step in your business processes.
Here are some examples of transitional activities in your business environment that
may require an end to replication:
- Initiating a database backup.
- Performing a regularly scheduled reboot of your source database server.
- Quiescing your database in preparation for an upgrade.
- Weekly batch processing has just completed.
- Preparing for off-line maintenance activities.

If you are replicating data continuously with Continuous mirroring and business
reasons arise that require an end to replication, InfoSphere® CDC provides multiple
options that suit most business needs. If your business requirements dictate that
replication must end at a particular point in your source database log because the
target database must be in a known state when replication ends, you can choose
from the following Scheduled End to replication options:
- -se parameter—When specified without –t or –p, this parameter ends replication at
the current time in the source database log.
- -t parameter—When specified with –se, this parameter ends replication at a user-
specified date and time.
- -p parameter—When specified with –se, this parameter ends replication at a user-
specified log position.

An example of a scenario that might require these options is that you are populating
a reporting instance and you need stable (non-changing) data in your reporting
instance during the day. At the end of the day when you shut down your application,
you can choose one of the Scheduled End (Net Change) options to update the
reporting instance with data from the current day as well.
If business requirements do not require a specific end point but do require a time
frame for ending replication, InfoSphere CDC provides escalating options (Normal,
Immediate, and Abort) that end replication more rapidly at the expense of a slower
start when resuming replication. For example, a routine end to replication with no
particular urgency may require the Normal option, whereas a sudden business need
to end replication rapidly may require the Abort option. A routine reboot of a SAN
might be appropriate for the Normal option, whereas a sudden and unexpected
hardware or application failure may require the Abort option.
If you initiate an end to replication and business reasons warrant a change in the
time frame, you can reschedule the end of replication by specifying a new date and
time, a new position in the database log, or choose another option for ending
replication.
Ending replication is also necessary if you want to update and make changes to
your subscription by:
- Adding a table mapping to the subscription.
- Deleting a table mapping from the subscription.
- Temporarily removing a table mapping from the subscription (parking a table).
122
- Modifying mapping details such as source and target column mappings, derived
columns, data translations, row and column selections, user exits, and so on.
- Updating the properties of a subscription when the structure of your source or
target tables change.

This command also includes an asynchronous option for scripting (-nw parameter)
that can be used with -se to allow your script to continue executing without waiting
for the Scheduled End to replication.
You can also start and end replication in Management Console. For more
information, see Starting and ending replication.
To stop an instance after ending replication on all subscriptions, use the
dmshutdown command.

Syntax
dmendreplication [-I <INSTANCE_NAME>] [-c|-i|-a|-se [-t <date and time>|-p

<log position>] [-w|-nw]] <-A|-s <SUBSCRIPTION NAME ...>> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the InfoSphere CDC instance for which you want to end replication.
Alternatively, you can specify the TSINSTANCE environment variable in place
of this value.
- -c
- Specifies that InfoSphere CDC ends replication on the specified subscriptions
with the Normal option. InfoSphere CDC will use this option by default if you do
not specify –se, -i, or –[Link] option completes in progress work and then ends
replication. If a refresh is in progress, Normal will complete the refresh for the
current table before replication ends.
Normal is the most appropriate option for most business requirements and is
the preferred method for ending replication in most situations.
- -i
- Specifies that InfoSphere CDC ends replication on the specified subscriptions
with the Immediate [Link] option stops all in progress work and then ends
replication. Starting replication after using this option can be slower than using -
c. If a refresh is in progress, the refresh for the current table will be interrupted
and then replication will end.
You should ensure that all dependent source database logs are available
before ending replication using the Immediate 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 Immediate, 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 business reasons require replication to end faster
than -c at the expense of a slower start when you resume replication on the
specified subscriptions.
123
- -a
- Specifies that InfoSphere CDC ends replication on the specified subscriptions
with the Abort [Link] 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
[Link] you specify the following parameters with -se, replication will end at
a specific date and time or log position:
- –t—End replication at a specific date and time in your source database log.
- –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 <date and time>
- Indicates the date and time in the source database log when replication will end
when using –se. When specifying a value for this parameter, use the following
format:“yyyy-MM-dd HH:mm”
This parameter is optional when you specify –se.
- -p <log position>
- Indicates that InfoSphere CDC will end replication at the specified DB2® LUW
LSN in your source database log when using -se. Here is an example of an
LSN format for DB2 LUW:00000138800C
This parameter is optional when you specify –se.
- -w
- Indicates that this command will wait for replication to end when you use –se.
–w is the default setting for a Scheduled End to [Link] you are scripting
the command with this parameter, your script must wait for -se processing to
complete before it continues to execute.
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.
- -nw
124
 - 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 [Link] –s to
end replication on one or more subscriptions.
- -s <SUBSCRIPTION NAME>
- Indicates the subscriptions where InfoSphere CDC will end [Link]
specify multiple subscriptions, list the subscriptions separated by a space. For
example:
Subscription1 Subscription2 Subscription3
You must specify a value for this parameter or use –A for all subscriptions.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
the locale of the machine where InfoSphere CDC is installed.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmendreplication -I MYINSTANCE -c -s FINANCEInfoSphere CDC ends replication
with the Normal option for the FINANCE subscription in the specified instance.
dmendreplication -I MYINSTANCE –se –t “2010-02-05-00-00” FINANCE -nw
InfoSphere CDC ends replication with the Scheduled End option for the FINANCE
subscription at the specified time in the source database log. The command exits
before Scheduled End processing is complete.
dmendreplication -I MYINSTANCE –a –s SUBSCRIPTION1 SUBSCRIPTION2
InfoSphere CDC ends replication with the Abort option for SUBSCRIPTION1 and
SUBSCRIPTION2 in the specified instance.

125
dmrefresh - Refresh subscription
Use this command to refresh the specified subscriptions. When you refresh a
subscription, InfoSphere® CDC ensures that the target tables are synchronized with
the source tables. Typically, you would refresh target tables when you have set the
replication method to Refresh on your tables.
However, you can also refresh target tables that have a replication method set to
Mirror and a status of Active or Refresh. When you refresh a table configured for
mirroring, InfoSphere CDC refreshes the target table so that it is synchronized with
the source table and then marks a table capture point as the starting point for
mirroring.
This command exits after it has successfully refreshed the specified subscriptions. If
you terminate this program while it is still running, InfoSphere CDC ends replication
immediately for the specified subscriptions.

Syntax
dmrefresh [-I <INSTANCE_NAME>] [-a|-f] <-A|-s <SUBSCRIPTION_NAME ...> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the InfoSphere CDC instance for which you want to refresh one or
more subscriptions. Alternatively, you can specify the TSINSTANCE
environment variable in place of this value.
- -a
- Specifies that InfoSphere CDC refreshes all target tables in the subscription.
- -f
- Specifies that InfoSphere CDC refreshes only target tables that are flagged for
refresh. If you omit both the -a and -f options, InfoSphere CDC assumes -f by
default.
- -A
- Specifies that InfoSphere CDC refreshes all subscriptions.
- -s <SUBSCRIPTION_NAME>
- Specifies that InfoSphere CDC refreshes the indicated subscription. To specify
multiple subscriptions, list the subscriptions separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmrefresh -I NEWINSTANCE -a -s FINANCEInfoSphere CDC refreshes all target
tables in the Finance subscription.

126
127
dmstartmirror - Start mirroring
Issue this command from your InfoSphere® CDC source to start mirroring on the
specified subscriptions. This command starts mirroring for any table with a
replication method of Mirror and a status of Refresh or Active. Tables with a
replication method of Mirror and a status of Refresh are refreshed before mirroring
begins.
InfoSphere CDC provides two types of mirroring for source tables that are mapped
to target tables: Continuous (-c parameter) and Scheduled End (Net Change) (-n
parameter). The type of mirroring you select depends on your business needs.
As its name implies, Continuous mirroring replicates changes to the target on a
continuous basis. Use this type of mirroring when business requirements dictate that
you need replication to be running continuously and you do not have a clearly
defined reason to end replication at the present time.
Scheduled End (Net Change) mirroring replicates changes (to the target) up to a
user-specified point in the source database log and then ends replication. Use this
type of mirroring when business requirements dictate that you only replicate your
data periodically and you have a clearly defined end point for the state of your target
database when replication ends. Scheduled End (Net Change) mirroring allows you
to end replication at the following points in your source database log:
- -n parameter—When specified without –tor –p, this parameter ends replication at
the current time in the source database log.
- -t parameter—When specified with –n, this parameter ends replication at a user-
specified date and time.
- -p parameter—When specified with –n, this parameter ends replication at a user-
specified log position.

These user specified end points ensure that your target database is in a known state
when replication ends.
You can also start and end replication in Management Console. For more
information, see Starting and ending replication.

Syntax
dmstartmirror [-I <INSTANCE_NAME>] [-c|-n [-t <date and time>|-p

<log position>] [-w|-nw]] <-A|-s <SUBSCRIPTION NAME ...> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the InfoSphere CDC instance for which you want to start mirroring.
Alternatively, you can specify the TSINSTANCE environment variable in place
of this value.
- -c
- Specifies that InfoSphere CDC will start Continuous mirroring on the specified
[Link] you do not specify –c or -n, InfoSphere CDC will start
Continuous mirroring by default on the specified subscriptions.
- -n
- Specifies that InfoSphere CDC mirrors all committed database changes in the
source database and then ends replication normally at the current source
system time in the database log with the Scheduled End option. The source
128
 system time when replication will end is set when you issue this [Link]
you specify the following parameters with –n, replication will end at a specific
date and time or log position:
- –t—End replication at a specific date and time in your source database log.
- –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 <date and time>
- Indicates the date and time in the source database log when replication will end
when using –n. When specifying a value for this parameter, use the following
format:“yyyy-MM-dd HH:mm”
This parameter is optional when you specify –n.
- -p <log position>
- Indicates that InfoSphere CDC will end replication at the specified DB2® LUW
LSN in your source database log when using -se. Here is an example of an
LSN format for DB2 LUW:00000138800C
This parameter is optional when you specify –n.
- -w
- Indicates that this command will wait for replication to end when you use –n. –w
is the default setting for a Scheduled End to [Link] you are scripting the
command with this parameter, your script must wait for -n processing to
complete before it continues to execute.
This parameter does not apply if you specify –c for Continuous mirroring.
- -nw
- Indicates that this command will not wait for replication to end if you specify -n.
If you are scripting this command, this parameter allows your script to continue
executing (asynchronous) if -n processing is not [Link] parameter does
not apply if you specify –c for Continuous mirroring.
- -A
- Indicates that InfoSphere CDC starts mirroring for all [Link] –s to
start mirroring for one or more subscriptions.
- -s <SUBSCRIPTION_NAME>
- Indicates the subscriptions where InfoSphere CDC will start mirroring. To
specify multiple subscriptions, list the subscriptions separated by a space. For
example:Subscription1 Subscription2 Subscription3
You must specify a value for this parameter or use –A for all subscriptions.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
the locale of the machine where InfoSphere CDC is installed.

Result
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 FINANCEInfoSphere CDC starts continuous
mirroring for the FINANCE subscription.
129
dmstartmirror -I MYINSTANCE –n –p “000000FB:000001A4:0001” –nw –A
InfoSphere CDC starts mirroring with the Scheduled End option for all subscriptions
in the specified instance. Replication will end at the specified Microsoft SQL Server
LSN in the source database log. The command will not wait for Scheduled End
processing to complete.
dmstartmirror -I MYINSTANCE –n –t “2010-02-05-00-00” FINANCE -nwInfoSphere
CDC starts mirroring with the Scheduled End option for the FINANCE subscription in
the MYINSTANCE instance. Replication will end at the specified time in the source
database log. The command will exit before Scheduled End processing is complete.

130
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
- dmdecodebookmark - Display verbose information bookmark
- dmsetbookmark - Set bookmark
- dmshowbookmark - Display bookmark information
- dmshowlogdependency - Show Log Dependency

131
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:
- Specify the thread ID in the -t <thread_number> parameter of this command.
- Place the archive logs in subdirectories that are named using the thread number.
For example, /archivelog/mycdcsystem/1 for thread 1 and
/archivelog/mycdcsystem/2 for thread 2.
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 <INSTANCE_NAME>] [-t <thread_number>] -d <filename>

Parameters
- -I <INSTANCE_NAME>
- The name of the InfoSphere CDC instance. You can set the TSINSTANCE
environment variable to the name of your InfoSphere CDC instance. After this is
complete, you no longer have to specify the instance when issuing commands.
- -t <thread_number>
- The thread ID of the Oracle archive log. If your database environment is not
Oracle RAC, the thread ID will always be 1. This parameter is optional.
- -d <filename>
- Specify the name (including extension) and the fully qualified path to the
archive log file being registered as it appears on the backup Oracle database.
For example, you can specify the following value: /archivelog/arch_1_22781.arc

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmarchivelogavailable -I MYINSTANCE -t 1 -d /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 for the specified instance.
dmarchivelogavailable -I MYINSTANCE -t 1 -d /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 for the specified instance.

132
Related reference:
dmarchivelogremoved - Mark archive log as removed
dmshowlogdependency - Show Log Dependency

133
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 <INSTANCE_NAME>] -d <file name> [-a]

Parameters
- -I <INSTANCE_NAME>
- The name of the InfoSphere CDC instance. You can set the TSINSTANCE
environment variable to the name of your InfoSphere CDC instance. After this is
complete, you no longer have to specify the instance when issuing commands.
- -d <filename>
- Specify the name (including extension) and the fully qualified path to the
archive log file being registered as it appears on the backup Oracle database.
For example, you can specify the following value: /archivelog/arch_1_22781.arc
- -a
- Indicates that all available logs before and including the log that you specified in
this command will be removed. This parameter is optional.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Example
dmarchivelogremoved -I MYINSTANCE -d /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
dmshowlogdependency - Show Log Dependency

134
dmdecodebookmark - Display verbose information
bookmark
Use this command to display verbose information about a bookmark.

Syntax
dmdecodebookmark [-I <INSTANCE_NAME>] (-b <bookmark> | -f <bookmark_file>)

[-d <database_version>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- The name of the InfoSphere® CDC instance. You can set the TSINSTANCE
environment variable to the name of your InfoSphere CDC instance. After this is
complete, you no longer have to specify the instance when issuing commands.
- -b <bookmark>
- The bookmark as a hexadecimal-encoded string.
- -f <bookmark_file>
- The bookmark file as a binary file.
- -d<database_version>
- The database and version that generated the bookmark specified, if the
bookmark was generated by InfoSphere CDC version 6.2 or earlier.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmdecodebookmark -f [Link] CDC displays information about the
bookmark stored in the [Link] file.

135
dmsetbookmark - Set bookmark
CAUTION:
Improper use of this command can result in data loss or data duplication. You
should only execute this command when directed by IBM Technical Support.
Use this command on your InfoSphere® CDC source system to set the replication
position (bookmark) in the stream of change data for a subscription. You can obtain
the replication position for a subscription with the dmshowbookmark command,
which is executed on your InfoSphere CDC target system.

Syntax
dmsetbookmark [-I <INSTANCE_NAME>] -s <SUBSCRIPTION_NAME ...> (-b <bookmark> | -f

<bookmark_file_name>) [-a] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- The name of the InfoSphere CDC instance. You can set the TSINSTANCE
environment variable to the name of your InfoSphere CDC instance. After this is
complete, you no longer have to specify the instance when issuing commands.
- -s <SUBSCRIPTION_NAME>
- The name of the subscription for which InfoSphere CDC sets a replication
position (bookmark).
- -b <bookmark>
- Indicates the replication position (bookmark) which determines the point in the
database log where you want InfoSphere CDC to resume mirroring. When
mirroring resumes, InfoSphere CDC will start capturing change data at the
indicated replication position. The replication position is a hexadecimal-encoded
string that is obtained from the dmshowbookmark command.
- -f <bookmark_file_name>
- Indicates the name of the binary or XML file that contains all replication position
(bookmark) information which determines the point in the database log where
you want InfoSphere CDC to resume mirroring. When mirroring resumes,
InfoSphere CDC will start capturing change data at the replication position
indicated in the [Link] can specify an absolute path for the location of the file.
If you do not specify an absolute path, you must place the file in the InfoSphere
CDC installation directory. InfoSphere CDC will auto-detect the binary or XML
format of the [Link]: 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 <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.
136
Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails

Examples
dmsetbookmark -I MYINSTANCE -b 6578616d706c65 -s FINANCEInfoSphere CDC
sets a replication position (bookmark) for the Finance subscription for the specified
instance. This command specifies that mirroring will resume at the indicated
replication position in the database log.
dmsetbookmark -I MYINSTANCE -f bookmark -s FINANCEInfoSphere CDC sets a
replication position (bookmark) for the Finance subscription for the specified
instance. This command specifies that mirroring will resume at the replication
position (bookmark) contained in the bookmark file. InfoSphere CDC will auto-detect
the XML or binary format of the file. The file is located in InfoSphere CDC installation
directory since no absolute path is specified.

137
dmshowbookmark - Display bookmark information
CAUTION:
Improper use of this command in conjunction with the dmsetbookmark command
can result in data loss or data duplication. You should only execute the
dmsetbookmark command when directed by IBM Technical Support.
Use this command on your InfoSphere® CDC target system to obtain the replication
position (bookmark) in the stream of change data for a subscription. After generating
the replication position information with this command, you can use the
dmsetbookmark command on the source system to set the replication position for a
subscription.
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 <INSTANCE_NAME>] -s <SOURCE_ID>

[-f <bookmark_file_name>] [-x <bookmark_file_name>] [-v] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- The name of the InfoSphere CDC instance. You can set the TSINSTANCE
environment variable to the name of your InfoSphere CDC instance. After this is
complete, you no longer have to specify the instance when issuing commands.
- -s <SOURCE_ID>
- Specifies the source ID of the subscription for which you want to obtain the
replication position (bookmark).Source IDs are automatically generated based
on truncating the subscription name to 8 characters during subscription
creation. Source IDs must be unique.
- -f <bookmark_file_name>
- Specifies the name of the binary file that will be generated by this command.
The generated file contains information about the replication position
(bookmark) for the specified subscription.
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 <bookmark_file_name>
- Specifies the name of the XML file that will be generated by this command. The
generated file contains information about the replication position (bookmark) for
the specified subscription. Use this parameter if you are replicating from a DB2
for LUW DPF source environment. The XML file contains replication positions
(bookmarks) for all [Link] 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 XML file
138
 generated by this parameter.
- -v
- Displays verbose information about the replication position (bookmark),
including a hexadecimal-encoded string. The amount of information displayed
depends on the type and version of the source engine. The hexadecimal-
encoded string is always displayed. This parameter displays a subset of what
the dmdecodebookmark command displays. If not specified, only a
hexadecimal-encoded string is [Link]: Use the -x parameter if you are
issuing this command from the target of a DB2 LUW DPF source environment.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmshowbookmark -I MYINSTANCE -s MASTER -f bookmarkInfoSphere CDC
obtains the replication position (bookmark) information for the specified instance and
the MASTER source ID. Replication position (bookmark) information is contained in
the bookmark binary file which will be placed in the InfoSphere CDC installation
directory since no absolute path has been specified.
dmshowbookmark -I MYINSTANCE -s FINANCE -x mybookmarksInfoSphere CDC
obtains the replication position (bookmark) information for the specified instance and
the FINANCE source ID. Replication position (bookmark) information is contained in
the mybookmarks XML file which will be placed in the InfoSphere CDC installation
directory since no absolute path has been specified.

139
dmshowlogdependency - Show Log Dependency
Use this command to display information about source database logs in order to
implement a log retention policy. For a specified instance of InfoSphere® CDC, you
can display:
- A list of all the logs that are required for the specified instance.
- The earliest open transaction in the log for the specified instance.
- The logs which contain the position confirmed by the target database for the
specified instance.
- The logs which contain the position the specified instance is reading from.

You must issue this command on your InfoSphere CDC source system.

Syntax
dmshowlogdependency [-I <INSTANCE_NAME>] ( -p <partition_number> | -t | -l) [-c]

(-s <SUBSCRIPTION_NAME> | -A | -a) [-v] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- The name of the InfoSphere CDC instance. You can set the TSINSTANCE
environment variable to the name of your InfoSphere CDC instance. After this is
complete, you no longer have to specify the instance when issuing commands.
- -c
- Considers the current position instead of the restart position.
- -p <partition_number>
- Specify an integer for the partition number for which you want to display the
complete list of required source database logs for the specified instance. These
logs are required to start replication and contain data that has not been applied
to the [Link] parameter is mandatory if you are replicating from a DPF
source environment and optional if your source environment is not DPF.
If you do not specify a value for this parameter and you are replicating from a
DPF environment on your InfoSphere CDC source system, InfoSphere CDC will
use the default partition number.
- -t
- Displays the source database log which contains the position confirmed by the
target database. 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 confirmed by the target
database for the corresponding subscription.
- -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.
- Accurate information about where in the log InfoSphere CDC is reading will only
be provided if there is a steady stream of in scope data being applied and
140
 committed on the source database
- -s <SUBSCRIPTION_NAME>
- Displays a source database log or a list of logs for the specified subscription.
- -A
- Displays a source database log or a list of logs for all subscriptions.
- -a
- Displays a source database log or a list of logs for each individual subscription.
- -v
- Specifies verbose output (otherwise, the output is formatted for scripting).
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails. The command can also print as NULL if there are no
tables defined in the subscription.

Examples
dmshowlogdependency -I MYINSTANCE -ADisplays the complete list of required
source database logs for all subscriptions in the specified instance.
dmshowlogdependency -I MYINSTANCE -p 1 -s MYSUBSCRIPTIONDisplays the
complete list of database logs that are required on partition 1 in your DPF source
environment for the specified instance and subscription.

Related reference:
dmarchivelogavailable - Mark archive log as available
dmarchivelogremoved - Mark archive log as removed

141
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
- dmsupplementallogevallist - Supplemental logging evaluation list

142
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:
- The dependency that the instance has on supplemental logging
- 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 <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- The name of the InfoSphere CDC for Oracle databases instance. You can set
the TSINSTANCE environment variable to the name of your InfoSphere CDC
instance. After this is complete, you no longer have to specify the instance
when issuing commands.
- -L <locale>
- The name of the locale used for the InfoSphere CDC for Oracle databases
instance. The default is your machine's locale.

143
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 <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- The name of the InfoSphere CDC instance. You can set the TSINSTANCE
environment variable to the name of your InfoSphere CDC instance. After this is
complete, you no longer have to specify the instance when issuing commands.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

144
dmsupplementallogevallist - Supplemental logging
evaluation list
Use this command to view a list of table names for which InfoSphere® CDC
believes that supplemental logging can be disabled. InfoSphere CDC will perform a
best-effort check to determine which tables may have had supplemental logging
enabled at one point, but for which supplemental logging is no longer required.
The resulting list is not to be considered exhaustive; you should verify that
supplemental logging is no longer required before making changes in logging
configurations.

Syntax
dmsupplementallogevallist –I <instance> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the InfoSphere CDC instance for which you want to end replication.
Alternatively, you can specify the TSINSTANCE environment variable in place
of this value.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
the locale of the machine where InfoSphere CDC is installed.

Result
This command returns a list of table names for which InfoSphere CDC believes that
supplemental logging can be disabled.
Examples
dmsupplementallogevallist -I MYINSTANCE InfoSphere CDC displays a list of
tables, for the MYINSTANCE instance, where supplemental logging may no longer
be needed.

145
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

146
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 <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the operation was successful. If it fails, this
command returns a non-zero value.

147
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 <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Related reference:
dmenablecontinuouscapture - Enable Continuous Capture
dmdisablecontinuouscapture - Disable Continuous Capture

148
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

149
dmexportconfiguration - Export InfoSphere CDC
Configuration
Use this command to export the configuration details of an installed instance of
InfoSphere® CDC. Configuration details are sent to an XML configuration file. You
can use the dmimportconfiguration command to import the XML file that you create
with this command into another instance of InfoSphere CDC.
Note: This command does not export subscription-specific settings that are
configured in Management Console. Subscription-specific settings can be exported
to an XML file in Management Console.
Note: This command is interactive and will prompt you for your password. You
cannot script this command.

Syntax
dmexportconfiguration <absolute_path_to_configuration_file> [-L <locale>]

Parameters
- <absolute_path_to_configuration_file>
- The absolute path to the XML configuration file that you want to export.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmexportconfiguration c:\[Link] CDC exports the XML file to
the specified absolute path.

Related reference:
dmimportconfiguration - Import InfoSphere CDC Configuration

150
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 <absolute_path_to_configuration_file> [-L <locale>]

Parameters
- <absolute_path_to_configuration_file>
- The absolute path to the XML configuration file that you are importing.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmimportconfiguration c:\[Link]

InfoSphere CDC imports the XML configuration file from the specified absolute path.

Related reference:
dmexportconfiguration - Export InfoSphere CDC Configuration

151
Managing tables for replication commands
This section contains commands that help you manage the tables that you want to
replicate with InfoSphere® CDC.
See also:

- dmdescribe - Describe source tables

- dmflagforrefresh - Flag for Refresh
- dmmarktablecapturepoint - Mark a table capture point on a source table
- dmpark - Park table
- dmreaddtable - Update source table definition
- dmreassigntable - Update target table definition
- dmsetreplicationmethod - Set replication method

152
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 <INSTANCE_NAME>] <-A|-s <SUBSCRIPTION_NAME ...> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the InfoSphere® CDC instance for which you want to send source
metadata changes over to the target. Alternatively, you can specify the
TSINSTANCE environment variable in place of this value.
- -A
- Specifies that InfoSphere CDC will send source metadata changes made to all
subscriptions over to the target.
- -s <SUBSCRIPTION_NAME>
- Specifies that InfoSphere CDC sends source metadata changes for the
indicated subscriptions over to the target. To specify multiple subscriptions, list
the subscriptions separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmdescribe -I NEWINSTANCE -s FINANCEInfoSphere CDC sends source
metadata changes in the Finance subscription over to the target for the specified
instance.

153
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 <INSTANCE_NAME>] -s <SUBSCRIPTION_NAME ...>

<-A|-t <schema>.<table> ...> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere® CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -s <SUBSCRIPTION_NAME>
- Specifies the name of the subscription. To specify multiple subscriptions, list the
subscriptions separated by a space.
- -A
- Specifies that InfoSphere CDC flags all source tables for refresh in the
subscription.
- -t <schema>.<table>
- 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 [Link].
To specify multiple tables, list the tables separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmflagforrefresh -I MYINSTANCE -s FINANCE -AInfoSphere CDC flags for refresh
all source tables in the Finance subscription for the specified instance.

154
dmmarktablecapturepoint - Mark a table capture
point on a source table
Use this command to mark a table capture point on a source table and change the
status of the table to Active. If you changed the table before executing this
command, those changes will not be replicated.
Mark a table capture point on a source table when you want to override an existing
position in the stream of changed data. This is possible when you have already
synchronized (refreshed) your source and target tables using an application other
than InfoSphere® CDC (for example, using the import or export capabilities of your
database platform) and you know the point in time your source and target are
synchronized with each other. InfoSphere CDC mirrors changes to the target table
from the current position in the stream of changed data. This position is set by
InfoSphere CDC when you select Mirror (Change Data Capture) after mapping your
tables in the Map Tables wizard. If you want to override the position set by
InfoSphere CDC, then you can manually mark a table capture point in Management
Console. When you decide to start mirroring on the subscription, InfoSphere CDC
identifies the position you have set as the point in time from which to capture and
replicate database changes to the target.

Syntax
dmmarktablecapturepoint [-I <INSTANCE_NAME>] -s <SUBSCRIPTION_NAME ...>

-A|-t <<schema>.<table>...> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -s <SUBSCRIPTION_NAME>
- Specifies the subscription name. To specify multiple subscriptions, list the
subscriptions separated by a space.
- -A
- Specifies that InfoSphere CDC overrides an existing position in the stream of
changed data on all source tables in the subscription.
- -t <schema>.<table>
- 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 [Link]. To specify multiple tables, list the tables separated by a
space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
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 -AInfoSphere CDC sets the
155
status of all tables in the Finance subscription to Active.
dmmarktablecapturepoint -I MYINSTANCE -s ACCOUNTING -t [Link]
InfoSphere CDC sets the status of the specified table in the Accounting subscription
to Active.

156
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 <INSTANCE_NAME>] -s <SUBSCRIPTION_NAME ...> <-A|-t <schema>.<table> ...>

[-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -s <SUBSCRIPTION_NAME>
- Specifies the subscription name. To specify multiple subscriptions, list the
subscriptions separated by a space.
- -A
- Specifies that InfoSphere CDC parks all source tables in the subscription.
- -t <schema>.<table>
- Specifies the name of a source table in the subscription that InfoSphere CDC
parks. You must specify the table name in the format [Link]. To specify
multiple tables, list the tables separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmpark -I MYINSTANCE -s FINANCE -AInfoSphere CDC parks all source tables in
the Finance subscription.

Related reference:
dmendreplication - End replication

157
dmreaddtable - Update source table definition
Use this command to update the definition of one or more source tables in the
InfoSphere® CDC metadata. Run this command after you have changed the
definition of a source table using your relational database.
Notes:
- This command will set the table status to Parked after updating the source table
definition in the InfoSphere CDC metadata.
- This command is not the equivalent of the Management Console Update Source
Table Definition dialog, which you access by selecting Configuration >
Subscriptions > <subscription_name>, then right-clicking the table mapping name
under Table Mappings, and then selecting Update Table Definition > Source Table.

Note:

Syntax
dmreaddtable [-I <INSTANCE_NAME>] <-A|-t <schema>.<table> ...> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -A
- Specifies that InfoSphere CDC updates definitions for all source tables that are
available for replication.
- -t <schema>.<table>
- 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
[Link]. To specify multiple tables, list the tables separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmreaddtable -I NEWINSTANCE -AInfoSphere CDC updates definitions for all
source tables that are available for replication. The status for all tables will be set to
Parked.

158
dmreassigntable - Update target table definition
Use this command to update the definition of a target table in InfoSphere® CDC
metadata after you change the definition of the target table in your database.

Syntax
dmreassigntable [-I <INSTANCE_NAME>] -s <SUBSCRIPTION_NAME ...>

<-A|-t <schema>.<table> ...> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -s <SUBSCRIPTION_NAME>
- Specifies the subscription that contains the source table that is mapped to the
target table which was updated in your database. To specify multiple
subscriptions, list the subscriptions separated by a space.
- -A
- Specifies that InfoSphere CDC updates definitions for all target tables in the
subscription.
- -t <schema>.<table>
- 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 [Link]. To
specify multiple tables, list the tables separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the operation was successful. If it fails, this
command returns a non-zero value.

Example
dmreassigntable -I NEWINSTANCE -s FINANCE -AInfoSphere CDC updates
definitions for all target tables in the Finance subscription.
dmreassigntable -I CDCINSTANCE -s FINANCE -t SCHEMA1.SRCTBL1
InfoSphere CDC updates the definition for the target table that is mapped to the
SCHEMA1.SRCTBL1 source table in the Finance subscription.

159
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 <INSTANCE_NAME>] <-r|-m> -s <SUBSCRIPTION_NAME ...>

<-A|-t <schema>.<table> ...> [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -m
- Specifies that tables will use Mirror (Change Data Capture) as the replication
method.
- -r
- Specifies that tables will use Refresh (Snapshot) as the replication method.
- -s <SUBSCRIPTION_NAME>
- Specifies the name of the subscriptions. To specify multiple subscriptions, list
the subscriptions separated by a space.
- -A
- Specifies that all tables in the subscription will use the indicated replication
method.
- -t <schema>.<table>
- 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
[Link]. To specify multiple tables, list the tables separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmsetreplicationmethod -I MYINSTANCE -r -s FINANCE -AAll tables in the Finance
subscription will use Refresh as the replication method in the specified InfoSphere
CDC instance.
dmsetreplicationmethod -I NEWINSTANCE -m -s FINANCE -t [Link]
source table [Link] in the Finance subscription will use Mirror as the
replication method in the specified InfoSphere CDC instance.

160
161
Monitoring replication commands
This section contains commands that help you monitor replication in InfoSphere®
CDC.
See also:

- dmclearevents - Clear events

- dmgetsubscriptionstatus - Get subscription status
- dmshowevents - Display InfoSphere CDC events

162
dmclearevents - Clear events
Use this command to delete events from the Event Log view in Management
Console.

Syntax
dmclearevents [-I <INSTANCE_NAME>] [-S|-T-|-B] <-A|-s <SUBSCRIPTION_NAME ...>

[-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere® CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -S
- Specifies that InfoSphere CDC clears events from the source.
- -T
- Specifies that InfoSphere CDC clears events from the target.
- -B
- Specifies that InfoSphere CDC clears events from both the source and target. If
none of the S, T, and B options are specified, InfoSphere CDC assumes B by
default.
- -A
- Specifies that InfoSphere CDC clears events for all subscriptions.
- -s <SUBSCRIPTION_NAME>
- Specifies that InfoSphere CDC clears events for the indicated subscription. To
specify multiple subscriptions, list the subscriptions separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmclearevents -I MYINSTANCE -S -AInfoSphere CDC clears events from the
source for all subscriptions for the specified instance.
dmclearevents -I MYINSTANCE -B -s FINANCE MARKETINGInfoSphere CDC
clears events from both the source and target for the Finance and Marketing
subscriptions for the specified instance.

163
dmgetsubscriptionstatus - Get subscription status
Issue this command on the InfoSphere® CDC source engine to retrieve status
information for one or more subscriptions and send the results to standard output.
Please note that this command can be issued on Linux, UNIX and Windows source
replication engines only, not on target replication engines.

Syntax
dmgetsubscriptionstatus [-I <INSTANCE_NAME>] [-p] <-A|-s <SUBSCRIPTION_NAME ...>

[-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -p
- Specifies that InfoSphere CDC sends status information to standard output.
- -A
- Specifies that InfoSphere CDC retrieves status information for all subscriptions.
- -s <SUBSCRIPTION_NAME>
- Specifies the name of the subscription for which status information is retrieved.
To specify multiple subscriptions, list the subscriptions separated by a space.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns one of the following statuses for each subscription:
- Recovering—The subscription is in an undetermined state.
- Idle—The subscription is not running.
- Starting—The subscription is in start up mode and is not currently replicating data.
- Running—The subscription is running and replicating data.

Examples
dmgetsubscriptionstatus -I MYINSTANCE -p -AInfoSphere CDC retrieves status
information for all subscriptions and sends the results to standard output for the
specified instance.

164
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 <INSTANCE_NAME>] <-a|-s <SUBSCRIPTION_NAME> ...

|-t <SOURCE_ID> ...|-s <SUBSCRIPTION_NAME> ... -t <SOURCE_ID> ...> [-h] [-c max_msg]

[-L <locale>]

or
dmshowevents -I <INSTANCE_NAME> <-a|-s <SUBSCRIPTION_NAME>|-t

<SOURCE_ID>> ...> [-h] [-c <max_msg>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -a
- Specifies that InfoSphere CDC shows events for all subscriptions.
- -s <SUBSCRIPTION_NAME>
- Specifies the name of the subscription for which InfoSphere CDC displays
source events. To specify multiple subscriptions, list the subscriptions
separated by a space.
- -t <SOURCE_ID>
- Specifies the source ID of the subscription for which InfoSphere CDC displays
target events. List the source IDs if you specify more than [Link] IDs are
automatically generated based on truncating the subscription name to 8
characters during subscription creation. Source IDs must be unique.
- -h
- Specifies that InfoSphere CDC displays a header before the list of events. This
option helps you identify each item of information that is displayed for each
event.
- -c <max_msg>
- Specifies the maximum number of events that InfoSphere CDC displays. If you
omit this parameter or you specify a value greater than the total number of
events, InfoSphere CDC displays all events for the specified subscriptions and
source IDs.
- Minimum Setting—0. No events are shown.
- Maximum Setting—2147483647
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the operation was successful. If it fails, this
command returns a non-zero value.
165
Examples
dmshowevents -I NEWINSTANCE -s FINANCEInfoSphere CDC displays all events
for the Finance subscription for the specified instance.
dmshowevents -I MYINSTANCE –a –hInfoSphere CDC displays all events for all
subscriptions. A header is displayed before the list of events for the specified
instance.
dmshowevents -I NEWINSTANCE –s FINANCE MARKETING –t ATLANTA –h –c
20InfoSphere CDC displays the most recent 20 events for the Finance and
Marketing subscriptions and for the Atlanta source ID. A header is displayed before
the list of events for the specified instance.

Sample output
TIME|AGENTTYPE|SUBSCRIPTION|EVENTID|SEVERITY|EVENTPROGRAM|EVENTTEXT

2006-04-21 [Link].817|T|ATLANTA|95|Information|class [Link].

publication.c|IBM InfoSphere Change Data Capture Communications ending.

2006-04-21 [Link].614|T|ATLANTA|1538|Information|class [Link].

publication.c|---IBM InfoSphere Change Data Capture for ATLANTA terminating

normally.

2006-04-21 [Link].333|T|ATLANTA|1537|Information|class [Link].

publication.c|Describe conversation with ATLANTA completed successfully.

2006-04-21 [Link].911|T|ATLANTA|1536|Information|class [Link].

publication.c|Describe conversation started by ATLANTA.

2006-04-21 [Link].333|T|ATLANTA|1531|Information|class [Link].

publication.c|Communication with ATLANTA successfully started on Data channel.

2006-04-21 [Link].973|T|ATLANTA|1534|Information|class [Link].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.

166
Other commands
This section contains miscellaneous commands that allow you to determine the
version of InfoSphere® CDC, verify communications, stop InfoSphere CDC, set
system parameters, and back up your metadata.
See also:

- dmbackupmd - Back up metadata

- dmconfigurets - Configure InfoSphere CDC
- dmmarkexternalunloadstart - Start table data unload
- dmmarkexternalunloadend - End table data unload
- dmmdcommander
- dmmdconsole
- dmset - Set InfoSphere CDC system parameter
- dmshowversion - Show InfoSphere CDC version
- dmshutdown - Shut down InfoSphere CDC
- dmsupportinfo - Collect IBM Support information
- dmterminate - Terminate InfoSphere CDC processes
- dmts32 - Start InfoSphere CDC
- dmts64 - Start InfoSphere CDC

167
dmbackupmd - Back up metadata
Use this command to create a backup of the InfoSphere® CDC metadata database
which contains information about your current replication configuration. You should
always back up your metadata when there are changes to your subscription
configuration and table status. You can only back up your metadata while
InfoSphere CDC is running.
The backup of the metadata database is created in <Installation_directory>
/instance/<instance_name>/conf/backup. The files in the backup directory should be
stored on separate media for possible recovery.

Syntax
dmbackupmd [-I <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

168
dmconfigurets - Configure InfoSphere CDC
Use this command to launch the InfoSphere® CDC configuration tool. You can use
this tool to create instances and configure your installation of InfoSphere CDC.
If the DISPLAY environment variable has been set, the configuration tool will
attempt to launch the graphical user interface (GUI) version of the configuration tool
when this command is issued. If you do not have the graphical libraries installed to
view the GUI, you will need to ensure that the DISPLAY environment variable has
been cleared in order to launch the command line version.

Syntax
dmconfigurets [-L <locale>]

Parameters
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

169
dmmarkexternalunloadstart - Start table data unload
Use this command when you want to perform a refresh outside of InfoSphere® CDC
while the tables are still active.
dmmarkexternalunloadstart will mark the starting point of the data unload for the
external tool that will be used to load the data to the target replication engine.

Syntax
dmmarkexternalunloadstart [-I <INSTANCE_NAME>] [-L <locale>]

-s <SUBSCRIPTION_NAME ...> [-t <table>]

Parameters
- [-I <INSTANCE_NAME>]
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- [-L <locale>]
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.
- -s <SUBSCRIPTION_NAME>
- Specifies that InfoSphere CDC sends source metadata changes for the
indicated subscription to the target. To specify multiple subscriptions, list the
subscriptions separated by a space.
- [-t <table>]
- Specifies the name of a source table in the subscription on which InfoSphere
CDC marks a table capture point. The table must be named in the format
<schema>.<table>.
- To mark the table capture point on all the source tables in the specified
subscription, omit this parameter.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmmarkexternalunloadstart -I MYINSTANCE -t [Link]
CDC marks the unload start point in the table named MYTABLE in the specified
schema for the specified instance.

Related concepts:
Performing an external refresh

170
dmmarkexternalunloadend - End table data unload
Use this command when you want to perform a refresh outside of InfoSphere® CDC
while the tables are still active.
dmmarkexternalunloadend will mark the ending point of the data unload for the
external tool that will be used to load the data to the target replication engine.

Syntax
dmmarkexternalunloadend [-I <INSTANCE_NAME>] [-L <locale>]

-s <SUBSCRIPTION_NAME ...> [-t <table>]

Parameters
- [-I <INSTANCE_NAME>]
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- [-L <locale>]
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.
- -s <SUBSCRIPTION_NAME>
- Specifies that InfoSphere CDC sends source metadata changes for the
indicated subscriptions over to the target. To specify multiple subscriptions, list
the subscriptions separated by a space.
- [-t <table>]
- Specifies the name of a source table in the subscription on which InfoSphere
CDC marks a table capture point. The tables must be named in the format
<schema>.<table>.
- To mark the table capture point on all the source tables in the specified
subscription, omit this parameter.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmmarkexternalunloadend -I MYINSTANCE -t [Link]
CDC marks the unload end point in the table named MYTABLE in the specified
schema for the specified instance.

Related concepts:
Performing an external refresh

171
dmmdcommander
This command is for internal use only.

172
dmmdconsole
This command is for internal use only.

173
dmset - Set InfoSphere CDC system parameter
Use this command to view or change InfoSphere® CDC system parameters. You
can also change system parameters in Management Console.
Note: You can set any system parameter using this command. However, it will only
display system parameters that are set to non-default values.

Syntax
dmset [-I <INSTANCE_NAME>] [<parameter_name>[=[<parameter_value>]]] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- <parameter_name>
- Specifies the name of the InfoSphere CDC system parameter.
- <parameter_value>
- Specifies the value that you want to assign to the system parameter.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmset -I MYINSTANCEDisplays all of the system parameters that are set to non-
default values.
dmset -I MYINSTANCE events_max_retain=20000Sets the events_max_retain
system parameter to 20000.
dmset -I MYINSTANCE events_max_retainDisplays the current value of the
specified parameter.
dmset -I MYINSTANCE stop_replication=Deletes the stop_replication system
parameter.

174
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 <locale>]

Parameters
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the operation was successful. If it fails, this
command returns a non-zero value.

175
dmshutdown - Shut down InfoSphere CDC
Use this command to stop an instance of InfoSphere® CDC and end replication on
all subscriptions that use the instance as a source. This command is often used
prior to taking a server or database offline for maintenance purposes or upgrading
InfoSphere CDC.
Note: As a best practice before you run this command and to ensure that it
completes successfully, use the dmendreplication command to end replication on all
subscriptions that use the specified instance as a source and as a target. This
command will not complete successfully if target subscriptions are still running.
To end replication on subscriptions that use the specified instance as a target, you
can use the –a parameter which will generate an error when forcefully ending
replication on subscriptions that use the specified instance as the target.
If this command does not end InfoSphere CDC processes and stop the specified
instance, use the dmterminate command on the UNIX and Linux platforms to force a
complete shut down and on Windows, to stop the service.

Syntax
dmshutdown [-I <INSTANCE_NAME>] [-c|-i|-a|-se [-t <date and time>|-p <log position>]

[-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this value.
- -c
- Specifies that InfoSphere CDC stops the specified instance and ends
replication on all subscriptions that use the instance as a source with the
Normal option. InfoSphere CDC will use this option by default if you do not
specify –se, -i, or –[Link] option completes in progress work and then ends
replication. If a refresh is in progress, Normal will complete the refresh for the
current table before replication ends.
Normal is the most appropriate option for most business requirements and is
the preferred method for ending replication in most situations.
- -i
- Specifies that InfoSphere CDC stops the specified instance and ends
replication on all subscriptions that use the instance as a source with the
Immediate [Link] option stops all in progress work and then ends
replication. Starting replication after using this option can be slower than using -
c. If a refresh is in progress, the refresh for the current table will be interrupted
and then replication will end.
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 [Link] option stops all in progress work and then
176
 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.
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 [Link] can use the
following parameters with this option to end replication at a specific date and
time or log position:
- –t—Stop the instance and end replication at a specific date and time in your
source database log.
- –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 <date and time>
- Indicates the date and time in the source database log when replication will end
when using –se. When specifying a value for this parameter, use the following
format:“yyyy-MM-dd HH:mm”
This parameter is optional when you specify –se.
- -p <log position>
- Indicates that InfoSphere CDC will end replication at the specified DB2® LUW
LSN in your source database log when using -se. Here is an example of an
LSN format for DB2 LUW:00000138800C
This parameter is optional when you specify –se.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
the locale of the machine where InfoSphere CDC is installed.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Related reference:
dmterminate - Terminate InfoSphere CDC processes
177
178
dmsupportinfo - Collect IBM Support information
Note: You should only run this command when the Management ConsoleSupport
Assistant cannot connect to your InfoSphere® CDC datastore because it is not
running or it will not run.
Use this command (when requested by IBM® Technical Support) to collect
InfoSphere CDC environment information in a generated .zip file that is used to
diagnose and troubleshoot your support issue.
Once the command has completed collecting information and generating the .zip
file, the output will display the full path and name of the .zip file. If you run this
command multiple times, the generated .zip files are numbered randomly. Note that
you are responsible for deleting the generated .zip files when they are no longer
required.

Syntax
dmsupportinfo [-I <INSTANCE_NAME>] [-t <"yyyy-MM-dd hh:mm:ss to yyyy-MM-dd hh:mm:ss">] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the name of the InfoSphere CDC instance. Alternatively, you can
specify the TSINSTANCE environment variable in place of this [Link] you do
not specify an instance (possibly because you could not create an instance),
this command will only collect non-instance specific information.
- -t <"yyyy-MM-dd hh:mm:ss to yyyy-MM-dd hh:mm:ss">
- Specifies the date and time range (relative to the time zone of the operating
system where you issue this command) used by InfoSphere CDC to retrieve
environment [Link]: 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 <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Example
dmsupportinfo -I PRODUCTION -t "2009-12-03 [Link] to 2009-12-03 [Link]"
Retrieves support information for the Production instance from 8:00 AM to 12:00 PM
on December 3, 2009. This is the time range when you experienced support issues
with this instance of InfoSphere CDC.

Related concepts:
Troubleshooting and contacting IBM Support

179
180
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 <locale>]

Parameters
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

181
dmts32 - Start InfoSphere CDC
Use this command to start a 32-bit instance of InfoSphere® CDC.

Syntax
dmts32 [-I <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the InfoSphere CDC instance for which you want to start.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmts32 -I -MYINSTANCEInfoSphere CDC starts for the specified instance.

182
dmts64 - Start InfoSphere CDC
Use this command to start a 64-bit instance of InfoSphere® CDC.

Syntax
dmts64 [-I <INSTANCE_NAME>] [-L <locale>]

Parameters
- -I <INSTANCE_NAME>
- Specifies the InfoSphere CDC instance for which you want to start.
- -L <locale>
- The name of the locale used for the InfoSphere CDC instance. The default is
your machine's locale.

Result
This command returns a value of 0 if the command was successful and a non-zero
value if the command fails.

Examples
dmts64 -I MYINSTANCEInfoSphere CDC starts for the specified instance.

183
User exits for InfoSphere CDC for Oracle databases
A user exit lets you define a set of actions that InfoSphere® CDC can run before or
after a database event occurs on a specified table. User exits allow you to
customize your environment to meet your business requirements. After compiling
the user exit, you can specify the user exit in Management Console.
InfoSphere CDC provides two types of user exits:
- Stored procedure—This type of user exit is run directly by the database engine and
is generally faster at processing database requests.
- Java class—This type of user exit utilizes the InfoSphere CDC API. Javadocs with
interface and class specifications for the API are installed with the product. The
Javadocs are located in /<installation_directory>/docs/api. To open the Javadocs
in your browser, click [Link].

Sample Java™ class user exits are also provided with InfoSphere CDC. You can
extend or modify these samples to suit your environment.
In this section, you will learn:

- Stored procedure user exits for table and row level operations
- Sample Java class user exits for InfoSphere CDC for Oracle databases
- InfoSphere CDC API reference – Javadocs

184
Stored procedure user exits for table and row level
operations
A stored procedure is a program (or procedure) which is physically stored within a
database. The advantage of a stored procedure is that when it is run, in response to
a user request, it is run directly by the database engine, which usually runs on a
separate database server and is generally faster at processing database requests.
After writing and compiling user exit programs, you can specify at which user exit
point you want to invoke the user exit (either before or after a row-level or before or
after a table-level operation) on the User Exits tab of InfoSphere® CDC.
See also:

- Defining a stored procedure user exit

- Stored procedure user exit database connections
- Retrieving data with a stored procedure user exit
- Example of a stored procedure user exit

185
Defining a stored procedure user exit
When defining a stored procedure user exit in InfoSphere® CDC, consider the
following:
- Overloaded stored procedures are not supported.
- Stored procedure user exits must have at least two parameters, which must be the
first two defined in the following order:
- result—An integer output parameter that returns '0' if the stored procedure user
exit is successful or a non-zero value if the stored procedure user exit is not
successful.
- returnMsg—A character output parameter that returns error messages to the
Event Log if the stored procedure user exit is not successful.

Related reference:
Example of a stored procedure user exit

186
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.

187
Retrieving data with a stored procedure user exit
You can retrieve data from your source table by passing system parameters to your
stored procedure. You can retrieve the following type of data:
- Retrieve system values (s$)—when passed to a stored procedure, the s$ prefix
makes system values available from the source database to your stored
procedure. For example, s$entry identifies the entry point at which InfoSphere®
CDC had run the user exit.
- Retrieve journal control fields (j$)—when passed to a stored procedure, the j$
prefix makes journal control fields available from the source database to your
stored procedure. For example, j$USER identifies the operating system user name
of the person that made the update on the source table. This is useful if you are
using the stored procedure to audit table or row-level operations that have
occurred on the source table.
- Retrieve data values—depending on the prefix you pass to the stored procedure,
you can retrieve data from the source database and make it available to your
stored procedure. For example, you can use b$ to retrieve the before image of the
source column, or you can use k$ to access the target table to find the rows that
need to be modified.
Each of these values can be used as input parameters for the stored procedure user
exit that you write. The format used to retrieve data is slightly different depending on
the product that you are using:
- For InfoSphere CDC, the format is <x>$<value>
where <x> represents the prefix and <value> represents the name of the value to be
retrieved.
See also:

- Retrieving system values using the s$ prefix

- Retrieving journal control fields using the j$ prefix
- Retrieving data values using b$, a$, k$, and d$ prefixes

188
Retrieving system values using the s$ prefix
This prefix is used to retrieve system values. The following table presents and briefly
describes these values.
Table 1. Descriptions of system values

Prefix and Value Data Type Description

189
s$entry NUMBER Represents the entry point
from where the stored
procedure was invoked.
You can invoke a stored
procedure from the
following entry points:
1—indicates that
InfoSphere® CDC has
invoked the stored
procedure before a table
clear (truncate)
operation2—indicates that
InfoSphere CDC has
invoked the stored
procedure after a table
clear (truncate)
operation3—indicates that
InfoSphere CDC has
invoked the stored
procedure before a row
insert
operation4—indicates that
InfoSphere CDC has
invoked the stored
procedure after a row
insert
operation5—indicates that
InfoSphere CDC has
invoked the stored
procedure before a row
update
operation6—indicates that
InfoSphere CDC has
invoked the stored
procedure after a row
update
operation7—indicates that
InfoSphere CDC has
invoked the stored
procedure before a row
delete
operation8—indicates that
InfoSphere CDC has
invoked the stored
procedure after a row
delete
operation9—indicates that
InfoSphere CDC has
invoked the stored
procedure before a table
refresh
operation10—indicates
that InfoSphere CDC has
invoked the stored
190
 procedure after a table
refresh operation
s$srcSysId VARCHAR Identifies uniquely the
location of the source data.
s$srcTabId VARCHAR Represents the name of
the source table in the
source database that
sends replicated data to
the target.
s$tgtTabId VARCHAR Represents the name of
the target table in the
target database that
receives replicated data
from the source.

191
Retrieving journal control fields using the j$ prefix
This prefix is used to retrieve information about the operation that occurred on the
source system. You can use jb$ with InfoSphere® CDC to retrieve the same
information.
Note: If you are replicating data using InfoSphere Change Data Capture for DB2®
for i on the source system, then the value for j$ and jb$ with ENTT and SEQN
journal control fields will be different. jb$ENTT generates 'UB' to indicate that the
before image of a row has been updated on the source table, and generates 'UP' to
indicate that the after image of a row has been updated on the source table. Also, if
you are using InfoSphere Change Data Capture for DB2 for i on the source system,
then jb$SEQN generates an internal ID for the row within a transaction.
The available values are listed:

Prefix and Value Data Type Description

j$CCID VARCHAR Identifies the
transaction with the
insert, update, or
delete operation.
j$CODE VARCHAR Identifies the type of
journal or log entry,
either “U” for a
refresh operation or
“R” for mirroring. The
IBM® i platform will
send “F” for file or
table-level entries.
j$CTRR or VARCHAR Identifies the relative
j$CNTRRN record number of the
source table that
recorded the
journal/log
[Link]: CTRR or
CNTRRN contains
meaningful
information when you
invoke your stored
procedure on the
insert entries that
make up the refresh.
The IBM i platform
will also fill this in on
any insert, update, or
delete operation.
j$ENTT or j$ENTTYP VARCHAR Generates journal or
log codes that identify
the operation type on
the source system.

192
j$JRN or j$JOURNAL VARCHAR The name of the
journal/log where
InfoSphere CDC is
reading insert,
update, or delete
operations from.
j$JOB VARCHAR Identifies the name of
the job that made the
insert, update, or
delete on the source
system.
j$MBR or j$MEMBER VARCHAR Identifies the name of
the source table or its
alias.
j$NBR or j$JOBNO VARCHAR Identifies the process
ID of the program on
the source table that
is making the insert,
update, or delete
operation.
j$PGM or VARCHAR Identifies the name of
j$PROGRAM the program on the
source system that
made the insert,
update or delete
operation.
j$SEQN or j$SEQNO VARCHAR Identifies the
sequence number of
the insert, update, or
delete operation in
the journal or log.
j$SYNM or VARCHAR Identifies the host
j$SYSTEM name of the source
system.
j$USER VARCHAR Identifies the
operating system
user name that made
the insert, update, or
delete operation on
the source.
j$USPF VARCHAR Identifies the
database user name
that made the insert,
update, or delete
operation on the
source.

193
j$TSTP or VARCHAR Identifies the date
j$TIMSTAMP and time of when the
insert, update, or
delete operation or
refresh was made on
the source. In
environments that
support microsecond
precision, the date
and time format of
this journal control
field is YYYY-MM-
DD-
HH:MM:[Link]
. Otherwise,
InfoSphere CDC sets
the microsecond
component UUUUUU
to zeroes or does not
include it at all.

194
Retrieving data values using b$, a$, k$, and d$
prefixes
Four prefixes are used to retrieve data:

Prefix Mode Description

b$<source column Input Used to retrieve the
name> before image of the
data in a source
column. The before
image is the original
image from the
source table column
before any
transformation is
applied to it.
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.

195
a$<source column Input Used to retrieve the
name> after image of the
data in a source
column. The after
image is the
translated data from
the source table
column. For example,
the data that was
translated by a
derived expression.
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$<target key column Input Used to access the
name> target table to find the
rows that need to be
[Link]: Key
columns are not
available for auditing.
d$<target column Input/Output Used to retrieve data
name> values after
transformation, which
will be used to update
the table in the target
database. Only these
values may be
modified by the
stored procedure.

196
197
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
PROD.AUDIT_STPROC ( The parameters you declare and want to
result
returnMsg
OUT INT,
OUT CHAR, pass to your stored procedure must be
s$entry
s$srcSysId
IN NUMBER,
IN CHAR,
valid data types.
s$srcTabId IN CHAR, The following parameters are mandatory
s$tgtTabId IN CHAR,
j$ENTT IN CHAR, and must be declared in your stored
a$IDNO
a$PRICE
IN NUMBER,
IN NUMBER, procedure:
a$DESC
a$LONGDESC
IN CHAR,
IN CHAR,
result—Returns a value of '0' if the
a$TRANSDATE IN DATE, stored procedure user exit is successful.
d$IDNO IN NUMBER,
d$PRICE IN NUMBER, If the stored procedure user exit is not
d$DESC
d$LONGDESC
IN CHAR,
IN CHAR, successful it will return a non-zero value
d$TRANSDATE IN DATE
)
and a message will be sent to the Event
[Link]—Returns an error
message to the Event Log if the stored
procedure is not [Link] following
parameters have been declared in this
stored procedure:
s$entry—Retrieves the entry point at
which the stored procedure was called.
In this example, InfoSphere® CDC calls
the user exit at every entry
point.s$srcSysId—Retrieves the location
of source data.s$srcTabId—Retrieves
the name of the source
table.s$tgtTabId—Retrieves the name of
the target table.j$ENTT—Retrieves the
journal code that indicates the type of
operation on the source
table.a$—Retrieves the after image of
the IDNO, PRICE, DESC, LONGDESC,
and TRANSDATE source
columns.d$—Retrieves the transformed
data of the IDNO, PRICE, DESC,
LONGDESC, and TRANSDATA target
columns.
IS
ENTRYPOINT VARCHAR(50); This stored procedure user exit can be
BEGIN
CASE s$entry invoked from these entry points.
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
values ( This stored procedure user exit will
s$entry, s$srcSysId,
s$srcTabId, s$tgtTabId, INSERT these values into
j$ENTT, a$IDNO, a$PRICE, a$DESC,
a$LONGDESC, a$TRANSDATE, d$IDNO,
PROD.AUDIT_TABLE1.
d$PRICE, d$DESC, d$LONGDESC, d$TRANSDATE,
ENTRYPOINT);

198
 result := 0;
returnMsg := 'OK'; This stored procedure user exit is
END AUDIT_STPROC; successful and returns a '0' value.
Note: If your stored procedure returns a
non-zero value because the stored
procedure is not successful, then an
error message is sent to the Event Log.

199
Sample Java class user exits for InfoSphere CDC
for Oracle databases
InfoSphere® CDC provides sample user exits that you can extend or modify to suit
your environment. The samples are found in [Link], which is located in the
samples directory in your InfoSphere CDC installation directory. The Java™ file
contains the following samples:
- [Link]—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
[Link].
- [Link]—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
[Link].
- [Link]—Calls a stored procedure with the image coming from
the source. This sample is located in
[Link].
- [Link]—Subscribes to replication events to retrieve the details of
the events which took place. This sample is located in
[Link].
- [Link]—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
[Link].
Note the following:
- To run the sample user exits without modifying them, you must specify the fully
qualified path to the compiled user exit in Management Console. For example,
[Link].
- Compiled sample user exits are located in the [Link] file which is found in the lib
directory in your InfoSphere CDC installation directory. Note that the compiled user
exits in the [Link] file have a *.class extension.
- If you want to modify the sample user exits, you must compile the user exit after
you make changes to the source code.
- The user exit class must also be in the InfoSphere CDC runtime classpath.
For more information on how to specify Java class or Stored Procedure user exits in
Management Console, see your Management Console documentation.
See also:

- To compile the sample Java class user exits (UNIX and Linux)

200
To compile the sample Java class user exits (UNIX
and Linux)
Procedure
1. Stop InfoSphere® CDC.
2. Unzip the [Link] file into the lib directory in your InfoSphere CDC installation
directory. Make sure you maintain the directory structure when unzipping the jar
[Link] unzipping the jar file, you will have a directory structure like the following:
<installation_directory>/lib/com/datamirror/ts/target

/publication/userexit/sample

3. Make your changes to the sample user exit.

4. Compile the modified user exit. For example, if you want to compile
[Link], open a command window, navigate to the lib directory and
issue the following command:javac -classpath [Link]:.
com/datamirror/ts/target/publication/userexit/sample

/[Link]

If this command runs successfully, there will be no output on your screen.

Note: Your system must have the Java™ JDK to run this command.
5. After running the command successfully, navigate to the following directory and
confirm that you have created a [Link] file:<installation_directory>
/lib/com/datamirror/ts/target

/publication/userexit/sample

6. Start InfoSphere CDC.

7. The final step to configure the user exit is to specify the fully qualified path to
UserExitSample in Management Console. For example:
[Link]

Note: Do not specify the .class extension.

What to do next
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.

201
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 platform-appropriate
api directory and click the [Link] file to open the Javadoc documentation in your
browser:
- UNIX and Linux—<InfoSphere CDC installation directory>/docs/api

202
Conflict resolution audit table
When InfoSphere® CDC resolves a conflict between the source and target tables, it
records information about the resolution in the TS_CONFAUD table. InfoSphere
CDC creates this table in the target metadata location that is specified during the
configuration of InfoSphere CDC.
Note:InfoSphere CDC will add data continuously to the audit table as conflicts occur,
but will never purge data from the table. Depending on the number of conflicts, the
audit table will to grow in size over time. It is the user's responsibility to schedule
maintenance (such as using a DELETE FROM statement) on the conflict resolution
audit table regularly. A good practice would be to remove the applicable information
from the audit table after you have resolved each conflict.
In this section, you will learn:

- Structure of the conflict resolution audit table

- Row image format
- Truncated images
- Unaudited data types

203
Structure of the conflict resolution audit table
You can use the TS_CONFAUD table to track how conflict resolution affects your
target table. For example, you can query the AFTERIMG column to see when a
change was made to the target table. Then you can review the contents of the
BEFOREIMG and AFTERIMG columns to see the change on the source table that
resulted in the data on the target table. This can help in identifying issues in your
conflict resolution strategy.
Conflict detection and resolution is configured in Management Console.
The structure of the TS_CONFAUD table is as follows:

Column Description
CNFTIME The date and time on the target when the
conflict was detected.
SRCTIME The time the conflicting data was applied
to the source table.
SRCSYSID The source ID of the subscription.
SRCSCHEMA The schema or library name for the
source table.
SRCNAME The name of the source table.
SRCMEMBER This field is blank.
TGTSCHEMA The schema or library for the target table.
TGTNAME The name of the target table.
TGTMEMBER This column is only used for the IBM® i
platform.
OPTYPE The row-level operation on the source
that caused the conflict. The value is one
of: 1—Inserted into the source
table.2—Updated on the source
table.3—Deleted from the source table.
CNFTYPE The type of conflict that was detected.
The value is one of: 1—Inserted into the
source table. The key for that row
already exists in the target
table.2—Updated or deleted on the
source table. The key for that row does
not exist in the target table.3—Updated
or deleted on the source table. The
images of the source and target tables
do not match.4—Unexpected conflict
was detected.
RESMTD The conflict resolution method that was
used. The value is one of: 1—Source
wins2—Target wins3—Largest value
wins4—Smallest value wins5—User
exitIf the resolution method was None,
then a row will not be entered into this
table. See your InfoSphere® CDC
documentation for more information on
these methods.
204
CNFRES Indicates if the conflict was resolved. The
value is one of: Y—Conflict was
resolved.N—Conflict was not resolved.
BEFORETRNC Indicates if the before image stored in
BEFOREIMG was truncated. The value
is one of:
Y—Value was truncated.N—Value was
not truncated.
BEFOREIMG A representation of the row in the source
table after it was changed. See Row
Image Format for more information on
the format of this column.
AFTERTRNC Indicates if the after image stored in
AFTERIMG was truncated. The value is
one of:
Y—Value was truncated.N—Value was
not truncated.
AFTERIMG A representation of the row in the source
table after it was changed. See Row
Image Format for more information on
the format of this column.
TGTIMG A representation of the row in the target
table before replication occurred. See
Row Image Format for more information
on the format of this column.
TGTTRNC Indicates if the after image stored in
TGTIMG was truncated. The value is one
of: Y—Value was truncated.N—Value
was not truncated.
WINIMG A representation of the final row in the
target table after conflict resolution has
occurred. See Row Image Format for
more information on the format of this
column.
WINTRNC Indicates if the image stored in WINIMG
was truncated. The value is one of:
Y—Value was truncated.N—Value was
not truncated.

Related concepts:
Row image format

205
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)

where 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.

206
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)

where value is the truncated value and length is the number of characters in the
truncated string.

207
Unaudited data types
The audit table does not include columns of the following data types in its images:
- IMAGE
- NTEXT
- TEXT

If the source or target table contains rows with these data types, then the image
simply overlooks them. Binary data will appear in the images as hex-encoded
characters. The image does not store any information from unsupported columns.

208
Uninstalling InfoSphere CDC for Oracle databases
This section provides step-by-step instructions on how to uninstall InfoSphere®
CDC.
In this section, you will learn:

- To uninstall InfoSphere CDC for Oracle databases (UNIX and Linux)

209
To uninstall InfoSphere CDC for Oracle databases
(UNIX and Linux)
Procedure
1. Stop InfoSphere® CDC by using the dmshutdown command.
2. At the command prompt, launch the configuration tool by issuing the following
command from the <InfoSphere CDC installation directory>/bin directory:
./dmconfigurets
3. Enter 1 and press Enter to list the installed instances of InfoSphere CDC. Record
the names of all these instances. Uninstalling InfoSphere CDC is simply deleting
the InfoSphere CDC instances.
4. Enter 4 and press Enter to delete the initial instance of InfoSphere CDC.
5. Enter the instance name that you want to delete and press Enter.
6. Repeat the above steps to delete all the InfoSphere CDC instances you recorded
previously.
7. Delete the InfoSphere CDC installation directory.

210
Troubleshooting
If you encounter issues while running InfoSphere® CDC, you have a number of
options for tracking and troubleshooting issues to help with problem resolution.
There are three methods that you can use in InfoSphere CDC for tracking and
troubleshooting issues:
- Data Collection with the IBM® Support Assistant (ISA DC)
- Management Console Support Assistant
- The dmsupportinfo command, which is executed on the replication engine
If you are trying to troubleshoot issues with InfoSphere CDC version 10.2 or later on
Linux, UNIX and Windows operating systems, you should use the ISA DC tool
unless otherwise instructed by IBM Technical Support.
In this section, you will learn:

- Using the IBM Support Assistant (ISA DC)

- Locating log files
In addition to the Management Console event log, InfoSphere CDC produces
other logs to help troubleshoot installation and replication errors.
- Troubleshooting and contacting IBM Support

211
Using the IBM Support Assistant (ISA DC)
You can use the IBM® Support Assistant Data Collection tool (ISA DC) to collect
InfoSphere® CDC data to provide to IBM Technical Support to assist you in
troubleshooting issues with InfoSphere CDC, to request a product enhancement or
to ask a question about InfoSphere CDC.
ISA DC can be used with InfoSphere CDC replication engines that are version 10.2
or later, except InfoSphere CDC for z/OS®.
The ISA DC tool is included in the InfoSphere CDC installation process, and does
not require configuration. The executable files are located in the isa folder in the
InfoSphere CDC directory. Simply run the [Link], [Link] or [Link] file, as
appropriate, to launch the tool.
Prerequisites and considerations for using ISA DC
The following prerequisite must be satisfied on the machine on which ISA DC will be
run, in order to successfully use the tool:
- IBM JRE/JDK version 1.6 or later
The following issues should be taken into consideration before you attempt to use
ISA DC:
- ISA DC cannot be run remotely. It must be run on the machine where the instance
is configured.
- ISA DC cannot be used to collect data from InfoSphere CDC for z/OS.
- If InfoSphere CDC is installed but you have not configured an instance or are
unable to configure an instance, ISA DC can still be used to collect minimal data to
assist IBM Technical Support in resolving the issue.
See also:

- To use ISA DC to collect data for a product problem (command line)

- To use ISA DC to collect data for a product problem (GUI)
- To use ISA DC to collect data for a question or an enhancement request
(command line)
- To use ISA DC to collect data for a question or an enhancement request (GUI)

212
To use ISA DC to collect data for a product problem
(command line)
Procedure
1. Launch the IBM® Support [Link] the [Link] or [Link] file, located in
the isa\isadc folder in the root directory of the InfoSphere® CDC instance.
2. Enter 1 to accept the license agreement and press [Link] the license
agreement has been accepted, it will not be shown again.
3. Provide a file name and press [Link] name provided will be given to the .zip
file containing the data collection results.
If you do not want to assign a name to the data collection results, press Enter
and a default name will be used.
4. Enter 1 to confirm your chosen file name and press Enter to continue.
5. Enter 1 to run the InfoSphere Change Data CaptureSupport Assistant Data
Collector and press [Link] Welcome page is displayed.
6. Read the Welcome page information and enter 1 to proceed. Press Enter.
7. Enter 1 to collect data for a product problem and press Enter.
8. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
9. Select the name of the InfoSphere CDC instance for which data will be collected.
If you have multiple instances of InfoSphere CDC configured, you will be asked
to select which instance for which you want to collect. Enter the corresponding
number for the instance name and press Enter.
If you have a single InfoSphere CDC instance configured, it will be selected
automatically and this step will be skipped.
Even if you do not have an instance configured, ISA DC will still collect what
data is available. If no instance is configured, you can skip to Step 14.
10. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
11. If your selected instance is not running, you will be alerted by ISA DC. As only
minimal data is available if the instance is stopped, it is preferable that the
instance be running during data [Link] to start your instance. When the
instance is running, enter 1 and press Enter.
If you cannot start your instance and want to continue the data collection
process, enter 2 and press Enter.
12. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
13. If the instance is running, you will be asked for information regarding when the
problem occurred.
A. Enter the date and time when you think the problem began and press Enter.
This information must be entered in the following format: yyyy-mm-dd
hh:mm:ss
213
 B. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
C. Determine the period of time for which the data will be collected and press
[Link] amount specified will be applied as a before value and an after
value to the date and time specified previously. For example, if you select 1
Day as the time period, data will be collect for 24 hours before the specified
date and time and for the 24 hours after the specified date and time.
D. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
14. Select the method to transfer the data collection archive file and press Enter.
Choose one of the following options:
- Send using secure transfer to IBM Support (HTTPS)—Sends the .zip file to
IBM Support using a secure protocol.
- Send using FTP to IBM Support (unencrypted)—Sends the .zip file to IBM
Support using an unencrypted protocol.
- Send using FTP to another location (unencrypted)—Sends the .zip file to a
recipient of your choice, using an unencrypted protocol.
- End the collection without sending—Ends the data collection and creates
the .zip file, but does not transfer it.
15. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
16. If you chose to end the collection without sending the output, ISA DC will notify
your when the .zip file has been successfully created. Enter 1 and press Enter to
exit the application.
17. If you chose to transfer the file using HTTPS, follow these steps:
A. If you want to receive a confirmation email when the upload was successful,
enter an email address and press Enter. If you do not want to receive
confirmation, press Enter to continue.
B. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
C. Enter the PMR number that was given to you by IBM Technical Support and
press Enter. Ensure that the PMR number follows the required naming
convention of [Link]. If an unknown
PMR number is entered, you will be asked to correct the PMR number and
re-send the data.
D. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
214
18. If you chose to transfer the file to IBM Technical Support using unencrypted
FTP, follow these steps:
A. Enter the PMR number that was given to you by IBM Technical Support and
press Enter. Ensure that the PMR number follows the required naming
convention of [Link]. If an unknown PMR
number is entered, you will be asked to correct the PMR number and re-send
the data.
B. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
19. If you chose to transfer the file using unencrypted FTP, follow these steps:
A. Enter the FTP host name and press Enter.
B. Enter the user name and press Enter.
C. Enter the password for the user name and press Enter.
D. Enter the path for the directory on the FTP server and press Enter.
E. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
20. When you receive notice that the operation has completed successfully, enter 1
and press Enter to exit the application.

215
To use ISA DC to collect data for a product problem
(GUI)
Procedure
1. Launch the IBM® Support [Link] the [Link] file, located in the
isa\isadc folder in the root directory of the InfoSphere® CDC instance.
2. Read the license agreement and click OK to accept [Link] the license
agreement has been accepted, it will not be shown again.
3. Click [Link] Welcome screen opens.
4. Click OK.
5. Select A product problem from the drop down box.
6. Click OK.
7. Select the name of an InfoSphere CDC instance from the drop down list and
click [Link] you have multiple instances of InfoSphere CDC configured, you will
be asked to select which instance for which you want to collect.
If you have a single InfoSphere CDC instance configured, it will be selected
automatically and this step will be skipped.
8. If your selected instance is not running, you will be alerted by ISA DC. As only
minimal data is available if the instance is stopped, it is preferable that the
instance be running during data [Link] to start your instance. When the
instance is running, select Yes, I have started the instance from the drop down
box and click OK.
If you cannot start your instance and want to continue the data collection
process, select No, continue with minimal data collection from the drop down
box and click OK.
9. If the instance is running, you will be asked for information regarding when the
problem occurred. Enter the date and time when you think the problem began
and click [Link] information must be entered in the following format: yyyy-mm-
dd hh:mm:ss.
10. Determine the period of time for which the data will be collected and click OK.
Choose one of the following values:
- 6 hours
- 12 hours
- 1 Day
- 2 Days
- 7 Days
The amount specified will be applied as a before value and an after value to the
date and time specified previously. For example, if you select 1 Day as the time
period, data will be collect for 24 hours before the specified date and time and
for the 24 hours after the specified date and time.
11. If you chose to end the collection without sending the output, select Do not
transfer data to IBM. ISA DC will notify you when the .zip file has been
successfully created.
12. If you want to transfer the data to IBM using a secure transfer (HTTPS), select
the Transfer to IBM option.
A. Choose the HTTPS transfer type option.
B. Enter the PMR number that was given to you by IBM Technical Support.
Ensure that the PMR number follows the required naming convention of
216
 [Link]. If an unknown PMR number is
entered, you will be asked to correct the PMR number and re-send the data.
C. Enter your email address.
D. Click Transfer.
13. If you want to transfer the data to IBM using unencrypted FTP, select the
Transfer to IBM option.
A. Choose the FTP transfer type option.
B. Enter the PMR number that was given to you by IBM Technical Support.
Ensure that the PMR number follows the required naming convention of
[Link]. If an unknown PMR number is
entered, you will be asked to correct the PMR number and re-send the data.
C. Click Transfer.
14. If you choose to send the data to a location other than IBM using unencrypted
FTP, click Transfer to another server via FTP
A. Enter the email address or IP address of the recipient in the Hotmail/IP
Address field.
B. Enter the user name.
C. Enter the password.
D. Enter the path for the directory on the FTP server.
E. Click Transfer.
15. When you receive notice that the operation has completed successfully, click
Browse directory if you want to see the file you created or click Start New
Collection to collect more [Link] exit the application, close your browser tab or
window.

217
To use ISA DC to collect data for a question or an
enhancement request (command line)
Procedure
1. Launch the IBM® Support [Link] the [Link] or [Link] file, located in
the isa\isadc folder in the root directory of the InfoSphere® CDC instance.
2. Enter 1 to accept the license agreement and press [Link] the license
agreement has been accepted, it will not be shown again.
3. Provide a file name and press [Link] name provided will be given to the .zip
file containing the data collection results.
If you do not want to assign a name to the data collection results, press Enter
and a default name will be used.
4. Enter 1 to confirm your chosen file name and press Enter to continue.
5. Enter 1 to run the InfoSphere Change Data CaptureSupport Assistant Data
Collector and press [Link] Welcome page is displayed.
6. Read the Welcome page information and enter 1 to proceed. Press Enter.
7. Enter 2 to collect data for a question or an enhancement request and press
Enter.
8. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
9. Select the method to transfer the data collection archive file and press Enter.
Choose one of the following options:
- Send using secure transfer to IBM Support (HTTPS)—Sends the .zip file to
IBM Support using a secure protocol.
- Send using FTP to IBM Support (unencrypted)—Sends the .zip file to IBM
Support using an unencrypted protocol.
- Send using FTP to another location (unencrypted)—Sends the .zip file to a
recipient of your choice, using an unencrypted protocol.
- End the collection without sending—Ends the data collection and creates
the .zip file, but does not transfer it.
10. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3 and
press Enter.
11. If you chose to end the collection without sending the output, ISA DC will notify
your when the .zip file has been successfully created. Enter 1 and press Enter to
exit the application.
12. If you chose to transfer the file using HTTPS, follow these steps:
A. If you want to receive a confirmation email when the upload was successful,
enter an email address and press Enter. If you do not want to receive
confirmation, press Enter to continue.
B. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
218
 C. Enter the PMR number that was given to you by IBM Technical Support and
press Enter. Ensure that the PMR number follows the required naming
convention of [Link]. If an unknown
PMR number is entered, you will be asked to correct the PMR number and
re-send the data.
D. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
13. If you chose to transfer the file to IBM Technical Support using unencrypted
FTP, follow these steps:
A. Enter the PMR number that was given to you by IBM Technical Support and
press Enter. Ensure that the PMR number follows the required naming
convention of [Link]. If an unknown PMR
number is entered, you will be asked to correct the PMR number and re-send
the data.
B. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
14. If you chose to transfer the file using unencrypted FTP, follow these steps:
A. Enter the FTP host name and press Enter.
B. Enter the user name and press Enter.
C. Enter the password for the user name and press Enter.
D. Enter the path for the directory on the FTP server and press Enter.
E. Enter 1 to process your input and continue collecting data. Press [Link] you
want to cancel the collection, enter 2 and press Enter.
If you want to go back and change your input for the previous step, enter 3
and press Enter.
15. When you receive notice that the operation has completed successfully, enter 1
and press Enter to exit the application.

219
To use ISA DC to collect data for a question or an
enhancement request (GUI)
Procedure
1. Launch the IBM® Support [Link] the [Link] file, located in the
isa\isadc folder in the root directory of the InfoSphere® CDC instance.
2. Read the license agreement and click OK to accept [Link] the license
agreement has been accepted, it will not be shown again.
3. Click [Link] Welcome screen opens.
4. Click OK.
5. Select A question or enhancement request from the drop down box.
6. Click OK.
7. If you chose to end the collection without sending the output, select Do not
transfer data to IBM. ISA DC will notify you when the .zip file has been
successfully created.
8. If you want to transfer the data to IBM using a secure transfer (HTTPS), select
the Transfer to IBM option.
A. Choose the HTTPS transfer type option.
B. Enter the PMR number that was given to you by IBM Technical Support.
Ensure that the PMR number follows the required naming convention of
[Link]. If an unknown PMR number is
entered, you will be asked to correct the PMR number and re-send the data.
C. Enter your email address.
D. Click Transfer.
9. If you want to transfer the data to IBM using unencrypted FTP, select the
Transfer to IBM option.
A. Choose the FTP transfer type option.
B. Enter the PMR number that was given to you by IBM Technical Support.
Ensure that the PMR number follows the required naming convention of
[Link]. If an unknown PMR number is
entered, you will be asked to correct the PMR number and re-send the data.
C. Click Transfer.
10. If you choose to send the data to a location other than IBM using unencrypted
FTP, click Transfer to another server via FTP
A. Enter the email address or IP address of the recipient in the Hotmail/IP
Address field.
B. Enter the user name.
C. Enter the password.
D. Enter the path for the directory on the FTP server.
E. Click Transfer.
11. When you receive notice that the operation has completed successfully, click
Browse directory if you want to see the file you created or click Start New
Collection to collect more [Link] exit the application, close your browser tab or
window.

220
221
Locating log files
In addition to the Management Console event log, InfoSphere® CDC produces
other logs to help troubleshoot installation and replication errors.
Review the log files in the <CDC_installation directory>\Uninstall\Logs directory
if you encounter any errors during the installation of InfoSphere CDC.
If you encounter replication errors or replication stops, review any of these trace
logs:
- <CDC_installation_directory>/log—This directory contains information for an
InfoSphere CDC problem. Refer to this directory if the problem is related to
configuring an InfoSphere CDC instance. However, it is always useful to refer this
directory as well as the <CDC_installation_directory>/instance/<instance_name>
/log directory to troubleshoot any problem.
- <CDC_installation_directory>/instance/<instance_name>/log—This directory
stores trace files for a specific InfoSphere CDC instance. It is also useful to refer to
the <CDC_installation_directory>/instance/<instance_name>/log directory to
troubleshoot your problem. When tracing has been enabled, the trace files will be
enabled under <CDC_installation_directory>/instance/<instance_name>/log/on.
- <CDC_installation_directory>/instance/<instance_name>/tmp—This directory
temporarily stores data such as incomplete large transactions and large LOB data
values.
- <CDC_installation_directory>/instance/<instance_name>/stagingstore—This
directory stores sincle scrape staging store data that does not fit in memory. When
an InfoSphere CDC instance is stopped normally, the contents of this staging store
are written to files that are stored in this directory.

222
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:
- [Link]

For contact information in your region:

- [Link]

Related reference:
dmsupportinfo - Collect IBM Support information

223