CDC Admin Guide

IBM InfoSphere Change Data Capture
Version 6.5.2
InfoSphere Change Data Capture Management Console, Version 6.5.2

Management Console Administration Guide
IBM InfoSphere Change Data Capture

Version 6.5.2
InfoSphere Change Data Capture Management Console, Version 6.5.2

Management Console Administration Guide
Note Before using this information and the product it supports, read the information in Notices on page 711.
First edition, fourth revision This edition applies to version 6, release 5, modification 2 of IBM InfoSphere Change Data Capture (product number 5724-U70), version 6, release 5 of IBM InfoSphere Change Data Capture for z/OS (product number 5755-U96), version 10, release 1 of IBM InfoSphere Classic Change Data Capture for z/OS (product number 5655-W29), and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation 2008, 2011. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Overview of InfoSphere CDC . . . . . . 1
Understanding the InfoSphere CDC workflow . . . 3
Setting up user accounts . . . . . . . 25

Managing user accounts . . . . . . . . . To add a user. . . . . . . . . . . . To edit a user. . . . . . . . . . . . To delete a user . . . . . . . . . . . To copy a user . . . . . . . . . . . To change the existing role on a user account . To enable a System Administrator with user account and datastore administration privileges To view the history of a user account . . . . Managing security on user accounts . . . . . To disable a user account . . . . . . . . To require a user to change password at next login . . . . . . . . . . . . . . To override password expiration policy set in Management Console . . . . . . . . . To unlock a user account . . . . . . . . To unlock a system administrator user account Setting password and account security policies on user accounts . . . . . . . . . . . . . To set complex passwords on user accounts . To enforce password history . . . . . . . To enforce password expiry . . . . . . . To enforce password locking on failed login attempts . . . . . . . . . . . . . To enforce new account expiry . . . . . . To display previous failed login attempts . . To display the last successful login . . . . Creating user list reports . . . . . . . . . To create a user list report . . . . . . . . . . . . . . . . . 25 26 27 28 28 29 29 30 30 30
Whats new . . . . . . . . . . . . . 5 Before you start Management Console . 7

Configuring firewall settings for outbound (static) ports . . . . . . . . . . . . . . . . . 7 To configure static ports . . . . . . . . . 9 Logging in to Management Console by connecting to Access Server . . . . . . . . . . . . . 10 To log in to Management Consoleby connecting to Access Server . . . . . . . . . . . . 10 To change your log in password . . . . . . 11
. 30 . 31 . 31 31 . . . . . . . . . . 31 32 32 33 33 33 33 33 34 34
Understanding the Management Console interface . . . . . . . . . . 13 Setting preferences . . . . . . . . . 15

Setting advanced preferences . . . . . . . . To set timeout values . . . . . . . . . . To allocate memory for Management Console . . To add a character encoding . . . . . . . . To modify a character encoding . . . . . . To delete a character encoding . . . . . . . To import the CSV template . . . . . . . . To export the CSV template . . . . . . . . To show incomplete table mappings before mirroring . . . . . . . . . . . . . . Setting connection preferences . . . . . . . . To specify a default Access Server port number To specify firewall settings for outbound (static) ports . . . . . . . . . . . . . . . To connect to databases automatically . . . . Setting datastore multiuser preferences . . . . . To automatically enable multiuser configuration when adding new datastores . . . . . . . To prompt users to log comments when unlocking subscriptions . . . . . . . . . Setting prompt preferences . . . . . . . . . To set prompt preferences . . . . . . . . To automatically close progress windows . . . To show the Show Subscription Active/Edit Panel . . . . . . . . . . . . . . . To configure filtering for databases, schemas, and tables . . . . . . . . . . . . . . . Setting monitoring preferences . . . . . . . . To set the length of time for data retention . . . To set the sample rate for data collection . . . To show the subscription error indicator. . . . To reset the subscription error indicator . . . . To automatically retrieve events for selected subscription . . . . . . . . . . . . . 15 16 16 16 17 17 17 18 18 18 19 19 19 19 20 20 20 21 21 21 21 21 22 22 22 22 23
Setting up datastores . . . . . . . . 35
Managing datastores . . . . . . . . . . To add a datastore . . . . . . . . . . To edit a datastore . . . . . . . . . . To delete a datastore . . . . . . . . . To copy a datastore . . . . . . . . . . To view the history of a datastore . . . . . To set connection parameters on a datastore . Managing datastore connections . . . . . . To delete a connection . . . . . . . . . To override default connection parameters on a datastore . . . . . . . . . . . . . Assigning users to datastores . . . . . . . To assign a datastore to users . . . . . . To assign users to a datastore . . . . . . Enabling multiple users to work simultaneously on the same datastore . . . . . . . . . . . To enable multiple users to work with a datastore . . . . . . . . . . . . . Creating datastore list reports . . . . . . . To create a datastore list report . . . . . . . . . . . . . . . . . . . 35 36 36 37 37 37 37 38 39 39 40 40 41
. 42 . 43 . 43 . 44
Auditing user accounts, datastores, security policies, and general events. . 45 iii
Copyright IBM Corp. 2008, 2011
Collecting data generated by user activities . To enable auditing . . . . . . . . To generate an audit trail log . . . . To generate a security log report . . . To clear the log . . . . . . . . .
. . . . .
. . . . .
. . . . .
45 46 46 46 47
To delete a project . Exporting and importing To export projects . To import projects .
. . . projects . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
69 69 69 69
Setting up datastores for replication . . 71 Setting up and configuring subscriptions . . . . . . . . . . . . 49

Subscriptions view (Configuration perspective) . Setting up subscriptions . . . . . . . . . To add a subscription . . . . . . . . . To modify a subscription . . . . . . . . To delete a subscription . . . . . . . . Specifying network settings for subscriptions . . To specify a TCP host for a subscription . . . To specify a firewall port for a subscription. . Setting propagation control on subscriptions . . To set propagation control on a subscription . Locking subscriptions within a datastore . . . To view subscription state details . . . . . To view subscription state details in the Subscription Active/Edit Panel. . . . . . To lock a subscription for editing . . . . . To lock a subscription for editing in the Subscription Active/Edit Panel. . . . . . To unlock a subscription . . . . . . . . To unlock a subscription in the Subscription Active/Edit Panel . . . . . . . . . . To unlock a subscription (System Administrator) To unlock a subscription in the Subscription Active/Edit Panel (System Administrator) . . To view the history report for a subscription . Determining error handling for subscriptions . . To set error handling for a subscription . . . Making subscriptions persistent . . . . . . To mark a subscription as persistent . . . . Searching for tables used in replication . . . . To search for subscriptions that use a table in replication . . . . . . . . . . . . . Setting up subscriptions for datastores outside of your organization . . . . . . . . . . . To add a subscription for an external target datastore . . . . . . . . . . . . . To modify a subscription for an external target datastore . . . . . . . . . . . . . Copying subscriptions . . . . . . . . . . To copy a subscription. . . . . . . . . To copy a subscription for an external target datastore . . . . . . . . . . . . . Upgrading existing Transformation Server subscriptions to InfoSphere CDC . . . . . . To upgrade a subscription . . . . . . . To transfer a bookmark from the original subscription to the upgraded subscription . . To clear the table capture point on the original subscription . . . . . . . . . . . . Reverting to Transformation Server . . . . . To downgrade a subscription . . . . . . Using projects to organize your subscriptions . . To add a project . . . . . . . . . . . To rename a project. . . . . . . . . . . . . . . . . . . . . . 50 50 51 52 52 52 53 53 53 54 54 55 Understanding the Datastores view . . . . . . Connecting to a datastore. . . . . . . . . . To connect to a datastore . . . . . . . . . To disconnect from a datastore . . . . . . . Shutting down a datastore . . . . . . . . . To shut down a datastore. . . . . . . . . Updating access parameters for a subscription. . . To update access parameters for a subscription Setting system parameters on source and target datastores . . . . . . . . . . . . . . . To add a system parameter . . . . . . . . To modify a system parameter . . . . . . . To delete a system parameter . . . . . . . Creating aliases for a target datastore on a private network connection. . . . . . . . . . . . To add an alias . . . . . . . . . . . . To modify an alias . . . . . . . . . . . To delete an alias . . . . . . . . . . . Handling a changed host name or port information for a datastore . . . . . . . . . . . . . To update host name and port changes for source datastores and associated subscriptions . . . . To update host name and port changes for target datastores and associated subscriptions . . . . 71 72 72 72 73 73 73 73 73 74 74 74 74 75 75 75 75 76 77
. 55 . 55 . 55 . 56 . 56 56 . . . . . . . 57 57 57 57 58 59 59
Managing tables available for replication . . . . . . . . . . . . . 79

Updating, removing, and viewing tables for replication . . . . . . . . . . . . . To update the definition of a table . . . . To remove a table from Management Console To view the properties of a table . . . . Updating the definition of a mapped source and target table in a subscription. . . . . . . To update the definition of a source table . To update the definition of a target table . . . . . . . . . . . . 79 79 80 80
. 59 . 60 . 60 . 61 . 61 . 61 . 63 . 64 . 65 . 66 . . . . . . 66 67 67 68 68 68
. 80 . 81 . 81
Mapping tables . . . . . . . . . . . 83
Table Mappings view . . . . . . . . . . . Understanding filtering and mapping tables . . . To manually define a filter . . . . . . . . Mapping using standard replication . . . . . . To map multiple source tables using standard replication . . . . . . . . . . . . . . To map multi-member tables to existing tables on IBM i using standard replication . . . . . . To map multi-member tables to new tables on IBM i using standard replication . . . . . . To map multiple source tables for InfoSphere Classic CDC for z/OS using standard replication . To map a single source table using standard replication . . . . . . . . . . . . . . To map a single multi-member source table on IBM i using standard replication . . . . . . 83 86 86 87 87 89 90 91 92 94
iv
InfoSphere Change Data Capture: Management Console Administration Guide
Mapping using LiveAudit . . . . . . . . . 95 To map multiple source tables to existing tables using LiveAudit . . . . . . . . . . . . 96 To map multiple source tables to new tables using LiveAudit . . . . . . . . . . . . 97 To map a single source table using LiveAudit . . 98 To map a single multi-member source table using LiveAudit for IBM i . . . . . . . . . . 99 Mapping using Adaptive Apply . . . . . . . 100 To map multiple source tables for bulk Adaptive Apply . . . . . . . . . . . . . . . 101 To map a single source table using Adaptive Apply . . . . . . . . . . . . . . . 102 To map a multi-member source table using Adaptive Apply on IBM i . . . . . . . . 104 Mapping to summarize data . . . . . . . . 105 To map a source table to summarize data . . . 105 To map a multi-member source table to summarize data on IBM i . . . . . . . . 107 Mapping to consolidate data (one-to-one) . . . . 108 To map a source table to consolidate data (one-to-one) . . . . . . . . . . . . . 109 To map a multi-member source table to consolidate data on IBM i (one-to-one) . . . . 110 Mapping to consolidate data (one-to-many) . . . 111 To map a source table to consolidate data (one-to-many) . . . . . . . . . . . . 113 To map a multi-member source table to consolidate data on IBM i (one-to-many) . . . 114 Mapping to a datastore outside of your organization . . . . . . . . . . . . . . 116 To map source tables for a subscription on an external datastore . . . . . . . . . . . 116 Mapping using InfoSphere DataStage . . . . . 117 To map multiple source tables to InfoSphere DataStage using flat files . . . . . . . . 119 To map multiple source tables to InfoSphere DataStage using Direct Connect . . . . . . 119 To map a single source table to InfoSphere DataStage using flat files . . . . . . . . 120 To map a single source table to InfoSphere DataStage using Direct Connect . . . . . . 121 Generating an InfoSphere DataStage definition file for a subscription . . . . . . . . . . . . 121 To generate an InfoSphere DataStage definition file . . . . . . . . . . . . . . . . 123 Mapping to a JMS Message Destination using InfoSphere CDC Event Server . . . . . . . . 123 To map multiple source tables to a JMS message destination . . . . . . . . . . . . . 126 To map a single source table to a JMS message destination . . . . . . . . . . . . . 127 To stage a source table . . . . . . . . . 129 Remapping a source table . . . . . . . . . 130 To remap a source table . . . . . . . . . 130 To remap a source table (InfoSphere CDC Event Server) . . . . . . . . . . . . . . 131 Copying selected table mappings . . . . . . . 131 To copy selected table mappings . . . . . . 131 To copy selected table mappings for an external target datastore . . . . . . . . . . . . 132
Deleting table mappings. . . . . . . . . To delete a table mapping . . . . . . . To delete a table mapping (InfoSphere CDC Event Server) . . . . . . . . . . . Exporting and importing subscriptions and selected table mappings . . . . . . . . . To export a subscription into an XML file . . To export selected table mappings into an XML file . . . . . . . . . . . . . . . To import a subscription from an XML file . Modifying table mappings . . . . . . . . To modify table mappings . . . . . . .
. 133 . 133 . 133 . 134 . 134 . . . . 135 135 135 135
Replicating Data Definition Language (DDL) changes . . . . . . . . . . . 137

Prerequisites and considerations for replicating DDL changes in InfoSphere CDC for Oracle databases version 6.5.1 . . . . . . . . . Supported DDL operations . . . . . . . . Working with rule sets . . . . . . . . . To define a rule set for a subscription . . . To delete a rule set . . . . . . . . . Modifying rule sets . . . . . . . . . . To change the name of a rule set . . . . . To change the schema for a rule set . . . . To add tables to a rule set . . . . . . . To remove tables from a rule set . . . . . To change the structural replication value for a rule set . . . . . . . . . . . . . To edit a pattern for a rule set . . . . . . To delete a pattern from a rule set . . . . Copying rule sets . . . . . . . . . . . To copy selected rule sets . . . . . . . Exporting rule sets . . . . . . . . . . To export selected rule sets into an XML file . Promoting rule sets . . . . . . . . . . To promote selected rule sets to a new subscription . . . . . . . . . . . . To promote selected rule sets to an existing subscription . . . . . . . . . . . . Changing the refresh order of tables in a Rules-based subscription . . . . . . . . To change the refresh order of tables . . . Previewing tables in-scope for DDL replication . To preview tables in a subscription that match rule sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 139 140 142 144 144 145 145 145 145 146 146 147 147 147 148 148 148
. 149 . 150 . 151 . 151 . 152 . 152
Customizing InfoSphere DataStage table mappings . . . . . . . . . . 155

Setting properties for a subscription that targets InfoSphere DataStage. . . . . . . . . . To specify batch size thresholds for an InfoSphere DataStage subscription . . . . To specify large object truncation size for an InfoSphere DataStage subscription . . . . To specify the file name format for an InfoSphere DataStage subscription . . . . To specify Direct Connect settings for an InfoSphere DataStage subscription . . . . . 155 . 156 . 156 . 157 . 157
Contents
Understanding data types supported by InfoSphere CDC . . . . . . . . . 159

Supported data types. . . . Supported column mappings . . . . . . . . . . . . . . 159 . 163
Using journal control fields for auditing replication activities . . . . 197

About journal control fields . . . . . . Commit Cycle ID (&CCID) . . . . . . Source RRN (&CNTRRN) . . . . . . Entry Type Code (&CODE) . . . . . . Entry Type (&ENTTYP) . . . . . . . Source Job Name (&JOB) . . . . . . Source Job Number (&JOBNO) . . . . Source Job User (&JOBUSER) . . . . . Journal Name (&JOURNAL) . . . . . Source Table Library (&LIBRARY) . . . Source Table Member Name (&MEMBER) . Source Table Name (&OBJECT) . . . . Source Program Name (&PROGRAM) . . Journal Sequence Number (&SEQNO) . . Source Server Name (&SYSTEM) . . . . Record Modification Time (&TIMSTAMP) . Record Modification User (&USER) . . . About journal codes . . . . . . . . . Table Clear . . . . . . . . . . . Delete . . . . . . . . . . . . . Insert . . . . . . . . . . . . . Update Before . . . . . . . . . . Update After . . . . . . . . . . Translating journal codes into meaningful information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 198 198 199 199 200 200 201 202 203 203 204 204 205 206 207 207 208 209 210 210 210 211
Mapping columns . . . . . . . . . 173

Mapping source columns to target columns . . To map a source column to a target column . Mapping journal control fields to target columns To map a journal control field to a target column . . . . . . . . . . . . . Mapping expressions to target columns . . . To map an expression to a target column . . To accumulate or deduct numeric data on a target column . . . . . . . . . . . Mapping source and target columns automatically To map columns automatically . . . . . Mapping initial values to target columns . . . To define an initial value for a target column Adding and mapping derived columns to target columns . . . . . . . . . . . . . . To add a derived column . . . . . . . To map a derived column to a target column To modify a derived column . . . . . . To delete a derived column. . . . . . . . 173 . 173 174 . 174 . 175 . 175 . 176 176 . 177 . 177 178 . 178 . 179 180 . 181 . 181
Setting data translations on column mappings . . . . . . . . . . . . . 183

Setting data translations . . . . . . . To add a data translation . . . . . To modify a data translation . . . . To delete a data translation . . . . . Importing and exporting data translations . To export a data translation . . . . To import a data translation . . . . . . . . . . . . . . . . . . . . . . . . . 183 184 184 185 185 185 186
. 211
Controlling table operations . . . . . 213

Controlling the apply of refresh operations To keep all rows on a refresh . . . . To delete all rows on a refresh. . . . To audit rows on a refresh . . . . . Specifying SQL to control refresh operations To specify additional SQL after a refresh To delete selected rows on a refresh . . . . . . . . . . . . . . . . . . . . . . . 213 213 214 214 215 216 216
Replicating multibyte (MBCS) and double-byte (DBCS) character data . . 187

Common encoding conversion scenarios . . . Considerations when replicating MBCS character data . . . . . . . . . . . . . . . Upgrading subscriptions to use auto-encoding mode . . . . . . . . . . . . . . . To upgrade subscriptions to use auto-encoding mode . . . . . . . . . . . . . . Configuring MBCS encoding conversion between your source and target . . . . . . . . . To configure MBCS encoding conversion . . Specifying the workload preference . . . . . To set the workload preference . . . . . Handling Unicode character encoding . . . . To set handling for Unicode character encoding . 188 . 189 . 190 . 191 . . . . . 191 191 192 193 193 194
Configuring user exits . . . . . . . 219

Configuring table-level user exits . . . . . . . To configure a stored procedure . . . . . . To configure a derived column or an expression that calls %STPROC, %USER, or %USERFUNC . To configure a user exit for a Java class. . . . Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server. . . . . . . . To configure for IDispatch COM DLL . . . . To configure for C or C++ . . . . . . . . To configure a stored procedure . . . . . . Configuring table-level user exits for InfoSphere CDC for Oracle databases (version 6.1 and below) or InfoSphere CDC for Sybase databases (version 6.1 and below) . . . . . . . . . . . . . To configure a C shared library . . . . . . To configure a stored procedure (Oracle and Sybase) . . . . . . . . . . . . . . To configure a derived column or an expression that calls %STPROC (Oracle and Sybase) . . . Configuring table-level user exits for InfoSphere CDC for IBM i (version 6.2 and below) or InfoSphere CDC for z/OS . . . . . . . . . 219 220 221 222 223 224 225 226
228 229 230 231
Setting member identifiers. . . . . . 195

Setting member identifiers for multi-member source tables . . . . . . . . . . . To add a member identifier. . . . . . To modify a member identifier . . . . To delete a member identifier . . . . . . . . . . . . . 195 195 196 196
231
vi
To configure a standard function . . . . . . Creating a custom data format for IBM InfoSphere DataStage . . . . . . . . . . . . . . To create a custom data format for InfoSphere DataStage . . . . . . . . . . . . . To modify an existing custom data format when upgrading from InfoSphere DataStage 6.3 to 6.5 . Configuring subscription-level user exits . . . . To configure a user exit for a subscription . . . Understanding user exit configuration for InfoSphere CDC Event Server . . . . . . . . Overriding JMS message header properties . . . To override JMS message header properties . . Sending the XML message to a different JMS message destination . . . . . . . . . . . To send the XML message to another JMS message destination . . . . . . . . . . Creating XML output and applying XSLT to an XML message . . . . . . . . . . . . . To create an XML message and apply XSLT . . Sending XML messages to multiple JMS message destinations . . . . . . . . . . . . . . To send an XML message to a different JMS message destination . . . . . . . . . . Querying a Web service to access content . . . . To query a Web service to access content . . . Content based routing . . . . . . . . . . To route the content of an XML message to another JMS message destination . . . . . .
231 232 233 233 234 234 235 235 235 236 237 238 239 240 240 241 242 243 243
Column functions . . . . . . . . . 245

Conventions in using column functions . . String functions . . . . . . . . . . Concatenation%CONCAT . . . . . Lowercase%LOWER . . . . . . . Left trim%LTRIM . . . . . . . . Capitalization%PROPER . . . . . . Character substitution%REPLACE. . . Right trim%RTRIM. . . . . . . . Substring%SUBSTRING . . . . . . Uppercase%UPPER . . . . . . . Date and time functions . . . . . . . . Century%CENTURY . . . . . . . Current date%CURDATE. . . . . . Current time%CURTIME . . . . . . Current timestamp%CURTMSTP . . . Conversion functions . . . . . . . . . Character conversion%TOCHAR . . . Character format conversion %TOCHARFORMAT . . . . . . . . Date conversion%TODATE . . . . . Date and time conversion%TODATETIME Number conversion%TONUMBER . . Time conversion%TOTIME . . . . . Conditional and variable functions . . . . Conditional%IF . . . . . . . . . Variable%VAR . . . . . . . . . Data functions . . . . . . . . . . . Before value%BEFORE . . . . . . Current value%CURR . . . . . . . Retrieve column%GETCOL (DB2 for i) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 246 246 247 248 249 250 251 252 253 254 254 255 256 258 259 259
. 261 . 262 263 . 266 . 267 . 269 . 269 . 270 . 271 . 271 . 271 . 273
Retrieve column%GETCOL (Dynamic SQL) Retrieve column%SELECT . . . . . . . User exit functions . . . . . . . . . . . Stored procedure%STPROC . . . . . . . User exit%USER . . . . . . . . . . User exit%USER (InfoSphere CDC for Microsoft SQL 5.x). . . . . . . . . . . User Exit%USERFUNC . . . . . . . . %GETCOL column function scenarios (DB2 for IBM i) . . . . . . . . . . . . . . . . Retrieving a column from another table using the %GETCOL function (DB2 for i) . . . . . Performing an outer join using the %GETCOL function (DB2 for i) . . . . . . . . . . Nesting columns to join data using the %GETCOL function (DB2 for i) . . . . . . Combining columns using the %GETCOL function (DB2 for i) . . . . . . . . . . %GETCOL column function scenarios (Dynamic SQL) . . . . . . . . . . . . . . . . Retrieving a column using the %GETCOL function (Dynamic SQL). . . . . . . . . Retrieving a column using the %GETCOL function without reading the same row from the table . . . . . . . . . . . . . . . Retrieving a column using nested %GETCOL functions (Dynamic SQL) . . . . . . . . Filtering rows using the %GETCOL function (Dynamic SQL) . . . . . . . . . . . . Publishing multiple derived columns using the %GETCOL function (Dynamic SQL) . . . . . . XPath functions . . . . . . . . . . . . ceiling . . . . . . . . . . . . . . . concat . . . . . . . . . . . . . . . contains . . . . . . . . . . . . . . floor . . . . . . . . . . . . . . . false . . . . . . . . . . . . . . . formatNumber . . . . . . . . . . . . normalizeSpace. . . . . . . . . . . . not . . . . . . . . . . . . . . . . number . . . . . . . . . . . . . . position . . . . . . . . . . . . . . round . . . . . . . . . . . . . . . startsWith . . . . . . . . . . . . . string . . . . . . . . . . . . . . . stringLength. . . . . . . . . . . . . substring . . . . . . . . . . . . . . substringAfter . . . . . . . . . . . . substringBefore . . . . . . . . . . . . sum . . . . . . . . . . . . . . . translate . . . . . . . . . . . . . . true . . . . . . . . . . . . . . . Transform extensions . . . . . . . . . . . sxt:add . . . . . . . . . . . . . . sxt:db-lookup . . . . . . . . . . . . sxt:divide. . . . . . . . . . . . . . sxt:filter . . . . . . . . . . . . . . sxt:formatDate . . . . . . . . . . . . sxt:getSequentialNum . . . . . . . . . sxt:getSubField . . . . . . . . . . . . sxt:getSysDateTime . . . . . . . . . .
Contents
276 279 283 283 284 288 289 291 291 292 292 292 293 293
293 294 295 295 296 297 297 297 297 298 298 298 298 299 299 299 299 300 300 300 300 301 301 301 302 302 303 303 303 304 304 305 305 305
vii
sxt:getSysDate . . . . sxt:getSysTime . . . . sxt:groupConcat . . . sxt:ifExist . . . . . . sxt:ifReturn . . . . . sxt:isEqual . . . . . sxt:multiply . . . . . sxt:nodeConcat . . . . sxt:padLeft . . . . . sxt:padRight . . . . . sxt:proper . . . . . sxt:setDefault . . . . sxt:subtract . . . . . sxt:toLowerCase . . . sxt:toUpperCase . . . sxt:trim . . . . . . Using external Java objects in Simple string objects (type SQL data types (type II) . XML objects (type III) . XPath expression operators . + Operator . . . . . - Operator . . . . . * Operator . . . . . div Operator . . . . mod Operator . . . . = Operator . . . . . != Operator . . . . . < Operator . . . . . <= Operator . . . . . > Operator . . . . . >= Operator . . . . . or Operator . . . . . and Operator . . . . () parentheses Operator . [ ] Operator . . . . . / Operator . . . . . // Operator . . . . . @ Operator . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . data I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
306 306 306 306 307 307 307 307 308 308 308 309 309 309 310 310 310 310 311 311 311 312 312 312 312 312 312 312 313 313 313 313 313 313 313 314 314 314 314
Controlling row operations . . . . . 327

Suppressing the apply of row operations . . . . To suppress an insert, update, or delete . . . Preventing the audit of row operations . . . . . To prevent row operations from being audited To audit only the after image . . . . . . . Detecting conflicts on row operations . . . . . To detect conflicts on row operations . . . . Enabling the apply of soft deletes (InfoSphere CDC for Oracle databases) . . . . . . . . . . . To enable InfoSphere CDC for Oracle to apply a soft delete . . . . . . . . . . . . . 327 327 328 328 328 329 329 330 330
Customizing JMS message destination mappings . . . . . . . . 331

Creating an XML message . . . . . . . . To create an XML message . . . . . . . Importing and exporting XML files, schemas, and mapping projects . . . . . . . . . . . To import an XML, schema, or mapping definition file . . . . . . . . . . . To export an XML schema or mapping definition file . . . . . . . . . . . Building an XPath expression . . . . . . . To build an XPath expression . . . . . . Querying columns from other tables. . . . . To query columns from other tables . . . . . 331 . 331 . 332 . 333 . . . . . 333 334 334 335 335
Setting JMS message header properties . . . . . . . . . . . . . 339

Defining the JMS message header . . . . . . To add a JMS message header property . . . To add a custom JMS message header property To delete a custom JMS message header property . . . . . . . . . . . . . . Setting general runtime options . . . . . . . To enable InfoSphere CDC Event Server to trim text . . . . . . . . . . . . . . . . To disable InfoSphere CDC Event Server from differentiating between an empty string from a NULL value . . . . . . . . . . . . . To disable streamed transformation mode . . . 339 339 340 340 341 341
Filtering rows and columns . . . . . 315

Filtering rows . . . . . . . . . To filter rows . . . . . . . . Selecting critical columns to filter rows . To select critical columns . . . . Filtering columns . . . . . . . . To filter columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 315 316 316 316 317
342 342
Configuring replication . . . . . . . 343

Flagging a source table for refresh . . . . . To flag a source table for a Standard Refresh To flag a source table for a Differential Refresh Sample: Refreshing subsets of rows . . . . Marking a table capture point on a source table To mark a table capture point on a source table before mirroring . . . . . . . . . . Parking a table from replication . . . . . . To park a table from replication . . . . . Changing the refresh order of tables . . . . . To change the refresh order of tables . . . Changing the replication method of a table . . To change the replication method of a table . Selecting a new journal table . . . . . . . To select a new journal table . . . . . . Setting members for replication . . . . . . . 343 345 346 . 346 348 . . . . . . . . . . 349 349 349 349 350 350 350 351 352 353
Setting conflict detection and resolution . . . . . . . . . . . . . 319

Resolving conflicts for source or target wins . To resolve conflicts for source row wins . To resolve conflicts for target row wins . . Resolving conflicts for largest or smallest value wins . . . . . . . . . . . . . . To resolve conflicts for largest value wins . To resolve conflicts for smallest value wins Resolving conflicts with user exits . . . . To resolve conflicts with user exit programs . . . . . . . . . 319 . 321 . 321 . . . . . 321 323 323 323 324
viii
To select a member for replication . . . . Changing the message destination . . . . . To change the message destination of a table
. 353 . 353 353
Starting and ending replication. . . . 355

Starting mirroring . . . . . . . . . . . To start continuous mirroring . . . . . . To start scheduled end (net-change) mirroring Starting a refresh on a subscription . . . . . To start a refresh . . . . . . . . . . Ending replication . . . . . . . . . . . To end replication . . . . . . . . . . Sending XML messages to a JMS message destination . . . . . . . . . . . . . To send an XML message to a JMS message destination or a staging target database. . . . 356 . 357 357 . 358 . 360 . 361 . 362 . 363 . 363
Setting notifications . . . . . . . . 365

Selecting a notification handler . . . . . . Choosing a notification category and a message type . . . . . . . . . . . . . . . Setting notifications for a datastore . . . . . To set an e-mail (MAPI) notification . . . . To set an email (SMTP) notification . . . . To set an e-mail notification (InfoSphere CDC for Oracle) . . . . . . . . . . . . To set an e-mail notification . . . . . . To set a notification for the CHCPRINT spool file . . . . . . . . . . . . . . . To set a notification for an operator system log To set a notification for a UNIX system log . To set a notification using a user exit program To set a notification using a user exit program To set a notification using a user exit program To set a notification for a message queue . . To filter a notification message . . . . . Setting notifications for a subscription . . . . To set notifications for a subscription . . . To view the datastore default notifications for a subscription . . . . . . . . . . . . Copying notifications for a subscription . . . To copy notification settings . . . . . . Setting latency thresholds and notifications . . To set a latency threshold and notification . . . 366 . . . . 367 368 368 369
. 369 . 370 . 370 370 . 371 371 371 372 . 372 . 373 . 373 . 373 . . . . . 374 374 374 374 375
Displaying the replication diagram . . . . . Viewing latency for a subscription . . . . . To view latency values for a subscription . . Viewing replication activity. . . . . . . . To view replication activities for a subscription Viewing replication events . . . . . . . . To view events (InfoSphere CDC version 6.5 and later). . . . . . . . . . . . . To retrieve events that occurred within a date range (InfoSphere CDC version 6.5 and later) To view events (InfoSphere CDC version 6.3 and earlier) . . . . . . . . . . . . To view event details . . . . . . . . . To copy events . . . . . . . . . . . To clear all events for the selected subscription To clear selected events for the selected subscription . . . . . . . . . . . . To export events . . . . . . . . . . Performance view (Monitoring perspective) . . Available metrics . . . . . . . . . . . Datastore metrics . . . . . . . . . . Database Workload metrics . . . . . . . Log cache metrics . . . . . . . . . . Log reader metrics . . . . . . . . . Log parser metrics. . . . . . . . . . Single Scrape metrics . . . . . . . . . Source Engine metrics . . . . . . . . Communications metrics . . . . . . . Target Engine metrics . . . . . . . . Target Apply metrics . . . . . . . . . Analyzing subscription performance. . . . . To chart metrics for a subscription . . . . To change the metrics when you are already collecting data . . . . . . . . . . . To chart metrics for tables . . . . . . . To view the busiest tables in a subscription . To stop table-level performance monitoring .
389 390 391 391 393 . 393 . 395 . 395 . 396 . 396 . 397 397 . . . . . . . . . . . . . . . . . . . . 397 398 398 399 399 402 403 404 407 408 409 413 415 418 422 423 423 424 424 424
. . . .
System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier)
General product system parameters AuthCode . . . . . . . DBMS . . . . . . . . . dbUser . . . . . . . . dllname . . . . . . . . DSN . . . . . . . . . NetServiceName . . . . . pwdencrypt . . . . . . . Startup Timeout . . . . . TSSrcCP . . . . . . . . TSTgtCP . . . . . . . . TCP_KEEPALIVE_SECS . . . WindowsAuthentication . . . Replication system parameters . AutoRestart . . . . . . . convertNotNullableColumns . MirrorError . . . . . . . RefreshError. . . . . . . RefreshMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 425
. . . . . . . . . . . . . . . . . . . 425 426 426 426 426 426 427 427 427 428 428 428 429 429 429 430 430 431 431
Promoting subscription changes . . . 377

Before you promote a subscription or selected table mappings . . . . . . . . . . . . . . Promoting subscriptions . . . . . . . . . . To promote a subscription to a new subscription To promote changes to an existing subscription Promoting selected table mappings . . . . . . To promote selected table mappings to a new environment. . . . . . . . . . . . . To promote selected table mappings to an existing subscription . . . . . . . . . . 377 378 379 380 382 382 384
Monitoring subscriptions . . . . . . 387

Subscriptions view (Monitoring perspective) Understanding subscription states . . . . . . . 387 . 388
Contents
ix
Database translation log system parameters Cleanup Interval . . . . . . . . Cleanup Log Events . . . . . . . Cleanup Record Count . . . . . . LogCleanupMethod . . . . . . . Report Position Interval . . . . . . Synchronization Interval. . . . . . Commitment control system parameters . CommitmentControl . . . . . . . Commit Group Size . . . . . . . RefreshBlock . . . . . . . . . SeparateCommits . . . . . . . . Event log system parameters . . . . . AllowEventLogClear . . . . . . . Multibyte character set system parameters. Unicode Handling . . . . . . . . Latency system parameters . . . . . . Deadband Percentage . . . . . . Monitor Sample Interval. . . . . . Notification system parameters . . . . implicit_transformation_warning . . . DM_STATUS_INTERVAL . . . . . Heartbeat Timeout. . . . . . . . InvalidNumericMsg . . . . . . . Tracing system parameters . . . . . . CommTrace . . . . . . . . . . ProgramTrace . . . . . . . . . traceActive . . . . . . . . . . TraceLevel . . . . . . . . . . trcCleanup . . . . . . . . . . trcCOMM . . . . . . . . . . trcFiles . . . . . . . . . . . trcFncCalls . . . . . . . . . . trcJrlSync . . . . . . . . . . . trcReplStatus . . . . . . . . . trcScan . . . . . . . . . . . trcSQL. . . . . . . . . . . . trcThread . . . . . . . . . . . Data type system parameters . . . . . TrimVarchar . . . . . . . . . . Lock detection system parameters . . . DeadlockRetrys. . . . . . . . . DM_LOCK_DETECTION . . . . . DM_LOCK_TIMEOUT . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
432 432 432 433 434 434 435 436 436 437 437 438 438 438 439 439 440 440 442 442 442 443 444 444 445 445 446 446 446 447 447 447 448 448 448 448 448 448 449 449 449 449 449 450
global_unicode_as_char . . . . . . . . . 456 Supplemental logging system parameters . . . . 456 mirror_logging_by_empty_triggers . . . . . 457 Disk resource system parameters . . . . . . . 457 mirror_global_disk_quota_mb . . . . . . . 457 mirror_global_disk_quota_gb . . . . . . . 458 staging_store_can_run_independently . . . . 459 staging_store_disk_quota_gb . . . . . . . 459 Apply process system parameters . . . . . . 459 convert_not_nullable_column . . . . . . . 460 global_default_after_database_minimum_timestamp 460 global_default_before_database_minimum_timestamp 461 mirror_end_on_error . . . . . . . . . . 461 mirror_expected_errors_list . . . . . . . . 461 refresh_end_on_error . . . . . . . . . . 462 refresh_expected_errors_list . . . . . . . 462 refresh_loader_drop_index . . . . . . . . 462 refresh_with_referential_integrity . . . . . . 463 userexit_max_lob_size_kb . . . . . . . . 463
System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) . . . . . . . . . . . . 465
General product system parameters . . . . . . 465 CODE_PAGE . . . . . . . . . . . . 466 DEFAULT_ORACLE_HOME . . . . . . . 466 DEFAULT_ORACLE_SID . . . . . . . . 466 DEFAULT_ORACLE_USER . . . . . . . . 467 DM_COMMS_HOME . . . . . . . . . 467 D_MIRROR_HOME . . . . . . . . . . 467 D_MIRROR_LOG . . . . . . . . . . . 467 DM_DYNAMIC_PARAMETER_CHECK_INT 468 DM_MAX_MONITOR_ENTRIES . . . . . . 468 DM_TS_MAX_POOL_SIZE_MB . . . . . . 469 DM_TS_POOL_BLOCK_SIZE_MB . . . . . 469 <subscription>_MAX_POOL_SIZE_MB . . . . 470 <subscription>_POOL_BLOCK_SIZE_MB . . . 470 LD_LIBRARY_PATH . . . . . . . . . . 471 LIBPATH . . . . . . . . . . . . . . 471 ORACLE_HOME . . . . . . . . . . . 471 ORACLE_SID . . . . . . . . . . . . 472 PASSWORD . . . . . . . . . . . . . 472 PUBLISH_METADATA . . . . . . . . . 472 RLD_SYSTEM_TXQSIZE . . . . . . . . 473 <subscription>_TXQSIZE . . . . . . . . . 473 SHLIB_PATH . . . . . . . . . . . . 474 STARTUP_TIMEOUT. . . . . . . . . . 474 TCP_KEEPALIVE_SECS . . . . . . . . . 474 USER . . . . . . . . . . . . . . . 475 Apply process system parameters . . . . . . 475 convertNotNullableColumns . . . . . . . 476 D_MIRROR_MIRROR_ERROR_LIST. . . . . 476 D_MIRROR_MIRROR_ERROR_STOP . . . . 477 D_MIRROR_REFRESH_ERROR_LIST . . . . 477 D_MIRROR_REFRESH_ERROR_STOP . . . . 478 DM_ADAPTIVE_APPLY_SOFT_DELETES . . . 478 DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME> 479 DM_ADAPTIVE_APPLY_MIMIC_SOURCE_OPERATION 479 DM_ARRAY_BIND_MAX . . . . . . . . 480 FILTER_NOCHANGE_UPDATES_FOR_AUDIT 480
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later). . . . . . . . 451
General product system parameters . . . . . . 451 mirror_auto_restart_interval_minutes . . . . 451 Notification system parameters . . . . . . . 452 events_max_retain . . . . . . . . . . . 452 global_shutdown_after_no_heartbeat_response_minutes 452 global_conversion_not_possible_warning . . . 452 implicit_transformation_warning . . . . . . 453 Maximize throughput system parameters . . . . 454 global_max_batch_size . . . . . . . . . 454 mirror_interim_commit_threshold . . . . . 454 refresh_commit_after_max_operations . . . . 455 Encoding system parameters . . . . . . . . 455
NLS_LANG . . . . . . . . . . . . . 481 NLS_NCHAR . . . . . . . . . . . . 481 NOT_NULL_DATE_DEFAULT . . . . . . 481 TRIM_CHAR_TO_VARCHAR . . . . . . . 481 TRIM_VARCHAR_TO_VARCHAR . . . . . 482 TRIM_TO_NULL . . . . . . . . . . . 482 UNICODE_HANDLING. . . . . . . . . 483 Cascading replication system parameters . . . . 484 CASCADE_OMIT_TARGETS . . . . . . . 484 PREVENT_RECURSION. . . . . . . . . 485 Database journal (trigger) system parameters . . . 485 REPORT_POSITION_INTERVAL . . . . . . 485 MONITOR_PURGE_INTERVAL . . . . . . 486 MONITOR_REFRESH_PERIOD . . . . . . 486 Maximize throughput system parameters . . . . 487 COMMIT_GROUP_SIZE. . . . . . . . . 487 COMMIT_LEVEL . . . . . . . . . . . 488 COMMIT_INTERVAL . . . . . . . . . 488 MAINTAIN_TRANSACTION_CONSISTENCY 489 SYNCHRONIZATION_COMMIT_ GROUP_SIZE . . . . . . . . . . . . 489 SYNCHRONIZATION_INTERVAL . . . . . 490 TRANSACTION_GROUP_SIZE . . . . . . 490 TRANSACTION_INTERVAL . . . . . . . 491 TRANSACTION_RECORDS_THRESHOLD . . 491 Tracing system parameters . . . . . . . . . 492 D_MIRROR_SP_TRACE . . . . . . . . . 492 D_MIRROR_TRACE . . . . . . . . . . 492 D_MIRROR_TRACE_FILE_SIZE . . . . . . 493 D_MIRROR_TRACE_ON_ERROR . . . . . 493 DM_PRINT_DIAGNOSTICS . . . . . . . 494 D_MIRROR_ALARM_TRACE . . . . . . . 494 Refresh loader system parameters . . . . . . 495 DIRPATH_BUF_ROWS . . . . . . . . . 495 DIRPATH_BUF_SIZE . . . . . . . . . . 496 DIRPATH_CACHE_DATE_SIZE . . . . . . 497 DIRPATH_LOAD . . . . . . . . . . . 497 DIRPATH_LOGGING . . . . . . . . . 498 DIRPATH_DO_RECOVERY. . . . . . . . 498 User exit system parameters . . . . . . . . 499 D_MIRROR_SP_CONNECTION . . . . . . 499 DM_FROM_CODEPAGE_V4USEREXIT. . . . 499 DM_TO_CODEPAGE_V4USEREXIT . . . . . 500 Table mapping system parameters . . . . . . 500 TS_DELETE_ASSIGNED_OBJECTS_DURING_DESCRIBE 500 Notification system parameters . . . . . . . 501 implicit_transformation_warning . . . . . . 501 DEADBAND_PERCENTAGE . . . . . . . 502 DM_STATUS_INTERVAL . . . . . . . . 503 HEARTBEAT_TIMEOUT . . . . . . . . 504 LOG_EMAIL_USERNAME . . . . . . . . 504 MONITOR_SAMPLE_INTERVAL. . . . . . 505 STATISTICS_INTERVAL . . . . . . . . . 505 Disk resource system parameters . . . . . . . 506 LOG_MAX_SIZE . . . . . . . . . . . 506
mirror_auto_restart_interval_minutes . . . . 507 mirror_set_table_data_capture_timeout . . . . 508 Transaction log location system parameters . . . 508 mirror_archive_log_directory . . . . . . . 508 mirror_asm_oracle_path . . . . . . . . . 508 mirror_online_log_directory . . . . . . . 509 oracle_archive_dir . . . . . . . . . . . 509 oracle_archive_destination_id . . . . . . . 509 oracle_archive_logs_only . . . . . . . . 510 oracle_log_path_userexit. . . . . . . . . 510 oracle_log_shipping . . . . . . . . . . 510 oracle_using_log_transport_services . . . . . 511 Notification system parameters . . . . . . . 512 events_max_retain . . . . . . . . . . . 512 global_conversion_not_possible_warning . . . 513 global_shutdown_after_no_heartbeat_response_minutes 513 implicit_transformation_warning . . . . . . 513 Maximize throughput system parameters . . . . 514 mirror_interim_commit_threshold . . . . . 514 mirror_sess_hist_age_threshold . . . . . . 515 mirror_src_ora_version . . . . . . . . . 515 refresh_commit_after_max_operations . . . . 515 userexit_max_lob_size_kb . . . . . . . . 516 Encoding system parameters . . . . . . . . 516 global_unicode_as_char . . . . . . . . . 516 Disk resource system parameters . . . . . . . 517 mirror_global_disk_quota_mb . . . . . . . 517 mirror_global_disk_quota_gb . . . . . . . 518 staging_store_can_run_independently . . . . 518 staging_store_disk_quota_gb . . . . . . . 519 staging_store_disk_quota_mb . . . . . . . 519 Apply process system parameters . . . . . . 520 convert_not_nullable_column . . . . . . . 520 global_max_batch_size . . . . . . . . . 520 mirror_end_on_error . . . . . . . . . . 521 mirror_expected_errors_list . . . . . . . . 521 refresh_end_on_error . . . . . . . . . . 522 refresh_expected_errors_list . . . . . . . 522 refresh_in_unicode . . . . . . . . . . 523 refresh_with_referential_integrity . . . . . . 523 trim_char_to_varchar . . . . . . . . . . 523 trim_varchar_to_varchar. . . . . . . . . 524 userexit_max_lob_size_kb . . . . . . . . 524
System parameters for InfoSphere CDC for Oracle databases (trigger) (version 6.3 and later). . . . . . . . 525
General product system parameters . . . . . . 525 mirror_auto_restart_interval_minutes . . . . 525 Notification system parameters . . . . . . . 526 events_max_retain . . . . . . . . . . . 526 global_conversion_not_possible_warning . . . 526 global_shutdown_after_no_heartbeat_response_minutes 526 implicit_transformation_warning . . . . . . 527 Maximize throughput system parameters . . . . 527 mirror_interim_commit_threshold . . . . . 528 refresh_commit_after_max_operations . . . . 528 Database journal (trigger) system parameters . . . 528 mirror_journal_schema . . . . . . . . . 529 Encoding system parameters . . . . . . . . 529
Contents
System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) . . . . . . . . . . . . . 507
General product system parameters . . . . . . 507
xi
global_unicode_as_char . . . . Disk resource system parameters . . mirror_global_disk_quota_mb . . mirror_global_disk_quota_gb . . Apply process system parameters . convert_not_nullable_column . . global_max_batch_size . . . . mirror_end_on_error . . . . . mirror_expected_errors_list . . . refresh_end_on_error . . . . . refresh_expected_errors_list . . refresh_in_unicode . . . . . refresh_with_referential_integrity . trim_char_to_varchar . . . . . trim_varchar_to_varchar. . . . userexit_max_lob_size_queue_kb .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
529 530 530 531 531 531 532 532 533 533 533 534 534 535 535 535
System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) . . . . . . . . . . . 537
General product system parameters . . . . . CODE_PAGE . . . . . . . . . . . D_MIRROR_HOME . . . . . . . . . D_MIRROR_LOG . . . . . . . . . . DM_DYNAMIC_PARAMETER_CHECK_INT DM_MAX_MONITOR_ENTRIES . . . . . DSQUERY . . . . . . . . . . . . LD_LIBRARY_PATH . . . . . . . . . LIBPATH . . . . . . . . . . . . . PUBLISH_METADATA . . . . . . . . SYBASE . . . . . . . . . . . . . SYBASE_OCS . . . . . . . . . . . SHLIB_PATH . . . . . . . . . . . STARTUP_TIMEOUT. . . . . . . . . USER . . . . . . . . . . . . . . Apply process system parameters . . . . . convertNotNullableColumns . . . . . . D_MIRROR_MIRROR_ERROR_STOP . . . D_MIRROR_REFRESH_ERROR_STOP . . . FILTER_NOCHANGE_UPDATES_FOR_AUDIT NLS_LANG . . . . . . . . . . . . TRANSACTION_GROUP_SIZE . . . . . TRANSACTION_INTERVAL . . . . . . TRANSACTION_RECORDS_THRESHOLD . TRIM_CHAR_TO_VARCHAR . . . . . . TRIM_VARCHAR_TO_VARCHAR . . . . TRIM_TO_NULL . . . . . . . . . . Cascading replication system parameters . . . PREVENT_RECURSION. . . . . . . . Database journal (trigger) system parameters . . REPORT_POSITION_INTERVAL . . . . . Maximize throughput system parameters . . . COMMIT_GROUP_SIZE. . . . . . . . COMMIT_INTERVAL . . . . . . . . SYNCHRONIZATION_COMMIT_ GROUP_SIZE . . . . . . . . . . . SYNCHRONIZATION_INTERVAL . . . . Tracing system parameters . . . . . . . . D_MIRROR_ALARM_TRACE . . . . . . D_MIRROR_TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 538 538 538 538 539 539 540 540 540 541 541 541 541 542 542 542 543 543 544 544 544 545 546 546 546 547 548 548 548 548 549 549 550 551 552 552 552 553
D_MIRROR_TRACE_FILE_SIZE . D_MIRROR_TRACE_ON_ERROR Notification system parameters . . implicit_transformation_warning . DEADBAND_PERCENTAGE . . DM_STATUS_INTERVAL . . . HEARTBEAT_TIMEOUT . . . LOG_EMAIL_USERNAME . . . MONITOR_SAMPLE_INTERVAL. STATISTICS_INTERVAL . . . . Disk resource system parameters . . LOG_MAX_SIZE . . . . . . Refresh loader system parameters . D_HOME_BCP . . . . . . . D_MIRROR_BCP . . . . . . D_MIRROR_BCP_ROWS . . . D_MIRROR_FASTBCP . . . . DM_BCP_PACKET_SIZE . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
553 554 554 555 555 557 557 558 558 559 559 559 560 560 560 561 561 561
System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) . . . . . . . . . . . 563
General product system parameters . . . . . . 563 mirror_auto_restart_interval_minutes . . . . 563 Notification system parameters . . . . . . . 564 events_max_retain . . . . . . . . . . . 564 global_conversion_not_possible_warning . . . 564 global_shutdown_after_no_heartbeat_response_minutes 565 implicit_transformation_warning . . . . . . 565 Maximize throughput system parameters . . . . 566 global_max_batch_size . . . . . . . . . 566 mirror_interim_commit_threshold . . . . . 566 refresh_commit_after_max_operations . . . . 567 Encoding system parameters . . . . . . . . 567 global_unicode_as_char . . . . . . . . . 567 Disk resource system parameters . . . . . . . 568 mirror_global_disk_quota_mb . . . . . . . 568 mirror_global_disk_quota_gb . . . . . . . 569 staging_store_can_run_independently . . . . 570 staging_store_disk_quota_gb . . . . . . . 570 Apply process system parameters . . . . . . 570 global_default_after_database_minimum_timestamp 571 global_default_before_database_minimum_timestamp 571 convert_not_nullable_column . . . . . . . 572 mirror_end_on_error . . . . . . . . . . 572 mirror_expected_errors_list . . . . . . . . 572 refresh_end_on_error . . . . . . . . . . 573 refresh_expected_errors_list . . . . . . . 573 refresh_loader_drop_index . . . . . . . . 574 refresh_with_referential_integrity . . . . . . 574 trim_char_to_varchar . . . . . . . . . . 574 trim_varchar_to_varchar. . . . . . . . . 575 userexit_max_lob_size_kb . . . . . . . . 575 Supplemental logging system parameters . . . . 576 auto_configure_supplemental_logging . . . . 576 mirror_logging_by_empty_triggers . . . . . 576
System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) . . . . . . . . . . . . . . 577
xii
General product system parameters . . . . . . Authorization Code . . . . . . . . . . Enable *MAXOPT3 Option . . . . . . . . Record Format Check . . . . . . . . . Startup Timeout . . . . . . . . . . . TCP_KEEPALIVE_SECS . . . . . . . . . Replication system parameters . . . . . . . Allow Refresh While Active . . . . . . . End on Error During Mirroring . . . . . . End on Error During Refresh . . . . . . . Refresh After Restore . . . . . . . . . . Cascading replication system parameters . . . . Enable Cascading Replicates . . . . . . . Database journal (trigger) system parameters . . . Default Journal Library . . . . . . . . . Default Journal Name . . . . . . . . . Replicate User Defined Journal Entries . . . . Report Position Interval . . . . . . . . . Synchronization Interval. . . . . . . . . Remote journal system parameters . . . . . . Data Origin TCP/IP Name . . . . . . . . Data Origin Port . . . . . . . . . . . Relational Database Directory Entry . . . . . Commitment control system parameters . . . . Commitment Control . . . . . . . . . . Multibyte character set system parameters. . . . Unicode Handling . . . . . . . . . . . Latency system parameters . . . . . . . . . Deadband Percentage . . . . . . . . . Monitor Sample Interval. . . . . . . . . Notification system parameters . . . . . . . Heartbeat Timeout. . . . . . . . . . . Messages on Column Not Null Capable . . . Messages on Invalid Numerics . . . . . . Progress Status Interval . . . . . . . . . Data type system parameters . . . . . . . . Numeric Column Validation . . . . . . . Date and time column function system parameters Default Date On Error . . . . . . . . . Row and column filtering system parameters. . . Audit Filtered Transactions . . . . . . . . Critical Column Filtering . . . . . . . . Event log system parameters . . . . . . . . Notify Message Queue . . . . . . . . . Notify Message Queue Library . . . . . . Notify Message Threshold . . . . . . . . Lock detection system parameters . . . . . . Lock Timeout Value . . . . . . . . . .
577 578 578 578 579 579 580 580 580 581 581 582 582 582 582 583 583 584 584 585 585 585 586 586 586 587 587 588 588 590 590 590 591 591 592 593 593 593 593 594 594 595 595 595 596 596 597 597
System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) . . . . . . . . . . . . . . 599
General product system audit_auth_ code . auth_ code . . . db_password . . db_user . . . . debug . . . . . engine_ port. . . parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 600 600 600 601 601 601
log_file_quota . . . . . . . . . . . log_total_quota . . . . . . . . . . . md_db_url . . . . . . . . . . . . md_schema . . . . . . . . . . . . scrape_timeout . . . . . . . . . . . startup_timeout . . . . . . . . . . target_debug . . . . . . . . . . . target_initial_codepage . . . . . . . . ts_password . . . . . . . . . . . . ts_product . . . . . . . . . . . . Access Server system parameters . . . . . . accessserver_udp_ listenport . . . . . . agent_assert . . . . . . . . . . . . agent_debug. . . . . . . . . . . . agent_jdbcdb2_driver. . . . . . . . . agent_jdbcdb2_driver_net . . . . . . . agent_jdbcpb_driver . . . . . . . . . agent_jdbcpb_driver_net. . . . . . . . agent_max_connections_num . . . . . . agent_message_version . . . . . . . . agent_msg_resources_file . . . . . . . agent_src_engine_address . . . . . . . agent_src_engine_port . . . . . . . . agent_src_engine_socket_tmout . . . . . agent_trace_in_message . . . . . . . . agent_trace_out_message . . . . . . . agent_udp_ listenport . . . . . . . . Cascading replication system parameters . . . cascade_replication . . . . . . . . . Commitment control system parameters . . . commit_group_size . . . . . . . . . commit_ interval . . . . . . . . . . refresh_commit_ block_size. . . . . . . scraper_trans_ num_limit . . . . . . . source_default_ commit_level . . . . . . target_default_commit_level . . . . . . Database translation log system parameters . . report_position_interval . . . . . . . . Fastload system parameters . . . . . . . refresh_del_fastload_file . . . . . . . . dofastload . . . . . . . . . . . . fastload_backup_path . . . . . . . . fastload_in_whole . . . . . . . . . . fastload_path . . . . . . . . . . . make_fastload_log_file . . . . . . . . max_fastload_ file_size . . . . . . . . Latency system parameters . . . . . . . . monitor_sample_interval . . . . . . . Lock detection system parameters . . . . . dm_lock_detection. . . . . . . . . . dm_lock_timeout . . . . . . . . . . Multibyte character set system parameters. . . unicode_handling . . . . . . . . . . Notification system parameters . . . . . . dm_status_interval . . . . . . . . . heartbeat_timeout . . . . . . . . . . Replication system parameters . . . . . . dobatch . . . . . . . . . . . . . source_default_active_refresh . . . . . . target_mirror_number_of_errors_before_abort target_print_refresh_details . . . . . . .
Contents
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
601 601 602 602 602 602 602 603 603 603 603 603 604 604 604 604 604 604 605 605 605 605 605 605 605 606 606 606 606 607 607 608 609 609 609 610 610 611 611 611 612 613 613 613 614 614 615 615 615 616 616 617 617 618 618 619 619 619 620 620 . 620
xiii
target_refresh_number_of_errors_before_abort Tracing system parameters . . . . . . . . message_handler_trace_level . . . . . . message_trace_level . . . . . . . . . target_trace_logical_messages . . . . . . target_trace_physical_messages . . . . . trace_level . . . . . . . . . . . . trace_on . . . . . . . . . . . . . Teradata TPump system parameters . . . . . tpump_arc_data_files . . . . . . . . . tpump_files_root_folder . . . . . . . . tpump_logging . . . . . . . . . . . tpump_max_file_size . . . . . . . . . tpump_script_params_file . . . . . . . tpump_script_val_file. . . . . . . . . tpump_ timeout . . . . . . . . . .
. . . . . . . . . . . . . . .
621 621 621 621 621 622 622 622 622 622 623 624 624 625 625 626
System parameters for InfoSphere CDC for DB2 for LUW (version 6.1 and later) . . . . . . . . . . . . . . . 627
General product system parameters . . . . . . 627 mirror_auto_restart_interval_minutes . . . . 627 Notification system parameters . . . . . . . 628 events_max_retain . . . . . . . . . . . 628 global_conversion_not_possible_warning . . . 628 global_shutdown_after_no_heartbeat_response_minutes 629 implicit_transformation_warning . . . . . . 629 Maximize throughput system parameters . . . . 630 mirror_interim_commit_threshold . . . . . 630 refresh_commit_after_max_operations . . . . 630 Encoding system parameters . . . . . . . . 631 global_unicode_as_char . . . . . . . . . 631 Disk resource system parameters . . . . . . . 632 mirror_global_disk_quota_mb . . . . . . . 632 mirror_global_disk_quota_gb . . . . . . . 632 staging_store_can_run_independently . . . . 633 staging_store_disk_quota_gb . . . . . . . 633 staging_store_disk_quota_mb . . . . . . . 634 Apply process system parameters . . . . . . 634 convert_not_nullable_column . . . . . . . 634 global_max_batch_size . . . . . . . . . 635 mirror_end_on_error . . . . . . . . . . 635 mirror_expected_errors_list . . . . . . . . 636 refresh_end_on_error . . . . . . . . . . 636 refresh_expected_errors_list . . . . . . . 637 refresh_loader_drop_index . . . . . . . . 637 refresh_with_referential_integrity . . . . . . 637 userexit_max_lob_size_kb . . . . . . . . 638
Encoding system parameters . . . . . mbcs_support_is_on . . . . . . . tpump_utf16_support_workaround_is_on Disk resource system parameters . . . . mirror_global_disk_quota_mb . . . . mirror_global_disk_quota_gb . . . . Apply process system parameters . . . convert_not_nullable_column . . . . mirror_end_on_error . . . . . . . mirror_expected_errors_list . . . . . mirror_td_apply_method . . . . . refresh_end_on_error . . . . . . . refresh_expected_errors_list . . . . trim_char_to_varchar . . . . . . . trim_varchar_to_varchar. . . . . . userexit_max_lob_size_kb . . . . . Teradata TPump system parameters . . . mirror_tpump_files_root_folder_path . mirror_tpump_max_file_size_mb . . . mirror_tpump_script_val_file_name . . mirror_tpump_timeout_seconds . . . mirror_tpump_update_on_key_column . Fastload system parameters . . . . . refresh_allow_fast_loader . . . . . refresh_max_fastload_file_size_mb . . use_jdbc_for_refresh . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
642 642 643 643 643 644 644 644 645 645 646 646 647 647 648 648 648 648 649 650 650 651 651 651 652 652
System parameters for InfoSphere CDC Event Server . . . . . . . . . 653

Notification system parameters . . . . events_max_retain . . . . . . . . global_conversion_not_possible_warning implicit_transformation_warning . . . Apply process system parameters . . . convert_not_nullable_column . . . . mirror_commit_on_transaction_boundary mirror_end_on_error . . . . . . . mirror_expected_errors_list . . . . . mirror_interim_commit_threshold . . refresh_end_on_error . . . . . . . refresh_expected_errors_list . . . . userexit_max_lob_size_kb . . . . . Disk resource system parameters . . . . mirror_global_disk_quota_mb . . . . mirror_global_disk_quota_gb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653 653 653 654 654 655 655 656 656 656 657 657 657 658 658 658
System parameters for InfoSphere CDC for InfoSphere DataStage . . . . 661

Notification system parameters . . . . . . . 661 ds_output_timestamp_utc . . . . . . . . 661 events_max_retain . . . . . . . . . . . 662 global_conversion_not_possible_warning . . . 662 global_shutdown_after_no_heartbeat_response_minutes 662 implicit_transformation_warning . . . . . . 663 Disk resource system parameters . . . . . . . 663 mirror_global_disk_quota_mb . . . . . . . 663 mirror_global_disk_quota_gb . . . . . . . 664 Apply process system parameters . . . . . . 665 convert_not_nullable_column . . . . . . . 665 mirror_end_on_error . . . . . . . . . . 665
System parameters for InfoSphere CDC for Teradata (version 6.2 and later) . . . . . . . . . . . . . . . 639
Notification system parameters . . . . . . . 639 events_max_retain . . . . . . . . . . . 639 global_conversion_not_possible_warning . . . 640 global_shutdown_after_no_heartbeat_response_minutes 640 implicit_transformation_warning . . . . . . 640 Maximize throughput system parameters . . . . 641 global_max_batch_size . . . . . . . . . 641 mirror_interim_commit_threshold . . . . . 642
xiv
mirror_expected_errors_list . . . . mirror_interim_commit_threshold . refresh_end_on_error . . . . . . refresh_expected_errors_list . . . refresh_with_referential_integrity . . trim_char_to_varchar . . . . . . trim_varchar_to_varchar. . . . . InfoSphere DataStage system parameters userexit_max_lob_size_kb . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
666 666 666 667 667 667 668 668 668
Apply process system parameters convert_not_nullable_column . userexit_max_lob_size_kb . .
. . .
. . .
. . .
. . .
. . .
. 684 . 684 . 685
Commands for Access Server . . . . 687

Datastore commands . . . . . . . . . . . dmchangeconnectionpasswordChanging the connection parameters to a datastore . . . . dmcreatedatastoreAdding a datastore . . . dmdeleteconnectionDeleting a datastore connection . . . . . . . . . . . . . dmdeletedatastoreDeleting a datastore . . . dmlistuserdatastoresGenerating a report list of datastores assigned to a user . . . . . . . User account commands. . . . . . . . . . dmchangeuserpasswordChanging the password on a user account . . . . . . . dmcreateuserAdding a user account . . . . dmdeleteuserDeleting a user . . . . . . dmdisableuserDisabling a user account . . . dmenableuserEnabling a user . . . . . . dmlistusersListing user accounts . . . . . dmresetuserResetting a user account . . . . dmunlockuserUnlocking a user account . . . Other commands . . . . . . . . . . . . dmaccessserverStart Access Server . . . . dmaddconnectionAdding a datastore connection to a user . . . . . . . . . . dmlistdatastoreusersGenerating a report list of users assigned to a datastore . . . . . . . dmshowversionShow InfoSphere CDC Access Server version . . . . . . . . . . . . onlineOpen command environment . . . . 687 687 688 689 690 690 691 691 692 694 694 695 695 697 698 698 698 699 700 700 701
System parameters for InfoSphere CDC for Informix . . . . . . . . . . 669

General product system parameters . . . . . . 669 mirror_auto_restart_interval_minutes . . . . 669 Notification system parameters . . . . . . . 670 events_max_retain . . . . . . . . . . . 670 global_conversion_not_possible_warning . . . 670 global_shutdown_after_no_heartbeat_response_minutes 670 implicit_transformation_warning . . . . . . 671 Maximize throughput system parameters . . . . 671 mirror_interim_commit_threshold . . . . . 672 refresh_commit_after_max_operations . . . . 672 Encoding system parameters . . . . . . . . 672 global_unicode_as_char . . . . . . . . . 673 Disk resource system parameters . . . . . . . 673 mirror_global_disk_quota_mb . . . . . . . 673 mirror_global_disk_quota_gb . . . . . . . 674 staging_store_can_run_independently . . . . 675 staging_store_disk_quota_gb . . . . . . . 675 Apply process system parameters . . . . . . 675 convert_not_nullable_column . . . . . . . 676 global_max_batch_size . . . . . . . . . 676 mirror_end_on_error . . . . . . . . . . 677 mirror_expected_errors_list . . . . . . . . 677 refresh_end_on_error . . . . . . . . . . 677 refresh_expected_errors_list . . . . . . . 678 refresh_with_referential_integrity . . . . . . 678 trim_char_to_varchar . . . . . . . . . . 678 trim_varchar_to_varchar. . . . . . . . . 678 userexit_max_lob_size_kb . . . . . . . . 679
Using Support Assistant and contacting IBM Support . . . . . . . 703

Preparing to collect diagnostic data and tracing information . . . . . . . . . . . . . To enable tracing for Management Console and Access Server . . . . . . . . . . . To enable tracing for datastores for InfoSphere CDC version 6.3 and above (optional) . . . To start the collection of diagnostic data and tracing information with Support Assistant . Contacting IBM Support. . . . . . . . . . 703 . 704 . 704 . 705 . 706
System parameters for InfoSphere CDC for Netezza databases . . . . . 681

Notification system parameters . . . . . . . 681 events_max_retain . . . . . . . . . . . 681 global_conversion_not_possible_warning . . . 682 global_shutdown_after_no_heartbeat_response_minutes 682 implicit_transformation_warning . . . . . . 682 Maximize throughput system parameters . . . . 683 acceptable_latency_in_minutes . . . . . . 683 Disk resource system parameters . . . . . . . 683 mirror_global_disk_quota_gb . . . . . . . 684
Glossary . . . . . . . . . . . . . 707 Notices . . . . . . . . . . . . . . 711

Trademarks . . . . . . . . . . . . . . 713
Contents
xv
xvi
Overview of 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 CDC Management Console GUI application. InfoSphere CDC provides low impact capture and fast delivery of data changes for key information management initiatives including dynamic data warehousing, master data management, application consolidations or migrations, operational BI, and enabling SOA projects. InfoSphere CDC also helps reduce processing overheads and network traffic by only sending the data that has changed. Replication can be carried out continuously or periodically. When data is transferred from a source server, it can be remapped or transformed in the target environment. The following diagram illustrates the key components of InfoSphere CDC.
The key components of the InfoSphere CDC architecture are described below: v Access ServerControls all of the non-command line access to the replication environment. When you log in to Management Console, you are connecting to Access Server. Access Server can be closed on the client workstation without affecting active data replication activities between source and target servers. v Admin APIOperates as an optional Java-based programming interface that you can use to script operational configurations or interactions. v Apply agentActs as the agent on the target that processes changes as sent by the source. v Command line interfaceAllows you to administer datastores and user accounts, as well as to perform administration scripting, independent of Management Console. v Communication Layer (TCP/IP)Acts as the dedicated network connection between the Source and the Target.
v Source and Target DatastoreRepresents the data files and InfoSphere CDC instances required for data replication. Each datastore represents a database to which you want to connect and acts as a container for your tables. Tables made available for replication are contained in a datastore. v Management ConsoleAllows you to configure, monitor and manage replication on various servers, specify replication parameters, and initiate refresh and mirroring operations from a client workstation. Management Console also allows you to monitor replication operations, latency, event messages, and other statistics supported by the source or target datastore. The monitor in Management Console is intended for time-critical working environments that require continuous analysis of data movement. After you have set up replication, Management Console can be closed on the client workstation without affecting active data replication activities between source and target servers. v MetadataRepresents the information about the relevant tables, mappings, subscriptions, notifications, events, and other particulars of a data replication instance that you set up. v MirrorPerforms the replication of changes to the target table or accumulation of source table changes used to replicate changes to the target table at a later time. If you have implemented bidirectional replication in your environment, mirroring can occur to and from both the source and target tables. v RefreshPerforms the initial synchronization of the tables from the source database to the target. This is read by the Refresh reader. v Replication EngineServes to send and receive data. The process that sends replicated data is the Source Capture Engine and the process that receives replicated data is the Target Engine. An InfoSphere CDC instance can operate as a source capture engine and a target engine simultaneously. v Single ScrapeActs as a source-only log reader and a log parser component. It checks and analyzes the source database logs for all of the subscriptions on the selected datastore. v Source transformation engineProcesses row filtering, critical columns, column filtering, encoding conversions, and other data to propagate to the target datastore engine. v Source database logsMaintained by the source database for its own recovery purposes. The InfoSphere CDC log reader inspects these in the mirroring process, but filters out the tables that are not in scope for replication. v Target transformation engineProcesses data and value translations, encoding conversions, user exits, conflict detections, and other data on the target datastore engine. There are two types of target-only destinations for replication that are not databases: v JMS MessagesActs as a JMS message destination (queue or topic) for row-level operations that are created as XML documents. v InfoSphere DataStageProcesses changes delivered from InfoSphere CDC that can be used by InfoSphere DataStage jobs. For more information on how to install Management Console and Access Server, see Access Server and Management Console - Installation Guide. For information on how to install your source and target replication engines, see the end-user documentation for your replication engine platform. See also: Understanding the InfoSphere CDC workflow on page 3
Understanding the InfoSphere CDC workflow

This list and the following sections detail the workflow for setting up and configuring replication in InfoSphere CDC: v Installing Access Server v Installing Management Console v Adding and configuring datastores v Adding and configuring subscriptions v Mapping and customizing tables If you are using InfoSphere CDC Event Server, creating and customizing XML messages for table mappings. If you are using InfoSphere DataStage, generating .dsx definition files and custom Java classes for InfoSphere DataStage jobs. v Starting and ending replication
Overview of InfoSphere CDC
Whats new
The following table lists the major feature changes to Management Console version 6.5.2:
Item Description For more information, see:
Support for Management Console enables you Netezza databases to connect to a configured target Netezza datastore and replicate data from a supported InfoSphere CDC source datastore.
A large number of features and enhancements have been added to Management Console version 6.5.1. The following table lists the major feature changes:
Item Description For more information, see: Starting and ending replication on page 355 Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187 Mapping using InfoSphere DataStage on page 117
Ending replication Four choices for stopping replication Replicating multibyte character set (MBCS) data Table mappings for InfoSphere CDC for InfoSphere DataStage Row subsets on refresh v Auto-encoding mode v Translation and Encoding tabs in the Table Mappings view Two options: Flat File or Direct Connect
Filter a refresh through the use of an SQL WHERE clause to only include rows within a specified range.
Flagging a source table for refresh on page 343
Monitoring
Subscriptions view (Monitoring Changes to the Monitoring perspective, including a new view: perspective) on page 387 Performance. Performance view (Monitoring perspective) on page 398 Upgrade Transformation Server for Microsoft SQL Server or Transformation Server for Oracle to InfoSphere CDC version 6.5 Upgrading existing Transformation Server subscriptions to InfoSphere CDC on page 64 Reverting to Transformation Server on page 67
Upgrading InfoSphere CDC
DDL Replication
Replicate the structural changes to Replicating Data Definition tables Language (DDL) changes on page 137
Before you start Management Console

Before you can start and log in to Management Console, make sure that you have Access Server installed and running. For more information, see the Management Console and Access Server - Installation Guide. Important: As of version 6.3.1 fix pack 1, both Management Console and Access Server must be at the same level. Management Console can only connect to a similar version of Access Server. InfoSphere CDC version 6.5 introduces a number of enhancements and changes. While InfoSphere CDC version 6.5 is backward-compatible, you must upgrade your existing InfoSphere CDC agent datastores for their appropriate database platforms to version 6.5 to access the full range of functionality introduced with version 6.5. In this section, you will learn: Configuring firewall settings for outbound (static) ports Logging in to Management Console by connecting to Access Server on page 10 Related concepts Setting up user accounts on page 25 Commands for Access Server on page 687
Configuring firewall settings for outbound (static) ports

If your network uses a firewall or other security mechanism that requires static ports for communication, then you must specify the ports that other computers can use to communicate with Access Server services. Note: In addition to a network firewall, you might have personal firewall software installed and enabled on client machines. This firewall may cause a problem when connecting to Management Console from Access Server. To calculate the number of Access Server ports to open, use this formula: number of ports to open = 2 * (number of users + (number of users * number of datastores) + number of datastores) where a datastore refers to an InfoSphere CDC installation.
The following figure highlights the ports you can configure for Management Console and Access Server components. You can configure static port numbers for all or some of these ports, depending on your network requirements.
The labels in the figure above correspond to the following groups of ports: v 1Communication from Management Console to the Access Server service. You specify this port when you install Access Server and when you log in to Management Console. The default port is 10101 and you can set this value in Management Console. v 2Communication from Access Server back to Management Console for monitor updates. v 3Communication from Management Console to the Access Server service, per datastore (that is, per InfoSphere CDC installation). This requires two ports for each InfoSphere CDC installation. v 4Communication from the Access Server service to the datastore, listen process. This is established for each Management Console connection. v 5Communication from the Access Server service to the datastore, monitor process. This is a shared connection between all Management Console connections on the same datastore. This requires two ports for each datastore. You must also configure your routers and firewalls to allow communication through the configured ports. For more information, contact your network administrator. Management Console requires: v One input and output port to the Access Server. v One input port from the Access Server v One input and output port per datastore (regardless of whether you connect to the datastore) The Access Server requires: v One input and output port per datastore, per installation of Management Console v Two input and output ports, per datastore Additionally, you can have more than one datastore, or more than one installation of Management Console; for example:
v v v v
One installation of Management Console and one datastore One installation of Management Console and two datastores Two installations of Management Console and one datastore Two installations of Management Console and two datastores
Example: calculating ports required

To help determine the number of ports required, take a scenario where there are ten concurrent users and three datastores. To calculate the number of Access Server ports to open, use this formula: number of ports to open = 2 * (number of users + (number of users * number of datastores) + number of datastores) where a datastore refers to an InfoSphere CDC installation. Using the above scenario of ten concurrent users and three datastores, the number of Access Server ports required is 86. Here is the breakdown of the calculation, following the order in the figure above illustrating the ports you can configure for Management Console and Access Server components: v Number of concurrent users that will log into Access Server = 10 v One port per user to connect to and deliver unsolicited message = 10 v Number of possible concurrent connections from Management Console to connect to datastores); that is, 10 users * 3 datastores = 10 * 3 v Number of possible concurrent connections to datastore, listen process; that is, 10 users * 3 datastores) v Two ports required to connect to each datastore, monitor process = 2 * 3 Therefore, 10 + 10 + (10 *3) + (10 *3) + (2 *3) = 86 To calculate the number of ports to open Management Console, use this formula: number of ports to open = 2 + number of datastores Using the above scenario of ten concurrent users and three datastores, the number of ports required is 5 for each Management Console. This is the breakdown of the calculation for each Management Console: v Connection to Access Server = 1 v Connection for unsolicited updates from Access Server = 1 v One port for each connection to a datastore, listen process = 1 * 3 Therefore, 1 + 1 + (1 *3) = 5 See also: To configure static ports
To configure static ports

1. Open the dmaccessserver.vmargs file in a text editor. This file is located in the conf directory in your Access Server installation directory. 2. Replace the entry in this file with the following text: -jar lib/server.jar local_port:<first_port> local_port_count:<number_available_ports> <Access_Server_listener_port> where:
v <first_port> is the first port in the range that you want the Access Server service to use when sending messages or establishing connections. v <number_available_ports> is the number of ports you want to reserve for this use. To calculate the number of Access Server ports to open, use this formula: number of ports to open = 2 * (number of users + (number of users * number of datastores) + number of datastores) where a datastore refers to an InfoSphere CDC installation. v <Access_Server_listener_port> is the port number that Access Server listens on and is set during the Access Server installation. You do not have to specify a value here if you are using the default port number of 10101. For example, if the number of available ports for communication is 500 and you want Access Server to listen for connections on port 10101, then the entry would be as follows:
-jar lib/server.jar local_port:10102 local_port_count:500 10101
This enables Access Server to listen for connections on port 10101 and restricts it to using ports in the range of 10102 to 10601. These changes will take effect after you restart the Access Server service.
Logging in to Management Console by connecting to Access Server

After you start Management Console, you will be prompted to log in to Access Server. Access Server is the server application that controls access to your replication environment. System Administrators with user and datastore account management rights can create additional user accounts in the Access Manager perspective. You can have multiple instances of Access Server in your working environment, but you can only connect to one server at a time. See also: To log in to Management Consoleby connecting to Access Server To change your log in password on page 11
To log in to Management Consoleby connecting to Access Server

1. Ensure that your InfoSphere CDC system administrator has added you as a user to an existing datastore in Management Console. Your system administrator can set your user name and password in the Access Manager perspective. Navigate to the programs menu and start Management Console. Enter your user name in the User Name box. Enter your password in the Password box. The password is case-sensitive. ,Enter or select the host name (system name) or full IP address of the workstation running Access Server in the Server Name list. 6. Enter the TCP/IP port number in the Port Number box. The port number that appears by default is specified in the Edit > Preferences menu. 2. 3. 4. 5.
10
Related tasks To add a user on page 26
To change your log in password

1. Click File > Access Server > Change Password. 2. Enter the current password in the Current Password box. 3. Enter and confirm the new password in the New Password and Confirm Password boxes. Your password must conform to the password policy defined by the Access Server system administrator.
11
12
Understanding the Management Console interface

Management Console is composed of a number of windows or tabs that are referred to as perspectives and views. After logging in to Management Console you will see three perspectives: the Configuration perspective, the Monitoring perspective, and the Access Manager perspective, from which you can access a number of different views depending on your role and access level: v Configuration perspectiveContains the Subscriptions view, the Datastores view, and the Table Mappings view. These views enable you to configure your replication environment by connecting to your datastores, creating subscriptions, mapping your tables, and configuring how to transform your data. Within the status bar for the perspective, you can view a summary of your configuration: The user name used to log onto Management Console. The number of datastores connected and warning information for any datastores that could not be connected. The number of subscriptions loaded. The number of tables loaded for the selected subscription. v Monitoring perspectiveContains the Subscriptions view and the Performance view. These views that allow you to initiate replication and monitor your replication activity. At the bottom of this perspective, you can view a summary of your monitoring environment: The user name used to log onto Management Console. The number of datastores connected and warning information for any datastores that could not be connected. The number of subscriptions loaded. v Access Manager perspectiveContains the Datastore Management view, the User Management view, and the Connection Management view. These views enable you to create and manage datastores, user accounts, and access connections. At the bottom of this perspective, you can view a summary of your Access Manager environment: The user name used to log onto Management Console. The number of datastores connected and warning information for any datastores that could not be connected. Preferences allow you to control the behavior of Management Console. For example, you can choose whether you want to connect to datastores automatically after logging in to Management Console. The information, features and options displayed in the Management Console interface is determined by several factors: v your role as a user v the datastores to which you have access v the type of the datastore v the version of the datastore Only the relevant information will be displayed in the interface and only the eligible features and options will be available for use.
13
Related concepts Managing user accounts on page 25 Setting up datastores on page 35 Setting up and configuring subscriptions on page 49 Monitoring subscriptions on page 387
14
Setting preferences
Preferences allow you to control certain aspects of the behavior of Management Console. In this section, you will learn: Setting advanced preferences Setting connection preferences on page 18 Setting datastore multiuser preferences on page 19 Setting prompt preferences on page 20 Setting monitoring preferences on page 21
Setting advanced preferences

When mapping tables, you can show all databases, schemas, libraries, or tables that are available for mapping, or you can specify filter criteria to display only those databases, schemas, libraries, or tables that you require. You can set the following advanced preferences: v Access Server TimeoutsSet the timeout value to indicate how long Management Console waits for a response from the datastore. v MemoryAllocate memory for Management Console. You can increase the amount of memory available for Management Console. v EncodingAdd character sets and encodings to Management Console. For InfoSphere CDC version 6.3 and earlier, you can add character sets and encodings to Management Console that are different from the standard character sets and encodings that are provided by default. These become available for encoding conversion on the Encoding tab in the Mapping Details view. You can also import and export character sets and encodings if you need to share these settings. v Always show incomplete table mappingsEnable this option to indicate whether Management Console displays source tables for a subscription, in the Table Mappings view, that have not been mapped to target tables. By default, these incomplete mappings are not displayed. To always show incomplete mappings, enable this option or right-click on the Table Mappings view and select Show Incomplete Mappings. Your preference is saved even after you restart Management Console. If you have incomplete table mappings, Management Console will warn you before it starts mirroring. Using filtering optimizes system performance and enables you to navigate more efficiently if you have a large number of nodes (databases, schemas, libraries, or tables). Depending on your InfoSphere CDC replication platform, and the Minimum Number value specified for filtering in Edit > Preferences > Prompts > Filtering, the Filter Databases, Filter Schemas, Filter Libraries, or Filter Tables dialog box opens when you expand a datastore, database, schema, or library respectively. The Filter Databases window can appear with the two replication platforms that can contain multiple databases, Transformation Server version 5.3 for SQL Server and z/OS. For other replication platforms that contain single database instances, the Filter Schemas and Filter Tables dialog boxes can open when you expand the respective nodes under a datastore.
15
See also: To set timeout values To allocate memory for Management Console To add a character encoding To modify a character encoding on page 17 To To To To delete a character encoding on page 17 import the CSV template on page 17 export the CSV template on page 18 show incomplete table mappings before mirroring on page 18
To set timeout values

1. Click Edit > Preferences. 2. Click Advanced. 3. Enter a value in the Describe Timeout (minutes) box in the Access Server Timeouts area. 4. Click Apply.
To allocate memory for Management Console

1. Click Edit > Preferences. 2. Click Advanced. 3. Enter the maximum amount of memory you want to allocate for Management Console in the Maximum Memory (in megabytes) box. 4. Click Apply.
To add a character encoding

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier. 1. Click Edit > Preferences. 2. Select Advanced and click Encoding. 3. Click Add. 4. Enter the supported encoding name in the ISO/IANA Name box. This is dependent on database platform. Refer to the Java Supported Encodings Document for a list of supported ISO/IANA encoding names. 5. Enter the supported encoding name in the IBM CCSID box. A Coded Character Set Identifier (CCSID) is a unique 16-bit number identifying a set of encoding scheme identifiers, character set identifiers, code page identifiers, and additional coding-related required information. 6. Choose one of the following from the Character Length box. v Single-byte v Double-byte v Multi-byte
16
Related concepts Setting advanced preferences on page 15 Related tasks To modify a character encoding To delete a character encoding
To modify a character encoding

1. 2. 3. 4. Ensure that the subscription is InfoSphere CDC version 6.3 or earlier. Click Edit > Preferences. Select Advanced and click Encoding. Click Modify.
5. Select the desired character set from the list in the Column Encodings dialog box. 6. Enter the supported encoding name in the ISO/IANA Name box. This is dependent on database platform. Refer to the Java Supported Encodings Document for a list of supported ISO/IANA encoding names. 7. Enter the supported encoding name in the IBM CCSID box. A Coded Character Set Identifier (CCSID) is a unique 16-bit number identifying a set of encoding scheme identifiers, character set identifiers, code page identifiers, and additional coding-related required information. 8. Choose one of the following from the Character Length box. v Single-byte v Double-byte v Multi-byte Related concepts Setting advanced preferences on page 15 Related tasks To delete a character encoding To add a character encoding on page 16
To delete a character encoding

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier. 1. Click Edit > Preferences. 2. Select Advanced and click Encoding. 3. Select the character set. 4. Click Delete. Related concepts Setting advanced preferences on page 15 Related tasks To add a character encoding on page 16 To modify a character encoding
To import the CSV template

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier. 1. Click Edit > Preferences.
Setting preferences
17
2. Select Advanced and click Encoding. 3. Click Import. 4. Enter a name for the template in the File Name box. Related concepts Setting advanced preferences on page 15 Related tasks To export the CSV template
To export the CSV template

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier. 1. Click Edit > Preferences. 2. Select Advanced and click Encoding. 3. Click Export. 4. Enter a name for the template in the File Name box. Related concepts Setting advanced preferences on page 15 Related tasks To import the CSV template on page 17
To show incomplete table mappings before mirroring

1. Click Edit > Preferences. 2. Click Advanced. 3. Enable Always show incomplete table mappings. 4. Click Apply.
Setting connection preferences

You can set the Access Server default port, specify the number of ports for Access Server, and choose whether you want to connect to datastores automatically after logging in to Management Console. Access Server Default PortThe Access Server default port is a unique TCP/IP number that is used to connect to Access Server. You specify this port number when you install Access Server and when you log in to Management Console. Enable Firewall SettingsThe starting port number, and number of ports you require to go through a firewall to Access Server. The following ports are required: two for connection to Management Console; and two for each datastore associated with your Management Console user. Connect to Datastores AutomaticallyWhen enabled, automatically connects to datastores after logging into Management Console. When disabled, you are required to manually connect to each datastore after logging in. See also: To specify a default Access Server port number on page 19 To specify firewall settings for outbound (static) ports on page 19 To connect to databases automatically on page 19
18
To specify a default Access Server port number

1. Click Edit > Preferences. 2. Click Connection. 3. Enter the unique TCP/IP port number in the Default Port text box in the Access Server area. 4. Click Apply. Related concepts Setting connection preferences on page 18
To specify firewall settings for outbound (static) ports

1. 2. 3. 4. Click Edit > Preferences. Click Connection. Enable the Enable Firewall Settings check box in the Firewall area. Enter the starting port in the Starting Port box.
5. Enter the number of ports in the Number of Ports box. By default, the value is 2. You need two ports to connect to Management Console, and two for each datastore associated with your Management Console user. You cannot specify less than two ports. 6. Click Apply. Related concepts Setting connection preferences on page 18
To connect to databases automatically

1. Click Edit > Preferences. 2. Click Connection. 3. Enable the Connect to Datastores Automatically check box in the Datastores area. 4. Click Apply. Related concepts Setting connection preferences on page 18
Setting datastore multiuser preferences

If you have, or you plan to add, a datastore that is accessed by more than one user, you can enable automatic multiuser configuration when adding datastores, and you can prompt users to log comments when unlocking subscriptions. Note that multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere CDC for IBM i. See also: To automatically enable multiuser configuration when adding new datastores on page 20 To prompt users to log comments when unlocking subscriptions on page 20
Setting preferences
19
To automatically enable multiuser configuration when adding new datastores

1. Verify your version of InfoSphere CDC. Multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere CDC for IBM i. 2. Click Edit > Preferences. 3. Click Multiuser. 4. Enable the Automatically enable multiuser configuration when adding datastores check box. 5. Click Apply.
To prompt users to log comments when unlocking subscriptions

1. Click Edit > Preferences. 2. Click Multiuser. 3. Enable the Ask user to log comments when unlocking a subscription check box. 4. Click Apply.
Setting prompt preferences

You can control when Management Console prompts you for confirmation before or while performing certain tasks. In the Confirmation area, you can enable: v Marking a Table Capture PointEnables Management Console to prompt you with a confirmation message before setting a capture point for a table. The message warns you that setting a capture point will update the bookmark for the table. v Shutting Down DatastoreEnables Management Console to prompt you with a confirmation message before shutting down an InfoSphere CDC datastore. v Changing Connection Parameters PasswordEnables Management Console to prompt you with a reminder that when you change a connection parameter password you must update related subscriptions. v Column Encodings Are Not CompatibleEnables Management Console to prompt you with a reminder when column encodings are not compatible. v Rules-Based Table Mappings Are Not AvailableEnables Management Console to prompt you with a reminder that Rules-based table mappings will not be available if a subscription is created that uses a single database for both the source and target datastore. v Close Progress Windows AutomaticallyEnables Management Console to close the progress window for successful actions; it will prompt you to request more details only if the action is not successful. In the Hints area, you can enable: v Show Subscription Active/Edit PanelEnables Management Console to display subscription information, in the Subscriptions perspective in the Configuration view. This is most useful when determining if a subscription on a datastore with multiuser mode enabled is locked, and who locked it, or if it is available for
20
editing. Depending on the state of the subscription, you will see a Start Editing button, an End Editing button, or an Unlock button if you are an administrator enabled to perform user access and datastore administration. In the Filtering area, you can enable: v Minimum numberSpecifies the minimum number of objects that will prompt database, schema, library, or table filtering when selecting nodes in a datastore. The default value is 5000. You can click Restore Defaults at any time to use the default preferences. See also: To set prompt preferences To automatically close progress windows To show the Show Subscription Active/Edit Panel To configure filtering for databases, schemas, and tables
To set prompt preferences

1. Click Edit > Preferences. 2. Click Prompts. 3. Specify the prompt options you want by enabling the appropriate check boxes. 4. Click Apply.
To automatically close progress windows

1. Click Edit > Preferences. 2. Click Prompts. 3. Enable the Close Progress Windows Automatically check box. 4. Click Apply.
To show the Show Subscription Active/Edit Panel

1. 2. 3. 4. Click Edit > Preferences. Click Prompts. Enable the Show Subscription Active/Edit Panel check box. Click Apply.
To configure filtering for databases, schemas, and tables

1. Click Edit > Preferences. 2. Click Prompts. 3. In the Minimum number box in the Filtering section, specify the number of databases, schemas (or libraries), or tables at which the Map Tables wizard will prompt you to specify a filter. Note that if you select a large value, loading all databases, schemas, or tables may take some time. The default value is 5000. 4. Click Apply.
Setting monitoring preferences

You can control the behavior of monitoring in Management Console by setting the following preferences:
Setting preferences
21
v Statistics History Retained (minutes)Specifies the length of time that Management Console retains data for the statistics view. v Statistics Sample Rate (seconds)Specifies the time interval frequency at which Management Console collects data for the statistics view. A lower number will increase the frequency of data collection. v Show the subscription error indicatorSpecifies that the error overlay icon will be displayed on top of a subscription's icon in the Monitoring > Subscription view, when an error is logged in the event log for the subscription. This indicator must be reset manually. v Automatically retrieve events for the selected subscriptionSpecifies that events will be loaded automatically for the selected subscription when the Events detail panel is opened in the Monitoring view. For subscriptions belonging to datastores which are InfoSphere CDC version 6.5 or later, either recent events or events for the last 24 hours will be loaded. For earlier versions of InfoSphere CDC, all events will be loaded. See also: To set the length of time for data retention To set the sample rate for data collection To show the subscription error indicator To reset the subscription error indicator To automatically retrieve events for selected subscription on page 23
To set the length of time for data retention

1. Click Edit > Preferences. 2. Click Monitoring. 3. Enter the number of minutes in the Statistics History Retained (minutes) box. 4. Click Apply.
To set the sample rate for data collection

1. Click Edit > Preferences. 2. Click Monitoring. 3. Enter the number of minutes in the Statistics Sample Rate (seconds) box. 4. Click Apply.
To show the subscription error indicator

1. Click Edit > Preferences. 2. Click Monitoring. 3. Select the Show the subscription error indicator check box. 4. Click Apply.
To reset the subscription error indicator

1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Right-click and select Reset Error Indicator
22
To automatically retrieve events for selected subscription

1. Click Edit > Preferences. 2. Click Monitoring. 3. Select the Automatically retrieve events for the selected subscription check box. 4. Click Apply.
Setting preferences
23
24
Setting up user accounts

Access Manager is an integrated component of Management Console that provides a central point of administration for System Administrators to manage datastores and user accounts. You must be a System Administrator with user and datastore account management permission to create datastores and users in the Access Manager perspective. You can then assign these users to datastores and set database connection parameters in order to provide users with access to an instance of InfoSphere CDC. Users can be assigned to different roles that are distinguished by different levels of access into Management Console. The Access Manager perspective also provides security options that you can set on user accounts. In this section, you will learn: Managing user accounts Managing security on user accounts on page 30 Setting password and account security policies on user accounts on page 31 Creating user list reports on page 34
Managing user accounts

The Access Manager perspective contains the User Management view. This view enables you to create and manage user accounts and assign them to datastores. In order to work in the Access Manager perspective, you must have a System Administrator role and be enabled to manage user accounts and datastores. Use the Access Manager view to: v Add, modify, delete, or copy user accountsAdding a user account is necessary to provide users with the ability to connect to Access Server and log into Management Console. When adding a user account, you must specify a unique user name. When setting a password for the user, it must meet any complex password requirements you may have set in Management Console. v Assign a datastore to a userAssigning a datastore provides the user access to an instance of InfoSphere CDC and the ability to connect to the datastore that you have made available for replication on the server. v Change the security role of a userChanging the security role on a user account determines the level of access a user has in Management Console. Users can work in either a System Administrator account, Administrator account, Monitor account, or an Operator account. v Generate a report on selected user accountsGenerating a report on a specific user account can help you keep track of which datastores the user has access to, the role of the user, the date of user account creation, and the last time it was modified. You can also track account status settings such as if the account is locked, disabled, if the user is required to change their password at next login, or if the account has a password expiry policy set on it.
25
Understanding user roles

There are four user role types available in the Management Console, each with varying degrees of access and control: v System AdministratorSpecifies that users assigned to this role can perform all available operations in Management Console. Only users that require full operational access to the Monitoring and Configuration perspectives should be assigned to this role. System Administrators can also modify system parameters to calibrate their replication environment. Enable user account and datastore administrationEnables a user assigned the System Administrator role access to the Access Manager perspective. If you enable this option for a user, then they can create users and datastores, as well as define Access Server password settings. This option is available only to the System Administrator role. v AdministratorSpecifies that users assigned to this role can access both the Monitoring and Configuration perspectives in Management Console. Administrators can create new subscriptions, can add, import and export projects, but are not able to access the Access Manager perspective, and cannot add or edit users or datastores. Administrators can start and end replication. v OperatorSpecifies that users assigned to this role can access both the Monitoring and Configuration perspectives in Management Console. Operators can add, import and export projects, but they cannot create new subscriptions. Users assigned to the Operator role can start, stop, and monitor replication activities. They can also view the tables selected for refresh and start a refresh on a subscription. Operators can view notifications sent by subscriptions or datastores. However, users assigned to this role cannot configure replication and select or remove tables from a refresh. v MonitorSpecifies that users assigned to this role only have access to the Monitoring perspective in Management Console. Users assigned to the Monitor role can view events, statistics, and table mappings. Monitors can view the replication state and status of a subscription and can view latency threshold information. However, users assigned to this role cannot start or stop replication, configure replication, refresh tables, or view notifications sent by subscriptions and datastores. See also: To add a user To edit a user on page 27 To delete a user on page 28 To copy a user on page 28 To change the existing role on a user account on page 29 To enable a System Administrator with user account and datastore administration privileges on page 29 To view the history of a user account on page 30 Related tasks To assign a datastore to users on page 40
To add a user
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > User Management.
26
3. Click File > Access Server > New User. 4. Enter the name of the user in the Name box. This is the name the user will need to supply when connecting to Access Server and logging into Management Console. 5. If you want to keep a profile of the user for system administrator purposes, type their full name and a description in the Full Name and Description boxes. 6. If you want the user to specify a password, enter and confirm it in the Password and Confirm Password boxes. If you have enabled complex passwords, then you must specify a password that meets the requirements. 7. If you want to assign the user to a role, choose one of the following: v System AdministratorSpecifies that users assigned to this role can perform all available operations in Management Console. Only users that require full operational access to the Monitoring and Configuration perspectives should be assigned to this role. System Administrators can also modify system parameters to calibrate their replication environment. Enable user account and datastore administrationEnables a user assigned the System Administrator role access to the Access Manager perspective. If you enable this option for a user, then they can create users and datastores, as well as define Access Server password settings. This option is available only to the System Administrator role. v AdministratorSpecifies that users assigned to this role can access both the Monitoring and Configuration perspectives in Management Console. Administrators can create new subscriptions, can add, import and export projects, but are not able to access the Access Manager perspective, and cannot add or edit users or datastores. Administrators can start and end replication. v OperatorSpecifies that users assigned to this role can access both the Monitoring and Configuration perspectives in Management Console. Operators can add, import and export projects, but they cannot create new subscriptions. Users assigned to the Operator role can start, stop, and monitor replication activities. They can also view the tables selected for refresh and start a refresh on a subscription. Operators can view notifications sent by subscriptions or datastores. However, users assigned to this role cannot configure replication and select or remove tables from a refresh. v MonitorSpecifies that users assigned to this role only have access to the Monitoring perspective in Management Console. Users assigned to the Monitor role can view events, statistics, and table mappings. Monitors can view the replication state and status of a subscription and can view latency threshold information. However, users assigned to this role cannot start or stop replication, configure replication, refresh tables, or view notifications sent by subscriptions and datastores.
To edit a user
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. 3. 4. 5. Click Access Manager > User Management. Select an existing user. Click File > Access Server > Properties. If you want to change the full name or description of the user, type this information in the Full Name and Description boxes.
27
6. If you want the user to specify a new password, enter and confirm it in the Password and Confirm Password boxes. As the system administrator, if you have enabled complex passwords, then you must specify a password that meets the requirements. 7. If you want to change the role assigned to the user, choose one of the following: v System AdministratorSpecifies that users assigned to this role can perform all available operations in Management Console. Only users that require full operational access to the Monitoring and Configuration perspectives should be assigned to this role. System Administrators can also modify system parameters to calibrate their replication environment. Enable user account and datastore administrationEnables a user assigned the System Administrator role access to the Access Manager perspective. If you enable this option for a user, then they can create users and datastores, as well as define Access Server password settings. This option is available only to the System Administrator role. v AdministratorSpecifies that users assigned to this role can access both the Monitoring and Configuration perspectives in Management Console. Administrators can create new subscriptions, can add, import and export projects, but are not able to access the Access Manager perspective, and cannot add or edit users or datastores. Administrators can start and end replication. v OperatorSpecifies that users assigned to this role can access both the Monitoring and Configuration perspectives in Management Console. Operators can add, import and export projects, but they cannot create new subscriptions. Users assigned to the Operator role can start, stop, and monitor replication activities. They can also view the tables selected for refresh and start a refresh on a subscription. Operators can view notifications sent by subscriptions or datastores. However, users assigned to this role cannot configure replication and select or remove tables from a refresh. v MonitorSpecifies that users assigned to this role only have access to the Monitoring perspective in Management Console. Users assigned to the Monitor role can view events, statistics, and table mappings. Monitors can view the replication state and status of a subscription and can view latency threshold information. However, users assigned to this role cannot start or stop replication, configure replication, refresh tables, or view notifications sent by subscriptions and datastores.
To delete a user
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > User Management. 3. Select an existing user or hold the Ctrl key to select multiple users. 4. Click File > Access Server > Delete User.
To copy a user
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > User Management. 3. Select an existing user. 4. Click File > Access Server > Copy.
28
5. Enter the name of the user in the New name box.
To change the existing role on a user account

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > User Management. 3. Select a user or hold the Ctrl key to select multiple users. 4. Click File > Access Server > Change Role. 5. Choose from one of the following roles: v System AdministratorSpecifies that users assigned to this role can perform all available operations in Management Console. Only users that require full operational access to the Monitoring and Configuration perspectives should be assigned to this role. System Administrators can also modify system parameters to calibrate their replication environment. Enable user account and datastore administrationEnables a user assigned the System Administrator role access to the Access Manager perspective. If you enable this option for a user, then they can create users and datastores, as well as define Access Server password settings. This option is available only to the System Administrator role. v AdministratorSpecifies that users assigned to this role can access both the Monitoring and Configuration perspectives in Management Console. Administrators can create new subscriptions, can add, import and export projects, but are not able to access the Access Manager perspective, and cannot add or edit users or datastores. Administrators can start and end replication. v OperatorSpecifies that users assigned to this role can access both the Monitoring and Configuration perspectives in Management Console. Operators can add, import and export projects, but they cannot create new subscriptions. Users assigned to the Operator role can start, stop, and monitor replication activities. They can also view the tables selected for refresh and start a refresh on a subscription. Operators can view notifications sent by subscriptions or datastores. However, users assigned to this role cannot configure replication and select or remove tables from a refresh. v MonitorSpecifies that users assigned to this role only have access to the Monitoring perspective in Management Console. Users assigned to the Monitor role can view events, statistics, and table mappings. Monitors can view the replication state and status of a subscription and can view latency threshold information. However, users assigned to this role cannot start or stop replication, configure replication, refresh tables, or view notifications sent by subscriptions and datastores.
To enable a System Administrator with user account and datastore administration privileges
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > User Management. 3. Select an existing user. 4. Click File > Access Server > Properties. 5. Ensure that the user is assigned to the System Administrator role. 6. Enable the Enable user account and datastore administration check box.
29
To view the history of a user account

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > User Management. 3. Select an existing user. 4. Click File > Access Server > Properties. 5. Click the History tab.
Managing security on user accounts

Note: To be able to work in the Access Manager perspective, you must be a System Administrator that has the privilege to manage datastores and user accounts. You can set specific security options on an existing user account in the Access Manager perspective of Management Console. Use the User Properties dialog box to: v Disable user accounts v Require users to change their passwords at next login v Override any password expiration policy you may have set in Management Console v Lock or unlock user accounts See also: To To To 31 To To disable a user account require a user to change password at next login override password expiration policy set in Management Console on page unlock a user account on page 31 unlock a system administrator user account on page 31
To disable a user account

1. Click Access Manager > User Management. 2. Select an existing user. 3. Click File > Access Server > Properties. 4. Enable the Account is disabled check box.
To require a user to change password at next login

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. 3. 4. 5. Click Access Manager > User Management. Select an existing user. Click File > Access Server > Properties. Enable the User must change password at next login check box in the Status section.
30
To override password expiration policy set in Management Console

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > User Management. 3. Select an existing user. 4. Click File > Access Server > Properties. 5. Enable the Password never expires check box.
To unlock a user account

1. Ensure you have system administrator authority with privileges to manage datastores and user accounts in Management Console 2. Click Access Manager > User Management. 3. Right-click the user that is locked out of the account and select Properties. 4. Disable the Account is locked check box. This check box is enabled automatically after the number of failed login attempts exceeds the locking policy set in the Access Server Options dialog box within Management Console.
To unlock a system administrator user account

1. Ensure you have system administrator authority with privileges to manage datastores and user accounts in Management Console 2. Issue the dmunlockuser command where Access Server is installed:
dmunlockuser user_name [-accessserver hostname port adminuser adminpassword]
where the values for the parameters are as follows: The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
Setting password and account security policies on user accounts

You can enhance password and account security on all user accounts in the Access Manager perspective of Management Console. Use the Access Server Options dialog box to:
31
v Set a complex password requirementEnhances password security by enabling users to specify a complex password when logging into Management Console. v Enforce password historyEnables System Administrators to enhance security by ensuring that old passwords are not continually reused. For this policy to be effective, do not let users change their password immediately after setting a new one. You can control this by setting the minimum age of the password. v Enforce a password expiry policyEnables System Administrators to enhance security by ensuring that new passwords are created and associated with user accounts. v Lock accounts after a number of failed login attemptsEnables a three strikes login policy which is used to prevent computer password attacks. The policy creates a condition where a user will be locked out of their account after a number of attempts. By default, this setting is set to 3 login attempts. v Enforce an account expiry after new account creationEnhances account security by forcing users to change their passwords when a new account is created for them. v Display the number of failed login attemptsEnables users to track the number of failed login attempts before they get locked out of the account. v Display the last successful loginEnables users to track their last successful login. Note: To be able to work in the Access Manager perspective, you must be a System Administrator that has the privilege to manage datastores and user accounts. See also: To set complex passwords on user accounts To enforce password history To enforce password expiry on page 33 To enforce password locking on failed login attempts on page 33 To enforce new account expiry on page 33 To display previous failed login attempts on page 33 To display the last successful login on page 33
To set complex passwords on user accounts

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click File > Access Server > Access Server Options. 3. Click Passwords. 4. Enable the Require complex password check box. 5. Enter the minimum password length in the Minimum password length box. The number must be between 0 and 30. 6. Enter the minimum number of alphabetic characters in the Minimum alphabetic characters box. The number must be between 0 and 30. 7. Enter the minimum number of non-alphabetic characters in the Minimum non-alphabetic characters box. The number must be between 0 and 30.
To enforce password history

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts.
32
2. 3. 4. 5.
Click File > Access Server > Access Server Options. Click Passwords. Enable the Enforce Password history check box. Enter the number of passwords remembered in the Passwords remembered box. The number must be between 1 and 12. The default number is 5.
To enforce password expiry

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click File > Access Server > Access Server Options. 3. Click Passwords. 4. Enable the Enforce password expiry check box. 5. Enter the maximum number of days before a password expires in the Maximum password (age) box. The number must be between 1 and 999. The default number is 3.
To enforce password locking on failed login attempts

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. 3. 4. 5. Click File > Access Server > Access Server Options. Click Accounts. Enable the Lock accounts on failed login attempts check box. Enter the maximum number of attempts before an accounts is locked in the Consecutive failures before lock box. The number must be between 1 and 100. The default number is 3.
To enforce new account expiry

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. 3. 4. 5. Click File > Access Server > Access Server Options. Click Accounts. Enable the Enforce new account expiry check box. Enter the maximum number of days before a new account expires in the Maximum new account age (days) box. The number must be between 1 and 999. The default number is 15.
To display previous failed login attempts

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click File > Access Server > Access Server Options. 3. Click Accounts. 4. Enable the Display previous failed login attempts check box.
To display the last successful login

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts.
33
2. Click File > Access Server > Access Server Options. 3. Click Accounts. 4. Enable the Display last successful login check box.
Creating user list reports

You can generate a user list report in the Access Manager perspective of Management Console. Note: To be able to work in the Access Manager perspective, you must be a System Administrator that has the privilege to manage datastores and user accounts. See also: To create a user list report
To create a user list report

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. 3. 4. 5. Click Access Manager > User Management. Select an existing user or hold Ctrl to select multiple users. Click File > Access Server > Reports > User Report. Enable one or more of the following: v Full NameIncludes the full name you specified when you created the user. v RoleIncludes the role you had assigned to the user. v DescriptionIncludes the description you specified when you created the user. v Account StatusIncludes information about the account such as password expiry or if the account has been disabled or locked. v Date CreatedIncludes the date you had created the user account. v Date Last ModifiedIncludes the date the user was last modified. v Datastores AccessIncludes the datastores you have assigned to the user.
34
Setting up datastores
Access Manager is an integrated component of Management Console that provides a central point of administration for System Administrators to manage datastores and user accounts. You must be a System Administrator with user and datastore account management permission to create datastores and users in the Access Manager perspective. You can then assign these users to datastores and set database connection parameters in order to provide users with access to an instance of InfoSphere CDC. Users can be assigned to different roles that are distinguished by different levels of access into Management Console. The Access Manager perspective also provides security options that you can set on user accounts. In this section, you will learn: Managing datastores Managing datastore connections on page 38 Assigning users to datastores on page 40 Enabling multiple users to work simultaneously on the same datastore on page 42 Creating datastore list reports on page 43
Managing datastores
A datastore represents the InfoSphere CDC instance. The Datastore Management view in the Access Manager perspective in Management Console can only be accessed by a user with the role of System Administrator that has been also been enabled to perform user account and datastore management. Use the Datastore Management view to: v Add, modify, copy, and delete datastoresAdding a datastore in Management Console means that you are providing users access to an instance of InfoSphere CDC for the purposes of configuration, monitoring, and operational control. When adding a new datastore, you can optionally specify information about the database and provide database connection parameters so that users can connect to the datastore. Only users you have assigned to a datastore can connect to the datastore. v Assign users to a datastoreAssigning users to a datastore gives them access to an installation of InfoSphere CDC and the ability to connect to the database that you have made available for replication on the server. v Enable multiple users to work with the same datastoreEnabling more than one user to work with subscriptions in the same datastore means allowing users to lock subscriptions they want to edit. This makes the subscriptions temporarily unavailable to others, so there are no edit conflicts. A System Administrator enabled to perform user account and datastore administration can also unlock a subscription on behalf of a user (for example, a user locks a subscription, but then goes on vacation; the System Administrator enabled to perform user account and datastore administration can override the lock and make the subscription available to other users now).
35
v Propagate connection parametersPropagating new connection parameters to all users of the datastore eases system administration in that you only have to specify connection parameters once. v Generate reports on the activities related to a set of datastoresGenerating a report on a specific datastore can help you keep track of which users you have assigned datastore access to and what databases users can access, the date of creation, and the last time it was modified. See also: To add a datastore To edit a datastore To delete a datastore on page 37 To copy a datastore on page 37 To view the history of a datastore on page 37 To set connection parameters on a datastore on page 37 Related concepts Setting up datastores for replication on page 71 Related tasks To assign users to a datastore on page 41
To add a datastore
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. Click Access Manager > Datastore Management. Click File > Access Server > New Datastore. Enter the name of the datastore in the Name box. Enter a description in the Description box. Enter the host name or the full IP address of the server where you have installed InfoSphere CDC in the Host Name box. 7. Enter the port number of the server in the Port box. 8. Ping the server. If successful, this returns the datastore properties including the type of server where you have installed InfoSphere CDC and the version number of the product. Datastores that use the Java VM and are platform independent will return a platform type of Java VM and a database type of JDBC for all types of servers. 9. If you want to enable multiple users to configure subscriptions in the same datastore, enable the Require subscriptions to be locked before editing box in the Multiuser Configuration area. Related concepts Setting up datastores for replication on page 71 2. 3. 4. 5. 6. Enabling multiple users to work simultaneously on the same datastore on page 42 Setting prompt preferences on page 20
To edit a datastore
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > Datastore Management. 3. Select an existing datastore.
36
Click File > Access Server > Properties. If you want to change the Name of the datastore, type it in the Name box. If you want to change the description, type it in the Description box. If the name of the server or IP address where InfoSphere CDC is installed has changed, type it in the Host Name box. 8. If the port number of the server has changed, type it in the Port box. 9. If you upgrade an instance of InfoSphere CDC 6.3 to the Fix Pack 3 level, and want to allow multiple users to work with the same datastore, you must ping the server by clicking Ping. 10. If you want to enable multiple users to configure subscriptions in the same datastore, enable the Require subscriptions to be locked before editing box in the Multiuser Configuration area. Related concepts Setting up datastores for replication on page 71 4. 5. 6. 7.
To delete a datastore
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > Datastore Management. 3. Select an existing datastore or hold Ctrl and select multiple datastores. 4. Click File > Access Server > Delete Datastore . Related concepts Setting up datastores for replication on page 71
To copy a datastore
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > Datastore Management. 3. Select an existing datastore. 4. Click File > Access Server > Copy Datastore. 5. Enter the name of the new datastore in the New Name box. Related concepts Setting up datastores for replication on page 71
To view the history of a datastore

1. Click Access Manager > Datastore Management. 2. Select a datastore. 3. Click File > Access Server > Properties. 4. Click History. Related concepts Setting up datastores for replication on page 71
To set connection parameters on a datastore

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > Datastore Management. 3. Select an existing datastore.
37
4. Click File > Access Server > Properties. 5. Click Connection Parameters. 6. Set the following options: v In the Connection Parameters section: Database/URLSpecifies the name of the database or the Universal Resource Locator (URL) of the database server you want to connect to. This option is automatically disabled for InfoSphere CDC for z/OS or InfoSphere CDC for DB2 for i datastores, and for datastores at version 6.3.0 and later. DatabaseSpecifies the name of the database server you want to connect to. This option is only enabled for datastores for which it is required. DB LoginSpecifies the database user name to connect to the database. If you want users to connect to the database for replication with InfoSphere DataStage, then you must specify the user you created when installing InfoSphere CDC. DB PasswordSpecifies the password to connect to the database. Confirm PasswordSpecifies a repeat entry of the password for accuracy. v In the Propagate Changes section: Propagate changes to all usersEnable this check box if you want all users assigned to this datastore to receive the connection parameters that you specify on this dialog box. Related concepts Setting up datastores for replication on page 71
Managing datastore connections

A datastore represents the InfoSphere CDC instance. The Connection Management view in the Access Manager perspective in Management Console can only be accessed by a user with the role of System Administrator that has been also been enabled to perform user account and datastore management. The contents displayed in the Connection Management view depend on the entry you select from either the Datastore Management view or the User Management view. Selecting an entry from the Datastore Management view displays the selected datastore and any users assigned to it. Selecting an entry from the User Management view displays the selected users and any assigned datastores. Use the Connection Management view to: v Assign a user to a datastoreAssigning a user to a datastore creates a relationship between the datastore and that user. When assigning a user, you can specify the correct connection parameters for the user to connect to the datastore; if you do not, the user will be prompted to enter these parameters when connecting to the datastore. You can assign the same user to more than one datastore. v Assign a datastore to a userAssigning a datastore to a user creates a relationship between the user and that datastore. When assigning a user, you can specify the correct connection parameters for the user to connect to the datastore; if you do not, the user will be prompted to enter these parameters when connecting to the datastore. You can assign the same datastore to more than one user.
38
v Set connection parametersSetting connection parameters on a datastore provides users with the ability to connect to the datastore. If you have already specified connection parameters for a datastore when you added it to Management Console, then these parameters will display when you assign a user to a datastore. You can choose to apply the same connection parameters, or you can choose to override them and specify another set of connection parameters. v Modify and delete connection parametersDeleting an existing connection is necessary when a user no longer requires access to a specific datastore. You can also modify connection parameters. Ensure that users are aware of the new parameters so that they can connect. See also: To delete a connection To override default connection parameters on a datastore Related tasks To assign users to a datastore on page 41
To delete a connection
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager. 3. Delete an existing connection using one of the following methods: v Click Datastores Management and select an existing datastore that has a user assigned to it. Click Connection Management and right-click on the user assigned to the datastore. Click Delete Connection. v Click User Management and select an existing user that has a datastore assigned to it. Click Connection Management and right-click on the datastore assigned to the user. Click Delete Connection.
To override default connection parameters on a datastore

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > Datastore Management. 3. Select the datastore. 4. Select the user assigned to this datastore in the Connection Management view. 5. Click File > Access Server > Connection Parameters. 6. Set the following options: v In the Connection Parameters section: Database/URLSpecifies the name of the database or the Universal Resource Locator (URL) of the database server you want to connect to. This option is automatically disabled for InfoSphere CDC for z/OS or InfoSphere CDC for DB2 for i datastores, and for datastores at version 6.3.0 and later. DatabaseSpecifies the name of the database server you want to connect to. This option is only enabled for datastores for which it is required. DB LoginSpecifies the database user name to connect to the database. If you want users to connect to the database for replication with InfoSphere DataStage, then you must specify the user you created when installing InfoSphere CDC.
39
DB PasswordSpecifies the password to connect to the database. Confirm PasswordSpecifies a repeat entry of the password for accuracy. the Propagate Changes section: Propagate changes to all usersEnable this check box if you want all users assigned to this datastore to receive the connection parameters that you specify on this dialog box. 7. If you want to set specific options on how these connection parameters are displayed to the user when connecting to the datastore in the Connect to datastore dialog box, then enable one or more of the following options: v Always show connection dialogAllows the user to specify the password each time they want to connect to the datastore. v Show parameter values (except password)Displays the connection parameters to the user (except password) each time the user tries to connect to the datastore. Enable this to allow you to enable Write-protect parameters (except password). v Write-protect parameters (except password)Displays the connection parameters to the user (except password) in read-only format each time the user tries to connect to the datastore. Enable Show parameter values (except password) to allow you to enable this. v Allow connection parameters savingAllows the user to save the connection parameters when connecting to a datastore.
v In
Assigning users to datastores

In the Access Manager perspective of Management Console using either the Datastore Management view, the User Management view, or the Connection Management view, you can either assign a datastore to a user, or you can assign a user to a datastore. Both methods create the required relationship between a datastore and a user. Users require this relationship to connect to a datastore. A datastore represents the InfoSphere CDC instance. See also: To assign a datastore to users To assign users to a datastore on page 41
To assign a datastore to users

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Ensure that you have added a user. 3. Click Access Manager > User Management. 4. Click File > Access Server > Assign > Datastore. 5. Select a datastore. 6. Review the connection parameters. You can click OK to accept the default connection parameters on the datastore or you can choose to override the default parameters for the selected user. 7. If you choose to override the defaults, specify the following: v In the Connection Parameters section:
40
Database/URLSpecifies the name of the database or the Universal Resource Locator (URL) of the database server you want to connect to. This option is automatically disabled for InfoSphere CDC for z/OS or InfoSphere CDC for DB2 for i datastores, and for datastores at version 6.3.0 and later. DatabaseSpecifies the name of the database server you want to connect to. This option is only enabled for datastores for which it is required. DB LoginSpecifies the database user name to connect to the database. If you want users to connect to the database for replication with InfoSphere DataStage, then you must specify the user you created when installing InfoSphere CDC. DB PasswordSpecifies the password to connect to the database. Confirm PasswordSpecifies a repeat entry of the password for accuracy. v In the Propagate Changes section: Propagate changes to all usersEnable this check box if you want all users assigned to this datastore to receive the connection parameters that you specify on this dialog box. 8. If you want to set specific options on how these connection parameters are displayed to the user when connecting to the datastore in the Connect to datastore dialog box, then enable one or more of the following options: v Always show connection dialogAllows the user to specify the password each time they want to connect to the datastore. v Show parameter values (except password)Displays the connection parameters to the user (except password) each time the user tries to connect to the datastore. Enable this to allow you to enable Write-protect parameters (except password). v Write-protect parameters (except password)Displays the connection parameters to the user (except password) in read-only format each time the user tries to connect to the datastore. Enable Show parameter values (except password) to allow you to enable this. v Allow connection parameters savingAllows the user to save the connection parameters when connecting to a datastore.
To assign users to a datastore

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Ensure that you have added a datastore. 3. Click Access Manager > Datastore Management. 4. Select an existing datastore. 5. Right-click and select Assign User. 6. Select a user or hold Ctrl to select multiple users. 7. Review the connection parameters. You can click OK to accept the default connection parameters on the datastore or you can choose to override the default parameters for the selected users. 8. If you choose to override the defaults, specify the following: v In the Connection Parameters section: Database/URLSpecifies the name of the database or the Universal Resource Locator (URL) of the database server you want to connect to.
41
This option is automatically disabled for InfoSphere CDC for z/OS or InfoSphere CDC for DB2 for i datastores, and for datastores at version 6.3.0 and later. DatabaseSpecifies the name of the database server you want to connect to. This option is only enabled for datastores for which it is required. DB LoginSpecifies the database user name to connect to the database. If you want users to connect to the database for replication with InfoSphere DataStage, then you must specify the user you created when installing InfoSphere CDC. v In DB PasswordSpecifies the password to connect to the database. Confirm PasswordSpecifies a repeat entry of the password for accuracy. the Propagate Changes section: Propagate changes to all usersEnable this check box if you want all users assigned to this datastore to receive the connection parameters that you specify on this dialog box.
9. If you want to set specific options on how these connection parameters are displayed to the user when connecting to the datastore in the Connect to datastore dialog box, then enable one or more of the following options: v Always show connection dialogAllows the user to specify the password each time they want to connect to the datastore. v Show parameter values (except password)Displays the connection parameters to the user (except password) each time the user tries to connect to the datastore. Enable this to allow you to enable Write-protect parameters (except password). v Write-protect parameters (except password)Displays the connection parameters to the user (except password) in read-only format each time the user tries to connect to the datastore. Enable Show parameter values (except password) to allow you to enable this. v Allow connection parameters savingAllows the user to save the connection parameters when connecting to a datastore.
Enabling multiple users to work simultaneously on the same datastore

Note: Multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere CDC for IBM i. You can configure datastores to allow multiple users to work on them simultaneously. Enabling this option requires users to explicitly lock a subscription within a datastore so that others do not use it and cause conflicts. A System Administrator enabled to perform user account and datastore administration can set this option either during or after datastore creation, and can also unlock subscriptions. Management Console displays the status of subscriptions in one of two ways: v Using status icons in the list of subscriptions in the Subscriptions perspective in the Configuration view. Depending on the state of the subscription, you will see a small lock icon to indicate that the subscription is locked, or a small box and arrow icon to indicate that the subscription is available for editing. This perspective does not provide details on who has locked a subscription. v Using the Subscription Active/Edit Panel, a window under the list of subscriptions in the Subscriptions perspective in the Configuration view that
42
displays subscription status details. This panel is enabled by default. To turn it off, go to Edit > Preferences. If the subscription is available for editing and multiuser configuration is enabled, you will see a Start Editing button. If you are editing the subscription, you will see a pencil and End Editing button. If another user is editing the subscription, you will see a lock icon and details on the user who has locked the subscription. If you are an administrator enabled to perform user access and datastore administration, you will see the Unlock button when a subscription is locked by another user. If multiuser configuration is not enabled, a subscription is always available for editing unless the subscription is currently replicating. If you disable the multiuser configuration option after it is enabled, Management Console users working with the subscriptions in this datastore will not be aware of this change until they log into Management Console again. If you are using multiple Access Server instances on the same datastore, then you must enable or disable the datastore multiuser configuration option for each instance. To enable multiple users to work with a datastore
To enable multiple users to work with a datastore

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Verify your version of InfoSphere CDC. Multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere CDC for IBM i. 3. Click Access Manager > Datastore Management. 4. Right-click on a datastore and select Properties. 5. Ping the server by clicking Ping in the Identification area. 6. Enable the Require subscriptions to be locked before editing check box in the Multiuser Configuration area. 7. Click OK. 8. If you are using multiple Access Server instances on the same datastore, then you must enable the datastore multiuser configuration option for each instance. Related concepts Enabling the apply of soft deletes (InfoSphere CDC for Oracle databases) on page 330 Related tasks To add a datastore on page 36 To modify a system parameter on page 74
Creating datastore list reports

You can generate a datastore list report in the Access Manager perspective of Management Console. Note: To be able to work in the Access Manager perspective, you must be a System Administrator that has the privilege to manage datastores and user accounts. See also:
43
To create a datastore list report
To create a datastore list report

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click Access Manager > Datastore Management. 3. Select an existing datastore or hold Ctrl to select multiple datastores. 4. Click File > Access Server > Reports > Datastore Report. 5. Enable one or more of the following: v DescriptionIncludes a description you specified when you added the datastore. v Datastore PlatformIncludes the type of database platform on which this datastore resides. v Date CreatedIncludes the date you had created the datastore. v Date Last ModifiedIncludes the date the datastore was last modified. v User AccessIncludes the users you have assigned to this datastore. 6. Click OK and Save.
44
Auditing user accounts, datastores, security policies, and general events

You can audit user accounts, datastores, security policies, and general events in the Access Manager perspective of Management Console. Collecting data generated by user activities is very important for analyzing the security of information, verifying system integrity, and detecting signs of suspicious behavior. By generating reports that contain this type of information, you can systematically examine user activities and identify any attempts to breach the security of your replication configuration. When audit logging is enabled, Access Server keeps track of significant activities and records them into an audit log file. You can archive audit log files and generate audit trail reports for a specified period of time from the current audit log, or from an archived log file. Two types of reports can be generated from an audit log: audit trail and security log. You can save audit trail reports as HTML files, and display or print them through a web browser. Note: To be able to work in the Access Manager perspective, you must be a System Administrator that has the privilege to manage datastores and user accounts. In this section, you will learn: Collecting data generated by user activities
Collecting data generated by user activities

Use the Audit tab in the Access Server Options dialog box to: v Enable audit loggingEnabling audit logging lets you audit the activity of user accounts, datastores, security policies set on user accounts, and other general events. Use the Audit Trail Report dialog box to generate an audit trail report. You can generate audit trail reports after enabling audit logging. The following activities are recorded in the report: v Added, modified, or deleted user accounts v Added, modified, deleted, or renamed datastores v New or lost user and datastore assignments v Enabled, disabled, or modified ability to generate an audit log v Modified security settings on user accounts Use the Security Log dialog box to generate a security log report. You can generate security log reports after enabling audit logging. The following activities are recorded the report: v Modified user passwords v v v v v Disabled or enabled user accounts Locked or unlocked user accounts Successful or failed log in attempts by a user Which users are logged or logged out of Management Console Which datastores users are connected to or disconnected from
v Started or stopped Access Server v Generated report lists

45
Each of the activities contained in either an audit trail or security log report has the following categories and items of information: v EventSpecifies the description of the activity being audited. v TimestampThe date and time of activity. v IdentificationDepending on the activities being audited, the report will specify the name on the user account, datastore name, and the process responsible for generating the activity. v CommentProvides more information if applicable. Note: To be able to work in the Access Manager perspective, you must be a System Administrator that has the privilege to manage datastores and user accounts. See also: To enable auditing To generate an audit trail log To generate a security log report To clear the log on page 47
To enable auditing
1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Click File > Access Server > Access Server Options. 3. Click the Audit tab. 4. Enable the Enable audit log check box. 5. Enable one or more of the following: v Audit account managementEnable if you want to audit user account management activities such as the creation, modification, and deletion of users. v Audit datastore managementEnable if you want to audit datastore management activities such as the creation, modification, and deletion of datastores. v Audit security policy managementEnable if you want to audit security policy settings related to passwords and user accounts. v Audit general eventsEnable if you want to audit general events generated by Access Server.
To generate an audit trail log

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Ensure that you have enabled audit logging. 3. Click File > Access Server > Audit log > Audit Trail. 4. Select the start date of the events you want to audit in the From box. 5. Select the end date of the events you want to audit in the To box.
To generate a security log report

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Ensure that you have enabled audit logging.
46
3. Click File > Access Server > Audit log > Security Log. 4. Select the start date of the events you want to audit in the From box. 5. Select the end date of the events you want to audit in the To box.
To clear the log

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Ensure that you have enabled audit logging and generated a report. This ensures that there is nothing important in the report that you want to save first before clearing the log. 3. Click File > Access Server > Audit log > Clear Log . 4. Click Yes.
Auditing user accounts, datastores, security policies, and general events
47
48
Setting up and configuring subscriptions

A subscription is a connection that is required to replicate data between a source datastore and a target datastore. It contains details of the data that is being replicated and how the source data is applied to the target. Subscriptions use datastores as the source or target of replicated data. You can view the datastores that your subscriptions are using in the Source and Target columns of the Subscriptions view. Before you can start replicating data, you need to add a subscription. When adding a new subscription, you can organize your subscription into a project and select the datastores you want to use as the source and target of data during replication activities. How you decide to set up the datastores in your subscriptions depends on your replication requirements.
Setting up subscriptions for datastores outside of your organization

You can also add subscriptions that send data to a target datastore that is external to your organization. In order to set up a subscription that sends data to an external target datastore, the receiving organization must have installed Management Console and you must have the necessary authentication and database details to connect to their target datastore. External source or target datastores are not available in your Access Manager, either because they reside outside of your organization or department, or your system administrator has not given you the permission to access it. If you have received authorization from the company or organization to which you are replicating data, then you can modify the properties of an external target datastore, including the port number, owner, and password. System and database information about external target datastores is provided by the organization or department that owns that datastore. You can also copy subscriptions that send data to an external target. This is a timesaving mechanism. If your organization is at the receiving end of replication activities coordinated with another organization that is outside of your database security policy, then you should see Unknown source datastores in your subscription list. This is because you are receiving replicated data from a source datastore that is outside of your security policy (and, therefore, to which you do not have access to) and the name of the source datastore is not known to you.
Setting properties for a subscription that targets IBM InfoSphere DataStage

If you create a subscription that uses InfoSphere CDC for InfoSphere DataStage as a target datastore, you can modify the following subscription properties: v Batch size thresholdsInfoSphere DataStage uses jobs to process batches of data. When balancing the need to get data applied to the target quickly against the need to minimize resource utilization, you can set the batch size threshold property to run jobs less frequently and process larger amounts of data.
49
v Large object truncation size for character and binary dataThe truncation point affects the fixed record length used by an InfoSphere DataStage job that processes the changed data. You should set this property to as small a size as possible while still retaining enough of the data from the large columns to meet your business needs. See also: Subscriptions view (Configuration perspective) Setting up subscriptions Specifying network settings for subscriptions on page 52 Setting propagation control on subscriptions on page 53 Locking subscriptions within a datastore on page 54 Determining error handling for subscriptions on page 57 Making subscriptions persistent on page 58 Searching for tables used in replication on page 59 Setting up subscriptions for datastores outside of your organization on page 60 Copying subscriptions on page 61 Upgrading existing Transformation Server subscriptions to InfoSphere CDC on page 64 Reverting to Transformation Server on page 67 Using projects to organize your subscriptions on page 68 Exporting and importing projects on page 69
Subscriptions view (Configuration perspective)

A subscription is a connection that is required to replicate data between a source datastore and a target datastore. It contains details of the data that is being replicated and how the source data is applied to the target. Subscriptions use datastores as the source or target of replicated data. In this view, you can do the following: v Add and configure subscriptions v Create, export, and import projects for your subscriptions v Promote subscriptions Related concepts Logging in to Management Console by connecting to Access Server on page 10 Setting up and configuring subscriptions on page 49 Promoting subscription changes on page 377
Setting up subscriptions
Before you can start replicating data, you need to add a subscription. When adding a new subscription, you can organize your subscription into a project and select the datastores you want to use as the source and target of data during replication activities. How you decide to set up the datastores in your subscriptions depends on your replication requirements. When creating your subscriptions, be aware that all subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is
50
automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, you must open the Advanced Settings dialog and give the subscription a unique Source ID. See also: To add a subscription To modify a subscription on page 52 To delete a subscription on page 52
To add a subscription
1. Click Configuration > Subscriptions. 2. Right-click on a project and select New Subscription. 3. Enter the name of the new subscription in the Name box. All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. 4. Enter the description of the new subscription in the Description box. 5. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. 6. Select the source datastore from the Source list. 7. Select the target datastore from the Target list. 8. If you selected <External> from the Target datastore list, click Details to supply the required connection information. 9. If you want to specify advanced settings for the subscription, click Advanced Settings. Modify the following properties and click OK, then click Next. v Source IDSpecify the source ID for the new subscription. v TCP HostSpecify the TCP host that your source datastore will use to recognize the target datastore when the computer where InfoSphere CDC is installed has multiple network cards. This is useful if you want to specify a host that is different from the host that you specified in the Access Manager perspective. The default option is Auto-select, which will automatically select the network card that can communicate with the target datastore. The host that you specified in theAccess Manager perspective also appears by default as well as any alias that you configured in the Datastore Properties dialog box. v Firewall PortSpecify a port number for the new subscription. v Mark subscription as persistentEnable if you want to specify that the subscription is persistent. A subscription can only be restarted automatically if it is enabled for persistency. v Propagation ControlClick Add and select the source ID for any subscription for which you want to prevent data from being replicated to the target. v Do not replicate data received from any subscriptionsEnable if you want to prevent replication from all subscriptions.
51
v Select the datastore to handle the transferable workSpecify where transferable work will be performed, in order to minimize impact on the source or target datastore. 10. Click OK. Related concepts Setting up subscriptions on page 50 Setting up subscriptions for datastores outside of your organization on page 60 Creating aliases for a target datastore on a private network connection on page 74 Using projects to organize your subscriptions on page 68 Related tasks To add a subscription for an external target datastore on page 60
To modify a subscription
1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select Properties. 3. You can modify the following: v DescriptionEnter the description of the subscription. v ProjectSelect a project or click New Project to create a new project. 4. If you specified an External target datastore when mapping your tables, you can click Details and modify the appropriate settings. Related concepts Setting up subscriptions on page 50 Setting up subscriptions for datastores outside of your organization on page 60 Creating aliases for a target datastore on a private network connection on page 74 Related tasks To modify a subscription for an external target datastore on page 61
To delete a subscription
1. Click Configuration > Subscriptions. 2. Ensure that replication for the subscription has ended. 3. Ensure that the subscription is connected to the target datastore. 4. Right-click on a subscription and select Delete Subscription. 5. If you have a subscription with an external target, ensure that you also delete the corresponding subscription on the external target. Related tasks To end replication on page 362 To delete a table mapping on page 133 To connect to a datastore on page 72
Specifying network settings for subscriptions

You can set some network communication settings for your subscription.
52
You can specify the TCP host that your source datastore will use to recognize the target datastore when the computer where InfoSphere CDC is installed has multiple network cards. This is useful if you want to specify a host that is different from the host that you specified in InfoSphere CDC Access Manager. You may also specify a firewall port for a subscription, which is useful if the source and target datastores have a limited number of ports for communication through a firewall. See also: To specify a TCP host for a subscription To specify a firewall port for a subscription
To specify a TCP host for a subscription

1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select Properties. 3. Click Advanced Settings. 4. Select the TCP host name for the subscription in the TCP Host drop down list. Your source datastore will use this name to recognize the source database when the computer where InfoSphere CDC is installed has multiple network cards. This is useful if you want to specify a host that you specified in the Access Manager perspective. The default option is Auto-select which will automatically select the network card that can communicate with the datastore. The host that you specified in the Access Manager perspective also appears by default as well as any aliases that you configured in the Datastore Properties dialog box. Related concepts Specifying network settings for subscriptions on page 52 Creating aliases for a target datastore on a private network connection on page 74
To specify a firewall port for a subscription

Click Configuration > Subscriptions. Right-click on a subscription and select Properties. Click Advanced Settings. Enter the appropriate port number in the Firewall Port box if your source datastore is behind a firewall. Related concepts Specifying network settings for subscriptions on page 52 1. 2. 3. 4.
Setting propagation control on subscriptions

You can use propagation control to prevent the replication of data from a particular source. This is useful if you are using a bidirectional replication configuration and prevents subscriptions from unnecessarily repeating operations like inserting data. Propagation control is not available for the following InfoSphere CDC replication engines: v InfoSphere Change Data Capture for Oracle databases version 6.0 and earlier v InfoSphere CDC for z/OS
53
v v v v
InfoSphere InfoSphere InfoSphere InfoSphere
CDC CDC CDC CDC
for DB2 for i for Teradata for InfoSphere DataStage Event Server
See also: To set propagation control on a subscription
To set propagation control on a subscription

1. Click Configuration > Subscriptions. 2. Ensure that the datastore for the subscription supports propagation control. Propagation control is not available for the following InfoSphere CDC replication engines: v InfoSphere CDC for Oracle databases version 6.0 and earlier v InfoSphere CDC for z/OS v InfoSphere CDC for DB2 for i v InfoSphere CDC for Teradata v InfoSphere CDC for InfoSphere DataStage v InfoSphere CDC Event Server 3. Right-click on a subscription and select Properties. 4. Click Advanced Settings. 5. If the subscription is for a InfoSphere Change Data Capture for Microsoft SQL Server version 5.3 datastore, choose a subscription from the Do not replicate data received form the following subscription list box and click OK. 6. If the subscription is for any other InfoSphere CDC version that supports propagation control, click Add in the Propagation Control area to select the source ID of the subscription from which you want to prevent data from being replicated to the target. Table-level recursion prevention overrides this setting for a subscription. For more information on how to set recursion prevention, see To change the replication method of a table on page 350. 7. Select the Do not replicate data received from any subscriptions box if you want to prevent data from being replicated to the target for all subscriptions. Related concepts Setting propagation control on subscriptions on page 53 Related tasks To change the replication method of a table on page 350
Locking subscriptions within a datastore

Note: Multiuser configuration can be enabled for InfoSphere CDC version 6.3 Fix Pack 3 and later. It is not available for InfoSphere CDC for z/OS or InfoSphere CDC for IBM i. Users can lock subscriptions within a datastore so that it is read-only to other users. If you are a System Administrator enabled to perform user account and datastore administration, you can also override this setting and unlock the subscription so that it becomes available to other users.
54
See also: To view subscription state details To view subscription state details in the Subscription Active/Edit Panel To lock a subscription for editing To lock a subscription for editing in the Subscription Active/Edit Panel To unlock a subscription on page 56 To unlock a subscription in the Subscription Active/Edit Panel on page 56 To unlock a subscription (System Administrator) on page 56 To unlock a subscription in the Subscription Active/Edit Panel (System Administrator) on page 57 To view the history report for a subscription on page 57
To view subscription state details

1. Ensure that you have the role of Operator, Administrator, or System Administrator. 2. Click Configuration > Subscriptions. 3. Browse through the list of subscriptions. Management Console displays an icon that indicates locked or available for editing beside each subscription in the list.
To view subscription state details in the Subscription Active/Edit Panel

1. Ensure that you have the role of Operator, Administrator, or System Administrator. 2. Click Configuration > Subscriptions. 3. Ensure that the Subscription Active/Edit Panel appears under the list of subscriptions. 4. Click the desired subscription in the list of subscriptions to view its details in the Subscription Active/Edit Panel.
To lock a subscription for editing

1. Ensure that you have the role of Operator, Administrator, or System Administrator. 2. Click Configuration > Subscriptions. Management Console displays an icon that indicates locked or available for editing beside each subscription in the list. 3. Right-click the subscription you want to edit from the list of subscriptions. 4. Click Start Editing to lock the subscription, which makes the subscription read-only to other users and allows you to start editing it.
To lock a subscription for editing in the Subscription Active/Edit Panel

1. Ensure that you have the role of Operator, Administrator, or System Administrator. 2. Click Configuration > Subscriptions. 3. Ensure that the Subscription Active/Edit Panel appears under the list of subscriptions.
55
4. Click the desired subscription in the list of subscriptions to view its details in the Subscription Active/Edit Panel. 5. Click the Start Editing button to lock the subscription, which makes the subscription read-only to other users and allows you to start editing it.
To unlock a subscription
1. Ensure that you have the role of Operator, Administrator, or System Administrator. 2. Click Configuration > Subscriptions. Management Console displays an icon that indicates locked or available for editing beside each subscription in the list. 3. Right-click the subscription you want to unlock from the list of subscriptions. 4. Click End Editing to unlock the subscription and allow other users to edit it. 5. Add a comment to log your changes for the subscription in the dialog that displays.
To unlock a subscription in the Subscription Active/Edit Panel

1. Ensure that you have the role of Operator, Administrator, or System Administrator. 2. Click Configuration > Subscriptions. 3. Ensure that the Subscription Active/Edit Panel appears under the list of subscriptions. 4. Click the desired subscription in the list of subscriptions to view its details in the Subscription Active/Edit Panel. 5. Click End Editing to unlock the subscription and allow other users to edit it. 6. Add a comment to log your changes for the subscription in the dialog that displays.
To unlock a subscription (System Administrator)

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Verify that the user who has locked the subscription has completed and saved all work. Management Console will notify the user, who currently has the subscription locked, that their changes will be aborted and Management Console will be terminated. This can result in lost in configuration if changes are currently being saved. 3. Click Configuration > Subscriptions. Management Console displays an icon beside each subscription that indicates locked or available for editing beside each subscription in the list.. 4. Right-click the subscription you want to unlock from the list of subscriptions. 5. Click End Editing to unlock the subscription, which aborts any unsaved changes and makes the subscription available to other users. 6. Add a comment to log your changes for the subscription in the dialog that displays. 7. Click OK.
56
To unlock a subscription in the Subscription Active/Edit Panel (System Administrator)

1. Ensure that you are a System Administrator and have the privileges to manage datastores and user accounts. 2. Verify that the user who has locked the subscription has completed and saved all work. Management Console will notify the user, who currently has the subscription locked, that their changes will be aborted and Management Console will be terminated. This can result in lost in configuration if changes are currently being saved. 3. Click Configuration > Subscriptions. 4. Ensure that the Subscription Active/Edit Panel appears under the list of subscriptions. 5. Click the desired subscription in the list of subscriptions to view its details in the Subscription Active/Edit Panel. 6. Click End Editing to unlock the subscription, abort any unsaved changes, and make the subscription available to other users. 7. Add a comment to log your changes for the subscription in the dialog that displays.
To view the history report for a subscription

1. Click Configuration > Subscriptions. 2. Right-click the subscription you want to view from the list of subscriptions. 3. Select Show Edit History to see all the activities to and comments logged against to the subscription.
Determining error handling for subscriptions

When an error occurs in an InfoSphere CDC for z/OS subscription, the global error parameter for the datastore determines whether replication stops or continues with error. You can use the subscription error handling options to override this, if desired. See also: To set error handling for a subscription
To set error handling for a subscription

1. 2. 3. 4. 5. Ensure that you are connected to an InfoSphere CDC for z/OS datastore. Click Configuration > Subscriptions. Right-click on a subscription and select Properties. Click Advanced Settings. Select an option from the When mirroring list box to determine the action to be performed when an error occurs while mirroring. v Use global End on Error settingApplies the ENDONERROR value for the address space, as set in the CONFIG statement. This is the default value. For more information on the CONFIG statement see the Modifying general product configuration control statements section in your InfoSphere Change Data Capture for z/OS documentation v End on ErrorEnds mirroring after an error is detected on the target database.
57
v Continue on ErrorMirroring continues after an error is detected on the target database. 6. Select an option from the When refreshing list box to determine the action to be performed when an error occurs during a refresh. v Use global End on Error settingApplies the ENDONERROR value for the address space, as set in the CONFIG statement. This is the default value. For more information on the CONFIG statement see the Modifying general product configuration control statements section in your InfoSphere Change Data Capture for z/OS documentation v End on ErrorEnds the refresh operation after an error is detected. v Continue on ErrorContinues the refresh operation after the error is detected.
Making subscriptions persistent

InfoSphere CDC may initiate a normal shutdown and end mirroring under the following circumstances: v Interruptions in network communications v DB2 LUW deadlock or timeout errors for subscriptions that target DB2 LUW To automatically restart continuous mirroring of subscriptions after a normal shutdown of InfoSphere CDC due to the preceding scenarios, you can mark the subscriptions as persistent. When persistency is enabled and network communications terminate, InfoSphere CDC attempts to automatically restart continuous mirroring for persistent subscriptions at regular intervals. Attempts continue until an automatic restart is successful or until the persistent subscription or the InfoSphere CDC for z/OS address space is terminated. In the event of a deadlock or timeout error with subscriptions that target DB2 LUW, an event message will indicate that the error is recoverable and if you mark the subscription as persistent it will restart automatically. When restarted, the subscription will resend the data that has been rolled back as a result of the error and continue. Subscriptions will not restart automatically if you intentionally end replication for an active subscription by name. For InfoSphere CDC for z/OS subscriptions only, automatic restart will still apply if you have ended replication for a group of subscriptions by specifying the wild card character ('*') with the ENDTSMIR command. Persistency is only relevant to subscriptions that are used for continuous mirroring. If a persistent InfoSphere CDC for z/OS subscription is used for Refresh or Scheduled End (Net Change) mirroring and network communications are interrupted, this subscription is restarted according to how the same subscription was terminated the last time it was used for continuous mirroring. For all other InfoSphere CDC replication engines, if a persistent subscription is used for Refresh or Scheduled End (Net Change) mirroring and network communications are interrupted, it will not be restarted automatically. You can set how often InfoSphere CDC for z/OS attempts to automatically restart continuous mirroring for all persistent subscriptions by modifying the AUTORESTARTINTERVAL configuration control statement keyword. For more
58
information, see your InfoSphere CDC for z/OS documentation. For all other InfoSphere CDC replication engines, you can enable persistency by setting a value to determine how often InfoSphere CDC attempts to automatically restart continuous mirroring for all persistent subscriptions through the mirror_auto_restart_interval_minutes system parameter. See also: To mark a subscription as persistent
To mark a subscription as persistent

1. 2. 3. 4. Click Configuration > Subscriptions. Right-click on a subscription and select Properties. Click Advanced Settings. Select the Mark subscription as persistent check box. The new persistency setting will not take effect until the subscription starts mirroring.
Searching for tables used in replication

In order to make tables available for replication, you must create a subscription and associate a source and target datastore. These datastores contain the tables you want to use in replication. You may have more than one subscription using the same table in replication. When you want to make the table unavailable from replication, it becomes important to search for the table and identify which subscriptions are using it replication activities. See also: To search for subscriptions that use a table in replication
To search for subscriptions that use a table in replication

1. Click Configuration > Datastores. 2. Select a datastore. 3. Right-click the datastore and select Replication Tables. 4. Expand the Available Tables tree to display the tables. 5. Select a table and click Properties to open the Table Properties dialog box. 6. Click the Subscriptions tab. 7. Click Search on the Subscriptions tab. If you do not want a case-sensitive search, clear the Match case box. 8. In the search results, you can identify the subscription from the following: v v v v SubscriptionThe name of the subscription that uses the selected table. Used AsIdentifies whether the table is used as source or target. Replication MethodThe replication method for the selected table. Table StatusIdentifies if the selected table has been refreshed, mirrored, or parked.
59
Setting up subscriptions for datastores outside of your organization

You can add subscriptions that send data to a target datastore that is external to your organization. In order to set up a subscription that sends data to an external target datastore, the receiving organization must have installed Management Console and you need to find out the necessary authentication and database details to connect to their target datastore. External target datastores are not available in your Access Manager because they reside outside of your organization or department, or your System Administrator has not given you the permission to access it. If you have received authorization from the company or organization to which you are replicating data, then you can modify the properties of an external target datastore, including the port number, owner, and password. System and database information about external target datastores is provided by the organization or department that owns that datastore. You can also copy subscriptions that send data to an external target. This is a time saving mechanism. If your organization is at the receiving end of replication activities coordinated with another organization that is outside of your database security policy, then you should see Unknown source datastores in your subscription list. This is because you are receiving replicated data from a source datastore that is outside of your security policy (and, therefore, to which you do not have access to) and the name of the source datastore is not known to you. See also: To add a subscription for an external target datastore To modify a subscription for an external target datastore on page 61
To add a subscription for an external target datastore

1. Ensure that you have the required information to connect to the external target datastore. 2. Click Configuration > Subscriptions. 3. Right-click on a subscription and select New Subscription. 4. Enter the name of the new subscription in the Name box. All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. 5. Enter the description of the new subscription in the Description box. 6. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. 7. Select <External> from the Target list and click Details. 8. Select the operating system from the Platform list.
60
9. Enter the host name or IP address of the external target in the Host Name box. 10. Enter the port number for the external target in the Target Port box. 11. Select the type of database for your external target that holds the InfoSphere CDC metadata from the Database Type list. The metadata tables are created when you install InfoSphere CDC. For more information, see the appropriate InfoSphere CDC End-User Documentation. 12. Enter the name of the metadata database in the Database Name box. 13. Enter the name of the database user that owns the external target metadata in the Owner box. 14. Enter the password for the database user in the Password box. 15. Click OK. 16. If the subscription is sending data to an external target, you can specify a source ID that makes the subscription identifiable for the receiving organization. Click Advanced Settings and enter the source ID in the Source ID box. Related concepts Setting up subscriptions for datastores outside of your organization on page 60 Related tasks To modify a subscription for an external target datastore
To modify a subscription for an external target datastore

1. Ensure that you have the required information to connect to the external target datastore. 2. Click Configuration > Subscriptions. 3. Right-click on a subscription with an external target datastore and select Properties. 4. Click Details and make the necessary changes. Related concepts Setting up subscriptions for datastores outside of your organization on page 60 Related tasks To add a subscription for an external target datastore on page 60
Copying subscriptions
Copying a subscription is a time-saving mechanism. If you have a subscription that contains table mappings that you do not want to recreate, then you can copy the subscription under a new name. You can also recreate an existing subscription with the same table mappings if you want to setup a replication scenario within in another environment. See also: To copy a subscription To copy a subscription for an external target datastore on page 63
To copy a subscription
1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select Copy Subscription. 3. Enter a name for the subscription in the Name box.
61
4. 5.
6. 7. 8.
All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. Enter a description for the subscription in the Description box. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. Click Next. Select the source datastore for the new subscription from the New Source Datastore list. Select the databases and owners for the new source datastore under New Name.
9. If you want to specify advanced settings for the subscription, click Advanced Settings. Modify the following properties and click OK, then click Next. v Source IDSpecify the source ID for the new subscription. v TCP HostSpecify the TCP host that your source datastore will use to recognize the target datastore when the computer where InfoSphere CDC is installed has multiple network cards. This is useful if you want to specify a host that is different from the host that you specified in the Access Manager perspective. The default option is Auto-select, which will automatically select the network card that can communicate with the target datastore. The host that you specified in theAccess Manager perspective also appears by default as well as any alias that you configured in the Datastore Properties dialog box. v Firewall PortSpecify a port number for the new subscription. v Mark subscription as persistentEnable if you want to specify that the subscription is persistent. A subscription can only be restarted automatically if it is enabled for persistency. v Propagation ControlClick Add and select the source ID for any subscription for which you want to prevent data from being replicated to the target. v Do not replicate data received from any subscriptionsEnable if you want to prevent replication from all subscriptions. v Select the datastore to handle the transferable workSpecify where transferable work will be performed, in order to minimize impact on the source or target datastore. 10. Click Next. 11. Select the target datastore for the new subscription from the New Target Datastore list. 12. Select the databases and owners for the new target datastore under New Name. 13. If you want to specify advanced settings for the subscription, click Advanced Settings. Modify the following properties and click OK, then click Next. v Source IDSpecify the source ID for the new subscription. v TCP HostSpecify the TCP host that your source datastore will use to recognize the target datastore when the computer where InfoSphere CDC is
62
v v
v v
installed has multiple network cards. This is useful if you want to specify a host that is different from the host that you specified in the Access Manager perspective. The default option is Auto-select, which will automatically select the network card that can communicate with the target datastore. The host that you specified in theAccess Manager perspective also appears by default as well as any alias that you configured in the Datastore Properties dialog box. Firewall PortSpecify a port number for the new subscription. Mark subscription as persistentEnable if you want to specify that the subscription is persistent. A subscription can only be restarted automatically if it is enabled for persistency. Propagation ControlClick Add and select the source ID for any subscription for which you want to prevent data from being replicated to the target. Do not replicate data received from any subscriptionsEnable if you want to prevent replication from all subscriptions. Select the datastore to handle the transferable workSpecify where transferable work will be performed, in order to minimize impact on the source or target datastore.
14. Click Next. 15. If the existing subscription contains user exits, then specify their location for the new subscription under New Location and click Next. 16. If you built a derived column, an expression, or a row-filtering expression that uses the %SELECT column function, then confirm the list of displayed expressions and click Next. After copying the subscription, you may have to change these expressions manually. 17. Review the list of changes and click Finish. Related concepts Copying subscriptions on page 61 Related reference Retrieve column%SELECT on page 279
To copy a subscription for an external target datastore

1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select Copy Subscription. 3. Enter the name of the new subscription in the Name box. 4. Enter the description of the new subscription in the Description box. 5. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. 6. Click Next. 7. Select the new source datastore for the subscription from the New Source Datastore list. 8. Select the databases and owners for your new source datastore under New Name. 9. Click Next. 10. If you want to specify advanced settings, click Advanced Settings.
63
11. If you want to change the properties of the external target datastore, then make the necessary changes and click Next. 12. Review the list of changes and click Finish. Related concepts Copying subscriptions on page 61
Upgrading existing Transformation Server subscriptions to InfoSphere CDC

If you have existing subscriptions for Transformation Server, then you can upgrade these subscriptions to InfoSphere CDC.
Supported upgrade paths v Transformation Server for Microsoft SQL Server version 5.3.4 to Transformation Server for Microsoft SQL Server version 6.2 to InfoSphere CDC for Microsoft SQL Server version 6.5.1 v Transformation Server for Oracle version 6.0 (Service Pack 3 OR Service Pack 3 TFE 28 or later) to InfoSphere CDC for Oracle databases version 6.5 Supported upgrade combinations When you upgrade a source or target product from Transformation Server to either InfoSphere CDC for Microsoft SQL Server version 6.5.1 or InfoSphere CDC for Oracle databases version 6.5, then the corresponding source or target product can be of any other platform, provided it meets the minimum version requirements: v InfoSphere CDC version 6.3 (any platform) or later v IBM i version 6.1 TFE 1 or later v Transformation Server for z/OS version 5.4 or later Also, when upgrading combinations between Transformation Server for Microsoft SQL Server and Transformation Server for Oracle, whether either of these products is used as a source or a target of replication, you must always upgrade Transformation Server for Microsoft SQL Server to Transformation Server for Microsoft SQL Server version 6.2 before upgrading to InfoSphere CDC for Oracle version 6.5.
When upgrading your subscriptions, ensure that you complete the following tasks: v Ensure that there are no uncommitted transactions to existing subscriptions on the source; otherwise, you will encounter errors while upgrading subscriptions. v Ensure that you quiesce all database activity before upgradingTransformation Server for Oracle to InfoSphere CDC for Oracle databases. v Upgrade subscriptions by selecting new names, new source IDs, and source and target datastores. Note: Transformation Server for Microsoft SQL Server version 5.3.4 supports multiple databases. Transformation Server for Microsoft SQL Server version 6.2 supports a single database. If you are upgrading a subscription that uses multiple databases, such as database1.user.source_table -> database2.user.target_table, ... databaseY.user.target_table you must install Transformation Server for Microsoft SQL Server version 6.2 on database1, database2, ...databaseY to upgrade the subscription. v After upgrading, you must transfer the bookmark from your original subscription to the new upgraded subscription. Or, you can perform a refresh on the upgraded subscription, however you would lose your current position in the log. If you find you need to resort back to your original subscription after the upgrade, then you can transfer the bookmark to the original subscription.
64
v After transferring the bookmark to the new subscription, you can choose to clear the table capture point for the original subscription. This task is optional and will prevent you from resuming replication with the original subscription. This means that you cannot resort back to Transformation Server for replication activities. Therefore, only clear the table capture point on the original subscription when certain you no longer need to replicate with that subscription. If the upgraded subscription is not running as expected and you want to resume mirroring with the original subscription, you must refresh the tables in the original subscription so that the subscription is reset to start from a new capture point. Considerations: v Propagation control settings will not be included in the upgrade. v Notifications are not included in the upgrade. v InfoSphere CDC for Oracle uses the single scrape mechanism, which enables it to only begin replication from one bookmark position. Once you begin replication on a subscription, you cannot set a bookmark position that InfoSphere CDC for Oracle has already passed. For this reason, it is important to note that if you have multiple subscriptions that need to be upgraded, you must upgrade all subscriptions and transfer each of the bookmarks before starting replication on any of these subscriptions. See also: To upgrade a subscription To transfer a bookmark from the original subscription to the upgraded subscription on page 66 To clear the table capture point on the original subscription on page 66
To upgrade a subscription
1. Ensure that you have installed the correct product version to which you want to upgrade. For example, if you are upgrading to InfoSphere CDC for Oracle version 6.5, then you need to install this product in addition to having an existing installation of Transformation Server for Oracle version 6.0 (Service Pack 3 TFE 28 and above). 2. Ensure that you perform the upgrade during a period of time when there is low transaction activity taking place in your database. 3. Ensure that you have created a new datastore for the InfoSphere CDC product to which you want to upgrade. 4. Ensure that the new datastore is associated to the same database that contains the tables being replicated by your existing installation of Transformation Server. 5. Ensure that there are no uncommitted transactions to existing subscriptions on the source; otherwise, you will encounter errors while upgrading subscriptions. 6. Log in to Management Console. 7. Connect to the datastore that is associated with your existing installation of Transformation Server. 8. Connect to the new datastore that is associated with your new installation of InfoSphere CDC. 9. Click Configuration > Subscriptions.
65
10. Select the subscription you want to upgrade to InfoSphere CDC. This subscription contains the same datastore that is associated with your existing installation of Transformation Server. You can select and upgrade more than one subscription at a time. 11. Click Subscription > Upgrade > Upgrade Subscription. 12. Click Continue if you want to upgrade the subscription without assistance from Product Support. 13. Enter a new name for the subscription in the New Name box. 14. Enter a new source ID for the subscription in the New Source ID box. 15. Select a new source datastore for the subscription in the Source Datastore box. 16. Select a new target datastore for the subscription in the Target Datastore box. 17. Click OK. 18. View the report. After upgrading your subscription, Management Console displays an upgrade report that outlines any issues encountered during the upgrade process to InfoSphere CDC. Related tasks To log in to Management Consoleby connecting to Access Server on page 10 To connect to a datastore on page 72
To transfer a bookmark from the original subscription to the upgraded subscription

1. Ensure that you have already upgraded your subscriptions from Transformation Server to InfoSphere CDC. 2. Click Configuration > Subscriptions. 3. Click Subscription > Upgrade > Transfer Bookmark. Management Console displays all subscriptions for which you can transfer the bookmark. 4. Enable the Transfer to New Subscription check box for subscriptions for which you want to transfer the bookmark. 5. To view the upgrade report for the subscription, click View Upgrade Report... . 6. Enable the After transferring bookmark... check box if you want to start mirroring after transferring the bookmark. If you are upgrading subscriptions for InfoSphere CDC for Oracle, then ensure you have upgraded and transferred the bookmarks of all subscriptions before enabling this check box. 7. Click Transfer Bookmark to transfer the bookmark to the specified subscriptions. You can resume mirroring with these subscriptions. After transferring the bookmark, Management Console displays a report that outlines any issues encountered during the bookmark transfer process. Related tasks To upgrade a subscription on page 65 To clear the table capture point on the original subscription
To clear the table capture point on the original subscription

1. Ensure that you have already upgraded your subscriptions from Transformation Server to InfoSphere CDC. 2. Click Configuration > Subscriptions. 3. Click Subscriptions > Upgrade > Clear Table Capture Point.
66
Management Console displays all subscriptions for which you can clear the table capture point. 4. Enable the Clear Log check box for subscriptions for which you want to clear the table capture point. 5. Click Clear Table Capture Point to set the replication method for the specified subscriptions to Refresh. Related tasks To upgrade a subscription on page 65 To transfer a bookmark from the original subscription to the upgraded subscription on page 66
Reverting to Transformation Server

Supported downgrade paths v InfoSphere CDC for Microsoft SQL Server version 6.2 to Transformation Server for Microsoft SQL Server version 5.3.4 v InfoSphere CDC for Oracle databases version 6.5 to Transformation Server for Oracle version 6.0 Service Pack 3 TFE 28 or later
You can revert from InfoSphere CDC to Transformation Server when you want to resume replication activities with the original subscription. If this is the case, then you must ensure that the original subscription has an existing log position and it has not been cleared. Otherwise, you cannot resume replication activities with that subscription unless you perform a refresh on it. In order to continue replication activities from the current log position, you must transfer the bookmark from the upgraded subscription to the original subscription. See also: To downgrade a subscription Related tasks To clear the table capture point on the original subscription on page 66
To downgrade a subscription
1. Ensure you have not cleared the table capture point on the original subscription. 2. Click Configuration > Subscriptions. 3. Click Subscription > Upgrade > Transfer Bookmark. Management Console displays all subscriptions for which you can transfer the bookmark. 4. Enable the Transfer to Original Subscription check box for subscriptions for which you want to transfer the bookmark. 5. To view the upgrade report for the subscription, click View Upgrade Report... . 6. Enable the After transferring bookmark... check box if you want to start mirroring after transferring the bookmark. If you are upgrading subscriptions for InfoSphere CDC for Oracle, then ensure you have transferred the bookmarks of all subscriptions before enabling this check box. 7. Click Transfer Bookmark to transfer the bookmark to the specified subscriptions. You can resume mirroring with these subscriptions.
67
After transferring the bookmark, Management Console displays a report that outlines any issues encountered during the bookmark transfer process. This report is displayed whether or not errors are encountered during the transfer bookmark process. Related concepts Reverting to Transformation Server on page 67
Using projects to organize your subscriptions

Projects let you group your subscriptions into categories to reflect your organizational or operational needs. Organizational Approach for ProjectsThe organizational approach is useful if you want to group your subscriptions according to their current state of development. In many working environments, organizations prefer to test an InfoSphere CDC replication configuration before promoting the configuration to a production environment. If you have subscriptions that are still in development, others that are being tested, and some that have been promoted to production, you may want to group your subscriptions in projects according to their current development state. For example, you can use Test, Development, and Production for project names. As you finish development or testing of a subscription, you can then move the subscription to the appropriate project. Operational Approach for ProjectsThe operational approach is useful if you are creating subscriptions that relate to particular departments or operations within your organization. For example, you may have subscriptions that relate to human resources, finance, or sales. In this case, you may want to organize your subscriptions into projects that reflect these particular operations or departments. See also: To add a project To rename a project To delete a project on page 69
To add a project
1. Click Configuration > Subscriptions. 2. Right-click in the Subscriptions view and select Project > Add New Project. 3. Enter a unique name for your project. Related concepts Using projects to organize your subscriptions Related tasks To rename a project To delete a project on page 69
To rename a project
1. Click Configuration > Subscriptions. 2. Right-click on a project and select Project > Rename Project. 3. Enter a new name for your project.
68
Related concepts Using projects to organize your subscriptions on page 68 Related tasks To add a project on page 68 To delete a project
To delete a project
1. Click Configuration > Subscriptions. 2. Right-click on a project and select Project > Delete Project. Management Console will delete the project and move all subscriptions to your Default project. Related concepts Using projects to organize your subscriptions on page 68 Related tasks To rename a project on page 68 To add a project on page 68
Exporting and importing projects

Every user of Management Console will have a different approach to organizing their projects and subscriptions. To share your project organization with other users, you can export your projects to a CSV template on your local computer. Other users can then import the CSV template into Management Console. See also: To export projects To import projects
To export projects
1. Click Configuration > Subscriptions. 2. Right-click on a project and select Project > Export Projects. 3. Enter a name for the template in the File Name box. 4. Click Save. Related concepts Exporting and importing projects Related tasks To import projects
To import projects
1. Click Configuration > Subscriptions. 2. Right-click on a project and select Project > Import Projects. Existing projects will be deleted during project import. 3. Select the CSV template that you want to import into Management Console and click Open. You will have to restart Management Console or reconnect to Access Server to see the changes.
69
Related concepts Exporting and importing projects on page 69 Related tasks To export projects on page 69
70
Setting up datastores for replication

Datastores are logical entities that represent the data files and processes required to accomplish data replication. Each datastore represents the database or target destination to which you want to connect. Tables made available for replication are contained in a datastore. Depending on the database platform on which you have installed InfoSphere CDC, you can connect to datastores on several different platforms, including DB2 for i, DB2 for z/OS, DB2 for LUW, IBM InfoSphere DataStage, solidDB, and Informix Dynamic Server, Microsoft SQL Server, Oracle databases, Sybase databases, Teradata, and InfoSphere CDC Event Server. In this section, you will learn: Understanding the Datastores view Connecting to a datastore on page 72 Shutting down a datastore on page 73 Updating access parameters for a subscription on page 73 Setting system parameters on source and target datastores on page 73 Creating aliases for a target datastore on a private network connection on page 74 Handling a changed host name or port information for a datastore on page 75
Understanding the Datastores view

The Datastores view is located in the Configuration perspective in Management Console. The functionality options and what the Datastores view looks like to a user depends on that user's role. A user must have a role of System Administrator, Administrator, or Operator in order to see this view. Note that users with the Monitor role can connect to datastores to which they have access using the Connect to datastore button located above the Subscriptions view of the Monitoring perspective, even though they cannot see the Datastores view. Depending on the role that your user ID has, you can do the following in this view:
Functions Connect to datastores Roles v System Administrator v Administrator v Operator v Monitor Configure notifications on source or target datastores v System Administrator v Administrator v Operator Configure properties on datastores v System Administrator v Administrator (can configure properties except for system parameters)
71
Functions View, create or modify replication tables
Roles v System Administrator v Administrator
Related concepts Logging in to Management Console by connecting to Access Server on page 10 Setting up datastores for replication on page 71
Connecting to a datastore
Before you can connect to a datastore, you must have user access to a datastore. If you do not see a datastore listed, request your System Administrator to set access parameters for you in the Access Manager perspective in Management Console. By default, Management Console connects to all datastores that you have access to when you log in to Management Console by connecting to Access Server. You can turn off this behavior in Edit > Preferences. If the Connect to Datastores Automatically preference is disabled, you must manually connect to each datastore. To see whether or not you are connected to a datastore, use the Datastores view. To see a summary of your datastore connection status, refer to the bottom right section of Management Console. This section shows the number of connections established. If Management Console cannot establish a connection with a particular . Click the icon to datastore, then this datastore is listed with the following icon: view general information about the datastore and possible reasons as to why a connection could not be established. See also: To connect to a datastore To disconnect from a datastore
To connect to a datastore
1. 2. 3. 4. Ensure that you have user access to the datastore. Click File > Connect to Datastores. Select the datastore. Click Connect.
Related concepts Assigning users to datastores on page 40
To disconnect from a datastore

1. Ensure that you have user access to the datastore 2. Click Configuration > Datastores. 3. Select the datastore. 4. Click File > Datastore > Disconnect.
72
Related concepts Assigning users to datastores on page 40
Shutting down a datastore

Note: This information does not apply to InfoSphere CDC for z/OS datastores. When you want to end all replication processes for an InfoSphere CDC replication engine to perform database or operating system maintenance activities, you must shut down the associated datastore in Management Console. This ends replication on all active subscriptions. You can also use the command-line tools that are available with your InfoSphere CDC replication engine to end all replication processes. See also: To shut down a datastore
To shut down a datastore

1. Click Configuration > Datastores. 2. Right-click on a datastore and select Shut down datastore.
Updating access parameters for a subscription

When configuring a datastore in Access Manager, you must specify the access parameters that InfoSphere CDC uses to connect to the database. Access parameters include information such as a user ID, password, host name, and port. If at some point you decide to change access parameters for a datastore, then you need to update each subscription that uses this datastore as a target in Management Console. See also: To update access parameters for a subscription
To update access parameters for a subscription

1. Click Configuration > Datastores. 2. Right-click on a datastore and select Properties. 3. Click General. 4. Click Update Related Subscriptions. 5. If there are any active subscriptions, click End Replication on each active subscription. 6. Click Update. 7. Restart Management Console.
Setting system parameters on source and target datastores

You can add, modify, or delete system parameters for datastores. System parameters let you customize the behavior of InfoSphere CDC in your replication environment. You can specify system parameters in Management Console or modify system parameters on the replication servers by performing
73
server-dependent operations. When you change the value of a system parameter for a particular source or target datastore, all users that have access to that datastore will see the change as well. The default values for most system parameters should be adequate. However, depending on your requirements, you can modify the a system parameter to specify a behavior for InfoSphere CDC that is different than the default. See also: To add a system parameter To modify a system parameter To delete a system parameter
To add a system parameter

1. Click Configuration > Datastores. 2. Right-click on a datastore and select Properties. 3. Click Add on the System Parameters tab. 4. Enter the name of the parameter in the Parameter Name box. 5. Enter the value in the Value box. 6. Click OK. Related concepts Setting system parameters on source and target datastores on page 73
To modify a system parameter

1. Click Configuration > Datastores. 2. Right-click on a datastore and select Properties. 3. Select a system parameter on the System Parameters tab. 4. Click Modify. 5. Enter a value in the Value box. 6. Click OK. Related concepts Setting system parameters on source and target datastores on page 73
To delete a system parameter

1. Click Configuration > Datastores. 2. Right-click on a datastore and select Properties. 3. Select a system parameter on the System Parameters tab. 4. Click Delete. Related concepts Setting system parameters on source and target datastores on page 73
Creating aliases for a target datastore on a private network connection

The Access Manager perspective uses the host name or the IP address you specified to connect to your target datastore. If you want to create a subscription that replicates data to a target datastore on a private network connection, then you need to identify the name your source datastore uses to recognize that target datastore. Depending on your environment, this could be a host name, IP address, Data Source Name (DSN), etc. You can identify this name by creating an alias in
74
Management Console. For more information on how to set up connection parameters to connect to a datastore, see To set connection parameters on a datastore on page 37. See also: To add an alias To modify an alias To delete an alias
To add an alias
1. Click Configuration > Datastores. 2. Right-click on a datastore and select Properties. 3. Click Add on the Alias tab. 4. Enter a name in the Alias box. Related concepts Creating aliases for a target datastore on a private network connection on page 74
To modify an alias
1. Click Configuration > Datastores. 2. Right-click on a datastore and select Properties. 3. Select an alias on the Alias tab. 4. Click Modify. 5. Enter a name in the Alias box. Related concepts Creating aliases for a target datastore on a private network connection on page 74
To delete an alias
1. Click Configuration > Datastores. 2. Right-click on a datastore and select Properties. 3. Select an alias on the Alias tab. 4. Click Delete. Related concepts Creating aliases for a target datastore on a private network connection on page 74
Handling a changed host name or port information for a datastore

If you have changed the host name or port for a datastore, you need to ensure the existing subscriptions associated with the datastore can map to the new datastore configuration information. There are two scenarios: v A change the to host name or port for a datastore used as the source in a subscriptionExisting subscriptions for the datastore must map appropriately to the new host name or port, or you may not be able to connect to the datastore or replicate data to the target datastore. The source subscription configuration can optionally identify the host name that is used to select the network interface
75
used by InfoSphere CDC. When you change the host name for the source machine and update the datastore definition in Access Manager, the subscription itself may still reference the old host name or port. To resolve this, change the source subscriptions so that the datastore is associated with the new host name and port. v A change to the host name or port for a datastore used as the target in a subscriptionAfter you change datastore information, and update the datastore definition in Access Manager, you may see duplicate subscriptions in the Subscriptions view. One subscription identifies the target datastore with the old host name and port; the other subscription displays the source datastore as unknown and the correct target datastore. The source component of the subscription stores the host name and port for the target so that the source and target can communicate. When you change the host name or port for the datastore, existing subscriptions will continue to reference the old host name or port. To resolve this, change the target subscriptions so that the datastore is associated with the new host name and port. See also: To update host name and port changes for source datastores and associated subscriptions To update host name and port changes for target datastores and associated subscriptions on page 77
To update host name and port changes for source datastores and associated subscriptions
1. Restart Access Server to ensure there are no users logged in. 2. Start Management Console and log into Access Server. Note: If you use the auto-connect feature for connecting to datastores, turn it off by clicking Edit > Preferences > Connect, and disabling Connect to Datastores Automatically prior to connecting to Access Server. 3. Click Access Manager > Datastore Management. 4. Right-click the datastore and select Properties. 5. Update the Host Name and Port fields for the datastore. 6. Click OK. 7. 8. 9. 10. 11. 12. 13. 14. 15. Click File > Access Server > Disconnect to log off Access Server. Click File > Access Server > Connect and log back into Access Server. Click Configuration > Datastores. Connect to the source datastore by right-click it and selecting Connect. Right-click the subscription from the Subscriptions perspective, and select Properties. Click Advanced Settings. Verify that the value in the TCP Host field. If it identifies the old host name, select Auto-Select and then click OK. Click OK. If this datastore is also the target for subscriptions, follow the steps to update related subscriptions in To update host name and port changes for target datastores and associated subscriptions on page 77.
76
To update host name and port changes for target datastores and associated subscriptions
1. Restart Access Server to ensure there are no users logged in. 2. Start Management Console and log into Access Server. Note: If you use the auto-connect feature for connecting to datastores, turn it off by clicking Edit > Preferences > Connect, and disabling Connect to Datastores Automatically prior to connecting to Access Server. Click Access Manager > Datastore Management. Right-click the datastore and select Properties. Update the Host Name and Port fields for the datastore. Click OK. Click File > Access Server > Disconnect to log off Access Server. Click File > Access Server > Connect and log back into Access Server. Click Configuration > Datastores. Connect to the datastore and to all datastores that have subscriptions where this datastore is the target, by right-clicking the target datastores and selecting Connect.
3. 4. 5. 6. 7. 8. 9. 10.
11. Right-click the datastore you updated above from the Datastores perspective, and select Properties. 12. Click Update Related Subscriptions and complete the steps to update the subscriptions where this datastore is the target. 13. If this datastore is also the source for subscriptions, follow the steps to update related subscriptions in To update host name and port changes for source datastores and associated subscriptions on page 76.
77
78
Managing tables available for replication

You can view the tables that are available for replication, update the definition of the table if you have changed the structure of the table in your database, and remove any tables from replication in Management Console. In this section, you will learn: Updating, removing, and viewing tables for replication Updating the definition of a mapped source and target table in a subscription on page 80
Updating, removing, and viewing tables for replication

When you map tables, the tables are added to the set of tables available for replication. If you have changed the definition of either a source or target table in your RDBMS (relational database management system), you will need to update its definition in Management Console. If you have deleted tables from your RDBMS (relational database management system), then you also need to remove the table from replication. Use the Replication Tables dialog box to update the definition of a table that has changed in your database, to view the properties of tables, and to remove tables no longer in use by subscriptions for replication. You can make tables available for replication by selecting tables for a table mapping in the Map Tables wizard. See also: To update the definition of a table To remove a table from Management Console on page 80 To view the properties of a table on page 80
To update the definition of a table

1. 2. 3. 4. Click Configuration > Datastores. Select a datastore. Right-click and select Replication Tables. Expand the database user or schema until you display its tables. Tables are only available if you have created a table mapping in the Map Tables wizard. 5. Select the table that has changed in your relational database management system and click Update. The status of the table mapping will change to Parked.
79
Related concepts Updating, removing, and viewing tables for replication on page 79
To remove a table from Management Console

1. Ensure that there are no subscriptions using the tables in replication. Delete any table mappings, if necessary. 2. Click Configuration > Datastores. 3. Select a datastore. 4. Right-click and select Replication Tables. 5. Expand the database user or schema until you display its tables. Tables are only available if you have created a table mapping in the Map Tables wizard. 6. Select the table and click Remove. Related concepts Searching for tables used in replication on page 59 Updating, removing, and viewing tables for replication on page 79 Related tasks To delete a table mapping on page 133
To view the properties of a table

1. Click Configuration > Datastores. 2. Select a datastore. 3. Right-click and select Replication Tables. 4. Expand the database user or schema until you display its tables. Tables are only available if you have created a table mapping in the Map Tables wizard. 5. Select the table and click Properties. Related concepts Updating, removing, and viewing tables for replication on page 79
Updating the definition of a mapped source and target table in a subscription

Once you change the structure of a mapped source or target table in your database, you must update the definition of the table in Management Console so that subscriptions are aware of the new structure. v Updating the definition of a source tableIf you change the definition of a source table (add a new column, set column constraints, or new foreign key dependencies) in your database, then you have to update the definition of the table in Management Console. Management Console requires you to update the source table so that the new structure is available for configuration when editing your table mapping details. For example, if you have added a new column on the source table, then you may want to map this new column to a target column. v Updating the definition of a target tableIf you change the definition of a target table (add a new column, set column constraints, or new foreign key dependencies) in your database, then you need to update the definition of the target table in Management Console. Management Console requires you to update the target table so that the new structure is available for configuration
80
when editing your table mapping details. For example, if you have added a new column on the target table, then you may want to map a source column to the target column. See also: To update the definition of a source table To update the definition of a target table
To update the definition of a source table

1. 2. 3. 4. Click Configuration > Subscriptions. Select the subscription that contains the mapped source and target tables. Select and right-click on the table mapping in the Table Mappings area. Select Update Table Definition > Source Table.
5. Select each active subscription and click End Replication. 6. Select Update metadata definition of table, if you want the source catalog updated with the current definition of the source table selected. 7. Select Describe, if you want the source database to send its definition of the table to the target. By default, this option is selected. 8. Select Reassign, if you want to reassign the current target table with the definition in the source table. By default, this option is selected. 9. Click Update. The status of the table mapping is changed to Parked. 10. Verify your mapping details. If you have added a new column and you want InfoSphere CDC to replicate data from this column, then you need to map that column to the target. 11. If you want to restart mirroring on the subscription, you need to synchronize your source and target tables so that InfoSphere CDC can set a log position. Related concepts Flagging a source table for refresh on page 343 Updating the definition of a mapped source and target table in a subscription on page 80 Mapping source columns to target columns on page 173
To update the definition of a target table

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Select and right-click on the table mapping in the Table Mappings area. 4. Select Update Table Definition > Target Table. 5. Click End Replication on each active subscription. 6. Click Update. 7. Verify your table mapping details. If you have added a new column to your target table and you want InfoSphere CDC to replicate data to the column, then you need to map a source column to the new target column. Related concepts Mapping source columns to target columns on page 173 Updating the definition of a mapped source and target table in a subscription on page 80
Managing tables available for replication
81
82
Mapping tables
After defining a subscription in Management Console, use the Map Tables wizard to map source and target tables. Subscriptions can contain as many table mappings as necessary. The number of table mappings you create depends on how many source tables you want InfoSphere CDC to replicate to the target system. In this section, you will learn: Table Mappings view Understanding filtering and mapping tables on page 86 Mapping using standard replication on page 87 Mapping using LiveAudit on page 95 Mapping using Adaptive Apply on page 100 Mapping to summarize data on page 105 Mapping to consolidate data (one-to-one) on page 108 Mapping to consolidate data (one-to-many) on page 111 Mapping to a datastore outside of your organization on page 116 Mapping using InfoSphere DataStage on page 117 Generating an InfoSphere DataStage definition file for a subscription on page 121 Mapping to a JMS Message Destination using InfoSphere CDC Event Server on page 123 Remapping a source table on page 130 Copying selected table mappings on page 131 Deleting table mappings on page 133 Exporting and importing subscriptions and selected table mappings on page 134 Modifying table mappings on page 135
Table Mappings view

After defining a subscription in Management Console, you can use the Map Tables wizard to map source and target tables. Subscriptions can contain as many table mappings as necessary, and the number of table mappings you create depends on how many source tables you want InfoSphere CDC to replicate to the target system. The table mappings that you create with the wizard are displayed in this view, and when you select a subscription with table mappings, the table mappings are loaded into the view. Use the Table Mappings view to see a list of mapped source and target tables within a subscription. You can also view the mapping type, replication method, and status of each table mapping. In this view, you can perform the following actions: v View a list of mapped source and target tables within a subscription v View a list of defined rule sets for use with DDL replication (InfoSphere CDC for Oracle version 6.5.1 only) v View the mapping type, replication method, and status of each table mapping
83
v v v v v
Change the replication method of a table mapping Flag a source table for refresh before mirroring Mark a table capture point on a source table Park a table mapping from replication Change the refresh order on a table mapping
v Customize the kind of information you want to map to target columns in a subscription. v Include or exclude rows or columns for replication. v Add, modify, and delete a data translation. v Specify how InfoSphere CDC converts character sets on source and target columns during replication. v Set how a target table responds to changes made on the source table. v Control the truncation of the target table in response to a table-level clear or refresh operation so that all or some of the rows are preserved. v Set member identifiers for multi-member source tables. v Configure conflict detection and resolution. v Configure user exits. If you are mapping tables with both the source and target datastores of InfoSphere CDC for Oracle databases version 6.5.1, you are able to replicate DDL changes. The Table Mappings view will then have two displays: Direct Mappings and Rules. The Direct Mappings display will show the mappings created using the Map Tables wizard. The Rules display will show all rule sets defined for the selected subscription. For more information on replicating DDL changes and defining rule sets, see Replicating Data Definition Language (DDL) changes on page 137 At the bottom of the Tables Mapping view, the Details area will display information about either the selected table mapping or selected rule. This information can be viewed by double-clicking on either the table mapping or the rule set name. If a rule set has been selected, the Details area will display the details of the rule set. If a table mapping has been selected, a number of tabs containing mapping information details are available. The specific tabs that are loaded for display will differ depending on which databases and which version of corresponding InfoSphere CDC agents on the source and target systems for the selected table mapping. The following list contains descriptions for each of these tabs: v Column MappingsUse the Column Mappings tab to perform the following tasks: map source columns to target columns create a derived column on the source table build custom expressions and map to target columns map accumulation and deduction expressions for summarization mapping types map journal control fields map source and target columns automatically v FilteringUse the Filtering tab to perform the following tasks: define a row-filtering expression to include or exclude rows from replication
84
filter columns enable critical column selection v TranslationUse the Translation tab in InfoSphere CDC version 6.3, and earlier, to perform the following tasks: set translations set translation conversions set multibyte character encoding conversions (this is a new feature and only available in specific platforms and versions of InfoSphere CDC) v EncodingUse the Encoding tab in InfoSphere CDC version 6.5, and later, to perform the following tasks: set encodings set encoding conversions set multibyte character encoding conversions (this is a new feature and only available in specific platforms and versions of InfoSphere CDC) v ConflictsUse the Conflicts tab when you want InfoSphere CDC to detect conflicts on target columns and resolve them: source row wins target row wins largest value wins smallest value wins user exits
v OperationsUse the Operation tab to specify the row-level or table-level operations you want InfoSphere CDC to apply on a target table when there is a corresponding row-level or table-level operation on the source table. If you do not want InfoSphere CDC to detect conflicts on target columns, then you can select None. v User ExitsUse the User Exit tab when you want InfoSphere CDC to detect conflicts on target columns and resolve them. You can perform the following tasks: identify the name and type of user exit you want InfoSphere CDC to call specify at which event or action you want InfoSphere CDC to call the user exit (either before or after a row-level or table-level operation) v Flat FileAppears if you have an InfoSphere DataStage subscription that was created using the flat file method. It includes the following information: LocationSpecifies the location of the directory for output of the flat files. Record FormatSpecifies the format of the records to be generated. Custom Data FormatSpecifies the name of the Java class used, if any, to format the data. v Direct ConnectAppears if you have an InfoSphere DataStage subscription that was created using the direct connect method. It includes the following information: Record FormatSpecifies the format of the records to be generated. Custom Data FormatSpecifies the name of the Java class used, if any, to format the data. If you have been viewing multiple table mappings or rule sets, you can use the Recent Mappings list box to return to a previously selected item.
Mapping tables
85
Related concepts Setting up and configuring subscriptions on page 49 Mapping tables on page 83 Mapping columns on page 173 Filtering rows and columns on page 315 Setting data translations on column mappings on page 183 Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187 Controlling row operations on page 327 Controlling table operations on page 213 Setting member identifiers on page 195 Setting conflict detection and resolution on page 319 Configuring table-level user exits on page 219
Understanding filtering and mapping tables

Using filtering optimizes system performance and enables you to navigate more efficiently if you have a large number of nodes (databases, schemas, libraries, or tables) to navigate. Depending on your InfoSphere CDC replication platform, and the Minimum Number threshold value specified for filtering in Edit > Preferences > Prompts > Filtering, the Filter Databases, Filter Schemas, Filter Libraries, or Filter Tables dialog box opens when you expand a datastore, database, or schema respectively when mapping tables. The Filter Databases window can appear for the two replication platforms that can contain multiple databases: InfoSphere CDC for z/OS and version 5.3 of Transformation Server for Microsoft SQL Server. For other replication platforms that contain single database instances, the Filter Schemas window (for Oracle) or Filter Libraries window (for IBM i ) can open, and Filter Tables dialog boxes can open when you expand the respective nodes under a datastore. See also: To manually define a filter Related concepts Setting advanced preferences on page 15
To manually define a filter

1. Select the node (datastore, database, or schema) and click Specify Filter. Depending on your InfoSphere CDC replication platform, and the Minimum Number value specified for filtering in Edit > Preferences > Advanced > Filtering, the Filter Databases, Filter Schemas, or Filter Tables dialog box opens when you expand a datastore, database, or schema respectively. 2. Select a method of filtering: v Select Show all schemas or Show all tables to v Select Show filtered schemas or Show filtered tables, then you can Click Import to load a previously exported set of filtering criteria, or
86
Manually enter the filtering variables you want to use in the provided field and click Export to save the criteria in a .txt file 3. Click OK.
Mapping using standard replication

If you want your target table to keep an updated image of the data contained in the source table, then map your source and target tables using standard replication. Your source and target tables can be of different types and you can transform the data that you replicate between the source and the target. Under standard replication, InfoSphere CDC applies the same operation that occurred on the source table to the target table. A row insert operation on the source table determines a row insert operation on the target table, and so on. You can map tables one at a time using standard replication. Management Console provides two mechanisms for mapping: v Multiple one-to-one table mappingsMap tables using one-to-one replication when you want to map multiple source tables to multiple target tables at a time and these tables share the same table structure and similar table names. The Map Tables wizard automatically maps tables based on an example mapping you set up. v Custom table mappingsMap tables using custom replication when you want to map only one source table to one target table at a time. Use custom table mappings when you need more control over the way the table is mapped. For example, use custom mappings for tables that do not share the same table structure or similar table names, for mappings where you need to filter out columns for a particular table, or for tables where you want to pick a particular index. See also: To map multiple source tables using standard replication To map multi-member tables to existing tables on IBM i using standard replication on page 89 To map multi-member tables to new tables on IBM i using standard replication on page 90 To map multiple source tables for InfoSphere Classic CDC for z/OS using standard replication on page 91 To map a single source table using standard replication on page 92 To map a single multi-member source table on IBM i using standard replication on page 94
To map multiple source tables using standard replication

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Multiple One-to-One Mappings > Standard and click Next. 4. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For
Mapping tables
87
more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Select Map to existing target tables and click Next. If you want to map to a new target table, click Create new target tables. 9. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. The wizard uses the relationship between this target table and the selected source table to map the remaining source and target tables. You can click Change Example Table if you want the Map Tables wizard to base the mapping on a different source table. This option is only available if you have selected more than one source table. 10. Enable a table to map from the Target Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 11. Click Next. 12. Verify the mappings in the Complete Mappings dialog, and click Next. Note: The Map Tables wizard may leave some source tables unmapped if it did not find a target table that shared the same table structure or similar column names. You must map these manually. 13. If you are replicating source database changes using InfoSphere CDC for Oracle Trigger-based edition and you want to use a journal table to mirror database operations from the source table to the target table, then choose one of the following and click Next: v Use Default JournalEnable when you want InfoSphere CDC for Oracle to use the default journal table provided with InfoSphere CDC for Oracle: <TS SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and replicate database changes from the source to the target. v Use Selected JournalEnable when you want InfoSphere CDC for Oracle to use another journal table other than the default journal table provided with InfoSphere CDC for Oracle. When you select the database owner and provide a name for the journal table, InfoSphere CDC Event Server creates this new journal table and uses it to detect and replicate database changes from the source to the target. OwnerLists the database owner of the journal table. NameLists the name of the journal table. 14. Review the mapping summary and click Finish.
88
Related tasks To map a single source table using standard replication on page 92 To map a single multi-member source table on IBM i using standard replication on page 94 To map multi-member tables to existing tables on IBM i using standard replication To map multi-member tables to new tables on IBM i using standard replication on page 90
To map multi-member tables to existing tables on IBM i using standard replication

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Multiple One-to-One Mappings > Standard and click Next.. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter.
5. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 6. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Select Map to existing target tables and click Next. 10. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. The wizard uses the relationship between this target table and the selected source table to map the remaining source and target tables. You can click Change Example Table if you want the Map Tables wizard to base the mapping on a different source table. This option is only available if you have selected more than one source table. 11. Select the target table from the Target Table list and click Next. If any of the mappings are incorrect, you can click the assigned target table and pick another target table from the displayed list. If you have not chosen similar tables, you can select target tables individually by clicking on the target list beside the source table you want to map. 12. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent
Mapping tables
89
recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN). This option is only available when you have installed InfoSphere CDC for DB2 for i on the source database. 13. Click Next. 14. Review the mapping summary and click Finish. Related concepts Mapping using standard replication on page 87 Setting member identifiers for multi-member source tables on page 195
To map multi-member tables to new tables on IBM i using standard replication

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Multiple One-to-One Mappings > Standard and click Next.. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. Click Next. Select Create New Target Tables and click Next.
5.
6.
7. 8.
90
9. Click in the Target Library column, select a target owner, and click Next. 10. Choose from the following options and click Next: v Identical to the source table namesNames the new target tables the same name as the source tables. v Source table names with prefixes and/or suffixesAdds the suffix, the prefix, or both, to the source table name. Enable the Use prefix/suffix for index name check box to use the prefix and suffix as the index name. 11. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN). This option is only available when you have installed InfoSphere CDC for DB2 for i on the source database. 12. Review the mapping summary and click Finish. Related concepts Mapping using standard replication on page 87 Setting member identifiers for multi-member source tables on page 195
To map multiple source tables for InfoSphere Classic CDC for z/OS using standard replication
1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Multiple One-to-One Mappings > Standard and click Next. 4. Expand the Source Tables list to view the IMS tables from your InfoSphere Classic CDC for z/OS datastore that are available for mapping. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For
Mapping tables
91
more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Select Map to existing target tables and click Next. If you want to map to a new target table, click Create new target tables. 9. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. The wizard uses the relationship between this target table and the selected source table to map the remaining source and target tables. You can click Change Example Table if you want the Map Tables wizard to base the mapping on a different source table. This option is only available if you have selected more than one source table. 10. Enable a table to map from the Target Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 11. Click Next. 12. Verify the mappings in the Complete Mappings dialog, and click Next. Note: The Map Tables wizard may leave some source tables unmapped if it did not find a target table that shared the same table structure or similar column names. You must map these manually. 13. Review the mapping summary and click Finish.
To map a single source table using standard replication

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Custom Table Mapping > Standard and click Next. 4. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed.
92
If you want to map to a new target table, click Create Table. 9. Choose one of the following and click Next: v Use an IndexSelect the index (or constraint if you are mapping to target columns on a Netezza database where InfoSphere CDC for Netezza databases has been installed) name from the box or select <Auto Detect> if you want InfoSphere CDC to automatically choose the index or constraint. Use if your target table has an index or a constraint that uniquely identifies a row. v Use all searchable columnsSearches all target columns to identify which columns are suitable to uniquely identify rows. The results of the search are used to build a WHERE clause which uniquely identifies the row on the target column to apply data. v Specify the keySelect the target columns from the Key Columns list. Use if one or more target columns uniquely identifies a row. 10. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. 11. If you are replicating source database changes using InfoSphere CDC for Oracle databases (trigger) and want to use a journal table to mirror database operations from the source to the target table, then enable one of the following: v Use Default JournalEnable when you want InfoSphere CDC for Oracle databases to use the default journal table provided with InfoSphere CDC for Oracle databases: <TS SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and replicate database changes from the source to the target. v Use Selected JournalEnable when you want InfoSphere CDC for Oracle databases to use another journal table other than the default journal table provided with InfoSphere CDC for Oracle databases. When you select the database owner and provide a name for the journal table, InfoSphere CDC for Oracle databases creates this new journal table and uses it to detect and replicate database changes from the source to the target. OwnerLists the database owner of the journal table. NameLists the name of the journal table. 12. If you have configured bidirectional replication, then enable the Prevent Recursion check box. This prevents InfoSphere CDC from replicating changes back to the source database when you have configured a subscription for bidirectional replication. This is only available in versions of InfoSphere CDC that support both source and target databases. Contact IBM Technical Support to implement bidirectional replication in your environment. 13. Click Next. 14. Review the mapping summary. 15. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping.
Mapping tables
93
v Return to current viewReturns you to the current view. Related concepts Mapping using standard replication on page 87 Setting member identifiers for multi-member source tables on page 195
To map a single multi-member source table on IBM i using standard replication

1. 2. 3. 4. 5. Ensure that InfoSphere CDC for IBM i is installed on both source and target. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Custom Table Mapping > Standard and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 6. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh.
7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 10. Select a table from the Target Table list. If you do not see your table listed, select the database user or schema and click Refresh. Choose one of the following options and click Next: v Source and Target Files are Single MemberMerges all members from the source table to a single-member target table. v Use Source member Structure on TargetMaintains the same multi-member structure on the target table as the one on the source table. Each source member is mapped to the corresponding target member. v Merge Source Members into One Target MemberMerges all members from the source table to a single member in a multi-member. 11. Choose one of the following and click Next: v Use an IndexSelect the index (or constraint if you are mapping to target columns on a Netezza database where InfoSphere CDC for Netezza databases has been installed) name from the box or select <Auto Detect> if you want InfoSphere CDC to automatically choose the index or constraint. Use if your target table has an index or a constraint that uniquely identifies a row. v Use all searchable columnsSearches all target columns to identify which columns are suitable to uniquely identify rows. The results of the search are used to build a WHERE clause which uniquely identifies the row on the target column to apply data.
94
v Specify the keySelect the target columns from the Key Columns list. Use if one or more target columns uniquely identifies a row. 12. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN). This option is only available when you have installed InfoSphere CDC for DB2 for i on the source database. 13. Review the mapping summary. 14. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping using standard replication on page 87 Setting member identifiers for multi-member source tables on page 195
Mapping using LiveAudit

If you want your target table to keep an audit trail of operations applied to the source table, then use the Map Tables wizard to map your source and target tables using LiveAudit. When you replicate data using LiveAudit, your target tables contain rows that track insert, update, delete, and clear (truncate) operations applied to the mapped source table. LiveAudit is most useful if your environment must satisfy data auditing and change-tracking requirements. With LiveAudit, you can audit changes to sensitive information, and you can monitor and report on risk in a timely manner. The following table summarizes how row-level operations are replicated to the target datastore when you map your tables for LiveAudit.
Mapping tables
95
Source operations INSERT UPDATE (Key not changed)
Target Operations INSERTs the new row that was added. Either: v INSERT the row that contains the after image. v INSERT row containing before image values, and INSERT another row containing after image values.
UPDATE (Key changed)
Either: v INSERT the row that contains the after image. v INSERT row containing before image values, and INSERT another row containing after image values.
DELETE
INSERTs the row that was deleted.
Management Console provides two mechanisms for mapping: v Multiple one-to-one table mappingsMap tables using one-to-one replication when you want to map multiple source tables to multiple target tables at a time and these tables share the same table structure and similar table names. The Map Tables wizard automatically maps tables based on an example mapping you set up. v Custom table mappingsMap tables using custom replication when you want to map only one source table to one target table at a time. Use custom table mappings when you need more control over the way the table is mapped. For example, use custom mappings for tables that do not share the same table structure or similar table names, for mappings where you need to filter out columns for a particular table, or for tables where you want to pick a particular index. Note: For mappings with extra journal control fields in LiveAudit, use custom table mappings. See also: To map multiple source tables to existing tables using LiveAudit To map multiple source tables to new tables using LiveAudit on page 97 To map a single source table using LiveAudit on page 98 To map a single multi-member source table using LiveAudit for IBM i on page 99
To map multiple source tables to existing tables using LiveAudit

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Multiple One-to-One Mappings > LiveAudit and click Next. Review the following audit columns. You can choose to add, modify, or delete audit columns to the target table. Click Next: v AudTimeStores the &TIMSTAMP journal control field which indicates date and time changes are made to the source.
96
5.
6.
7.
8. 9. 10.
11.
v AudTypeStores the &ENTTYP journal control field which indicates the type of change made to the source. v AudUserStores the &USER journal control field which indicates the ID of the user who made the change to the source. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. Click Next. Select Map to existing target tables and click Next. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. Verify that the correct target table is mapped to the source tables and click Next. If any of the mappings are incorrect, you can click the assigned target table and pick another target table from the displayed list. If you have not chosen similar tables, you can select target tables individually by clicking on the target list beside the source table you want to map.
12. Review the mapping summary and click Finish. InfoSphere CDC inserts a row into the target table for every row-level operation (insert, update, or delete) applied to a row in the source table. The target table can become extremely large. Ensure that you allow sufficient disk space and perform regular maintenance for target tables that audit data. Related concepts Mapping using LiveAudit on page 95
To map multiple source tables to new tables using LiveAudit

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Multiple One-to-One Mappings > LiveAudit and click Next. 4. Review the following audit columns. You can choose to add, modify, or delete audit columns to the target table. Click Next: v AudTimeStores the &TIMSTAMP journal control field which indicates date and time changes are made to the source. v AudTypeStores the &ENTTYP journal control field which indicates the type of change made to the source. v AudUserStores the &USER journal control field which indicates the ID of the user who made the change to the source.
Mapping tables
97
5. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. Click Next. Select Create new target tables and click Next.
6.
7.
8. 9.
10. Click Click to select a target owner under Target Library or Target Schema (if you're using a DB2 agent) and select a target owner. Note that if you are mapping to a datastore that uses a DB2 database, you must enter the Tablespace in the Select Schema for New Target Tables dialog box. 11. Choose from the following options and click Next: v Identical to the source table namesNames the new target tables the same name as the source tables. v Source table names with prefixes and/or suffixesAdds the suffix, the prefix, or both, to the source table name. Enable the Use prefix/suffix for index name check box to use the prefix and suffix as the index name. 12. Review the mapping summary and click Finish. Related concepts Mapping using LiveAudit on page 95
To map a single source table using LiveAudit

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Custom Table Mapping > LiveAudit and click Next. Review the following audit columns. You can choose to add, modify, or delete audit columns to the target table. Click Next: v AudTimeStores the &TIMSTAMP journal control field which indicates date and time changes are made to the source.
v AudTypeStores the &ENTTYP journal control field which indicates the type of change made to the source. v AudUserStores the &USER journal control field which indicates the ID of the user who made the change to the source. 5. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For
98
more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 6. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 10. Enable a table to map from the Target Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 11. Click Next. 12. Review the mapping summary. 13. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping using LiveAudit on page 95
To map a single multi-member source table using LiveAudit for IBM i

1. Ensure that InfoSphere CDC for IBM i is installed on both source and target. 2. Click Configuration > Subscriptions. 3. Select a subscription, right-click and select Map Tables. 4. Select Custom Table Mapping > LiveAudit and click Next. 5. Review the following audit columns. You can choose to add, modify, or delete audit columns to the target table. Click Next: v AudTimeStores the &TIMSTAMP journal control field which indicates date and time changes are made to the source. v AudTypeStores the &ENTTYP journal control field which indicates the type of change made to the source. v AudUserStores the &USER journal control field which indicates the ID of the user who made the change to the source. 6. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 7. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh.
Mapping tables
99
8. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 9. Click Next. 10. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 11. Select a target table to map from the Target Table list and choose one of the following options. v Source and Target Files are Single MemberMerges all members from the source table to a single-member target table. v Use Source member Structure on TargetMaintains the same multi-member structure on the target table as the one on the source table. Each source member is mapped to the corresponding target member. v Merge Source Members into One Target MemberMerges all members from the source table to a single member in a multi-member target table. 12. Review the mapping settings. 13. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping using standard replication on page 87 Setting member identifiers for multi-member source tables on page 195
Mapping using Adaptive Apply

If you know that your source and target tables are not synchronized, but you want to replicate data from the source to the target without error, then map your source table to your target table using the Adaptive Apply mapping type. For example, if there is an insert on the source table, but that row already exists in your target table, InfoSphere CDC switches the insert to an update operation. Also, if there is an update on your source table, and this row does not exist on your target table, then InfoSphere CDC switches the update into an insert. Adaptive Apply ensures that replicated rows in the source and target tables are the same. You can also use Adaptive Apply to restore the contents of a target table from recorded journal or log entries. To do this, you set the journal or log position to a specific entry or point in time, and then use Adaptive Apply to populate an empty target table with the latest data. Management Console provides two mechanisms for mapping: v Multiple one-to-one table mappingsMap tables using one-to-one replication when you want to map multiple source tables to multiple target tables at a time and these tables share the same table structure and similar table names. The Map Tables wizard automatically maps tables based on an example mapping you set up. v Custom table mappingsMap tables using custom replication when you want to map only one source table to one target table at a time. Use custom table mappings when you need more control over the way the table is mapped. For example, use custom mappings for tables that do not share the same table
100
structure or similar table names, for mappings where you need to filter out columns for a particular table, or for tables where you want to pick a particular index. See also: To map multiple source tables for bulk Adaptive Apply To map a single source table using Adaptive Apply on page 102 To map a multi-member source table using Adaptive Apply on IBM i on page 104
To map multiple source tables for bulk Adaptive Apply

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Multiple One-to-One Mappings > Adaptive Apply and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter.
5. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Select Map to existing target tables and click Next. If you want to map to a new target table, click Create new target tables. 9. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. The wizard uses the relationship between this target table and the selected source table to map the remaining source and target tables. You can click Change Example Table if you want the Map Tables wizard to base the mapping on a different source table. This option is only available if you have selected more than one source table. 10. Enable a table to map from the Target Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 11. Click Next. 12. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table.
Mapping tables
101
v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN). This option is only available when you have installed InfoSphere CDC for DB2 for i on the source database. 13. Verify the mappings in the Complete Mappings dialog, and click Next. Note: The Map Tables wizard may leave some source tables unmapped if it did not find a target table that shared the same table structure or similar column names. You must map these manually.
To map a single source table using Adaptive Apply

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Custom Table Mapping > Adaptive Apply and click Next. 4. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 9. Enable a table to map from the Target Table list and click Next. If you do not see your table listed, right-click the database user or schema and select Refresh. Click Next. If you want to create a new table to map to, click Create Table. 10. Choose one of the following and click Next:
102
v Use an IndexSelect the index (or constraint if you are mapping to target columns on a Netezza database where InfoSphere CDC for Netezza databases has been installed) name from the box or select <Auto Detect> if you want InfoSphere CDC to automatically choose the index or constraint. Use if your target table has an index or a constraint that uniquely identifies a row. v Use all searchable columnsSearches all target columns to identify which columns are suitable to uniquely identify rows. The results of the search are used to build a WHERE clause which uniquely identifies the row on the target column to apply data. v Specify the keySelect the target columns from the Key Columns list. Use if one or more target columns uniquely identifies a row. 11. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. 12. If you are replicating source database changes using InfoSphere CDC for Oracle databases (trigger) and want to use a journal table to mirror database operations from the source to the target table, then enable one of the following: v Use Default JournalEnable when you want InfoSphere CDC for Oracle databases to use the default journal table provided with InfoSphere CDC for Oracle databases: <TS SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and replicate database changes from the source to the target. v Use Selected JournalEnable when you want InfoSphere CDC for Oracle databases to use another journal table other than the default journal table provided with InfoSphere CDC for Oracle databases. When you select the database owner and provide a name for the journal table, InfoSphere CDC for Oracle databases creates this new journal table and uses it to detect and replicate database changes from the source to the target. OwnerLists the database owner of the journal table. NameLists the name of the journal table. If you have configured bidirectional replication, then enable the Prevent Recursion check box. This prevents InfoSphere CDC from replicating changes back to the source database when you have configured a subscription for bidirectional replication. This is only available in versions of InfoSphere CDC that support both source and target databases. Contact IBM Technical Support to implement bidirectional replication in your environment. Click Next. Review the mapping summary. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view.
13.
14. 15. 16.
Mapping tables
103
Related concepts Mapping using Adaptive Apply on page 100
To map a multi-member source table using Adaptive Apply on IBM i

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Custom Table Mapping > Adaptive Apply and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh.
6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 9. Enable a table to map from the Target Table list and click Next. If you do not see your table listed, right-click the database user or schema and select Refresh. Click Next. If you want to create a new table to map to, click Create Table. 10. Choose one of the following and click Next: v Use an IndexSelect the index (or constraint if you are mapping to target columns on a Netezza database where InfoSphere CDC for Netezza databases has been installed) name from the box or select <Auto Detect> if you want InfoSphere CDC to automatically choose the index or constraint. Use if your target table has an index or a constraint that uniquely identifies a row. v Use all searchable columnsSearches all target columns to identify which columns are suitable to uniquely identify rows. The results of the search are used to build a WHERE clause which uniquely identifies the row on the target column to apply data. v Specify the keySelect the target columns from the Key Columns list. Use if one or more target columns uniquely identifies a row. 11. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table.
104
v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN). This option is only available when you have installed InfoSphere CDC for DB2 for i on the source database. 12. Review the mapping settings. 13. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping using Adaptive Apply on page 100
Mapping to summarize data

If you want to accumulate or deduct numerical values on the target, then map your source and target tables using the Summarization mapping type. There are two types of summarization: Accumulation and Deduction. Accumulation ensures that numeric changes applied to the target column are directly proportional to changes applied to the corresponding source columns. Deduction ensures that numeric changes applied to the target columns are inversely proportional to changes applied to mapped source columns. See also: To map a source table to summarize data To map a multi-member source table to summarize data on IBM i on page 107
To map a source table to summarize data

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Custom Table Mapping > Summarization and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For
Mapping tables
105
more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 9. Enable a table to map from the Target Table list and click Next. If you do not see your table listed, right-click the database user or schema and select Refresh. Click Next. If you want to create a new table to map to, click Create Table. 10. Select the target columns from the Key Columns list and click Next. 11. Choose one of the following from the Summarization Type list: v AccumulationNumeric changes applied to target columns are directly proportional to changes applied to source columns. v DeductionNumeric changes applied to target columns are inversely proportional to changes applied to source columns. 12. Select the source column from the Summarized Column list and click Next. 13. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. 14. If you are replicating source database changes using InfoSphere CDC for Oracle databases (trigger) and want to use a journal table to mirror database operations from the source to the target table, then enable one of the following: v Use Default JournalEnable when you want InfoSphere CDC for Oracle databases to use the default journal table provided with InfoSphere CDC for Oracle databases: <TS SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and replicate database changes from the source to the target. v Use Selected JournalEnable when you want InfoSphere CDC for Oracle databases to use another journal table other than the default journal table provided with InfoSphere CDC for Oracle databases. When you select the database owner and provide a name for the journal table, InfoSphere CDC for Oracle databases creates this new journal table and uses it to detect and replicate database changes from the source to the target. OwnerLists the database owner of the journal table. NameLists the name of the journal table. 15. If you have configured bidirectional replication, then enable the Prevent Recursion check box. This prevents InfoSphere CDC from replicating changes
106
back to the source database when you have configured a subscription for bidirectional replication. This is only available in versions of InfoSphere CDC that support both source and target databases. Contact IBM Technical Support to implement bidirectional replication in your environment. 16. Click Next. 17. Review the mapping settings. 18. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping to summarize data on page 105
To map a multi-member source table to summarize data on IBM i

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Custom Table Mapping > Summarization and click Next. 4. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 9. Enable a table to map from the Target Table list and click Next. If you do not see your table listed, right-click the database user or schema and select Refresh. Click Next. If you want to create a new table to map to, click Create Table. 10. Select the target columns from the Key Columns list and click Next. InfoSphere CDC for IBM i requires that the selected key columns match an existing index. 11. Choose one of the following from the Summarization Type list: v AccumulationNumeric changes applied to target columns are directly proportional to changes applied to source columns. v DeductionNumeric changes applied to target columns are inversely proportional to changes applied to source columns. 12. Select the source column from the Summarized Column list and click Next. 13. Choose a replication method from the following and click Next:
Mapping tables
107
v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN). This option is only available when you have installed InfoSphere CDC for DB2 for i on the source database. 14. Review the mapping settings. 15. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping to summarize data on page 105
Mapping to consolidate data (one-to-one)

If your business environment contains information that is scattered across different source tables, you may want to consolidate it to facilitate report generation, data management, or data security. To merge different information about a common entity into a single row, such as a person, a customer, or a product part, map your source table to your target table using the Consolidation one-to-one mapping type. See also: To map a source table to consolidate data (one-to-one) on page 109 To map a multi-member source table to consolidate data on IBM i (one-to-one) on page 110
108
Related concepts Mapping using standard replication on page 87 Adding and mapping derived columns to target columns on page 178 Related tasks To map a source table to consolidate data (one-to-many) on page 113 To map a multi-member source table to consolidate data on IBM i (one-to-many) on page 114 Related reference Retrieve column%GETCOL (Dynamic SQL) on page 276
To map a source table to consolidate data (one-to-one)

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Custom Table Mapping > Consolidation One-to-one and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter.
5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 9. Enable a table to map from the Target Table list and click Next. If you do not see your table listed, right-click the database user or schema and select Refresh. Click Next. If you want to create a new table to map to, click Create Table. 10. Check the key for the target columns and click Next. 11. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. 12. If you are replicating source database changes using InfoSphere CDC for Oracle databases (trigger) and want to use a journal table to mirror database operations from the source to the target table, then enable one of the following:
Mapping tables
109
v Use Default JournalEnable when you want InfoSphere CDC for Oracle databases to use the default journal table provided with InfoSphere CDC for Oracle databases: <TS SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and replicate database changes from the source to the target. v Use Selected JournalEnable when you want InfoSphere CDC for Oracle databases to use another journal table other than the default journal table provided with InfoSphere CDC for Oracle databases. When you select the database owner and provide a name for the journal table, InfoSphere CDC for Oracle databases creates this new journal table and uses it to detect and replicate database changes from the source to the target. OwnerLists the database owner of the journal table. NameLists the name of the journal table. 13. If you have configured bidirectional replication, then enable the Prevent Recursion check box. This prevents InfoSphere CDC from replicating changes back to the source database when you have configured a subscription for bidirectional replication. This is only available in versions of InfoSphere CDC that support both source and target databases. Contact IBM Technical Support to implement bidirectional replication in your environment. 14. Click Next. 15. Review the mapping settings. 16. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping to consolidate data (one-to-one) on page 108
To map a multi-member source table to consolidate data on IBM i (one-to-one)

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Custom Table Mapping > Consolidation One-to-one and click Next. 4. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed.
110
9. Enable a table to map from the Target Table list and click Next. If you do not see your table listed, right-click the database user or schema and select Refresh. Click Next. If you want to create a new table to map to, click Create Table. 10. Check the key for the target columns and click Next. 11. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN). This option is only available when you have installed InfoSphere CDC for DB2 for i on the source database. 12. Review the mapping settings. 13. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping to consolidate data (one-to-one) on page 108
Mapping to consolidate data (one-to-many)

If you are using a lookup table to make updates to a target table, then you can map your lookup table using one-to-many row consolidation. When you map a lookup table using one-to-many consolidation, InfoSphere CDC only applies updates to the rows in the target table. v If you insert a row into your lookup table, InfoSphere CDC: Does not apply an operation to the target table (leaves the target table unchanged); or Updates the row that has the same consolidation key value.
Mapping tables
111
If you delete a row from your lookup table, InfoSphere CDC does not apply an operation to target table. v If you update a row in your lookup table, InfoSphere CDC updates all rows that have the same consolidation key value. v The following example illustrates how InfoSphere CDC can update regional tax code information in a target table that was mapped to a source table using One to Many Consolidation. When there are updates made to the lookup table TAXCODES, InfoSphere CDC updates these columns in the target table.
Before you map your lookup table for one-to-many consolidation, make sure you have completed the following tasks:
v Created a lookup table For InfoSphere CDC to accomplish one-to-many row consolidation, you need to create a lookup table that contains the columns you want InfoSphere CDC to update in your target table. For example, if you want InfoSphere CDC to update tax codes for a specific state, then make sure these columns exist in your lookup table and that you set a primary key. For example, the primary key in the TAXCODES table would be STATE. You can then map your lookup table to the target table using one-to-many consolidation. v Mapped your source table to the target table using Standard mapping type InfoSphere CDC requires that at least one source table is mapped to the target table using a mapping type other than one-to-many consolidation, such as Standard. When you map a source table using one-to-many mapping, InfoSphere CDC only updates the target table and does not insert or delete rows in the target table. Therefore, another mapping type such as Standard ensures that InfoSphere CDC populates the target table with source data. You need to identify the primary key on the source table. For example, to populate the target table STOREDATA with data from the source table STORELOC, you would map the source columns STORE, CITY, STATE, and TAX to the target columns STORE_CON, CITY_CON, STATE_CON, and TAX_CON. You can map these columns using Standard mapping type. v Created a derived column on the source table using %GETCOL to retrieve data from your lookup table After mapping your source table to the target table using Standard mapping type, InfoSphere CDC requires you create a derived column on the source table to retrieve data from the lookup table when replicating data from the source to the target table. For example, if you want your source table to retrieve tax codes and state information from the TAXCODES table, your %GETCOL expression would be: %GETCOL(TAX, TAXCODES, <default value>, STATE, STATE). The default value of the tax you want InfoSphere CDC to retrieve is up to you. In this example, a typical default value would be 0. See also:
112
To map a source table to consolidate data (one-to-many) To map a multi-member source table to consolidate data on IBM i (one-to-many) on page 114
To map a source table to consolidate data (one-to-many)

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Custom Table Mapping > Consolidation One-to-many and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh.
6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 9. Enable a table to map from the Target Table list and click Next. If you do not see your table listed, right-click the database user or schema and select Refresh. Click Next. If you want to create a new table to map to, click Create Table. 10. Check the consolidation key for the target columns and click Next. InfoSphere CDC uses the consolidation key to determine the rows that will be updated in the target table in response to an update in the look-up table. The consolidation key must identify the same column you identified as the primary key in the lookup table. 11. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. 12. If you are replicating source database changes using InfoSphere CDC for Oracle databases (trigger) and want to use a journal table to mirror database operations from the source to the target table, then enable one of the following: v Use Default JournalEnable when you want InfoSphere CDC for Oracle databases to use the default journal table provided with InfoSphere CDC
Mapping tables
113
for Oracle databases: <TS SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and replicate database changes from the source to the target. v Use Selected JournalEnable when you want InfoSphere CDC for Oracle databases to use another journal table other than the default journal table provided with InfoSphere CDC for Oracle databases. When you select the database owner and provide a name for the journal table, InfoSphere CDC for Oracle databases creates this new journal table and uses it to detect and replicate database changes from the source to the target. OwnerLists the database owner of the journal table. NameLists the name of the journal table. 13. If you have configured bidirectional replication, then enable the Prevent Recursion check box. This prevents InfoSphere CDC from replicating changes back to the source database when you have configured a subscription for bidirectional replication. This is only available in versions of InfoSphere CDC that support both source and target databases. Contact IBM Technical Support to implement bidirectional replication in your environment. 14. Click Next. 15. Review the mapping settings. 16. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. 17. After you map your lookup table for one-to-many consolidation, set the following on the table mapping: a. Select the table mapping you just created in the Table Mappings view and right-click Open Mapping Details. b. Verify your column mappings to the target table on the Column Mappings tab. Make sure that the appropriate columns from the lookup table are mapped to the target table. c. Select Update all if exists from the On Insert list on the Operations tab. This ensures that InfoSphere CDC updates all rows where the consolidation key is the same when there is an insert on the lookup table. d. Click Apply.
To map a multi-member source table to consolidate data on IBM i (one-to-many)

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Custom Table Mapping > Consolidation One-to-many and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 5. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh.
114
6. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 7. Click Next. 8. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 9. Select a table from the Target Table list. If you do not see your table listed, select the database user or schema and click Refresh. Choose one of the following options and click Next: v Source and Target Files are Single MemberMerges all members from the source table to a single-member target table. v Use Source member Structure on TargetMaintains the same multi-member structure on the target table as the one on the source table. Each source member is mapped to the corresponding target member. v Merge Source Members into One Target MemberMerges all members from the source table to a single member in a multi-member. 10. If you want to create a new table to map to, click Create Table. 11. Check the key for the target columns and click Next. 12. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN). This option is only available when you have installed InfoSphere CDC for DB2 for i on the source database. 13. Review the mapping settings. 14. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping.
Mapping tables
115
v Return to current viewReturns you to the current view. 15. After you map your lookup table for one-to-many consolidation, set the following on the table mapping: a. Select the table mapping you just created in the Table Mappings view and right-click Open Mapping Details. b. Verify your column mappings to the target table on the Column Mappings tab. Make sure that the appropriate columns from the lookup table are mapped to the target table. c. Select Update all if exists from the On Insert list on the Operations tab. This ensures that InfoSphere CDC updates all rows where the consolidation key is the same when there is an insert on the lookup table. d. Click Apply.
Mapping to a datastore outside of your organization

If you are mapping tables for a subscription with an external target datastore, the organization that owns the external target datastore must first add tables to the subscription before you can map the tables. After adding tables to the subscription, you can map tables using one of the available mapping types. See also: To map source tables for a subscription on an external datastore
To map source tables for a subscription on an external datastore

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select the mapping mode and type, depending on the number of tables you want to map and the structure of them. 4. Click Next. 5. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 6. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Review the mapping settings. 10. Click Finish.
116
Related concepts Mapping to a datastore outside of your organization on page 116
Mapping using InfoSphere DataStage

After adding a subscription that uses InfoSphere CDC for InfoSphere DataStage as a target datastore, you must map one or more source tables to the target system, IBM InfoSphere DataStage. You can create as many table mappings as you feel necessary, and this may depend on the number of tables that you want to replicate to the target system. There are two methods of mapping tables in InfoSphere CDC for consumption by InfoSphere DataStage. The two options differ from one another. In the Flat File method, InfoSphere CDC produces one or more files containing information about one or more records and database operations, with each record occupying its own line followed by a delimiter if you use the Single Record option, or with each record occupying two lines if you choose the Multiple Records option when mapping your tables. Those files are saved to be retrieved by InfoSphere DataStage and used by the Sequential File Reader stage of the InfoSphere DataStage job. For update operations, the flat file will have both the before and after image in one line. In the Direct Connect method, the data is not written to a file, but is sent instead over a TCP/IP connection directly to InfoSphere DataStage to be processed by a specific InfoSphere DataStage job that you have identified by specifying the matching Project Name, Job Name, and Connection Key in the InfoSphere DataStage Properties dialog box in Management Console. The InfoSphere DataStage Connector processes the data, then transforms and translates it into a format recognized by the InfoSphere DataStage job. With the Direct Connect connection method, you can enable the autostart feature to run in active mode, which allows you to start a InfoSphere DataStage job from InfoSphere CDC and begin to stream data to InfoSphere DataStage. Running with autostart enabled requires both InfoSphere CDC and InfoSphere DataStage to be installed on the same server. If autostart is not enabled, you will be running in passive mode, and you must run jobs from InfoSphere DataStage before the Direct Connect data stream can begin. Note that to use the full functionality of the Direct Connect option, you must have Management Console version 6.5, Access Server version 6.5 installed as well as having InfoSphere CDC version 6.5 installed on the same server as InfoSphere DataStage, a component of IBM Information Server version 8.5.
Understanding the workflow

Depending on the connection method you choose, files are either saved for retrieval by InfoSphere DataStage (Flat File), or data is streamed to InfoSphere DataStage (Direct Connect), by InfoSphere CDC when either when data limits are reached (determined the Batch Size Threshold settings you've indicated in the InfoSphere DataStage Properties dialog box in Management Console after mapping your tables) or when a refresh or mirroring operation ends. For the Flat File connection method, the process begins once a refresh or mirroring operation begins, and InfoSphere CDC starts writing change information to temporary data files for only those tables in the subscription for which there are changes. Once the Batch Size Threshold limits are met, InfoSphere CDC hardens
Mapping tables
117
the temporary data files at the subscription level with timestamps in the filenames. No data files are produced for tables that have no changes. Once the refresh or mirroring operation is ended, <TABLE_NAME>.STOPPED files, which server as status flags, are produced for each table in the subscription, then the bookmark is updated. These files are ready for consumption by the InfoSphere DataStage job. Attention: If you kill a refresh or mirroring operation using the dmterminate command, the temporary data files cannot be hardened at the subscription level, no <TABLE_NAME>.STOPPED status flag files are generated for the tables in the subscription, and the bookmark is not updated. You must restart the refresh or mirroring process. Be aware that restarting uses the last-saved bookmark and starts a new set of temporary data files to be hardened as thresholds are met. To ensure that the temporary data files are hardened, and the <TABLE_NAME>.STOPPED status flag files are created, use a Normal or Scheduled End shutdown in Management Console, or you can issue a dmshutdown command with the appropriate flags for the severity level. If you use the Abort or Immediate shutdown options, InfoSphere CDC may opt not harden the temporary data files as a way of facilitating these more rapid shutdown requests. For the Direct Connect connection method, the process is similar. The size and time limits set in the InfoSphere DataStage Properties dialog box determine when data is sent, and the matching Project Name, Job Name, and Connection Key information set in the InfoSphere DataStage Properties dialog box permit InfoSphere CDC to send the data to InfoSphere DataStage directly, without saving any of the data as flat files. Additionally, with the Direct Connect connection method, you can enable the autostart feature to run in active mode, which allows InfoSphere DataStage to start a job when appropriate and begin to stream data to InfoSphere DataStage. Running with autostart enabled requires both InfoSphere CDC and InfoSphere DataStage to be installed on the same server. If autostart is not enabled, you must run jobs from InfoSphere DataStage before the Direct Connect data stream can begin. For instructions on enabling autostart, see the Management Console documentation. It is important to note that the Direct Connect connection method does not maintain the ordering of operations across tables, though it will maintain the transactional boundaries that existed on the source. For example, if the transaction on the source was
INSERT TABLE1 INSERT TABLE2 COMMIT
then both of the INSERT actions will be completed by InfoSphere DataStage before it performs the COMMIT action, however, because the order of operations is not maintained, there is no way to determine the order in which the INSERT actions will be done prior to being committed to the target database. Important: In order to use the autostart function in the Direct Connect method on a UNIX or Linux system, ensure that you have correctly set the database library directory in the dsenv file for InfoSphere Information Server. See the topic on "Ensuring thatInfoSphere DataStage users have the correct localization settings (Linux, UNIX)" and "Configuring the dsenv file" in the InfoSphere Information Server Planning, Installation, and Configuration Guide. To map multiple source tables to InfoSphere DataStage using flat files on page 119
118
To map multiple source tables to InfoSphere DataStage using Direct Connect To map a single source table to InfoSphere DataStage using flat files on page 120 To map a single source table to InfoSphere DataStage using Direct Connect on page 121
To map multiple source tables to InfoSphere DataStage using flat files

Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Multiple InfoSphere DataStage Mappings and click Next. Select Flat File and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 6. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 1. 2. 3. 4. 5. 8. Click Next. 9. Enter the output directory for the flat files that are generated by InfoSphere CDC and used by InfoSphere DataStage in the Directory box. 10. Enable one of the following options for the flat file output records and click Next: v Single RecordAn update operation is sent as a single row. v Multiple RecordAn update operation is sent as two rows. 11. Review the mapping settings. 12. Click Finish.
To map multiple source tables to InfoSphere DataStage using Direct Connect

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Multiple InfoSphere DataStage Mappings and click Next. 4. Select Direct Connect and click Next. 5. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For
Mapping tables
119
more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 6. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Enter the host name of your InfoSphere DataStage installation in the Host box. 10. Specify the starting port if you have selected more than one source table in the Port box. 11. Enable one of the following options for the output records used by InfoSphere DataStage and click Next: v Single RecordAn update operation is sent as a single row. v Multiple RecordAn update operation is sent as two rows. 12. Review the mapping settings. 13. Click Finish.
To map a single source table to InfoSphere DataStage using flat files

1. Click Configuration > Subscriptions. 2. Select a subscription, right-click and select Map Tables. 3. Select Custom InfoSphere DataStage Mapping and click Next. 4. Select Flat File and click Next. 5. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 6. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Enter the output directory for the flat files that are generated by InfoSphere CDC and used by InfoSphere DataStage in the Directory box. 10. Select one of the following options for the record format of the flat files and click Next: v Single RecordAn update operation is sent as a single row. v Multiple RecordAn update operation is sent as two rows. 11. Review the mapping settings. 12. Click Finish.
120
To map a single source table to InfoSphere DataStage using Direct Connect

1. 2. 3. 4. 5. Click Configuration > Subscriptions. Select a subscription, right-click and select Map Tables. Select Custom InfoSphere DataStage Mapping and click Next. Select Direct Connect and click Next. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 6. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Enable one of the following options for the output records used by InfoSphere DataStage and click Next: v Single RecordAn update operation is sent as a single row. v Multiple RecordAn update operation is sent as two rows. 10. Review the mapping settings. 11. Click Finish.
Generating an InfoSphere DataStage definition file for a subscription

InfoSphere DataStage uses job definitions to describe the sequence of steps, or stages, required to transform data based on system and business requirements. InfoSphere DataStage jobs are designed and edited in InfoSphere DataStage Designer. When using InfoSphere CDC for InfoSphere DataStage, you have the option of generating a job definition in InfoSphere CDC without the need to create it in InfoSphere DataStage Designer, or you can create a custom data format if you are using an existing format you created in InfoSphere DataStage Designer. Before you generate a definition file, you must map your tables.
Using Management Console to generate a definition file

When using InfoSphere CDC for InfoSphere DataStage, you can generate a job definition containing default data formatting in Management Console without the need to create it in InfoSphere DataStage Designer. After mapping your tables to InfoSphere DataStage, you can generate a job definition file (*.dsx) that describes the default data format of the flat file generated by InfoSphere CDC among other things. You import this file into InfoSphere DataStage Designer to create a template set of jobs into which you can add business logic and customize as necessary. Generating an InfoSphere DataStage definition .dsx file is most useful to users who do not already have existing or custom InfoSphere DataStage jobs set up. If
Mapping tables
121
you have existing jobs in InfoSphere DataStage, or you have made changes to the data format that will be sent by InfoSphere CDC to InfoSphere DataStage, you should consider creating a custom data format for InfoSphere DataStage. The .dsx definition file you generate in Management Console and import into InfoSphere DataStage contains the information that is used to recreate columns in InfoSphere DataStage based on the data types of the source columns as determined by your table mapping choices. The .dsx file also contains information on which of the two connection methods that you select when you map your tables. The connection type options are: v Flat Fileuses a file system to deposit source changes for InfoSphere DataStage to retrieve. v Direct Connectuses TCP/IP as the transport protocol to stream data from InfoSphere CDC to InfoSphere DataStage. Note that to use the full functionality of the Direct Connect option, including the autostart option, you must have Management Console version 6.5, Access Server version 6.5 installed as well as having InfoSphere CDC version 6.5 installed on the same server as InfoSphere DataStage, a component of IBM Information Server version 8.5. For the Flat File connection method, the package consists of a job sequence, a parallel job, and two utility routines that are used by the job sequence. The job sequence has three parameters. The values for these parameters are specified by Management Console when it generates the InfoSphere DataStage .dsx definition file: v SPFolderPaththe full path name for the folder that InfoSphere DataStage searches for the source flat files created by InfoSphere CDC. v SPFileNamePatternthe file name pattern used to identify the source flat files created by InfoSphere CDC. v SPEndFileNamePatternthe file name thatInfoSphere DataStage creates when subscriptions stop mirroring. The name of this file signalsInfoSphere DataStage to stop. If you do not wantInfoSphere DataStage to stop, you can change the name of the file with this parameter. For the Direct Connect connection method, the data is not written to a file, but is sent instead over a TCP/IP connection directly to InfoSphere DataStage to be processed by a specific InfoSphere DataStage job that you have identified by specifying the matching Project Name, Job Name, and Connection Key in the InfoSphere DataStage Properties dialog box in Management Console after mapping your tables. The InfoSphere DataStage Connector processes the data, then transforms and translates it into a format recognized by the InfoSphere DataStage job. Important: In order to use the autostart function in the Direct Connect method on a UNIX or Linux system, ensure that you have correctly set the database library directory in the dsenv file for InfoSphere Information Server. See the topic on "Ensuring that InfoSphere DataStage users have the correct localization settings (Linux, UNIX)" and "Configuring the dsenv file" in the InfoSphere Information Server Planning, Installation, and Configuration Guide.
Creating a custom data format for InfoSphere DataStage

You can customize the data that is being generated by InfoSphere CDC and sent to InfoSphere DataStage by specifying a Java class. This is ideal for users who have existing InfoSphere DataStage jobs that expect a particular data format. If you use a custom data format that changes the default format of the flat file sent from
122
InfoSphere CDC to InfoSphere DataStage, the .dsx file described in Using Management Console to generate a definition file on page 121 will not be useful because it contains only default data formatting. If you have created and imported a .dsx file into InfoSphere DataStage, you must ensure that it is still relevant in InfoSphere DataStage Designer. For more information on these requirements, refer to the InfoSphere DataStage product technical documentation. See also: To generate an InfoSphere DataStage definition file Related concepts Setting properties for a subscription that targets InfoSphere DataStage on page 155
To generate an InfoSphere DataStage definition file

1. Ensure that you have completed your table mapping for the subscription. 2. Click Configuration > Subscriptions. 3. Right-click on a subscription and select InfoSphere DataStage > Generate InfoSphere DataStage Job Definition . 4. Select the location for your DSX file (*.dsx) and click Save. 5. Import the DSX file into InfoSphere DataStage Designer. For more information on importing and working with the DSX file in InfoSphere DataStage Designer, see your IBM InfoSphere DataStage documentation.
Mapping to a JMS Message Destination using InfoSphere CDC Event Server

InfoSphere CDC Event Server receives replicated row-level operations (inserts, updates, deletes) from your source database and transforms these rows into XML. Using Management Console, you can map source columns to XML elements and attributes. When you start mirroring and if there is a row-level operation on your source table, InfoSphere CDC Event Server receives and applies the row-level operation to the XML document which is sent to a JMS message destination (queue or topic). Before you can use InfoSphere CDC Event Server to transform table data in XML, you must install and setup a InfoSphere CDC source product that can scrape row-level operations (inserts, updates, and deletes) from your source database. InfoSphere CDC Event Server is a target-only product. This means that InfoSphere CDC Event Server can only receive row-level and table-level operations already replicated from another supported InfoSphere CDC product that you have installed. You must install another InfoSphere CDC product and connect to this datastore so that you can select the source tables you want to make available for replication. You can then continue to add a subscription that uses InfoSphere CDC Event Server as the target datastore. There are two methods for mapping to a JMS Message Destination: v Message destination mappingsAllows you to map a source table to a JMS message destination. In this method, InfoSphere CDC Event Server receives the row-level operation (insert, update, or delete) and transforms it into a row that
Mapping tables
123
is inserted into an XML message. The Message Destination Mappings mapping type option is available in the Map Tables wizard. When you map a source table to a message destination, InfoSphere CDC Event Server receives the row-level operation and transforms this row into XML. This XML message is sent to a JMS application supported by InfoSphere CDC Event Server. v Custom table mapping: StandardYou can stage your source table in an embedded target staging database using the Standard mapping type provided with InfoSphere CDC Event Server. In this method, the standard mapping type creates an exact copy of your source table in the staging database and to a JMS message destination. InfoSphere CDC Event Server receives the row-level operation from the staging database and transforms it into XML. When you select the Custom Table Mapping option in the Map Tables wizard and choose Standard, the wizard lets you map your source table to a target table available in an embedded staging database provided with InfoSphere CDC Event Server. InfoSphere CDC Event Server provides an embedded staging database as a temporary repository for your source table before it is transformed to XML. You may want to map your source table to a target staging table in order to customize the source table outside of your production database in some way before InfoSphere CDC Event Server converts the replicated rows into XML. Also, by mapping the source table to a staging database, you can reduce performance overhead on your production database. InfoSphere CDC Event Server depends on the staging database (instead of your production database) to receive and transform replicated rows into XML. LiveAudit If you want your target table to keep an audit trail of operations applied to the source table, then use the Map Tables wizard to map your source and target tables using LiveAudit. Adaptive ApplyAdaptive Apply ensures that replicated rows in the source and target tables are the same. You can also use Adaptive Apply to restore the contents of a target table from recorded journal or log entries. To do this, you set the journal or log position to a specific entry or point in time, and then use Adaptive Apply to populate an empty target table with the latest data.
Setting mapping details on a subscription that targets a JMS Message destination

Management Console lets you create an XML message for subscriptions that target JMS message destinations. In addition to the existing mapping details that you can configure with other InfoSphere CDC products you install, Management Console provides additional configuration details available only with subscriptions created with InfoSphere CDC Event Server: v XML Message tabUse this tab to create your XML message, import and export mapping projects, import and export XML schemas, build XPath expressions, and query columns from other tables if required. v XML Settings tabUse this tab to set JMS message header properties and set general runtime options. As with other InfoSphere CDC products, the Filtering tab, the Translation tab, and the User Exits tab are available for configuration with InfoSphere CDC Event Server. The Column mappings tab and the Operations tab are only available if you have mapped your source table to a target staging table.
124
v Column Mapping tabUse this tab to map source columns to columns in a target staging table. InfoSphere CDC Event Server provides an embedded staging database as a temporary repository for your source table before it is converted into XML. This tab is only available if you have you have mapped your source table to a target staging table using the Standard mapping type in the Map Tables wizard. You may want to map your source table to a target staging table when: You want to customize the source table outside of your production database. Before mapping your source table to a JMS message destination, you can map your source table to a target staging table in order to send a copy of the source table to the staging database. Using the Column Mappings tab, you can decide on the source columns you want to map (or unmap) from columns in the target staging table. This lets you control which columns you want to include or exclude for replication and therefore the kind of data you want to include or exclude for InfoSphere CDC Event Server to XML. You want to reduce performance overhead on your production database. Because you have mapped your source table to a target staging table, when you start replication, a copy of your source table is sent to the staging database. In this scenario, InfoSphere CDC Event Server receives replicated rows from the staging database (instead of your production database) and transforms these rows into XML. This setup reduces performance overhead on your production environment. v Filtering tabUse this tab to include or exclude rows or columns for replication. v Translation tabDepending on how you have mapped your source table, you can use this tab to add a data translation between your source and target staging columns and set encoding conversions or both. You can only set a data translation on a subscription for source columns that are mapped to target staging columns. If you have only mapped your source table to a JMS message destination, then you can only set encoding conversions for any multibyte character sets in your source table. When you add a data translation and start replication, the supported InfoSphere CDC source product translates values from the source column into the new value you specified for the mapped target column. InfoSphere CDC Event Server then inserts the translated value into an XML document. v Encoding tabUse this tab to view and set encoding options. For InfoSphere CDC version 6.3 and earlier, Management Console provides standard character sets and encodings. To add additional character sets and encodings, use the CSV (comma separated variable) template that is found in the Advanced preferences of Edit > Preferences. This step is not necessary for InfoSphere CDC version 6.5, which retrieves the supported encodings directly from your datastores. v Operation tabUse this tab to control how InfoSphere CDC Event Server applies row-level operations (insert, update, and deletes) and table-level operations (truncate/clear) to the target staging table. This tab is only available if you have you have mapped your source table to a target staging table using the Standard mapping type in the Map Tables wizard. v User Exits tabUse this tab configure a user exit for InfoSphere CDC Event Server. User exits define a set of actions that you want InfoSphere CDC Event Server to run either before or after applying a row-level operation. Depending on how you have mapped your source table, InfoSphere CDC Event Server can run the user exit before or after applying a row-level operation to the target staging table, run the user exit before or after applying a row-level operation to the JMS message destination, or both. Row-level operations include an insert, update, or a delete.
Mapping tables
125
See also: To map multiple source tables to a JMS message destination To map a single source table to a JMS message destination on page 127 To stage a source table on page 129
To map multiple source tables to a JMS message destination

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select a subscription, right-click and select Map Tables. Ensure that you have ended replication on the subscription. 4. Select Multiple One-to-One Mappings > Message Destination and click Next. 5. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 6. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Enable one of the following options: v Use the source table structure for the XML message: Include before-image valuesEnable this check box when you want the XML message to include the before image of a row-level operation. The before-image represents the data in the source column before an insert, update, or delete operation on the row. Include after-image valuesEnable this check box when you want the XML message to include the after image of a row-level operation. The after-image represents the data in the source column after an insert, update, or delete operation on the row. Include journal control valuesEnable this check box when you want the XML message to include journal control fields. These provide information about the source table, the source database, or the row-level operations taking place in the database log or journal of the source database. For example, the _ENNTYPE journal control field indicates the type of row-level operation (insert, update, or delete) that took place on the source table. v Value FormatChoose how you want to format source column data in the XML message. You can choose from one of the following:
126
Use attributes for data valuesFormats data values of the before image, the after image, or journal control fields in your XML message as XML attributes. Use elements for data valuesFormats data values of the before image, the after image, or journal control fields in your XML message as XML elements. v Do not specify the message format at this timeEnable this option when you want to manually decide whether you want to include the before or after image values for source columns, or journal control fields in your XML document. 10. Click Next. 11. Select and expand the JMS connection you had configured in the InfoSphere CDC Event Server Configuration Tool and select an existing destination or click Add Destination to add a queue or a topic. 12. Enter the name of queue or topic in the Name box. 13. Enter a brief description about the queue or topic in the Description box. 14. Enter the JNDI name of the JMS queue or topic to which you want to send the XML message in the Request Destination box. 15. Enable one of the following options: v Use persistent deliveryEnable to ensure the message is not lost in transit due to a JMS provider failure. v Use transacted sessionsEnables InfoSphere CDC Event Server to open a transacted session and commit every message to the JMS queue or topic. 16. Click Test and OK. 17. Click Next and Finish. Related concepts Mapping to a JMS Message Destination using InfoSphere CDC Event Server on page 123 Related tasks To map a single source table to a JMS message destination To stage a source table on page 129
To map a single source table to a JMS message destination

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select a subscription, right-click and select Map Tables. Ensure that you have ended replication on the subscription. 4. Select Custom Table Mapping > Message Destination and click Next. 5. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter.
Mapping tables
127
6. Enable one or more tables to map from the Source Tables list. If you do not see your table listed, right-click the database user or schema and select Refresh. 7. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 8. Click Next. 9. Enable one of the following options: v Use the source table structure for the XML message: Include before-image valuesEnable this check box when you want the XML message to include the before image of a row-level operation. The before-image represents the data in the source column before an insert, update, or delete operation on the row. Include after-image valuesEnable this check box when you want the XML message to include the after image of a row-level operation. The after-image represents the data in the source column after an insert, update, or delete operation on the row. Include journal control valuesEnable this check box when you want the XML message to include journal control fields. These provide information about the source table, the source database, or the row-level operations taking place in the database log or journal of the source database. For example, the _ENNTYPE journal control field indicates the type of row-level operation (insert, update, or delete) that took place on the source table. v Value FormatChoose how you want to format source column data in the XML message. You can choose from one of the following: Use attributes for data valuesFormats data values of the before image, the after image, or journal control fields in your XML message as XML attributes. Use elements for data valuesFormats data values of the before image, the after image, or journal control fields in your XML message as XML elements. v Do not specify the message format at this timeEnable this option when you want to manually decide whether you want to include the before or after image values for source columns, or journal control fields in your XML document. 10. If you have decided to format the XML message based on an imported schema, mapping project, or XML file, then browse for the file and enable one or both of the following options: v Import repeated elements with the same parentBy default, InfoSphere CDC Event Server imports only one repeated element in a group node with the same parent. Enable this option to import all repeated elements. v Import attribute valuesBy default, InfoSphere CDC Event Server imports only the structure of your XML. Enable this option to import the attribute values. This may be necessary if attribute values represent the structure of your XML document. 11. Click Next. 12. Select and expand the JMS connection you had configured in the InfoSphere CDC Event Server Configuration Tool and select an existing destination or click Add Destination to add a queue or a topic. 13. Enter the name of queue or topic in the Name box.
128
14. Enter a brief description about the queue or topic in the Description box. 15. Enter the JNDI name of the JMS queue or topic to which you want to send the XML message in the Request Destination box. 16. Enable one of the following options: v Use persistent deliveryEnable to ensure the message is not lost in transit due to a JMS provider failure. v Use transacted sessionsEnables InfoSphere CDC Event Server to open a transacted session and commit every message to the JMS queue or topic. 17. Click Test and OK. 18. Click Next and Finish. Related concepts Mapping to a JMS Message Destination using InfoSphere CDC Event Server on page 123 Related tasks To map multiple source tables to a JMS message destination on page 126 To stage a source table
To stage a source table

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select a subscription, right-click and select Map Tables. Ensure that you have ended replication on the subscription. 4. Select Custom Table Mappinghe mapping mode and type, depending on the number of tables you want to map and the structure of them. 5. Select the mapping type (Standard, LiveAudit, or Adaptive Apply), depending on your requirements. 6. Click Next. 7. Expand the database, schema, or table from the Source Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. You may be prompted to filter databases, schemas, or tables if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select a datastore, database, or schema and click Specify Filter. 8. Enable the table to map from the Source Table list. If you do not see your table listed, right-click the database user or schema and select Refresh. 9. If you want to hide columns so that the target is not aware of them, select a source table and click Filter Columns. Clear the check box for the column you want to hide and click OK. 10. Click Next. 11. Expand the database, schema, or table from the Target Tables list to view tables from your database that are available for mapping. Right-click the database user or schema and click Refresh if you do not see your table listed. 12. Choose one of the following and click Next:
Mapping tables
129
v Use an IndexSelect the index (or constraint if you are mapping to target columns on a Netezza database where InfoSphere CDC for Netezza databases has been installed) name from the box or select <Auto Detect> if you want InfoSphere CDC to automatically choose the index or constraint. Use if your target table has an index or a constraint that uniquely identifies a row. v Use all searchable columnsSearches all target columns to identify which columns are suitable to uniquely identify rows. The results of the search are used to build a WHERE clause which uniquely identifies the row on the target column to apply data. v Specify the keySelect the target columns from the Key Columns list. Use if one or more target columns uniquely identifies a row. 13. Choose a replication method from the following and click Next: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. This check box is only available in versions of InfoSphere CDC that support both source and target databases. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. 14. Review the mapping summary. 15. Choose one of the following options and click Finish: v Define column mappingsContinues with the column mapping. v Create a new table mappingAllows you to start a new table mapping. v Return to current viewReturns you to the current view. Related concepts Mapping to a JMS Message Destination using InfoSphere CDC Event Server on page 123
Remapping a source table

You can remap an existing source table so that it is mapped to the correct target table. If you want to remap a source table on a subscription that uses InfoSphere CDC Event Server as the target datastore, then you can do the following: v Remap a source table already mapped to a JMS message destination to a staging target table. v Remap a source table already mapped to a staging target table to a JMS message destination. See also: To remap a source table To remap a source table (InfoSphere CDC Event Server) on page 131
To remap a source table

1. Ensure that the subscription has at least one table mapping. You set this when mapping tables in the Map Tables wizard. 2. Ensure that you have ended any active replication on the subscription. 3. Click Configuration > Subscriptions. 4. Select the subscription that contains the mapped source and target tables.
130
5. Select the mapped source and target tables in the Table Mappings view. 6. Right-click and click Remap Source Table . Related concepts Remapping a source table on page 130
To remap a source table (InfoSphere CDC Event Server)

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select the subscription that contains the mapped source and target tables. Ensure that you have ended replication on the subscription. 4. Select the table mapping in the Table Mappings view. 5. Right-click Remap Source Table. This option is only available if you have already mapped your source table to a message destination or to a staging target table. 6. Select one of the following options: v Message Destination MappingsSelect this option if you want to map this source table to a message destination. v One mapping of any typeSelect this option if you want to map this source table to a staging target table. Select Standard as the mapping type. 7. Click Next and map the source table to a message destination or to a staging target table. Related concepts Remapping a source table on page 130 Related tasks To map multiple source tables to a JMS message destination on page 126 To stage a source table on page 129
Copying selected table mappings

Copying selected table mappings is similar to copying a subscription except that it only copies the mappings that you select to a new or existing subscription. Copying a subscription copies all table mappings to a new or existing subscription. This is useful if you only want to copy a subset of the mappings in a subscription. See also: To copy selected table mappings To copy selected table mappings for an external target datastore on page 132 Related concepts Copying subscriptions on page 61
To copy selected table mappings

1. Click Configuration > Subscriptions. 2. Select the subscription with the table mappings you want to copy. 3. Right-click one or more table mappings in the Table Mapping view and select Copy... .
Mapping tables
131
4. Enter a name for the subscription in the Name box. All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. 5. Enter a description for the subscription in the Description box. 6. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. 7. Click Next. 8. Select the source datastore for the new subscription from the New Source Datastore list. 9. Select the databases and owners for your new source datastore under New Name. 10. If you want to specify advanced settings, click Advanced Settings. 11. Click Next. 12. Select the target datastore for the new subscription from the New Target Datastore list. 13. Select the databases and owners for the new target datastore under New Name and click Next. 14. If the existing subscription contains user exits, then specify their location for the new subscription under New Location and click Next. 15. If you built a derived column, an expression, or a row-filtering expression that uses the %SELECT column function, then confirm the list of displayed expressions and click Next. After copying the subscription, you may have to change these expressions manually. 16. Review the list of changes and click Finish. Related concepts Copying subscriptions on page 61 Related reference Retrieve column%SELECT on page 279
To copy selected table mappings for an external target datastore

1. Click Configuration > Subscriptions. 2. Select the subscription with the table mappings you want to copy to an external target datastore. 3. Right-click one or more table mappings in the Table Mapping view and select Copy... . 4. Enter a name for the subscription in the Name box. All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a
132
subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. 5. Enter a description for the subscription in the Description box. 6. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. 7. Click Next. 8. Select the new source datastore for the subscription from the New Source Datastore list. 9. Select the databases and owners for your new source datastore under New Name. 10. If you want to specify advanced settings, click Advanced Settings. 11. Click Next. 12. If you want to change the properties of the external target datastore, then make the necessary changes and click Next. 13. Review the list of changes and click Finish. Related concepts Copying subscriptions on page 61 Setting up subscriptions for datastores outside of your organization on page 60 Related reference Retrieve column%SELECT on page 279
Deleting table mappings

You can delete table mappings that belong to a particular subscription. Before deleting a table mapping, you need to end replication on the subscription that contains the table mapping you want to delete. If the subscription uses InfoSphere CDC Event Server as the target datastore and you have mapped your source table to both a JMS message destination and a staging target table, then you are provided with the option to delete either mapping. See also: To delete a table mapping To delete a table mapping (InfoSphere CDC Event Server)
To delete a table mapping

1. 2. 3. 4. Ensure that you have ended replication on the subscription. Click Configuration > Subscriptions. Select the subscription that contains the mapped source and target tables. Select the table mapping in the Table Mappings view.
5. Right-click and click Delete.... Related concepts Ending replication on page 361
To delete a table mapping (InfoSphere CDC Event Server)

1. Click Configuration > Subscriptions.
Mapping tables
133
2. Select a subscription that contains the table mapping to a message destination, to a staging target table, or both. Ensure that you have ended replication on the subscription. 3. Select the table mapping in the Table Mappings view. 4. Right-click and select Delete.... 5. If you have mapped your source table to both a message destination and a target staging table, you will be presented with the following options: v Delete message destination mappingEnable this check box if you want to unmap your source table from a JMS message destination. v Delete staging target mappingEnable this check box if you want to unmap your source table from a staging target table. 6. If you have mapped your source table to either one of a message destination or a staging target table, then click Yes to the confirmation message. Related concepts Ending replication on page 361
Exporting and importing subscriptions and selected table mappings

Using InfoSphere CDC's export and import capabilities, you can prepare XML files that include details you have set on your subscription, and you can save these files on your local computer or elsewhere. You can also export selected table mappings in a subscription. You may have an existing subscription created in a previous version of Management Console that you need to import into Management Console 6.5 and require that the subscription use auto-encoding mode. You must first allow Management Console to create the new subscription using the Import Subscription wizard and choose the Import to a new subscription option. After importing subscription details to the new subscription, you can then convert the subscription to use auto-encoding as available in Management Console 6.5. See also: To export a subscription into an XML file To export selected table mappings into an XML file on page 135 To import a subscription from an XML file on page 135 Related tasks To upgrade subscriptions to use auto-encoding mode on page 191
To export a subscription into an XML file

1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select Export Subscription. 3. Enter the name for the XML file and click Save.
134
Related concepts Exporting and importing subscriptions and selected table mappings on page 134 Related tasks To promote a subscription to a new subscription on page 379 To promote changes to an existing subscription on page 380 To export selected table mappings into an XML file
To export selected table mappings into an XML file

1. Click Configuration > Subscriptions. 2. Select the subscription with the table mappings you want to export. 3. Right-click one or more table mappings in the Table Mapping view and select Export.... 4. Enter the name for the XML file and click Save. 5. Import the XML file that you have created into a subscription Related tasks To import a subscription from an XML file To export a subscription into an XML file on page 134
To import a subscription from an XML file

1. Click Configuration > Subscriptions. 2. Right-click on a project and select Import Subscription. 3. Select an XML file and click Open. 4. Depending on how you want to import the settings of your subscription, select one of the following options: v Import to a new subscriptionCopies the settings in the XML file into a new subscription. v Import to an existing subscriptionCopies the settings in the XML file into an existing subscription. Related concepts Exporting and importing subscriptions and selected table mappings on page 134 Related tasks To promote a subscription to a new subscription on page 379 To promote changes to an existing subscription on page 380
Modifying table mappings

You may need to change your existing table mappings. For example, your business requirements may have changed, or there may be errors in previous mappings. See also: To modify table mappings
To modify table mappings

1. End replication on the subscription. 2. If you need to modify a row or column selection expression for your source table, then you can make modifications on the Filtering tab in Management Console.
Mapping tables
135
3. If you need to add a new column to the target table, then alter the structure of the table. This task is done outside of InfoSphere CDC. 4. If you have altered the structure, then update the definition of the table in Management Console: a. Click Configuration > Datastores. b. Right-click Replication Tables. c. Expand the database user or schema until you display its tables. Tables are only available if you have created a table mapping in the Map Tables wizard. d. Select the table that has changed in your relational database management system and click Update. 5. If you have set any data translations or column mappings for the target table, then InfoSphere CDC retains these settings as previously defined. You can make modifications to these settings on the Column Mappings tab or the Translation tab in Management Console. After making the changes, click Apply. 6. Change the replication method to Mirroring and flag the table for refresh: a. In the Table Mappings view, select the table mapping. b. Right-click and select Change replication method. c. Enable Mirroring. d. Select the table mapping and right-click Flag for refresh. InfoSphere CDC will refresh the tables before mirroring and update the target with new modifications.
136
Replicating Data Definition Language (DDL) changes

SQL statements are divided into two categories: Data Definition Language (DDL) and Data Manipulation Language (DML). DDL statements are used to describe a database, to define its structure, to create its objects and to create the table's sub-objects. The following list provides some examples of types of DDL statements: v Creating tables (CREATE command) v Modifying the structure of a table (ALTER command) without deleting and recreating it, such as adding columns, removing columns or changing column definitions (for example, length or default values) v Removing objects (such as tables) from the database (DROP command) v Partitioning tables (PARTITION command) DML statements are used to control the information contained within the database. The following lists provides some examples of types of DML statements: v Adding records to a table (INSERT command) v Modifying information in a table (UPDATE command) v Removing records from a table (DELETE command) While all InfoSphere CDC replication engines can replicate DML changes, InfoSphere CDC for Oracle databases version 6.5.1 also includes support for replicating DDL changes, enabling simplified and more automated change management. Data changes continue to be replicated, but you no longer have to manually update subscription information when the structure of a table changes. For example, new tables and columns are added according to the DDL statement. Although a wide array of DDL operations exist, InfoSphere CDC replicates only those that are related to tables and characteristics of tables; it does not replicate the larger context of the database. In this section, you will learn: Prerequisites and considerations for replicating DDL changes in InfoSphere CDC for Oracle databases version 6.5.1 on page 138 Supported DDL operations on page 139 Working with rule sets on page 140 Modifying rule sets on page 144 Copying rule sets on page 147 Exporting rule sets on page 148 Promoting rule sets on page 148 Changing the refresh order of tables in a Rules-based subscription on page 151 Previewing tables in-scope for DDL replication on page 152
137
Related concepts Table Mappings view on page 83
Prerequisites and considerations for replicating DDL changes in InfoSphere CDC for Oracle databases version 6.5.1
Prerequisites
The following InfoSphere CDC prerequisites must be satisfied in order to allow DDL replication: v Both the source and target datastores must be InfoSphere CDC for Oracle databases version 6.5.1 or later. v Oracle database must be version 9.2.0.5 or later for both the source and target databases. v The release versions of the Oracle database need to be compatible. The DDL operations that are performed on the source database must be supported on the target database. v Primary keys/unique index supplemental logging must be enabled at the database level for the source database. v The Oracle user specified during creation of the source and target InfoSphere CDC for Oracle databases instances must be the same. v The source and target datastores must be different databases. You cannot use the same database as both a source and target datastore. v The physical elements of the source and target datastores must be identical. For example, there must be existing tablespaces on the source and target datastores and the names of the tablespaces must be identical. v Database encoding (code page) must be identical for the source and target
Considerations
The following InfoSphere CDC issues should be taken into consideration before you attempt DDL replication: v A table targeted for DDL replication cannot be involved in any other InfoSphere CDC table mapping. That is to say, you cannot mirror from two different source tables to a single target table. v Conflict Detection and Resolution is not supported for DDL replication. v Differential refresh and Refreshing a Subset of Rows are not supported for tables for which DDL operations are being replicated. v Derived columns and derived expressions are not supported for tables for which DDL operations are being replicated. v LOB columns are selected by rowid from the database at the time of replication. Therefore, only the current image of a LOB column field in a source table will be sent at the time of replication. If latency is present for a subscription that is replicating DDL operations and there are changes to the structure of the LOB column, the target column may contain a null value until the next DML change on that row. If latency is present and the rowid of the row changes, due to DDL operations or row movement in a partitioned table, the target column may contain a null or incorrect value v Bidirectional replication is not supported for DDL replication.
138
v When InfoSphere CDC encounters certain object types that cannot be replicated, such as UDTs (user-defined columns), the table will be parked. The table will have to be dropped, recreated and its structure changed in order to be supported for DDL replication. Related concepts Supported data types on page 159 Flagging a source table for refresh on page 343
Supported DDL operations

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. Examples of the table-related DDL operations that InfoSphere CDC will replicate include: v Tables v Object grants v Comments v Indexes v Partitions and subpartitions v Constraints The following table indicates the types of DDL changes that can be replicated by InfoSphere CDC.
Adding tables Adding columns with a default value Setting columns to unused Dropping primary key constraints Adding unique constraints Adding not null constraints Dropping check constraints Adding partitions Adding subpartitions Dropping tables Modifying columns (widening widths, precision or range) Dropping unused columns Adding foreign key constraints Dropping unique constraints Dropping columns Modifying columns (shrinking widths, precision or range) Adding primary key constraints Dropping foreign key constraints Adding an overflow tablespace
Disabling not null constraints Adding check constraints Adding compression Dropping partitions Dropping subpartitions Dropping compression Splitting partitions Adding comments on tables Deleting comments on columns Shrinking space checks Changing column types Moving subpartitions Disabling primary key constraint non-validation Enabling unique constraint non-validation
Deleting comments on tables Adding comments on columns Enabling row movement Encrypting columns Moving partitions Modifying subpartition ranges Enabling foreign key constraint non-validation Shrinking spaces Decrypting columns Modifying partition ranges Enabling primary key constraint non-validation Disabling foreign key constraint non-validation
139
Disabling unique constraint non-validation Enabling check constraint non-validation Altering tables (read write)
Enabling null constraint non-validation Disabling check constraint non-validation Making constraints deferrable deferred (primary key) Enabling triggers Disabling primary key constraint validation Enabling unique constraint validation Disabling null constraint validation
Disabling null constraint non-validation Altering tables (read only) Making constraints deferrable initially immediate (primary key) Disabling triggers Enabling foreign key constraint validation Disabling unique constraint validation Enabling check constraint validation
Changing column encodings Enabling primary key constraint validation Disabling foreign key constraint validation Enabling null constraint validation Disabling check constraint validation Dropping supplemental log groups
Setting table parallel degree Adding supplemental log (alter table parallel <degree>) groups
The table-related objects for which DDL replication is not supported by InfoSphere CDC are listed below: v Views v Synonyms v Triggers v Materialized views v Materialized view logs v Tables containing user-defined types The following DDL operations are not supported by InfoSphere CDC: v RENAME v REORG v FLASHBACK TO BEFORE DROP Please note that TRUNCATE TABLE operations will be considered DML operations by tables with Direct Mappings. TRUNCATE (ANY OBJECT) operations will be replicated as DDL operations for Rules-based tables.
Working with rule sets

DDL replication is supported in InfoSphere CDC for Oracle databases version 6.5.1 or later for tables specified through rule-based selection. This is achieved through the creation of rule sets within a subscription, which are then used to determine the tables that will have DDL operations replicated. For tables matching rule sets, both the data within the tables as well as the structure of the tables will be replicated as they change When you start replication for a subscription, the subscription's rule sets are used to determine which tables will be in-scope. Replication for all tables in the subscription that satisfy the rules criteria will begin with the target table being dropped (if it exists) and created. This is called a structural refresh. This is then
140
followed by a normal data refresh. Mirroring of both data changes and structural changes will begin after the refresh is complete. Rule sets are defined on a per-subscription basis. That is to say that they are defined within, and belong solely to, a selected subscription. You can define multiple rule sets within each subscription. Subscriptions can contain both Rules-based mappings for DDL replication and the standard InfoSphere CDC mappings (called Direct Mappings) for DML-only replication. The Table Mappings view will show a separate display for each type of mapping. Just like subscriptions containing Direct Mappings, subscriptions containing Rules-based mappings (or combinations of Direct Mappings and Rules-based mappings) can be copied, promoted, exported and imported. Each rule set identifies a pool of tables from within a single schema; the tables are selected either by exact name or through a pattern. Individual tables can be chosen to either be included or excluded from replication. Patterns can be defined to include or exclude tables that match the criteria. A simple example of pattern-based identification for a rule set would be as follows:
Tables to include Tables to exclude A*, B* *C
The returned result would be that all tables whose names begin with the letter A or the letter B, whose names do not end in the letter C in the selected schema would be in-scope for replication. The evaluation process is performed on each rule set independently and in no particular order (there is no order of precedence for rule sets). As each rule set is evaluated, the tables that match the criteria are added to a pool. As each rule set is consulted, the pool is augmented by the tables that match it's criteria. If there are multiple rule sets, a table must match only a single rule to be included in the pool; a table doesnt have to match all the rules to be included. Tables will not be removed from the pool once added and tables will not be added multiple times to the pool. Important: Source tables involved in a Direct Mapping will never be evaluated against rule sets. When you are defining a rule set, you should consider the following issues: v Understand your logic fully when creating your patterns and table lists. You should make sure that the conditions set in the various rules are not contradictory. v You should consider not just the tables that currently exist that will match the rules, but also the tables that the rule set will match in the future. v You should also consider the rules defined for other subscriptions replicating to the same target database and verify that there is no overlap. A table targeted for DDL replication cannot be involved in any other InfoSphere CDC table mapping, either Direct Mapping or Rules-based. v When you are creating patterns for your rule sets, keep in mind that patterns are case-sensitive. v All DDL replication actions for tables in Management Console are based on the table name, not the Source ID
141
You can only create or modify rule sets while replication is not active. If you want to arrange the order in which the tables will be refreshed, you can set the Refresh Order and move the tables that are in-scope for replication into groups. Refresh order, in the sequence you chose, will be performed before mirroring begins. You can set the capture point for tables that are included in a rule set. If tables are marked as Mirror/Active, InfoSphere CDC will assume that the target table is synchronized with the source table at the time that the capture point is marked, so there is no need to do a refresh. You can see what the rules evaluate to before starting replication by previewing the tables that will be in-scope for replication. Management Console will display a list of the tables that satisfy the rule set criteria at the current moment. That is to say, what is actually in the database at the moment the preview occurs; changes in the database may result in the list of in-scope tables being different at the moment that replication is actually started than it was when previewed. Please note the following limitations for subscriptions that have rule sets defined: v You cannot manually park tables in a Rules-based mapping. v A Direct table mapping takes precedence over a Rules-based mapping for that table. Tables in a Direct mapping are excluded from DDL replication. v DDL replication is not available for tables with Direct Mappings. v Replication of tables with interval partitions is supported only for Rules-base mappings, not Direct mappings. See also: To define a rule set for a subscription To delete a rule set on page 144
To define a rule set for a subscription

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription. Click Rules in the Table Mappings view. Right-click in the view and select Define Rule Set....
5. Enter the name of the rule in the Rule Set Name box. Each rule set name within a subscription must be unique. 6. Click Next. 7. Select the schema. You may be prompted to filter schemas if Automatically prompt for filter when expanding nodes is enabled in your preferences. For more information see, Setting advanced preferences on page 15. To manually define a filter, select the datastore name and click Specify Filter. 8. Click Next. 9. If you choose to manually select which tables to include in the rule set, perform the following steps: a. Click Add Table... b. Select the tables to be included in the rule set. c. Click OK.
142
10. If you choose to use a pattern within the table names to select which tables to include in the rule set, perform the following steps: a. Click Add Pattern... b. Specify a value in the Pattern box. Patterns are case-sensitive. c. Determine how to apply the pattern. Select one of the following options: v Match all tablesSpecifies that any defined patterns will be overridden and all tables will be considered for replication. v Matches the patternSpecifies that tables with names that match the pattern will be included in the rule set. v Starts with the patternSpecifies that tables with names that match the pattern at the beginning of their names will be included in the rule set. v Contains the patternSpecifies that tables with names that contain the pattern in any part of their names will be included in the rule set. v Ends with the patternSpecifies that tables with names that match the pattern at the end of their names will be included in the rule set. d. Click OK to add the pattern and exit the dialog box. Alternately, click Add if you want to create another pattern. 11. Select the Replicate structural changes only checkbox if you want to replicate only structural, not data, changes for the tables. 12. Click Next. 13. If you choose to manually select which tables to exclude from the rule set, perform the following steps: a. Click Add Table... b. Select the tables to be excluded from the rule set. You cannot exclude all tables. c. Click OK. 14. If you choose to use a pattern within the table names to select which tables to exclude from the rule set, perform the following steps: a. Click Add Pattern... b. Specify a value in the Pattern box. Patterns are case-sensitive. c. Determine how to apply the pattern. Select one of the following options: v Matches the patternSpecifies that tables with names that match the pattern will be excluded from the rule set. v Starts with the patternSpecifies that tables with names that match the pattern at the beginning of their names will be excluded from the rule set. v Contains the patternSpecifies that tables with names that contain the pattern in any part of their names will be excluded from the rule set. v Ends with the patternSpecifies that tables with names that match the pattern at the end of their names will be excluded from the rule set. d. Click OK to add the pattern and exit the dialog box. Alternately, click Add if you want to create another pattern. 15. Click Next. 16. Select one of the following options and click Finish: v Show rule set detailsCompletes the rule set definition and displays it in the Details area of the Rules view.
143
v Create a new rule setCompletes the rule set definition and opens a new instance of the Define Rule Set wizard, allowing for the creation of a new rule set. v Return to the rules viewCompletes the rule set definition and returns you to the Rules view.
To delete a rule set

1. 2. 3. 4. Click Configuration > Subscriptions. Select a subscription. Click Rules in the Table Mappings view. Select a rule set.
5. Right-click and select Delete....
Modifying rule sets

InfoSphere CDC evaluates the rule sets when replication is started in order to determine which tables are replicated. Replication must be stopped before any modifications can be made to rule sets. While you are making changes to a rule set, a star will appear next to the rule set name in the Rules view, until the changes in the rule set are saved. Rule sets that are not valid cannot be saved and must be corrected before you can proceed. If you want to back out of your changes before you save them, you can click Revert to go back to the latest saved rule set details. Before starting replication, you can evaluate the rule set by previewing the tables that will be in-scope for replication. Management Console will display a list of the tables that satisfy the rule set criteria at the current moment. That is to say, what is actually in the database at the moment the preview occurs; changes in the database may result in the list of in-scope tables being different at the moment that replication is actually started than it was when previewed. After making changes to a rule set, restarting replication will result in a refresh being performed on all tables in the subscription that currently match your rule set criteria but didn't when the subscription was last mirrored. The refresh will be a structural refresh, meaning that the target tables will be dropped and recreated. Tables in the subscription that continue to match the modified rule set will begin mirroring. If you have marked a Table Capture Point for tables that match the rule set criteria, the capture point will be obeyed. The table will not be refreshed and replication will begin at the set point. Tables that no longer meet the criteria of a rule set will be excluded from replication, but will not be deleted from the target. See also: To To To To To change the name of a rule set on page 145 change the schema for a rule set on page 145 add tables to a rule set on page 145 remove tables from a rule set on page 145 change the structural replication value for a rule set on page 146
To edit a pattern for a rule set on page 146 To delete a pattern from a rule set on page 147
144
To change the name of a rule set

1. 2. 3. 4. 5. Click Configuration > Subscriptions. Select a subscription. Click Rules in the Table Mappings view. Select a rule set. Right-click and select Open Details.
6. Change the name of the rule set in the Rule Set Name box. 7. Click Save.
To change the schema for a rule set

5. Right-click and select Open Details. 6. Click Change Schema... 7. Select a new schema for the rule set. 8. Click OK. 9. Click Save.
To add tables to a rule set

1. Click Configuration > Subscriptions. 2. Select a subscription. 3. Click Rules in the Table Mappings view. 4. Select a rule set. 5. Right-click and select Open Details. 6. Click Add Table... next to the Include Tables list. 7. Select the tables to be included in the rule set. Tables already included in the rule set by pattern are listed; tables included by exact match will not be listed. 8. Click OK. 9. Click Add Table... next to the Exclude Tables list. 10. Select the tables to be excluded from the rule set. Tables already excluded in the rule set by pattern are listed; tables included by exact match will not be listed. 11. Click OK. 12. Click Save.
To remove tables from a rule set

1. 2. 3. 4. 5. 6. Click Configuration > Subscriptions. Select a subscription. Click Rules in the Table Mappings view. Select a rule set. Right-click and select Open Details. Select the tables in the Include Tables list that are to be removed from the rule set.
145
7. Click Delete. 8. Select the tables in the Exclude Tables list that are to be removed from the rule set. 9. Click Delete. 10. Click Save.
To change the structural replication value for a rule set

5. Right-click and select Open Details. 6. Enable or disable the Replicate structural changes only check box. 7. Click Save.
To edit a pattern for a rule set

1. Click Configuration > Subscriptions. 2. Select a subscription. 3. Click Rules in the Table Mappings view. 4. Select a rule set. 5. Right-click and select Open Details. 6. Select the pattern. 7. Click Edit Pattern... next to the Include Tables list. 8. Make any needed changes in the Pattern box. 9. Determine how to apply the pattern. Select one of the following options: v Match all tablesSpecifies that any defined patterns will be overridden and all tables will be considered for replication. v Matches the patternSpecifies that tables with names that match the pattern will be included in the rule set. v Starts with the patternSpecifies that tables with names that match the pattern at the beginning of their names will be included in the rule set. v Contains the patternSpecifies that tables with names that contain the pattern in any part of their names will be included in the rule set. v Ends with the patternSpecifies that tables with names that match the pattern at the end of their names will be included in the rule set. 10. Click OK. 11. Click Edit Pattern... next to the Exclude Tables list. 12. Make any needed changes in the Pattern box. 13. Determine how to apply the pattern. Select one of the following options: v Matches the patternSpecifies that tables with names that match the pattern will be excluded from the rule set. v Starts with the patternSpecifies that tables with names that match the pattern at the beginning of their names will be excluded from the rule set. v Contains the patternSpecifies that tables with names that contain the pattern in any part of their names will be excluded from the rule set. v Ends with the patternSpecifies that tables with names that match the pattern at the end of their names will be excluded from the rule set.
146
14. Click Save.
To delete a pattern from a rule set

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Click Configuration > Subscriptions. Select a subscription. Click Rules in the Table Mappings view. Select a rule set. Right-click and select Open Details. Select the pattern that you want to delete in the Include Tables list. Click Delete. Select the pattern that you want to delete in the Exclude Tables list. Click Delete. Click Save.
Copying rule sets

Copying rule sets is similar to copying a subscription except that it only copies the rule sets that you select to a new or existing subscription. Copying a subscription copies all Direct mappings and rule sets to a new or existing subscription. Copying rule sets is useful if you only want to copy a subset of the rule sets in a subscription. See also: To copy selected rule sets Related concepts Copying subscriptions on page 61 Copying selected table mappings on page 131
To copy selected rule sets

1. Click Configuration > Subscriptions. 2. Select a subscription. Click Rules in the Table Mappings view. Select one or more rule sets. Right-click and select Copy.... Enter a name for the subscription in the Name box. All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. 7. Enter a description for the subscription in the Description box. 8. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. 9. Click Next. 3. 4. 5. 6.
147
10. Select the source datastore for the new subscription from the New Source Datastore list. 11. Select the databases and owners for your new source datastore under New Name. 12. If you want to specify advanced settings, click Advanced Settings. 13. Click Next. 14. Select the target datastore for the new subscription from the New Target Datastore list. Note that subscriptions with rule-based table mappings can not be promoted when the source and target datastores are identical. 15. Review the copy settings and click Finish.
Exporting rule sets

Using InfoSphere CDC's export and import capabilities, you can prepare XML files that include details you have set on your subscription, and you can save these files on your local computer or elsewhere. You can also export selected rule sets in a subscription. See also: To export selected rule sets into an XML file Related concepts Exporting and importing subscriptions and selected table mappings on page 134
To export selected rule sets into an XML file

1. Click Configuration > Subscriptions. 2. Select the subscription with the rule sets you want to export. 3. 4. 5. 6. 7. Click Rules in the Table Mappings view. Select one or more rule sets. Right-click and select Export.... Enter the name for the XML file and click Save. Import the XML file that you have created into a subscription
Promoting rule sets

Use the Promote Rule Sets wizard to promote your selected rule sets to an existing or to a new subscription in a new environment. For example, you can promote your subscription from a development environment and into a production environment when you are ready to use that subscription in replication activities. Using the Promote Rule Sets wizard, you can: v Promote a Subscription to a New EnvironmentIn this scenario, you are promoting selected rule sets to a subscription in a new environment. For example, you may have projects that are exclusive for development or testing purposes. You can promote subscriptions into one of these environments. v Promote Changes to an Existing SubscriptionIn this scenario, you have made changes to rule sets in a subscription that has already been promoted to another environment. For example, the subscription may already exist in a project that you have reserved for testing subscriptions, but you may have made some minor changes to the rule sets for the subscription. To make sure the
148
subscription in the test environment includes the changes that you made, you need to promote your changes to the testing environment. Note: When promoting changes to an existing subscription, InfoSphere CDC maintains synchronization between your source and target tables and you do not need to set the log position in the new environment. However, if you are making changes that causes you to lose synchronization between your source and target tables (such as updating the definition of a source table), then InfoSphere CDC does not maintain the log position and you will have to resynchronize your source and target tables in the original and in the new environment. For more information on how to synchronize source and target tables in a table mapping, see Flagging a source table for refresh on page 343. See also: To promote selected rule sets to a new subscription To promote selected rule sets to an existing subscription on page 150 Related concepts Promoting subscription changes on page 377
To promote selected rule sets to a new subscription

1. Click Configuration > Subscriptions. 2. Select the subscription with the rule sets you want to promote. 3. 4. 5. 6. 7. Click Rules in the Table Mappings view. Select one or more rule sets. Right-click and select Promote.... Select Promote to a new subscription. Enter the name of the new subscription in the Name box.
All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. 8. Enter the description of the new subscription in the Description box. 9. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. 10. Click Next. 11. Select the name of the new source datastore from the New Source Datastore list. 12. Select the name of the database and owner from the New Name list. 13. If you want to specify advanced settings for the subscription, click Advanced Settings. Modify the following properties and click OK, then click Next. v Source IDSpecify the source ID for the new subscription. v TCP HostSpecify the TCP host that your source datastore will use to recognize the target datastore when the computer where InfoSphere CDC is installed has multiple network cards. This is useful if you want to specify a host that is different from the host that you specified in the Access Manager
149
perspective. The default option is Auto-select, which will automatically select the network card that can communicate with the target datastore. The host that you specified in theAccess Manager perspective also appears by default as well as any alias that you configured in the Datastore Properties dialog box. v Firewall PortSpecify a port number for the new subscription. v Mark subscription as persistentEnable if you want to specify that the subscription is persistent. A subscription can only be restarted automatically if it is enabled for persistency. v Propagation ControlClick Add and select the source ID for any subscription for which you want to prevent data from being replicated to the target. v Do not replicate data received from any subscriptionsEnable if you want to prevent replication from all subscriptions. v Select the datastore to handle the transferable workSpecify where transferable work will be performed, in order to minimize impact on the source or target datastore. 14. Select the name of the new target datastore from the New Target Datastore list. Note that subscriptions with rule-based table mappings can not be promoted when the source and target datastores are identical. 15. Review the list of changes and click Finish.
To promote selected rule sets to an existing subscription

1. Click Configuration > Subscriptions. 2. Select the subscription with the rule sets you want to promote. 3. Click Rules in the Table Mappings view. 4. Select one or more rule sets. 5. Right-click and select Promote.... 6. Select Promote changes to an existing subscription. 7. Select the subscription to which you want to promote changes from the Promote To list. 8. In the Mappings area you can select one of the following two options and click Next: v Replace all mappings in the existing subscriptionIndicates that the selected rule sets that you are promoting will replace all existing mappings in the existing subscription you are promoting to. For example, you plan on promoting table mappings from subscription Develop to subscription Test. Subscription Develop contains four rule sets: A, B, C, and D. A and B are selected for promotion to subscription Test. Subscription Test contains three rule sets: A, B, and Z. By selecting this option, rule sets A and B in subscription Develop will replace all of the existing rule sets in subscription Test. After promotion is complete, subscription Test will only contain rule sets A and B. Rule set Z will no longer exist in subscription Test. v Only replace the selected mappingsIndicates that only the selected table mappings and rule sets in the subscription being promoted will replace table mappings and rule sets (with identical names) in the existing subscription you are promoting to. All other table mappings and rule sets will remain in the subscription you are promoting to.
150
9.
10. 11. 12.
For example, you plan on promoting rule sets from subscription Develop to subscription Test. Subscription Develop contains four rule sets: A, B, C, and D. A and B are selected for promotion to subscription Test. Subscription Test contains three rule sets: A, B, and Z. By selecting this option, rule sets A and B in subscription Develop will only replace rule sets A and B in subscription Test. After promotion is complete, subscription Test will still contain three rule sets: A, B and Z. Confirm the source datastore and the name of the database and owner from which you want to promote the changes, then click Next. Note that subscriptions with rule-based table mappings can not be promoted when the source and target datastores are identical. Confirm the target datastore to which you want to promote the changes. Click View XML to confirm the location and attributes of the promoted subscription. Review the list of changes and click Finish.
Changing the refresh order of tables in a Rules-based subscription

Before replication begins for a Rules-based subscription, all in-scope tables that are not active are refreshed. You can determine the order in which InfoSphere CDC refreshes both the Rules-based and Direct Mapping tables in a subscription by moving tables that are in-scope for replication into groups. Each table you decide to move into a group is assigned a sequence number that InfoSphere CDC uses to refresh each table mapping in numerical order. This is useful if you want InfoSphere CDC to refresh your smaller tables before larger tables, or refresh your larger tables first. Any remaining table mappings that you did not add to a group are refreshed in an arbitrary order by InfoSphere CDC last. You can change the refresh order of tables only when the subscription isn't running. When you set a refresh order, it is not a permanent configuration setting. It is an operational setting, since the list of tables to be included for replication is dynamic and constantly changing. You are simply choosing the order to refresh the tables that are currently in-scope. The refresh order information for your Rules-based subscriptions will be deleted when the refresh is complete. If you mark a table capture point on a Rules-based table to which you have assigned a refresh order, the marked table will be removed from the refresh order and returned to the Ungrouped Tables list. See also: To change the refresh order of tables
To change the refresh order of tables

1. Ensure that you have ended any active replication on the subscription. 2. When setting up tables that have referential integrity constraints, ensure that the target tables are empty before starting replication. 3. Click Configuration > Subscriptions. 4. Select a subscription.
151
5. Right-click and select Refresh Order.... to create a group. 6. Click Repeat this step to create as many groups as you need. Grouped tables are refreshed first, in the order they are specified. All other tables are refreshed after grouped tables. 7. Select one or more tables from the Ungrouped Tables list. 8. Select the group to which you want to move the selected tables and click 9. Click OK. .
Previewing tables in-scope for DDL replication

After you have created rule sets for a subscription, you can use the Preview Tables Selected by Rules dialog box to see the tables that are in-scope for DDL replication. The dialog displays the names of all tables that match the criteria for all rule sets defined for this subscription. Using the icons on the toolbar, you can also flag for refresh or mark a table capture point for a selected table. These options are mutually exclusive. The display is sorted by schema, with the tables within that schema that will be included for replication listed below it. The total number of tables that are in-scope is displayed in the bottom left corner of the dialog. The Status column indicates the current replication status for the tables. There are three possible values: Active, Parked or Refresh. The Structure Only column indicates if the tables have been marked for structural refresh only (through the Replicate structural changes only option). If no tables match the criteria, the schema symbol will display a yellow warning icon: ( Please note that the results displayed in the preview window indicate the tables that match the criteria at the moment in time that the dialog was opened. The list of tables is static and will not be updated. To refresh the display, you will need to close and reopen the dialog. See also: To preview tables in a subscription that match rule sets Related concepts Marking a table capture point on a source table on page 348 Flagging a source table for refresh on page 343
To preview tables in a subscription that match rule sets

152
5. Right-click in the Table Mappings display area and select Show Rule Set Tables....
153
154
Customizing InfoSphere DataStage table mappings

If you are using InfoSphere DataStage, after you have mapped your tables to InfoSphere DataStage, you can customize your table mappings by creating derived columns, by filtering rows and columns, and by specifying how InfoSphere CDC converts character sets on source columns during replication: v Derived ColumnsUsed to create an expression that is evaluated by InfoSphere CDC on a source column. The results of the expression are sent to the target system, InfoSphere DataStage. v Multibyte and Unicode Character Set ConversionsUsed to specify how InfoSphere CDC converts character sets on source columns during replication. v Filtering Rows and ColumnsUsed to include or exclude rows or columns for replication. When customizing your InfoSphere DataStage table mappings in Management Console, you will have access to a subset of functionality that is normally available for database targets. Functionality that is not available for InfoSphere DataStage table mappings is not displayed or disabled. Setting properties for a subscription that targets InfoSphere DataStage Related concepts Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187 Filtering rows and columns on page 315 Related tasks To add a derived column on page 179
Setting properties for a subscription that targets InfoSphere DataStage

After you have mapped tables for a subscription that uses InfoSphere CDC for InfoSphere DataStage as a target datastore, you can modify the following subscription properties: v GeneralAppears for both the Flat File and the Direct Connect connection methods for table mappings. Batch size thresholdsBalances the need to get data applied to the target quickly against the need to minimize resource utilization. You can set the batch size threshold property to run InfoSphere DataStage jobs less frequently and process larger amounts of data. Large object truncation size for character and binary dataAffects the fixed record length used by an InfoSphere DataStage job that processes the changed data. You should set this property to as small a size as possible while still retaining enough of the data from the large columns to meet your business needs. v File Name FormatAppears only for subscriptions using the Flat File connection method for table mappings. Include the record count in the file nameEnable this check box to include the record count in the file name of the Flat File output for the InfoSphere DataStage job. v Direct ConnectAppears only for subscriptions using the Direct Connect connection method for table mappings.
155
Project NameUsed by InfoSphere DataStage to uniquely identify the information sent by InfoSphere CDC for processing. Job NameUsed by InfoSphere DataStage to uniquely identify the information sent by InfoSphere CDC for processing. Connection KeyUsed by InfoSphere DataStage to authenticate the connection and communicate with InfoSphere CDC to process the uniquely identified job. Auto-start InfoSphere DataStage JobEnable this after setting the three preceeding settings to start the InfoSphere DataStage job from InfoSphere CDC. See also: To specify batch size thresholds for an InfoSphere DataStage subscription To specify large object truncation size for an InfoSphere DataStage subscription To specify the file name format for an InfoSphere DataStage subscription on page 157 To specify Direct Connect settings for an InfoSphere DataStage subscription on page 157 Related concepts InfoSphere DataStage system parameters on page 668 Related tasks To specify Direct Connect settings for an InfoSphere DataStage subscription on page 157
To specify batch size thresholds for an InfoSphere DataStage subscription

1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select InfoSphere DataStage > InfoSphere DataStage Properties. 3. Enter the number of rows that can be changed before subscription data is sent to InfoSphere DataStage in the Number of rows box. The default value is 100000. 4. Enter the amount of time that will elapse before subscription data is sent to InfoSphere DataStage in the Time (seconds) box. The default value is 600. The values that you specify are used by InfoSphere CDC to determine when a flat file is complete and is made available to InfoSphere DataStage for processing. 5. Click OK.
To specify large object truncation size for an InfoSphere DataStage subscription

1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select InfoSphere DataStage > InfoSphere DataStage Properties. 3. Enter the truncation point for large character data in the Character data (# characters) box. The default value is 8000.
156
4. Enter the truncation point for large binary data in the Binary data (# bytes) box. The default value is 8000. 5. Click OK.
To specify the file name format for an InfoSphere DataStage subscription

1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select InfoSphere DataStage > InfoSphere DataStage Properties. 3. Enable the Include record count in file name check box. 4. Click OK.
To specify Direct Connect settings for an InfoSphere DataStage subscription

1. Click Configuration > Subscriptions. 2. Select the desired subscription and ensure that it is mapped using the Direct Connect connection method. 3. Right-click on the subscription and select InfoSphere DataStage > InfoSphere DataStage Properties. 4. Enter values for the following: v Project Name: v Job Name: v Connection Key: 5. If you want to use the auto-start options, enable the Auto-start InfoSphere DataStage Job check box.
Customizing InfoSphere DataStage table mappings
157
158
Understanding data types supported by InfoSphere CDC

When you map source and target columns for replication in Management Console, you should know which data types are compatible. For more information on how to map tables for replication, see the "Mapping tables" section in your Management Console documentation. In this section, you will learn: Supported data types Supported column mappings on page 163
Supported data types

Each InfoSphere CDC replication engine supports a variety of data types, as indicated by the table below. The following considerations and restrictions exist for the replication of data types: v InfoSphere CDC casts data into and out of the database with VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX), TEXT, IMAGE, NTEXT, XML, and SQL_VARIANT data types. Due to this limitation imposed by the database, mirroring and refresh performance may be reduced when replicating these data types. In addition to the listed data types, InfoSphere CDC supports Alias Data Types (ADT) in all versions of Microsoft SQL Server.
v User-defined data types that are not aliases of standard database data types cannot be replicated by InfoSphere CDC. Tables where unsupported data types are present will not be included in the catalog and are not available for mapping. v v InfoSphere CDC does not provide support for columns of type BFILE or CFILE.
If you are replicating the TIMEZONE data type and the source and target have a different TIMEZONE value, the data replicated will be adjusted and use the source TIMEZONE value. v InfoSphere CDC provides support for the ROWID and XML data types and this includes the use of SQL*Loader to load the data into the source table. v v and SBCS v InfoSphere CDC can replicate IMAGE, TEXT, NTEXT, VARBINARY(MAX), NVARACHAR(MAX), and VARCHAR(MAX) data types of unlimited length. Binary data in derived expressions is not supported You cannot map a binary type target table column to a constant or journal control field Binary data columns are not supported for value translations. InfoSphere CDC does not support the replication of data types INTERVAL, TIMESPAN, and TIME WITH TIMEZONE. The LOAD utility is not supported with LOB and XML columns. Support for CHAR and VARCHAR data types includes BIT, MIXED
v v v v
159
You cannot map binary data types to a Netezza target table column.
InfoSphere CDC can replicate data in Large Object (LOB) columns available in your database. These columns contain character or image data that are larger than scalar data types. For instance, some tables contain columns for long textual comments or bitmap images. InfoSphere CDC can replicate LOB data types of all lengths supported by the source and target DBMS. When replicating LOB data, consider the following: v InfoSphere CDC version 6.3 and earlier does not support the replication of LOB data types encoded in multibyte character sets (MBCS). Replication of single-byte character set (SBCS) encoded LOB data types is supported. v InfoSphere CDC for z/OS version 6.2 and earlier running on a source or target does not support the replication of large object (LOB) data. v InfoSphere CDC replicates LOB data types by querying the source database directly for every row change which may affect product performance in some situations. To avoid this scenario, remove LOB columns from table mappings in Management Console. v Netezza does not contain LOB data types. If you have replicated data types NCLOB or CLOB from a source InfoSphere CDC product, then you must map these to character data types in the target table in the Netezza database in Management Console. InfoSphere CDC can replicate BLOB, CLOB, LONG, LONG RAW, and NCLOB data types of unlimited length. InfoSphere CDC can replicate BLOB and CLOB data types of unlimited length.
v v v
InfoSphere CDC can replicate IMAGE, TEXT, NTEXT, VARBINARY(MAX), NVARCHAR(MAX), and VARCHAR(MAX) data types of unlimited length. v There is no limit as to the total length of all LOB columns in a table when replicating LOB columns. v LOB columns are read from the database at the time of replication. Therefore, only the current image of a LOB column field in a source table will be sent at the time of replication. v You cannot map LOB columns in a source table to key columns in a target table. v You cannot define LOB columns as key columns in a target table. v You cannot reference LOB columns in row-filtering expressions. v LOB data types are truncated before sending them to an expression defined for a derived column. v LOB data types are truncated before sending them to target row-level user exits. v InfoSphere CDC provides support for traditional LOBs (known as BASICFILE LOBs in Oracle 11.1 and higher). It also supports LOBs stored as SECUREFILE with the following options: DEDUPLICATE/KEEP_DUPLICATES, COMPRESS/NOCOMPRESS or ENCRYPT/DECRYPT. LOB, CLOB AND DBCLOB columns are not supported for value translations. v LOB, BINARY AND VARBINARY type source derived columns are not supported
160
You cannot pass LOB columns to user exits
InfoSphere CDC can replicate data in XML columns available in your database. When replicating XML data, consider the following: InfoSphere CDC for z/OS version 6.2 and earlier running on a source or target does not support the replication of XML data. DB2 for LUW version 9.8 does not support the replication of XML v data. v XML data types are not supported in non-nullable columns on target tables. v XML data types are supported in nullable columns on target tables v v You cannot map XML columns in a source table to key columns in a target table. v You cannot define XML columns as key columns in a target table. v You cannot reference XML columns in derived or row-filtering expressions. v XML columns are not supported for Conflict Detection and Resolution operations v XML columns are not supported for value translations v XML columns are not supported for code page translation v XML columns are not supported for code page overrides, but they will be translated, if required. You cannot pass XML columns to user exits
Supported by replication engine DB2 LUW BIGINT BIGSERIAL BINARY BINARY_DOUBLE BINARY_FLOAT BIT BLOB BOOLEAN BOOL BYTE BYTEINT CHAR CHARACTER CHARACTER FOR BIT DATA CHARACTER VARYING CLOB DATE DATE DMY DATE EUR DATE ISO DATE JUL DATE MDY DATE USA DATE YMD U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U DB2 for DB2 for z/OS i U U Informix Dynamic Server U U U U U U U U U Microsoft SQL Server U Oracle Redo Oracle Trigger
v XML type source derived columns are not supported v

Table 1. Supported data types
Data type
Netezza U
Sybase U
Teradata
161
Table 1. Supported data types (continued)

Data type DB2 LUW DATETIME DATETIME HOUR TO SECOND DATETIME YEAR TO FRACTION(5) DATETIME2 DATETIMEOFFSET DBCLOB DBCS EITHR DBCS GRAPHIC DBCS ONLY DBCS OPEN DECIMAL DOUBLE DOUBLE PRECISION FLOAT FLOAT(p) GRAPHIC HEX (fixed length only) IMAGE INT8 INTEGER INTERVAL INTERVAL DAY TO SECOND INTERVAL DAY TO MONTH LOBs LONG RAW LONG VARCHAR LONG VARCHAR FOR BIT DATA LONG VARGRAPHIC LVARCHAR MONEY NCHAR NCLOB NTEXT NUMERIC NUMERIC(p, s) NUMERIC(p) NVARCHAR NVARCHAR2 NVARCHAR(MAX) PACKED DECIMAL RAW REAL ROWID ROWVERSION SERIAL SERIAL8 U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U DB2 for DB2 for z/OS i Supported by replication engine Informix Dynamic Server Microsoft SQL Server U Oracle Redo Oracle Trigger
Netezza
Sybase U
Teradata
162
Table 1. Supported data types (continued)

Data type DB2 LUW SMALLDATETIME SMALLFLOAT SMALLINT SMALLMONEY SQL_VARIANT TEXT TIME TIMETZ TIMEZONE TIME EUR TIME HMS TIME ISO TIME JIS TIME USA TIMESTAMP TIMESTAMP WITH TIME ZONE TIMESTAMP WITH LOCAL TIME ZONE TINYINT UNICHAR UNIQUEIDENTIFIER UNITEXT UNIVARCHAR VARBINARY VARBINARY(MAX) VARBYTE VARCHAR VARCHAR FOR BIT DATA VARCHAR(MAX) VARCHAR2 VARGRAPHIC XML XMLTYPE ZONED NUMERIC U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U DB2 for DB2 for z/OS i Supported by replication engine Informix Dynamic Server Microsoft SQL Server U Oracle Redo Oracle Trigger
Netezza
Sybase U
Teradata
Supported column mappings

This section indicates the table mappings that you can create in Management Console with supported data types. InfoSphere CDC for DB2 for LUW
Source data types BIGINT BLOB CHAR Supported table mappings Any numeric, binary, or BLOB data type Any binary or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type
163
Source data types CHARACTER FOR BIT DATA CLOB DATE DBCLOB DECIMAL DOUBLE PRECISION FLOAT GRAPHIC INTEGER LONG VARCHAR LONG VARCHAR FOR BIT DATA LONG VARGRAPHIC NUMERIC REAL SMALLINT TIME TIMESTAMP VARCHAR VARCHAR FOR BIT DATA VARGRAPHIC XML
Supported table mappings Any binary or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type Any date data type Any character, variable character, CLOB, DBCLOB, or BLOB data type Any numeric data type Any numeric, binary, or BLOB data type Any numeric, binary, or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type Any numeric, binary, or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type Any binary or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type Any numeric, binary, or BLOB data type Any numeric, binary, or BLOB data type Any numeric, binary, or BLOB data type Any time data type Any date, time, or timestamp data type Any character, variable character, CLOB, binary, or BLOB data type Any binary or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type XML, CLOB, or any character type
InfoSphere CDC for z/OS For the purposes of supported table mappings, the following text offers a definition of binary and text fields: v A text field is any CHAR, VARCHAR, GRAPHIC, VARGRAPHIC, BINARY, VARBINARY, BLOB, CLOB or DBCLOB column which has a CCSID (code page) or an XML column. By default, columns will have a CCSID or not, based on their definition in DB2. This CCSID, or lack of it, can be overridden using the Encoding tab in the Mapping Details view. Any text field can be mapped to any other text field. v A binary field is any CHAR, VARCHAR, GRAPHIC, VARGRAPHIC, BINARY, VARBINARY, BLOB, CLOB or DBCLOB column which does not have a CCSID (code page). By default, columns will have a CCSID or not, based on their definition in DB2. This CCSID, or lack of it, can be overridden using the Encoding tab in the Mapping Details view. Any binary field can be mapped to any other binary field.
164
Source data types BIGINT BINARY BLOB CHAR (for BIT) CHAR (for MIXED) CHAR (for SBCS) CLOB DATE DBCLOB DECIMAL FLOAT GRAPHIC INTEGER ROWID
Supported table mappings when a code page is assigned N/A Any text field Any text field Any text field Any text field Any text field Any text field N/A Any text field N/A N/A Any text field N/A N/A
Supported table mappings when a code page is not assigned N/A Any binary field Any binary field Any binary field Any binary field Any binary field Any binary field N/A Any binary field N/A N/A Any binary field N/A N/A
Supported table mappings when a code page is not applicable Any numeric data type N/A N/A N/A N/A N/A N/A Any date data type
Any numeric data type Any numeric data type
Any numeric data type For DB2 for z/OS to DB2 to z/OS mappings, a source ROWID column can only be mapped to a target ROWID column. Column mappings to any other target database permit mappings to binary data types. Any numeric data type Any time data type Any date, time, or timestamp data type N/A N/A N/A N/A N/A Any text field where the source field contains a valid XML document
SMALLINT TIME TIMESTAMP VARBINARY VARCHAR (for BIT) VARCHAR (for MIXED) VARCHAR (for SBCS) VARGRAPHIC XML
N/A N/A N/A Any text field Any text field Any text field Any text field Any text field N/A
N/A N/A N/A Any binary field Any binary field Any binary field Any binary field Any binary field N/A
165
InfoSphere CDC for Informix

Source data types BIGINT BIGSERIAL BLOB BOOLEAN CHAR CHARACTER CHARACTER VARYING CLOB DATE DATETIME HOUR TO SECOND DATETIME YEAR TO FRACTION(5) DECIMAL FLOAT INT8 INTEGER LVARCHAR MONEY NCHAR NUMERIC NVARCHAR SERIAL SERIAL(8) SMALLFLOAT SMALLINT VARCHAR Supported table mappings Any numeric data type Any numeric data type Any BLOB data type. Any Boolean data type Any character or variable character data type Any character or variable character data type Any character or variable character data type Any character, variable character, CLOB, binary, or BLOB data type Any date data type Any date data type Any date data type Any numeric data type Any numeric data type Any numeric data type Any numeric data type Any character or variable character data type Any numeric data type Any character or variable character data type Any numeric data type Any character or variable character data type Any numeric data type Any numeric data type Any numeric data type Any numeric data type Any character or variable character data type
InfoSphere CDC for Microsoft SQL Server

Source data types BIGINT BINARY BIT CHAR DATETIME Supported table mappings Any numeric data type Any binary or BLOB data type Any numeric data type Any character, variable character, CLOB, binary, or BLOB data type Any datetime, date, or time data type
166
Source data types DATE DATETIME2 DATETIMEOFFSET DECIMAL FLOAT IMAGE INTEGER MONEY NCHAR NTEXT NVARCHAR NVARCHAR(MAX) NUMERIC REAL ROWVERSION SMALLDATETIME SMALLINT SMALLMONEY SQL_VARIANT TEXT TIME TINYINT UNIQUEIDENTIFIER VARBINARY VARBINARY(MAX) VARCHAR(MAX) XML
Supported table mappings Any datetime, date, or time data type Any datetime, date, or time data type Any datetime, date, or time data type Any numeric data type Any numeric data type Any BLOB data type. Any numeric data type Any numeric data type Any character, variable character, CLOB, binary, or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type Any numeric data type Any numeric data type Any binary or BLOB data type Any datetime, date, or time data type Any numeric data type Any numeric data type sql_variant Any character, variable character, CLOB, binary, or BLOB data type Any datetime, date, or time data type Any numeric data type Any binary or BLOB data type Any binary or BLOB data type Any binary or BLOB data type Any character, variable character, CLOB, binary, or BLOB data type XML, CLOB, or any character type
InfoSphere CDC for Oracle databases

Source data types BLOB Supported table mappings Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type
CHAR
167
Source data types CLOB
Supported table mappings Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any date or timestamp data type Any numeric data type Any numeric data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type
DATE FLOAT INTEGER INTERVAL DAY TO SECOND
INTERVAL DAY TO MONTH
LONG RAW
Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any numeric data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any numeric data type Any date or timestamp data type Any date or timestamp data type Any date or timestamp data type Any date or timestamp data type
LONG VARCHAR
NCHAR
NCLOB
NUMERIC NVARCHAR2
RAW
REAL TIMESTAMP TIMESTAMP WITH TIME ZONE TIMESTAMP WITH LOCAL TIME ZONE TIMEZONE
168
Source data types VARCHAR2
Supported table mappings Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type
XMLTYPE
InfoSphere CDC for Oracle databases (trigger)

Source data types BLOB Supported table mappings Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any date or timestamp data type Any numeric data type Any numeric data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type LONG RAW Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type
CHAR
CLOB
DATE FLOAT INTEGER INTERVAL DAY TO SECOND
INTERVAL DAY TO MONTH
LONG VARCHAR
NCHAR
169
Source data types NCLOB
Supported table mappings Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any numeric data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any numeric data type Any date or timestamp data type Any date or timestamp data type Any date or timestamp data type Any date or timestamp data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type Any character, variable character, LOB, interval DTS, interval YTM, LONG RAW, LONG VARCHAR, NCHAR, NVARCHAR, RAW, or XML type data type
NUMERIC NVARCHAR2
RAW
REAL TIMESTAMP TIMESTAMP WITH TIME ZONE TIMESTAMP WITH LOCAL TIME ZONE TIMEZONE VARCHAR2
XMLTYPE
InfoSphere CDC for Sybase databases

Source data types BIGINT BINARY BIT CHAR DATE DATETIME DECIMAL FLOAT IMAGE INTEGER MONEY NCHAR NTEXT Supported table mappings Any numeric data type Any binary or LOB data type Any numeric data type Any character, variable character, or binary data type Any date or datetime data type Any date or datetime data type Any numeric data type Any numeric data type Any binary or LOB data type Any numeric data type Any numeric data type Any character, variable character, or binary data type Any character, variable character, or binary data type
170
Source data types NVARCHAR NUMERIC REAL SMALLDATETIME SMALLINT SMALLMONEY TEXT TIME TIMESTAMP TINYINT UNICHAR UNITEXT UNIVARCHAR VARBINARY VARCHAR
Supported table mappings Any character, variable character, or binary data type Any numeric data type Any numeric data type Any date or datetime data type Any numeric data type Any numeric data type Any character, variable character, or binary data type Any time data type Any character, variable character, or binary data type Any numeric data type Any character, variable character, or binary data type Any character, variable character, or binary data type Any character, variable character, or binary data type Any binary or LOB data type Any character, variable character, or binary data type
InfoSphere CDC for Teradata

Source data types BYTE BYTEINT CHAR DATE DECIMAL DOUBLE PRECISION FLOAT GRAPHIC INT (or INTEGER) INTERVAL LONG VARCHAR NUMERIC REAL SMALLINT TIME Supported table mappings Any character, variable character, GRAPHIC, or VARGRAPHIC data type Any numeric data type Any character, variable character, GRAPHIC, or VARGRAPHIC data type Any date or timestamp data type Any numeric data type Any numeric data type Any numeric data type Any character, variable character, GRAPHIC, or VARGRAPHIC data type Any numeric data type Any numeric data type Any character, variable character, GRAPHIC, or VARGRAPHIC data type Any numeric data type Any numeric data type Any numeric data type Any time or timestamp data type
171
Source data types TIMESTAMP VARBYTE VARCHAR VARGRAPHIC
Supported table mappings Any date, time, or timestamp data type Any character, variable character, GRAPHIC, or VARGRAPHIC data type Any character, variable character, GRAPHIC, or VARGRAPHIC data type Any character, variable character, GRAPHIC, or VARGRAPHIC data type
172
Mapping columns
After mapping your tables using the Map Tables wizard, you can use the Column Mappings tab in the Table Mappings view to customize what items you want to map to target columns in a subscription. If you have mapped your tables using any mapping type, then most or all of your target columns are already mapped to source columns that have identical names and attributes. However, using the Columns Mappings tab, you can customize the kind of information you want to map to a target column and populate it with. Database defaults, if defined in the target database, will be used automatically during the mapping process if there is no compatible (that is to say, identically named) source column for the target column. In this section, you will learn: Mapping source columns to target columns Mapping journal control fields to target columns on page 174 Mapping expressions to target columns on page 175 Mapping source and target columns automatically on page 176 Mapping initial values to target columns on page 177 Adding and mapping derived columns to target columns on page 178
Mapping source columns to target columns

Manually map any remaining target columns left by the Map Table wizard so that they are populated with data during replication activities. For example, the Map Tables wizard may have left certain target columns unmapped if the column names between the source and target tables did not match, or if the data types between columns are not compatible. See also: To map a source column to a target column
To map a source column to a target column

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... You may see target columns that are not mapped to any source columns. These target columns are mapped with an initial default value such as BLANK, CURRENT DATE, NULL, and so on. 5. Click the Column Mappings tab. 6. Expand the Source Columns list and select a source column. 7. Ensure that the data types are compatible by enabling the Show Column Data Types check box. You can map source columns to target columns only if the data types between both are compatible.
173
8. Drag and drop the source column to the Source area to map it to a target column. 9. Click Save. ) displays next to any source column that is mapped to a A check mark ( target column. When you start replication on the subscription, InfoSphere CDC populates the target column with data from the source column. Related concepts Mapping source columns to target columns on page 173 Starting and ending replication on page 355
Mapping journal control fields to target columns

Journal control fields let you populate a target column with system information about the inserts, updates, or deletes taking place on your source tables. If you decide to map a journal control field to a target column, then each time there is a change in your source table, InfoSphere CDC translates the journal control field into system information and populates this information into the mapped target column during replication. For example, you may want to audit the name of the user that inserts a row in a source table. To capture this information in a target column, map the &USER journal control field to the appropriate target column. Journal control fields are especially useful when you want to audit the changes that are taking place in your source environment. These are available to you when you select LiveAudit as your mapping type. See also: To map a journal control field to a target column Related concepts About journal control fields on page 197 Mapping using LiveAudit on page 95
To map a journal control field to a target column

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Column Mappings tab. 6. Expand the Journal Control Fields list and select a journal control field that is compatible with the data type of the target column. 7. Drag and drop the journal control field to Source area to map it to a target column. 8. Click Save. When you start replication on the subscription, InfoSphere CDC populates the target column with system information.
174
Related concepts Mapping journal control fields to target columns on page 174
Mapping expressions to target columns

Mapping expressions to a target columnExpressions are stored and evaluated on target columns. For example, you can create an expression that: v Converts integer data on the source column to character data using the column function %TOCHAR. An expression such as %TOCHAR(OrderID, 6) would convert integer data to a string of six characters in the source column OrderID so that it is compatible with the target column that you want to populate. v Calls a stored procedure that you have configured in a user exit program. You can specify an expression that contains a valid call to the %STPROC column manipulation function. If you are calling a stored procedure that is not owned by the InfoSphere CDC user, you must provide the name in the form <schema>.<stored procedure name>. Mapping accumulation and deduction expressions to a target columnIf you have mapped your tables using Summarization in the Map Tables wizard, then you can map accumulation or deduction expressions to a target column. When you map tables for summarization, the target table is largely a repository of numerical data increments or decrements in response to source row-level operations transferred by refresh or mirroring activity. For example, if you have a target column such as REVENUE and you want the value in this column to increment each time a product gets sold in the SALESAMOUNT source column, then you can map SALESAMOUNT to REVENUE. Drag and drop the source column from the list beside the target column to which you want to map. Considerations in mapping expressions to target columnsWhen you are mapping expressions to target columns, keep in mind that many databases have column name length limitations, which can affect how some expressions, user exits, and derived columns are handled. Column name length limitations can cause InfoSphere CDC to describe a column alias to the target when the source column name length exceeds the column name length limit on the target. The restriction is 30 characters for most InfoSphere CDC compatible databases (Informix, IBM DB2 LUW, Oracle, or Sybase prior to version 15.0), with two exceptions: v Microsoft SQL Server 128 characters v Sybase 15.0 and later 255 characters See also: To map an expression to a target column To accumulate or deduct numeric data on a target column on page 176 Related concepts Mapping to summarize data on page 105 Related tasks To configure a derived column or an expression that calls %STPROC (Oracle and Sybase) on page 231
To map an expression to a target column

1. Click Configuration > Subscriptions. 2. Select the subscription.
Mapping columns
175
3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Column Mappings tab. 6. Expand the Expressions list and drag and drop New Expression to the target column you want to map. 7. Build an expression. 8. Click OK. You should see the expression mapped to the target column on the Column Mappings tab. 9. Click Save. When you start replication, InfoSphere CDC evaluates the expression on the target column. Related concepts Mapping expressions to target columns on page 175
To accumulate or deduct numeric data on a target column

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapped for Summarization 4. Right-click and select Open Details.... 5. Click the Column Mappings tab. 6. Depending on which source columns you want to summarize data, map your source columns to target columns. 7. Expand the Summarization list and drag and drop either Accumulation or Deduction expressions on the source and target column mapping. You can also build an expression that summarizes data. 8. Select the source column and click OK. Depending on how you want to summarize data, the source column in the list updates with a plus or minus sign. 9. Click Save. When you start replication on the subscription, InfoSphere CDC accumulates or deducts the summarized data in response to row-level operations occurring on the source table. Related concepts Mapping expressions to target columns on page 175
Mapping source and target columns automatically

Use the Map Columns Automatically dialog box to customize how you want to map source and target columns. For example, you may have wanted to map a particular target column to a source column, but because the column names did not match, the Map Tables wizard did not map them as you wanted. The Map Tables wizard cannot map a source column such as LOC to the target column LOCATION. Instead, you can map columns using a different mapping mode based on criteria such as ordinal position. See also: To map columns automatically on page 177
176
To map columns automatically

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Column Mappings tab. 6. Click Auto Map. 7. Select one of the following mapping modes: v Original mappingMaps columns based on changes made on the Column Mapping tab before you opened the Map Columns Automatically dialog box. v Ordinal positionMaps columns based on the order of columns in the source and target tables. The first column in the target table is mapped to the first column in the source table, the second column in the target table is mapped to the second column in the source table, and so on. If the number of columns in the target table is greater than the number of the columns in the source table, then initial values are used for trailing columns in the target table. If the number of columns in the source table is greater than the number of columns in the target table, then trailing columns in the source table remain unmapped. You can only map by ordinal position provided the data types are compatible. v Name to nameMaps columns based on matching column names. For example, if a column in the source table is called EMPNAME, then this column is automatically mapped to the column in the target table called EMPNAME. v Name to descriptionMaps columns based on matching target column names in source column descriptions. This is useful when you are working on an IBM i database platform and you need to map the source table names to target columns. 8. Click OK. 9. Click Save. You should see your target columns mapped in the mode you selected on the Column Mappings tab. When you start replication on the subscription, InfoSphere CDC populates the target columns using the mapping mode you set. Related concepts Mapping source and target columns automatically on page 176
Mapping initial values to target columns

Use the Column Mappings tab to map initial values to unmapped target columns. After you have mapped your tables using the Map Tables wizard, there may be target columns that remain unmapped. Target columns can remain unmapped if the source and target column names do not match, or if there is a greater number of target columns than source columns. For these target columns, you can define an initial value such as a constant to populate the target column, or use the default value of the target column as specified in your RDBMS. See also: To define an initial value for a target column on page 178
Mapping columns
177
To define an initial value for a target column

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Column Mappings tab. You will see any unmapped target columns. 6. Place your cursor beside the target column that you want to populate with an initial value, and click the Initial Value column. to open the Set Initial Value dialog box. 7. Click 8. Select one of the following options: v ConstantPopulates the target column with a constant. The constant is limited to 25 characters. If you select this option, you need to enter a constant in the Constant box. v NullPopulates the target column with a null value. The data type of the target column must be nullable. v BlankPopulates the target column with a blank character. The data type of the target column must be character or a binary data type. v ZeroPopulates the target column with a value of zero. The data type of the target column must be numeric. v Database DefaultPopulates the target column with the default specified in your RDBMS. Whenever a row gets inserted into the target table, the value that populates this column is determined from the column defaults defined in your RDBMS. v Current DatePopulates the target column with the current date. The data type of the target column must be datetime. If your subscription uses InfoSphere CDC for z/OS as a target datastore, and you have mapped your tables using the LiveAudit mapping type, then both the before image and the after image of an update operation are populated with the same current date. v Read OnlyIndicates that the column is Read Only and cannot be populated with an initial value. 9. Click OK. 10. Click Save. Related concepts Mapping initial values to target columns on page 177
Adding and mapping derived columns to target columns

Derived columns let you move the processing of an expression from the target instance to the source instance. For example, you may have already defined an expression that concatenates the values of two source columns, FIRSTNAME and LASTNAME, and mapped this expression to a target column named called FULLNAME. When you start replication, InfoSphere CDC evaluates the expression on the target instance and stores the results in the FULLNAME target column.
178
However, it may become necessary in your environment to move the processing of this expression to the source instance. Using this same example, you can build a derived column on the source table named FULLNAME and define an expression that concatenates the values of the two source columns FIRSTNAME and LASTNAME. You can then map the derived column named FULLNAME to the target column named FULLNAME. When you start replication, InfoSphere CDC evaluates the expression on the source instance and sends the results to the target column. You can also create a derived column to: v Extract characters from string data by using functions such as %SUBSTRING, and then store the result in a derived column. For example, you can extract a person's initial from a column named FIRSTNAME, by using the expression SUBSTRING(FIRSTNAME,1,1). v Call a stored procedure that you have configured in a user exit program. You can specify an expression that contains a valid call to the %STPROC column manipulation function. If you are calling a stored procedure that is not owned by the InfoSphere CDC user, you must provide the name in the form <schema>.<stored procedure name>. v Retrieve information from a lookup table using %GETCOL. You can create a derived column on the source table using %GETCOL so that you can retrieve data from a lookup table. You can then map the source table using one-to-many consolidation. In each of these scenarios, you can then map the derived column to the appropriate target column. InfoSphere CDC will evaluate the expression on the source table and send the results to the target column. Many databases have column name length limitations, which can affect how some expressions, user exits, and derived columns are handled. Column name length limitations can cause InfoSphere CDC to describe a column alias to the target when the source column name length exceeds the column name length limit on the target. The restriction is 30 characters for most InfoSphere CDC compatible databases (Informix, IBM DB2 LUW, Oracle, or Sybase prior to version 15.0), with two exceptions: v Microsoft SQL Server 128 characters v Sybase 15.0 and later 255 characters Since the derived expression is evaluated each time a change is replicated to the target table, the complexity of the expression can affect overall performance. See also: To add a derived column To map a derived column to a target column on page 180 To modify a derived column on page 181 To delete a derived column on page 181
To add a derived column

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column.
Mapping columns
179
Right-click and select Open Details.... Click the Column Mappings tab. Expand the Source Columns list and double-click New Derived Column. If you already have a source column in your RDBMS on which you want to base the properties of your derived column, click Copy Column and select the column from the list of tables. The properties of this column (the data type, length, and any precision) are used as the properties of your derived column. 8. Enter a name for the derived column in the Name box. This name must be unique. 9. Enter a brief description of the derived column in the Description box. 10. Select a data type of the result from the Data Type list. 4. 5. 6. 7. 11. Enter the maximum length for the returned value in the Length box. 12. Select an evaluation frequency: v After Image OnlySelect this option when you want InfoSphere CDC to evaluate the expression in the derived column for the after image of the source table. v Before and After ImagesSelect this option when you want InfoSphere CDC to evaluate the expression in the derived column for both the before and after images of the source table. 13. If you selected the After Image Only value, evaluate it for performance reasons. Derived columns and the expressions you build for them are evaluated on source tables. If you selected the Before and After Images (*BTH) value, an evaluation is only necessary when you are performing conflict detection and resolution, which requires the before image to recognize conflicts, or when you are auditing so that you can audit the full before image. You also need to select this evaluation frequency if the target column to which you mapped the derived column is a primary key column. This maintains database integrity. Derived columns and the expressions you build for them are evaluated on source tables. Click Editor to build the expression for the derived column. Click Verify to verify the syntax of the expression. Click OK to return to the Define Derived Column dialog box.
14.
15. 16. 17.
18. Click OK. 19. Click Save.
To map a derived column to a target column

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Column Mappings tab. 6. Expand the Source Columns list, and drag and drop the derived column and map it to the appropriate target column. 7. Click Save.
180
When you start replication on the subscription, InfoSphere CDC populates the target column with the results stored in the derived column. Related concepts Adding and mapping derived columns to target columns on page 178 Related tasks To add a derived column on page 179 To modify a derived column To delete a derived column
To modify a derived column

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Column Mappings tab. 6. Expand the Source Columns list, select and right-click on an existing derived column and click Modify Derived Column. 7. Make the necessary changes and click OK. 8. Click Verify to ensure the expression is valid. 9. Click Save. When you start replication on the subscription, InfoSphere CDC populates the target column with the results stored in the derived column. Related concepts Adding and mapping derived columns to target columns on page 178 Related tasks To add a derived column on page 179 To delete a derived column
To delete a derived column

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Column Mappings tab. 6. Expand the Source Columns list, select and right-click on an existing derived column and click Delete Derived Column. 7. Click Save. Related concepts Adding and mapping derived columns to target columns on page 178 Related tasks To end replication on page 362 To add a derived column on page 179 To modify a derived column
Mapping columns
181
182
Setting data translations on column mappings

Use the Translation tab to add, modify, and delete a data translation. When you add a data translation and start replication, InfoSphere CDC converts data from the source columns into the new data you set for a mapped target column. You can also import and export data translations. In this section, you will learn: Setting data translations Importing and exporting data translations on page 185
Setting data translations

Management Console lets you translate specific data in your source columns to new data to mapped target columns. For example, you may have a source column called CITY containing entries like NY, TO, and LON: codes that you want translated to a target column in their full names (New York, Toronto, and London). By specifying data translations, you can convert specific data values during data replication. You can define data translations for different data types and should only be used when there is a limited number of translations, such as translating product codes to their descriptions. If you need to convert numerical or date information (where the number of possible data types are limitless), it is best to use an appropriate column function or write a user exit program to convert this kind of information. Before adding a data translation, consider the following: You can add a data translation for columns that contain integer data. However, InfoSphere CDC does not support translations that convert to or from fractional data. For example, InfoSphere CDC supports translations to and from 1 and 100, but does not support translations to and from 1.01 and 100.01. v You cannot add a data translation for date, time and timestamp data types. Only character and integer numeric data types are supported. v v If you use fractional data to represent whole numbers (for example, 1.0 and 100.0), then InfoSphere CDC translates these whole numbers if you have defined corresponding integer translations (for 1 and 100 respectively).
You can add a data translation only if the target column is already mapped to a source column. v You cannot add data-to-data translations for target columns with large object (LOB) data types. v v If you have created a subscription that targets an InfoSphere CDC Event Server datastore, then you can only add a data translation for source columns that are mapped to target staging columns. You cannot set a data translation for source columns that are mapped to XML elements and attributes.
See also: To add a data translation on page 184 To modify a data translation on page 184
183
To delete a data translation on page 185 Related tasks To add a data translation To modify a data translation To delete a data translation on page 185 To import a data translation on page 186 To export a data translation on page 185 Related reference Sample: Refreshing subsets of rows on page 346
To add a data translation

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Translation tab. 6. Select a mapped source and target column. 7. Click Add. 8. Enter the data you want to translate in the From Value box. 9. If you want to translate a NULL data type, then check the Translate from NULL box. 10. Enter the value to which you want to translate, in the To Value box. 11. If you want to translate to a NULL value, check the Translate to NULL box. 12. If you want to add another translation, click Add to add the current translation and prepare the dialog for the creation of another translation. If you do not want to add another data translation, click OK. 13. Click Save. Related concepts Mapping tables on page 83 Starting and ending replication on page 355
To modify a data translation

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Translation tab. 6. Select a translation from the Data Translations list and click Modify. 7. Make the necessary changes and click OK. 8. Click Save.
184
Related concepts Mapping tables on page 83 Starting and ending replication on page 355
To delete a data translation

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Translation tab. 6. Select an existing data translation and click Delete. 7. Click Save. Related concepts Mapping tables on page 83 Starting and ending replication on page 355
Importing and exporting data translations

You can import and export data translations for mapped source and target columns. It may be necessary to export a data translation when you know of multiple column mappings that require the same translation. Instead of manually specifying the translation for each column mapping, you can import the data translation and apply it for each column mapping. When you import a data translation into Management Console, any existing translations are replaced with the imported translations. See also: To export a data translation To import a data translation on page 186
To export a data translation

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. 6. 7. 8. 9. Click the Translation tab. Select a mapped source and target column. Ensure that you have added a data translation for this mapping. Click Export. Save the data translation as a CSV file and click OK.
Setting data translations on column mappings
185
Related concepts Importing and exporting data translations on page 185 Related tasks To import a data translation
To import a data translation

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Translation tab. 6. Select a mapped source and target column. 7. Ensure that you have exported a data translation for this mapping. 8. Click Import. 9. Locate the CSV file and click OK. Related concepts Importing and exporting data translations on page 185 Related tasks To export a data translation on page 185
186
Replicating multibyte (MBCS) and double-byte (DBCS) character data

InfoSphere CDC replicates character data between a wide variety of encodings and will automatically convert the data from the column encoding detected on the source to the column encoding detected on the target. For example, you can replicate multibyte character data such as Japanese, Chinese, or Korean. Character data in these languages cannot be represented in a single-byte. The most common MBCS implementation is double-byte character sets (DBCS). By default, InfoSphere CDC assumes that the data stored in a character capable column is in the encoding associated with that column type. For instance, if your database is set to use Shift-JIS, then data stored in CHAR and VARCHAR columns is assumed to be in Shift-JIS by default. However, InfoSphere CDC is only concerned with the encoding of the data, not the encoding of the column storage type. This flexibility allows the product to deal with situations where the encoding of the data does not match the encoding specified for the column in the database. The ability to override the detected encoding is determined by InfoSphere CDC. Overriding the detected column encoding allows you to specify the actual encoding of the data as known by you. This functionality has been extended to not only standard character-capable column types such as CHAR and VARCHAR, but also to traditionally Unicode capable columns such as NCHAR and NVARCHAR, many traditionally binary column types, as well as many large object (LOB) column types, whether or not these are traditionally considered to be character-based. InfoSphere CDC treats all of them as being character data capable. To provide the greatest level of flexibility and where permitted by the limitations of the database, InfoSphere CDC undertakes to remove the distinction between the data themselves and the data type as known by the database that is used to contain the data. There may be situations where you want to replicate the data exactly as is with no change to encoding. In these situations, you can designate the column as being binary and the data will be replicated as is. All binary designated column data must also be mapped to binary column data. Encoding conversion can increase the workload for your source or target servers. InfoSphere CDC provides the ability to specify (with a subscription-level preference) where that workload will be incurred on either the source or the target. InfoSphere CDC also provides an upgrade process for subscriptions that use older implementations (InfoSphere CDC version 6.3 and earlier) of MBCS support. Management Console allows you to quickly convert subscriptions to the auto-encoding mode for MBCS data that is available in InfoSphere CDC version 6.5. In this section, you will learn: Common encoding conversion scenarios on page 188 Considerations when replicating MBCS character data on page 189 Upgrading subscriptions to use auto-encoding mode on page 190
187
Configuring MBCS encoding conversion between your source and target on page 191 Specifying the workload preference on page 192 Handling Unicode character encoding on page 193
Common encoding conversion scenarios

Use the following scenarios as guidelines when you want to convert character set encodings between your source and target.
Scenario 1: Converting encoding between a DB2 z/OS source and a DB2 LUW target
In this scenario, you have a DB2 z/OS source database with data in Simplified Chinese and a default database character set encoding of CCSID 935. Your target database is a DB2 for Windows system with data in Simplified Chinese and a default character set encoding of GB18030 (CCSID 1392). InfoSphere CDC will automatically detect the default database encoding of the source and target columns in your table mappings. If the detected encodings are appropriate for your business needs, no further configuration is required. Note: Because of the encoding differences between these platforms, it is important to note that not all characters will convert with equivalent characters.
Scenario 2: Converting from a national language character set to Unicode

In this scenario, you have a configuration in which data needs to be converted from a national language character set to Unicode. For example, the character set encoding on the source is Traditional Chinese, while the character set encoding on the target (to which you want to convert) is Unicode. No configuration is required in Management Console.
Scenario 3: Overriding the database default encoding of a column as detected by InfoSphere CDC
The default encoding of a column in a database can be different from the data itself. InfoSphere CDC allows you to deal with these situations by allowing you to override the detected encoding of a column. For example, you have a source database with a default encoding of Windows-1252 and you want to replicate CHAR data to your target. You also have Shift-JIS character data in CHAR columns in your source database. InfoSphere CDC will likely detect that all CHAR columns in your source database are Windows-1252 because this is the encoding of the column in your database or the default database encoding. InfoSphere CDC will determine if you can select an encoding that is more appropriate for your data. If InfoSphere CDC allows it, you can override the Windows-1252 encoding and select Shift-JIS encoding for those columns that contain Shift-JIS data.
188
Scenario 4: Replicating mixed character data encodings on the source to multiple encodings on the target
In this scenario, your source data is a mix of different character encodings but is primarily IBM-943. Business requirements dictate that you must have the following character encodings on your target: IBM-943 and IBM-943c. InfoSphere CDC allows you to override the detected encodings in your target columns and set them to either IBM-943 or IBM-943c.
Scenario 5: Replicating character data with no change to encoding

You can replicate data as is with no change to the encoding by designating the source and target columns in a table mapping as a binary with the Override encoding as binary option in Management Console. In this scenario, your DB2 for z/OS source has data structures in a character field. The data structure contains EBCDIC characters, dates, and packed numbers. You want to use a user exit to split the data and send it to 10-20 fields on your target. You can use the Java getBytes function in your user exit to read the data and perform the data conversion. Since the getBytes function is only allowed on a binary field or a character field that is overridden in Management Console as a binary, you can use Override encoding as binary option for the source and target columns in the table mapping. This will allow getBytes to retrieve data from the source image as bytes. The Override encoding as binary option is useful in scenarios where the character column does not contain characters only, but other data types with complex structures.
Scenario 6: Overriding a binary field with an appropriate encoding for your data
In this scenario, you have source column with various encodings in a binary field. You use row filtering when replicating tables to the target so that you only have one type of encoding on the target. In the source columns that are detected as Binary by Management Console, you can override the detected encoding type of Binary and select the encoding that is appropriate for the actual data in each source column. In this scenario, you can have the same source table mapped to the same target table, but the encodings on the source binary columns are different from the single encoding that is found on your target. Related concepts Configuring MBCS encoding conversion between your source and target on page 191 Handling Unicode character encoding on page 193
Considerations when replicating MBCS character data

When mapping source columns to target columns that contain MBCS character data, consider the following: v Most databases enforce NCHAR and NVARCHAR as Unicode and the encoding is not changeable. v All binary data types such as BLOB will not have a default encoding, although InfoSphere CDC allows you to specify an encoding.
189
v Ensure that the target column you want to send data to is large enough to store the replicated character data. Your data will not be replicated if you override the encoding for v graphic, vargraphic, and dbclob columns. v For InfoSphere CDC products that support XML replication, InfoSphere CDC can only replicate XML compliant data to XML column types. Please see the XML specification for the compliance criteria. v InfoSphere CDC will respect the mappings and apply the data according to the character set that is configured for the data. InfoSphere CDC does not validate that the character set can be inserted correctly into the column. v Target tables must use the correct length values. Databases use character length semantics, byte length semantics, or both. v InfoSphere CDC version 6.5 performs encoding conversion on the target by default, with an option to specify the source. This is a change in behavior from previous releases of InfoSphere CDC that always performs encoding conversion on the source with no option to specify the target. Encoding conversion is a CPU intensive activity and you should take this into consideration when deciding where encoding conversion will take place. v Before using MBCS functionality in InfoSphere CDC, you must ensure that your operating system, database, and all tools used to enter data (such as a terminal) are properly configured for your MBCS environment by a system administrator. Otherwise, unexpected behavior may result. v Java class user exits in InfoSphere CDC support MBCS character data. All character data is converted to Java String objects. v InfoSphere CDC for Teradata does not support MBCS character data on the AIX operating system. Related concepts Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187
Upgrading subscriptions to use auto-encoding mode

If you are planning to upgrade your datastore to InfoSphere CDC version 6.5 and you want to use the auto-encoding functionality that is available for MBCS character data, you are required to manually upgrade subscriptions that you created with InfoSphere CDC version 6.3 and earlier. To use auto-encoding mode for subscriptions created with InfoSphere CDC version 6.3 and earlier: 1. Upgrade your target datastore to InfoSphere CDC version 6.5. 2. Upgrade your source datastore to InfoSphere CDC version 6.5. 3. Upgrade subscriptions that were created with InfoSphere CDC version 6.3 by following the procedure outlined in this section. For more information on upgrade procedures, see the InfoSphere CDC documentation for your database platform. Note: All subscriptions created with a new installation of InfoSphere CDC version 6.5 will automatically use auto-encoding mode. See also: To upgrade subscriptions to use auto-encoding mode on page 191
190
To upgrade subscriptions to use auto-encoding mode

1. Click Configuration > Subscriptions. 2. Right-click the subscription (InfoSphere CDC version 6.3 and earlier) that you want to upgrade and select Convert to Auto-Encoding Mode. 3. Management Console prompts you to confirm that you want to convert all table mappings in the subscription to auto-encoding mode. Click Yes. 4. Management Console displays a progress bar and disconnects from Access Server when the upgrade is complete. 5. Log in to Access Server to use auto-encoding mode for the upgraded subscription. Related concepts Upgrading subscriptions to use auto-encoding mode on page 190
Configuring MBCS encoding conversion between your source and target

Use the Encoding tab in the Mapping Details view to configure encoding conversion between your source and target for MBCS data. InfoSphere CDC converts the character sets during replication. InfoSphere CDC automatically detects the default database encoding for source and target columns in a table mapping. If your database supports it, you can choose to override the default encoding for a column if this suits your business needs. If the detected default encodings are appropriate for your business needs, no further changes are necessary. For InfoSphere CDC version 6.3 and earlier, Management Console provides standard character sets and encodings. To add additional character sets and encodings, use the CSV (comma separated variable) template that is found in the Advanced preferences of Edit > Preferences. This step is not necessary for InfoSphere CDC version 6.5, which retrieves the supported encodings directly from your datastores. See also: To configure MBCS encoding conversion
To configure MBCS encoding conversion

1. 2. 3. 4. Click Configuration > Subscriptions. Right-click the table mapping and select Open Details.... Click the Encoding tab. Depending on your version of InfoSphere CDC, choose from the following options: For InfoSphere CDC version 6.5: a. If you want to change the encoding for a source column that supports character encoding, click Edit in the Source Encoding area to open the Source Encoding dialog box. b. From the list of supported encoding overrides, select the appropriate encoding for your data. For example, if your data is stored in Chinese characters, then you can select from either Traditional or Simplified encodings.
191
c. To replicate the data with no changes to the encoding, select Override encoding as binary. You must also designate the target column as binary if the source column is binary. d. Click OK. e. If you want to change the encoding for a target column that supports character encoding, click Edit in the Target Encoding area to open the Target Encoding dialog box. f. From the list of supported encoding overrides, select the appropriate encoding for your data. This is the encoding that your source data will be converted to. g. If you designated a source column as binary, you must also select Override encoding as binary for the target column. h. Click OK. For InfoSphere CDC version 6.3 and earlier: a. If you want to change the encoding for a source or target column that supports character encoding, select the source column and click Edit to open the Column Encoding dialog box. b. In the Source drop down list, select the appropriate encoding for your source column. For example, if your data is stored in Chinese characters, then you can select from either Traditional or Simplified encodings. c. In the Target drop-down list, select the appropriate encoding for your target column. This is the encoding that your source data will be converted to. d. Click OK. 5. Click Save. Related concepts Configuring MBCS encoding conversion between your source and target on page 191
Specifying the workload preference

InfoSphere CDC provides the ability to specify whether your source or target should try to minimize CPU load in order to improve performance. Encoding conversion is one process that respects this preference. There are a number of factors that influence where the encoding conversion will take place and because of these, this preference is not a guarantee. Factors influencing where the encoding conversion takes place include the encoding conversion capabilities of the source and target, and the number of table mappings of a single source column to target columns. The InfoSphere CDC version 6.5 workload preference defaults to having the workload processed on the target. Therefore, by default, encoding conversion, which attempts to respect the workload preference, will occur on the target. You also have an option to specify the source. This is a change in behavior from previous releases of InfoSphere CDC which always perform encoding conversion on the source with no option to specify the target. Subscriptions that are upgraded from InfoSphere CDC version 6.3 will perform encoding conversion on the source by default, although you now have the option of specifying the target. Encoding conversion is a CPU intensive activity and you should take this into consideration when deciding where encoding conversion will take place.
192
See also: To set the workload preference
To set the workload preference

1. Click Configuration > Subscriptions. 2. Right-click the subscription that contains table mappings with encoding conversion work and select Properties. 3. Click Advanced Settings. 4. Select one of the following options from the Select the datastore to handle transferable work drop-down box: v TargetInfoSphere CDC will attempt to perform the encoding conversion workload on the server where your target datastore is installed. This is the default setting. v SourceInfoSphere CDC will attempt to perform the encoding conversion workload on the server where your source datastore is installed. This is the default setting for subscriptions that have been upgraded from InfoSphere CDC version 6.3 and earlier. Note: If your target datastore is InfoSphere CDC for InfoSphere DataStage, encoding conversion workload will always take place on the server where your target datastore is installed. 5. Click OK and click OK again. 6. A progress bar is displayed while Management Console updates the subscription properties. Related concepts Specifying the workload preference on page 192
Handling Unicode character encoding

Note: The tasks in this section are only applicable to InfoSphere CDC version 6.3 and earlier. Use the Encoding tab in the Mapping Details view of Management Console to set how InfoSphere CDC handles Unicode data from the source column. If your source column contains character data stored in multibyte, double-byte, or Unicode character set, then you can indicate how InfoSphere CDC handles data from this source column when replicating to a target column. Management Console provides standard character sets and encodings. If you want to add more character sets and encodings, then you are required to add it to the CSV template that is found in the Advanced preferences in Edit > Preferences. Before you can configure how InfoSphere CDC handles Unicode data, you need to set one of the following system parameters (depending on the version and platform of InfoSphere CDC) to define the system default method of handling data in Unicode columns: v For InfoSphere CDC for Oracle databases (version 6.3), see global_unicode_as_char on page 516. v For InfoSphere CDC for Oracle databases (trigger) (version 6.3), see global_unicode_as_char on page 529.
193
v For InfoSphere CDC for Oracle databases (version 6.2 and earlier), see UNICODE_HANDLING on page 483. v For Transformation Server for Microsoft SQL Server (version 5.3 and earlier), see Unicode Handling on page 439. v For InfoSphere CDC for Microsoft SQL Server (version 6.0 to version 6.3), see global_unicode_as_char on page 456. v For InfoSphere CDC for Sybase databases (version 6.3), see global_unicode_as_char on page 567. v For InfoSphere CDC for Informix (version 6.3), see global_unicode_as_char on page 673. v For InfoSphere CDC for DB2 for LUW (version 6.1 to version 6.3), see global_unicode_as_char on page 631. v For Transformation Server for DB2 UDB (version 6.0 and earlier), see unicode_handling on page 617. v For InfoSphere CDC for DB2 for i (version 6.2 and earlier), see Unicode Handling on page 587. See also: To set handling for Unicode character encoding
To set handling for Unicode character encoding

Note: This task is only applicable to InfoSphere CDC version 6.3 and earlier. 1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Encoding tab. 6. Right-click the source column that supports character handling from the Source Columns list and select Edit Encoding. This opens the Column Encoding dialog box. 7. If you have set the applicable system parameter (depending on your version of InfoSphere CDC) to use the system default method to handle the character set, select System Default. 8. If you want to use an encoding for the character set, select from one of the following: v CHARSelect this value if you have set the applicable system parameter to CHAR or true. InfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this encoding when Unicode columns contain single-byte character data. v NOCHANGESelect this value if you have set the applicable system parameter to NO CHANGE or false. InfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this encoding when Unicode columns contain non-single-byte character data. NOCHANGE ensures that InfoSphere CDC handles non-single-byte character data in the same way as previous InfoSphere CDC releases. 9. Click Save. Related concepts Handling Unicode character encoding on page 193
194
Setting member identifiers

IBM i environments supports a table concept known as multi-member files, in which one table can possess several different members. Each member is part of the same table and shares the same schema, but the members are uniquely named and have unique data. If you have installed InfoSphere CDC for IBM i on your source system and want to replicate a multi-member source table to a single-member target table, then you need to identify each member in the source table. InfoSphere CDC requires an identifier so that it does not truncate rows when it applies a refresh to a single-member target table. If you do not specify an identifier for your multi-member source table, then each time InfoSphere CDC applies a refresh to the single-member target, the member data on the target is overwritten by data from another member. In this section, you will learn: Setting member identifiers for multi-member source tables
Setting member identifiers for multi-member source tables

You can add, modify, or delete member identifiers when you have installed InfoSphere CDC for IBM i on your source system and you are replicating a multi-member source table to a single-member target table on any platform. Before adding a member identifier, you need to create a column on the target table that can maintain the identifiers for the members in your source table. After creating the target column, map the journal control field &MEMBER to this column. See also: To add a member identifier To modify a member identifier on page 196 To delete a member identifier on page 196
To add a member identifier

1. Ensure that you have mapped an InfoSphere CDC for IBM i multi-member source table to a single-member target table on any platform 2. Click Configuration > Subscriptions. 3. Select the subscription. 4. Click the Table Mappings view and select the table mapping from the Source Table column. 5. Right-click and select Open Details.... 6. Click the Operation tab. 7. Click Member Identifiers. 8. Click Add. 9. Enter the name of the member for which you want to add an identifier in the Member Name box. 10. Expand the Target Columns tree and double-click to select the target column you want to include in the member identifier WHERE clause. 11. Click Verify to make sure the expression is valid and click OK.
195
You can continue adding identifiers for each member in your source table. 12. Click OK. 13. Click Save. Related concepts Setting member identifiers for multi-member source tables on page 195
To modify a member identifier

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. Click Member Identifiers. 7. Click Modify. 8. Make the necessary changes and clickOK. You can continue making changes to other member identifiers or click OK to save your changes. 9. Click Save. Related concepts Setting member identifiers for multi-member source tables on page 195
To delete a member identifier

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. Click Member Identifiers. 7. Select the member identifier that you want to delete and click Delete. 8. Click OK. 9. Click Save. Related concepts Setting member identifiers for multi-member source tables on page 195
196
Using journal control fields for auditing replication activities

In this section, you will learn: About journal control fields About journal codes on page 208 Translating journal codes into meaningful information on page 211
About journal control fields

Journal control fields provide information about the log entry on the source system. When a change is made on the source system, the database records the change in a log entry that contains the changed data plus extra information about what type of change was made, who made the change, and when the change was made. When a relevant log entry triggers a replication event to the target system, InfoSphere CDC replicates the changed data along with the extra log entry information to the target system. InfoSphere CDC makes the extra log entry information available through journal control fields. InfoSphere CDC provides many journal control fields that contain log entries from your source systems. You can map journal control fields to columns on the target system. InfoSphere CDC replicates the log information from the source system and applies this information to the mapped columns on your target system. For example, you may want to maintain when the last replicated change was applied to each row in a table on the source system. To capture this information for each row in a table on the target system, you can add a column to the table and map that column to the appropriate journal control field. You can also include journal control fields in row selection and derived expressions. Before using a journal control field, you should consider the following: v If you have installed Transformation Server Version 5.2 or higher, some journal control fields contain non-character data. Depending on the source and target database vendors, InfoSphere CDC converts these values to character data before they are passed to a user exit program. For more information, see the appropriate User Exits section for your platform. v Depending on the type of platform you have installed InfoSphere CDC and the replication method (mirror or refresh), some journal control fields may or may not be supported. v If you have installed InfoSphere CDC for z/OS and you want to build an expression with &MEMBER, then you need to enclose this journal control field in single quotes. v InfoSphere CDC does not support the mapping of journal control fields to LOB columns in a target table. See also: Commit Cycle ID (&CCID) on page 198 Source RRN (&CNTRRN) on page 198 Entry Type Code (&CODE) on page 199 Entry Type (&ENTTYP) on page 199 Source Job Name (&JOB) on page 200
197
Source Job Number (&JOBNO) on page 200 Source Job User (&JOBUSER) on page 201 Journal Name (&JOURNAL) on page 202 Source Table Library (&LIBRARY) on page 203 Source Table Member Name (&MEMBER) on page 203 Source Table Name (&OBJECT) on page 204 Source Program Name (&PROGRAM) on page 204 Journal Sequence Number (&SEQNO) on page 205 Source Server Name (&SYSTEM) on page 206 Record Modification Time (&TIMSTAMP) on page 207 Record Modification User (&USER) on page 207
Commit Cycle ID (&CCID)

An identifier for the transaction with the insert, delete or update operation. Data TypeInteger (InfoSphere CDC 5.x and later) InfoSphere CDC SupportSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to a default value of 0.
Source RRN (&CNTRRN)

The relative record number of the source table that recorded the journal entry. Data TypeInteger (InfoSphere CDC 5.x) InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control field is available only when InfoSphere CDC refreshes data, and is not available when mirroring data. If you decide to use this journal control field when mirroring data, InfoSphere CDC sets this journal control field to a default value of 0. v InfoSphere CDC for DB2 UDB Support for this journal control field is available only when InfoSphere CDC refreshes data, and is not available when mirroring data. If you decide to use this journal control field when mirroring data, InfoSphere CDC sets this journal control field to a default value of 0. v InfoSphere CDC for z/OSSupport for this journal control field is not available.
198
Entry Type Code (&CODE)

The code that identifies the type of journal entry. "U" for refresh and "R" for mirror. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available only when mirroring data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to a default value of U. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC refreshes data, and is not available when mirroring data. When refreshing data, InfoSphere CDC sets this journal control field to a default value of R. If you decide to use this journal control field when mirroring data, InfoSphere CDC sets this journal control field to NULL. v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for DB2 LUWSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for z/OSSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data.
Entry Type (&ENTTYP)

Indicates the type of update. For each journal entry code there are one or more possible journal entry types that provide more detailed information about the entry. For more information, see Using journal control fields for auditing replication activities on page 197. You can use journal entry types for auditing events that occur between your source and target tables. For example, you can use a journal entry type to label each audit record with the event that occurred on your source table that caused the audit record to be written to the target table. This is represented by a distinct two-letter code. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to a default value of RR. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data.
199
v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for DB2 UDBSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for z/OSSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data.
Source Job Name (&JOB)

The name of the job that made the update on the source system. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to UNKNOWN. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the program that performed the operation on the source table. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to NULL. v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this journal control field is not available. If you decide to use this journal control field when mirroring data, this journal control field contains data that is not consistent with the defined contents of the journal control field. If you decide to use this journal control field when refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this journal control field is not available. If you decide to use this journal control field when mirroring data, InfoSphere CDC leaves it empty. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to TS. v InfoSphere CDC for DB2 UDBSupport for this journal control field is not available. If you decide to use this journal control field when mirroring data, InfoSphere CDC leaves it empty. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to TS. v InfoSphere CDC for z/OSSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the Logical Unit of Work's Correlation ID. The Correlation ID is an internal DB2 identifier. It is usually the name of the job that created the Logical Unit of Work.
Source Job Number (&JOBNO)

The operating system user ID of the update process. Data TypeCharacter
200
InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to a default value of 0. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the process ID (UNIX) and the process name (Windows) that performed the operation on the source table. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to NULL. v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this journal control is not available. If you decide to use this journal control field when mirroring data, InfoSphere CDC sets this journal control field to a default value of 0. If you decide to use this journal control field when refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this journal control field is not available. If you decide to use this journal control field when mirroring data, InfoSphere CDC leaves this journal control field empty. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to 000000. v InfoSphere CDC for DB2 UDBSupport for this journal control field is not available. If you decide to use this journal control field when mirroring data, InfoSphere CDC leaves this journal control field empty. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to 000000. v InfoSphere CDC for z/OSSupport for this journal control field is not available. When mirroring data, InfoSphere CDC sets this journal control field to 000000. If you decide to use this journal control when refreshing data, the journal control field contains an empty string.
Source Job User (&JOBUSER)

The operating system user at the time of the update. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to UNKNOWN. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the name of the user that performed the operation on the source
201
v v
table. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to NULL. InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this journal control field is not available. If you decide to use this journal control field when mirroring or refreshing data, InfoSphere CDC leaves this journal control field empty. InfoSphere CDC for Microsoft SQL Server (version 6.0 and later)Support for this journal control field is not available. If you decide to use this journal control field when mirroring data, InfoSphere CDC sets this journal control field to the database user name. The name is set to the database user that owns the InfoSphere CDC metadata tables. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to TS. InfoSphere CDC for DB2 UDBSupport for this journal control field is not available. InfoSphere CDC for z/OSSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring data, this journal control field contains the Authorization ID that the job used to connect to DB2. This is usually the User ID of the job. When refreshing data, this journal control field contains the User ID of the InfoSphere CDC address space.
Journal Name (&JOURNAL)

The name of the journal. Depending on the version of InfoSphere CDC you install, the high byte of this journal control field identifies the name of the journal, and the low byte of this field identifies the library where it resides. For example, JRN1 LIB1. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. If both the name and library are included in this journal control field, then &JRNLIB journal control field is not supported by InfoSphere CDC. v InfoSphere CDC for IBM iSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, it contains the journal name and journal library to which the source table is journaled. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to UNKNOWN. v InfoSphere CDC for OracleSupport for this journal control field is not available. v InfoSphere CDC for Oracle - Trigger version 6.3 and laterSupport for this journal control field is not available. v InfoSphere CDC for Oracle - Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the journal name in the format <schema>.<journal>. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to NULL.
202
InfoSphere CDC for Microsoft SQL ServerSupport for this journal control field is not available. v InfoSphere CDC for DB2 for Linux, UNIX and WindowsSupport for this journal control field is not available. v InfoSphere CDC for InformixSupport for this journal control field is not available. v InfoSphere CDC for SybaseSupport for this journal control field is not available. v InfoSphere CDC for z/OSSupport for this journal control field is only available when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the name of the DB2 subsystem or data sharing group to which InfoSphere CDC is connected.
Source Table Library (&LIBRARY)

The name of the source table schema or its alias. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the journal name in the format <schema>.<journal>. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to a default value of N. v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for DB2 UDBSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for z/OSSupport for this journal control field is only available when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, the journal control field contains the database name in which the table was created and owner ID of the table in the format <dbname.owner>.
Source Table Member Name (&MEMBER)

The name of the source table or its alias. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products.
203
v InfoSphere CDC for IBM iSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing data, this journal control field contains the name of the source table. v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing data, this journal control field contains the name of the source table. v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this journal control field is not available. If you decide to use this journal control field when mirroring or refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for DB2 UDBSupport for this journal control field is not available. If you decide to use this journal control field when mirroring or refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for z/OSSupport for this journal control field is not available.
Source Table Name (&OBJECT)

The name of the source table or its alias. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data. When mirroring or refreshing data, this journal control field contains the name of the source table. v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data v InfoSphere CDC for DB2 LUWSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing data, this journal control field contains the name of the source table. v InfoSphere CDC for z/OSSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing data, this journal control field contains the name of the source table.
Source Program Name (&PROGRAM)

The name of the program on the source system that made the update. Data TypeCharacter
204
InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to UNKNOWN. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the program that performed the operation on the source table. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to NULL v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this journal control field is not available. If you decide to use this journal control field when mirroring or refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this journal control field is not available. If you decide to use this journal control field when mirroring data, InfoSphere CDC sets this journal control field to UNKNOWN. If you decide to use this journal control field when refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for DB2 UDBSupport for this journal control field is not available. If you decide to use this journal control field when mirroring or refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for z/OSSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing data, this journal control field contains the DB2 plan name to which the user is connected. A plan describes the SQL that accesses the tables, paths, indices used and so on.
Journal Sequence Number (&SEQNO)

The sequence number of this update in the journal. Data TypeInteger (InfoSphere CDC 5.x) InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for DB2 for Linux, UNIX and WindowsSupport for this journal control field is not available. v InfoSphere CDC for IBM iSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to relative record number on the target. v InfoSphere CDC for InformixSupport for this journal control field is not available. v InfoSphere CDC for Microsoft SQL ServerSupport for this journal control field is not available.
205
v InfoSphere CDC for OracleSupport for this journal control field is not available. v InfoSphere CDC for Oracle - Trigger version 6.3 and laterSupport for this journal control field is not available. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the sequence number. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to NULL. v InfoSphere CDC for SybaseSupport for this journal control field is not available. v InfoSphere CDC for z/OSSupport for this journal control field is only available when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the RBA or LRSN integer. DB2 uses RBAs and LRSNs to keep track of log positions. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to a default value of 0.
Source Server Name (&SYSTEM)

The host name of the source system. Data TypeCharacter InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing data, this journal control field contains the name of the source system. v InfoSphere CDC for Microsoft SQL Server (version 5.x)Support for this journal control field is not available. If you decide to use this journal control field when mirroring or refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for Microsoft SQL Server (version 6.x)Support for this journal control field is not available. If you decide to use this journal control field when mirroring or refreshing data, InfoSphere CDC leaves this journal control field empty. v InfoSphere CDC for DB2 UDBSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data v InfoSphere CDC for z/OSSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring or refreshing data, this journal control field contains the system name on which InfoSphere CDC is running. The system name is extracted from the root control block (CVT) of the z/OS operating system.
206
Record Modification Time (&TIMSTAMP)

The date and time of when the update or refresh was made on the source. In environments that support microsecond precision, the date and time format of this journal control field is YYYY-MM-DD-HH:MM:SS.UUUUUU. Otherwise, InfoSphere CDC sets the microsecond component UUUUUU to zeroes or does not include it at all. Data TypeTimestamp (InfoSphere CDC 5.x) InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring data, this journal control field contains the date and time when you write the data to the source table. When refreshing data, this journal control field contains the current date and time. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. InfoSphere CDC for Oracle supports the following date and time format for this journal control field: YYYY-MM-DD-HH:MM:SS. When mirroring data, this journal control field contains the date and time when you write the data to the source table. When refreshing data, this journal control field contains the current date and time. v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring data, this journal control field contains the date and time when you write the data to the source table. When refreshing data, this journal control field contains the date and time of when InfoSphere CDC replicated the row in the source table. v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring data, this journal control field contains the date and time when you write the data to the source table. When refreshing data, this journal control field contains the date and time of when InfoSphere CDC refreshed the first row. v InfoSphere CDC for DB2 UDBSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring data, this journal control field contains the date and time when you write the data to the source table. When refreshing data, this journal control field contains the date and time of when InfoSphere CDC refreshed the first row. v InfoSphere CDC for z/OSSupport for this journal control field is available when InfoSphere CDC mirrors or refreshes data. When mirroring data, this journal control field contains the date and time when you write the data to the source table. When refreshing data, this journal control field contains the date and time when the SQL FETCH was issued. Note that the time value format (local or UTC) is determined by the REPLTIMESTAMP configuration parameter.
Record Modification User (&USER)

The user ID that made the update on the source. Data TypeCharacter
207
InfoSphere CDC SupportDepending on the InfoSphere CDC product that you install, journal control fields may or may not be supported when mirroring or refreshing data. Unsupported journal control fields contain default values that vary between the InfoSphere CDC products. v InfoSphere CDC for IBM iSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to UNKNOWN. v InfoSphere CDC for Oracle Trigger version 6.0 and earlierSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the name of the database user that performed the operation on the source table. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to NULL. v InfoSphere CDC for Microsoft SQL Server (version 5.3)Support for this journal control field is only available when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the name of the user or if the user that made the change is the system administrator, it contains the name of the dbo. v InfoSphere CDC for Microsoft SQL Server (version 6.0)Support for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. If you decide to use this journal control field when refreshing data, InfoSphere CDC sets this journal control field to NOT SET. v InfoSphere CDC for DB2 UDBSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the Authorization ID that the job used to connect to DB2. v InfoSphere CDC for z/OSSupport for this journal control field is available only when InfoSphere CDC mirrors data, and is not available when refreshing data. When mirroring data, this journal control field contains the Authorization ID that the job used to connect to DB2. This is usually the User ID of the job.
About journal codes

The &ENTTYP journal control field generates journal codes that provide you with the information you need to identify the exact table operations on the source system that generated the audit record in the table on the target system. By mapping the &ENTTYP journal control field to the added audit column in the table on the target system, you can determine the events that generated each audit record. In the target database, the &ENTTYPjournal control field contains the two-character journal code that identifies the specific event that happened at the source table level and which generated the audit record on the target system. InfoSphere CDC generates multiple journal codes. Journal codes represent events that take place in your source database. You can customize the journal codes by building an expression with the %IF column function. For more information, see Translating journal codes into meaningful information on page 211. You can customize the journal codes generated by InfoSphere CDC. See also: Table Clear on page 209 Delete on page 210
208
Insert on page 210 Update Before on page 210 Update After on page 211
Table Clear
The Table Clear events clear data in a table on the source system. Depending on the type of Table Clear event that has taken place on the source system, InfoSphere CDC supports an IBM i journal code.
IBM i journal codes

v CRIndicates that a file, table, or member has been cleared on the source system. v MDIndicates that a file, table, or member has been deleted on the source system. This uses journal control fields for auditing replication activities. v RSIndicates that prior to a refresh, a file, table, or member has been cleared on the source system. In this case, the refresh is a result of an implied table restore. v AYJournal Change Apply Start, which indicates the starting point for a set of journal entries applied to a file, table, or member on the source system. InfoSphere CDC appends this entry to the audit table on the target system. v AZJournal Change Apply End, which indicates the ending point for a set of journal entries applied to a file, table, or member on the source system. InfoSphere CDC appends this entry to the audit table on the target system. v RCJournal Change Remove Start, which indicates the starting point for a set of journal entries and reverses previous applies that were made to a file, table, or member on the source system. InfoSphere CDC appends this entry to the audit table on the target system. v RZJournal Change Remove End, which indicates the ending point for a set of journal entries and reverses previous applies that were made to a file, table, or member on the source system. InfoSphere CDC appends this entry to the audit table on the target system. RZ is a journal code generated by InfoSphere CDC. It is not an IBM i journal code. v JMIndicates that journaling on the file or table has been started on the source system. v EJIndicates that journaling on the file or table ended on the source system. v RGIndicates that a file, table, or member has been reorganized on the source system. v MNBefore Rename, which indicates when the file or member has been renamed on the source system. InfoSphere CDC appends this entry to the audit table on the target system. v NZAfter Rename, which indicates that a new name has been given to a file or member on the source system. InfoSphere CDC appends this entry to the audit table on the target system. v MMBefore Publication File Move, which indicates when the file has been moved on the source system. InfoSphere CDC appends this entry to the audit table on the target system. v MZAfter Publication File Move, which indicates a new location for a file that has been moved on the source system. InfoSphere CDC appends this entry to the audit table on the target system. MZ is a journal code generated by InfoSphere CDC. It is not an IBM i journal code. v MRIndicates that a file on the source system has been restored.
209
v CHIndicates that a file on the source system has been changed. When a non-schema change is applied to the audit table on the source system, InfoSphere CDC appends this entry to the audit table on the target system.
Delete
The Delete events delete records in a table on the source system. Depending on the type of Delete event that has taken place on the source system, InfoSphere CDC supports an IBM i journal code.
IBM i journal codes

v DLIndicates that a record from a table on the source system has been deleted. v DRIndicates that a record from a table on the source system has been deleted because of a rollback operation of an inserted record.
Insert
The Insert events insert rows in a table on the source system. Depending on the type of Insert event that has taken place on the source system, InfoSphere CDC supports an IBM i journal code.
IBM i journal codes

v PTIndicates that a record in a table on the source system has been inserted. v PXIndicates that a record in a table on the source system has been inserted by re-establishing a deleted record. v URIndicates that a record in a table on the source system has been inserted through a rollback of a deleted record. v RRIndicates that a record in a table on the source system has been refreshed.
Update Before
The Update Before events provide you with the before image of records updated in a table on the source system. Depending on the type of Update Before event that has taken place on the source system, InfoSphere CDC generates a journal code.
IBM i journal codes

v UBIndicates the before image of a record updated in a table on the source system. v FDIndicates the before image of a record updated in a table on the source system that satisfies a row selection expression. InfoSphere CDC appends this entry to the audit table on the target system as a Filtered Record Delete. FD is a journal code generated by InfoSphere CDC. It is not an IBM i journal code. v FBIndicates the before image of a record updated in a table on the source system that does not satisfy a row selection expression. InfoSphere CDC appends this entry to the audit table on the target system as a Filtered Record Insert. This record is only placed in the audit table when the corresponding after image satisfies the row selection expression (FI) and you want to include both images in the audit table. Otherwise, InfoSphere CDC only includes a single record (FI) in the audit table. You can audit both images using an InfoSphere CDC system parameter. For more information, see the appropriate InfoSphere CDC User Manual for your platform. FB is a journal code generated by InfoSphere CDC. It is not an IBM i journal code. v BRIndicates the before image of a record updated for rollback in a table on the source system.
210
Update After
The Update After events provide you with the after image of records updated in a table on the source system. Depending on the type of Update After event that has taken place on the source system, InfoSphere CDC generates a journal code.
IBM i journal codes

v UPIndicates the after image of a record updated in a table on the source system. v FIIndicates the after image of a record updated in a table on the source system that satisfies a row selection expression. InfoSphere CDC appends this entry to the audit table on the target system as a Filtered Record Insert. FD is a journal code generated by InfoSphere CDC. It is not an IBM i journal code. v FPIndicates the after image of a record updated in a table on the source system that does not satisfy a row selection expression. InfoSphere CDC appends this entry to the audit table on the target system as a Filtered Record Delete. This record is only placed in the audit table when the corresponding before image satisfies the row selection expression (FD) and you want to include both images in the audit table. Otherwise, InfoSphere CDC only includes a single record (FD) in the audit table. You can audit both images using an InfoSphere CDC system parameter. For more information, see the appropriate InfoSphere CDC documentation for your platform. FP is a journal code generated by InfoSphere CDC. It is not an IBM i journal code. v URIndicates the after image of a record updated for rollback in a table on the source system.
Translating journal codes into meaningful information

When you map your tables using LiveAudit, you can map your audit columns to the &ENTTYP journal control field to let you know what kind of change has been made on your source table. Because there are many changes that can take place, if you map a journal control field to a target column, InfoSphere CDC generates a distinct two-letter journal code on your audit table to help you identify the event that occurred on the source. For example, if there has been a row inserted in your source table, then in response to this update, InfoSphere CDC inserts a row into the target table with the journal code 'PT'. The journal codes your system generates depend on the database platform that you are using. You may want to customize journal codes so that they are more meaningful in your organization. For example, instead of having the journal code "PT" to indicate that there has been a new row inserted in your source table, you may want to use a one-letter code such as "I" to identify the insert. The %IF column function evaluates conditional expressions and returns different values if the expression is true or false. The example below illustrates how you can use the %IF column function to convert journal codes into custom letters
%IF(&ENTTYP=PT OR &ENTTYP="RR","I", %IF(&ENTTYP= "UB", "B", %IF(&ENTTYP= "UP", "A", %IF(&ENTTYP="DL","D","R"))))
This expression does the following: v If a row has been inserted or refreshed on the source table, then InfoSphere CDC generates "I" on the audit table. v If the before image on the source table has been updated, then InfoSphere CDC generates "B" on the audit table.
211
v If the after image has been updated on the source table then InfoSphere CDC generates "A" in the audit table. v If a row on the source table has been deleted, then InfoSphere CDC generates "D" on the audit table, otherwise it generates "R" on the audit table.
212
Controlling table operations

By default, InfoSphere CDC truncates the target table in response to a table-level clear or refresh operation. You can control this so that InfoSphere CDC preserves all or some of the rows. In this section, you will learn: Controlling the apply of refresh operations Specifying SQL to control refresh operations on page 215
Controlling the apply of refresh operations

Use the Operations tab to control how InfoSphere CDC applies table-level clear or refresh operations to a target table. You can do this if you have mapped your tables using one of Standard, Adaptive Apply, Summarization, or Consolidation. Also, if you have mapped your tables using LiveAudit, then you can specify that InfoSphere CDC provide an audit trail each time there is an table-level clear or refresh operation applied to the target table. See also: To keep all rows on a refresh To delete all rows on a refresh on page 214 To audit rows on a refresh on page 214
To keep all rows on a refresh

1. Click Configuration > Subscriptions. 2. Select the subscription. Ensure that the subscription contains a table mapping that was mapped using Standard, Adaptive Apply, Summarization or Consolidation. 3. Select the table mapping in the Table Mappings view. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. From the On Clear/Truncate list, select Do Not Delete. 7. Click Save. When you start a refresh on a table mapping, InfoSphere CDC does not delete the rows in the target table.
213
Related concepts Mapping using standard replication on page 87 Mapping using LiveAudit on page 95 Mapping using Adaptive Apply on page 100 Mapping to summarize data on page 105 Starting a refresh on a subscription on page 358 Controlling the apply of refresh operations on page 213
To delete all rows on a refresh

1. Click Configuration > Subscriptions. 2. Select the subscription. Ensure that your subscription contains a table mapping that was mapped using Standard, Adaptive Apply or Summarization. 3. Select the table mapping in the Table Mappings view. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. Select Delete All from the On Clear/Truncate list. 7. Click Save. Related concepts Mapping using standard replication on page 87 Mapping using Adaptive Apply on page 100 Mapping to summarize data on page 105 Starting a refresh on a subscription on page 358
To audit rows on a refresh

1. Click Configuration > Subscriptions. 2. Select the subscription. Ensure that your subscription contains a table mapping that was mapped using LiveAudit. 3. Select the table mapping in the Table Mappings view. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. Select Audit from the On Clear/Truncate list. 7. Click Save. When you start a refresh on the table mapping, InfoSphere CDC audits the table-level clear or refresh operations applied to the target table.
214
Related concepts Mapping using standard replication on page 87 Mapping using LiveAudit on page 95 Mapping using Adaptive Apply on page 100 Mapping to summarize data on page 105 Starting a refresh on a subscription on page 358
Specifying SQL to control refresh operations

By default, InfoSphere CDC deletes all rows in the target table in response to a table-level clear or refresh operation. Use the Operation tab to specify a SQL WHERE clause that restricts the rows you want InfoSphere CDC to delete in response to a table clear or refresh operation. InfoSphere CDC only deletes or truncates the rows for which the condition is true. For example, you may want to use the WHERE clause to delete rows from the supplier table. The SQL statement SupplierName= 'IBM' would delete all rows from the supplier table where the SupplierName is IBM. You can also specify additional SQL statements that execute after InfoSphere CDC applies a table refresh or truncate/clear operation to the target table. For all InfoSphere CDC products (except for InfoSphere CDC for z/OS and InfoSphere CDC for DB2 LUW), you need to run the DMSQL command to enable the Additional SQL feature in Management Console. For more information, see the commands section of the appropriate InfoSphere CDC End-User Documentation for your InfoSphere CDC product. If you have installed InfoSphere CDC for z/OS, then you need to set the keyword ALLOWSQL to YES to enable theAdditional SQL feature in Management Console. You can add this keyword to the CHCDBMxx Configuration Control data set member. For more information about this keyword, see Modifying DBMS LOAD Configuration Control Statements in the InfoSphere CDC for z/OS End-User Documentation. If you have installed InfoSphere CDC for DB2 LUW, then you need to create a metadata table to enable the Additional SQL feature in Management Console. For more information, see InfoSphere CDC for DB2 LUW End-User Documentation. Before issuing SQL statements in Management Console, consider the following: v If you are referencing a database, table, or column name that contains spaces, then you must enclose the name in square brackets. For example, to reference the table name "EMP NY", you must enter it as [EMP NY]. v If your delete WHERE clause references a character column, the specified value must be enclosed in single quotes. For example, MGR = 'Anna Kim'. v You cannot reference LOB columns in delete WHERE clauses. v Specify only SQL INSERT, UPDATE, and DELETE statements. v SQL statements must be 4,000 bytes or less in length. If you specify SQL statements that do not fit on one line, do not press the Enter key to break the statements over more than one line. The text will feed automatically to the next line. v No support for logical branching and iteration. v The database running on the target server must recognize the syntax of the SQL statements.
215
v Separate multiple SQL statements by semicolons (;). If a character string in a SQL statement contains a semicolon, specify two semicolons consecutively (;;) in the string. v Management Console does not verify SQL statements for syntactical correctness. The target DBMS verifies statements during replication. See also: To specify additional SQL after a refresh To delete selected rows on a refresh
To specify additional SQL after a refresh

1. 2. 3. 4. Click Configuration > Subscriptions. Select the subscription. Select the table mapping in the Table Mappings view. Right-click and select Open Details....
5. Click the Operation tab. 6. Select Delete Selected Rows from the On Clear/Truncate list. 7. Click Additional SQL. 8. If you want InfoSphere CDC to execute SQL after a truncate operation, then type SQL statement in the SQL Immediately After Truncate box. 9. If you want InfoSphere CDC to execute SQL after a refresh operation, then type SQL in the SQL Immediately After Refresh box. 10. Click OK. 11. Click Save. Note: If InfoSphere CDC encounters an error during execution of a SQL statement, it ignores all remaining statements. Also, depending on the system parameters you have set, InfoSphere CDC either continues or ends data replication in response to the error. Related concepts Specifying SQL to control refresh operations on page 215 Related tasks To delete selected rows on a refresh
To delete selected rows on a refresh

1. 2. 3. 4. Click Configuration > Subscriptions. Select the subscription. Select the table mapping in the Table Mappings view. Right-click and select Open Details....
5. Click the Operation tab. 6. Select Delete Selected Rows from the On Clear/Truncate list. 7. Click Editor to specify a SQL WHERE clause for the selected rows. 8. Expand the Target Columns list and select the target columns on which you want to restrict deletions. 9. Click Verify to make sure the SQL WHERE clause is valid and click OK. 10. Click Save.
216
Related concepts Specifying SQL to control refresh operations on page 215 Starting a refresh on a subscription on page 358
217
218
Configuring user exits

A user exit lets you define a subroutine that InfoSphere CDC can invoke when a predefined event occurs. Two types of user exits are available: v Table-level user exits run a set of actions before or after a database event occurs on a specified table. v Subscription-level user exits run a set of actions before or after a commit event occurs on a specified subscription. Subscription-level user exits can work in tandem with table-level user exits, to keep track of which table-level user exits were invoked during a transaction. The subscription-level user exit could then use that information to apply actions based on the tables in the transaction. In this section, you will learn: Configuring table-level user exits Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server on page 223 Configuring table-level user exits for InfoSphere CDC for Oracle databases (version 6.1 and below) or InfoSphere CDC for Sybase databases (version 6.1 and below) on page 228 Configuring table-level user exits for InfoSphere CDC for IBM i (version 6.2 and below) or InfoSphere CDC for z/OS on page 231 Creating a custom data format for IBM InfoSphere DataStage on page 232 Configuring subscription-level user exits on page 234 Understanding user exit configuration for InfoSphere CDC Event Server on page 235 Overriding JMS message header properties on page 235 Sending the XML message to a different JMS message destination on page 236 Creating XML output and applying XSLT to an XML message on page 238 Sending XML messages to multiple JMS message destinations on page 240 Querying a Web service to access content on page 241 Content based routing on page 243
Configuring table-level user exits

A table-level 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. When using InfoSphere CDC, a database event is defined as either a row-level operation or as a table-level operation. Row-level operations include an insert, update, or a delete. Table-level operations include a refresh or a truncate operation. For example, you can configure a row-level user exit program that sends an alert after InfoSphere CDC replicates a delete operation on a particular target table. User exits can be grouped as either a Before User Exit or an After User Exit: v Before User Exitruns before InfoSphere CDC replicates any row-level or table-level operations to the target table.
219
v After User Exitruns after InfoSphere CDC replicates any row-level or table-level operations to the target table. The following list identifies common scenarios for developing a user exit program before or after row or table-level operations: v Customize when InfoSphere CDC replicates a row-level operation to the target table. For example, you can develop logic for insert, update, or delete operations so that these occur based on some specified criteria, such as the original invoice date. InfoSphere CDC can run the user exit and apply the row-level operation (insert, update, or delete) to the appropriate target table based on the original invoice date, such as, January 2004, February 2004, November 2006, and so on. v Disable the default row-level or table-level operations, and replace them by invoking a user exit program that performs custom operations. For example, in response to a table-level truncate operation, you can develop a user exit that lets you do a soft delete rather than a hard delete on the target table. A consideration to keep in mind is that many databases have column name length limitations, which can affect how some expressions, user exits, and derived columns are handled. Column name length limitations can cause InfoSphere CDC to describe a column alias to the target when the source column name length exceeds the column name length limit on the target. The restriction is 30 characters for most InfoSphere CDC compatible databases (Informix, IBM DB2 LUW, Oracle, or Sybase prior to version 15.0), with two exceptions: v Microsoft SQL Server 128 characters v Sybase 15.0 and later 255 characters See also: To configure a stored procedure To configure a derived column or an expression that calls %STPROC, %USER, or %USERFUNC on page 221 To configure a user exit for a Java class on page 222
To configure a stored procedure

1. Verify your version of InfoSphere CDC. This information is applicable to the following versions of InfoSphere CDC: v InfoSphere CDC for Microsoft SQL Server (version 6.0 and higher) v InfoSphere CDC for DB2 UDB (version 6.1 and higher) v InfoSphere CDC for Oracle (version 6.3) v InfoSphere CDC for Oracle - Trigger (version 6.3) v InfoSphere CDC for Sybase (version 6.3) 2. Click Configuration > Subscriptions. 3. Select the subscription. 4. 5. 6. 7. Select the table mapping in the Table Mappings view. Right-click and select Open Details.... Click the User Exits tab. Select Stored Procedure from the User Exit Type list. Use the Stored Procedure - Deprecated option to maintain user exits that were created using InfoSphere CDC for Microsoft SQL Server (version 5.3). Use the Stored Procedure option for all new user exits.
220
8. Enter the name of the schema that contains the stored procedure in the Schema box. 9. Enter the name of the user exit programs you want InfoSphere CDC to call beside one or more of the following operations:
Option Before Insert After Insert Before Update After Update Before Delete After Delete Before Refresh After Refresh Before Truncate After Truncate Description InfoSphere CDC runs the user exit before replicating an insert operation. InfoSphere CDC runs the user exit after replicating an insert operation. InfoSphere CDC runs the user exit before replicating an update operation. InfoSphere CDC runs the user exit after replicating an update operation. InfoSphere CDC runs the user exit before replicating a delete operation. InfoSphere CDC runs the user exit after replicating a delete operation. InfoSphere CDC runs the user exit before replicating a refresh operation. InfoSphere CDC runs the user exit after replicating a refresh operation. InfoSphere CDC runs the user exit before replicating a truncate operation. InfoSphere CDC runs the exist after replicating a truncate operation.
10. Click Save. Related concepts Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server on page 223 Related tasks To configure a stored procedure on page 226
To configure a derived column or an expression that calls %STPROC, %USER, or %USERFUNC

1. Click the Column Mappings tab, and do one of the following: v If you want InfoSphere CDC to evaluate an expression on the source table, then add a derived column. v If you want InfoSphere CDC to evaluate an expression on the target table, then build an expression. Make sure the expression you define contains a valid call to the %STPROC, %USER or %USERFUNC column function. If you are calling a stored procedure that is not owned by the InfoSphere CDC user, you must provide the name in the form <schema>.<stored procedure name>. 2. Map the derived column or the expression to the target column.
221
Related concepts Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server on page 223 Related tasks To configure a stored procedure on page 226 To configure a stored procedure on page 220 To add a derived column on page 179 To map a derived column to a target column on page 180 To map an expression to a target column on page 175
To configure a user exit for a Java class

Note: For Java class user exits, method names are pre-defined. This means that you can only enable and disable user exit programs. You need to configure a user exit in java that implements the UserExitIF interface class. For more information about this class, see the InfoSphere CDC End-User Documentation for each platform. 1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the User Exits tab. 6. Select Java Class from the User Exit Type list. 7. Enter the name of the Java class user exit that implements the UserExitIF interface in the Class Name box. For example, you may have imported the UserExitIF interface, and the user exit program class that implements this interface in your function has the following definition: public class UE1 implements UserExitIF In the Class Name box, you need to type:
Option UE1 <Java package>.UE1 Description If it is a stand-alone class If the class is included in a Java package (for example, com.ibm.interface.UE1)
The files you generate from compiling the user exit program must be located in a library or folder that is referenced by the CLASSPATH environment variable. 8. Enter the parameters that you want to make available to the user exit program in the Parameter box. You can access the parameters in the user exit program class by invoking the getParameter( ) method during the initialization process. There are no conventions for specifying the parameters. The values you type in this box are free-form. The string of parameter values cannot exceed 255 characters in length. 9. Enter the name of the user exit programs you want InfoSphere CDC to call beside one or more of the following operations:
222
Option Before Insert After Insert Before Update After Update Before Delete After Delete Before Refresh After Refresh Before Truncate After Truncate
Description InfoSphere CDC runs the user exit before replicating an insert operation. InfoSphere CDC runs the user exit after replicating an insert operation. InfoSphere CDC runs the user exit before replicating an update operation. InfoSphere CDC runs the user exit after replicating an update operation. InfoSphere CDC runs the user exit before replicating a delete operation. InfoSphere CDC runs the user exit after replicating a delete operation. InfoSphere CDC runs the user exit before replicating a refresh operation. InfoSphere CDC runs the user exit after replicating a refresh operation. InfoSphere CDC runs the user exit before replicating a truncate operation. InfoSphere CDC runs the exist after replicating a truncate operation.
10. Click Save. Related concepts Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server
Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server
You can configure the following types of table-level user exits with InfoSphere CDC for Microsoft SQL Server: IDispatch COM DLL (InfoSphere CDC for Microsoft SQL Server)You can invoke at runtime a function you defined using IDispatch. When configuring an IDispatch COM DLL user exit,Management Console lets you enable or disable user exits developed for IDispatch. Before you can use Management Console to configure a user exit, you need to do the following in Microsoft SQL Server: v Create the user-defined function. v Create the user exit. v Extract or build the DLL file and place it in a location. For example, C:\Program Files\Microsoft SQL Server\MSSQL\Bin (or wherever appropriate). v If you are using Visual Basic, you must reference the library dts_usrext.tlb after starting Visual Basic. InfoSphere CDC provides a predefined interface (IDTS_UserExit) so that InfoSphere CDC can interact with the server object you define. The interface contains four predefined user exit program stubs that you should not modify. As a result, you can only select (not name) the functions that you want to call at the various processing points. For more information, see your user exits documentation for InfoSphere CDC for Microsoft SQL Server. C or C++ (InfoSphere CDC for Microsoft SQL Server)You can specify a DLL library that contains the compiled user exit program.
223
Stored Procedure (Transformation Server for Microsoft SQL Server (version 5.3)deprecated)You can configure a user exit as a stored procedure for Transformation Server for Microsoft SQL Server Version 5.3. Depending on how you have configured the stored procedure, you need to identify temporary or permanent tables so that Transformation Server can populate these tables with the images of the row-level operations applied to the target table. Your stored procedure user exit can then retrieve the image of the row from these tables and use them as required. Java ClassFor Java class user exits, method names are pre-defined. This means that you can only enable and disable user exit programs. You need to configure a user exit in java that implements the UserExitIF interface class. For more information about this class, see the InfoSphere CDC End-User Documentation for each of these platforms. See also: To configure for IDispatch COM DLL To configure for C or C++ on page 225 To configure a stored procedure on page 226 Related concepts Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server on page 223
To configure for IDispatch COM DLL

Note: This function is deprecated and is available only for backward compatibility to Transformation Server for Microsoft SQL Server version 5.3. It is applicable to InfoSphere CDC for Microsoft SQL Server (version 6.2 and higher) 1. Click Configuration > Subscriptions. 2. Select the subscription. Select the table mapping in the Table Mappings view. Right-click and select Open Details.... Click the User Exits tab. Select IDispatch COM DLL from the User Exit Type list box. Enter the name of the class module and project that contains the user exit program that you want run in the DLL Name box. 8. If you want InfoSphere CDC to retrieve the current constant value from the target and pass it to a user exit program that runs before or after InfoSphere CDC replicates an update operation to the target table, then enable Update All Columns. 9. Enter the name of the user exit programs you want InfoSphere CDC to call beside one or more of the following operations: 3. 4. 5. 6. 7.
Option Before Insert After Insert Before Update Description InfoSphere CDC runs the user exit before replicating an insert operation. InfoSphere CDC runs the user exit after replicating an insert operation. InfoSphere CDC runs the user exit before replicating an update operation.
224
Option After Update Before Delete After Delete Before Refresh After Refresh Before Truncate After Truncate
Description InfoSphere CDC runs the user exit after replicating an update operation. InfoSphere CDC runs the user exit before replicating a delete operation. InfoSphere CDC runs the user exit after replicating a delete operation. InfoSphere CDC runs the user exit before replicating a refresh operation. InfoSphere CDC runs the user exit after replicating a refresh operation. InfoSphere CDC runs the user exit before replicating a truncate operation. InfoSphere CDC runs the exist after replicating a truncate operation.
10. Click Save. In some environments, the target table may contain one or more columns that store user-defined constants. Other applications usually maintain these constant values, and they are not affected by InfoSphere CDC. If you do not enable Update All Columns, then InfoSphere CDC passes the default column value (for example, zero, blank, or NULL) to the user exit program. Due to performance reasons, it is important that you clear this box if you do not need to pass the user-defined constant values. Related concepts Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server on page 223
To configure for C or C++

Note: This function is deprecated and is available only for backward compatibility to Transformation Server for Microsoft SQL Server version 5.3. It is applicable to InfoSphere CDC for Microsoft SQL Server (version 6.2 and higher) 1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the User Exits tab. 6. Select C/C++ DLL from the User Exit Type list. 7. Enter the full path name of a DLL library that contains the compiled user exit program in the DLL Name box. 8. If you want InfoSphere CDC to retrieve the current constant value from the target and pass it to a user exit program that runs before or after InfoSphere CDC replicates an update operation to the target table, then enable Update All Column. 9. Enter the name of the user exit programs you want to call in the Function Name list. 10. Enter the name of the user exit programs you want InfoSphere CDC to call beside one or more of the following operations:
225
11. Click Save. In some environments, the target table may contain one or more columns that store user-defined constants. Other applications usually maintain these constant values, and they are not affected by InfoSphere CDC. If you do not enable Update All Columns, then InfoSphere CDC passes the default column value (for example, zero, blank, or NULL) to the user exit program. Due to performance reasons, it is important that you clear this box if you do not need to pass the user-defined constant values. Related concepts Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server on page 223
To configure a stored procedure

Note: This function is deprecated and is available only for backward compatibility to Transformation Server for Microsoft SQL Server version 5.3. It is applicable to InfoSphere CDC for Microsoft SQL Server (version 6.2 and higher) 1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the User Exits tab. 6. Select Stored Procedure from the User Exit Type list. 7. Enter the database owner of the stored procedure, in the Database Owner box.
226
8. If you have a stored procedure that runs after InfoSphere CDC replicates an update operation to the target table, then provide the name of the temporary or permanent table in the Update Table Image box. During replication, InfoSphere CDC populates this table with the after image of the update operation that was applied to the target. Your stored procedure user exit then retrieves the after image of the row from this table. 9. If you have a stored procedure that requires access to a specific row, then provide the name of the temporary or permanent table in the Key Table Image box. Depending on the kind of row-level operation applied to the target table, InfoSphere CDC populates this table with either the after or before images of the key column data. Your stored procedure user exit then retrieves the after or before image of the key column data from this table. 10. If you have a stored procedure that requires access to journal information for each updated row, then provide the name of the temporary or permanent table in the Journal Table Image box. InfoSphere CDC populates this table with the journal header information. Journal header information includes journal control fields and journal codes that indicate what kind of update was made on the row. For more information about journal control fields, see Using journal control fields for auditing replication activities on page 197. 11. If you have configured a stored procedure that runs before a row-level operation is replicated to the target table, then provide the name of the temporary or permanent table in the Before Table Image box. During replication, InfoSphere CDC populates this table with the before image of the rows in the source table. Your stored procedure user exit then retrieves the before image of the row from this table. Notes: v InfoSphere CDC supports fully qualified image table names to a maximum of 100 characters in length, but database naming restrictions still apply. Note that InfoSphere CDC does not verify whether an image table name conforms to a database naming convention. If you are referencing a database or table that contains spaces, then you must enclose the name in square brackets. For example, to reference the table name "EMP NY", you must enter it as [EMP NY]. v The image tables and the target tables should reside in different databases to prevent any possibility of locking the database. 12. If you want to create permanent tables using Management Console, then click Create Tables. 13. If you want to retrieve the current constant value (also known as the before or after image of the source row) and pass it to a user exit program that runs before or after a row-level operation is replicated to the target table, then check the Update All Columns box. 14. Enter the name of the user exit programs you want InfoSphere CDC to call beside one or more of the following operations:
Option Before Insert After Insert Description InfoSphere CDC runs the user exit before replicating an insert operation. InfoSphere CDC runs the user exit after replicating an insert operation.
227
Option Before Update After Update Before Delete After Delete Before Refresh After Refresh Before Truncate After Truncate
Description InfoSphere CDC runs the user exit before replicating an update operation. InfoSphere CDC runs the user exit after replicating an update operation. InfoSphere CDC runs the user exit before replicating a delete operation. InfoSphere CDC runs the user exit after replicating a delete operation. InfoSphere CDC runs the user exit before replicating a refresh operation. InfoSphere CDC runs the user exit after replicating a refresh operation. InfoSphere CDC runs the user exit before replicating a truncate operation. InfoSphere CDC runs the exist after replicating a truncate operation.
15. Click Save. In some environments, the target table may contain one or more columns that store user-defined constants. Other applications usually maintain these constant values, and they are not affected by InfoSphere CDC. If you do not enable Update All Columns, then InfoSphere CDC passes the default column value (for example, zero, blank, or NULL) to the user exit program. Due to performance reasons, it is important that you clear this box if you do not need to pass the user-defined constant values. Related concepts Configuring table-level user exits for InfoSphere CDC for Microsoft SQL Server on page 223 Related tasks To configure a stored procedure on page 220
Configuring table-level user exits for InfoSphere CDC for Oracle databases (version 6.1 and below) or InfoSphere CDC for Sybase databases (version 6.1 and below)
C Shared LibraryYou can configure a C user exit program for InfoSphere CDC. You can configure the InfoSphere CDC to run the user exit program before or after an insert, update, delete, or truncate operation. Stored ProcedureYou can configure a stored procedure user exit for InfoSphere CDC. You need to identify the schema that contains the stored procedure and identify the InfoSphere CDC operations on which you want to run the user exit. InfoSphere CDC can call your stored procedure from either the source or target when you use the %STPROC column function in an expression. If you want InfoSphere CDC to evaluate and call your stored procedure on the source, then you need to add a derived column. If you want InfoSphere CDC to evaluate and call your stored procedure on the target, then you need to build an expression. See also: To configure a C shared library on page 229
228
To configure a stored procedure (Oracle and Sybase) on page 230 To configure a derived column or an expression that calls %STPROC (Oracle and Sybase) on page 231
To configure a C shared library

1. Click Configuration > Subscriptions. 2. Ensure that you are connected to an InfoSphere CDC for Oracle or an InfoSphere CDC for Sybase datastore. 3. Select the subscription. 4. Select the table mapping in the Table Mappings view. 5. Right-click and select Open Details.... 6. Click the User Exits tab. 7. Select C Shared Library from the User Exit Type list. 8. Enter the full path name of the file containing the shared library in the File (path) box. 9. If you want InfoSphere CDC to retrieve the current constant value from the target and pass it to a user exit program that runs before or after InfoSphere CDC replicates an update operation to the target table, then check the Retrieve Current Values box. 10. Enter the name of the user exit programs you want InfoSphere CDC to call beside one or more of the following operations:
Specify the parameters that you want InfoSphere CDC to pass to the user exit program. 12. Click Save. In some environments, the target table may contain one or more columns that store user-defined constants. Other applications usually maintain these constant values, and they are not affected by InfoSphere CDC. If you do not 11.
229
enable Retrieve Current Value, then InfoSphere CDC passes the default column value (for example, zero, blank, or NULL) to the user exit program. Due to performance reasons, it is important that you clear this box if you do not need to pass the user-defined constant values. Related concepts Configuring table-level user exits for InfoSphere CDC for Oracle databases (version 6.1 and below) or InfoSphere CDC for Sybase databases (version 6.1 and below) on page 228
To configure a stored procedure (Oracle and Sybase)

1. Ensure that you are connected to an InfoSphere CDC for Oracle or an InfoSphere CDC for Sybase datastore. 2. Click Configuration > Subscriptions. 3. Select the subscription. 4. Click the Table Mappings view and select the table mapping from the Source Table column. 5. Right-click and select Open Details.... 6. Click the User Exits tab. 7. Select Stored Procedure from the User Exit Type list. 8. Enter the name of the schema that contains the stored procedure in the Schema box. 9. If you want InfoSphere CDC to retrieve the current constant value from the target and pass it to a user exit program that runs before or after InfoSphere CDC replicates an update operation to the target table, then check the Retrieve Current Values box. 10. Enter the name of the user exit programs you want InfoSphere CDC to call beside one or more of the following operations:
230
11. Click Save. In some environments, the target table may contain one or more columns that store user-defined constants. Other applications usually maintain these constant values, and they are not affected by InfoSphere CDC. If you do not enable Retrieve Current Value, then InfoSphere CDC passes the default column value (for example, zero, blank, or NULL) to the user exit program. Due to performance reasons, it is important that you clear this box if you do not need to pass the user-defined constant values. Related concepts Configuring table-level user exits for InfoSphere CDC for Oracle databases (version 6.1 and below) or InfoSphere CDC for Sybase databases (version 6.1 and below) on page 228
To configure a derived column or an expression that calls %STPROC (Oracle and Sybase)
1. Ensure that you are connected to an InfoSphere CDC for Oracle or an InfoSphere CDC for Sybase datastore. 2. Click the User Exits tab, and configure a stored procedure. 3. Click the Column Mappings tab, and do one of the following: v If you want InfoSphere CDC to evaluate an expression on the source table, then add a derived column. v If you want InfoSphere CDC to evaluate an expression on the target table, then build an expression. Make sure the expression you define contains a valid call to the %STPROC column function. If you are calling a stored procedure that is not owned by the InfoSphere CDC user, you must provide the name in the form <schema>.<stored procedure name>. 4. Map the derived column or the expression to the target column. Related tasks To configure a stored procedure (Oracle and Sybase) on page 230 To add a derived column on page 179 To map a derived column to a target column on page 180 To map an expression to a target column on page 175
Configuring table-level user exits for InfoSphere CDC for IBM i (version 6.2 and below) or InfoSphere CDC for z/OS
You can write standard function user exits in RPG, COBOL, and C/C++. See also: To configure a standard function
To configure a standard function

1. Ensure that you are connected to an InfoSphere CDC for IBM i or an InfoSphere CDC for z/OS datastore. 2. Click Configuration > Subscriptions. 3. Select the subscription. 4. Click the Table Mappings view and select the table mapping from the Source Table column.
231
5. 6. 7. 8.
Right-click and select Open Details.... Click the User Exits tab. Select Standard Function from the User Exit Type list. Enter the name of the user exit programs you want InfoSphere CDC to call beside one or more of the following operations:
9. Click Save. Related concepts Configuring table-level user exits for InfoSphere CDC for IBM i (version 6.2 and below) or InfoSphere CDC for z/OS on page 231
Creating a custom data format for IBM InfoSphere DataStage

You can customize the data that is being generated by InfoSphere CDC and sent to InfoSphere DataStage by specifying a Java class. This is ideal for users who have existing InfoSphere DataStage jobs that expect a particular data format. If you use a custom data format that changes the default format of the flat file sent from InfoSphere CDC to InfoSphere DataStage, the .dsx file described in Using Management Console to generate a definition file on page 121 will not be useful because it contains only default data formatting. If you have created and imported a .dsx file into InfoSphere DataStage, you must ensure that it is still relevant in InfoSphere DataStage Designer. For example, you may have an existing InfoSphere DataStage file-based job that will not read the default data format generated by Management Console. In this case, it may be easier for you to specify a Java class to customize the data format rather than modifying your existing InfoSphere DataStage job. A Java class that creates a custom data format must implement the DataStageDataFormatIF interface.
232
Requirement: If you have an existing custom data format, and you are upgrading from InfoSphere CDC for InfoSphere DataStage version 6.3 to 6.5, you must modify the existing custom data format because of changes to the DataStageDataFormatIF interface in version 6.5. Important: If you are using the direct connect connection method, the custom data format is not supported for version 6.5. For more information on the DataStageDataFormatIF interface, see the Javadocs that are installed with your InfoSphere CDC for InfoSphere DataStage installation. For more information on these requirements, refer to the InfoSphere DataStage product technical documentation. See also: To create a custom data format for InfoSphere DataStage To modify an existing custom data format when upgrading from InfoSphere DataStage 6.3 to 6.5
To create a custom data format for InfoSphere DataStage

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Flat File or Direct Connect tab depending on your mapping type. 6. Enter the name of the Java class that implements the DataStageDataFormatIF interface in the Class Name box. For example, you may have imported the DataStageDataFormatIF interface, and the class that implements this interface in your function has the following definition:
public class CustomFormat1 implements DataStageDataFormatIF
In the Class Name box in the Custom Data Format area, you must type: v CustomFormat1Identifies a stand-alone class. v <Java package>.CustomFormat1Identifies that class is included in a Java package (for example, com.ibm.interface.CustomFormat1 ). The files you generate from compiling the class must be located in a library or folder that is referenced by the CLASSPATH environment variable. 7. Click Save. Related tasks To modify an existing custom data format when upgrading from InfoSphere DataStage 6.3 to 6.5
To modify an existing custom data format when upgrading from InfoSphere DataStage 6.3 to 6.5
1. Add the following method to your existing custom data format that calls the DataStageDataFormatIF interface for the flat file connection method:
233
public void formatChangedRowFields( UserExitJournalHeader journalHeader, DataRecordIF rowDataImage, Map<String, Object> changeRecord, int opType) throws DataTypeConversionException;
Remember: If you are using the direct connect connection method, the custom data format is not supported for version 6.5. 2. Add a return within the method. 3. Recompile the Java file.
Configuring subscription-level user exits

A subscription-level user exit lets you define a set of actions that InfoSphere CDC can run before or after a commit event occurs on a specified subscription. Subscription-level user exits can work alone or in tandem with table-level user exits, to keep track of which table-level user exits were called during a transaction. The subscription-level user exit could then use that information to apply actions based on the tables in the transaction. See also: To configure a user exit for a subscription
To configure a user exit for a subscription

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Right-click and select User Exits. 4. Select Java Class from the User Exit Type list. 5. Enter the name of the Java class user exit that implements the SubscriptionUserExitIF interface in the Class Name box. For example, you may have imported the SubscriptionUserExitIF interface, and the user exit program class that implements this interface in your function has the following definition:
public class UE1 implements SubscriptionUserExitIF
In the Class Name box, you must type: v UE1Indicates a stand-alone class. v <Java package>.UE1Indicates that the class is included in a Java package (for example, com.datamirror.interface.UE1). The files you generate from compiling the user exit program must be located in a library or folder that is referenced by the CLASSPATH environment variable. 6. Enter the parameters that you want to make available to the user exit program in the Parameter box. You can access the parameters in the user exit program class by invoking the getParameter( ) method during the initialization process. There are no conventions for specifying the parameters. The values you type in this box are free-form. The string of parameter values cannot exceed 255 characters in length.
234
Understanding user exit configuration for InfoSphere CDC Event Server

You can configure a user exit to define a set of actions that InfoSphere CDC Event Server can run either before or after applying a row-level operation to a staged target table or to a JMS message destination. Row-level operations include an insert, update, or a delete. You can develop the user exit using Java. You can run user exits either before or after the following conditions: v Row level operations are applied to a table in a staging database v Row level operations are applied to a JMS message destination v Row level operations are applied to a table in a staging database and a JMS message destination In this section, you will learn:
Overriding JMS message header properties

You can override the default JMS message header properties you had set for a source table to XML mapping in the XML Settings tab. Depending on the JMS message property you want to override, InfoSphere CDC Event Server lets you specify parameters for the following methods in the EventServerIF interface: v setJmsCorrelationID() v setJmsCustomProperty() v setJmsDeliveryMode() v setJmsPriority() v setJmsReplyTo() v setJmsTimeToLive() v setJmsType() For an example of a user exit that overrides the JMS properties of an existing source table to XML mapping, see SampleUserExit1.java located in the samples folder or directory of your InfoSphere CDC Event Server installation. See also: To override JMS message header properties
To override JMS message header properties

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Ensure that you have created at least one source table to XML message destination mapping within this subscription. 4. Select the table mapping and right-click Open Details.... 5. Click the User Exits tab. 6. Choose Java Class from the User Exit Type box. 7. In the Class Name box, enter the Java class name of the user exit that implements the UserExitIF interface if you have developed the user exit in Java.
235
8. Enter the parameters that you want to make available to the user exit program in the Parameter box. You can access the parameters in the Java class by invoking the getParameter() method during the initialization process. There are no conventions for specifying the parameters. The values you type in this box are free-form. The string of parameter values cannot exceed 255 characters in length. 9. Enable the Before or After check box for one or more of the following operations:
Option Insert Description InfoSphere CDC Event Server runs the user exit before or after applying an insert operation to a table you have staged, before or after applying an insert operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying an update operation to a table you have staged, before or after applying an update operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a delete operation to a table you have staged, before or after applying a delete operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a refresh operation to a table you have staged, before or after applying a refresh operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a truncate operation to a table you have staged, before or after applying a truncate operation to a JMS message destination, or both.
Update
Delete
Refresh
Truncate
Related concepts Sending XML messages to multiple JMS message destinations on page 240 Defining the JMS message header on page 339 Overriding JMS message header properties on page 235 Understanding user exit configuration for InfoSphere CDC Event Server on page 235
Sending the XML message to a different JMS message destination

You can develop a user exit that lets you send an XML message to a different JMS message destination than the one you added using the InfoSphere CDC Configuration tool. Using the setDestination() method in a user exit with the EventServerIF interface, you can send an XML message to a different JMS message destination. For an example of a user exit that sends an XML message to a different JMS message destination, see SampleUserExit2.java located in the samples folder or directory of your InfoSphere CDC Event Server installation.
236
See also: To send the XML message to another JMS message destination
To send the XML message to another JMS message destination

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Ensure that you have created at least one source table to XML message destination mapping within this subscription. 4. Select the table mapping and right-click Open Details.... 5. Click the User Exits tab. 6. Choose Java Class from the User Exit Type box. 7. In the Class Name box, enter the Java class name of the user exit that implements the UserExitIF interface if you have developed the user exit in Java. 8. Enter the parameters that you want to make available to the user exit program in the Parameter box. You can access the parameters in the Java class by invoking the getParameter() method during the initialization process. There are no conventions for specifying the parameters. The values you type in this box are free-form. The string of parameter values cannot exceed 255 characters in length. 9. Enable the Before or After check box for one or more of the following operations:
Option Insert Description InfoSphere CDC Event Server runs the user exit before or after applying an insert operation to a table you have staged, before or after applying an insert operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying an update operation to a table you have staged, before or after applying an update operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a delete operation to a table you have staged, before or after applying a delete operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a refresh operation to a table you have staged, before or after applying a refresh operation to a JMS message destination, or both.
Update
Delete
Refresh
237
Option Truncate
Description InfoSphere CDC Event Server runs the user exit before or after applying a truncate operation to a table you have staged, before or after applying a truncate operation to a JMS message destination, or both.
10. Click Save. You can start mirroring on the subscription that contains the source table assigned to a JMS message destination. The user exit program will set the new destination before InfoSphere CDC Event Server applies the operation to a JMS message destination. Related concepts Sending XML messages to a JMS message destination on page 363 Sending the XML message to a different JMS message destination on page 236
Creating XML output and applying XSLT to an XML message

You can develop a user exit which lets you create an XML message and then format the XML message using XSL Transformations (XSLT). InfoSphere CDC Event Server lets you specify parameters for the following methods in the EventServerIF interface: v createXmlOutput() v apply Xslt() For example, the following user exit applies XSLT on an existing XML message:
} /** * Apply XSLT transform to the output message * @throws UserExitException */ private void applyXslt(EventServerIF eventServer, ReplicationEventIF p_Event) throws UserExitException { //Get TS/ES XML Engine to create the xml file String xml = eventServer.createXmlOutput(p_Event); // Apply XSLT transform to the xml message String xsltOutput = eventServer.applyXslt("xslt/dbxml.xsl", xml); //Set the xml message that TS/ES is going to send eventServer.setOutputTextMessage(xsltOutput); } public boolean processReplicationEvent(ReplicationEventIF p_Event) throws UserExitException { boolean retValue = true; int eventType = p_Event.getEventType(); if (eventType == ReplicationEventTypes.BEFORE_INSERT_EVENT) { EventServerIF eventServer = p_Event.getEventServer(); // Apply XSLT transform applyXslt(eventServer, p_Event); } return retValue; }
See also: To create an XML message and apply XSLT on page 239
238
To create an XML message and apply XSLT

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Ensure that you have created at least one source table to XML message destination mapping within this subscription. 4. Select the table mapping and right-click Open Details.... 5. Click the User Exits tab. 6. Choose Java Class from the User Exit Type box. 7. In the Class Name box, enter the Java class name of the user exit that implements the UserExitIF interface if you have developed the user exit in Java. 8. Enter the parameters that you want to make available to the user exit program in the Parameter box. You can access the parameters in the Java class by invoking the getParameter() method during the initialization process. There are no conventions for specifying the parameters. The values you type in this box are free-form. The string of parameter values cannot exceed 255 characters in length. 9. Enable the Before or After check box for one or more of the following operations:
Update
Delete
Refresh
Truncate
10. Click Save.
239
You can start mirroring on the subscription that contains the source table assigned to a JMS message destination. The user exit program will set the new destination before InfoSphere CDC Event Server applies the operation to a JMS message destination. Related concepts Sending XML messages to a JMS message destination on page 363 Creating XML output and applying XSLT to an XML message on page 238
Sending XML messages to multiple JMS message destinations

You can send an XML message to a different JMS queue or topic than the one you configured in InfoSphere CDC Event Server using standard Java methods. This lets you override the JMS message destination you selected when configuring InfoSphere CDC. For an example of a user exit that sends to a different JMS message destination, see SampleUserExit2.java located in the samples folder or directory of your InfoSphere CDC Event Server installation. You need to create the JMS destination you want to send the XML message to using Java JMS methods. For more information, see http://java.sun.com/ products/jms/javadoc-102a/index.html. See also: To send an XML message to a different JMS message destination
To send an XML message to a different JMS message destination

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. Ensure that you have created at least one source table to XML message destination mapping within this subscription. Select the table mapping and right-click Open Details.... Click the User Exits tab. Choose Java Class from the User Exit Type box. In the Class Name box, enter the Java class name of the user exit that implements the UserExitIF interface if you have developed the user exit in Java. Enter the parameters that you want to make available to the user exit program in the Parameter box. You can access the parameters in the Java class by invoking the getParameter() method during the initialization process. There are no conventions for specifying the parameters. The values you type in this box are free-form. The string of parameter values cannot exceed 255 characters in length. Enable the Before or After check box for one or more of the following operations:
3. 4. 5. 6. 7.
8.
9.
240
Option Insert
Description InfoSphere CDC Event Server runs the user exit before or after applying an insert operation to a table you have staged, before or after applying an insert operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying an update operation to a table you have staged, before or after applying an update operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a delete operation to a table you have staged, before or after applying a delete operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a refresh operation to a table you have staged, before or after applying a refresh operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a truncate operation to a table you have staged, before or after applying a truncate operation to a JMS message destination, or both.
Update
Delete
Refresh
Truncate
10. Click Save. You can start mirroring on the subscription that contains the source table assigned to a JMS message destination. The user exit program will set the new destination before InfoSphere CDC Event Server applies the operation to a JMS message destination. Related concepts Sending XML messages to a JMS message destination on page 363 Sending XML messages to multiple JMS message destinations on page 240
Querying a Web service to access content

You can query a Web service using standard Java methods. By developing a user exit, you can call a web service with InfoSphere CDC Event Server. For example, you may be using a web service application to keep track of new customers that have just registered online. You can access content from the Web service application to include it in an XML message you configured with InfoSphere CDC Event Server. For an example of a user exit that queries a Web service, see SampleUserExit3.java located in the samples folder or directory of your InfoSphere CDC Event Server installation. See also: To query a Web service to access content on page 242
241
To query a Web service to access content

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Ensure that you have created at least one source table to XML message destination mapping within this subscription. 4. Select the table mapping and right-click Open Details.... 5. Click the User Exits tab. 6. Choose Java Class from the User Exit Type box. 7. In the Class Name box, enter the Java class name of the user exit that implements the UserExitIF interface if you have developed the user exit in Java. 8. In the Class Name box, type:
Option UE1 <Java package>.UE1 Description If it is a stand-alone class If the class is included in a Java package (for example, com.datamirror.interface.UE1). The files you generate from compiling the user exit program must be located in a library or folder that is referenced by the CLASSPATH environment variable.
Option Insert Description InfoSphere CDC Event Server runs the user exit before or after applying an insert operation to a table you have staged, before or after applying an insert operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying an update operation to a table you have staged, before or after applying an update operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a delete operation to a table you have staged, before or after applying a delete operation to a JMS message destination, or both.
Update
Delete
242
Option Refresh
Description InfoSphere CDC Event Server runs the user exit before or after applying a refresh operation to a table you have staged, before or after applying a refresh operation to a JMS message destination, or both. InfoSphere CDC Event Server runs the user exit before or after applying a truncate operation to a table you have staged, before or after applying a truncate operation to a JMS message destination, or both.
Truncate
11. Click Save. You can start mirroring on the subscription that contains the source table assigned to a JMS message destination. The user exit program will set the new destination before InfoSphere CDC Event Server applies the operation to a JMS message destination. Related concepts Sending XML messages to a JMS message destination on page 363 Querying a Web service to access content on page 241
Content based routing

You can develop a user exit that lets you send an XML message to a specific JMS message destination based on the content of the message. For example, you may want to create a simple XML message whenever a new employee is created. You can detect new employees by monitoring inserts into the dbo.Employee table and create an source table to XML mapping using all columns from this table. You can then send the XML message to a JMS queue called "HR1" and also send this XML message to another queue called "IT1" each time a new employee is added to the IT department. See also: To route the content of an XML message to another JMS message destination
To route the content of an XML message to another JMS message destination

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. Ensure that you have created at least one source table to XML message destination mapping within this subscription. Select the table mapping and right-click Open Details.... Click the User Exits tab. Choose Java Class from the User Exit Type box. In the Class Name box, enter the Java class name of the user exit that implements the UserExitIF interface if you have developed the user exit in Java.
3. 4. 5. 6. 7.
243
Update
Delete
Refresh
Truncate
10. Click Save. You can start mirroring on the subscription that contains the source table assigned to a JMS message destination. The user exit program will set the new destination before InfoSphere CDC Event Server applies the operation to a JMS message destination. Related concepts Sending XML messages to multiple JMS message destinations on page 240 Content based routing on page 243
244
Column functions
InfoSphere CDC provides a number of column functions that you can use in expressions when mapping target columns. This topic describes each of the column functions, their syntax and parameters, and also provides examples that illustrate how to use them. In this section, you will learn: Conventions in using column functions String functions on page 246 Date and time functions on page 254 Conversion functions on page 259 Conditional and variable functions on page 269 Data functions on page 271 User exit functions on page 283 %GETCOL column function scenarios (DB2 for IBM i) on page 291 %GETCOL column function scenarios (Dynamic SQL) on page 293 Publishing multiple derived columns using the %GETCOL function (Dynamic SQL) on page 295 XPath functions on page 296 Transform extensions on page 302 Using external Java objects in data transformations on page 310 XPath expression operators on page 311
Conventions in using column functions

Before using column functions in expressions, you should consider the following: v Depending on the InfoSphere CDC you have installed, some column functions may not be supported. v Names of column functions are case insensitive. v For some column functions, you cannot specify a Large OBject (LOB) column as a function parameter. For more information about LOB data type support, see the InfoSphere CDC documentation for your database platform. v You can specify character literals in their internal numeric representation, as parameters for column functions. To do this, use the double-angled bracket notation (<< >>). This notation lets you work with character literals that contain both printable and non-printable characters. v Specifying character values as decimal integers: The values you specify within brackets are decimal integers that represent either American Standard Code for Information Interchange (ASCII) or Extended Binary Coded Decimal Interchange Code (EBCDIC) characters. For ASCII characters, these values must be in the range of 0 to 127. For EBCDIC, these values must be in the range of 0 to 255. For example, <<32>> represents a blank character in ASCII. Do not prefix these values with zeroes. If you have installed InfoSphere CDC for z/OS or InfoSphere CDC for DB2 for i as a target system, and the column function manipulates a value from a
245
target column, then specify integers in EBCDIC format. For all other InfoSphere CDC products installed on the target system, you can specify integers in ASCII format. v InfoSphere CDC for z/OS does not support the double-angled bracket notation. v You can specify multiple characters in the same character literal. For example, if you are using the ASCII character set, the notation <<65>><<78>><<78>><<65>> and <<65>>NN<<65>> represent the string "ANNA". v If you do not follow the double-angled bracket notation, such as <45>>, then InfoSphere CDC does not generate an error. Instead, InfoSphere CDC treats it as a sequence of characters (<, 4, 5, >, and >), and returns the result based on this sequence. v To specify NULL as a parameter in a column function, enter NULL without any delimiter. v Many databases have column name length limitations, which can affect how some expressions and user exits are handled. Column name length limitations can cause InfoSphere CDC to describe a column alias to the target when the source column name length exceeds the column name length limit on the target. The restriction is 30 characters for most InfoSphere CDC compatible databases (Informix, IBM DB2 LUW, Oracle, or Sybase prior to version 15.0), with two exceptions: Microsoft SQL Server 128 characters Sybase 15.0 and later 255 characters
String functions
Use these functions when you want InfoSphere CDC to manipulate strings. During replication, you can have InfoSphere CDC concatenate multiple strings, remove blank characters from a string, change the case of the characters in a string, replace characters of a string with other characters, or extract a substring from a string. Note: Some examples in this section use the double-angled bracket notation (<< >>) and are based on the American Standard Code for Information Interchange (ASCII) character set. Under a different character set, these examples do not produce the same results as described. See also: Concatenation%CONCAT Lowercase%LOWER on page 247 Left trim%LTRIM on page 248 Capitalization%PROPER on page 249 Character substitution%REPLACE on page 250 Right trim%RTRIM on page 251 Substring%SUBSTRING on page 252 Uppercase%UPPER on page 253
Concatenation%CONCAT
Use this function when you want InfoSphere CDC to concatenate multiple character fields and literals to form a single string. There is no limit to the number of input fields or the resulting length.
246
Syntax
%CONCAT(<parm1>, <parm2>, ...<parm20>)
Parameters
parm1 to parm20Specify character columns, literals, or column functions that return character strings. Note: Concatenating a NULL has no effect. If all input fields are NULL, then NULL is returned.
Result data type

Character-based.
Examples
%CONCAT(FNAME, " ", LNAME) Concatenates the values from the FNAME and LNAME columns with a blank character inserted between them. For example, if FNAME = "Ray" and LNAME = "Kennedy", this function returns "Ray Kennedy". WITH P %CONCAT("InfoSphere", " ", "CDC", "Management", "Console") Returns the string "InfoSphere CDC Management Console". %CONCAT("Anna", "<<32>>", "Kim<<0>>") Returns the NULL-terminated ASCII string "Anna Kim". For information about the double-angled bracket notation, see String functions on page 246.
Lowercase%LOWER
Use this function when you want InfoSphere CDC to convert all uppercase characters in a string to lowercase during replication.
Syntax
%LOWER(<parm>)
Parameters
parmSpecifies a character column, literal, or column function that returns a character string.
Result data type

Character-based. Returns NULL if parm is NULL.
Examples
%LOWER(DEPARTMENT) Returns the strings in the DEPARTMENT column in lowercase. For example, "accounting", "marketing", and so on.
Column functions
247
%LOWER("BrUcE JoNeS") Returns the string "bruce jones". %LOWER(%SUBSTRING("BrUcE JoNeS",3,2)) Returns the string "uc". %LOWER("<<65>><<78>><<78>><<65>><<32>><<75>><<73>><<77>>") Returns the ASCII string "anna kim". Related concepts String functions on page 246 Related reference Uppercase%UPPER on page 253 Substring%SUBSTRING on page 252
Left trim%LTRIM
Use this function when you want InfoSphere CDC to trim all leading blank characters from a character string during replication. Blank characters that are embedded in a string are not trimmed.
Syntax
%LTRIM(<parm>)
Parameters
Result data type

Examples
%LTRIM(" George Smith") Returns the string "George Smith" with no leading blank characters. %LTRIM("Andrea Moss ") Returns the string "Andrea Moss ". The %LTRIM function does not trim trailing and embedded blank characters. %LTRIM("<<32>><<32>><<32>>Anna Kim") Returns the ASCII string "Anna Kim" with no leading blank characters.
248
Related concepts String functions on page 246 Related reference Right trim%RTRIM on page 251
Capitalization%PROPER
Use this function when you want InfoSphere CDC to convert the first letter of each word to uppercase, and the remaining letters to lowercase during replication. A word is a consecutive sequence of non-blank characters encapsulated by blank characters and string boundaries.
Syntax
%PROPER(<parm>)
Parameters
parmSpecifies a character column, literal, or column manipulation function that returns a character string.
Result data type

Examples
%PROPER(NAME) Returns the value in the NAME column with the first letter of each word capitalized. For example, "Steve Malone". %PROPER("TiNa MaNcInI") Returns the string "Tina Mancini". %PROPER(%SUBSTRING("tInA mAnCiNi",3,6)) Returns the string "Na Man". %PROPER("mary-lou fernandez") Returns the string "Mary-lou Fernandez". Note that "lou" is not converted to "Lou". %PROPER("<<97><<110>><<110>><<97>><<32>><<107>><<105>><<109>>") Returns the ASCII string "Anna Kim".
Column functions
249
Related concepts String functions on page 246 Related reference Substring%SUBSTRING on page 252
Character substitution%REPLACE
Use this function when you want InfoSphere CDC to replace leading, trailing, or all occurrences of a specified character with another character during replication. It provides a character-by-character replacement. You can use this function to replace leading blank characters with zeros.
Syntax
%REPLACE(<parm>, "<type>", "<str1>", "<str2>")
Parameters
v parmSpecifies a character column, literal, or column function that returns a character string. If parm is NULL, this function returns NULL. v typeSpecifies the substitution type. You must enclose values of this parameter in double quotes. *ALLReplaces all occurrences of the specified character. *TRAILReplaces all trailing occurrences of the specified character. *LEADReplaces all leading occurrences of the specified character. v str1Specifies the set of characters to be replaced. v str2Specifies the set of characters to replace those specified in str1 . If the number of characters in str1 is greater than that in str2 , the extraneous characters in str1 are deleted in the result. If the number of characters in str1 is less than that in strthe extraneous characters in str2 are ignored. If you specify str2 as two consecutive double quotes ("") , you can remove instances of a character from str1.
Result data type

Character. Returns NULL if parm is NULL.
Examples
%REPLACE(CUSTNO, "*LEAD", " ", "0") Replaces all leading blank characters in the CUSTNO column with zeros. %REPLACE(CUSTNO, "*LEAD", "ABC", "123") Replaces all leading occurrences of "A" with "1", "B" with "2", and "C" with "3" in the CUSTNO column. Evaluation begins with the first character and continues until a character other than "A", "B" or "C" is found. For example, if a column value is "AC7777", this example returns "137777". If a column value is "ADC7777", this example returns "1DC7777". %REPLACE(PHONENO, "*ALL", " ", "")
250
Removes all blank characters in the PHONENO column. This example illustrates how the %REPLACE function can be used to remove a character from a string instead of replacing it with another character. %REPLACE(PHONENO, "*LEAD", " ", "") Removes all leading blank characters in the PHONENO column. This example is similar to the previous example, except that only leading blank characters are removed. To remove leading blank characters, you can also use the %LTRIM function. To remove trailing blank characters, use the %RTRIM function. %REPLACE(PARTNO, "*TRAIL", "ACY", "acy") Replaces all trailing occurrences of "A" with "a", "C" with "c", and "Y" with "y" in the PARTNO column. Evaluation begins with the last character and continues until a character other than "A", "C" or "Y" is found. For example, if a column value is "2361ACY", this example returns "2361acy". If a column value is "2361ADY", this example returns "2361ADy". %REPLACE("259899", "*ALL", "29", "4") Returns "458". Replaces all occurrences of "2" with "4", and removes all occurrences of "9". %REPLACE("259899", "*ALL", "2", "45") Returns "459899". Replaces all occurrences of "2" with "4". Does not remove occurrences of "5". %REPLACE(PRODDESC, "*ALL", "<<0>><<13>>", "<<32>><<32>>") On platform that use the ASCII character set, this functions replaces all occurrences of NUL and carriage return in the PRODDESC column with blank characters. Related concepts String functions on page 246 Related reference Left trim%LTRIM on page 248 Right trim%RTRIM
Right trim%RTRIM
Use this function when you want InfoSphere CDC to trim all trailing blank characters from a character string during replication. Blank characters that are embedded in a string are not trimmed.
Syntax
%RTRIM(<parm>)
Parameters
v parmSpecifies a character column, literal, or column function that returns a character string.
Column functions
251
Result data type

Examples
%RTRIM("Steve Malone ") Returns the string "Steve Malone" with no trailing blank characters. %RTRIM(" Andrea Moss") Returns the string " Andrea Moss". The %RTRIM function does not trim leading and embedded blank characters. %RTRIM("Anna Kim<<32>><<32>><<32>>") Returns the ASCII string "Anna Kim" with no trailing blank characters. Related concepts String functions on page 246 Related reference Left trim%LTRIM on page 248
Substring%SUBSTRING
Use this function when you want InfoSphere CDC to create a character string that is a subset of an existing string that begins at a specified starting position and continues for a specified length.
Syntax
%SUBSTRING(<parm>, <position>, <length>)
Parameters
v parmSpecifies a character column, literal, or column function that returns a character string. v positionSpecifies the starting position. This value must be greater than or equal to 1. v lengthSpecifies the length of the substring. This value must be greater than or equal to 1.
Result data type

Character-based. Returns NULL if parm is NULL. If position is greater than the length of parm , then the function returns a string of blank characters, with a length of length. If position is less than the length of parm, but position + length is greater then the length of parm , then the function returns a string of length length that has the portion of parm that starts at position and ends at the end of parm, right-padded with blank characters.
Examples
%SUBSTRING(DIVISION,3,2)
252
Returns two characters from the DIVISION column beginning from the third position. %SUBSTRING("Tony Jackson",0,2) Generates a runtime error because the starting position cannot be less than 1. %SUBSTRING("Anna<<32>>Kim<<0>>", 1, 8) Returns the ASCII string "Anna Kim" with no NULL-termination. Related concepts String functions on page 246
Uppercase%UPPER
Use this function when you want InfoSphere CDC to convert all lowercase characters in a string to uppercase during replication.
Syntax
%UPPER(<parm>)
Parameters
Result data type

Examples
%UPPER(DEPARTMENT) Returns the strings in the DEPARTMENT column in uppercase. For example, "ACCOUNTING", "MARKETING", and so on. %UPPER("AnDrEa MoSs") Returns the string "ANDREA MOSS". %UPPER("[emp ny]") Returns the string "[EMP NY]". %UPPER(%SUBSTRING("AnDrEa MoSs",3,2)) Returns the string "DR". %UPPER("<<97>><<110>><<110>><<97>><<32>><<75>><<73>><<77>>") Returns the ASCII string "ANNA KIM".
Column functions
253
Related concepts String functions on page 246 Related reference Lowercase%LOWER on page 247 Substring%SUBSTRING on page 252
Date and time functions

Use these functions when you want InfoSphere CDC to manipulate date and time values during replication. You can add a two-digit century specification to a date, or retrieve the current date and time. See also: Century%CENTURY Current date%CURDATE on page 255 Current time%CURTIME on page 256 Current timestamp%CURTMSTP on page 258
Century%CENTURY
Use this function when you want InfoSphere CDC to add a two-digit century specification to a date that identifies the year without the century during replication. This function accepts a character date value specified in one of six different formats.
Syntax
%CENTURY(<parm>, "<type>", [centuryline])
Parameters
v parmSpecifies a character column, literal or column function that returns a date value accepted by the function. v typeSpecifies the format of the input date. You must enclose values of this parameter in double quotes. *YMDThe input format is yymmdd. *MDYThe input format is mmddyy. *DMYThe input format is ddmmyy. *YMThe input format is yymm. *MYThe input format is mmyy. *JULThe input format is yyjjj, where jjj represent the sequence number of a day in the calendar year. jjj must be between 1, which represents January 1st, and 366, which represents December 31st in a leap year. For jjj values less than 100, you must specify the leading zero or zeros. For example, the Julian date for February 4th is 035, which represents the 35th day of the year. v centurylineSpecifies the year in the century used to determine which century is added to the date. All years that precede the century line year will be designated as being in the 21st century. All years including and following the century line year will be designated as being in the 20th century. If centuryline is greater than 99, all years are designated as being in the 21st century. For example, if centuryline is set to 30 and the two-digit year specified by parm is 19, this function returns 2019. If centuryline is set to 20 and the two-digit year specified by parm is 33, this function returns 1933.
254
This parameter is optional. If you omit this parameter, InfoSphere CDC assumes a default value of 40.
Result data type

Character if parm is character. Otherwise, it returns a numeric value. If parm or type is NULL, this function returns NULL.
Examples
Input Date (parm) 101001 211197 032080 0493 2001 99365 NULL Input Format (type) "*YMD" "*DMY" "*MDY" "*MY" "*YM" "*JUL" "*YM" 92 0 60 80 Input century line (centuryline) Result 20101001 (October 1, 2010) 21111997 (November 21, 1997) 03201980 (March 20, 1980) 041993 (April 1993) 202001 (January 2002) 1999365 (December 31, 1999) NULL
Related concepts Date and time functions on page 254
Current date%CURDATE
Use this function when you want InfoSphere CDC to return the current date during data replication (refresh or mirroring) activities on the source or target. For example, you may want to track when InfoSphere CDC inserts a record or when it performs updates on source and target columns. This function uses the system clock you have set on the source or target. Note: InfoSphere CDC for IBM i does not support this function. Mapping a target column to an expression that uses the %CURDATE function is not the same as defining the current date as the initial value for the target column. When you map a target column to an expression, InfoSphere CDC populates the target column with the current date when a record is inserted or updated in the target table. However, when you define the initial value as the current date, InfoSphere CDC populates the target column with the current date only when it inserts a record into the target table.
Syntax
%CURDATE("<timezone>")
Parameters
timezoneSpecifies the time zone of the result. You must enclose values of this parameter in double or single quotes. v *LOCReturns the date local to the source or target.
Column functions
255
v *UTCReturns the date in Coordinated Universal Time (UTC). v *GMTReturns the date in Greenwich Mean Time (GMT). This is the same as *UTC.
Result data type

Character in the format CCYY-MM-DD.
Examples
%CURDATE("*LOC") If the local time is March 11, 2004, this function returns 2004-03-11. %CURDATE("*UTC") For a server located in the Japan Standard Time (JST) zone, on August 28, 2007, at 1:21 AM, this function returns 2007- 08-27. JST is 9 hours ahead of UTC (UTC+9). %CURDATE("*GMT") For a server located in the Japan Standard Time (JST) zone, on August 28, 2007, at 1:21 AM, this function returns 2007- 08-27. JST is 9 hours ahead of UTC (UTC+9). This example is equivalent to %CURDATE ("*UTC"). %SUBSTRING(%TOCHAR(%CURDATE("*LOC"), 10), 6, 5) Returns the month and day of the %CURDATE function invocation local to the source or target. You can use this example if you require the month and day only. For example, if the local date is January 29, 2007, the expression returns "01-29". The %TOCHAR function extracts the month, separator character, and day. Related concepts Date and time functions on page 254 Mapping initial values to target columns on page 177 Related reference Character conversion%TOCHAR on page 259 Substring%SUBSTRING on page 252 Current time%CURTIME Current timestamp%CURTMSTP on page 258
Current time%CURTIME
Use this function when you want InfoSphere CDC to return the time when it inserts or updates a row on source and target columns. This function uses the system clock on the source or target. Note: InfoSphere CDC for DB2 for i does not support this function.
Syntax
%CURTIME("<timezone>")
256
Parameters
timezoneSpecifies the time zone of the result. You must enclose values of this parameter in double or single quotes. v *LOCReturns the time local to the source or target. v *UTCReturns the time in Coordinated Universal Time (UTC). v *GMTReturns the time in Greenwich Mean Time (GMT). This is the same as *UTC.
Result data type

Character, in the format HH.MM.SS.
Examples
%CURTIME("*LOC") If the local time is 11:25:22 PM (local), this function returns 23.25.22. %CURTIME("*UTC") For a server located in the Hawaiian Standard Time (HST) zone, at 9:14:33 PM, this function returns 07.14.33. HST is 10 hours behind UTC (UTC-10). %CURTIME("*GMT") For a server located in the Hawaiian Standard Time (HST) zone, at 9:14:33 PM, this function returns 07.14.33. HST is 10 hours behind UTC (UTC-10). This example is equivalent to %CURTIME ("*UTC"). %TOCHAR(%IF(%VAR(EST, %TONUMBER(%REPLACE(%TOCHAR(%CURTIME("*LOC"), 8), "*ALL", ".", "")) + 30000) < 240000, %VAR(EST), %VAR(EST) 240000), 6) Returns the time of the %CURTIME function invocation three time zones ahead relative to the local time zone on the source or target. This example illustrates that an expression can be defined to convert local time to the equivalent time in any other time zone (not necessarily UTC). It returns a character result after performing time calculations. For example, if this expression is evaluated on a server located in the Pacific Standard Time (PST) zone at 3:22:48 PM, the expression returns "182248". The result represents the same time in the Eastern Standard Time (EST) zone, which is 3 hours ahead of PST (PST+3). In the event that the returned Pacific time is in the interval from 9:00:00 PM to 12:00:00 AM, the %IF function ensures that the expression returns the equivalent Eastern time on the following day. To modify the above expression to select a different time zone ahead or behind the local time zone, change + 30000 to a different sign and value. For example, changing +30000 to +20000 returns the equivalent time in the Central Standard Time (CST) zone. %IF(%VAR(DIFF, %TONUMBER(%TOCHAR(%CURTIME("*LOC"), 2)) %TONUMBER(%TOCHAR(%CURTIME("*UTC"), 2))) > 12, %VAR(DIFF) %IF(%VAR(DIFF) < 12, %VAR(DIFF) + 24, &VAR(DIFF)))
24,
Column functions
257
Returns the time difference between UTC and the time zone of the source or target where the %CURTIME functions are invoked. For example, if this expression is evaluated on a server located in the Central Europe Time (CET) zone at 6:43:07 PM, the expression returns 1. If the server is located in the Mountain Standard Time (MST) zone and the functions are invoked at 1:22:13 AM, the expression returns -7. Note: This example compares equivalent times after obtaining two separate time samples, which may not always produce the correct results. The expression will not produce the correct result if %CURTIME ("*LOC") is invoked at 7:59:59 AM, local time, and %CURTIME ("*UTC") is invoked one second later at 8:00:00 AM, local time. Related concepts Date and time functions on page 254 Mapping initial values to target columns on page 177 Related reference Current date%CURDATE on page 255 Current timestamp%CURTMSTP Character conversion%TOCHAR on page 259 Substring%SUBSTRING on page 252
Current timestamp%CURTMSTP
Use this function to when you want InfoSphere CDC to track the date and time when it inserts or updates a row in source and target columns. This function uses the system clock on the source or target. Note: InfoSphere CDC for DB2 for i does not support this function.
Syntax
%CURTMSTP("<timezone>")
Parameters
timezoneSpecifies the time zone of the result. You must enclose values of this parameter in double or single quotes. v *LOCReturns the time local to the source or target. v *UTCReturns the time in Coordinated Universal Time (UTC). v *GMTReturns the time in Greenwich Mean Time (GMT). This is the same as *UTC.
Result data type

Character, in the format CCYY-MM-DD-HH.MM.SS.UUUUUU, where UUUUUU represents the number of microseconds. For example, 2008-12-09-03.11.34.849217. For environments that do not support microsecond precision, zeroes will be used to right-pad the result to a six-digit length. In the examples for this function, the results do not show microseconds.
Examples
%CURTMSTP("*LOC")
258
If the local time is 2:05:54 AM on June 18, 2005, this function returns 2005-06-18-02.05.54. %CURTMSTP("*UTC") For a server located in the Japan Standard Time (JST) zone, at 4:31:01 AM on September 22, 2011, this function returns 2011-09-21-19.31.01. JST is 9 hours ahead of UTC (UTC+9). %CURTMSTP("*GMT") For a server located in the Japan Standard Time (JST) zone, at 4:31:01 AM on September 22, 2011, this function returns 2011-09-21-19.31.01. JST is 9 hours ahead of UTC (UTC+9). This example is equivalent to %CURTMSTP("*UTC"). %TOCHAR(%CURTMSTP("*UTC"), 16) Returns the date and time (hours and minutes only) of the %CURTMSTP function invocation in UTC. You can use this example if you do not require the number of seconds and microseconds. For example, if the %CURTMSTP function is invoked on a server located in the Western Standard Time (WST) zone on April 24, 2013 at 4:05:22 AM, the expression returns "2013-04-23-20.05". WST is 8 hours ahead of UTC (UTC+8). The %TOCHAR function converts the date to character data and returns the first 16 characters of the timestamp returned by the %CURTMSTP function. Related concepts Date and time functions on page 254 Related reference Character conversion%TOCHAR Current date%CURDATE on page 255 Current time%CURTIME on page 256
Conversion functions
Use these functions when you want InfoSphere CDC to convert values from one data type to another during replication. You can convert from any value to a character string or a numeric value, or from a numeric or character value to a datetime-type value. See also: Character conversion%TOCHAR Character format conversion%TOCHARFORMAT on page 261 Date conversion%TODATE on page 262 Date and time conversion%TODATETIME on page 263 Number conversion%TONUMBER on page 266 Time conversion%TOTIME on page 267
Character conversion%TOCHAR
Use this function to convert any value to a character string.
Column functions
259
Syntax
%TOCHAR(<parm>, <length>, [decimal])
Parameters
v parmSpecifies a column name, literal, or a column function. If you specify a date, time, or timestamp for this parameter, the output format is "yyyy-MM-dd HH:mm:ss". If you specify a DATE, the output format is "yyyy-MM-dd". If you specify a TIME, the output format is "HH:mm:ss" v lengthSpecifies the number of characters to be returned. A decimal place counts as a returned value. For example, if you specify that you want to return three characters, this function returns the three leftmost or high order digits of parm. Note: Specify a negative value for this parameter if you would like %TOCHAR to treat the incoming value as unsigned. This feature is only available with InfoSphere CDC for z/OS. v decimalAn integer value that specifies the number of decimal places in the returned value. The following table provides several examples with integers that have a defined number of decimal places and an example of how InfoSphere CDC converts real floating decimals.
Input value 1.2345 1234.5 1.02 1.02 (Real floating decimal) Length 6 7 7 7 Decimal 2 2 2 2 Result 001.23 1234.50 0001.02 1.02000
Result data type

If length specifies a value greater than the length of parm, the result is left-padded or right-padded with blank characters.
Examples
Input value (parm) 12345 123.45 0.123 1234 Input length (length) 3 5 3 6 Decimal places (decimal) Not specified. Not specified. Not specified. Not specified. Result "123" "123.4" "0.1" "001234" The integer value is left-padded with zeros to return a string of six characters. 1.02 7 Not specified. "1.020000" The decimal part is right-padded with zeros to return a string of seven characters.
260
Input value (parm) 45699
Input length (length) 9
Decimal places (decimal) 2
Result "000456.99" The integer value is left-padded with zeros and two decimal places to return a string of nine characters.
&SEQNO
-20
Not specified.
"13878964169332555778". By specifying a negative length, %TOCHAR treats the &SEQNO journal control field as unsigned. Note: The ability to specify negative lengths is only supported by InfoSphere CDC for z/OS.
Related reference Character format conversion%TOCHARFORMAT Number conversion%TONUMBER on page 266
Character format conversion%TOCHARFORMAT

Note: This function is not available for InfoSphere CDC for z/OS Use this function to convert any date or number to a string. This function returns date formats found in java.text.SimpleDateFormat or number formats found in java.text.DecimalFormat. If your input value is a String, this function returns a String.
Syntax
%TOCHARFORMAT(<parm>, "<format>")
Parameters
v parmSpecifies the input value which can be a String, Date, or Number. v formatSpecifies the format of the returned value. Note the following when specifying values for this parameter: If parm = NumberSpecify formats that are valid for java.text.DecimalFormat. If parm = DateSpecify formats that are valid for java.text.SimpleDateFormat. If parm = StringThe function will ignore this parameter and return a String.
Result data type

String. This function returns NULL if parm or format are NULL.
Column functions
261
Examples
Input value (parm) 1234 Format for return value (format) Result "0.###E0" Returns a string in the following format: v 1.234E3 date "yyyy.MM.dd G 'at' HH:mm:ss z" Returns a string in the following format: v 2001.07.04 AD at 12:08:56 PDT
Related reference Character conversion%TOCHAR on page 259 Number conversion%TONUMBER on page 266
Date conversion%TODATE
Use this function when you want InfoSphere CDC to convert a numeric or character data type value to a datetime-data type during replication. You can convert dates from packed-numeric, zoned-numeric, or from character formats without century, to datetime or character-type values with century.
Syntax
%TODATE(<date>, "<type>")
Parameters
v dateSpecifies the input date. If date is the name of a column containing a character string, the length of that string must match the length for the format specified by type as indicated below. InfoSphere CDC generates an error if the length is any other value. Note the following about the values returned by this function: If you specify NULL for date, this function returns NULL. If you specify "0" for date, this function returns "1901-01-01". If you specify a DATE for date, this function returns a DATE Note: If you specify "-" and "/" characters, these characters are removed before the value is evaluated by InfoSphere CDC.
type value *YMD (yymmdd) *MDY (mmddyy) *DMY (ddmmyy) *YYMD (ccyymmdd) *CYMD (cyymmdd) *JUL (yyjjj) *CJUL (cyyjjj) *YJUL (ccyyjjj) Length of date 6 digits 6 digits 6 digits 8 digits 7 digits 6 digits 6 digits 7 digits
v typeSpecifies the format of the input date. You must enclose values of this parameter in double quotes.
262
*YMDSpecifies the input format is yymmdd. *MDYSpecifies the input format is mmddyy. *DMYSpecifies the input format is ddmmyy. *YYMDSpecifies the input format is ccyymmdd, where cc represents the century. *CYMDSpecifies the input format is cyymmdd, where c represents the century. A value of 0 for c represents the 20th century. Any other value represents the 21st century. *JULSpecifies the input format is yyjjj, where jjj represent the sequence number of a day in the calendar year. jjj must be between 1, which represents January 1st, and 366, which represents December 31st in a leap year. For jjj values less than 100, you must specify the leading zero or zeros. For example, the Julian date for February 4th is 035, which represents the 35th day of the year. When you set type to *JUL, if you specify a value for yy between 40 and 99, the %TODATE function returns the corresponding year in the 20th century. For example, 1940. If you specify a value for yy between 0 and 39, the %TODATE function returns the corresponding year in the 21st century. For example, 2039. *CJULSpecifies the input format is cyyjjj, where c represents the century. A value of 0 for c represents the 20th century. Any other value represents the 21st century. *YJULSpecifies the input format is ccyyjjj, where cc represents the century.
Result data type

Date in standard ISO (International Organization for Standardization) format, that is CCYY-MM-DD.
Examples
Input date (date) 760704 100195 000000 010768 19560205 1100216 95004 102032 1991359 Input format (type) *YMD *MDY *MDY *DMY *YYMD *CYMD *JUL *CJUL *YJUL Result 1976-07-04 (July 4, 1976) 1995-10-01 (October 10, 1995) 1901-01-01 (January 1, 1901) 1968-07-01 (July 1, 1968) 1956-02-05 (February 5, 1956) 2010-02-16 (February 16, 2010) 1995-01-04 (January 4, 1995) 2002-02-01 (February 2, 2002) 1991-12-25 (December 25, 1991)
Related reference Date and time conversion%TODATETIME
Date and time conversion%TODATETIME

Use this function when you want InfoSphere CDC to convert a numeric or character data type to a datetime data type during replication. You can convert
Column functions
263
dates from packed-numeric, zoned-numeric, or from character formats without century, to datetime or character-type values with century. You can also convert time data types from packed-numeric, zoned-numeric, or character formats into datetime or character-type values with century. Note: InfoSphere CDC for DB2 for i does not support this function.
Syntax
%TODATETIME (<date>, "<type>", <time>)
Parameters
v dateSpecifies the input date. If date is the name of a column containing a character string, the length of that string must match the length for the format specified by type as indicated below. InfoSphere CDC generates an error if the length is any other value. Note the following about the values returned by this function: If you specify NULL for date, this function returns NULL. If InfoSphere CDC encounters an error when parsingdate, this function returns "1901-01-01". If you specify "DATE" for date, this function returns a timestamp. Note: If you specify "-" and "/" characters, these characters are removed before the value is evaluated by InfoSphere CDC.
type value *YMD (yymmdd) *MDY (mmddyy) *DMY (ddmmyy) *YYMD (ccyymmdd) *CYMD (cyymmdd) *JUL (yyjjj) *CJUL (cyyjjj) *YJUL (ccyyjjj) Length of date 6 digits 6 digits 6 digits 8 digits 7 digits 6 digits 6 digits 7 digits
v typeSpecifies the format of the input date. You must enclose values of this parameter in double quotes. *YMDSpecifies the input format is yymmdd. *MDYSpecifies the input format is mmddyy. *DMYSpecifies the input format is ddmmyy. *YYMDSpecifies the input format is ccyymmdd, where cc represents the century. *CYMDSpecifies the input format is cyymmdd, where c represents the century. A value of 0 for c represents the 20th century. Any other value represents the 21st century. *JULSpecifies the input format is yyjjj, where jjj represent the sequence number of a day in the calendar year. jjj must be between 1, which represents January 1st, and 366, which represents December 31st in a leap year. For jjj values less than 100, you must specify the leading zero or zeros. For example, the Julian date for February 4th is 035, which represents the 35th day of the year.
264
When you set type to *JUL, if you specify a value for yy between 40 and 99, the %TODATETIME function returns the corresponding year in the 20th century. For example, 1940. If you specify a value for yy between 0 and 39, the %TODATETIME function returns the corresponding year in the 21st century. For example, 2039. *CJULSpecifies the input format is cyyjjj, where c represents the century. A value of 0 for c represents the 20th century. Any other value represents the 21st century. *YJULSpecifies the input format is ccyyjjj, where cc represents the century. v timeSpecifies the input time. The table below indicates the length and format for this parameter, depending on the data type of the input time.
Data type Numeric Length 5 digits 6 digits Character 8 digits Format HMMSS. For example, 71500 represents 7:15 AM. HHMMSS. For example, 223000 represents 10:30 PM. HH:MM:SS. You must enclose values of this parameter in double quotes. For example, "10:30:00" represents 10:30 AM.
Result data type

Date, in standard ISO (International Organization for Standardization) format. If the input date contains an invalid value for the year, month, or day, the %TODATETIME function returns the default value 1901-01-01 for the date.
Examples
The table below provides examples for this function. These examples show the colon (:) as the separator in the returned ISO time values. Depending on your environment, a different character may separate the year, the month, and the day in the output date. Also, a different character may separate the hours, the minutes, and the seconds in the output time.
Input date (date) 891102 Input format (type) *YMD Input time (time) 112500 Result 1989-11-02 11:25:00 (November 2, 1989 at 11:25 AM) 1996-03-04 13:42:00 (March 4, 1996 at 1:42 PM) 1901-01-01 10:55:00 (January 1, 1901 at 10:55 AM) 1970-05-21 09:05:00 (May 21, 1970 at 9:05 AM) 2010-09-02 02:30:00 (February 9, 2010 at 2:30 AM)
Column functions
030496
*MDY
"13:42:00"
000000
*MDY
"10:55:00"
210570
*DMY
"09:05:00"
20100902
*YYMD
023000
265
Input date (date) 1060723
Input format (type) *CYMD
Input time (time) 193300
Result 2006-07-23 19:33:00 (July 23, 2006 at 7:33 PM) 1991-03-01 22:01:00 (March 1, 1991 at 10:01 PM) 1997-04-16 04:35:00 (April 16, 1997 at 4:35 AM) 2002-04-02 17:15:00 (April 2, 2002 at 5:15 PM)
91060
*JUL
220100
097106
*CJUL
043500
2002092
*YJUL
"17:15:00"
Related reference Date conversion%TODATE on page 262 Time conversion%TOTIME on page 267
Number conversion%TONUMBER
Use this function when you want InfoSphere CDC to convert a character field or literal to a numeric value during replication. If your input value is a number, this function returns a number.
Syntax
%TONUMBER(<parm>)
Parameters
v parmSpecifies a character column, literal or column function that returns a character string. It must be in the following format:
[<whitepsace>] [<sign>] [<digits>] [.<digits>] [{e | E} [<sign>] <digits>]
In the specification above, the white space can consist of one or more blank or tab characters. The signs must be plus (+) or minus (-), and you can specify only decimal digits. At least one digit must appear after the decimal point. The decimal digits may be followed by an exponent that consists of the letter E (in upper or lower case) and an optionally signed decimal integer. Note the following when using the %TONUMBER function: If parm does not follow the format above, the %TONUMBER function returns zero. If you convert a correctly formed character field or literal that contains an exponent, the %TONUMBER function returns a signed decimal of arbitrary precision with a 32-bit scale. Floating point values and integer values expressed in character form are converted to a signed decimal of arbitrary precision with a 32-bit scale. Precision may be lost when you convert numerical values expressed in character form that exceed a certain number of digits. If parm is a number, this function returns a number.
Result data type

Numeric.
266
Examples
Input value (parm) "12.45" Result Returns a floating point value of 12.45. If this function is mapped to an integer column, then it truncates the decimal part is truncated and returns 12. Returns an integer value of 3. Returns a floating point value of -12.4. Returns an integer of -920824. Leading zeros are removed. If the column from which this function is called is nullable, this function returns NULL. Otherwise, it returns an integer value of 0. Returns an integer value of 0, because the %TONUMBER function cannot convert character strings that do not conform to the data format described for parm. Returns an integer value of 0. The input value is valid as a character string, but it cannot be converted to a numeric value. Returns a non-zero result, but precision may be lost. Returns an integer value of 0. Returns an integer value of 0. Returns a floating point value of 220. Returns a floating point value of 4500. Returns an integer value of 0. Returns a floating point value of -0.1. Returns an integer value of 0. Returns a floating point value of 66.67
"3" "-12.4" "-0920824" NULL
"ABC"
""
"12345678901234567.89" "- 10" "911HELLO" "+2.2e+2" " 4.5E3" "$1000" "-.1e0" "44 90" " 66.67"
Time conversion%TOTIME
Use this function when you want InfoSphere CDC to convert a character, numeric, or time data type to a time data type during replication. You can convert from different formats based on the type of the input value. Use this function to when you want InfoSphere CDC to track the date and time when it inserts or updates a row in source and target columns. This function uses the system clock on the source or target. Note: InfoSphere CDC for DB2 for i does not support this function.
Syntax
%TOTIME(<time>)
Parameters
timeSpecifies a column or literal that can have one of the following types:
Column functions
267
v Time, in the format HMMSS or HHMMSS. For example, 71500 represents 7:15 AM and 223000 represents 10:30 PM. v Numeric. This value must be positive, and if it contains a fractional part, the fraction must be zero. v Character, in one of the following formats:
[whitespace] digit digit digit digit digit digit [whitespace]
This format lets you specify a time value that contains six consecutive digits. Any number of blank characters can precede or follow the six digits. For example, %TOTIME ( 012537 ) returns 01:25:37.
[whitespace] digit [digit] separator digit [digit] [separator digit [digit]] [whitespace]
This format lets you specify a time value that contains valid separator characters (colon, comma, period or one or more spaces) between hours, minutes, and seconds. Any number of blank characters can precede the first digit or follow the last digit. You cannot specify more than one separator character in the time value. For example, %TOTIME (12:05.20) is not valid. You can omit the number of seconds, in which case the %TOTIME function assumes zero seconds. For example, %TOTIME ("12:05") returns 12:05:00. You can omit leading zeros in the number of hours, minutes, and seconds. For example, %TOTIME ("12 5 20") returns 12:05:20.
[whitespace] digit [digit] separator digit [digit] [whitespace] {A | a | P | p} [{M | m}] [whitespace]
This format lets you specify a time value that indicates AM or PM. You can specify AM and PM in a number of different ways, such as A, AM, Am, a, aM, am, P, or PM. Any number of blank characters can precede the first digit or follow the AM/PM specification. You cannot specify more than one separator character in the time value. For example, %TOTIME ("04: 20 PM") is not valid. You cannot specify seconds in this format. If you do so, the %TOTIME function assumes zero seconds. You can omit leading zeros in the number of hours and minutes. For example, %TOTIME ("3 5 P") returns 15:05:00. Note the following with respect to return values for this function: v If your input value is NULL, this function returns NULL. v If your input value is a Time this function returns a Time. v If InfoSphere CDC encounters an error when parsing the input value, this function returns 00:00:00".
Result data type

This function returns a Time.
Examples
The following examples show the colon (:) as the separator character in the returned ISO (International Organization for Standardization) time values. Depending on your environment, a different character may separate the hours, minutes, and seconds in the output time.
Input value (parm) " 012537 " Result 01:25:37
268
Input value (parm) "22:4:12" "4:05P" "2 5 Am" 204521 91035.0000 250521 "10: 10:35"
Result 22:04:12 16:05:00 02:05:00 20:45:21 09:10:35 00:00:00 00:00:00
Conditional and variable functions

Use the %IF column function when you want InfoSphere CDC to evaluate an expression and return different results. Use the %VAR function when you want InfoSphere CDC to declare a new variable, assign a value to it, or retrieve the value of an existing variable. See also: Conditional%IF Variable%VAR on page 270
Conditional%IF
Use this function when you want InfoSphere CDC to evaluate a conditional expression and return different results during replication.
Syntax
%IF(<conditional>, <expression_if_true>, <expression_if_false>)
Parameters
v conditionalSpecifies a conditional expression that evaluates to true or false. The conditional expression must compare identical data types. v expression_if_trueSpecifies an expression that is evaluated if the condition is true. v expression_if_falseSpecifies an expression that is evaluated if the condition is false. The values returned by expression_if_true and expression_if_false must both be of the same data type.
Result data type

The type of data returned by the true (expression_if_true) and false (expression_if_false) expressions.
Examples
%IF(ID=1, "ID is 1", "ID is not 1") If the value in the ID column is equal to 1, this function returns the string "ID is 1". Otherwise, it returns the string "ID is not 1".
Column functions
269
%IF(DATSTR="010101", %TODATE(19010101, "*YYMD"), %IF(DATSTR="999999", NULL, %TODATE(DATSTR, "*YMD"))) If a value in the DATSTR column is "010101", this function returns 1901-01-01. If a value in DATSTR is "999999", it returns NULL. In all other cases, it returns equivalent dates to values in DATSTR. For example, for a value of "710723" in the DATSTR column, this example returns 71-07-23. Related reference Date conversion%TODATE on page 262 Variable%VAR
Variable%VAR
Use this function when you want InfoSphere CDC to evaluate a conditional expression and return different results during replication.
Syntax
%VAR(<variable_name>, [expression])
Parameters
v variable_nameSpecifies the name of the defined or retrieved variable. v expressionSpecifies a literal or a complex expression. This parameter is optional. If you specify it, the function creates a new variable, assigns the given value to it, and returns the value of the variable. If the variable already exists, the function assigns the new value to it. If you omit this parameter, the function retrieves the value of the variable, provided that the variable is defined (using the %VAR function) in a preceding column or previously in the current expression. You can pass a variable in the same row, from column to column, in ascending column sequence. However, you cannot pass a variable between rows.
Result data type

The type of data assigned to the variable (variable_name).
Examples
%VAR(SBTTL, PRICE*QTY) If the value in the PRICE column is 10 and the value in the QTY column is 5, then this function assigns the value 50 to the SBTTL variable, and returns the value 50. %VAR(SBTTL) If SBTTL is defined either in an expression for a preceding column or earlier in the current expression, this function returns the current value of the SBTTL variable. %IF(%VAR(QTY, QTYORD + QTYBACKORD) <100, %VAR(QTY) * PRICE, %VAR(QTY) * PRICE * (1- DISCOUNT)) Sets the QTY variable to QTYORD plus QTYBACKORD. If QTY is less than 100, then the result of the expression is QTY * PRICE. Otherwise, the result of the expression is QTY * PRICE * (1 - DISCOUNT).
270
Related reference Conditional%IF on page 269
Data functions
Use these functions when you want InfoSphere CDC to retrieve column values during replication. When you use these functions, InfoSphere CDC can return the value of a source column before applying an update, the value of a target column before applying an update, and the value of a column for a specific row in a table. See also: Before value%BEFORE Current value%CURR Retrieve column%GETCOL (DB2 for i) on page 273 Retrieve column%GETCOL (Dynamic SQL) on page 276 Retrieve column%SELECT on page 279
Before value%BEFORE
Use this function when you want InfoSphere CDC to retrieve the value of a source column before applying an update.
Syntax
%BEFORE(<parm>)
Parameters
parmSpecifies the name of a source column. You cannot specify a journal control field, an expression, or a column function as the input parameter.
Result data type

The data type of the source column (parm). When a row is inserted into the target table, including all rows that are inserted during a refresh, this function returns NULL. Otherwise, this function returns the appropriate default value for the data type of the target column.
Examples
%BEFORE(CRLIMIT) Returns the previous value in the CRLIMIT column, before it was updated on the source by the change being replicated. Related reference Current value%CURR
Current value%CURR
Use this function when you want InfoSphere CDC to retrieve the value of a target column before applying an update on a source column. By default %CURR will only access the target database to retrieve the current value when the source operation is an UPDATE. In general it provides no value if
Column functions
271
done for an INSERT or DELETE. If you are using %CURR for Adaptive Apply or with conflict resolution enabled, then you may want InfoSphere CDC to access the target database for all source operations. This behavior can be enabled by adding the enable_percent_curr_for_all_db_operations system parameter and then setting it to true. Note: InfoSphere CDC for z/OS does not support this function.
Syntax
%CURR(<parm>)
Parameters
parmSpecifies the name of a source column. You cannot specify a journal control field, an expression, or a column function as the input parameter.
Result data type

The data type of the target column (parm). When a row is inserted into the target table, including all rows that are inserted during a refresh, this function returns the appropriate default value for the data type of the target column. The %CURR function returns the value of the target column as single-byte characters, even if the source column contains multibyte data. Note: This function does not support the retrieval of large object columns such as BLOB, CLOB, and XML from the target database.
Examples
%CURR(BALANCE) Returns the current value of the target column BALANCE. In an expression, the current balance would be placed in the derived column before the update to BALANCE is applied to the target table. %CURR(BALANCE) - %BEFORE(BALANCE) Calculates the difference between the values in the source and target columns before an update is made. If the result is not equal to zero, the column values were not the same before the update was applied on the source and on the target. You can use this example only for numeric fields. (SRCCNT - %BEFORE(SRCCNT)) + %CURR(TGTTOT) You can use this example to maintain the total of two or more numeric column values that are contained in the same table on different datastores. In each source table, the SRCCNT column is mapped to the corresponding target column with the same name. The expression in this example is assigned to the derived column TGTTOL on the target. When a value in a SRCCNT column is updated, the difference between the new value and the previous value is calculated using the %BEFORE function. This difference is added to the current sum stored in the derived column TGTTOL. The result of the expression is assigned to the derived column.
272
%CURR(%TONUMBER(EMPNO)) InfoSphere CDC generates an error when verifying the expression, because %CURR does not accept another column function (in this example, %TONUMBER) as its parameter. Related reference Before value%BEFORE on page 271
Retrieve column%GETCOL (DB2 for i)

Use this function when you want InfoSphere CDC to retrieve the value of a column for a specific row in a table. You can also use this function, with a subset of parameters, so that InfoSphere CDC returns additional columns when it has previously invoked a %GETCOL function. You can use the %GETCOL function in expressions to perform the following operations: v Obtain columns from one or more keyed secondary tables and join them with an existing primary table before sending data to the target. The primary table refers to the source table being replicated. The secondary tables refer to tables referenced in the %GETCOL function. v Specify how keys of the secondary tables are populated, to allow InfoSphere CDCto perform the necessary secondary reads. v Use columns from secondary tables that were retrieved previously to populate keys for subsequent reads (the population of key column values is not restricted to primary columns only). v Specify the order that table reads are performed. v Condition the table reads that are performed. v Read tables external to InfoSphere CDC to perform dynamic translations on the target. Note: This topic contains information about the %GETCOL function supported by InfoSphere CDC for IBM i.
Long syntax formatreads from database

%GETCOL(<column_name>, <table_name>, [default_value], [record_format], [<key_count>, <key_value1>, <key_value2>, ..., <key_valuen>])
This function reads a table and returns the value of the column specified, based on the key column values that are identified. If more than one row satisfy the key requirements specified, then this function returns the first row only. If the read is unsuccessful, then this function returns the default value specified and sends a message to the appropriate message queue. The specified column in the table must exist when specifying the expression.
Short syntax formatreads from existing &GETCOL result

%GETCOL(<column_name>, <table_name>) %GETCOL(<column_name>, <table_name>, [default_value]) %GETCOL(<column_name>, <table_name>, [default_value]), [record_format])
This function returns the value of the specified column from a row retrieved by a previous %GETCOL function invocation. The short syntax lets you retrieve more than one column from a table (that was read previously using the %GETCOL function),
Column functions
273
without reading the table again. The previous %GETCOL function invocation must be for the same journal entry during continuous mirroring or the same row during refresh. The <table_name> and record_format parameters specified in the short format of the %GETCOL function invocation must match the <table_name> and record_format parameters specified in the long format of the %GETCOL function invocation.
Parameters
v column_nameSpecifies the name of a column. You cannot specify an expression for this parameter. v table_nameSpecifies the name of a table. This table must be keyed. You cannot specify an expression for this parameter. You can specify the table name using one of the following formats: The library, file, and member names are specified. For example, "LIBRARY/FILE(MEMBER)". The library and file are specified. InfoSphere CDC assumes a default value of *FIRST for the member name. For example, "LIBRARY/FILE". The file is specified. InfoSphere CDC assumes a default value of *LIBL for the library name and a default value of *FIRST for the member name. For example, "FILE". The file and member names are specified. InfoSphere CDC assumes a default value of *LIBL for the library name. For example, "FILE(MEMBER)". v default_valueSpecifies a default value to return if the read fails. This value must be a literal or constant, depending on the data type of the specified column. For character, date, time, and timestamp data types, you must enclose values of this parameter in double quotes. For example, "NO SALESREP" or "1995-05-10". If you specify NULL as the default value, then the column must be nullable. You cannot specify an expression for this parameter. If you omit this parameter, then you must enter a comma instead of the parameter value to indicate its position in the parameter list. If you omit this parameter, then this function returns a default value according to the data type of the column specified.
Field type Character Decimal (packed) Numeric (zoned) Real (4byte floating point) Float (8byte floating point) Date Default value Blank character Zero Zero Zero Zero 0001-01-01 (Date Zero). This applies to all date formats except *JUL (Julian). 1940-01-01 (Date Zero). This applies to the *JUL (Julian) date format. Time Integer (4 bytes) Small integer (2 bytes) Timestamp 00:00:00 (Time Zero) Zero Zero 0001-01-01 00:00:00 (Timestamp Zero)
274
v record_formatSpecifies the record format for the record to read. You cannot specify an expression for this parameter. Specify this parameter if more than one record format exist. If you omit this parameter, then you must enter a comma instead of the parameter value to indicate its position in the parameter list. If you omit this parameter, then InfoSphere CDC reads the first record format. v key_countIndicates the number of key values specified as parameters. It should be the number of key columns of the record format selected. It must be an integer greater than 0. You cannot specify an expression for this parameter. If you omit this parameter, then InfoSphere CDC assumes a default value of 1. v key_value1, key_value2, ...key_valuenSpecifies the key values to use when performing the read. These key values must match the key columns of the table to read. Character data passed as key parameters is padded with blank characters, or truncated if the length does not match the length of the key column. The key value can be either a primary table column (direct column mapping) or an expression. Some examples include: An expression performed on a primary table column that matches the definition of the key column in the table to read. A column from a previous read using the %GETCOL function. An expression performed on a column that was previously read using the %GETCOL function. You must specify these parameters if the key_count parameter is specified.
Result data type

The data type of the column retrieved (column_name). The %GETCOL function returns the value of the column as single-byte characters, even if the source column contains multibyte data.
Examples
The following examples are of scenarios where the %GETCOL function is used: %GETCOL (CUSTNAME, "PRODLIB/CUSTMAST") Retrieves the CUSTNAME column from a previous read of the CUSTMAST table in library PRODLIB, member *FIRST, and record format *FIRST. If the read is unsuccessful (for example, not found) and assuming that the data type for the CUSTNAME column is CHARACTER, then this function returns blanks characters. %GETCOL (CUSTNAME, "PRODLIB/CUSTMAST", "NO CUSTMAST") Retrieves the CUSTNAME column from a previous read of the CUSTMAST table in library PRODLIB, member *FIRST, and record format *FIRST. If the read is unsuccessful (for example, not found), then this function returns "NO CUSTMAST". %GETCOL (CUSTNAME, "PRODLIB/CUSTMAST",, "FMT2") Retrieves the CUSTNAME column from a previous read of the CUSTMAST table in library PRODLIB, member *FIRST, and record format "FMT2". The previous read must have "FMT2" specified for the record format.
Column functions
275
If the read is unsuccessful (for example, not found) and assuming that the data type for the CUSTNAME column is CHARACTER, then this function returns blank characters. Related concepts %GETCOL column function scenarios (DB2 for IBM i) on page 291 %GETCOL column function scenarios (Dynamic SQL) on page 293 Related reference Retrieve column%GETCOL (Dynamic SQL) Retrieve column%SELECT on page 279
Retrieve column%GETCOL (Dynamic SQL)

Note: This topic contains information about the %GETCOL function supported by any InfoSphere CDC product except for InfoSphere CDC for IBM i. Use this function to perform a secondary table column lookup based on the specified secondary columns. The %GETCOL function retrieves data from secondary table columns. To use this function before replication, you must add a derived column to the primary table and enter an expression for that column that uses the %GETCOL function. You can also use this function when entering an expression for a target column. To use this function, the secondary tables must have WHERE clause columns. The WHERE clause columns must be specified by name and you must provide a value expression for every WHERE clause column. Any column in the replicating table can be referenced by value expressions, and the captured column value is substituted in the expression. If the secondary columns have different data types, then you must convert them to appropriate data types using conversion column functions such as %TOCHAR. If you are using InfoSphere CDC for z/OS, then see %GETCOL and %SELECT Function Calls and Processing Efficiency in your InfoSphere CDC for z/OS documentation for information about performance considerations when using the %GETCOL or %SELECT column functions. This function gives you the option of specifying the encoding to be used for a column in a secondary table. You should only specify a value for ENCODING if you want to override or change the default encoding of the column as set in your database and detected by InfoSphere CDC. When retrieving data from a secondary table, InfoSphere CDC will use the following criteria (in the order specified) to determine the encoding for a column: 1. The ENCODING specification for a column in a secondary table that is explicitly identified in %GETCOL. 2. The ENCODING specification for a column in your subscription if the secondary table is specified in the subscription. This encoding value is specified on the Encoding tab in the Mapping Details view of Management Console 3. The default encoding of the column in your database.
Long syntax formatreads from database

%GETCOL(<secondary_column_name>, <table_name>, [default_value], <secondary_column_name1>, <key_value1>, [<secondary_column_name2> , <key_value2>, [...], <secondary_column_namen>, <key_valuen>])
276
This function reads a table and returns the value of the column specified, based on the secondary column names and values that are identified. If you specify a table or column name that contains spaces, then you must enclose that name in square brackets. For example, enter [EMP NY] to reference a table named "EMP NY".
Long syntax format with optional ENCODING specification

%GETCOL(<secondary_column_name> [ENCODING <encoding>], <table_name>, [default_value], <secondary_column_name1> [ENCODING <encoding1>], <key_value1>, [<secondary_column_name2> [ENCODING <encoding2>], <key_value2>, [...], <secondary_column_namen> [ENCODING <encodingn>], <key_valuen>])
Short syntax formatreads from existing &GETCOL result

%GETCOL(<secondary_column_name>, <table_name>, <default_value>)
This function returns the value of a the specified column from a row retrieved by a previous %GETCOL function invocation. The short syntax lets you retrieve more than one column from a table (that was read previously using the %GETCOL function), without reading the table again. You must use the long syntax format of this function to specify an encoding. The <table_name> parameter specified in the short format of the %GETCOL function invocation must match the <table_name> parameter specified in the long format of the %GETCOL function invocation. If the read is unsuccessful or a previous %GETCOL function invocation was not performed, then InfoSphere CDC generates an error message and sets the values of the derived column in which the %GETCOL function is used to default values, based on the data type of the derived column.
Parameters
v secondary_column_nameSpecifies the name of a column in a secondary table. You cannot specify an expression for this parameter. If the specified column does not exist in the secondary table, then InfoSphere CDC generates an error message when verifying the expression that contains the %GETCOL function. If you want to override or change the default encoding for a column as set by your database and detected by InfoSphere CDC, you have the option of using ENCODING <encoding> to specify the ISO/IANA name for the encoding of the column. ENCODING <encoding> is not supported for InfoSphere CDC for z/OS. This option is only supported when using the long syntax format. If you are using InfoSphere CDC for Informix, the values you specify here must be in lower case. v table_nameSpecifies the name of a table. Note the following when specifying this parameter: If you installed InfoSphere CDC for Oracle, you can specify the table name in the format '<OWNER_NAME>.<TABLE_NAME>', where the owner and table are in uppercase. If you omit the owner name, then InfoSphere CDC assumes that the owner is the user that installed InfoSphere CDC. If ownership of the table cannot be determined, then InfoSphere CDC assumes the default value of PUBLIC for the owner name. If you installed InfoSphere CDC for Microsoft SQL Server or InfoSphere CDC for Sybase, you must specify the table name in the format "<database_name>.<owner_name>.<table_name>". If you installed InfoSphere CDC for z/OS, you must specify the table name in the format "<owner_name>.<table_name>" or <owner_name>.<table_name>. If you installed InfoSphere CDC for DB2 LUW, you must specify the table name in the format "[owner_name].<table_name>" or '[owner_name].<table_name>'.
Column functions
277
v default_valueSpecifies a default value to return when no row can be found in the secondary table using the key value that matches the value of the referring (foreign) secondary column in the primary table row. If the corresponding row cannot be found in the secondary table, then the default value populates the derived column for the row sent to the target. If you specify NULL as the default value, then the column must be nullable. For certain InfoSphere CDC products, this is a required parameter. InfoSphere CDC generates an error if a default value is required, but is not specified in a %GETCOL function invocation. If you omit this parameter, then you must enter two consecutive commas (for the long syntax) or a comma (for the short syntax) prior to the right parenthesis to indicate its position in the parameter list. In this case, the %GETCOL function returns a default value according to the data type of the column specified. v secondary_column_name1, secondary_column_name2, ...secondary_column_namenIdentifies the secondary column name in the secondary table used to retrieve the secondary column specified by secondary_column_name. The DB2 UDB for z/OS API requires that the column specified in secondary_column_name is not nullable. InfoSphere CDC for z/OS generates an error message if it encounters a NULL key value when processing the %GETCOL function. To ensure that the %GETCOL function is invoked only for records with non-NULL key values, use the %IF function. If you are using InfoSphere CDC for Informix, the values you specify here must be in lower case. v key_value1, key_value2, ...key_valuenSpecifies an associated key value for each secondary column name. The key value can be any expression. If you specify a primary column name, then InfoSphere CDC uses the after image value of that column as the key_value for the secondary column in the secondary table to locate the corresponding row in the secondary table. You can specify multiple secondary column names and key value pairs. If you are using InfoSphere CDC for Informix, the values you specify here must be in lower case. Note: For InfoSphere CDC for z/OS, you can specify up to nine secondary_column_name/key_value pairs.
Result data type

The data type of the column retrieved (secondary_column_name). The %GETCOL function always returns data that matches the data type of the column. For character (String) data, it returns a UTF-8 string.
Examples
For examples and scenarios for the %GETCOL function, see the related topics below.
278
Related concepts %GETCOL column function scenarios (Dynamic SQL) on page 293 %GETCOL column function scenarios (DB2 for IBM i) on page 291 Configuring MBCS encoding conversion between your source and target on page 191 Related reference Character conversion%TOCHAR on page 259 Retrieve column%GETCOL (DB2 for i) on page 273 Conditional%IF on page 269
Retrieve column%SELECT
Use this function to specify a valid SQL SELECT statement that retrieves one or more column values from a secondary table so that they can be logically joined to a primary table record. For information about performance considerations when using the %GETCOL or %SELECT column functions, see the "%GETCOL and %SELECT Function Calls and Processing Efficiency" section in your InfoSphere CDC for z/OS documentation. You can specify only one SQL SELECT statement in each %SELECT function. To use this function, the z/OS user identifier that is used to start the InfoSphere CDC address space must have sufficient DB2 for z/OS privileges to perform SQL SELECT statements. Note: This function is only supported by InfoSphere CDC for z/OS. CAUTION: The use of SQL SELECT statements may constitute a security concern in your environment. Certain clauses and functions may have side effects that result in the changing of DB2 table data, the generation of data outside of the control of DB2 or both. Therefore, you should exercise caution when using the %SELECT function to issue SQL SELECT statements.
Syntax
%SELECT(<sql_select_stmt>, <parm>, <parm2>, ..., <parm>, [default_value], [default_value2], ...,[default_value])
Parameters
v sql_select_stmtSpecifies a character string containing a valid SQL SELECT statement. The statement must be valid according to DB2 for z/OS usage rules. For usage rules, see your DB2 for z/OS documentation. You must use parameter placeholders to refer to values that are not available until the expression is being executed. To identify parameter placeholders in the SQL SELECT WHERE clause, use question marks (?). In the SQL WHERE clause, you can use any operators that are supported by DB2 for z/OS, such as IN. For information about other operators that you can use, see your DB2 for z/OS documentation. v parm1, parm2, ..., parmnSpecify literals, column functions, expressions, expression variables, or primary table columns. In the WHERE clause, the value specified for parm1 replaces the first question mark, the value specified for
Column functions
279
parm2 replaces the second question mark in the WHERE clause, and so on. You cannot specify NULL for any parameter placeholder. default_value1, default_value2, ..., v default_valuemSpecify default values that the function returns for each column when the record specified by the WHERE clause does not exist in the secondary table. If you do not specify a default value for a column and the secondary table record does not exist, then this function returns an appropriate value, based on the data type of the column. For example, zero for numeric-based columns, zero-length strings for character-based columns, and so on. To specify a default value for a column that is not listed first in the SQL SELECT statement, you must specify default values for all preceding columns. Note the following when specifying parameters for this function: The number of parameters cannot exceed 21. You must specify a minimum of two parameters. If you only want to specify the SQL SELECT statement parameter, then you must also specify another parameter for the function. See examples below for situations where you must specify an unused parameter.
Result data type

The data type of the first secondary table column listed in the SQL SELECT statement. The result of the %SELECT function is a value from the first column specified in the SQL SELECT statement. If two or more column values are retrieved by the SQL SELECT statement, then these values are assigned to variables. By default, the variable names are the same as the corresponding column names. If these variable names cannot be defined, then the names are set to COLn, where n is the numeric position, starting at 1, of the corresponding column in the SQL SELECT statement. Using the %VAR function in expressions, you can retrieve the values assigned to variables and map them to subsequent columns in the primary table. Using a single %SELECT function to retrieve all secondary table column values and then using the %VAR function to map to subsequent columns is more efficient than invoking the %SELECT function multiple times to retrieve each column value individually. Note: If you have defined variables that have the same names as those created by InfoSphere CDC automatically, then the previously defined variables will be overwritten. Therefore, make sure existing variable names that you have defined do not conflict with variable names created by InfoSphere CDC.
Examples
The following examples use the relationship between primary and secondary tables:
280
%SELECT("SELECT COUNTRY FROM DB1.GSMITH.COUNTRY WHERE BRANCH = ?", EMPBRANCH) Assuming the primary and secondary tables shown above, you map the %SELECT function to the EMPCOUNTRY column in the EMPLOYEE table. For an employee in the EMPLOYEE primary table, this example returns their country from the COUNTRY secondary table record. If COUNTRY does not contain a record that satisfies the condition in the WHERE clause, then this function returns the default value for the data type of the COUNTRY column. For example, blank characters if the data type is character. %SELECT("SELECT Q1, Q2, Q3, Q4 FROM DB1.GSMITH.SALES WHERE EMP = ? AND ? = 4", EMPID, EMPBRANCH, 0, 0, 0, 0) Assuming the primary and secondary tables shown above, you map the %SELECT function to the EMPQ1 column in the EMPLOYEE table. For an employee in the EMPLOYEE primary table, who works at Branch 4, this example returns their first quarter sales figure from the SALES secondary table record. Since this example returns more than one column value, InfoSphere CDC defines three variables, named Q2, Q3, and Q4, to maintain the second, third, and fourth quarter sales figures, respectively. You can retrieve these values using the %VAR function and map them to the EMPQ2, EMPQ3, and EMPQ4 columns in EMPLOYEE. If SALES does not contain a record that satisfies the condition in the WHERE clause, then the function returns 0. In addition, InfoSphere CDC sets the three variables Q2, Q3, and Q4 to 0. %SELECT("SELECT INCOME, CODE, LASTADJDATE, NEXTADJDATE FROM DB1.GSMITH.SALARY WHERE EMP = ? AND BRANCH = ?", EMPID, EMPBRANCH, 0, "Z", 1970-01-01) Assuming the primary and secondary tables shown in the previous image, you map the %SELECT function to the EMPINCOME column in the EMPLOYEE table. For an employee in the EMPLOYEE primary table, this example returns their income from the SALARY secondary table record. Since this example returns more than one column value, InfoSphere CDC defines three variables, named CODE, LASTADJDATE, and NEXTADJDATE, to maintain
Column functions
281
the other items of salary information. You can retrieve these values using the %VAR function and map them to columns that you must add to the primary table. If SALARY does not contain a record that satisfies the condition in the WHERE clause, then: v The %SELECT function returns 0. v The CODE variable is set to "Z". v The LASTADJDATE variable is set to 1970-01-01. v The NEXTADJDATE variable is set to 1901-01-01 (the z/OS default date value). %SELECT("SELECT INCOME, LASTADJDATE, CODE, NEXTADJDATE FROM DB1.GSMITH.SALARY WHERE EMP = ? AND BRANCH = ?", EMPID, EMPBRANCH, 0, 1970-01-01) In this example, you must specify a default value for LASTADJDATE only.Since this column is listed third in the SQL SELECT statement, you must also specify default values for the INCOME and CODE columns. To eliminate the need to specify a default value for CODE, reference LASTADJDATE before CODE in the SQL SELECT statement. %SELECT("SELECT USED FROM DB1.GSMITH.VACATION WHERE EMP = ? AND EMPCOUNTRY IN (USA, UK, JAPAN, FRANCE)", EMPID, 0) Assuming the primary and secondary tables shown in the previous image, you map the %SELECT function to the EMPVACUSED column in the EMPLOYEE table. For an employee in the EMPLOYEE primary table located in United States, United Kingdom, Japan, or France, this example returns the amount of vacation used from the VACATION secondary table record. If VACATION does not contain a record that satisfies the condition in the WHERE clause, then the %SELECT function returns 0. %SELECT("SELECT NEXT VALUE FOR SEQ1 FROM SYSIBM.SYSDUMMY1", 1) This example returns the next value for sequence SEQ1. In this case, the data type of the result is the same as the data type of the sequence object. This example uses the %SELECT function to retrieve the next value for a sequence in DB2 for z/OS V8 or higher. SYSDUMMY1 is an existing DB2 dummy system table referenced in the SQL SELECT statement to satisfy syntax requirements. You must enter any integer value for the second parameter, in order to call the function. For example, 1. For information about sequences and the types of values that you can generate from sequences, see your DB2 for z/OS documentation. %SELECT("SELECT PREVIOUS VALUE FOR SEQ2 FROM SYSIBM.SYSDUMMY1", 24) This example returns the previous value for sequence SEQ2. In this case, the data type of the result is the same as the data type of the sequence object.
282
This example uses the %SELECT function to retrieve the previous value for a sequence in DB2 for z/OS V8 or higher. SYSDUMMY1 is an existing DB2 dummy system table referenced in the SQL SELECT statement to satisfy syntax requirements. You must enter any integer value for the second parameter, in order to call the function. For example, 24. For information about sequences and the types of values that you can generate from sequences, see your DB2 for z/OS documentation.
User exit functions

Use these functions to call user exit programs from expressions. Depending on the InfoSphere CDC platform you have installed, you can call a stored procedure or another type of user exit program using a column function. See also: Stored procedure%STPROC User exit%USER on page 284 User exit%USER (InfoSphere CDC for Microsoft SQL 5.x) on page 288 User Exit%USERFUNC on page 289
Stored procedure%STPROC
Use this function to call a stored procedure. You can call a stored procedure from a derived column on the source or create an expression on the target. Note: InfoSphere CDC for z/OS and InfoSphere CDC for DB2 UDB do not support this function. On the z/OS platform, use the %USER function to call a user exit program that issues SQL statements.
Syntax
%STPROC(stored_procedure_name, <parm1>, <parm2>, ..., <parm20>)
Parameters
v stored_procedure_nameSpecifies the name of the stored procedure in the default database. You must enclose values of this parameter in single quotes. If you installed InfoSphere CDC for Microsoft SQL Server, you must specify the name of the stored procedure in the format <databae_name>.<owner_name>.<stored_procedure_name>. The database and owner name are not required if the stored procedure is defined in the default database. v parm1, parm2, ..., parm20Specify columns or literals that are passed as parameters to the stored procedure (maximum 20). The type and order of the parameters specified in the %STPROC function invocation must match the type and order of the parameters defined in the stored procedure. If you installed InfoSphere CDC for Sybase, the first parameter defined in the stored procedure specifies the value returned by the function. Do not specify this parameter in the list of parameters for the %STPROC function (parm1, parm2, ..., parm20). You can omit any number of trailing parameters. InfoSphere CDC assumes the default value if a parameter is not specified. For example, for a stored procedure
Column functions
283
with five parameters, if you specify values for the first two parameters only, InfoSphere CDC assigns default values to the last three parameters.
Result data type

The data type of the result returned by the stored procedure.
Examples
The following example returns the customer name that corresponds to a specified customer identification number. Perform the following steps: 1. Define a stored procedure, as presented below, in the default database: v If you installed InfoSphere CDC for Microsoft SQL Server or InfoSphere CDC for Sybase: create procedure CUSTNAME @CUSTNAME varchar(30) OUT, @CUSTID int as select @CUSTNAME=name from customer where custno=@CUSTID v If you installed InfoSphere CDC for Oracle:
create or replace function custname (custid integer) return varchar2 as nameFound varchar2(30); begin select name1 into nameFound from customer where custno = custid; return nameFound; end custname;
2. Use the following column function:

%STPROC('CUSTNAME, CUSTOMER_ID)
This call returns the customer name that corresponds to the customer identification number CUSTOMER_ID. Related tasks To add a derived column on page 179 To map an expression to a target column on page 175 Related reference User exit%USER
User exit%USER
Use this function to call a user exit program from an expression. This function provides flexibility when complex logic that cannot be expressed using the provided column functions is required. You can use this function to call a user exit program with input parameters. For more information about user exit programs, see the appropriate InfoSphere CDC user exits guide. Note: InfoSphere CDC for Microsoft SQL Server does not support this function. If you are using an InfoSphere CDC product other than InfoSphere CDC for z/OS, you cannot use this function to call a stored procedure.
Syntax
%USER(<program_name>, <parm1>, <parm22>, ..., <parmn>
284
Parameters
v program_nameSpecifies the name of the user exit program. You must enclose values of this parameter in single quotes. You can write the user exit program in any high-level language. You must place an executable object for the user exit program in the InfoSphere CDC installation directory prior to starting refresh or mirroring. v parm1, parm2, ..., parmnSpecify columns or literals that are passed as parameters to the user exit program (maximum 20). In the user exit program that you write, you must declare a data structure that defines specific fields for the result and each input parameter (parm1, parm2, ..., parmn).
Field DATATYPE Length and data type Two-byte binary Description Specifies the data type of the result or input parameter: v 1Character v 2Date v 3Float v 4Integer v 5Packed numeric v 6Time v 7Zoned numeric LENGTH Two-byte integer Specifies the length of the result or input parameter in bytes. Specifies the number of digits in the result or input parameter. Specifies the number of decimal places in the result or input parameter. Specifies whether or not the result or input parameter is NULL: v 0Result or input parameter is not NULL. v 1Result or input parameter is NULL.
DIGITS
Two-byte binary
DECPLC
Two-byte binary
NULLIND
Two-byte binary
Column functions
285
Field DTMFMT
Length and data type Four-byte character
Description Specifies the date format in the result or input parameter: v *USAUnited States date format. v *ISOISO (International Organization for Standardization) date format. v *EUREuropean date format. v *JISJapanese Industrial Standard. v *YMDThe date format is yymmdd. v *MDYThe date format is mmddyy. v *DMYThe date format is ddmmyy.
<V ALUE>
Specifies one of the following: v For each input parameter, the field that contains the input parameter value passed to the user exit program. v For the user exit program result, the field that contains the result returned by the user exit program. The name of this field in the user exit program is user-defined. For example, see the COBOL user exit program below.
Result data type

The data type of the result returned by the user exit program.
Examples
%USER('USERSEL1, BRANCH) This function calls the COBOL program USERSEL1, passing the BRANCH column as a parameter. USERSEL1 checks whether or not BRANCH is set to '11'. If it is, then the user exit program returns a one-byte character value of Y. Otherwise, it returns a character value of N. Note: The following user exit program is provided for illustration purposes only and should be tested for all production environments.
286
IDENTIFICATION DIVISION. PROGRAM-ID. USERSEL1. AUTHOR. IBM CORP. INSTALLATION. DATAMIRROR CORP. DATE-COMPILED. ******************************************************************* * Program : USERSEL1. * ---------------* Version: 1.0 * ---------------* Description: SAMPLE COBOL USER ENTRY POINT PROGRAM * ---------------* ****************************************************************** ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. IBM-AS400. OBJECT-COMPUTER. IBM-AS400. ****************************************************************** * D A T A D I V I S I O N ****************************************************************** DATA DIVISION. ****************************************************************** * W O R K I N G S T O R A G E S E C T I O N ****************************************************************** WORKING-STORAGE SECTION. * 01 DATATYPES COMP-4. 03 TYP-CHAR PIC S9(4) VALUE 1. 03 TYP-DATE PIC S9(4) VALUE 2. 03 TYP-FLOAT PIC S9(4) VALUE 3. 03 TYP-INTEGER PIC S9(4) VALUE 4. 03 TYP-PACKED PIC S9(4) VALUE 5. 03 TYP-TIME PIC S9(4) VALUE 6. 03 TYP-ZONED PIC S9(4) VALUE 7. ****************************************************************** * L I N K A G E S E C T I O N ****************************************************************** LINKAGE SECTION. 01 RETURN-VALUE. 03 RV-DATATYPE PIC S9(4) COMP-4. 03 RV-LENGTH PIC S9(4) COMP-4. 03 RV-DIGITS PIC S9(4) COMP-4. 03 RV-DECPLC PIC S9(4) COMP-4. 03 RV-NULLIND PIC S9(4) COMP-4. 03 RV-DTMFMT PIC X(4). 03 RV-SELECT PIC X(1). 01 PARM-1. 03 P1-DATATYPE PIC S9(4) COMP-4. 03 P1-LENGTH PIC S9(4) COMP-4. 03 P1-DIGITS PIC S9(4) COMP-4. 03 P1-DECPLC PIC S9(4) COMP-4. 03 P1-NULLIND PIC S9(4) COMP-4. 03 P1-DTMFMT PIC X(4). 03 P1-BRANCH PIC X(2). ****************************************************************** * P R O C E D U R E D I V I S I O N ****************************************************************** PROCEDURE DIVISION USING RETURN-VALUE PARM-1. ML-0010. * * This example program checks parm 1 for a value of '11 and if found, * returns 'Y, else returns 'N. * * Define the Returned Value as a 1-byte character field. *
Column functions
287
MOVE TYP-CHAR TO RV-DATATYPE. MOVE 1 TO RV-LENGTH. MOVE ZERO TO RV-DIGITS. MOVE ZERO TO RV-DECPLC. MOVE ZERO TO RV-NULLIND. MOVE SPACES TO RV-DTMFMT. * * Test for a value of '11 in the first parameter. * IF P1-BRANCH IS EQUAL TO '11 MOVE 'Y TO RV-SELECT ELSE MOVE 'N TO RV-SELECT. EXIT PROGRAM.
Related reference Stored procedure%STPROC on page 283 User exit%USER (InfoSphere CDC for Microsoft SQL 5.x) User Exit%USERFUNC on page 289
User exit%USER (InfoSphere CDC for Microsoft SQL 5.x)

If you have installed InfoSphere CDC for Microsoft SQL Server, use this function to call a stored procedure on the source. This function allows you to specify Microsoft stored procedures as input parameters. To call stored procedures in expressions defined on the target, use the %STPROC function. For information about creating Microsoft SQL Server stored procedures, see InfoSphere CDC for Microsoft SQL Server User Exits Guide. Note: This function is only supported by InfoSphere CDC for Microsoft SQL Server on the source.
Syntax
%USER(<database_name>.<owner_name>.<stored_procedure_name>, <parm1>, <parm2>, ..., <parm20>
Parameters
v database_nameSpecifies the name of the database where the stored procedure resides. v owner_nameSpecifies the owner of the stored procedure. For example, dbo. v stored_procedure_nameSpecifies the name of the stored procedure. v parm1, parm2, ..., parm20Specify columns or literals that are passed as parameters to the stored procedure (maximum 20). The type and order of the parameters specified in the %USER call must match the type and order of the parameters defined in the stored procedure. The first parameter defined in the stored procedure must be the OUTPUT parameter followed by the input parameters. Do not specify this parameter in the %USER parameter list (parm1, parm2, ..., parm20). The number of parameters specified in the stored procedure must match the number of parameters specified in Management Console. You can omit any number of trailing parameters. InfoSphere CDC assumes the default value if a parameter is not specified. For example, for a stored procedure
288
with five parameters, if you specify values for the first two parameters only, InfoSphere CDC assigns default values to the last three parameters.
Result data type

Examples
%USER("ibm.dbo.sp_date_diff",COL_DATE) %USER("ibm.dbo.sp_date_diff","12jan-2000") The first call example specifies a source column name as input parameter (COL_DATE), while the second call example specifies a value as input parameter ("12-jan-2000"). These examples assume that a stored procedure, similar to the following, is defined in the database. The example stored procedure calculates the difference in days between the current date and a date specified as parameter:
CREATE PROCEDURE dbo.sp_date_diff @out_int int output, @in_date datetime AS select @out_int = DATEDIFF(day, @in_date, getdate()) GO %USER("ibm.dbo.sp_join",col_item_number) %USER("ibm.dbo.sp_join",12)
The first call example specifies a source column name as input parameter (col_item_number), while the second call example specifies a value as input parameter (12). These examples assume that a stored procedure, similar to the following, is defined in the database. The example stored procedure performs a join to a description table to get the description of an item given its item number:
CREATE PROCEDURE dbo.sp_join @out_item_description varchar(10) output @in_item_number int AS SELECT @out_item_description = inventory_db.dbo.description.item_desc FROM inventory_db.dbo.item_list INNER JOIN inventory_db.dbo.description ON inventory_db.dbo.item_list.item_number = inventory_db.dbo.description.item_number WHERE (inventory_db.dbo.description.item_number = @in_item_number) GO
Related reference Stored procedure%STPROC on page 283 User exit%USER on page 284 User Exit%USERFUNC
User Exit%USERFUNC
Use this function to call a Java class user exit program or a stored procedure from an expression. This function provides flexibility when complex logic that cannot be expressed using the provided column functions is required. You can use this function to call a user exit program with input parameters. This function also supports MBCS data. For more information about user exit programs, see your InfoSphere CDC user exits documentation.
Syntax
%USERFUNC(function_type, program_name, [<parm1>, <parm2>, ..., <parmn>]
Column functions
289
Parameters
v function_typeIndicate the type of user exit. Specify JAVA to call a Java class user exit program or STOREDPROC to call a stored procedure user exit program. You must enclose these values in double quotes to indicate they are strings, not column names. The Java class should be placed in your lib directory. If your Java class has a package name then you must create the appropriate directories under the lib directory. The stored procedure must exist in your database and you must specify the database owner or schema. v program_nameThe name of your Java class or stored procedure. Stored procedures must exist in your database you must specify the database owner or schema as well as the name of the stored procedure. v parm1, parm2, ..., parmnSpecify columns or literals that are passed as parameters to the Java class user exit or stored procedure user exit.
Result data type

Examples
%USERFUNC("JAVA", "USERSEL1", BRANCH) This function calls the Java user exit program of USERSEL1 and passes the BRANCH column as a parameter. USERSEL1 checks whether or not BRANCH is set to '11'. If it is, then the user exit program returns a one-byte character value of Y. Otherwise, it returns a character value of N. %USERFUNC("STOREDPROC","dbo.sp_date_diff",COL_DATE) %USERFUNC("STOREDPROC","dbo.sp_date_diff","12-jan-2000") The first call example specifies a source column name as input parameter (COL_DATE), while the second call example specifies a value as input parameter ("12-jan-2000"). These examples assume that a stored procedure, similar to the following, is defined in the database. The example stored procedure calculates the difference in days between the current date and a date specified as parameter. The stored procedure must exist in your database and you must specify the stored procedure name and database owner or schema:
CREATE PROCEDURE dbo.sp_date_diff @out_int int output, @in_date datetime AS select @out_int = DATEDIFF(day, @in_date, getdate()) GO
%USERFUNC("STOREDPROC","dbo.sp_join",col_item_number) %USERFUNC("STOREDPROC","dbo.sp_join",12) The first call example specifies a source column name as input parameter (col_item_number), while the second call example specifies a value as input parameter (12). These examples assume that a stored procedure, similar to the following, is defined in the database. The example stored procedure performs a join to a description table to get the description of an item given its item number.
290
The stored procedure must exist in your database and you must specify the stored procedure name and database owner or schema.
CREATE PROCEDURE dbo.sp_join @out_item_description varchar(10) output @in_item_number int AS SELECT @out_item_description = inventory_db.dbo.description.item_desc FROM inventory_db.dbo.item_list INNER JOIN inventory_db.dbo.description ON inventory_db.dbo.item_list.item_number = inventory_db.dbo.description.item_number WHERE (inventory_db.dbo.description.item_number = @in_item_number) GO
Related concepts Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187 Related reference Stored procedure%STPROC on page 283 User exit%USER on page 284 User exit%USER (InfoSphere CDC for Microsoft SQL 5.x) on page 288
%GETCOL column function scenarios (DB2 for IBM i)

The %GETCOL column function scenarios in this section are specific to InfoSphere CDC for IBM i. If you are using a different InfoSphere CDC product, %GETCOL column function scenarios (Dynamic SQL) on page 293. See also: Retrieving a column from another table using the %GETCOL function (DB2 for i) Performing an outer join using the %GETCOL function (DB2 for i) on page 292 Nesting columns to join data using the %GETCOL function (DB2 for i) on page 292 Combining columns using the %GETCOL function (DB2 for i) on page 292
Retrieving a column from another table using the %GETCOL function (DB2 for i)
This example uses the relationship between a primary (EMPLOYEE) and secondary (BRANCH, STATE, and COUNTRY) tables.
In this example, you will retrieve the column NAME from the STATE table using the STATE column from the EMPLOYEE table. To use this example, perform the following steps: 1. Add a derived column, STNAME, based on the NAME column, to the STATE table. 2. Enter the following expression for the STNAME derived column:
Column functions
291
%GETCOL(NAME, "PRODLIB/STATE", , , 1, STATE)
Performing an outer join using the %GETCOL function (DB2 for i)

This example uses the relationship between primary and secondary tables. In this example, you will retrieve the column NAME from the COUNTRY table using the COUNTRY column from the STATE table. The COUNTRY column, used to read the COUNTRY table, is not from the primary table. To use this example, perform the following steps: 1. Add a derived column, CTNAME, based on the NAME column, to the COUNTRY table. 2. Enter the following expression for the CTNAME column: %GETCOL(NAME, "PRODLIB/COUNTRY", , , 1, %GETCOL(COUNTRY, "PRODLIB/STATE")) The second %GETCOL function retrieves the COUNTRY column from the STATE table. This column was retrieved in a previous %GETCOL invocation. In the first %GETCOL function, the default_value and record_format parameters are not specified, as they are specified in the long version of the %GETCOL function that performed the read.
Nesting columns to join data using the %GETCOL function (DB2 for i)
This example uses the relationship between primary and secondary tables. In this example, you will consolidate data from secondary tables without replicating the secondary tables. To use this example, perform the following steps: 1. Add a derived column, CTNAME, based on the NAME column, to the COUNTRY table. 2. Enter the following expression for the CTNAME column: %GETCOL(NAME, "PRODLIB/COUNTRY", , , 1, %GETCOL(COUNTRY, "PRODLIB/STATE", , , 1, STATE)) This function retrieves the NAME column from the COUNTRY table using the STATE column from the EMPLOYEE table and the COUNTRY column from the STATE table.
Combining columns using the %GETCOL function (DB2 for i)

This example uses the relationship between primary and secondary tables. In this example, you will combine the STATE and COUNTRY columns from the STATE table using the %CONCAT function. To use this example, perform the following steps: 1. Add a derived column, REGION, based on the STATE and COUNTRY columns in the STATE table. 2. Enter the following expression for the REGION column: %CONCAT(%GETCOL(STATE, "PRODLIB/STATE", "FAILED", , 1, STATE), "-", %GETCOL(COUNTRY, "PRODLIB/STATE", "FAILED")) The second %GETCOL function retrieves the COUNTRY column from the STATE table. This column was retrieved in a previous %GETCOL function invocation.
292
Related reference Concatenation%CONCAT on page 246
%GETCOL column function scenarios (Dynamic SQL)

The %GETCOL column function scenarios in this section apply to any InfoSphere CDC product except InfoSphere CDC for IBM i. For InfoSphere CDC for z/OS, you can also refer to Retrieve column%SELECT on page 279. See also: Retrieving a column using the %GETCOL function (Dynamic SQL) Retrieving a column using the %GETCOL function without reading the same row from the table Retrieving a column using nested %GETCOL functions (Dynamic SQL) on page 294 Filtering rows using the %GETCOL function (Dynamic SQL) on page 295
Retrieving a column using the %GETCOL function (Dynamic SQL)

This example refers to the primary (EMPLOYEE) and secondary (BRANCH, STATE, and COUNTRY) table relationship. The table names referenced in the examples follow the format forInfoSphere CDC for Microsoft SQL Server and InfoSphere CDC for Sybase databases. If you installed another InfoSphere CDC product, see the <table_name> parameter in this function for more information about specifying table names which depends on your database.
To use the example, you must add a derived column to the MASTER.DBO.EMPLOYEE primary table and enter the specified %GETCOL function in that column. %GETCOL(NAMEB, "MASTER.DBO.BRANCH", "<NO NAME>", BRANCHB, BRANCH) This example retrieves the NAMEB column from the MASTER.DBO.BRANCH secondary table, using the value in the BRANCH column in the primary table and the key column BRANCHB in the secondary table. If a record in the primary table has a branch number that does not exist in the MASTER.DBO.BRANCH table, then this function returns "" for that record in the retrieved column.
Retrieving a column using the %GETCOL function without reading the same row from the table
This example refers to the primary and secondary tables. The table names referenced in the examples follow the format for InfoSphere CDC for Microsoft SQL Server and InfoSphere CDC for Sybase databases. If you installed another
Column functions
293
InfoSphere CDC product, see the <table_name> parameter in this function for more information about specifying table names which depends on your database. To use the example, you must add a derived column to the MASTER.DBO.EMPLOYEE primary table and enter the specified %GETCOL function in that column. %GETCOL(NAMES, "MASTER.DBO.STATE", , STATES, STATE) This function call retrieves the NAMES column from the MASTER.DBO.STATE secondary table, using the key column STATE in the primary table and the key column STATES in the secondary table. If a record in the primary table has a state that does not exist in MASTER.DBO.STATE, then this function returns the default value for the data type of the NAMES column. For example, blank characters if the data type is character. %GETCOL(COUNTRYS, "MASTER.DBO.STATE", "") Used after the previous %GETCOL function, this function call retrieves the COUNTRYS column from the MASTER.DBO.STATE secondary table, without reading again the same row from the table. If a record in the primary table has a state that does not exist in MASTER.DBO.STATE, then this function returns the default value for the data type of the COUNTRYS column. For example, blank characters if the data type is character.
Retrieving a column using nested %GETCOL functions (Dynamic SQL)

This example refers to the primary and secondary table relationship. The table names referenced in the examples follow the format for InfoSphere CDC for Microsoft SQL Server and InfoSphere CDC for Sybase databases. If you installed another InfoSphere CDC product, see the <table_name> parameter for information about specifying table names for this function, depending on your database. To use the example, you must add a derived column to the MASTER.DBO.EMPLOYEE primary table and enter the specified %GETCOL function in that column. %GETCOL(NAMES, "MASTER.DBO.STATE", , STATES, STATE) This function call retrieves the NAMES column from the MASTER.DBO.STATE secondary table, using the key column STATE in the primary table and the key column STATES in the secondary table. If a record in the primary table has a state that does not exist in MASTER.DBO.STATE, then this function returns the default value for the data type of the NAMES column. For example, blank characters if the data type is character. %GETCOL(NAMEC, "MASTER.DBO.COUNTRY", , COUNTRYC, %GETCOL(COUNTRYS, "MASTER.DBO.STATE", "")) Used after the previous %GETCOL function, the second %GETCOL function in this example is called first to retrieve the COUNTRYS column from the MASTER.DBO.STATE table. Then, the first %GETCOL function is called to retrieve the NAMEC column from the MASTER.DBO.COUNTRY table using the key column COUNTRYS in MASTER.DBO.STATE and the key column COUNTRYC in MASTER.DBO.COUNTRY.
294
In this example you do not retrieve the NAMEC column in the MASTER.DBO.COUNTRY table directly, using the COUNTRYC key column, because the primary table does not contain a key column to retrieve NAMEC. Instead, you retrieve the NAMEC column indirectly using the COUNTRYS key column in MASTER.DBO.STATE and the COUNTRYC key column in MASTER.DBO.COUNTRY.
Filtering rows using the %GETCOL function (Dynamic SQL)

This example refers to the primary and secondary table relationship. The table names referenced in the examples follow the format for InfoSphere CDC for Microsoft SQL Server and InfoSphere CDC for Sybase databases. If you installed another InfoSphere CDC product, see the <table_name> parameter in this function for more information about specifying table names which depends on your database. To use the example, you must add a derived column to the MASTER.DBO.EMPLOYEE primary table and enter the specified %GETCOL function in that column. %GETCOL(COUNTRYS, "MASTER.DBO.STATE", , STATES, STATE) = 'USA' This example uses the %GETCOL function in a row-filtering expression. The function retrieves values of the COUNTRYS column from the MASTER.DBO.STATE table and compares them with 'USA'. Depending on your row filtering settings on the Filtering tab, rows in the MASTER.DBO.EMPLOYEE primary table, with a COUNTRYS value set to USA, are either selected or omitted for replication.
Publishing multiple derived columns using the %GETCOL function (Dynamic SQL)
This example refers to the primary and secondary table relationship. The table names referenced in the examples follow the format for InfoSphere CDC for Microsoft SQL Server and InfoSphere CDC for Sybase databases. If you installed another InfoSphere CDC product, see the <table_name>parameter for information about specifying table names for this function, depending on your database.
This example combines the CUSTID and CUSTADDR tables into a single CUSTOMER table with all five columns. By calling the %GETCOL function twice, you retrieve values of two columns from the same row in the secondary table. The first call reads the entire row into memory and the second call retrieves data from the same row in memory, without reading the same table twice.
To use this example, perform the following steps: 1. Add a derived column, ADDR1, to the CUSTID source table and enter the following expression for the column: %GETCOL(ADDRESS1, "MASTER.DBO.CUSTADDR", "Not Found", CUSTNO, CUSTNO)
Column functions
295
2. Add a derived column, ADDR2, to the CUSTID source table and enter the following expression for the column: %GETCOL(ADDRESS2, "MASTER.DBO.CUSTADDR", "Not Found") The expression for ADDR1 queries the CUSTADDR table and returns the value in the ADDRESS1 column where the two CUSTNO values match. The expression for ADDR2 uses the results returned by the previous %GETCOL function invocation without reading the CUSTADDR table. Instead, it uses matching rows from the ADDR2 definition to know when to return the value from the ADDRESS2 column. If either %GETCOL function cannot find a matching row, then it returns a value of "Not Found".
Related concepts Filtering rows and columns on page 315
XPath functions
The XPath functions implemented by InfoSphere CDC Event Server follow specific syntax. For details regarding the XPath functions, see W3C's Web site at http://www.w3.org. In the current release the following XPath functions are implemented: See also: ceiling on page 297 concat on page 297 contains on page 297 floor on page 297 false on page 298 formatNumber on page 298 normalizeSpace on page 298 not on page 298 number on page 299 position on page 299 round on page 299 startsWith on page 299 string on page 300 stringLength on page 300 substring on page 300 substringAfter on page 300 substringBefore on page 301 sum on page 301 translate on page 301 true on page 302
296
ceiling
Returns the smallest integer greater than or equal to the numeric value of the argument. Syntaxceiling(value) Input Parameters(value) represents an input value that can be converted to a number. Example<sxt:element name="Price" value="ceiling(12.5)"/>. This function returns a value of 13.
concat
Concatenates two or more values into one string. Syntaxconcat(value1, value2, [, value3, ...]) Input Parametersvalue1, value2, [, value3, ...] represent input values: expressions, literals, or functions. Return ValueString Example<sxt:element name="Full_Name" value="concat(First_Name, ` `, Last_Name)"/>
contains
Determines whether a string is contained within another string. The function returns true if value 1 contains value 2, otherwise, false. Syntaxcontains(value1, value2) Input Parametersvalue1, value2 represent input values: expressions, literals, or functions. Return ValueBoolean Example<sxt:element name="isQualified" value="contains(/employee/ skill,"Java")"/>
floor
Returns the largest integer that is less than or equal to the numeric value of the argument. Syntaxfloor(value) Input Parametersvalue represents an input value that can be converted to a number. Return ValueNumber
Column functions
297
Example<sxt:element name="Price" value="floor(12.5)"/>. This function returns a value of 12.
false
Returns false. Syntaxfalse( ) Input ParametersNone Return ValuebBoolean Example<sxt:element name="OnSale" value="false()"/>
formatNumber
Formats a numeric value according to a specified pattern. The default pattern implemented follows Java JDK Version 1.1 specification. For more information on number formats, see the Java API documentation. Syntaxformat-number(value, format-pattern) Input Parameters v value represents an input value that can be converted to a number. v format-pattern represents a string value that contains the formatting rules. Return ValueString Example<sxt:element name="Price" value="format-number(12.5, $#.00)"/>. The preceding declaration formats "12.5" to "$12.50" and assigns it as the contents of the Price element.
normalizeSpace
Trims the leading and trailing white spaces (blank spaces, tabs and new line characters), and converts multiple white spaces to a single blank space. Syntaxnormalize-space(value) Input Parametersvalue represents an input string value. Return ValueString Example<sxt:element name="Test" value="normalize-space (` Hello world! )"/>
not
Returns true if the argument is false, returns false if the argument is true. Syntaxnot(value) Input Parametersvalue represents an input boolean value or expression.
298
Return ValueBoolean Example<sxt:element name="Admit" value="not(/Customers/Customer/ age<18)"/>
number
This function converts a value to a decimal number. Syntaxnumber(value) Input Parametersvalue represents an input string of numeric values. Return ValueNumber Example<sxt:element name="Cost" value="number(15.6)"/>
position
Returns a number equal to the context position from the expression evaluation context. Syntaxposition( ) Input ParametersNone Return ValueNumber Example<sxt:element name="ColumnNum" value="/root/a[position()=3]"/>
round
Returns the closest integer to the numeric value of the argument. Syntaxround(value) Input Parametersvalue represents an input number, which must be surrounded by single quotes. Return ValueNumber Example<sxt:element name="Cost" value="round(15.6)"/>. For this example, the return value is 16.
startsWith
Returns true if one string begins with another. Syntaxstarts-with(value1, value 2) Input Parameters v value1 represents an input value: an expression, a literal, or a function. v value2 represents the substring to be searched.
Column functions
299
Return ValueBoolean Example<sxt:element name="isLocal" value="starts-with(Phone, "416")"/>
string
Converts a number or node to a string. Syntaxstring(value) Input Parametersvalue represents an input number. Return ValueString Example<sxt:element name="Cost" value="string(15.6)"/>
stringLength
This function returns the length of a string. Syntaxstring-length(value) Input Parametersvalue represents an input value: an expression, a literal, or a function. Return ValueNumber Example<sxt:element name="TestLength" value="string-length(Phone)"/>
substring
This function extracts a substring from a string starting at, and ending with, a specified position. Syntaxsubstring(value, beginIndex, [length]) Input Parameters v value represents an input value: an expression, a literal, or a function. v beginIndex represents the beginning position, zero-based. v length represents the end position, zero based. If omitted, the substring runs to the end of the input string. Return ValueString Example<sxt:element name="Area_Code" value="substring(Phone, 0, 3)"/>
substringAfter
Extracts a substring from a string. The substring to be extracted appears after the first occurrence of a specified substring. Syntaxsubstring-after(value, searchSubstring) Input Parameters
300
v value represents an input value: an expression, literal, or a function. v searchSubstring represents the substring to be searched. Return ValueString Example<sxt:element name="LocalNumber" value="substring-after (Phone, ` `)"/>
substringBefore
Syntaxsubstring-before(value, searchSubstring) DescriptionExtracts a substring from a string. The substring to be extracted appears before the first occurrence of a specified substring. Input Parameters v value represents an input value: an expression, a literal, or a function. v searchSubstring represents the substring to be searched. Return ValueString Example<sxt:element name="AreaCode" value="substring-before(Phone, ` `)"/>
sum
Syntaxsum(node_set) DescriptionReturns the total value of a set of numeric values in a node-set. Input Parametersnode_set is an X-Path expression that represents a node-set. Return ValueNumber Example<sxt:element name="TotalPrice" value="sum(//UnitPrice)"/>
translate
Syntaxtranslate(value, from, to) DescriptionSubstitutes characters in a supplied string with specified replacement characters. Input Parameters v value represents an input value: an expression, a literal, or a function. v from represents the characters to be replaced. v to represents the characters to be used as the replacement for the from characters. If omitted, the from characters are removed. Return ValueString Example<sxt:element name="Phone" value="substring(Phone, ` `, `-`)"/>
Column functions
301
true
Syntaxtrue( ) DescriptionReturns true. Input ParametersNone Return ValueBoolean Example<sxt:element name="OnSale" value="true()"/> Nesting is supported in the current version.
Transform extensions
To meet specific transform requirements, these extensions have been developed to supplement XPath and XSLT recommendations provided by W3C. The first extension is an XPath expression for self-reference. A leading # symbol means self-reference from the target point of view. For example, /root/level1/@attr1 points to an attribute in the source DOM, while #/root/level1/@attr1 points to an attribute in the target that is the XML document to be generated. InfoSphere CDC Event Server functions are marked with the sxt: prefix, which must be used with the function name. See also: sxt:add on page 303 sxt:db-lookup on page 303 sxt:divide on page 303 sxt:filter on page 304 sxt:formatDate on page 304 sxt:getSequentialNum on page 305 sxt:getSubField on page 305 sxt:getSysDateTime on page 305 sxt:getSysDate on page 306 sxt:getSysTime on page 306 sxt:groupConcat on page 306 sxt:ifExist on page 306 sxt:ifReturn on page 307 sxt:isEqual on page 307 sxt:multiply on page 307 sxt:nodeConcat on page 307 sxt:padLeft on page 308 sxt:padRight on page 308 sxt:proper on page 308 sxt:setDefault on page 309 sxt:subtract on page 309 sxt:toLowerCase on page 309 sxt:toUpperCase on page 310 sxt:trim on page 310
302
sxt:add
Syntaxsxt:add (value1, value2, [value3,...]) DescriptionThis function adds two or more values provided. Input Parametersvalue1, value2, [value3, ...] represent two or more values that can be converted to numbers. Return ValueNumber Example<sxt:element name="Total_Quantity" value="sxt:add(QOH, QOO)"/>
sxt:db-lookup
Syntaxsxt:db-lookup (JDBCDriver, URL,UserName, Password, SQLStatement |StoredProcedure[,param1,param2,...]) DescriptionThis function gets a single value from the specified database by performing a query. Do not use this function on tables that are being transformed. Use sxtdb:lookup for tables under current transformation Input Parameters v JDBCDriverRepresents the name of a valid JDBC driver class. v URLRepresents a unique URL to the database. v UserNameRepresents a valid user name to access the database. v PasswordRepresents a valid password associated with the user name. v SQLStatementRepresents the SQL statement to be applied to the database. Only standard SQL types are supported. v StoredProcedure[,param1,param2,...] Represents the stored procedure. The syntax is: (outputParameter Datatype) call ProcedureName ([inputParameter Datatype, ...]) outputParameterThe stored procedure can have only one output parameter, and the output parameter must be the last parameter. The supported data types are: CHAR, VARCHAR, LONGVARCHAR, INTEGER, DOUBLE, DATE, TIME, TIMESTAMP inputParameterRepresents the value of the input parameter (optional). stringThis function will return the first column in the first row of the result set
sxt:db-lookup("sun.jdbc.odbc.JdbcOdbcDriver","jdbc:odbc:pubs", "sa","sa","SELECT country_name FROM countries WHERE country_id=?", @countryID)
sxt:divide
Syntaxsxt:divide (value1, value2) DescriptionThis function divides two values provided. Input Parametersvalue1, value2 represent two values that can be converted to numbers. value2 cannot be zero. Return ValueNumber
Column functions
303
Example<sxt:element name="Overtime_Rate" value="sxt:divide(overtime, standard)"/>
sxt:filter
Syntaxsxt:filter (node-set, condition) DescriptionThis function filters the node-set using a conditional expression in the context of each of the node-sets. This is equivalent to the XPath "[ ]" filtering mechanism. Input Parameters v node-set represents the node-set to be selectively returned if a node meets the condition. v condition represents a filter condition that can be evaluated (true or false). Return ValueNode-set Example<sxt:attribute name="keys" value="sxt:groupConcat(sxt:filter(data_key, sxt:is-equal(data_type,2)), )"/>
sxt:formatDate
Syntaxsxt:formatDate (value, original-format-pattern, to-format-pattern) DescriptionThis function formats the date string using the specified pattern. The patterns must follow the rules in Java. For more information on date formats, see the Java API documentation. Input Parameters v value represents an input value that can be converted to a date. v original-format-pattern represents a string value that contains the original formatting rules. v to-format-pattern represents a string value that contains the formatting rules for the converted date. The patterns must follow the rules in Java. yyyy-MM-dd (for example, 2001-01-25) MMM dd, yyyy (for example, Jan 25, 2004) MMMM d, yyyy (for example, January 25, 2004) M/dd/yyyy (for example 1/25/2004) yyyy-MM-dd HH:mm:ss (for example, 2004-01-25 13:25:30) yyyy-MM-dd hh:mm:ss a (for example, 2004-01-25 01:25:30 PM). Return ValueString Example<sxt:element name="Birthday" value="sxt:formatDate(@dob, yyyy-MMdd, MMM dd, yyyy)"/>
304
sxt:getSequentialNum
Syntaxsxt:getSequentialNum (seed, increment) Description This function generates sequential numbers in a session. Input Parameters v seed represents the start value of a counter. v increment represents the increment for each number. Return ValueNumber Example<sxt:element name="ID" value="sxt:getSequentialNum(1,1)"/>. In this example, when the function is called for the first time, the return value is 1; the second time, the return value is 2, the third time, 3, and so on. The counter does not persist between sessions or processes.
sxt:getSubField
Syntaxsxt:getSubField (value, delimiter, subFieldIndex) DescriptionThis function extracts a sub-field value from a string that contains a list of delimited values. Input Parameters v value represents an input value: an expression, a literal, or a function. v delimiter represents a delimiter used to separate the sub-field values. For example: comma, tab, |, and so on. v subFieldIndex represents the ordinal position of the sub-field. For example, the first sub-field is 1, and so on. Return ValueString Example<sxt:element name="Area_Code" value="sxt:getSubField(Phone, `-`, 1)"/>
sxt:getSysDateTime
SyntaxgetSysDateTime ( ) DescriptionThis function returns the system date and system time at runtime. Input ParametersNone Return ValueString Example<sxt:element name="UpdateTimestamp" value="sxt:getSysDateTime()"/>
Column functions
305
sxt:getSysDate
SyntaxgetSysDate ( ) DescriptionThis function returns the system date at runtime. Input ParametersNone Return ValueString Example<sxt:element name="UpdateDate" value="sxt:getSysDate()"/>
sxt:getSysTime
Syntaxsxt:getSysTime ( ) DescriptionThis function returns the system time at runtime. Input ParametersNone Return ValueString Example<sxt:element name="UpdateTime" value="sxt:getSysTime()"/>
sxt:groupConcat
Syntaxsxt:groupConcat (nodeToConcat, delimiter) DescriptionThis function converts one level node in a node-set to a string and then concatenates them together into a string Input Parameters v nodeToConcat represents the node to be concatenated. It must be a node-set. v delimiter represents the delimiter to be used for separating each sub-value. Return ValueString Example<sxt:element name="AuthorPhones" value="sxt:groupConcat(/authors/ phone, ,)"/>
sxt:ifExist
Syntaxsxt:if-exist (nodeOrExpr1, node OrExpr2) DescriptionThis function verifies whether or not the first value is empty. If it is empty, it returns the second value. Otherwise, it returns the first value. Input Parameters v nodeOrExpr1 represents the first node or expression. v nodeOrExpr2 represents the second node or expression. Return ValueString
306
Example<sxt:element name="Phone" value="sxt:if-exist(@WorkPhone, @HomePhone)"/>
sxt:ifReturn
Syntaxsxt:if-return (testCondition, valueForTrue, valueForFalse) DescriptionThis function evaluates a condition and, depending on the evaluation result, returns a specified value. Input Parameters v testCondition represents an expression that can be evaluated to true or false. v valueForTrue represents the value to be returned when the condition is true. v valueForFalse represents the value to be returned when the condition is false. Return ValueString Example<sxt:element name="Language" value="sxt:if-return(sxt:isequal(@lang,`fr), `French, `English)"/>
sxt:isEqual
Syntaxsxt:is-equal (nodeOrExpr, valueToTestAgainst) DescriptionThis function tests if a node or expression has a specific value. Input Parameters v nodeOrExpr represents a node/expression whose value is compared with the specified value. v valueToTestAgainst represents a specific value for testing the node or the expression. Return ValueBoolean Example<sxt:element name="no_name" value="sxt:is-equal(@name, ")"/>
sxt:multiply
Syntaxsxt:multiply (value1, value2, [value3, ...]) DescriptionThis function multiplies two or more values provided. Input Parametersvalue1, value2, [value3, ...] represent two or more values that can be converted to numbers. Return ValueNumber Example<sxt:element name="Cost" value="sxt:multiply(Quantity, Price)"/>
sxt:nodeConcat
Syntaxsxt:nodeConcat (flag, nodeToConcat, delimiter)
Column functions
307
DescriptionThis function converts each node in a node-set to a string and then concatenates them together into a string. Input Parameters v flag represents an expression that can be evaluated to true or false. v nodeToConcat represents the node to be concatenated. It must be a node-set. v delimiter represents the delimiter to be used for separating each sub-value. Return ValueString Example<sxt:element name="AuthorPhones" value="sxt:nodeConcat(,/ authors/phone, ,)"/>
sxt:padLeft
Syntaxsxt:pad-left (string_to_pad, value, string_to_fill) DescriptionThis function adds a number of characters to the left of a string. If the length of the string to return is less than the value specified, the return string is truncated. Input Parameters v string_to_pad specifies the string to be modified by adding characters to the left. v value specifies the length of the string to be returned. v string_to_fill specifies the string that contains the characters to fill. Return ValueString Example<sxt:element name="Leading_Zeros_Number" value="sxt:padleft(number,8, 0)"/>
sxt:padRight
Syntaxsxt:pad-right (string_to_pad, value, string_to_fill) DescriptionThis function adds a number of characters to the right of a string. If the length of the string to return is less than the value specified, the return string is truncated. Input Parameters v string_to_pad specifies the string to be modified by adding characters to the right. v value specifies the length of the string to be returned. v string_to_fill specifies the string that contains the characters to fill. Return ValueString Example<sxt:element name="Trailing_Space" value="sxt:pad-right(fname, 10, )"/>
sxt:proper
Syntaxsxt:proper (string)
308
DescriptionThis function performs a capitalization of all the words provided as input. The first letter of a word is converted to uppercase, while the other ones to lowercase. Input Parametersstring Specifies a string that contains a number of words. Return ValueString Example<sxt:element name="FullName" value="sxt:proper(full_name)"/>
sxt:setDefault
Syntaxsxt:setDefault (nodeOrExpr, defaultValue) DescriptionThis function returns a default value if a specified node/expression is evaluated to an empty string. Input Parameters v nodeOrExpr represents a node/expression to be tested. v defaultValue represents the value to be returned when the node/expression contains an empty string. Return ValueString Example<sxt:element name="Language" value="sxt:setDefault(@lang,English)"/>
sxt:subtract
Syntaxsxt:subtract (value1, value2, [value3, ...]) DescriptionThis function subtracts one or more values from the first value specified. Input Parametersvalue1, value2, [value3, ...] represent two or more values that can be converted to numbers. Return ValueNumber Example<sxt:element name="Stored_Quantity" value="sxt:subtract(100, 20, 30)"/>. In this example, the return value is 50.
sxt:toLowerCase
Syntaxsxt:toLowerCase (value) DescriptionThis function converts a string to lower case. Input Parametersvalue represents the value to convert to lower case. Return ValueString Example<sxt:element name="FirstName" value="sxt:toLowerCase(first_name) "/>
Column functions
309
sxt:toUpperCase
Syntaxsxt:toUpperCase (value) DescriptionThis function converts a string to upper case. Input Parametersvalue represents the value to convert to upper case. Return ValueString Example<sxt:element name="LastName" value="sxt:toUpperCase(last_name)"/>
sxt:trim
Syntaxsxt:trim (value) DescriptionThis function strips off the leading and trailing blank spaces of a string. Input Parametersvalue represents the string value to be trimmed. Return ValueString Example<sxt:element name="FirstName" value="sxt:trim(first_name)"/>
Using external Java objects in data transformations

You can extend your data transformations using external Java objects. Some of the things you can do include but are not limited to the following: v Implement your own custom data validation v Translate values using look-up tables v Perform complex calculations It is very easy to use your Java classes in your mapping project. The methods must be public but need not be static. Make sure that any external Java classes you want to use can be found in the CLASSPATH environment variable. InfoSphere CDC Event Server will use Java Reflection API to call your programs. InfoSphere CDC Event Server provides three types of calling conventions that can manipulate the following objects: See also: Simple string objects (type I) SQL data types (type II) on page 311 XML objects (type III) on page 311
Simple string objects (type I)

For this type of implementation, all the data passed to your Java program are of String type. Your program must also return a string. Syntaxjavas:[package.]className.methodName ([param1, ...]) -> String
310
where: v javasRepresents the identifier for the external Java call simple method. v classNameRepresents the Java class name, which may also reference the package name. v methodNameRepresents the method that performs the processing. Parameters are optional, and they can be XPath expressions, functions, or literal strings. Example<sxt:element name="MyTag" value="javas:com.ibm.MyClass.someMethod(@cust_id)"/>
SQL data types (type II)

For this type of implementation, all the data passed to your Java program are of Object type. Your program must also return an object. The data types are common SQL data types for databases. They are those defined by the java.sql package. The syntax is the same as for the type I, except that the identifier is java: instead of javas:, as follows:
java:[package.]ClassName.methodName([param1, ...]) -> Object
XML objects (type III)

This type of implementation supports extended XML objects, including XPath node-set and DOM objects (for example, Element and Node). InfoSphere CDC Event Server provides a set of XObjects (for example, XString, XNumber, XBoolean, and Xdate). The syntax is the following:
javax:[package.]ClassName.methodName([param1, ...]) -> XObject
In the current release, only type I (simple string objects) is fully implemented, while type II (SQL data types) and type III (XML objects) will be implemented in a future release.
XPath expression operators

An XPath expression returns either a node-set, a string, a Boolean, or a number. See also: + Operator on page 312 - Operator on page 312 * Operator on page 312 div Operator on page 312 mod Operator on page 312 = Operator on page 312 != Operator on page 312 < Operator on page 313 <= Operator on page 313 > Operator on page 313 >= Operator on page 313 or Operator on page 313 and Operator on page 313
Column functions
311
() parentheses Operator on page 313 [ ] Operator on page 314 / Operator on page 314 // Operator on page 314 @ Operator on page 314
+ Operator
DescriptionAdds two numbers. You can also use it to add two expressions that return a numeric result.
- Operator
DescriptionYields the difference between two numbers or indicates the negative value of a numeric expression.
* Operator
DescriptionMultiplies two numbers.
div Operator
DescriptionDivides two numbers and returns a floating decimal.
mod Operator
DescriptionDivides two numbers and returns only the remainder.
= Operator
DescriptionEqual. If the expression is equal to the specified value, the operator returns true. If the expression is not equal to the specified value, the operator returns false. Exampleprice=7.80 ReturnsTrue if price is 7.80; false if price is 7.90
!= Operator
DescriptionNot equal to. If the expression is not equal to the specified value, the operator returns true. If the expression is equal to the specified value, the operator returns false. Exampleprice!=7.80 ReturnsTrue if price is 7.90; false if price is 7.80
312
< Operator
DescriptionCompares two numeric expressions and determines whether expression1 is less than expression2; if so, the operator returns true. If expression1 is greater than or equal to expression2, the operator returns false. Exampleprice<7.80 ReturnsTrue if price is 7.00; false if price is 7.80
<= Operator
DescriptionCompares two specified numeric expressions and determines whether expression1 is less than or equal to the expression2; if it is, the operator returns true. If the expression1 is greater than expression2, the operator returns false. Exampleprice<=7.80 ReturnsTrue if price is 7.00; false if price is 7.90
> Operator
DescriptionCompares two numeric expressions and determines whether expression1 is greater than expression2; if it is, the operator returns true. If expression1 is less than or equal to expression2, the operator returns false. Exampleprice>7.80 ReturnsTrue if price is 7.90; false if price is 7.80
>= Operator
DescriptionCompares two numeric expressions and determines whether expression1 is greater than or equal to expression2 (true) or expression1 is less than expression2 (false).
or Operator
DescriptionLogical or.
and Operator
DescriptionLogical and.
() parentheses Operator
DescriptionControls the order in which the operators execute in the expression. Parentheses override the normal precedence order and cause the expressions within the parentheses to be evaluated first. When parentheses are nested, the contents of the innermost parentheses are evaluated before the contents of the outer ones.
Column functions
313
[ ] Operator
DescriptionA filter is evaluated as a Boolean on every node that is within the current context. If the Boolean evaluates to true, the node is included in the returned set; otherwise, it is excluded. Filters are enclosed in brackets.
/ Operator
DescriptionSelects from the root node.
// Operator
DescriptionSelects nodes in the document that match the selection no matter where they are.
@ Operator
DescriptionIdentifies an attribute of a node.
314
Filtering rows and columns

Use the Filtering tab to include or exclude rows or columns for replication. In this section, you will learn: Filtering rows Selecting critical columns to filter rows on page 316 Filtering columns on page 316
Filtering rows
In order to include or exclude particular rows for replication, you need to build a row-filtering expression. All row-filtering expressions that you define must return a boolean result. For example, you may have a source column such as SALARY that maintains the salary for each employee in your organization. You may only want to replicate those rows to the target table for those employees that have a salary greater than $48,000. In this scenario, you would need to define a row-filtering expression (SALARY > 48000). You can use column manipulation functions, basic numeric operators, and SQL SELECT WHERE clauses in your row-filtering expressions. The following are examples of valid row-filtering expressions: v (SALES < 10000) OR (SALES > 90000) v ((AIRPORT = 'JFK') OR (AIRPORT = 'LAX')) v %IF(COUNTRY = 'US', PRODUCTPRICE, PRODUCTPRICE *1.2) > 50 v PRODUCTPRICE * (1 + TAX) > 20000 See also: To filter rows
To filter rows
1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Filtering tab. 6. Click Editor and build a row-filtering expression. The expression must return a boolean result. 7. Click Verify to check the syntax of the expression and click OK to return to the Filtering tab. 8. Choose one of the following options in the Row-filtering area: v Select rows that match the expressionSelect this option if you want InfoSphere CDC to replicate the source rows that satisfy your row-filtering expression.
315
v Omit rows that match the expressionSelect this option if you want InfoSphere CDC to replicate all rows except those that satisfy your row-filtering expression. 9. Click Save. Related concepts Filtering rows on page 315
Selecting critical columns to filter rows

When you start replication on the subscription, InfoSphere CDC replicates the row based on the criteria you specified in your row-filtering expression. By default, InfoSphere CDC replicates inserts, updates, and deletes to the target table during replication. However, you can control the updates that InfoSphere CDC replicates using the select critical column feature. When you select a column as critical, InfoSphere CDC only replicates update operations when any critical column has changed value. For example, you may have a source table that maintains customer account information. Instead of receiving every update made to the source table, you may only want the target table to receive the row when the customer account balance is updated. In this scenario, you would select the column (Customer_Account_Balance) as a critical column. InfoSphere CDC will only replicate this row when there are updates made to the Customer_Account_Balance column. See also: To select critical columns
To select critical columns

1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Click the Filtering tab. 6. Enable the Critical check box next to each column you want to set as critical. 7. Click Save. 8. If you are using InfoSphere CDC for IBM i on the source, then you need to enable the Critical Column Filtering system parameter to *YES. Related reference Critical Column Filtering on page 595
Filtering columns
By default, InfoSphere CDC replicates all mapped source columns to the target table. If there is a source column you want to exclude for replication, then you can clear it on the Filtering tab. Excluding source columns for replication may become necessary if the column contains confidential information that you do not want the target to receive. See also:
316
To filter columns
To filter columns
1. Click Configuration > Subscriptions. 2. Select the subscription. 3. Click the Table Mappings view and select the table mapping from the Source Table column. 4. Right-click and select Open Details.... 5. Ensure that the source column has been unmapped from any target columns on the Column Mappings tab. 6. Click the Filtering tab. Source columns that you can clear for replication are selected with a green check mark in the Replicate column. If a source column has been mapped to a target column, the check mark will be grey instead of green and cannot be unchecked. You will have to unmap the source column on the Column Mappings tab before you will be able to filter it from replication. 7. Clear the green check mark for any columns that you do not want InfoSphere CDC to replicate data from a source columns 8. Click Save. Related concepts Filtering columns on page 316
Filtering rows and columns
317
318
Setting conflict detection and resolution

Conflict detection and resolution lets you detect, log, and act on inconsistent data on the target. This ensures your replication environment handles data conflicts automatically and in accordance with your business rules. Set conflict detection so that InfoSphere CDC can detect and resolve conflicts as they occur. As conflicts are detected and resolved, InfoSphere CDC logs them in a conflict resolution audit table. During replication, InfoSphere CDC detects conflicts when you: v Insert a row and the row's key already exists in the target table. This violates the unique key constraint. v Update a row and the row's key does not exist in the target table. v Update a row and the contents of the rows in the source table and target table, before the update, do not match. v Delete a row and the row's key does not exist in the target table. v Delete a row and the contents of the rows in the source table and target table, before the delete, do not match. InfoSphere CDC does not detect conflicts in target columns that are: v Populated with expressions using the %BEFORE, %CURR, %GETCOL, %STPROC, and %USER column functions. v Populated with journal control fields. v Not populated by a value. Notes: v InfoSphere CDC does not detect conflicts in columns that have Large Object (LOB) data types. v Conflict detection and resolution is only available when you map your tables using Standard replication. Conflict detection and resolution is supported for InfoSphere CDC Version 5.3 and higher. v Conflict detection and resolution is available for InfoSphere CDC for Teradata when JDBC apply mode is employed, but not for TPUMP apply mode. For more information on the requirements to configure a user exit program for conflict detection and resolution, see the "User Exits" section in the InfoSphere CDC documentation for your platform. In this section, you will learn: Resolving conflicts for source or target wins Resolving conflicts for largest or smallest value wins on page 321 Resolving conflicts with user exits on page 323
Resolving conflicts for source or target wins

Resolving conflicts for source wins
Use the Conflicts tab to set conflict detection and resolution so that the source wins. When InfoSphere CDC resolves conflicts so that the source column wins, it
319
applies the row from the source table to the target table. This ensures the target table row matches the data in your source table upon replication. For example, a remote location ships 100 books and updates their INVENTORY table to the latest quantity of the books. When InfoSphere CDC attempts to replicate the update to the target table, it detects a conflict because there is no row to update. In this scenario, InfoSphere CDC resolves the conflict by inserting the row from the source to the target.
Resolving conflicts for target wins

Use the Conflicts tab to set conflict detection and resolution so that the target wins. When InfoSphere CDC resolves conflicts for target wins, it does not apply any source changes to the target table. This preserves the row in the target table as InfoSphere CDC does not apply data from the source in the event of a conflict. For example, a remote location ships 25 pens and reduces the quantity of their pens to 175. Before starting replication with InfoSphere CDC, a clerk accidently changes the quantity of the pens to 300 on the target table. If InfoSphere CDC is configured to resolve conflicts for target wins, then no change is made to the target table and it is the same both before and after replication.
Note: Conflict detection and resolution is only available when you map your tables using Standard replication. Conflict detection and resolution is supported for InfoSphere CDC version 5.3 and higher. Conflict detection and resolution is not available for InfoSphere CDC for Teradata, InfoSphere CDC for InfoSphere DataStage or InfoSphere CDC Event Server. See also: To resolve conflicts for source row wins on page 321 To resolve conflicts for target row wins on page 321
320
Related concepts Resolving conflicts for source or target wins on page 319 Mapping using standard replication on page 87
To resolve conflicts for source row wins

Ensure that InfoSphere CDC is version 5.3 or higher Click Configuration > Subscriptions. Select the subscription. Click the Table Mappings view and select the table mapping from the Source Table column. This should be mapped for Standard replication. 5. Right-click and select Open Details.... 6. Click the Conflicts tab. 1. 2. 3. 4. The Target Column displays all of the columns in the target table. 7. Select the columns on which you want to detect conflicts. 8. Select Source Wins from the Conflict Resolution Method list. 9. Click Save. When you start replication on the subscription, if InfoSphere CDC detects a conflict in the target column, the source data is replicated to the target. Related concepts Resolving conflicts for source or target wins on page 319 Mapping using standard replication on page 87
To resolve conflicts for target row wins

1. Ensure that InfoSphere CDC is version 5.3 or higher 2. Click Configuration > Subscriptions. 3. Select the subscription. 4. Click the Table Mappings view and select the table mapping from the Source Table column. This should be mapped for Standard replication. 5. Right-click and select Open Details.... 6. Click the Conflicts tab. The Target Column displays all of the columns in the target table. 7. Select the columns on which you want to detect conflicts. 8. Select Target Wins from the Conflict Resolution Method list. 9. Click Save. When you start replication on the subscription, if InfoSphere CDC detects a conflict in the target column, the source data is replicated to the target. Related concepts Resolving conflicts for source or target wins on page 319 Mapping using standard replication on page 87
Resolving conflicts for largest or smallest value wins

Use the Conflicts tab to set conflict detection and resolution so that the largest value wins or the smallest value wins.
321
Resolving conflicts for largest value wins

When InfoSphere CDC resolves conflicts for largest value wins, it applies the change to the target if the source row has a larger value than the corresponding row on the target table. For example, if the comparison column contains revision times, then the target row matches the row that was most recently updated (largest time value). When resolving conflicts for largest value wins, InfoSphere CDC treats NULL values as the smallest possible value. If the row does not exist on the target table, then InfoSphere CDC uses NULL as the comparison value. If InfoSphere CDC detects the conflict while deleting a row, then it uses the before image of the source table and compares it to the target value. If both the source and target values are the same, then InfoSphere CDC resolves the conflict using the Target Wins method (no change is applied to the target).
Resolving conflicts for smallest value wins

When InfoSphere CDC resolves conflicts for smallest value wins, it only applies the change to the target if the value in the source row is smaller than the corresponding row on the target table. For example, if the comparison column contains quantities, then InfoSphere CDC matches the target row with the row that has the smaller quantity.
When resolving conflicts for smallest value wins, InfoSphere CDC treats NULL values as the smallest possible value. If the row does not exist on the target table, then InfoSphere CDC uses NULL as the comparison value. If InfoSphere CDC detects the conflict while deleting a row, then it uses the before image of the source table and compares it to the target value. If both the source and target values are the same, then InfoSphere CDC resolves the conflict using the Target Wins method (no change is applied to the target). If both the source and target values are the same, then InfoSphere CDC resolves it using the Target Wins method (no change is applied to the target). Note: Conflict detection and resolution is only available when you map your tables using Standard replication. Conflict detection and resolution is supported for InfoSphere CDC version 5.3 and higher. Conflict detection and resolution is not available for InfoSphere CDC for Teradata, InfoSphere CDC for InfoSphere DataStage or InfoSphere CDC Event Server. See also: To resolve conflicts for largest value wins on page 323 To resolve conflicts for smallest value wins on page 323
322
Related concepts Mapping using standard replication on page 87
To resolve conflicts for largest value wins

1. 2. 3. 4. 5. 6. 7. 8. 9. Ensure that InfoSphere CDC is version 5.3 or higher Click Configuration > Subscriptions. Select the subscription. Select the table mapping in the Table Mappings view. This should be mapped for Standard replication. Right-click and select Open Details.... Click the Conflicts tab. The Target Column displays all of the columns in the target table. Select the target columns on which you want to detect conflicts in the Detect Conflicts area. Select Largest Value Wins from the Conflict Resolution Method list. Select the column on the target table that you want to compare to the row on the source table from the Value Comparison Column .
10. Click Save. When you start replication on the subscription, if InfoSphere CDC detects a conflict in the target column, the source data is replicated to the target. Related concepts Resolving conflicts for source or target wins on page 319 Mapping using standard replication on page 87
To resolve conflicts for smallest value wins

1. Ensure that InfoSphere CDC is version 5.3 or higher 2. Click Configuration > Subscriptions. 3. Select the subscription. 4. Select the table mapping in the Table Mappings view. This should be mapped for Standard replication. 5. Right-click and select Open Details.... 6. Click the Conflicts tab. The Target Column displays all of the columns in the target table. 7. Select the columns on which you want to detect conflicts. 8. Select Smallest Value Wins from the Conflict Resolution Method list. 9. Select the column on the target table that you want to compare to the row on the source table from the Value Comparison Column. 10. Click Save. When you start replication on the subscription, if InfoSphere CDC detects a conflict in the target column, the source data is replicated to the target. Related concepts Resolving conflicts for source or target wins on page 319 Mapping using standard replication on page 87
Resolving conflicts with user exits

Use the Conflicts tab to resolve conflicts with user exit programs.
323
Resolving conflicts with user exit programs

When InfoSphere CDC resolves conflicts with a user exit program, it applies the image returned by the user exit program to the target table. Configuring a user exit program lets you specify the row you want InfoSphere CDC to use to resolve the conflict on the target table. When your user exit program returns a row, InfoSphere CDC applies that row to the target table to resolve the conflict. For example, a remote location receives a new shipment of erasers with a quantity of 400 and updates their INVENTORY table by inserting a new row. When InfoSphere CDC attempts to replicate the new insert, it detects a conflict because the row already exists in the target table. Since the database administrator has configured a user exit program that: v Receives data from the Eraser row from both the source and target table. v Concatenates values of both tables. InfoSphere CDC resolves the conflict according to the specifications in the user exit program.
Note: Conflict detection and resolution is only available when you map your tables using Standard replication. Conflict detection and resolution is supported for InfoSphere CDC version 5.3 and higher. Conflict detection and resolution is not available for InfoSphere CDC for Teradata, InfoSphere CDC for InfoSphere DataStage or InfoSphere CDC Event Server. See also: To resolve conflicts with user exit programs Related concepts Mapping using standard replication on page 87
To resolve conflicts with user exit programs

1. 2. 3. 4. Ensure that InfoSphere CDC is version 5.3 or higher Click Configuration > Subscriptions. Select the subscription. Select the table mapping in the Table Mappings view.
This should be mapped for Standard replication. 5. Right-click and select Open Details.... 6. Click the Conflicts tab. The Target Column displays all of the columns in the target table. 7. Select the columns on which you want to detect conflicts. 8. Select User Exit from the Conflict Resolution Method list.
324
9. Enter the full path and file name of the user exit program you want to call when InfoSphere CDC detects a conflict in the User Exit (with path) box. 10. Click Save. When you start replication on the subscription, if InfoSphere CDC detects a conflict in the target column, the source data is replicated to the target. Related concepts Resolving conflicts for source or target wins on page 319 Mapping using standard replication on page 87
325
326
Controlling row operations

Management Console lets you set how a target table responds to changes made on the source table. In this section, you will learn: Suppressing the apply of row operations Preventing the audit of row operations on page 328 Detecting conflicts on row operations on page 329 Enabling the apply of soft deletes (InfoSphere CDC for Oracle databases) on page 330
Suppressing the apply of row operations

Use the Operations tab to suppress an insert, update, or a delete from replicating to the target table. You may decide to suppress row-level operations from replicating to a target table if you have a target-side application on which you do not want any updates or deletes to occur. For example, if your target-side application is a data warehouse, you may only want inserts to occur on your data warehouse tables or other third party applications. You can suppress operations if you mapped tables using either Standard or Adaptive Apply replication. See also: To suppress an insert, update, or delete Related concepts Mapping using standard replication on page 87 Mapping using Adaptive Apply on page 100
To suppress an insert, update, or delete

1. Click Configuration > Subscriptions. 2. Select the subscription. Ensure that the subscription contains a table mapping that was mapped using Standard or Adaptive Apply. 3. Select the table mapping in the Table Mappings view. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. Choose one or more of the following: Do not insertPrevents InfoSphere CDC from applying an insert to a mapped target table. v Do not updatePrevents InfoSphere CDC from applying an update to a mapped target table. v Do not deletePrevents InfoSphere CDC from applying a delete to a mapped target table. 7. Click Save. v
327
Depending on your selections, when you start replication, InfoSphere CDC does not apply the row operation. Related concepts Suppressing the apply of row operations on page 327
Preventing the audit of row operations

Use the Operations tab to prevent InfoSphere CDC from the auditing of row operations. If you have mapped your tables using LiveAudit, then InfoSphere CDC audits row level operations taking place on the source. You can also restrict auditing so that your target table only audits the after image when there is a change to a row in the source table. This is especially useful if you want to reduce the size of your audit trails for recovery purposes. See also: To prevent row operations from being audited To audit only the after image Related concepts Mapping using LiveAudit on page 95
To prevent row operations from being audited

1. Click Configuration > Subscriptions. 2. Select the subscription. Ensure that the subscription contains a table mapping that was mapped using LiveAudit. 3. Select the table mapping in the Table Mappings view. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. Choose one or more of the following: v Do not insertPrevents InfoSphere CDC from auditing an insert to a mapped target table. v Do not updatePrevents InfoSphere CDC from auditing an update to a mapped target table. v Do not deletePrevents InfoSphere CDC from auditing a delete to a mapped target table. 7. Click Save. Related concepts Preventing the audit of row operations
To audit only the after image

1. Click Configuration > Subscriptions. Ensure that the subscription contains a table mapping that was mapped using LiveAudit. 2. Select the subscription. 3. Select the table mapping in the Table Mappings view. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. Select Audit After Image from the On Update list.
328
7. Click Save. Related concepts Preventing the audit of row operations on page 328
Detecting conflicts on row operations

Use the Operations tab to set conflict detection between row operations on the source and target. If you have mapped your tables using Adaptive Apply , then InfoSphere CDC forces the target table into consistency with row-level operations taking place on the source table. However, when InfoSphere CDC applies an insert, update, or delete and it is not the same as the row level operation applied to a target table, then this creates a conflict. For example, you may have inserted a row in the source table, but the resulting row-level operation on the target table is an update because that row already exists in the target table. To ensure that the target table is always consistent with the source table, you can set detection on row-level conflicts. When there is a conflict against an insert, update or a delete operation, InfoSphere CDC generates a message. You can view these messages in the Events area of the Subscriptions view of the Monitoring perspective. See also: To detect conflicts on row operations Related concepts Resolving conflicts for source or target wins on page 319 Mapping using Adaptive Apply on page 100
To detect conflicts on row operations

1. Click Configuration > Subscriptions. 2. Select the subscription. Ensure that the subscription contains a table mapping that was mapped using Adaptive Apply. 3. Select the table mapping in the Table Mappings view. 4. Right-click and select Open Details.... 5. Click the Operation tab. 6. Choose one or more of the following: v On InsertGenerates a message when there is an insert on the source, but the responding row-level operation on the target is an update. Select Update Row if Exists, Else Insert and check the Log changed database action box. v On UpdateGenerates a message when there is an update on the source, but the responding row-level operation on the target is an insert. Select Update Row if Exists, Else Insert and check the Log changed database action box. v On DeleteGenerates a messages when there is a delete on the source, but there is no responding row-level operation to apply to the target. Select Delete Row if Exists and check the Log changed database action box. 7. Click Save.
Controlling row operations
329
Related concepts Resolving conflicts for source or target wins on page 319 Detecting conflicts on row operations on page 329
Enabling the apply of soft deletes (InfoSphere CDC for Oracle databases)
You can introduce a flag that audits the current state of an existing target table which indicates that a row has been deleted (this is called a soft delete) instead of actually deleting the row (a hard delete). If you have mapped your target tables using Adaptive Apply, then you can enable InfoSphere CDC for Oracle databases to apply a soft delete on the target table. This means that when there is a delete on the source table, InfoSphere CDC either: v updates a row on the target table if the row exists, or v inserts a row on the target table if it does not exist. When InfoSphere CDC applies the soft delete, the target table will contain: v the before image of the row that was deleted and v the journal entry type Delete. Depending on whether you want InfoSphere CDC for Oracle databases to apply the soft delete to all mapped target tables or to apply the soft delete on a specific target table in the subscription, you must enable one of the following system parameters: v DM_ADAPTIVE_APPLY_SOFT_DELETESInfoSphere CDC for Oracle databases applies a soft delete on all target tables mapped using Adaptive Apply in a subscription. v DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME>InfoSphere CDC for Oracle databases applies a soft delete on a specific target table mapped using Adaptive Apply in a subscription. See also: To enable InfoSphere CDC for Oracle to apply a soft delete
To enable InfoSphere CDC for Oracle to apply a soft delete

1. Ensure that you have set either the DM_ADAPTIVE_APPLY_SOFT_DELETES system parameter or the DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME> system parameter to ON. 2. Click Configuration > Subscriptions. 3. Select the subscription. Ensure that the subscription contains a table mapping that is configured for Adaptive Apply replication. 4. Select the table mapping in the Table Mappings view. 5. Right-click and select Open Details.... 6. Click the Operation tab. 7. Choose Delete Row, If Exists from the On Delete list. 8. Click Save. Related reference DM_ADAPTIVE_APPLY_SOFT_DELETES on page 478 DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME> on page 479
330
Customizing JMS message destination mappings

After mapping your tables using the Map Tables wizard, you can use the XML Message tab to customize which columns you want to map to XML elements and attributes. You can build your XML message and XPath expressions, import and export mapping projects, import/export XML schemas, and query columns from other tables if required. This tab is only available for subscriptions targeting a JMS message destination. In this section, you will learn: Creating an XML message Importing and exporting XML files, schemas, and mapping projects on page 332 Building an XPath expression on page 334 Querying columns from other tables on page 335
Creating an XML message

You can create an XML message by mapping source columns to XML elements and attributes. See also: To create an XML message
To create an XML message

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. Select the subscription that contains the table mapping to a message destination. Ensure that you have ended any active replication on the subscription. Click the Table Mappings view and select the table mapping from the Source Table column. Right-click and select Open Details.... Click the XML Message tab.
3.
4. 5. 6.
7. Expand the Source tree and build the structure of the XML message in one of the following ways: v If you want the XML message to have the same structure as your source table, then you can drag and drop the entire source table to the root (/) node of the XML Document Structure area. This method retains mappings between source columns and XML elements and attributes. v If you have an existing XML structure, then you can import the structure into the XML Document Structure area. v You can manually build the XML structure using the options provided in the XML Document Structure area:
331
Add an XML element Add an XML attribute Rename an element or attribute Move an XML element or attribute up and down the result tree Change the node type to either XML element or attribute
8. Verify the following options from the Output area for each XML element or attribute you have mapped to a source column: v AlwaysIndicates that if the value of an XML element or attribute is empty, then InfoSphere CDC Event Server includes the XML element or attribute in the XML message and sets the value to an empty string. This occurs when you have mapped an XML element or attribute to a source column that is blank, or when you have mapped the XML element or attribute to a source column that contains a derived expression that results to an empty string. Optional when empty or NULLIndicates that if the value of an XML element or attribute is mapped to a source column that is empty or NULL, then the XML element or attribute is not included in the XML message. v Optional when NULLIndicates that if the value of an XML element or attribute is mapped to a source column that is NULL, then the XML element or attribute is not included in the XML message. However, if the XML element or attribute is mapped to a source column that contains an empty string, then InfoSphere CDC Event Server includes the XML element or attribute in the XML message. 9. Verify the XPath expression for each mapping in the Value area. v When you map a source column to an XML element or attribute, you are mapping the value of the source column to an XML element or attribute. This value is represented as an XPath expression in the Value area. If necessary, you can edit the expression using the Expression editor. 10. Click Save. Related concepts Importing and exporting XML files, schemas, and mapping projects Related tasks To build an XPath expression on page 334 To end replication on page 362
Importing and exporting XML files, schemas, and mapping projects

You can import XML files into Management Console. You can also import and export XSD files and XTRANS files created in Management Console. v Importing XML filesYou may have already created an XML file using an editor outside of Management Console. You can import this XML file and continue mapping source columns to elements and attributes in Management Console. When importing XML files, you can choose to import repeated elements, as well as choosing to import attribute values into Management Console. v Importing and exporting XSD filesYou may want to import the schema of an XML message into Management Console when it is necessary to generate an XML document using a specific structure. When importing the schema, the structure of the XML document is displayed the XML Document Structure area in Management Console. You can then continue to map source columns to XML elements or attributes to create values and build XPath expressions if required.
332
The XPath expression identifies the XML element or attribute that contains the value of a source column. You can also export the schema. This may be necessary when another department or organization requires the schema. v Importing and exporting XTRANS filesYou can export the mapping definition of your XML document with values to your local computer. You can later reuse the mapping definition for other XML documents by importing it back into Management Console. It is important to note that any preexisting mappings between source columns to XML elements and attributes in Management Console are replaced with the imported mapping definition.
See also: To import an XML, schema, or mapping definition file To export an XML schema or mapping definition file
To import an XML, schema, or mapping definition file

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. Select the subscription that contains the table mapping to a message destination. Click the Table Mappings view and select the table mapping from the Source Table column. Right-click and select Open Details.... Click the XML Message tab.
3. 4. 5. 6.
and from the Files of Type list, select one of the following: 7. Click v Schema fileImports the structure of the XML document. v Mapping definitionImports an XML document with mapped source column to XML element and attribute values. The values in the mapping definition replace any preexisting mappings of your XML document in Management Console. v XML fileImports an XML document. If you are importing an XML file, then the XML Import Options dialog box opens and you can enable one or both of the following options: Import repeated elements with the same parentBy default, Management Console imports only one repeated element in a group node with the same parent. Enable this option to import all repeated elements. Import attribute valuesBy default, Management Console imports only the structure of your XML. Enable this option to import the attribute values. This may be necessary if attribute values represent the structure of your XML document. 8. Click Save. Related concepts Importing and exporting XML files, schemas, and mapping projects on page 332
To export an XML schema or mapping definition file

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore.
333
2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select the subscription that contains the table mapping to a message destination. 4. Click the Table Mappings view and select the table mapping from the Source Table column. 5. Right-click and select Open Details.... 6. Click the XML Message tab. Ensure that you have created the structure of an XML message that you can export. and from the Save as Type list, select one of the following: 7. Click v Schema file (XSD)Exports only the structure of the XML document. This includes the name of the element, attribute, and the tree structure. Any pre-existing mapping definitions are not exported. v Mapping definition (XTRANS)Exports the structure of the XML document and the mapping definition you created in Management Console. 8. Click Save. Related concepts Importing and exporting XML files, schemas, and mapping projects on page 332
Building an XPath expression

When you launch the Expression Builder, you can build an XPath expression to reference a source column (the before or after image), a journal control field, a function, a literal value in single quotes, or a combination of these. For more information about XPath expressions, see http://www.w3.org/TR/xpath. See also: To build an XPath expression
To build an XPath expression

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. Select the subscription that contains the table mapping to a message destination. Click the Table Mappings view and select the table mapping from the Source Table column. Right-click and select Open Details.... Click the XML Message tab. Ensure that you have an existing XML structure you can build an expression for in the XML Document Structure area. Select an XML element or attribute for which you want to build an XPath expression and double-click the Value area to open the Expression Builder.
3. 4. 5. 6.
7.
334
8. You can build an expression using a combination of one or more of the following items: v FunctionsSpecifies functions and a location path for your XPath expression. v OperatorsUses operators to build your expression. For more information about a specific function or operator, press F1. v DatabaseRepresents the source database and lists all the nodes (such as source columns and journal control fields) in your source table. Select the node you want to search for, double-click it to add to the Expression box. You can repeat this process for all the nodes you want to add to the expression. v Target XML DocumentRepresents the XML document that you want to send to the JMS queue or topic. v Saved expressionsLists any saved expressions you have built. Your XPath expression can reference these.
9. Click Verify to verify the expression. 10. Click OK. Related concepts Building an XPath expression on page 334
Querying columns from other tables

The XML message you want to send may depend on columns from other tables. You can query these columns from other databases for which you have configured a JDBC connection or from tables in the InfoSphere CDC Event Server staging database. See also: To query columns from other tables
To query columns from other tables

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. 3. Select the subscription that contains the table mapping to a message destination. The selected subscription must use an InfoSphere CDC Event Server datastore as the target. 4. Select the table mapping to work with on the Table Mappings view. 5. 6. 7. 8. 9. Right-click and select Open Details.... Click the XML Message tab. Expand the Other Tables tree. Double-click on Add Tables. Choose one of the following options: v Add table as top level nodeSelect this option when you want the other table to reside at the node level. v Add table as a child of another tableSelect this option when you want the table to reside as the child of another table. You must add a parent table before you can add a child table.
335
10. Click Next. 11. Select the table you want to add. This can be from a database you have configured a JDBC connection for or from the InfoSphere CDC Event Server staging database. 12. Choose one of the following: v Click Next to continue with the wizardDirects the wizard to create the SQL statement for you based on the columns in the other table. You can modify the SQL statement in the SQL Expression editor. v Click Finish to add the table and open the SQL editorAllows you to create your own SQL statement in the SQL Expression editor. 13. If you chose the Click Finish to add the table and open the SQL editor option, click Finish. The SQL Expression Editor opens and you are required to build a valid SQL expression. When you have completed building the SQL statement, you must map this expression to an XML element or attribute in your XML document. When you start replication, InfoSphere CDC Event Server will retrieve data values from the table based on your query. Otherwise, click Next to continue build your SQL statement with the help of the wizard. 14. Review the columns in your select statement on the SELECT Clause. 15. If you want to add more columns, click Add. Specify a name for the column and the column or expression you want InfoSphere CDC Event Server to retrieve. You can modify the name to an alias name. With SQL, aliases can be used for column names and table names. If you specify an alias for the column name, the SELECT statement will retrieve the column and return the result with the alias name you specified. Select the column from the Column/Expression list box and click OK 16. Click Next. 17. On the WHERE Clause page, you can choose to add filters to restrict which rows are returned by the query. The where clause is optional. Omitting the WHERE clause from your SQL statement specifies that all rows are returned by the query. If you want to create a WHERE clause, click Add to enable the fields required to build your WHERE clause statement. Your WHERE clause can return one of the following values: v Static valuesTo build your WHERE clause so that it returns a static value, select Value from the Type list and specify the value in the Value box. v The before image or the after image of a rowTo build your WHERE clause so that it returns the before image or the after image of the column, select Trigger from the Type list and then select either the before image or the after image of the column from the Value list. Also, if you want InfoSphere CDC Event Server to detect any missing before images or after images, then enable the If before/after image does not exist, use other image check box. For example, if you map the before image of a column to an XML element or attribute and the operation on the source database was an insert, then because there is no before image of that column, InfoSphere CDC Event Server inserts the after image of the column instead when you enable this check box. Also, if you map the after image of a column to XML element or attribute and the operation on the source database was a delete, then because there is no after image of a delete operation, InfoSphere CDC Event Server inserts the before image of that column instead. v The column of a parent tableTo build your WHERE clause so that it returns the column of the parent table, select Parent Table Column from the
336
Type list and then select the column name from the Value list. This option is only available if the table is added a child of a parent table. 18. Click Next. 19. On the GROUP BY clause page, group the results by one or more columns. The GROUP BY clause is optional. When specified, it can be used in a SELECT statement to collect data across multiple rows. 20. Click Next. 21. On the ORDERED BY clause page, sort the records in your result set. The ORDER BY clause is optional. You can order the result set in either ascending or descending order. 22. Click Finish. Related concepts Querying columns from other tables on page 335
337
338
Setting JMS message header properties

Only available for subscriptions targeting a JMS message destination, you can use the XML Settings tab to set JMS message header properties for the XML message. These properties are saved on the source table to XML mapping and are valid each time you send the XML message to a queue or topic. You can edit these values using the expression editor at any time. In addition to the JMS header properties provided with InfoSphere CDC Event Server, you may also need to associate extra information in the header of an XML message. InfoSphere CDC Event Server lets you specify custom JMS header properties in an XML message. You can use this information in a JMS selector to filter messages. In this section, you will learn: Defining the JMS message header Setting general runtime options on page 341
Defining the JMS message header

You can add and delete JMS message header properties. You can also add or delete custom properties that you create. See also: To add a JMS message header property To add a custom JMS message header property on page 340 To delete a custom JMS message header property on page 340
To add a JMS message header property

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select the subscription that contains the table mapping to a message destination. 4. Click the Table Mappings view and select the table mapping from the Source Table column. 5. Right-click and select Open Details.... 6. Click the XML Settings tab. 7. Select one of the following in the Standard Settings area: v JMS Correlation IDProvides a way to correlate related messages. This is normally used for a request or response scenario. This can either be a vendor-specific ID, an application-specific string, or a provider-native byte value. v JMS PriorityIndicates the priority at which the JMS server will handle the message. By default, InfoSphere CDC Event Server assigns a priority of
339
4. JMS uses a priority scale from 0 to 9, where 0 indicates the lowest priority and 9 indicates the highest priority. v JMS Reply ToContains a destination supplied by a client when a message is sent. If you want to receive a response from the JMS queue or topic when either of these destinations receive a message, then specify the destination. v JMS Time to LiveSpecifies the number of milliseconds that you want the XML message to remain in the queue or topic. This value is used by your JMS provider to delete XML messages automatically once the amount of time specified in the box expires. The default value is 0, which indicates that the XML message will never be deleted automatically from the queue or topic. v JMS TypeSpecifies the type of message you are sending. This could be the name of the queue or topic. Your JMS provider can use a message repository that contains the definition of messages sent by third party applications. You should enter a symbolic value that can be configured to the values defined in the current providers' message repository. to open the expression editor and set a value for the JMS property. 8. Click 9. Specify a value (enclose the value in quotation marks) or an expression for the JMS property and click Verify . 10. Click OK. 11. Click Save. Related concepts Setting JMS message header properties on page 339
To add a custom JMS message header property

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select the subscription that contains the table mapping to a message destination. 4. Click the Table Mappings view and select the table mapping from the Source Table column. 5. Right-click and select Open Details.... 6. Click the XML Settings tab. 7. Click Add. 8. Enter the name of the JMS property and click OK. to set a value in the Expression editor. 9. Click 10. Click OK. 11. Click Save. Related concepts Setting JMS message header properties on page 339
To delete a custom JMS message header property

340
2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select the subscription that contains the table mapping to a message destination. 4. Click the Table Mappings view and select the table mapping from the Source Table column. 5. 6. 7. 8. 9. Right-click and select Open Details.... Click the XML Settings tab. Select the JMS property you want to delete in the Custom Settings area. Click Delete. Click Save.
Related concepts Setting JMS message header properties on page 339
Setting general runtime options

You can set the following runtime options: v Trim textBy default, InfoSphere CDC Event Server does not trim trailing spaces from values in the message body and message header. You can enable this option so that InfoSphere CDC Event Server trims the trailing spaces. v Nullable XPath expressionBy default, InfoSphere CDC Event Server differentiates between empty strings and a null value. Most XML parsers return an empty string if a referenced node does not exist in the source table. This results in no distinction between an empty string and a null value. However, InfoSphere CDC Event Server can differentiate a real empty string (the node does exist, but contains an empty value) from a null value (the referenced node does not exist at all). Disable this option if you do not want InfoSphere CDC Event Server to distinguish between empty strings and a null value. v Allowed streamed transformation modeBy default, InfoSphere CDC Event Server uses IBM's Streamed XML Transformation (XST). Disable this check box if you want InfoSphere CDC Event Server to use the Document Object Model (DOM) instead. The XST technology will dynamically switch parsing mode between (Simple API for XML) SAX and DOM depending on your transformation requirements. This may affect the performance but may be necessary in some cases. See also: To enable InfoSphere CDC Event Server to trim text To disable InfoSphere CDC Event Server from differentiating between an empty string from a NULL value on page 342 To disable streamed transformation mode on page 342
To enable InfoSphere CDC Event Server to trim text

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target.
Setting JMS message header properties
341
3. Select the subscription that contains the table mapping to a message destination. 4. Click the Table Mappings view and select the table mapping from the Source Table column. 5. Right-click and select Open Details.... 6. Click the XML Settings tab. 7. Enable the Trim Text check box to trim the trailing spaces from all values in the message body and message header. 8. Click Save. Related concepts Setting general runtime options on page 341
To disable InfoSphere CDC Event Server from differentiating between an empty string from a NULL value
1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. Select the subscription that contains the table mapping to a message destination. Click the Table Mappings view and select the table mapping from the Source Table column. Right-click and select Open Details.... Click the XML Settings tab. Disable the Nullable XPath expression check box.
3. 4. 5. 6. 7.
8. Click Save. Related concepts Setting general runtime options on page 341
To disable streamed transformation mode

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select the subscription that contains the table mapping to a message destination. 4. Click the Table Mappings view and select the table mapping from the Source Table column. 5. Right-click and select Open Details.... 6. Click the XML Settings tab. 7. Disable the Enable streamed transformation mode check box. 8. Click Save. Related concepts Setting general runtime options on page 341
342
Configuring replication
After creating subscriptions and mapping your tables between your source and target, you can configure replication in the Configuration perspective of Management Console. Configuration involves tasks such as flagging tables for refresh, marking a table capture point on a source table, changing the replication method, and parking a table from replication. Configuring replication is often necessary before proceeding to operational tasks such as starting replication or starting a refresh. The Configuration perspective requires Administrator or Operator role privileges for read and write access. The Monitor role cannot view the Configuration perspective. In this section, you will learn: Flagging a source table for refresh Marking a table capture point on a source table on page 348 Parking a table from replication on page 349 Changing the refresh order of tables on page 349 Changing the replication method of a table on page 350 Selecting a new journal table on page 351 Setting members for replication on page 353 Changing the message destination on page 353
Flagging a source table for refresh

The InfoSphere CDC refresh operation is designed to synchronize source and target tables. Tables can become out of synchronization for various reasons, including the following issues: v Parked tablesParking a table from replication for some time to make changes (such as updating the definition of a source table) and the changes that are taking place on the source are no longer being replicated. This may cause the target table to become inconsistent with the source table. v Configuration changesA refresh may be necessary when a set of subscriptions are promoted from a test environment to a production environment. The promotion operation may add new transformations or other table mapping changes which require the source and target tables to be refreshed in order to prepare for mirroring. v Maintenance operationsLarge bulk SQL operations performed during maintenance windows on the source table which affect a majority of the rows may be faster to resynchronize using refresh. Refresh may be faster than mirroring to replicate millions of changes due to the ability to bulk load rows into the target database. When you have a subscription that contains a target table that is not synchronized with the source table, you can flag the source table for a refresh. Tables that are flagged for refresh and have a replication method of Mirror will be refreshed before mirroring begins.
343
InfoSphere CDC will refresh all of the flagged tables within a single subscription as one sequential operation which will run to completion. Each table is refreshed individually one at a time until all flagged tables have finished refreshing. Refresh is an operation which applies to a single subscription, so while one subscription is refreshing other subscriptions are not affected; they may continue mirroring data for different tables or refreshing tables as required. To perform a parallel refresh, multiple subscriptions can be used. InfoSphere CDC offers two types of refresh operations: Standard Refresh and Differential Refresh. A Standard Refresh results in a complete copy of the data in a source table being sent to the target table. This operation truncates or deletes the contents of the target table and then inserts the new contents as sent by the source system. A Differential Refresh updates the target table by applying only the differences between it and the source table. Instead of the target table being cleared at the start of the refresh and repopulated with data, as with the Standard Refresh, the Differential Refresh compares each row in the target table with each row in the source table to identify missing, changed or additional rows. The primary advantage of the Differential Refresh is that the target table stays online during the refresh operation. There are three possible methods for the Differential Refresh: v Refresh OnlyPerforms a Differential Refresh by changing any target rows that differ from the source rows. v Refresh and Log DifferencesPerforms a Differential Refresh, and also creates a log table in the target replication engine metadata to track all changes during the refresh. The log table is identical to the target table, with the addition of a column to indicate the actions taken during the refresh, such as inserting a row, deleting a row, or updating a row. For an update, both the source and target row images are logged. This log table is created in the same database and tablespace as the TS_CONFAUD table (or DMMD_DMCONFAUD table for InfoSphere CDC for z/OS), with the same owner as the metadata. The name of the log table is created by combining the subscription name, the target table name, and the refresh start date and time. v Only Log DifferencesCreates and populates a log table in the target replication engine metadata to identify all differences between the source and target tables. The target table is not updated. This allows you to evaluate what the differences are between the target and the source. If you then decide to refresh the table, you can go back to the subscription and select Refresh Only to update the target table or update the target table manually based on the contents of the log table. Performing a Differential Refresh has some requirements and restrictions: v Differential refresh is only available for tables that use Standard replication v The collation sequence of the source and target tables must be identical v Derived columns on the source table are not supported v Any target columns which are mapped to derived expressions, constants or journal control fields will be ignored v The key columns of the target table must be mapped directly to columns on the source table. v The target table must have a unique key, either a primary key or a unique index with at least one non-nullable column.
344
Both a Standard Refresh and Differential Refresh can be further refined through the use of a SQL WHERE clause to only include rows within a specified range. This is useful for tables where only the most recent data requires a refresh. If you want to refine the refresh through the use of a SQL WHERE clause, then the Row Subset feature requires one of the following conditions be met: v The table capture point has been set, either explicitly or through the table having been mirrored in Management Console v The scraping point for the subscription has been set (using the SETLOGPOS command or dmsetbookmark command where applicable) The order in which data is retrieved from the database during a refresh depends on the type of refresh performed. During a Standard Refresh, no ORDER BY sort is used; the database determines the order in which the data is returned. During a Differential Refresh, InfoSphere CDC queries the database using an ORDER BY sort on the table keys chosen in the table mapping to sort the source and target tables and determine their differences. When a refresh is performed with multiple tables, the order in which each individual table is refreshed is based on the group order, as set in Refresh Order option. If no Refresh Order is set, then tables are refreshed in alphabetical order. After a refresh has successfully completed, the subscription can be restarted for mirroring. InfoSphere CDC will then process the backlog of changes. For tables which weren't refreshed InfoSphere CDC will continue processing changes from the position where mirroring ended. For tables which were refreshed, InfoSphere CDC will process all the changes that committed after refresh began for that table. See also: To flag a source table for a Standard Refresh To flag a source table for a Differential Refresh on page 346 Sample: Refreshing subsets of rows on page 346 Related concepts Changing the refresh order of tables on page 349 Starting a refresh on a subscription on page 358
To flag a source table for a Standard Refresh

1. Ensure that you have ended any active replication on the subscription. 2. Click Configuration > Subscriptions. Select the subscription that contains the mapped source and target tables. Select the mapped source and target tables in the Table Mappings view. Right-click on the table and click Flag for Refresh .... Select Standard Refresh. If you only want to refresh a subset of rows under certain conditions, then enable the Refresh only a subset of rows check box. Enter an SQL WHERE clause in both the Source WHERE clause and Target WHERE clause list box. You must ensure that the subscription is set to a replication method of Mirroring. You set this when mapping tables in the Map Tables wizard. 8. Click OK. 3. 4. 5. 6. 7.
345
Related concepts Starting and ending replication on page 355 Mapping tables on page 83 Flagging a source table for refresh on page 343 Controlling the apply of refresh operations on page 213 Ending replication on page 361
To flag a source table for a Differential Refresh

1. 2. 3. 4. Ensure that you have ended any active replication on the subscription. Click Configuration > Subscriptions. Select the subscription that contains the mapped source and target tables. Select the mapped source and target tables in the Table Mappings view.
5. Right-click on the table and click Flag for Refresh .... 6. Select Differential Refresh. 7. Select the level of Differential Refresh: v Refresh OnlyPerforms a Differential Refresh by changing any target rows that differ from the source rows. v Refresh and Log DifferencesPerforms a Differential Refresh, and also creates a log table to track all changes during the refresh. v Only Log DifferencesCreates and populates a log table to identify all differences between the source and target tables. 8. If you only want to refresh a subset of rows under certain conditions, then enable the Refresh only a subset of rows check box. Enter an SQL WHERE clause in both the Source WHERE clause and Target WHERE clause list box. You must ensure that the subscription is set to a replication method of Mirroring. You set this when mapping tables in the Map Tables wizard. 9. Click OK.
Sample: Refreshing subsets of rows

There are several uses for refreshing subsets of rows: v Re-synchronizing tables which are out-of-sync v Refreshing very large tables in stages Accommodating smaller batch windows Less interruption for other tables being replicated v Synchronization check for subset of rows For the following examples, we have a table mapping containing columns to indicate the status of customers. On the source table, this column is called STATUS. On the target table, the column is called ACTIVITY_STATUS. The table mapping has a Data Translation of the following values:
Source table (Before image) Column name: STATUS A D I Row Count 255 49 16 Target table (After image) Column name: ACTIVITY_STATUS ACTIVE DELETED INACTIVE Row Count 255 49 16
346
Source table (Before image) P 64
Target table (After image) PENDING 32
The difference between the two tables is that 32 "PENDING" rows are missing from the target table
Example 1: Refreshing a subset of rows

To synchronize the tables, you could perform a standard refresh, which would replace all rows in the target table. Instead, refreshing a subset of rows will allow you to refresh just the "PENDING" rows. Steps: 1. Select the table, right-click and choose Flag for refresh .... 2. Select Standard Refresh. 3. Select Refresh only a subset of rows. 4. In the Source WHERE clause list, type the following text: STATUS='P' 5. In the Target WHERE clause list, type the following text: ACTIVITY_STATUS='PENDING' 6. Click OK When the refresh starts, InfoSphere CDC will first delete the rows on the target using the target WHERE clause. All rows with ACTIVITY_STATUS='PENDING' will be removed. Subsequently, rows on the source will be selected using the source WHERE clause. All rows with STATUS='P' will be transferred to the target table.
Example 2: Partial synchronization checks

A Differential Refresh compares each row in the target table with each row in the source table to identify missing, changed or additional rows. For large tables, a full synchronization check could be time consuming. Using the Refresh only a subset of rows option will allow you to do partial synchronization checks. In this example, all rows with STATUS='D' will be checked. Steps: 1. Select the table, right-click and choose Flag for refresh .... 2. Select Differential Refresh and choose the Only Log Differences (Refresh Not Performed) mode. 3. Select Refresh only a subset of rows. 4. In the Source WHERE clause list, type the following text: STATUS='D' 5. In the Target WHERE clause list, type the following text: ACTIVITY_STATUS='DELETED' 6. Click OK Subsequently, when starting the subscription, all rows with STATUS=D' will be sent to the target for synchronization checking.
347
No rows will be updated on the target, due to Only Log Differences (Refresh Not Performed) being selected. If the subscription is started in Continuous mirroring mode, the mirroring will resume after the differences are logged.
Considerations
The following issues should be considered when you are using Refresh only a subset of rows: v Refresh of a subset of rows can only be configured when flagging individual tables v Refreshing a subset of rows will always insert the rows on the target with JDBC apply. Fast Load utility cannot be used when refreshing a subset of rows If the subset of rows to be refreshed is a large portion of the table, you may consider refreshing all rows instead to save time v When flagging the table for refresh next time, the Refresh only a subset of rows checkbox is unchecked by default. The WHERE clauses are maintained though, but not used when refreshing the table. v If both row filtering and Refresh only a subset of rows have been specified, row filtering expression and the source WHERE clause will be concatenated (AND operator). v If both deletion of selected rows and Refresh only a subset of rows have been specified, the expressions will be concatenated (AND operator) Related concepts Setting data translations on page 183
Marking a table capture point on a source table

Attention: Only use this procedure 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 Management Console (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. See also: To mark a table capture point on a source table before mirroring on page 349
348
To mark a table capture point on a source table before mirroring

1. Ensure that your database platform is in idle mode to avoid losing synchronization between your source and target tables. 2. Ensure that you have ended any active replication on the subscription that contains the source table. 3. Click Configuration > Subscriptions. 4. Select the subscription that contains the mapped source and target tables. 5. Select the mapped source tables in the Table Mappings view. You can mark a table capture point on more than one mapped source table at a time. 6. Right-click and select Mark Table Capture Point For Mirroring. Related concepts Marking a table capture point on a source table on page 348 Ending replication on page 361
Parking a table from replication

If your subscription contains more than one table mapping, then you can park one or more before starting mirroring or a refresh on your subscription. When you park a table mapping from replication, InfoSphere CDC does not replicate changes to the target. See also: To park a table from replication
To park a table from replication

1. Ensure that you have ended any active replication on the subscription. 2. Click Configuration > Subscriptions. 3. Select the subscription that contains the mapped source and target tables. 4. Select the mapped source and target tables in the Table Mappings view. You can park more than one table-mapping at a time. 5. Right-click and click Park (Do Not Replicate). Related concepts Parking a table from replication Ending replication on page 361
Changing the refresh order of tables

If you have set referential integrity constraints on your tables, then you can set a refresh order to preserve these constraints during a refresh. For example, you may want InfoSphere CDC to refresh your DEPARTMENT tables before refreshing your EMPLOYEE tables, based on the fact that each employee belongs to a specific department. You can change the order in which InfoSphere CDC refreshes your table mappings by moving tables into groups. Each table you decide to move into a group is assigned a sequence number that InfoSphere CDC uses to refresh each table mapping in numerical order. For example, if you want InfoSphere CDC to refresh your DEPARTMENT table before refreshing the EMPLOYEE table, then you can add a group for each of these table mappings and move the DEPARTMENT table in group 1 and the EMPLOYEE table in group 2.
349
Any remaining table mappings that you did not add to a group are refreshed in an arbitrary order by InfoSphere CDC last. See also: To change the refresh order of tables
To change the refresh order of tables

1. Ensure that you have ended any active replication on the subscription. 2. When setting up tables that have referential integrity constraints, ensure that the target tables are empty before starting replication. 3. Click Configuration > Subscriptions. 4. Select the subscription that contains the mapped source and target tables. 5. Select a table mapping in the Table Mappings view. 6. Right-click and select Refresh Order.... to create the groups you need. 7. Click Grouped tables are refreshed first, in the order they are specified. All other tables are refreshed after grouped tables. 8. Select one or more tables from the Ungrouped Tables list. 9. Select the group to which you want to move the selected tables and click Related concepts Changing the refresh order of tables on page 349 Selecting a new journal table on page 351 Ending replication on page 361 .
Changing the replication method of a table

Your subscription can contain table mappings that have a combination of replication methods: Mirror or Refresh. You can change the replication method of one or more of your table mappings within a subscription. Before you can change the replication method, if you are mirroring the source table to the target, then you need to end replication on the subscription. See also: To change the replication method of a table Related concepts Starting mirroring on page 356 Ending replication on page 361
To change the replication method of a table

1. Ensure that you have ended any active replication on the subscription. 2. Click Configuration > Subscriptions. 3. Select the subscription that contains the mapped source and target tables. 4. Select the table mapping in the Table Mappings view. 5. Right-click and click Change Replication Method. 6. Select one of the following options: v Mirror (Change Data Capture)Immediately replicates changes made to the source table to the target table or accumulate source table changes and
350
replicate at a later time. If your configuration requires you to prevent recursive updates when mirroring, enable the Prevent Recursion check box. v Refresh (Snapshot)Replicates a snapshot of the source table to the target table. Note: If you are replicating your source table using InfoSphere CDC for Oracle databases (trigger) and decide to change the replication method from Mirror to Refresh, then InfoSphere CDC disassociates the journal table from the source table. This was the journal table you had selected in the Map Tables wizard. After InfoSphere CDC completes the refresh operation on the subscription, if you want InfoSphere CDC to continue mirroring changes from this source table using the same journal table, then you must change the replication method back to Mirror and select the same journal table you were using before. v Prevent RecursionPrevents InfoSphere CDC from replicating changes back to the source database when you have configured a subscription for bidirectional replication. This is only available in versions of InfoSphere CDC that support both source and target databases. Contact IBM Support to implement bidirectional replication in your environment. v Use Relative Record NumberEnables InfoSphere CDC to replicate updates to the target using a relative record number. When this option is checked, InfoSphere CDC sends the Relative Record Number to the target and expects the Relative Record Number to be the identifying column on the target side. This means that the target tables cannot be updated by more than one source table (a target table cannot be a warehouse for multiple source tables). If you do not check this box, then InfoSphere CDC for DB2 for i uses a unique key to replicate to the target. Notes: When this option is checked, if the source table is reorganized, InfoSphere CDC Event Server will automatically start a refresh for that table. If no Relative Record Number is available on the target table (for example, if the table resides on a non-IBM i system), you can still make use of this option by mapping the Relative Record Number on the source table to a column in the target table to. For more information, see Source RRN (&CNTRRN) on page 198. This option is only available when using an InfoSphere CDC for DB2 for i source. Related tasks To set propagation control on a subscription on page 54
Selecting a new journal table

InfoSphere CDC for Oracle databases (trigger) uses journal tables to detect and replicate database changes to the target table. If you have mapped your source and target tables and have enabled Mirror (Change Data Capture) in the Map Tables wizard, then you have already selected a journal table. InfoSphere CDC creates this table and uses it to track the database operations that occur on your source system. Each time there is a new row-level operation on your source table, a trigger executes in response to the database operation and InfoSphere CDC reads the journal table to identify the database operation that occurred. InfoSphere CDC then scrapes the database operation from the journal table and replicates it to the target.
351
If you want to change the journal table you had selected in the Map Tables wizard, then you must change the replication method to Refresh so that InfoSphere CDC can disassociate the journal from the source table. You can then change the replication method back to Mirror and select a new journal table that you want InfoSphere CDC to use. See also: To select a new journal table
To select a new journal table

1. 2. 3. 4. Ensure that you have ended replication on the subscription. Click Configuration > Subscriptions. Select the subscription that contains the mapped source and target tables. Select a table mapping.
5. Right-click and select Change Replication Method. 6. Select Refresh. This disassociates the journal table from the source table. If you are using this same source table in other subscriptions, then you must set the replication method to Refresh for these subscriptions as well. InfoSphere CDC disassociates the journal table from the source table in each subscription. 7. Click OK. The table mapping should have a replication method and status of Refresh/Refresh. 8. Select the same table mapping and click Change Replication Method. 9. Select Mirror. This lets you select a new journal table. 10. Select one of the following options and click OK. v Use Default JournalEnable when you want InfoSphere CDC for Oracle databases to use the default journal table provided with InfoSphere CDC for Oracle databases: <TS SCHEMA>.DMCJRN. InfoSphere CDC uses this journal table to detect and replicate database changes from the source to the target. v Use Selected JournalEnable when you want InfoSphere CDC for Oracle databases to use another journal table other than the default journal table provided with InfoSphere CDC for Oracle databases. When you select the database owner and provide a name for the journal table, InfoSphere CDC for Oracle databases creates this new journal table and uses it to detect and replicate database changes from the source to the target. OwnerLists the database owner of the journal table. NameLists the name of the journal table.
352
Related concepts Ending replication on page 361 Selecting a new journal table on page 351 Mapping tables on page 83
Setting members for replication

IBM i environments supports a table concept known as multi-member files, in which one table can possess several different members. Each member is part of the same table and shares the same schema, but the members are uniquely named and have unique data. If you have installed InfoSphere CDC for IBM i and have multi-member source tables, then you can select the members you want InfoSphere CDC to replicate. See also: To select a member for replication
To select a member for replication

1. Ensure that you have ended replication on the subscription. 2. Click Configuration > Subscriptions. Select the subscription that contains the mapped source and target tables. Select a table mapping. Right-click, click Set Member Replication. You can choose from one of the following: v All current and future membersEnables InfoSphere CDC to replicate all members, including members you may add a future point in time. v Selected members onlyEnables InfoSphere CDC to only replicate the members you selected. Related concepts Setting members for replication 3. 4. 5. 6.
Changing the message destination

This option is only available for subscriptions that use InfoSphere CDC Event Server as the target datastore. You can change the JMS message destination of a table mapping. See also: To change the message destination of a table
To change the message destination of a table

1. Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC Event Server datastore. 2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select a subscription that contains the table mapping to a message destination. 4. Select the table mapping in the Table Mappings view. 5. Right-click and select Message Destination.
353
6. Select the new message destination and click OK. Related concepts Changing the message destination on page 353
354
Starting and ending replication

With InfoSphere CDC you can mirror data from source tables (using Change Data Capture replication) that are mapped to target tables in Management Console. InfoSphere CDC provides two types of mirroring: Continuous and Scheduled End (Net Change). 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: v Current time or Now v User-specified date and time v User-specified log position These user specified end points ensure that your target database is in a known state when replication ends. 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. 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 options: v Current time or Now v User-specified date and time v User-specified log position 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. You can also refresh all tables or a subset of tables in your subscription depending on your business requirements. A refresh sends a complete copy of data in a source table to the target table and overwrites any existing rows in the target table. Unlike mirroring, a refresh operation with InfoSphere CDC does not require additional database logging which reduces the workload of your source database.
355
Operational tasks such as starting and ending replication and starting a refresh are normally performed in the Monitoring perspective in Management Console and require Monitor role privileges. Configuration tasks for replication such as flagging tables for refresh, setting or changing the replication method, marking the table capture point, and parking tables are performed in the Configuration perspective of Management Consoled and require Administrator role privileges for read and write access and Operator role privileges for read-only access. In this section, you will learn: Starting mirroring Starting a refresh on a subscription on page 358 Ending replication on page 361 Sending XML messages to a JMS message destination on page 363
Starting mirroring
InfoSphere CDC provides two types of mirroring for source tables that are mapped to target tables: Continuous and Scheduled End (Net Change). The type of mirroring you select depends on your business needs. For both types of mirroring, before Management Console starts mirroring, it provides the following warnings: v The number of tables that will be refreshed before mirroring. This is informational. v The number of parked tables that will not be mirrored. This is informational. v Whether source tables are not mapped. This indicates incomplete mapping. InfoSphere CDC cannot start subscriptions that are not completely mapped. Ensure that all tables that you want to mirror are properly mapped. 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. Continuous mirroring is appropriate when your business processes require the source and target to be synchronized at all times. Continuous mirroring is also useful if your environment experiences frequent changes to large volumes of data. Instead of capturing these changes using a batch transfer, you can replicate changes to the target on a continuous basis. Scheduled End (Net Change) mirroring replicates changes (to the target) up to a user-specified point in the source database log and then ends replication. Use this type of mirroring when business requirements dictate that you only replicate your data periodically and you have a clearly defined end point for the state of your target database when replication ends. Scheduled End (Net Change) mirroring allows you to end replication at the following points in your source database log: v Current time or Now v User-specified date and time v User-specified log position These user specified end points ensure that your target database is in a known state when replication ends.
356
For example, if you start Scheduled End (Net Change) mirroring and specify a time of 12 PM, InfoSphere CDC will continue mirroring all changes that have been committed to the target until 12 PM in the source database log. At this point, mirroring will end. You can also reschedule the Scheduled End (Net Change) mirroring to a new time or log position if business reasons warrant. See also: To start continuous mirroring To start scheduled end (net-change) mirroring Related concepts Mapping tables on page 83
To start continuous mirroring

1. Ensure that the subscription has at least one table mapping with replication method set to Mirror. You can set the replication method in the Configuration perspective and also when you map tables in the Map Tables wizard. 2. Click Monitoring > Subscriptions. 3. If the subscription is available for editing, right-click one or more subscriptions and select Start Mirroring. Refresh Details is displayed if you have one or more tables flagged for refresh and allows you to view the refresh configuration of these tables. Continuous mirroring will not start until the refresh of these tables is complete. 4. Select Continuous and click OK to start mirroring. Mirroring will continue until you end replication. Related concepts Starting mirroring on page 356 Related tasks To start scheduled end (net-change) mirroring To flag a source table for a Standard Refresh on page 345
To start scheduled end (net-change) mirroring

1. Ensure that the subscription has at least one table mapping with replication method set to Mirror. You can set the replication method in the Configuration perspective and also when you map tables in the Map Tables wizard. 2. Click Monitoring > Subscriptions. 3. If the subscription is available for editing, right-click one or more subscriptions and select Start Mirroring. Refresh Details is displayed if you have one or more tables flagged for refresh and allows you to view the refresh configuration of these tables. Scheduled End (Net Change) mirroring will not start until the refresh of these tables is complete. 4. Depending on your version of InfoSphere CDC, choose one of the following options. InfoSphere CDC version 6.5: v Scheduled EndInfoSphere CDC mirrors all committed database changes in the source database and then ends replication normally at the indicated point.
357
NowInfoSphere 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. The source system time when replication will end is set when you click OK. Specific Date/TimeInfoSphere CDC mirrors all committed database changes in the source database and then ends replication normally at the specified date and time in your source system database log. The current Coordinated Universal Time (UTC) offset (in minutes) of your InfoSphere CDC source system is displayed as a hint. Specific Log PositionInfoSphere CDC mirrors all committed database changes in the source database and then ends replication normally at the specified log position in your source database log. The format of a valid log position for this subscription is displayed as a hint. This option is only available for supported source datastores. InfoSphere CDC version 6.3 and earlier: v Scheduled End (Net Change)InfoSphere CDC will continue mirroring up until the current source system time in the database log and then end replication. The source system time when replication will end is set when you click OK. 5. Click OK to start Scheduled End (Net Change) mirroring. After starting Scheduled End (Net Change) mirroring, you also have the option of rescheduling the end of replication to a more suitable time or log position if business reasons warrant. Related concepts Starting mirroring on page 356 Related tasks To start continuous mirroring on page 357 To flag a source table for a Standard Refresh on page 345
Starting a refresh on a subscription

The InfoSphere CDC refresh operation is designed to synchronize source and target tables. Tables can become out of synchronization for various reasons, including the following issues: v Parked tablesParking a table from replication for some time to make changes (such as updating the definition of a source table) and the changes that are taking place on the source are no longer being replicated. This may cause the target table to become inconsistent with the source table. v Configuration changesA refresh may be necessary when a set of subscriptions are promoted from a test environment to a production environment. The promotion operation may add new transformations or other table mapping changes which require the source and target tables to be refreshed in order to prepare for mirroring. v Maintenance operationsLarge bulk SQL operations performed during maintenance windows on the source table which affect a majority of the rows may be faster to resynchronize using refresh. Refresh may be faster than mirroring to replicate millions of changes due to the ability to bulk load rows into the target database.
358
When you have a subscription that contains a target table that is not synchronized with the source table, you can flag the source table for a refresh. Tables that are flagged for refresh and have a replication method of Mirror will be refreshed before mirroring begins. InfoSphere CDC will refresh all of the flagged tables within a single subscription as one sequential operation which will run to completion. Each table is refreshed individually one at a time until all flagged tables have finished refreshing. Refresh is an operation which applies to a single subscription, so while one subscription is refreshing other subscriptions are not affected; they may continue mirroring data for different tables or refreshing tables as required. To perform a parallel refresh, multiple subscriptions can be used. Rule-based tables are not part of a refresh. Within Management Console, when you start a refresh, you will see a warning to indicate that tables selected by rules will not be refreshed. InfoSphere CDC offers two types of refresh operations: Standard Refresh and Differential Refresh. A Standard Refresh results in a complete copy of the data in a source table being sent to the target table. This operation truncates or deletes the contents of the target table and then inserts the new contents as sent by the source system. A Differential Refresh updates the target table by applying only the differences between it and the source table. Instead of the target table being cleared at the start of the refresh and repopulated with data, as with the Standard Refresh, the Differential Refresh compares each row in the target table with each row in the source table to identify missing, changed or additional rows. The primary advantage of the Differential Refresh is that the target table stays online during the refresh operation. There are three possible methods for the Differential Refresh: v Refresh OnlyPerforms a Differential Refresh by changing any target rows that differ from the source rows. v Refresh and Log DifferencesPerforms a Differential Refresh, and also creates a log table in the target replication engine metadata to track all changes during the refresh. The log table is identical to the target table, with the addition of a column to indicate the actions taken during the refresh, such as inserting a row, deleting a row, or updating a row. For an update, both the source and target row images are logged. This log table is created in the same database and tablespace as the TS_CONFAUD table (or DMMD_DMCONFAUD table for InfoSphere CDC for z/OS), with the same owner as the metadata. The name of the log table is created by combining the subscription name, the target table name, and the refresh start date and time. v Only Log DifferencesCreates and populates a log table in the target replication engine metadata to identify all differences between the source and target tables. The target table is not updated. This allows you to evaluate what the differences are between the target and the source. If you then decide to refresh the table, you can go back to the subscription and select Refresh Only to update the target table or update the target table manually based on the contents of the log table. Performing a Differential Refresh has some requirements and restrictions: v Differential refresh is only available for tables that use Standard replication
359
v The collation sequence of the source and target tables must be identical v Derived columns on the source table are not supported v Any target columns which are mapped to derived expressions, constants or journal control fields will be ignored v The key columns of the target table must be mapped directly to columns on the source table. v The target table must have a unique key, either a primary key or a unique index with at least one non-nullable column. Both a Standard Refresh and Differential Refresh can be further refined through the use of a SQL WHERE clause to only include rows within a specified range. This is useful for tables where only the most recent data requires a refresh. If you want to refine the refresh through the use of a SQL WHERE clause, then the Row Subset feature requires one of the following conditions be met: v The table capture point has been set, either explicitly or through the table having been mirrored in Management Console v The scraping point for the subscription has been set (using the SETLOGPOS command or dmsetbookmark command where applicable) The order in which data is retrieved from the database during a refresh depends on the type of refresh performed. During a Standard Refresh, no ORDER BY sort is used; the database determines the order in which the data is returned. During a Differential Refresh, InfoSphere CDC queries the database using an ORDER BY sort on the table keys chosen in the table mapping to sort the source and target tables and determine their differences. When a refresh is performed with multiple tables, the order in which each individual table is refreshed is based on the group order, as set in Refresh Order option. If no Refresh Order is set, then tables are refreshed in alphabetical order. After a refresh has successfully completed, the subscription can be restarted for mirroring. InfoSphere CDC will then process the backlog of changes. For tables which weren't refreshed InfoSphere CDC will continue processing changes from the position where mirroring ended. For tables which were refreshed, InfoSphere CDC will process all the changes that committed after refresh began for that table. See also: To start a refresh Related concepts Promoting subscription changes on page 377 Flagging a source table for refresh on page 343 Changing the refresh order of tables on page 349
To start a refresh
1. Stop mirroring on any active subscriptions that will have tables refreshed. 2. Ensure that the tables to be refreshed have been flagged for refresh. 3. Click Monitoring > Subscriptions. 4. If the subscription is available for editing, right-click one or more subscriptions and select Start Refresh. The Start Refresh dialog shows all tables in the selected subscriptions that have been flagged for refresh
360
5. If you want to view the refresh details for a specific table, select it and click Refresh Options. If multiple table mappings were selected, any enabled row constraints will not be displayed on the Refresh Options dialog. 6. Click OK. Related concepts Controlling the apply of refresh operations on page 213
Ending replication
Ending replication allows you to prepare for transitional activities in your business environment and allows you to move to the next step in your business processes. Here are some examples of transitional activities in your business environment that may require an end to replication: v Initiating a database backup. v Performing a regularly scheduled reboot of your source database server. v Quiescing your database in preparation for an upgrade. v Weekly batch processing has just completed. v Preparing for off-line maintenance activities. If you are replicating data continuously with Continuous mirroring and business reasons arise that require an end to replication, InfoSphere CDC provides multiple options that suit most business needs. If your business requirements dictate that replication must end at a particular point in your source database log because the target database must be in a known state when replication ends, you can choose from the following options: v Current time or Now v User-specified date and time v User-specified log position An example of a scenario that might require these options is that you are populating a reporting instance and you need stable (non-changing) data in your reporting instance during the day. At the end of the day when you shut down your application, you can choose one of the Scheduled End (Net Change) options to update the reporting instance with data from the current day as well. If business requirements do not require a specific end point but do require a time frame for ending replication, InfoSphere CDC provides escalating options (Normal, Immediate, and Abort) that end replication more rapidly at the expense of a slower start when resuming replication. For example, a routine end to replication with no particular urgency may require the Normal option, whereas a sudden business need to end replication rapidly may require the Abort option. A routine reboot of a SAN might be appropriate for the Normal option, whereas a sudden and unexpected hardware or application failure may require the Abort option. If you initiate an end to replication and business reasons warrant a change in the desired time frame, you can reschedule the end of replication by specifying a new date and time, a new position in the database log, or choose another option for ending replication. Ending replication is also necessary if you want to update and make changes to your subscription by: v Adding a table mapping to the subscription.
361
v Deleting a table mapping from the subscription. v Temporarily removing a table mapping from the subscription (parking a table). v Modifying mapping details such as source and target column mappings, derived columns, data translations, row and column selections, user exits, and so on. v Updating the properties of a subscription when the structure of your source and/or target tables change. See also: To end replication
To end replication
1. Click Monitoring > Subscriptions. 2. If the subscriptions are available for editing, right-click one or more subscriptions and select End Replication. 3. Depending on your version of InfoSphere CDC, choose from the following options. InfoSphere CDC version 6.5: v NormalInfoSphere CDC 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. v ImmediateInfoSphere CDC stops all in progress work and then ends replication. Starting replication after using this option can be slower than using the Normal. 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. This recommendation does not apply to InfoSphere CDC for z/OS. Attention: Use this option if business reasons require replication to end faster than Normal at the expense of a slower start when you resume replication on the subscription. v AbortInfoSphere CDC stops all in progress work and then ends replication rapidly. Starting replication after using this option can be much slower than the Normal. 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. This recommendation does not apply to InfoSphere CDC for z/OS.
362
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 subscription. A sudden business requirement for an unplanned shutdown of your source system may require this option for ending replication. v Scheduled EndThis option will process all committed database changes in the source database and then end replication at the indicated point with the Normal option. This option is not available if all the tables in a subscription are currently refreshing. NowEnd replication at the current source system time in your source database log. The source system time when replication will end is set when you click OK. Specific Date/TimeEnd replication with the Normal option at the specified date and time. InfoSphere CDC displays the UTC offset (in minutes) of the source database. Specific Log PositionEnd replication with the Normal option at the specified log position. InfoSphere CDC displays the format of the log position for the source datastore. This option is only available for supported source datastores. InfoSphere CDC version 6.3 and earlier: v ControlledInfoSphere CDC completes all in-progress operations and applies pending changes to the target table. v ImmediateInfoSphere CDC interrupts any in-progress operations and does not apply pending changes to the target table. 4. Click OK. If business reasons warrant a change in the desired time frame for replication to end (faster or slower), 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. Note: As latency between the source and target increases, the amount of time required to end replication will also increase.
Sending XML messages to a JMS message destination

For InfoSphere CDC Event Server to send the XML message to a JMS message destination, you must start mirroring on the subscription that contains the table mapping. When you start mirroring on the subscription, InfoSphere CDC Event Server sends a complete copy of all the rows in your source table to the JMS message destination, to the staging target table, or both. The subscription stays active and waits for additional events to occur on the source table. See also: To send an XML message to a JMS message destination or a staging target database
To send an XML message to a JMS message destination or a staging target database

363
2. Click Configuration > Subscriptions. Ensure that you have created a subscription that uses the InfoSphere CDC Event Server datastore as the target. 3. Select the subscription that contains the table mapping to a message destination, a staging target table, or both. 4. Click the Table Mappings view and select the table mapping. Ensure that you have set the replication method for this table mapping to Mirror (Change Data Capture). 5. Click Monitoring > Subscriptions. 6. Select the subscription that contains the table mapping, right-click Start Mirroring. If this is the first time you are starting replication, InfoSphere CDC Event Server sends a copy of all the rows to your message destination, staging target table, or both. After this is complete, it switches to Mirror Continuous. Related concepts Sending XML messages to multiple JMS message destinations on page 240 Related tasks To create an XML message on page 331
364
Setting notifications
You can use notifications when you want to be alerted of any problems in your replication environment. Notifications are most useful when performing diagnostic analysis of replication activities in Management Console and you want to detect events that are happening in your source datastores, target datastores and subscriptions.
Setting notifications for datastores and subscriptions

You can set notifications so that they are sent from either a source or target datastore, or set notifications so that they are sent from a subscription. When you set a notification on the datastore, the InfoSphere CDC loads these as default notification settings across all subscriptions that use that datastore. This means that each subscription that uses the datastore for replication inherits the notification settings by default. Setting notifications at the datastore level is useful when you want to set the same notifications for all your datastores regardless of which subscriptions use them. However, if you have a subscription that uses the same datastore in some special way, then you can set the notification at the subscription level. Set notifications from the datastore before setting notifications from each subscription. This is to help you during diagnose and track the location of your notifications.
Filtering notifications
You can filter notifications. When an event occurs in your replication environment, InfoSphere CDC generates messages in the Events area of the Subscriptions view of the Monitoring perspective. Each message is identified with an event ID. Using the event ID, you can specify the messages for which you want to be notified or those which should be suppressed. For example, if you want to be notified when mirroring fails on a subscription, you can specify the event ID for that message in the Filter Messages dialog box.
Copying notifications
You can copy notification settings to notification categories in the same datastore or subscription. Email notification settings include information such as the name of the person to which you send a notification or the subject line of an e-mail. You can copy this information to other notification categories in the same datastore. For example, you may have already set an e-mail notification that gets sent to john_smith@ibm.com when the datastore DM0001@50000 on the source-side detects a fatal communications error on the network. You may have set other notifications that get sent in different events, but want all those notifications sent to the same account. Instead of having to manually specify that john_smith@ibm.com receive all notifications detected from DM0001@50000 in each notification, you can copy this setting to other notification categories. Before you setup an e-mail notification for MAPI, you should read the considerations outlined for these protocols in your InfoSphere CDC for Microsoft SQL Server documentation.
365
Setting latency thresholds and notifications

You can also set latency notifications that alert you when InfoSphere CDC has passed your warning or problem thresholds. You must specify a threshold before you can set up a notification. In this section, you will learn: Selecting a notification handler Choosing a notification category and a message type on page 367 Setting notifications for a datastore on page 368 Setting notifications for a subscription on page 373 Copying notifications for a subscription on page 374 Setting latency thresholds and notifications on page 374
Selecting a notification handler

Before setting up a notification, you need to decide on the kind of notification handler you want to use to receive notifications. Notification handlers specify how you want a certain notification to be handled. You can set a notification so that it is handled through e-mail, message queues, or user exits. For example, you may want to send messages to an e-mail address, relay a message to a message queue, or you may prefer to set up a user exit that triggers certain operations upon specific InfoSphere CDC events. Depending on the InfoSphere CDC product you have installed, you can select certain notification handlers in the Notifications dialog box: v Message QueueYou can indicate that you want to relay a message to a specified message queue when a certain type of message is generated. You have the option of relaying that message to up to ten different message queues. To specify a message queue, you need to specify both the name of the message queue and the library where it resides. v User Exit/User HandlerYou can indicate that you want to launch a user exit program when a certain type of message is generated. Note that you are responsible for creating the user exit program and ensuring that it works properly. For more information about creating user exit programs for alerts and alarms, see the appropriate InfoSphere CDC End-User Documentation. v EmailYou can indicate that you want to send the generated message to an e-mail address. Depending on the type of datastore, SMTP (Simple Mail Transfer Protocol) and MAPI (Messaging Application Program Interface) can be used for sending e-mail messages. Unless explicitly stated, each setting described below applies to both SMTP and MAPI. v Event LogYou can indicate that you want to send the generated message to the Windows application log. v CHCPRINTYou can indicate that you want to send the generated message to the CHCPRINT spool file provided with InfoSphere CDC for z/OS.
SYSLOG
v DB2 UDB for z/OSYou can indicate that you want to send the generated message to the operator system log maintained on zSeries servers. For more information about the operator system log, see the InfoSphere CDC for z/OS End-User Documentation.
366
v Oracle (on UNIX servers only)You can indicate that you want to send a generated message to the UNIX syslogd program that logs messages from external applications like InfoSphere CDC Related concepts Setting notifications for a datastore on page 368 Setting notifications for a subscription on page 373
Choosing a notification category and a message type

When setting up a notification, you must select a notification category and a notification message type.
Notification categories
Notification categories represent the events that InfoSphere CDC detects in your source and target datastores. v Scrape/Refresh Events (Source)Categorizes notifications that are generated for events that occur when InfoSphere CDC scrapes or refreshes data from your source datastore. v Apply Events (Target)InfoSphere CDC generates notifications related to events that occur during the target apply process. For example, InfoSphere CDC can generate a message when there is failure to apply on the target table. v Communications EventsCategorizes notifications that are generated for communication events that can occur between source and the target datastores. For example, InfoSphere CDC can generate a message when there is a failure to create TCP/IP socket. v Environment EventsCategorizes notifications that are generated when requirements for a basic replication environment are not met. For example, InfoSphere CDC can generate a message when it cannot connect to a database, or when permissions have not been set. v Journal/Log Maintenance EventsCategorizes notifications that are generated when InfoSphere CDC reads the journal or during log maintenance.
Notification message type

v Fatal MessagesEnables you to setup a notification for fatal messages. For example, InfoSphere CDC can generate a fatal message in the Events area of the Subscriptions view of the Monitoring perspective when it cannot open or find a metadata table, or when it encounters a communication error between datastores. v Error MessagesEnables you to setup a notification for error messages. InfoSphere CDC sends a notification when it encounters an error. For example, InfoSphere CDC can generate an error message in the Events area of the Subscriptions view of the Monitoring perspective when it inserts a row and creates a duplicate key, or when it encounters a runtime verification error on a derived expression. v Informational MessagesEnables you to setup a notification for informational messages. InfoSphere CDC sends a notification when it encounters an event that you need to know about. For example, InfoSphere CDC can generate informational messages in the Events area of the Subscriptions view of the Monitoring perspective when it is ready to mirror tables, or when it encounters instances that require code page conversions. v Status MessagesEnables you to setup a notification for status messages. InfoSphere CDC sends a notification when it encounters a specific event during
367
replication. For example, InfoSphere CDC can generate status messages in the Events area of the Subscriptions view of the Monitoring perspective when it is going to refresh a table, when it cannot journal changes on a table, or when it has parked a table for replication. v Operational MessagesEnables you to setup a notification for operational messages. InfoSphere CDC sends a notification when it has completed an operation during replication. For example, InfoSphere CDC can generate operational messages in the Events area of the Subscriptions view of the Monitoring perspective after applying an operation to the target table, or when it has completed a refresh on a table. Related concepts Setting notifications for a datastore Setting notifications for a subscription on page 373
Setting notifications for a datastore

Use the Source tab or the Target tab in the Notifications dialog box to set up a notification. InfoSphere CDC can generate messages for events that occur on either your source or target datastore. See also: To set an e-mail (MAPI) notification To set an email (SMTP) notification on page 369 To set an e-mail notification (InfoSphere CDC for Oracle) on page 369 To set an e-mail notification on page 370 To set a notification for the CHCPRINT spool file on page 370 To To To To To To set set set set set set a a a a a a notification notification notification notification notification notification for an operator system log on page 370 for a UNIX system log on page 371 using a user exit program on page 371 using a user exit program on page 371 using a user exit program on page 372 for a message queue on page 372
To filter a notification message on page 373
To set an e-mail (MAPI) notification

Note: This task is only applicable if you are connected to an InfoSphere CDC for Microsoft SQL Server version 5.3 datastore. 1. Verify your version of InfoSphere CDC. 2. Click Configuration > Datastores. 3. Right-click on a datastore and select Notifications. 4. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 5. Select a category from Notification Categories. 6. Select Email (MAPI). 7. Enter the e-mail address in the Alert Account box. Use a semicolon to separate multiple e-mail addresses or specify a distribution list from your e-mail application. 8. Enter the subject in theSubject box.
368
9. Enter the name of the mail profile you created to identify the mailbox of the specific domain user in theProfile box. The subject and profile name cannot exceed 254 characters. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
To set an email (SMTP) notification

Note: This task is only applicable if you are connected to an InfoSphere CDC for Microsoft SQL Server version 5.3 datastore. 1. Verify your version of InfoSphere CDC. 2. Click Configuration > Datastores. 3. Right-click on a datastore and select Notifications. 4. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 5. Select a category from Notification Categories. 6. Select Email (SMTP). 7. Enter the email address that will receive the e-mail in the Alert Account box. Use a semicolon to separate multiple e-mail addresses or specify a distribution list from your email application. 8. Enter the host name of your outgoing mail server in the SMTP Mail Host box. 9. Enter the e-mail address that will send the generated messaged in the Sender Account box. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
To set an e-mail notification (InfoSphere CDC for Oracle)

Note: This task is only applicable if you are connected to an InfoSphere CDC for Oracle datastore. 1. Click Configuration > Datastores. 2. Right-click on a datastore and select Notifications. 3. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 4. Select a category from Notification Categories. 5. Select the Email box. 6. Enter the e-mail address in the Address box. Use a semicolon to separate multiple e-mail addresses or specify a distribution list from your e-mail application. 7. Enter the subject in the Subject box. The subject cannot exceed 254 characters.
369
Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
To set an e-mail notification

Note: This task is only applicable if you are connected to an InfoSphere CDC for DB2 LUW datastore, InfoSphere CDC for Microsoft SQL Server version 6.0 datastore, or an InfoSphere CDC for Teradata datastore. 1. Click Configuration > Datastores. 2. Right-click on a datastore and select Notifications. 3. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 4. Select a category from Notification Categories. 5. Select the INTERNET MAIL box. 6. Enter the host name of your outgoing mail server in the SMTP Mail Host box. 7. Enter the e-mail address that you want to notify in the Alert Account box. Use a semicolon to separate multiple e-mail addresses or specify a distribution list from your e-mail application. 8. Enter your e-mail address in the Sender Mail Address box. 9. Enter your e-mail password in the Sender Mail Password box. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
To set a notification for the CHCPRINT spool file

1. Click Configuration > Datastores. 2. Ensure that you are connected to an InfoSphere CDC for z/OS datastore. 3. Right-click on a datastore and select Notifications. 4. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 5. Select a category from Notification Categories. 6. Select the CHCPRINT box. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
To set a notification for an operator system log

1. Click Configuration > Datastores. 2. Ensure that you are connected to an InfoSphere CDC for z/OS datastore. 3. Right-click on a datastore and select Notifications. 4. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 5. Select a category from Notification Categories. 6. Select the SYSLOG box.
370
To set a notification for a UNIX system log

1. Contact your UNIX system administrator to find out how many log channels are configured in your environment. This program supports up to eight log channels and identifies different locations where you can place messages. You can configure log channels using a predefined configuration file (/etc/syslog.conf). 2. Click Configuration > Datastores. 3. Ensure that you are connected to an InfoSphere CDC for Oracle datastore. 4. Right-click on a datastore and select Notifications. 5. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 6. Select a category from Notification Categories. 7. Select the Syslog box. 8. Enter the number of the log channel in the Facilities box. Routes messages to the location specified in the configuration file (/etc/syslog.conf). The number must be between 0 and 7 and it corresponds to the number specified in the configuration file. 9. Enter a string in the ID box. Appends to all messages routed through the log channel. You can attach an identifier for each message. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
To set a notification using a user exit program

Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC for z/OS datastore. Right-click on a datastore and select Notifications. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 5. Select a category from Notification Categories. 6. Select the USER HANDLER box. 7. Enter the name of the module in the box. Related concepts 1. 2. 3. 4. Setting notifications on page 365 Selecting a notification handler on page 366

1. Click Configuration > Datastores. 2. Ensure that you are connected to an InfoSphere CDC for IBM i datastore. 3. Right-click on a datastore and select Notifications.
371
4. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 5. Select a category from Notification Categories. 6. Select the USER HANDLER box. 7. Enter the name of the user exit program in the Program box. 8. Enter the name of the library in the Library box. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366

1. Click Configuration > Datastores. 2. Ensure that you are connected to an InfoSphere CDC for DB2 LUW datastore, an InfoSphere CDC for Microsoft SQL Server version 6.0 datastore, an InfoSphere CDC for PointBase datastore, or an InfoSphere CDC for Teradata datastore. 3. Right-click on a datastore and select Notifications. 4. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 5. Select a category from Notification Categories. 6. Select the USER HANDLER box. 7. Enter the fully qualified Java class name of the user exit program in the Java Class Name box. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
To set a notification for a message queue

Click Configuration > Datastores. Ensure that you are connected to an InfoSphere CDC for IBM i datastore. Right-click on a datastore and select Notifications. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 5. Select a category from Notification Categories. 6. Select the Message Queue box. 7. Enter the name of the message queue in the Queue box. You can relay the same message up to 10 message queues. 1. 2. 3. 4. 8. Enter the name of the library in the Library box.
372
To filter a notification message

Click Configuration > Datastores. Right-click on a datastore and select Notifications. Click Filter Messages. Enter the event ID in the box. If messages are sent from InfoSphere CDC for IBM i, use the full IBM i message ID when specifying this event ID. 5. Select one of the following: v Do not send these messagesDoes not send the specified messages. 1. 2. 3. 4. v Send these messages onlySends the specified messages. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
Setting notifications for a subscription

If you want to send a notification only when a datastore is used by a subscription, then you can set notifications at the subscription level. Before setting a notification for a subscription, you should do the following: v View any default notifications that were set at the datastore level for the subscription. v Decide what kind of events you want to be notified about in your replication environment. When setting notifications you must first identify the category of the message you want to set, and then decide on a severity level. See also: To set notifications for a subscription To view the datastore default notifications for a subscription on page 374
To set notifications for a subscription

1. Click Configuration > Subscriptions. 2. 3. 4. 5. 6. Right-click on a datastore and select Notifications. Click the Source tab or the Target tab. Select a category from Notification Categories. Clear any default notifications settings to enable the Notification Settings area. Specify how you want to send this notification in the Notification Settings area. Depending on the InfoSphere CDC product you have installed, you can send this notification through e-mail message queues, or a user exit program.
373
Related concepts Setting notifications for a subscription on page 373
To view the datastore default notifications for a subscription

1. Click Configuration > Subscriptions. 2. Right-click on a datastore and select Notifications. 3. Depending on whether you want InfoSphere CDC to detect events on the source datastore or on the target datastore, click the Source tab or the Target tab. 4. Click Datastore Defaults. The Notifications dialog box opens and displays the default notifications that were set for the datastore. Related concepts Setting notifications for a subscription on page 373
Copying notifications for a subscription

You can copy notification settings from one category to another in the same subscription. For example, e-mail notification settings include information such as the name of the person to which you send a notification, or you can copy the subject line of an email between different notification categories on a subscription. See also: To copy notification settings
To copy notification settings

1. Click Configuration > Datastores. 2. Right-click on a datastore and select Notifications. 3. Click Source or Target. 4. Select the notification setting. 5. Click Copy Settings. 6. Clear the boxes for the notifications that you do not want to copy. If you want to copy all notification settings, click OK. Related concepts Setting notifications on page 365 Selecting a notification handler on page 366
Setting latency thresholds and notifications

You can set a notification that specifies the latency (in minutes) of a subscription. This notification specifies how long it takes InfoSphere CDC to apply data to the target datastore. You must set latency thresholds before you can set a notification. When you set a notification, InfoSphere CDC sends you a notification after the following events: v NormalLatency for the journal or log is below the warning threshold. This means that latency is acceptable and within your normal range. Latency is normal according to the latency thresholds you have set for the subscription.
374
v WarningLatency for the journal or log is above the warning threshold but below the problem threshold. Latency is starting to become a problem according to the latency thresholds you have set for the subscription. v ProblemLatency for the journal or log is above the problem threshold. Latency is now a problem according to the latency thresholds you have set for the subscription. See also: To set a latency threshold and notification
To set a latency threshold and notification

1. 2. 3. 4. 5. Click Configuration > Subscriptions. Right-click on a subscription and select Latency Thresholds. Enable the Notify when latency crosses these thresholds check box. Specify a warning threshold (in minutes). Specify a problem threshold (in minutes). The problem threshold must be greater than the warning threshold. 6. Click Set Notification.
7. As a best practice, ensure that Target > Apply > Informational is enabled. You must configure at least one notification setting in the Informational category so that you can receive notification messages and this must be set on the Target tab. These changes will take effect the next time you start replication on this subscription. 8. Specify how you want to send this notification in the Notification Settings area. Depending on the InfoSphere CDC product you have installed, you can send this notification through e-mail message queues, or a user exit program. Related concepts Setting latency thresholds and notifications on page 374
375
376
Promoting subscription changes

Promotion is the process in Management Console by which you can develop, modify, and move configuration details in subscriptions from your development environment to your test environment then to your production environment. If your organization has implemented a succession of development stages, then you may want to test your subscriptions before making them available in your production environment. The Promote Subscription wizard promotes the configuration details you set for your table mapping in the Mapping Details area of Management Console to the new environment. When you are finished promoting your changes, the subscription is relocated into the new environment and uses new source and target datastores. The Promote Table Mappings wizard allows you to promote selected table mappings in a subscription rather than all table mappings. You may have an existing subscription created in a previous version of Management Console that you need to promote into Management Console 6.5 and require that the subscription use auto-encoding mode. You must first allow Management Console to create the new subscription using the Promote Subscription wizard and choose the Promote to a new subscription option. After promoting subscription details to the new subscription, you can then convert the subscription to use auto-encoding as available in Management Console 6.5. In this section, you will learn: Before you promote a subscription or selected table mappings Promoting subscriptions on page 378 Promoting selected table mappings on page 382 Related tasks To upgrade subscriptions to use auto-encoding mode on page 191
Before you promote a subscription or selected table mappings

You should consider the following points before promoting a subscription or selected table mappings: v End replicationEnsure that you have ended replication on the subscription. v Ensure that tables are present on the schema being promotedFor Management Console to successfully promote subscriptions, check that the database tables for the schemas selected for promotion are valid. Otherwise, promotion will fail. v Organize subscriptions into projectsOrganize the subscription that you want to promote into a project. The purpose of promoting subscriptions is to relocate your subscription from one environment to another. Placing subscriptions into projects are a useful organizational tool to distinguish between an existing and newly promoted subscription. v Review mapping details for the subscriptionEnsure that you have reviewed mapping details you set for the subscription. These mapping details are promoted to the new environment. Management Console promotes the properties of your subscription, including the source database information, source table selections, table mappings, the replication method, source and target
377
column mappings, any notifications you set for the subscription, data translations, and any expressions into the new environment. v Identify database name and ownerIdentify the database name and owner of the new source database. If you have built an expression on the source such as %GETCOL, then this kind of expression will reference the names of columns from other tables. Before you promote these expressions to the new environment, you should know the name and owner of the new source database that contain the table referenced in the expression. For example, you may have built a derived column on the source that references values from another table located in another database:
%GETCOL(JobTitle, "Northwind.dbo.CustomerData", "Sales Manager")
When promoting expressions to a new environment, the table called CustomerData might exist in another database other than Northwind. If so, then you need to specify the name of the new source database that contains this table in the Promote Subscription wizard. v Identify the full path name or program name of user exits called by an expressionIf you have an expression that calls a stored procedure on the source using the %USER column function, you need to make sure that stored procedure exists in the new source database and specify the location of the stored procedure (for example, the DLL path) in the Promote Subscription wizard. Also, if you have an expression that calls a stored procedure on the target using the %STPROC function, you need to make sure that stored procedure exists in the new target database. You should also know the location (full path) for the stored procedure. v Refreshing only a subset of rowsIf SQL Where clauses have been specified to define a subset of rows within a refresh configuration for a table mapping, they will not be promoted to the new table mapping. Related concepts Promoting subscription changes on page 377 Related tasks To end replication on page 362
Promoting subscriptions
Use the Promote Subscription wizard to promote your subscription to a new environment. For example, you can promote your subscription from a development environment and into a production environment when you are ready to use that subscription in replication activities. Using the Promote Subscription wizard, you can: v Promote to a new subscriptionIn this scenario, you are promoting a subscription to a new environment. For example, you may have projects that are exclusive for development or testing purposes. You can promote subscriptions into one of these environments. v Promote changes to an existing subscriptionIn this scenario, you have made changes to a subscription that has already been promoted to another environment. For example, the subscription may already exist in a project that you have reserved for testing subscriptions, but you may have made some minor changes on the subscription. To make sure the subscription in the test environment includes the changes that you made, you need to promote your changes to the testing environment.
378
Note: When promoting changes to an existing subscription, InfoSphere CDC maintains synchronization between your source and target tables and you do not need to set the log position in the new environment. However, if you are making changes that causes you to lose synchronization between your source and target tables (such as updating the definition of a source table), then InfoSphere CDC does not maintain the log position and you will have to resynchronize your source and target tables in the original and in the new environment. For more information on how to synchronize source and target tables in a table mapping, see Flagging a source table for refresh on page 343. See also: To promote a subscription to a new subscription To promote changes to an existing subscription on page 380
To promote a subscription to a new subscription

1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select Promote Subscription. 3. Select Promote to a new subscription. 4. Enter the name of the new subscription in the Name box. All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. 5. Enter the description of the new subscription in the Description box. 6. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. Click Next. Select the name of the new source datastore from the New Source Datastore list. Select the name of the database and owner from the New Name list. If you have built a derived column on the source that references another table in another database using the %GETCOL column function, specify the name of the database and owner that contains the table that is referenced in the %GETCOL function. Also, make sure that the table referenced in the derived column exists in the new source database. If you want to specify advanced settings for the subscription, click Advanced Settings. Modify the following properties and click OK, then click Next. v Source IDSpecify the source ID for the new subscription. v TCP HostSpecify the TCP host that your source datastore will use to recognize the target datastore when the computer where InfoSphere CDC is installed has multiple network cards. This is useful if you want to specify a host that is different from the host that you specified in the Access Manager perspective. The default option is Auto-select, which will automatically select the network card that can communicate with the target datastore. The
7. 8. 9.
10.
379
host that you specified in theAccess Manager perspective also appears by default as well as any alias that you configured in the Datastore Properties dialog box. v Firewall PortSpecify a port number for the new subscription. v Mark subscription as persistentEnable if you want to specify that the subscription is persistent. A subscription can only be restarted automatically if it is enabled for persistency. v Propagation ControlClick Add and select the source ID for any subscription for which you want to prevent data from being replicated to the target. v Do not replicate data received from any subscriptionsEnable if you want to prevent replication from all subscriptions. v Select the datastore to handle the transferable workSpecify where transferable work will be performed, in order to minimize impact on the source or target datastore. 11. Select the name of the new target datastore from the New Target Datastore list. 12. If you have added an alias for the target datastore that the source system can recognize, then click Advanced Settings and choose a valid alias and click OK. 13. Select the name of the database and owner from the New Name list and click Next. 14. If you have configured expressions with column functions that call user exit programs, such as %USER or %STPROC, then specify the full path that contains the stored procedure, or the name of the user exit program referenced in the expression, then click Next. Make sure that the stored procedure or user exit program already exists in the new source database. 15. If you have built a derived column, an expression, or a row-filtering expression that uses the %SELECT column function, then confirm the list of displayed expressions and click Next. After the promotion, make sure that the table or column referenced in the %SELECT expression exists in the new database. 16. Click View XML to confirm the location and attributes of the promoted subscription. 17. Review the list of changes and click Finish. Related concepts Before you promote a subscription or selected table mappings on page 377 Promoting subscriptions on page 378
To promote changes to an existing subscription

1. Click Configuration > Subscriptions. 2. Right-click on a subscription and select Promote Subscription. 3. Select Promote changes to an existing subscription. 4. Select the subscription to which you want to promote changes from the Promote To list. 5. In the Table Mappings area you can select one of the following two options and click Next:
380
v Replace all table mappings in the existing subscriptionIndicates the table mappings in the subscription you are promoting will replace all existing table mappings in the existing subscription you are promoting to. For example, you plan on promoting table mappings from subscription Develop to subscription Test. Subscription Develop contains four table mappings: A, B, C, and D. A and B are selected for promotion to subscription Test. Subscription Test contains three table mappings: A, B, and Z. By selecting this option, table mappings A and B in subscription Develop will replace all of the existing table mappings in subscription Test. After promotion is complete, subscription Test will only contain table mappings A and B. Table mapping Z will no longer exist in subscription Test. v Only replace table mappings from the promoted subscriptionIndicates the table mappings in the subscription you are promoting will only replace table mappings with identical names in the existing subscription you are promoting to. All other table mappings will remain in the subscription you are promoting to. For example, you plan on promoting table mappings from subscription Develop to subscription Test. Subscription Develop contains four table mappings: A, B, C, and D. A and B are selected for promotion to subscription Test. Subscription Test contains three table mappings: A, B, and Z. By selecting this option, table mappings A and B in subscription Develop will only replace table mappings A and B in subscription Test. After promotion is complete, subscription Test will still contain three table mappings: A, B and Z. 6. Confirm the source datastore and the name of the database and owner from which you want to promote the changes, then click Next. If you have built a derived column on the source that references another table in another database using the %GETCOL column function, specify the name of the database and owner that contains the table that is referenced in the %GETCOL function. Also, make sure that the table referenced in the derived column exists in the new source database. 7. Confirm the target datastore and the name of the database and owner to which you want to promote the changes. 8. If you have configured expressions with column functions that call user exit programs, such as %USER or %STPROC, specify the full path that contains the stored procedure, or the name of the user exit program referenced in the expression, then click Next. Make sure that the stored procedure or user exit program already exists in the new source database. 9. If you have built a derived column, an expression, or a row-filtering expression that uses the %SELECT column function, confirm the list of displayed expressions and click Next. After promotion, make sure that the table or column referenced in the %SELECT expression exists in the new database. 10. Click View XML to confirm the location and attributes of the promoted subscription. 11. Review the list of changes and click Finish.
381
Related concepts Before you promote a subscription or selected table mappings on page 377 Promoting subscriptions on page 378
Promoting selected table mappings

Use the Promote Table Mappings wizard to promote your selected table mappings to a subscription in a new environment. For example, you can promote your subscription from a development environment and into a production environment when you are ready to use that subscription in replication activities. Using the Promote Table Mappings wizard, you can: v Promote a Subscription to a New EnvironmentIn this scenario, you are promoting selected table mappings to a subscription in a new environment. For example, you may have projects that are exclusive for development or testing purposes. You can promote subscriptions into one of these environments. v Promote Changes to an Existing SubscriptionIn this scenario, you have made changes to table mappings in a subscription that has already been promoted to another environment. For example, the subscription may already exist in a project that you have reserved for testing subscriptions, but you may have made some minor changes to the table mappings for the subscription. To make sure the subscription in the test environment includes the changes that you made, you need to promote your changes to the testing environment. Note: When promoting changes to an existing subscription, InfoSphere CDC maintains synchronization between your source and target tables and you do not need to set the log position in the new environment. However, if you are making changes that causes you to lose synchronization between your source and target tables (such as updating the definition of a source table), then InfoSphere CDC does not maintain the log position and you will have to resynchronize your source and target tables in the original and in the new environment. For more information on how to synchronize source and target tables in a table mapping, see Flagging a source table for refresh on page 343. Be aware that if SQL Where clauses have been specified to define a subset of rows within a refresh configuration for a table mapping, they will not be promoted to the new table mapping. See also: To promote selected table mappings to a new environment To promote selected table mappings to an existing subscription on page 384 Related concepts Before you promote a subscription or selected table mappings on page 377
To promote selected table mappings to a new environment

1. Click Configuration > Subscriptions. 2. Select the subscription with the table mappings you want to promote. 3. Right-click one or more table mappings in the Table Mapping view and select Promote.... 4. Select Promote to a new subscription. 5. Enter the name of the new subscription in the Name box.
382
6. 7.
8. 9. 10.
11.
All subscriptions that come from the same source datastore must have a unique name and all subscriptions that go to the same target datastore must have a unique Source ID. The source ID is automatically generated based on truncating the subscription name to 8 characters. If you attempt to create a subscription with a duplicate Source ID, an error will result and the subscription will not be created. If this occurs, click Advanced Settings and give the subscription a unique Source ID. Enter the description of the new subscription in the Description box. If you want to include the new subscription in a project, select a project from the Project list or click New Project to create a new project. If you do not select a project, Management Console places the new subscription into the Default Project. Click Next. Select the name of the new source datastore from the New Source Datastore list. Select the name of the database and owner from the New Name list. If you have built a derived column on the source that references another table in another database using the %GETCOL column function, specify the name of the database and owner that contains the table that is referenced in the %GETCOL function. Also, make sure that the table referenced in the derived column exists in the new source database. If you want to specify advanced settings for the subscription, click Advanced Settings. Modify the following properties and click OK, then click Next. v Source IDSpecify the source ID for the new subscription. v TCP HostSpecify the TCP host that your source datastore will use to recognize the target datastore when the computer where InfoSphere CDC is installed has multiple network cards. This is useful if you want to specify a host that is different from the host that you specified in the Access Manager perspective. The default option is Auto-select, which will automatically select the network card that can communicate with the target datastore. The host that you specified in theAccess Manager perspective also appears by default as well as any alias that you configured in the Datastore Properties dialog box. v Firewall PortSpecify a port number for the new subscription. v Mark subscription as persistentEnable if you want to specify that the subscription is persistent. A subscription can only be restarted automatically if it is enabled for persistency.
v Propagation ControlClick Add and select the source ID for any subscription for which you want to prevent data from being replicated to the target. v Do not replicate data received from any subscriptionsEnable if you want to prevent replication from all subscriptions. v Select the datastore to handle the transferable workSpecify where transferable work will be performed, in order to minimize impact on the source or target datastore. 12. Select the name of the new target datastore from the New Target Datastore list. 13. If you have added an alias for the target datastore that the source system can recognize, then click Advanced Settings and choose a valid alias and click OK.
383
14. Select the name of the database and owner from the New Name list and click Next. 15. If you have configured expressions with column functions that call user exit programs, such as %USER or %STPROC, then specify the full path that contains the stored procedure, or the name of the user exit program referenced in the expression, then click Next. Make sure that the stored procedure or user exit program already exists in the new source database. 16. If you have built a derived column, an expression, or a row-filtering expression that uses the %SELECT column function, then confirm the list of displayed expressions and click Next. After the promotion, make sure that the table or column referenced in the %SELECT expression exists in the new database. 17. Click View XML to confirm the location and attributes of the promoted subscription. 18. Review the list of changes and click Finish. Related concepts Before you promote a subscription or selected table mappings on page 377
To promote selected table mappings to an existing subscription

1. Click Configuration > Subscriptions. 2. Select the subscription with the table mappings you want to promote. 3. Right-click one or more table mappings in the Table Mapping view and select Promote.... 4. Select Promote changes to an existing subscription. 5. Select the subscription to which you want to promote changes from the Promote To list. 6. In the Table Mappings area you can select one of the following two options and click Next: v Replace all table mappings in the existing subscriptionIndicates that the selected table mappings that you are promoting will replace all existing table mappings in the existing subscription you are promoting to. For example, you plan on promoting table mappings from subscription Develop to subscription Test. Subscription Develop contains four table mappings: A, B, C, and D. A and B are selected for promotion to subscription Test. Subscription Test contains three table mappings: A, B, and Z. By selecting this option, table mappings A and B in subscription Develop will replace all of the existing table mappings in subscription Test. After promotion is complete, subscription Test will only contain table mappings A and B. Table mapping Z will no longer exist in subscription Test. v Only replace the selected table mappingsIndicates that only the selected table mappings in the subscription being promoted will replace table mappings (with identical names) in the existing subscription you are promoting to. All other table mappings will remain in the subscription you are promoting to. For example, you plan on promoting table mappings from subscription Develop to subscription Test. Subscription Develop contains four table mappings: A, B, C, and D. A and B are selected for promotion to subscription Test. Subscription Test contains three table mappings: A, B, and Z. By selecting this option, table mappings A and B in subscription Develop will
384
only replace table mappings A and B in subscription Test. After promotion is complete, subscription Test will still contain three table mappings: A, B and Z. 7. Confirm the source datastore and the name of the database and owner from which you want to promote the changes, then click Next. If you have built a derived column on the source that references another table in another database using the %GETCOL column function, specify the name of the database and owner that contains the table that is referenced in the %GETCOL function. Also, make sure that the table referenced in the derived column exists in the new source database. 8. Confirm the target datastore and the name of the database and owner to which you want to promote the changes. 9. If you have configured expressions with column functions that call user exit programs, such as %USER or %STPROC, specify the full path that contains the stored procedure, or the name of the user exit program referenced in the expression, then click Next. Make sure that the stored procedure or user exit program already exists in the new source database. 10. If you have built a derived column, an expression, or a row-filtering expression that uses the %SELECT column function, confirm the list of displayed expressions and click Next. After promotion, make sure that the table or column referenced in the %SELECT expression exists in the new database. 11. Click View XML to confirm the location and attributes of the promoted subscription. 12. Review the list of changes and click Finish. Related concepts Before you promote a subscription or selected table mappings on page 377
385
386
Monitoring subscriptions
After configuring your replication environment and starting replication for your subscriptions, you can monitor and analyze replication activities for each subscription in the Monitoring perspective. You can use the Monitoring perspective to understand the characteristics of your replication environment and to diagnose potential problems by performing the following actions: v View replication activity for a subscription v Analyze replication performance v Examine the amount of latency for a subscription. You can set latency thresholds and notifications for your subscriptions to help you determine when latency is becoming a problem. v Check system messages and events that relate to a subscription or a datastore in the Event Log or Current Replication Events area. You can view messages for each subscription and datastore in your replication configuration. In this section, you will learn: Subscriptions view (Monitoring perspective) Understanding subscription states on page 388 Displaying the replication diagram on page 389 Viewing latency for a subscription on page 390 Viewing replication activity on page 391 Viewing replication events on page 393 Performance view (Monitoring perspective) on page 398 Available metrics on page 399 Analyzing subscription performance on page 422 Related concepts Setting notifications on page 365 Disk resource system parameters on page 506
Subscriptions view (Monitoring perspective)

The Subscription view of the Monitoring perspective allows you to monitor and analyze replication activities for each subscription so that you can understand your normal replication activity, observe trends and diagnose potential problems. In addition, the Subscription view contains operational features for subscriptions that allow you to connect to datastores, and to start replication and end replication. In this view, you can perform the following actions: v Connect to a datastore v View the subscription summary v v v v View the replication diagram Monitor the state of your subscription Start or end replication on a subscription Refresh a subscription
387
v View a summary of latency, replication activity and events The area at the top left of the view contains buttons that link to two summary modes: subscription summary and replication diagram. mode displays a summary of replication states and The subscription summary latency on the left, and a list of subscriptions on the right. The Replication section of the subscription summary breaks down replication into five states and shows a count of how many subscriptions fall within each state: v MirroringIncludes subscriptions in the Mirroring Continuous and the Mirroring Scheduled End state v RefreshIncludes subscriptions in the Refreshing state v FailedIncludes subscriptions in the Failed state v InactiveIncludes subscriptions in the Inactive state v OtherIncludes subscriptions in the Starting, Ending, Locked or Unknown state The links in the Replication section of the subscription summary can also be used as filters. Click a state to filter the list of subscriptions to display only subscriptions in that state. The Clear Filter link returns the list to its default display. The Latency area of the summary breaks down latency levels into three states: Problem, Warning, and Normal. A count is shown indicating how many subscriptions fall within each state. You must set latency threshold values for your subscriptions in order for values to be displayed in this area. mode displays a schematic to visually represent the The replication diagram datastores and the mapping relationships between them in your replication configuration. The bottom section of the window displays a summary of latency, replication activity and events. Related concepts Starting mirroring on page 356 Starting a refresh on a subscription on page 358 Ending replication on page 361 Displaying the replication diagram on page 389 Setting latency thresholds and notifications on page 374 Viewing replication activity on page 391 Viewing latency for a subscription on page 390 Viewing replication events on page 393 Monitoring subscriptions on page 387 Starting and ending replication on page 355 Connecting to a datastore on page 72
Understanding subscription states

Subscriptions configured in Management Console can be in one of the following states:
388
v EndingIndicates that InfoSphere CDC is close to completing replication activity on the subscription and is in the process of shutting down. v FailedIndicates that the subscription stopped replication after encountering an error. v InactiveIndicates that InfoSphere CDC is not replicating data on the subscription. v LockedIndicates that the subscription has been locked by a user. A locked subscription is read-only to all other users. v Mirror ContinuousIndicates that InfoSphere CDC is mirroring data between the source and target. This occurs when you have started continuous mirroring on the subscription. v Mirror Net ChangeIndicates that InfoSphere CDC is mirroring changes that were made to the source since replication last ended. InfoSphere CDC ends replication after the changes are mirrored to the target. v Refresh Before MirroringIndicates that InfoSphere CDC will refresh the data before mirroring will begin. v RefreshingIndicates that InfoSphere CDC is refreshing data from the source to the target. After completing the refresh, InfoSphere CDC starts mirroring the subscription or returns to a state of Inactive, depending on the replication method that you have selected for the subscription. v StartingIndicates that InfoSphere CDC is starting replication for the subscription. v UnknownIndicates that InfoSphere CDC cannot determine the state of the subscription. This may be a result of a lack of communication between the monitoring process and the datastores, or your subscription is using an external source datastore. v Waiting for DataStage to be StartedIndicates that Management Console is waiting for the InfoSphere DataStage job to begin before replication can start. v Waiting for DataStage Job to ConnectIndicates that Management Console is waiting for the InfoSphere DataStage job to connect before replication can start. v Ending DataStage jobIndicates that Management Console is waiting for the InfoSphere DataStage job to end before replication can end. An icon is displayed beside the subscription name to visually indicate its state. Related concepts Viewing replication events on page 393 Locking subscriptions within a datastore on page 54
Displaying the replication diagram

The replication diagram in the Subscriptions view of the Monitoring perspective uses a schematic to visually represent the datastores and the mapping relationships between them in your replication configuration. Datastores are represented by graphic elements with connecting lines running between datastores that share table mappings. Each connecting line that runs between datastore graphics has an arrowhead pointing to the target datastore. A circular indicator at the midpoint of the connector indicates subscription state: green for active, yellow for inactive, or red for failed. Since a connector can represent multiple subscriptions, the state that is displayed is that of the
389
subscription with the lowest state. For example, if 5 subscriptions are represented by a connector, four of which are active and one is inactive, the circular indicator will be yellow. Choosing either one of these datastores or connections loads a list of associated subscriptions and the projects they're organized in.
Viewing latency for a subscription

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 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. It is up to you to decide how much latency you are willing to tolerate in your environment. The Latency area of the Subscriptions view of the Monitoring perspective displays a graphical summary of latency for the current subscription. In order to view latency information, you need to ensure that Collect Statistics is enabled for the subscription. Once enabled, an icon column on the right side of the subscription list. will be displayed in a
You can drill down in this area to see a more detailed explanation of latency by double-clicking on the area title. A summary of latency values and a graph will be displayed: v CurrentIndicates the amount of time the subscription is latent in replicating data to the target. v HighIndicates the highest amount of time a subscription has experienced latency since you started to collect statistics. v LowIndicates the least amount of time a subscription has experienced latency since you started to collect statistics. v AverageIndicates the average amount of time a subscription has experienced latency since you started to collect statistics. You can export the latency information to a comma-delimited file by clicking Export Statistics, located above the graph. Latency considerations v To receive accurate latency statistics for a subscription, ensure that your system time (for each machine where you have installed InfoSphere CDC) is synchronized and that the time zone matches the time zone of your region. InfoSphere CDC calculates latency based on your system time and the offset from Coordinated Universal Time (UTC). v Depending on the platform on which you have InfoSphere CDC, you can set the DEADBAND PERCENTAGE system parameter to greater than zero on your target datastore if you want InfoSphere CDC to apply padding around your latency threshold. v Latency can jump for idle nodes in Oracle RAC environments due to Oracle checkpoint procedures. See also: To view latency values for a subscription on page 391
390
To view latency values for a subscription

1. 2. 3. 4. Click Monitoring > Subscriptions. Select a subscription. Ensure that Collect Statistics has been enabled for the subscription. Double-click on Latency.
Viewing replication activity

The Activity area of the Subscriptions view of the Monitoring perspective displays a graphical summary of either mirroring or refresh activity. You can drill down in this view to see a more detailed explanation of activity by double-clicking on the area title. In order to view replication activity, you need to ensure that the Collect Statistics button is enabled for the subscription. Once you've enabled statistics collection, an icon will be displayed in a column on the right side of the subscription list.
Activity - Refresh
If your subscription is refreshing, a pie chart depicting the progress of the refresh will be displayed, along with the following information: v Tables completedDisplays a percentage value for the number of tables in the subscription that have finished refreshing. v Refresh startedDisplays the date and time that the refresh began. v Refresh completedDisplays the date and time that the refresh ended. v Table nameSpecifies the name of the target table currently being refreshed. This information will only be displayed while the refresh is in progress. v Rows readSpecifies the number of rows in the source table that have been read. This information will only be displayed while the refresh is in progress. Double-clicking Activity - Refresh will drill down into a more detailed view of the replication activity. The pie chart is displayed again, along with a list of the tables to be refreshed. For each table, the following information is displayed: v Source TableSpecifies the source table. v Target TableSpecifies the target table being refreshed. v DurationDisplays the amount of time the refresh has lasted. v Records ReadDisplays the number of records that have been read from the source table. v Records AppliedDisplays the number of database operations (inserts, updates or deletes) performed on the target table. This value is only supplied when the refresh for that table has completed. The Records Applied value may differ from the Records Reads value, if a differential refresh was performed or if filters or user exits were used. v StatusDisplays the current status of the table. The status will be Refreshing... while the refresh of a table is still in progress or Completed when the refresh of the table has completed.
391
Activity - Mirroring
If your subscription is mirroring, a graph showing the recent progress of replication will be displayed, along with the total volume of bytes per second. Double-clicking Activity - Mirroring will drill down into a more detailed view of the replication activity. You can choose to view activities by either action or volume. If you select Operations, a list of basic replication activities (inserts, updates, and deletes) for the source and target datastores is displayed on the left.
Note: If you are applying to a Netezza database this counter will display as N/A (Not Applicable) as InfoSphere CDC for Netezza databases does not perform update operations. Updates that occur on the source database are replicated using DELETE and INSERT operations to minimize impact on the Netezza database. If you select Bytes, a list of processed volume activities (measured in bytes) for the source and target datastores is displayed on the left. Each activity is summarized by Statistics Sample Rate-based rates for current activity, the highest level of activity and cumulative activity for the replication session. For the Operations tab, the Cumulative column displays a count of the activities that occurred after statistics collection was enabled during the current replication session (the current session being when mirroring or refresh was started, until replication is ended). The next time that replication is started, the event count will return to zero and begin again. The frequency at which Management Console collects data for the cumulative count is based upon the value set in the Statistics Sample rate (seconds) box on the Preferences dialog. The count will begin after the first instance of the specified interval. Up to five of these activities can be selected to plot the graph on the right. Each activity will be assigned a different color on the graph. You can export the statistics information to a comma-delimited file by clicking Export Statistics, located above the graph. See also: To view replication activities for a subscription on page 393
392
Related concepts Setting monitoring preferences on page 21 Related reference Source pre-filter deletes on page 411 Source pre-filter inserts on page 411 Source pre-filter updates on page 411 Source post-filter deletes on page 412 Source post-filter inserts on page 412 Source post-filter updates on page 412 Target "source" deletes on page 418 Target "source" inserts on page 417 Target "source" updates on page 417 Target apply deletes on page 421 Target apply inserts on page 421 Target apply updates on page 421 Source communications bytes processed on page 414 Source database bytes processed on page 406 Source engine bytes processed on page 411 Target communications bytes processed on page 414 Target database bytes processed on page 422 Target engine bytes processed on page 417
To view replication activities for a subscription

1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Ensure that Collect Statistics has been enabled for the subscription. 4. Double-click on Activity, Activity - Mirroring or Activity - Refresh.
Viewing replication events

The Events area of the Subscriptions view of the Monitoring perspective lets you view events and messages generated by InfoSphere CDC during replication activities. It allows you to monitor activity and identify problems with the replication activity of your subscriptions. The top level view provides a summary regarding the number of events, broken down by type. You can drill down in this view to see a list of events by double-clicking on the area title. Events allow you to perform the following actions: v View events generated by specific subscriptions or datastores v Filter events based on severity v Copy events. You can then paste the event into another application. For example, you may want to copy an event into an e-mail for technical support reasons. v Export events to a comma-delimited file v Clear event messages that you no longer need to investigate v Search for specific events v From the Events column, view the number of errors associated with your subscription when you first loaded it. The value from this column acts as an
393
indicator for you to address the errors as required. Once you have addressed all the events, you can reset the Events column to repopulate with new statistics. If the subscription you have selected belongs to a datastore of InfoSphere CDC version 6.3 or earlier, the Events area will be titled Event Log Summary. In this mode, the Events area will display the events that occurred during the life of the subscription. If the subscription you have selected belongs to a datastore of InfoSphere CDC version 6.5 or later, the Events area will be titled Current Replication Events. In this mode, the Events area will display the events that occurred during the current replication session; that is to say, from when mirroring or refresh was started, until replication is ended. The next time that replication is started, the event count will return to zero and begin again. There are several categories of events, which are listed by increasing severity: v InformationThese events provide feedback about InfoSphere CDC operations. These events do not indicate that an error has occurred. v DiagnosticThese events contain information that helps you diagnose or solve a problem that may occur as a result of a certain action or operation. This category of events is generated only by InfoSphere CDC for DB2 for i, InfoSphere CDC for Oracle databases version 6.0 and earlier, InfoSphere CDC for Microsoft SQL Server version 5.3.4 and earlier replication engines. v NoticeThese events describe situations that InfoSphere CDC has detected, which alerts you about a potential error. This category of events is generated only by InfoSphere CDC for DB2 for i, InfoSphere CDC for Oracle databases version 6.0 and earlier, InfoSphere CDC for Microsoft SQL Server version 5.3.4 and earlier replication engines. v WarningThese events describe situations that InfoSphere CDC has detected, which alerts you about a potential error. v ErrorThese events describe an error that InfoSphere CDC has detected, or explain conditions that led to InfoSphere CDC shutting down. v EscapeThese events describe an error that InfoSphere CDC has detected, or explain conditions that led to InfoSphere CDC shutting down. This category of events is generated only by InfoSphere CDC for DB2 for i, InfoSphere CDC for Oracle databases version 6.0 and earlier, InfoSphere CDC for Microsoft SQL Server version 5.3.4 and earlier replication engines. There are multiple ways to filter the display of events: v CategoryClicking either Subscription, Single Scrape or Datastore will filter the display to include only those events that apply to the selected category. The Single Scrape option will only be available when it is an applicable filter. v Source or TargetFilter the display to include only the events generated by the source or target datastores. v ErrorsFilter the display to show only errors by clicking the Errors link. v WarningsFilter the display to show only warnings by clicking the Warnings link. v AllCancels the Errors and Warnings filters. The returns to the default value, which is to display all events that apply to the Category, Source or Target filters if applied. See also: To view events (InfoSphere CDC version 6.5 and later) on page 395
394
To retrieve events that occurred within a date range (InfoSphere CDC version 6.5 and later) To view events (InfoSphere CDC version 6.3 and earlier) on page 396 To view event details on page 396 To copy events on page 397 To clear all events for the selected subscription on page 397 To clear selected events for the selected subscription on page 397 To export events on page 398
To view events (InfoSphere CDC version 6.5 and later)

1. Click Monitoring > Subscriptions. 2. Select a subscription. Ensure that the subscription belongs to a datastore which is InfoSphere CDC version 6.5 or later. 3. Double-click Current Replication Events in the bottom section of the window. The display changes to show a list of events. 4. Click Retrieve Events and choose the quantity of events to retrieve: v Last 24 HoursRetrieves events from the last 24 hours. v Last 7 DaysRetrieves events from the last seven calendar days. v Last 30 DaysRetrieves events from the last thirty calendar days. v All EventsRetrieves all events. If the quantity of events is large, there may be a delay while they are loaded. v CustomAllows you to retrieve events based on a date range that you determine or by specific categories of events. to retrieve any events that have occurred Alternately, you can click subsequent to your last retrieval. 5. If you want to filter the display by event source category, click one of the following items: v SubscriptionFilters the display to include only events that apply to the subscription. v Single ScrapeFilters the display to include only events that apply to Single Scrape. This option will be unavailable if Single Scrape is not supported by the replication engine. v DatastoreFilters the display to include only events that apply to the datastore. v SourceFilters the display to include only events generated by the source datastore. v TargetFilters the display to include only events generated by target datastore. 6. If you want to filter the display by type of event, click Errors or Warnings at the bottom of the events list.
To retrieve events that occurred within a date range (InfoSphere CDC version 6.5 and later)
1. Click Monitoring > Subscriptions. 2. Select a subscription.
395
3. 4. 5. 6.
Ensure that the subscription belongs to a datastore which is InfoSphere CDC version 6.5 or later. Double-click Current Replication Events in the bottom section of the window. The display changes to show a list of events. Click Retrieve Events and select Custom. The Retrieve Events dialog box opens. Select the Retrieve events based on date range: option. Select the starting date and time value for the range in the From: controls.
7. Select the ending date and time value for the range in the To: controls. 8. Select Source Events to retrieve events from the source datastore and choose one of the following items from the list box: v AllIncludes all source events that occurred during the specified date range. v DatastoreIncludes all source events applicable to the datastore that occurred during the specified date range. v SubscriptionIncludes all source events applicable to the subscription that occurred during the specified date range. v Single ScrapeIncludes all source events applicable to the Single Scrape component that occurred during the specified date range. 9. Select Target Events to retrieve events from the target datastore and choose one of the following items from the list box: v AllIncludes all target events that occurred during the specified date range. v DatastoreIncludes all target events applicable to the datastore that occurred during the specified date range. v SubscriptionIncludes all target events applicable to the subscription that occurred during the specified date range. v Single ScrapeIncludes all target events applicable to the Single Scrape component that occurred during the specified date range.
To view events (InfoSphere CDC version 6.3 and earlier)

1. Click Monitoring > Subscriptions. 2. Select a subscription. Ensure that the subscription belongs to a datastore which is InfoSphere CDC version 6.3 and earlier. 3. Double-click Event Log Summary in the bottom section of the window. The display changes to show a list of events. 4. Click Retrieve Events. 5. If you want to filter the display of events by type, click Errors or Warnings at the bottom of the events list. Related concepts Viewing replication events on page 393
To view event details

1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Double-click on Current Replication Events or Event Log Summary, as applicable. The display changes to show a list of events. 4. Select an event.
396
5. Right-click and select Event Details. The Event Details dialog opens. 6. If you want to view details for sequential events, click Next or Previous Related concepts Viewing replication events on page 393
To copy events
1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Double-click on Current Replication Events or Event Log Summary, as applicable. 4. Select an event or hold Ctrl and select multiple events. 5. Right-click and select Copy Selected Events. 6. Paste the events in the desired application. Related concepts Viewing replication events on page 393
To clear all events for the selected subscription

1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Double-click on Current Replication Events or Event Log Summary, as applicable. 4. Right-click in the list of events and select Clear Events > Clear All Events. Related concepts Viewing replication events on page 393
To clear selected events for the selected subscription

1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Double-click on Current Replication Events or Event Log Summary, as applicable. 4. Right-click in the list of events and select Clear Events > Custom. The Clear Events dialog opens. 5. Select one of the following options to determine the time period for events to be cleared: v Clear all events beforeIncludes the events that occurred before the date and time you set. v Clear eventsIncludes all events listed. 6. If you want to clear events from the source datastore, select the Source Events check box and select one of the following items from the list box: v AllClears all events generated by the source datastore. v DatastoreClears all events generated by the source datastore applying to the source datastore. v SubscriptionClears all events generated by the source datastore applying to subscriptions. v Single ScrapeClears all events generated by the source datastore applying to Single Scrape.
397
7. If you want to clear events from the target datastore, select the Target Events check box and select one of the following items from the list box: v AllClears all events generated by the target datastore. v DatastoreClears all events generated by the target datastore applying to the target datastore. v SubscriptionClears all events generated by the target datastore applying to subscriptions. v Single ScrapeClears all events generated by the target datastore applying to Single Scrape.
To export events
1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Double-click on Current Replication Events or Event Log Summary, as applicable. 4. Right-click in the list of events and select Export Events. 5. If you want to export events from the source datastore, select the Source Events check box and select one of the following items from the list box: v AllClears all events generated by the source datastore. v DatastoreClears all events generated by the source datastore applying to the source datastore. v SubscriptionClears all events generated by the source datastore applying to subscriptions. v Single ScrapeClears all events generated by the source datastore applying to Single Scrape. 6. If you want to export events from the target datastore, select the Target Events check box and select one of the following items from the list box: v AllClears all events generated by the target datastore. v DatastoreClears all events generated by the target datastore applying to the target datastore. v SubscriptionClears all events generated by the target datastore applying to subscriptions. v Single ScrapeClears all events generated by the target datastore applying to Single Scrape. 7. You are prompted to save the list of events in a formatted text file to your local computer. Related concepts Viewing replication events on page 393
Performance view (Monitoring perspective)

Note: The Performance view and the ability to analyze subscription performance is only available for datastores that support this feature. The Performance view of the Monitoring perspective allows you to diagnose the performance of a subscription, or tables within a subscription, by selecting metrics by which to gauge performance. It allows you to focus on measuring the performance of InfoSphere CDC processes and components rather than other applications and processes that may also reside on the server with InfoSphere CDC.
398
The Performance view consists of four areas. The selected subscription (and any selected tables) is displayed in the top left area of the view. Directly below the selected subscription or table, a list of available metrics is displayed. Metrics are dynamic, and will vary depending on the subscription selected. Use the Collect Data button below the list of available metrics to toggle data collection on or off. After clicking this button, the graphical display area to the right is enabled. The graphical display area contains three zones: v BottlenecksDisplays a bar chart featuring the five components of the pipeline: Log Reader, Source Engine, Communication, Target Engine, and Target Database. The results of the bar chart will help you isolate which components are causing bottlenecks. v LatencyDisplays a graphical summary of latency for the selected subscription. v StatisticsDisplays a graph of the performance of the selected metrics with a statistics count area at the bottom. After selecting a subscription, click Collect Data to start collecting data. If you observe latency and a bottleneck is occurring, you can then proceed to collect metrics that relate to the component that is causing the bottleneck. For example, if you observe latency and there is a bottleneck in the Source Engine component, you should then collect metrics that relate to this component. Note: Collecting table-level statistics uses additional system resources and may affect performance.
Available metrics
The following is a list of the metrics available for analyzing subscription performance. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: Datastore metrics Database Workload metrics on page 402 Log cache metrics on page 403 Log reader metrics on page 404 Log parser metrics on page 407 Single Scrape metrics on page 408 Source Engine metrics on page 409 Communications metrics on page 413 Target Engine metrics on page 415 Target Apply metrics on page 418
Datastore metrics
These metrics allow you to analyze replication activities specific to your datastores. This category will appear twice - once for the source datastore and once for the target datastore. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed.
399
See also: Free memory - bytes Garbage collections - count Garbage collection CPU time - milliseconds Global memory manager - bytes Maximum memory - bytes on page 401 Network errors - count on page 401 Storage manager current bytes used on page 401 Storage manager maximum bytes used on page 401 Time check missed count on page 401 Total memory - bytes on page 402
Free memory - bytes

UnitsBytes DescriptionTracks the amount of free memory as a subset of the maximum memory that is available. UsingUse this statistic in conjunction with the Total memory and Maximum memory statistics to understand overall memory usage. A low value for this metric may indicate a memory starvation issue and can be addressed by allocating more memory to the engine. Related reference Total memory - bytes on page 402 Maximum memory - bytes on page 401
Garbage collections - count

UnitsCumulative count DescriptionTracks the cumulative count since the start of collection. UsingUse this statistic to understand garbage collection activity. A large number indicates that time spent freeing memory is having an impact on performance.
Garbage collection CPU time - milliseconds

UnitsMilliseconds DescriptionTracks the time since the start of collection. UsingA large number can indicate too much memory has been allocated, which is causing very large garbage collection blocks to occur.
Global memory manager - bytes

UnitsBytes DescriptionTracks the amount of physical memory used. UsingUse this statistic to determine if the InfoSphere CDC memory configuration is optimal or if adjustments are required.
400
Maximum memory - bytes

UnitsBytes DescriptionTracks the user configured memory for the InfoSphere CDC Java Virtual Machine (JVM). UsingUse this statistic in conjunction with the Free memory and Total memory statistics to understand overall memory usage. Related reference Free memory - bytes on page 400 Total memory - bytes on page 402
Network errors - count

UnitsCumulative count DescriptionTracks the number of TCP errors that resulted in a connection being dropped. UsingAny number above zero can indicate a network configuration issue that closes the connection after a short idle period. You may wish to increase the keep alive frequency to address this issue.
Storage manager current bytes used

UnitsBytes DescriptionCurrent number of bytes in use by the storage manager for all active subscriptions. UsageProvides a snapshot of global storage usage.
Storage manager maximum bytes used

UnitsBytes DescriptionMaximum number of bytes used by the storage manager over the life of the address space. UsingProvides run-time data on actual storage requirements. If the storage required is consistently less than the configured limit for the storage manager, STG64LIMIT, then the limit could be reduced to free storage for other jobs. Storage tuning possibilities exist by comparing the storage manager maximum bytes (global across all subscriptions) with the per-subscription maxima for staging space and retry cache. Subscriptions that use the largest percentage of storage could be analyzed for large units of recovery (URs) and perhaps applications could be adjusted.
Time check missed count

UnitsCumulative seconds DescriptionTracks the extent to which InfoSphere CDC missed its periodic time check. InfoSphere CDC will record the number of seconds missed, cumulatively.
401
UsingAn increased number can indicate CPU starvation. For non-mainframe replication engines, it could indicate excessive garbage collection, meaning that InfoSphere CDC is using a lot of small blocks of memory.
Total memory - bytes

UnitsBytes DescriptionTracks the total amount of memory currently allocated by the InfoSphere CDC Java Virtual Machine (JVM). UsingUse this statistic in conjunction with the Free memory and Maximum memory statistics to understand overall memory usage. This value should be less than or equal to Maximum memory. Related reference Free memory - bytes on page 400 Maximum memory - bytes on page 401
Database Workload metrics

These metrics allow you to analyze replication activities specific to the source database. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: In scope transactions - count Transaction histogram (0 to 1/2 X) - bytes Transaction histogram (1/2X to X) - bytes on page 403 Transaction Transaction Transaction Transaction histogram histogram histogram histogram (X to 2X) - bytes on page 403 (2X to 4X) - bytes on page 403 (4X to 8X) - bytes on page 403 (8X and larger) - bytes on page 403
In scope transactions - count

UnitsCumulative count DescriptionTracks the number of in scope transactions. UsingUse this statistic to understand how many transactions are in-scope relative to all of the transactions in the log. These statistics are a workload indicator and should be used in conjunction with the Total Transactions statistics.
Transaction histogram (0 to 1/2 X) - bytes

UnitsCumulative count DescriptionTracks the cumulative count of transactions of a given size. X is the size of the transaction that always gets stored in memory. UsingUse this statistic to understand memory usage. This statistic is a workload indicator and can indicate that memory settings must be tuned.
402
Transaction histogram (1/2X to X) - bytes

UnitsCumulative counts of transactions of a given size. DescriptionTracks the cumulative count of transactions of a given size. X is the size of the transaction that always gets stored in memory. UsingUse this statistic to understand memory usage. This statistic is a workload indicator and can indicate that memory settings must be tuned.
Transaction histogram (X to 2X) - bytes

Transaction histogram (2X to 4X) - bytes

Transaction histogram (4X to 8X) - bytes

Transaction histogram (8X and larger) - bytes

Log cache metrics

These metrics allow you to analyze replication activities specific to the log cache for the InfoSphere CDC for z/OS source replication engine. These metrics will only be available if you have a log cache configured for the datastore.
403
See also: Global log cache hit percentage Log cache IFI CPU (sec/100) Log cache IFI elapsed (sec/100)
Global log cache hit percentage

UnitsPercentage DescriptionPercentage of log data read requests across all active subscriptions that are serviced from the log cache as opposed to being directly read from the DB2 logs. This statistic accrues over the life of the InfoSphere CDC for z/OS address space. UsingProvides an overall indication of the effectiveness of the log cache. A high log cache hit percentage is desirable since subscriptions do not need to incur the additional overhead of reading log data directly. A low value could indicate that the cache is too small, or that certain subscriptions are latent.
Log cache IFI CPU (sec/100)

UnitsCentiseconds (1/100th of a second) DescriptionA cumulative count of the CPU used by the log cache task (DLR) in DB2 IFI calls to read log data. UsageProvides insight into the extent that the log cache CPU consumption is within in DB2 IFI calls to read log data, as opposed to its own handling of the cached data.
Log cache IFI elapsed (sec/100)

UnitsCentiseconds (1/100th of a second) DescriptionA cumulative count of the elapsed time spend by the log cache task (DLR) in IFI calls to read log data. UsageProvides insight into the elapsed time spend by the log cache task in the IFI API reading log data. This includes delays due to retrieval of archived logs which may not show up in CPU time. When displayed in a performance graphs, the units of centiseconds displayed over 1 second time intervals can be approximately interpreted as a percentage, although it may exceed 100 due to sampling delays.
Log reader metrics

These metrics allow you to analyze replication activities specific to the log reader for the source replication engine. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: Committed transactions - count on page 405 CPU time - seconds on page 405 IFI CPU (sec/100) on page 405
404
IFI elapsed (sec/100) Log position timestamp on page 406 Log records read on page 406 Log records in scope on page 406 Physical bytes read - bytes on page 406 Source database bytes processed on page 406 Subscription log cache hit percentage on page 407 Thread CPU - milliseconds/second on page 407
Committed transactions - count

UnitsCumulative count DescriptionTracks the total number of committed transactions. UsingUse this statistic to understand transaction processing. The number of transactions processed is a workload indicator.
CPU time - seconds

UnitsCumulative seconds DescriptionTotal CPU used by all threads. UsingUse this statistic to understand CPU usage. A high value could indicate a lot of out-of-scope data.
IFI CPU (sec/100)

UnitsCentiseconds (1/100th of a second) DescriptionCPU time spent by the log reader in DB2 IFI calls reading log data directly. UsingProvides an indication how much processing time the log reader spends reading log data. If a log cache is configured, then IFI CPU will be consumed if the subscription is more latent than the data in the cache or if the cache is unavailable.
IFI elapsed (sec/100)

UnitsCentiseconds (1/100th of a second) DescriptionElapsed time spent by the log reader in DB2 IFI calls reading log data directly. UsingProvides an indication how much time the log reader spends reading log data. In performance graphs with 1 second intervals, the units of centiseconds approximates a percentage, although the value may exceed 100 depending on sampling delays. If a log cache is configured, then time will be spent in IFI calls if the subscription is more latent than the data in the cache, or if the cache is unavailable.
405
Log position timestamp

UnitsCumulative seconds DescriptionTracks the replication speed relative to the database. UsingUse this statistic to understand the progress InfoSphere CDC is making relative to the database speed as measured by the log positions being read. This value may not be accurate if timestamps are not regularly encountered in the log file.
Log records read

UnitsCumulative count DescriptionCounts the total number of log records processed by the subscription. The log reader reads all records to interpret which ones are applicable for processing by its source engine. UsingProvides an indication of the overall amount of work the log reader is doing in terms of record volume.
Log records in scope

UnitsCumulative count DescriptionCounts the number of log records that are applicable for processing by the subscription engine. This includes records for configured tables, as well as control records for all URs. UsingProvides an indication of the amount of work being passed to the source engine. When considered in relation to Log records read this statistic might also highlight some tuning opportunities. If the number of log records in scope is small relative to the total number of log records, then efficiencies may be gained by configuration changes to reduce the amount of processing in discarding non-applicable log entries. Examples include merging multiple subscriptions into one or turning off change data capture for tables not being replicated.
Physical bytes read - bytes

UnitsBytes DescriptionTracks the physical bytes read by the log reader. This includes any extra I/O that is done by replication engines to read logs. For API-based log readers, this value will be 0. UsingUse this statistic to understand log reader activity. A large number can indicate that large amounts of log data are being processed. If this number is high, and the amount of data replicated is low, it means that InfoSphere CDC is filtering out most information from the log. If the number is low, it can indicate that there have been few changes in the database.
Source database bytes processed

UnitsCumulative bytes
406
DescriptionCount all log data bytes processed by the log reader for the current subscription. UsingProvides an indication of the overall amount of work the log reader is doing in terms of data volume.
Subscription log cache hit percentage

UnitsPercentage DescriptionPercentage of log data read requests for the current subscription that are serviced from the log cache as opposed to being directly read from the DB2 logs. This statistic accrues over the life of the current run of the subscription. UsingProvides an overall indication of the effectiveness of the log cache for this subscription. A high log cache hit percentage is desirable since subscriptions do not need to incur the additional overhead of reading log data directly. A low value could indicate that the cache is too small, or that the subscriptions is latent and not caught up to the cache.
Thread CPU - milliseconds/second

UnitsMilliseconds per second DescriptionA count of how much thread a CPU is using. UsingIndicates how busy a CPU is.
Log parser metrics

These metrics allow you to analyze replication activities specific to the log parser on the source replication engine. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: Disk reads - bytes Disk size - bytes on page 408 Disk writes - bytes on page 408 Thread CPU - milliseconds/second
Disk reads - bytes

UnitsCumulative bytes DescriptionTracks the physical bytes read from disk. UsingUse this statistic to analyze disk I/O activity. A large number can indicate a performance impact from disk I/O activity; increasing the memory allocated for the global memory manager may be required.
407
Disk size - bytes

UnitsBytes DescriptionTracks the current staging store size on disk. UsingUse this statistic to understand staging store sizing. A large size on disk can indicate that large transactions being processed or that there are many concurrent open transactions.
Disk writes - bytes

UnitsBytes DescriptionTracks the physical bytes written to disk UsingUse this statistic to analyze disk I/O activity. A large number can indicate a performance impact from disk I/O activity; increasing the memory allocated to Single Scrape may be required.

Single Scrape metrics

These metrics allow you to analyze replication activities specific to the Single Scrape component on the source replication engine. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: Disk reads - bytes Disk size - bytes Disk writes - bytes on page 409
Disk reads - bytes

UnitsCumulative bytes DescriptionTracks the physical bytes read from disk. UsingUse this statistic to analyze disk I/O activity. A large number can indicate a performance impact from disk I/O activity; increasing the memory allocated to Single Scrape may be required.
Disk size - bytes

UnitsBytes DescriptionTracks the current staging store size on disk.
408
UsingUse this statistic to understand staging store sizing. A large size on disk can indicate large latency for one or more subscriptions or can indicate a stopped subscription.
Disk writes - bytes

UnitsBytes DescriptionTracks the physical bytes written to disk UsingUse this statistic to analyze disk I/O activity. A large number can indicate a performance impact from disk I/O activity; increasing the memory allocated to Single Scrape may be required.
Source Engine metrics

These metrics allow you to analyze replication activities specific to the source engine. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: CPU Used - seconds Derived column CPU (sec/100) on page 410 Derived column elapsed (sec/100) on page 410 MBCS conversions - bytes on page 410 Rows evaluating derived columns - count on page 410 Rows calling source database - count on page 410 Rows calling user exits - count on page 410 Source database bytes processed on page 406 Source engine bytes processed on page 411 Source pre-filter deletes on page 411 Source Source Source Source Source pre-filter inserts on page 411 pre-filter updates on page 411 post-filter deletes on page 412 post-filter inserts on page 412 post-filter updates on page 412
Staging space current bytes used on page 412 Staging space maximum bytes used on page 412 Thread CPU - milliseconds/second on page 407
CPU Used - seconds

UnitsCumulative CPU seconds DescriptionTracks the CPU time used by the source engine. UsingUse this statistic to understand CPU usage. A value equal to the time period can indicate a CPU bottleneck.
409
Derived column CPU (sec/100)

UnitsCentiseconds (1/100th of a second) DescriptionCPU time spent processing derived columns UsageProvides an indication of the processing overhead of derived columns on the source.
Derived column elapsed (sec/100)

UnitsCentiseconds (1/100th of a second) DescriptionElapsed time spent processing derived columns. UsageProvides an indication how much time the source engine spends processing derived columns. In performance graphs with 1 second intervals, the units of centiseconds approximates a percentage, although the value may exceed 100 depending on sampling delays.
MBCS conversions - bytes

UnitsCumulative bytes DescriptionTracks the count of input bytes converted by character conversion. UsingUse this statistic to understand activity on the source replication engine due to MBCS conversions. A large number can indicate a performance issue due to MBCS processing.
Rows evaluating derived columns - count

UnitsCumulative row count DescriptionTracks the number of rows with at least one derived expression. UsingUse this statistic to understand activity on the source replication engine caused by one or more derived expressions. A large number can indicate a potential performance issue caused by the execution of one or more derived expressions.
Rows calling source database - count

UnitsCumulative row count DescriptionTracks the number of rows with at least one call out to the source database. UsingUse this statistic to understand row activity. A large number can indicate potential performance issues caused by calls out to the source database.
Rows calling user exits - count

UnitsCumulative row count DescriptionTracks the number of rows with calls out to user functionality
410
UsingUse this statistic to understand activity on the source replication engine caused by user exits. A large number can indicate a potential performance issue caused by calls out to user functionality.
Source database bytes processed

UnitsCumulative bytes DescriptionCount all log data bytes processed by the log reader for the current subscription. UsingProvides an indication of the overall amount of work the log reader is doing in terms of data volume.
Source engine bytes processed

UnitsCumulative bytes DescriptionNumber of in-scope bytes processed by the source engine. UsingProvides an indication of the data volume of work processed by the source engine, as well as a general indication of activity by the source engine.
Source pre-filter deletes

UnitsCumulative count DescriptionNumber of deletes processed for all in-scope tables by the source engine. UsageProvides an indication of the record-level workload being processed by the source engine.
Source pre-filter inserts

UnitsCumulative count DescriptionNumber of inserts processed for all in-scope tables by the source engine. UsageProvides an indication of the record-level workload being processed by the source engine.
Source pre-filter updates

UnitsCumulative count DescriptionNumber of updates processed for all in-scope tables by the source engine. UsageProvides an indication of the record-level workload being processed by the source engine.
411
Source post-filter deletes

UnitsCumulative count DescriptionNumber of deletes to be sent to the target after row filtering. UsageProvides an understanding of the workload being sent to the target. In conjunction with Source pre-filter deletes provides an understanding of the extent to which row filtering is active.
Source post-filter inserts

UnitsCumulative count DescriptionNumber of inserts to be sent to the target after row filtering. UsageProvides an understanding of the workload being sent to the target. In conjunction with Source pre-filter inserts provides an understanding of the extent to which row filtering is active.
Source post-filter updates

UnitsCumulative count DescriptionNumber of updates to be sent to the target after row filtering. UsageProvides an understanding of the workload being sent to the target. In conjunction with Source pre-filter updates provides an understanding of the extent to which row filtering is active.
Staging space current bytes used

UnitsBytes DescriptionNumber of bytes in the staging space currently used by the subscription. UsageProvides snapshots of the staging space to characterize current storage usage.
Staging space maximum bytes used

UnitsBytes DescriptionMaximum number of bytes in the staging space used by the subscription since it started. UsageProvides an indicator of the maximum storage used to stage URs by the subscription during its current run. This taken together with other subscriptions, along with retry cache maximums, can be used to tune the overall storage configured for the storage manager.

UnitsMilliseconds per second DescriptionA count of how much thread a CPU is using.
412
UsingIndicates how busy a CPU is.
Communications metrics
Use these metrics to analyze variances in the flow of data during replication activities for both source and target engines. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: Bytes sent - count Bytes received - count Keep alive received - count Keep alive sent - count on page 414 Source communications bytes processed on page 414 Source communications wait percentage on page 414 Source missing round trip response - count on page 414 Source network latency (millisecond) on page 414 Target communications bytes processed on page 414 Target communications wait percentage on page 415 Target missing round trip response - count on page 415 Target network latency (millisecond) on page 415
Bytes sent - count

UnitsCumulative count DescriptionTracks the cumulative count of bytes sent for a given subscription. UsingUse this number to help track the amount of bandwidth used as the source engine sends information to the target engine.
Bytes received - count

UnitsCumulative count DescriptionTracks the cumulative count of bytes received for a given subscription. UsingUse this number to help track the amount of bandwidth used as the target engine receives information from the source engine.
Keep alive received - count

UnitsCumulative count DescriptionTracks the number of keep alive messages that get received as a test of the network connection when there is no current replication activity. UsingUsed to test network connectivity when replication is not active.
413
Keep alive sent - count

UnitsCumulative count DescriptionTracks the number of keep alive messages that get sent as a test of the network connection when there is no current replication activity. UsingUsed to test network connectivity when replication is not active.
Source communications bytes processed

UnitsCumulative bytes DescriptionA counter of bytes sent on the network by from the source engine. UsingProvides an indication of the source actively moving data onto the network. If this number is not increasing it could be an indication of network delays or of downstream jobs being bottlenecked and unable to consume network data.
Source communications wait percentage

UnitsPercentage DescriptionPercentage of time the source engine tasks spend waiting to place data in the products communications queues. UsingA high wait percentage provides an indication of possible slow/unreliable networks, or possibly of the target tasks being backed up and being unable to consume network data.
Source missing round trip response - count

UnitsCumulative count DescriptionCount of how many times the replication engine missed receiving a reply in under 30 seconds, the default poll retry timeout value. UsingUse to determine if there are latency issues. Any number above zero can indicate a potential latency issue.
Source network latency (millisecond)

UnitsMilliseconds DescriptionTracks the roundtrip time for processing between the source engine and the target engine. UsingUse this number to detect increased network latency.
Target communications bytes processed

UnitsCumulative bytes DescriptionA counter of bytes received from the network by from the target engine.
414
UsageProvides an indication of the target actively processing data from the network. This number not advancing could be due to the target engine task being backed in its processing, or the network being delayed.
Target communications wait percentage

UnitsPercentage DescriptionPercentage of time the target communications tasks are waiting for the data from the products communications queues. UsageProvides an indication of where the bulk of the product's processing resides. A high value indicates the product is mostly waiting on data from the network. A low value indicates the product is spending the bulk of its time processing data, either in DB2 operations or in target engine processing, and has data from the network available when it is ready to process more data.
Target missing round trip response - count

UnitsCumulative count DescriptionCount of how many times the replication engine missed receiving a reply in under 30 seconds, the default poll retry timeout value. UsingUse to determine if there are latency issues. Any number above zero can indicate a potential latency issue.
Target network latency (millisecond)

UnitsMilliseconds DescriptionTracks the roundtrip time for processing between the target engine and the source engine. UsingUse this number to detect increased network latency.
Target Engine metrics

These metrics allow you to analyze replication activities specific to the target engine. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: CPU time - seconds on page 416 Expression CPU (sec/100) on page 416 Expression elapsed (sec/100) on page 416 MBCS conversions - bytes on page 416 Retry cache current bytes used on page 416 Retry cache maximum bytes used on page 416 Rows calling target database - count on page 417 Rows calling user exits - count on page 417 Target engine bytes processed on page 417 Target "source" inserts on page 417
415
Target "source" updates on page 417 Target "source" deletes on page 418 Thread CPU - milliseconds/second on page 407 User exit CPU sec/100) on page 418 User exit elapsed (sec/100) on page 418
CPU time - seconds

UnitsCumulative CPU seconds DescriptionTracks the CPU time for Image Builders UsingUse this statistic to understand CPU usage. A large number can indicate a potential CPU bottleneck on the target.
Expression CPU (sec/100)

UnitsCumulative centiseconds (1/100th of a second) DescriptionCPU time spent in evaluating expressions. UsageProvides an indication of the processing overhead associated with processing expressions on the target.
Expression elapsed (sec/100)

UnitsCumulative centiseconds (1/100th of a second) DescriptionElapsed time spent evaluating expressions. UsageProvides an indication of the overall overhead associated with processing expressions on the target.
MBCS conversions - bytes

UnitsCumulative bytes DescriptionTracks the count of input bytes converted by character conversion UsingUse this statistic to understand activity on the target replication engine caused by to MBCS conversions. A large number may indicate a performance issue caused by MBCS processing.
Retry cache current bytes used

UnitsBytes DescriptionThe number of bytes currently in use by the retry cache for a UR. UsageProvides snapshots of the retry cache to characterize current storage usage.
Retry cache maximum bytes used

UnitsBytes
416
DescriptionThe maximum number of bytes used in the retry cache during the current run of the subscription. UsageProvides run-time data on actual retry cache requirements which can be used to optimize product configuration. If the maximum bytes approaches the configured RETRYCACHESIZE then the subscription is in danger of running into scenarios with large URs without the ability to retry. Also, each subscription's retry cache (along with staging space) is taken from global storage, so for safe operation the sum of the maximum bytes across all subscriptions should fit into global storage limits.
Rows calling target database - count

UnitsCumulative row count DescriptionTracks the number of rows with at least one call out to the target database. UsingUse this statistic to understand row activity. A large number can indicate a potential performance issue caused by calls out to the target database.
Rows calling user exits - count

UnitsCumulative row count DescriptionTracks the number rows with calls out to user functionality UsingUse this statistic to understand activity caused by to user exits. A large number can indicate a potential performance issue caused by calls out to user functionality.
Target engine bytes processed

UnitsCumulative bytes DescriptionA counter of bytes received from the source engine. UsageProvides an indication of the progress of the target engine in consuming data from the source. This number not advancing could be due to the target apply task being backed up on the database or the target communications tasks not receiving data.
Target "source" inserts

UnitsCumulative counter DescriptionNumber of record operations received from the source as inserts. UsageProvides an indication of the in-scope workload to be processed by the target engine.
Target "source" updates

UnitsCumulative counter DescriptionNumber of record operations received from the source as updates.
417
UsageProvides an indication of the in-scope workload generated to be processed by the target engine.
Target "source" deletes

UnitsCumulative counter DescriptionNumber of record operations received from the source as deletes. UsageProvides an indication of the in-scope workload to be processed by the target engine.

User exit CPU sec/100)

UnitsElapsed centiseconds (1/100th of a second) DescriptionCPU time spent in user exits. UsageProvides an indication of the processing overhead associated with user exits.
User exit elapsed (sec/100)

UnitsElapsed centiseconds (1/100th of a second) DescriptionElapsed time spent in user exits. UsageProvides an indication of the overall time spent within with user exits. In performance graphs with 1 second intervals, the units of centiseconds approximates a percentage, although the value may exceed 100 depending on sampling delays.
Target Apply metrics

These metrics allow you to analyze replication activities specific to the target database. The availability of metrics is determined by the datastore that the subscription belongs to; only the metrics relevant to that datastore will be displayed. See also: Adaptive Apply changes - count on page 419 Apply commits - counts on page 419 Average array size - count on page 419 CDR conflicts - count on page 419 CPU used - seconds on page 419 Data errors ignored - count on page 420 DB2 CPU (sec/100) on page 420
418
DB2 elapsed (sec/100) on page 420 Retry count on page 420 Slow database operations - count on page 420 SQL errors ignored - count on page 420 Target apply deletes on page 421 Target apply inserts on page 421 Target apply updates on page 421 Rows evaluating expressions - count on page 422 Target database bytes processed on page 422 Thread CPU - milliseconds/second on page 407
Adaptive Apply changes - count

UnitsCumulative count DescriptionTracks the number of adaptive changes during adaptive apply. UsingUse this statistic to understand adaptive change activity. A large number of conflicts can impact performance due to the resolution of the conflict logic.
Apply commits - counts

UnitsCumulative count DescriptionTracks the number of apply commits UsingUse this statistic to understand apply activity on the target database. A large number of commits can indicate that transaction grouping has been misconfigured.
Average array size - count

UnitsDiscrete value DescriptionTracks the average size of arrays in the last period UsingUse this statistic to understand InfoSphere CDC optimizer activity. A small number can indicate that the optimizer is not able to array operations to improve performance.
CDR conflicts - count

UnitsCumulative count DescriptionTracks the number of conflicts detected in conflict detection and resolution. UsingUse this statistic to understand conflict detection activity. A large number of conflicts can impact performance due to the resolution of the conflict logic.
CPU used - seconds

UnitsCumulative CPU seconds DescriptionTracks the CPU time used by the target database.
419
UsingUse this statistic to understand CPU usage. A value equal to the time period can indicate a CPU bottleneck.
Data errors ignored - count

UnitsCumulative count DescriptionA count of non-critical target exceptions that were ignored by InfoSphere CDC.
DB2 CPU (sec/100)

UnitsCumulative centiseconds DescriptionA counter of the amount of CPU time spent in DB2 calls. UsageProvides an indication of the extent that DB2 contributes to the overall CPU consumption of the target apply task (DTC).
DB2 elapsed (sec/100)

UnitsCumulative centiseconds (1/100th of a second) DescriptionIndicates the elapsed time spent in DB2 performing operations including SQL statement preparation, executing statements to process inserts, updates, deletes and queries. UsageProvides an indication of the extent to which the database is the limiting factor in replication throughput. When displayed in performance graphs at 1 second intervals the unit of centiseconds is approximately a percentage, although the value may exceed 100 if there are delays in data collection. A high value indicates that the database is the limiting factor.
Retry count
UnitsCounter DescriptionA count of the number of retries of failed database operations that are recoverable. UsageProvides an indication of the amount of contention on the database, for example due to record, page or tablespace locks held by other jobs.
Slow database operations - count

UnitsCumulative count DescriptionTracks the count of slow database operations. UsingUse this statistic to understand activity on the target database. A high value for this statistic can indicate a performance problem with the target database.
SQL errors ignored - count

UnitsCumulative count DescriptionTracks the number of SQL data errors that have been ignored.
420
UsingUse this statistic to understand data error activity. This value indicates the number of data errors that could have stopped the target replication engine but did not due to either the mirror_end_on_error and refresh_end_on_error system parameters being set to false.
Target apply deletes

UnitsCumulative counter DescriptionNumber of deletes being attempted with the database. The counter is incremented on retries. UsageProvides an indication of the type of workload being passed to the database by the subscription, both in terms of the type of record-level operation and the number of operations. Depending on actual data and configuration, this number may differ significantly from target source deletes - it reflects the outcome of target processing activity including: user exits, adaptive apply, conflict detection and resolution, row level operation settings.
Target apply inserts

UnitsCumulative counter DescriptionNumber of inserts being attempted with the database. The counter is incremented on retries. UsageProvides an indication of the type of workload being passed to the database by the subscription, both in terms of the type of record-level operation and the number of operations. Depending on actual data and configuration, this number may differ significantly from target source inserts - it reflects the outcome of target processing activity including: user exits, adaptive apply, conflict detection and resolution, row level operation settings.
Target apply updates

UnitsCumulative counter DescriptionNumber of updates being attempted with the database. The counter is incremented on retries. UsageProvides an indication of the type of workload being passed to the database by the subscription, both in terms of the type of record-level operation and the number of operations. Depending on actual data and configuration, this number may differ significantly from target source updates - it reflects the outcome of target processing activity including: user exits, adaptive apply, conflict detection and resolution, row level operation settings.
Note: If you are applying to a Netezza database this counter will display as N/A (Not Applicable) as InfoSphere CDC for Netezza databases does not perform update operations. Updates that occur on the source database are replicated using DELETE and INSERT operations to minimize impact on the Netezza database.
421
Rows evaluating expressions - count

UnitsCumulative row count DescriptionTracks the number of rows with at least one expression. UsingUse this statistic to understand activity caused by one or more derived expressions. A large number can indicate a potential performance issues caused by the execution of one or more expressions.
Target database bytes processed

UnitsCumulative bytes DescriptionCumulative count of the record sizes that are being passed to the database for inserts, updates and deletes. UsageProvides an indication of the data volume portion of the workload being passed to the database by the subscription.

Analyzing subscription performance

Note: The Performance view and the ability to analyze subscription performance is only available for datastores that support this feature. The Performance view of the Monitoring perspective allows you to view, investigate and diagnose the performance of subscriptions or tables within them to determine the causes of unexpected or unacceptable levels of latency. Many factors can contribute to latency. Environmental variables, such as CPU speed, memory allocation and network bandwidth, can affect replication performance. InfoSphere CDC configuration settings may also be a cause. The following list provides examples of common situations in which you may experience latency: v Insufficient network bandwidth for the volume of transactions that you are processing is increasing the amount of time between changes on the source table and the same change on the target table. To resolve this problem, contact your network administrator. v Resource intensive batch jobs or background tasks on either the source or target can result in increased latency for subscriptions until these processes are complete. v InfoSphere CDC is replicating changes for rows which contain large amounts of data in one or more Large Objects (LOB) columns. v A database lock contention in which an application on the target database may unexpectedly lock data in the database. This may force InfoSphere CDC to wait for the locks to be released.
422
v Indexes that are not optimized or lack a primary/unique key. This can cause slow database operations and result in performance issues that surface in InfoSphere CDC. To determine what is causing the latency to occur, use the Bottlenecks area of the Performance view to identify where bottlenecks are occurring. This view displays a bar chart featuring the five components of the InfoSphere CDC replication pipeline that can be identified as bottlenecks: v Log ReaderDisplays bottleneck intervals for the log reader on the source replication engine. v Source EngineDisplays bottleneck intervals for the log parser on the source replication engine. v CommunicationsDisplays bottleneck intervals for communications for the source replication engine. v Target EngineDisplays bottleneck intervals for the target replication engine. v Target DatabaseDisplays bottleneck intervals for the target database. The results of the bar chart will help you isolate where bottlenecks are occurring. Once you have identified the problem area, you can perform a more in-depth analysis by charting metrics specific to that area. You can analyze table-level performance, if you suspect that individual tables within a subscription are causing latency issues. InfoSphere CDC provides a list of the source tables in the subscription that are the most active. Before proceeding with table-level analysis, you should be aware that the collection of table-level statistics might require additional resources and can affect system performance. Additionally, you can export the information collected in the Monitoring perspective to a comma-delimited file for further analysis by clicking Export Statistics, located above the graphical display. See also: To To To To chart metrics for a subscription change the metrics when you are already collecting data chart metrics for tables on page 424 view the busiest tables in a subscription on page 424
To stop table-level performance monitoring on page 424
To chart metrics for a subscription

1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Right-click and select Show in Performance View. The Performance view opens. 4. Enable the Collect check box for the metrics you want to collect. 5. Click Collect Data. 6. Enable the Chart check box for the metrics you want to chart and view.
To change the metrics when you are already collecting data

1. Click Monitoring > Subscriptions. 2. Select a subscription.
423
3. Right-click and select Show in Performance View. The Performance view opens. 4. Click Collect Data. This will halt the collection of data. 5. Enable the Collect check box for the metrics you want to collect. 6. Click Collect Data. 7. Enable the Chart check box for the metrics you want to chart and view.
To chart metrics for tables

1. Click Monitoring > Subscriptions. 2. Select a subscription. Ensure that replication for the subscription has been performed since the address space was last restarted. 3. Right-click and select Show in Performance View. The Performance view opens. 4. Right-click on the subscription and select Select Tables.... The Select Tables dialog opens. 5. Select the tables to be monitored for performance. 6. Click OK. 7. Enable the Collect check box for the metrics you want to collect. 8. Click Collect Data. 9. Enable the Chart check box for the metrics you want to chart and view.
To view the busiest tables in a subscription

1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Right-click and select Show in Performance View. The Performance view opens. 4. Right-click on the subscription and select Busy Tables....
To stop table-level performance monitoring

1. Click Monitoring > Subscriptions. 2. Select a subscription. 3. Right-click and select Show in Performance View. The Performance view opens. 4. Right-click on the subscription and select Select Tables.... The Select Tables dialog opens. 5. Deselect all items.
424
System parameters let you control the behavior of Transformation Server. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in Transformation Server. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of Transformation Server. Transformation Server provides system parameters that control the behavior of your source and target datastores. Notes: v If you make changes to a system parameter during active replication, you must stop and restart replication for the changes to take effect. v When upgrading to a later version of Transformation Server, any preexisting settings for system parameters are maintained. In this section, you will learn: General product system parameters Replication system parameters on page 429 Database translation log system parameters on page 432 Commitment control system parameters on page 436 Event log system parameters on page 438 Multibyte character set system parameters on page 439 Latency system parameters on page 440 Notification system parameters on page 442 Tracing system parameters on page 445 Data type system parameters on page 449 Lock detection system parameters on page 449
General product system parameters

General product system parameters let you control basic features of InfoSphere CDC and information you may have specified during installation. See also: AuthCode on page 426 DBMS on page 426 dbUser on page 426 dllname on page 426 DSN on page 426 NetServiceName on page 427 pwdencrypt on page 427 Startup Timeout on page 427 TSSrcCP on page 428
425
TSTgtCP on page 428 TCP_KEEPALIVE_SECS on page 428 WindowsAuthentication on page 429
AuthCode
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to adjust the authorization code issued by IBM. You may need to modify your authorization code when: v Moving from a temporary license to a permanent license v Machine classes have changed v Upgrading to a new version of InfoSphere CDC Applies ToSource and Target Note: You can also modify the authorization using the Authorization Code Setup utility Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
DBMS
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier For information about setting this system parameter, see your IBM representative. Applies ToTarget
dbUser
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier For information about setting this system parameter, see your IBM representative. Applies ToSource and Target
dllname
DSN
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier
426
Use this system parameter to identify ODBC data source name used by InfoSphere CDC to define the metadata database on either the source or target system. Applies ToSource and Target Note: This parameter was specified during InfoSphere CDC installation. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
NetServiceName
pwdencrypt
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to encrypt or decrypt user identifiers and passwords stored in InfoSphere CDC metadata tables. Applies ToSource The pwdencrypt system parameters is set to either 0 or 1: v 0Do not encrypt user identifiers and passwords in metadata tables. v 1Encrypt user identifiers and passwords in metadata tables. Default Setting1 Guidelines Encryption or decryption does not affect existing user identifiers and passwords in InfoSphere CDC metadata tables. Any changes you make to this system parameter apply only to user identifiers and passwords added after setting the system parameter. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference Deadband Percentage on page 440
Startup Timeout
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier For information about setting this system parameter, see your IBM representative.
427
Applies ToSource and Target
TSSrcCP
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to identify the code page InfoSphere CDC uses for each instance of a target database. Applies ToSource Default SettingThe system code page when InfoSphere CDC was installed. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
TSTgtCP
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to identify the source system code page of InfoSphere CDC. Applies ToTarget Default SettingThe system code page when InfoSphere CDC was installed. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
TCP_KEEPALIVE_SECS
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to determine the time (in seconds) InfoSphere CDC waits before sending a keep alive notification over the network. During idle periods, InfoSphere CDC sends a keep alive notification to keep the connection open. Applies ToSource and Target Default Setting300 seconds (5 min) Minimum Setting0 Guidelines v To prevent the firewall from closing during active data replication, set this parameter to a value lower than the configured firewall timeout. v To set TCP_KEEPALIVE_SECS: 1. Create a registry key called HKEY_LOCAL_MACHINE\SOFTWARE\DataMirror\ InfoSphere CDC\Comms
428
2. Create a string value called TCP_KEEPALIVE_SECS under the registry key created above. 3. Set TCP_KEEPALIVE_SECS to the value that you want. Note: It is important you set this system parameter when you have a firewall connection that has been configured to timeout. This prevents the firewall from closing the connection. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
WindowsAuthentication
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier For information about setting this parameter, contact IBM Support. Applies ToSource and Target
Replication system parameters

Replication system parameters let you control how InfoSphere CDC behaves after detecting errors during replication. You can also control how often InfoSphere CDC communicates the status of replication activities, and how InfoSphere CDC should apply a refresh operation. See also: AutoRestart convertNotNullableColumns on page 430 MirrorError on page 430 RefreshError on page 431 RefreshMode on page 431
AutoRestart
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to enable or disable InfoSphere CDC to automatically restart replication after detecting a failover in a clustered environment. Applies ToSource The AutoRestart system parameters is set to either 0 or 1: v 0Disables automatic restart of replication operations. v 1Enables automatic restart of replication operations. Default Setting0
429
Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference convertNotNullableColumns
convertNotNullableColumns
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to indicate whether or not NULL values will be converted to default values when replicating data that contains NULL values to non-nullable target columns. Applies ToTarget Set this parameter to one of the following: v OFFAn error message will be generated in Event Log. Replication will continue or not based on whether the MirrorError or RefreshError system parameters are set to END or ON. v ONInfoSphere CDC will automatically insert an appropriate default value in the target column. No error message is generated in Event Log and replication continues. Depending on the convertNotNullableMsg system parameter setting, a warning message may be generated in Event Log. The default value depends on the data type of the subscription column. For example, zero for numeric data types, blank character for character data types, 1901-01-01 for date data types, and so on. Default SettingOFF Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference MirrorError RefreshError on page 431 implicit_transformation_warning on page 442 D_MIRROR_MIRROR_ERROR_STOP on page 543 D_MIRROR_REFRESH_ERROR_STOP on page 543
MirrorError
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to start or stop InfoSphere CDC from continuing mirroring when it encounters one or more errors.
430
Applies ToTarget The MirrorError system parameter can be set to either END or GO: v ENDStops mirroring after InfoSphere CDC encounters an error. v GOContinues mirroring after InfoSphere CDC encounters an error. Default SettingEND Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
RefreshError
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to start or stop InfoSphere CDC from continuing mirroring when it encounters one or more errors. Applies ToTarget The RefreshError system parameter can be set to either END or GO: v ENDInfoSphere CDC ends a refresh operation after it encounters one or more errors. v GOInfoSphere CDC continues a refresh operation after it encountering one or more errors. Default SettingEND Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
RefreshMode
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set how InfoSphere CDC applies rows to the target during a refresh operation. InfoSphere CDC can use BCP (bulk copy refresh) in which a block of rows are sent as a single unit during a refresh operation. This method is faster than the standard method of refreshing tables used by InfoSphere CDC. Applies ToTarget The RefreshMode system parameter can be set to either BCP or SQL: v BCPPerform a bulk copy refresh. v SQLPerform a standard refresh. Default SettingBCP
431
Note: Use the RefreshBlock system parameter to set the number of records in a block. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference RefreshBlock on page 437
Database translation log system parameters

Database transaction log system parameters let you control how InfoSphere CDC cleans the logs of the distribution database. You can also control often InfoSphere CDC reports its log position to the target and performs log synchronization between the source and the target. See also: Cleanup Interval Cleanup Log Events Cleanup Record Count on page 433 LogCleanupMethod on page 434 Report Position Interval on page 434 Synchronization Interval on page 435
Cleanup Interval
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set the time (in seconds) for InfoSphere CDC to clean up the distribution database on the source system. Applies ToSource Default Setting120 seconds Minimum Settings1 second Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
Cleanup Log Events

VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to enable or disable InfoSphere CDC from generating a notification during a cleanup cycle. InfoSphere CDC can generate regular notifications to indicate how many processed log entries it deleted from the distribution database during a cleanup cycle. If the cleanup cycle completes in a short period of time, then InfoSphere CDC only generates notifications that mark the start and end of each cleanup cycle.
432
Applies ToSource The Cleanup Log Events system parameter is set to either YES or NO: v YESGenerates notifications indicating the duration of the cleanup cycle and how many processed log entries have been deleted from the distribution database. v NODoes not generate notifications indicating the duration of the cleanup cycle and how many processed log entries have been deleted from the distribution database. Default SettingNO Notes: v InfoSphere CDC places notifications in the Event Log. v If you modify the value after setting the system parameter, InfoSphere CDC uses the modified value after completing the next cleanup cycle. v The time between consecutive cleanup cycles is determined by the Cleanup Interval system parameter. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Viewing replication events on page 393 Setting system parameters on source and target datastores on page 73
Cleanup Record Count

VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to increase or decrease the number of log entries InfoSphere CDC can delete from the distribution database during a cleanup cycle. Depending on the number of log entries you set for deletion and the amount of data being mirrored in your environment, multiple operations may be required to delete all processed log entries during a cleanup cycle. Applies ToSource Default Setting8000 log entries Minimum Settings100 log entries Maximum Settings100000 log entries Guidelines v You may want to reduce the number of operations applied to the distribution database and set this parameter to a higher number so that InfoSphere CDC can delete a greater number of log entries. Although this improves the performance of the cleanup cycle, a higher number of log entries can increase the amount of time it takes for InfoSphere CDC to complete the cleanup cycle. This can also conflict with other processes that use the distribution database (for example, the Microsoft log reader process and the InfoSphere CDC log scraper process). To avoid conflicts with other processes that access the distribution database, set this parameter to a smaller number of log entries that InfoSphere CDC can delete during a clean up cycle.
433
v To ensure a short cleanup cycle, set this parameter to the approximate number of log entries that InfoSphere CDC can delete in your environment in 1 second. Notes: v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. v If you modify the value after setting the system parameter, InfoSphere CDC uses the modified value after completing the next cleanup cycle. v The time between consecutive cleanup cycles is determined by the Cleanup Interval system parameter. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference Cleanup Log Events on page 432
LogCleanupMethod
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to enable or disable Transformation Server from using its own stored procedures to clean up transactions in the distribution database. Applies ToSource The LogCleanupMethod system parameter is set to either 0 or 1: v 0Use Microsoft stored procedures. v 1Use the products own stored procedures. Default Setting0 Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
Report Position Interval

VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set how often (in milliseconds) InfoSphere CDC informs the target system about its log position. When the source system is in idle mode and there are no log entries for the subscription, the source system informs the target system of its current log position. The target system uses this information to advance its bookmarks. Applies ToSource Default Setting5000 milliseconds (5 seconds) Minimum Settings1000 milliseconds (1 second)
434
Maximum Settings300000 milliseconds (5 minutes) Guidelines v If the number of milliseconds is set low, then the target system can provide accurate progress notifications that indicate how far replication has progressed. v If the number of milliseconds is set high, it may affect the accuracy of the information displayed in progress and bookmark notifications. Notes: v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. v This system parameter can also prevent InfoSphere CDC from rereading log entries that do not apply to the table currently being replicated. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Synchronization Interval
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set how often (in seconds) InfoSphere CDC performs log synchronization between the source and the target. Synchronization is achieved when the source reports to the target the position of the last committed change. Applies ToSource Default Setting60 seconds Minimum Settings1 second Maximum Settings3000 seconds (50 minutes) Guidelines If you are replicating large volumes of data, set this system parameter to a lower number of seconds to remove obsolete logs more frequently. Note: If a value outside the acceptable range is specified, the default setting is used.
435
Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Commitment control system parameters

Commitment control system parameters let you control how InfoSphere CDC issues commits to the target system. See also: CommitmentControl Commit Group Size on page 437 RefreshBlock on page 437 SeparateCommits on page 438
CommitmentControl
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to enable or disable InfoSphere CDC from using commitment control. Enabling commitment control maintains transaction consistency during replication and ensures that all transactions are applied to the target system. If there is a communications or server failure and you have enabled this system parameter, then InfoSphere CDC rolls back the partially applied transaction to the last commit. Applies ToSource The CommitmentControl system parameter is set to either 0 or 2: v 0Disables commitment control for transaction processing. InfoSphere CDC does not maintain transaction consistency during replication. v 2Enables InfoSphere CDC to use commitment control against the target system after applying all rows. This setting provides true transaction consistency by ensuring that entire transactions are committed to the target database even in the event of a communications or server failure Default Setting0 Note: You can set the maximum number of rows that InfoSphere CDC can contain a committed transaction using the RefreshBlock system parameter.
436
Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference RefreshBlock
Commit Group Size

VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Specifies the number of rows applied to the database before a commit is issued. Applies ToTarget This system parameter allows the subscriber to issue the commits on an interval basis rather than on each entry thus reducing the number of commits and leading to an improvement in overall apply performance. Note: This parameter only affects the commit size if the CommitmentControl parameter is set to 0. Specify the number of entries you want InfoSphere CDC to apply before issuing a commit. For example, if you set this parameter to 10, a commit is issued every ten entries. Default Setting0 rows. InfoSphere CDC does not use commit groups to perform synchronization.
RefreshBlock
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set the number of rows InfoSphere CDC can contain in a refresh block or a commit group. Depending on how you are refreshing data to the target, InfoSphere CDC can contain rows for bulk copy refresh or a commit group operations. Applies ToTarget Default Setting10000 records Guidelines v If the table you are replicating is relatively large, increase the number of records (refresh block or commit group) to improve performance. v If you are encounter errors during replication, reduce the number of records. Although performance is affected, lowering the number of records may eliminate these errors during replication.
437
Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference CommitmentControl on page 436 SeparateCommits
SeparateCommits
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to control how InfoSphere CDC commits bookmarks. InfoSphere CDC can commit bookmarks together or separate from the user data. For more information about bookmarks and how to retrieve bookmark values on the target, see Transformation Server for Microsoft SQL Server Commands Reference. Applies ToTarget The SeparateCommits system parameter can set to On or Off: v OnInfoSphere CDC commits the bookmark separate from user data. v OffInfoSphere CDC commits the bookmark together with the user data. Default SettingOff Guidelines Set this parameter to On only for performance reasons. If you set this parameter to On and InfoSphere CDC encounters an error during the apply process and ends the apply process abnormally, then this may result in the bookmark not being synchronized with the target system. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
Event log system parameters

Event log system parameters let you control how InfoSphere CDC interacts with notify message queues. See also: AllowEventLogClear
AllowEventLogClear
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier For information about setting this system parameter, see your IBM representative. Applies ToSource
438
Multibyte character set system parameters

Multibyte character set system parameters let you control how InfoSphere CDC treats character sets during replication. See also: Unicode Handling
Unicode Handling
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to indicate the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Applies ToSource Data types Use this system parameter: v nchar v nvarchar This system parameter is set to either CHAR or NOCHANGE: v CHARInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v NOCHANGEInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. NOCHANGE ensures InfoSphere CDC will handle non-single-byte character data in the same way as previous InfoSphere CDC releases. Default SettingNOCHANGE Note: NOCHANGE does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you many need to apply user exit programs or other customization to properly represent the data in Unicode columns. For more information about user exit programs, see your InfoSphere CDC for Microsoft SQL Server documentation
439
Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related tasks To set handling for Unicode character encoding on page 194
Latency system parameters

Latency system parameters let you control how often InfoSphere CDC generates a latency notification and updates latency statistics in the Event Log. See also: Deadband Percentage Monitor Sample Interval on page 442
Deadband Percentage
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Applies ToTarget Identifies the size of the range around each latency threshold setting. Based on latency thresholds defined, a latency message is generated when latency has risen above or fallen below a threshold. Latency is calculated at regular intervals, where the interval is the current setting for the MONITOR_SAMPLE_INTERVAL system parameter. You can set notifications in response to a generated latency message. This system parameter, which is expressed as a percentage, allows you to pad a threshold equally on both sides to create a range around the threshold. By adjusting this system parameter, the size of the range around the threshold can be increased or decreased, and the threshold itself can be made thicker or thinner. A latency message is generated only when latency has risen above the upper limit of the range or fallen below the lower limit of the range. By changing the value assigned to this system parameter, you can control the number of latency messages placed in the Event Log. For example, assume that a latency threshold is 5 minutes and this system parameter is set to 10. A 10% range is applied around the 5 minute threshold. The following calculations are performed to determine the lower and upper limits (in minutes) of the range around the threshold: v Padding = 10% of 5 minutes = 0.5 minutes (rounded up to 1 minute) v Padding is rounded up or down to the nearest whole minute: Upper limit of range = 5 minutes + 1 minute (padding) = 6 minutes Lower limit of range = 5 minutes - 1 minute (padding) = 4 minutes As a result, a latency message will be generated only when latency rises above 6 minutes or falls below 4 minutes. Given sample latency over a ten minute period where latency is calculated every minute, three latency messages are generated. This graph illustrates latency message generation with the DEADBAND_PERCENTAGE value set to 10%:
440
If this DEADBAND_PERCENTAGE is set to 3 (the default setting) for the same example, no padding is applied to the latency threshold. Therefore, a latency message is generated each time latency crosses over the latency threshold of 5 minutes. Based on the same sample latency in the previous graph where latency is calculated every minute, five latency messages are generated when this system parameter is set to 3. This graph illustrates latency message generation with the DEADBAND_PERCENTAGE value set to 3%:
If the number of latency messages generated over the ten minute period for the 10% (3 latency messages) and 3% (5 latency messages) settings are averages, an additional 288 latency messages would be generated each day if this system parameter is not changed from its default setting to 10%. Since there are two latency thresholds that you can set (a warning threshold and a problem threshold), two separate ranges are defined when padding is at least one minute. In this case, each range is attached to its threshold, and the two ranges can overlap with no change in behavior. If a value outside the acceptable range is specified, the default setting is used. Default Setting3% Minimum Setting3% Maximum Setting10% Note: If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults.
441
Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting latency thresholds and notifications on page 374 Setting system parameters on source and target datastores on page 73 Related reference pwdencrypt on page 427
Monitor Sample Interval

VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set how often (in seconds) InfoSphere CDC updates replication latency metrics. InfoSphere CDC samples the target system to determine if latency has risen above or fallen below the specified threshold settings. Applies ToSource and Target Default Setting5 seconds Minimum Setting0 seconds. Replication latency metrics are not updated. Maximum Setting3600 seconds (one hour) Notes: v InfoSphere CDC generates latency notifications when latency rises above or falls below the thresholds and places these in the Event Log. v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. Related concepts Setting latency thresholds and notifications on page 374 System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Notification system parameters

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: implicit_transformation_warning DM_STATUS_INTERVAL on page 443 Heartbeat Timeout on page 444 InvalidNumericMsg on page 444
implicit_transformation_warning
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier
442
Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference convertNotNullableColumns on page 430 DM_STATUS_INTERVAL Heartbeat Timeout on page 444 InvalidNumericMsg on page 444
DM_STATUS_INTERVAL
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set how often (in seconds) InfoSphere CDC issues progress notifications about the status of replication activities. On the source, progress notifications identify: v The bookmark sent by the source v The corresponding log name v The subscription name to which the bookmark was sent On the target, progress notifications identify: v The bookmark received by the target v The corresponding log name v The source ID from which the bookmark was received Applies ToSource and Target Default Setting0 seconds. No progress notifications will be issued.
443
Minimum Setting0 seconds. No progress notifications will be issued. Maximum Setting7200 seconds Notes: v InfoSphere CDC places progress notifications in the Event Log. v If a value outside the acceptable range is specified, the default setting is used. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
Heartbeat Timeout
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to increase or decrease the communication timeout interval (in minutes) before InfoSphere CDC detects a communication problem and attempts to stop active replication processes. InfoSphere CDC sends internal heartbeat notifications between the source and target systems to verify communications and the status of replication processes for each active subscription. If the source or target do not receive a reply to a notification within the specified timeout interval, then InfoSphere CDC determines that a problem has occurred and attempts to stop all its source and target processes for each active subscription. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Notes: v InfoSphere CDC places notifications (message identifiers 3165 and 11010) in the Event Log when a heartbeat timeout occurs. v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Viewing replication events on page 393 Setting system parameters on source and target datastores on page 73
InvalidNumericMsg
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to enable or disable InfoSphere CDC from generating a notification each time it detects an invalid numeric field.
444
Applies ToTarget The InvalidNumericMsg system parameter can be set to YES, NO, or NB. v YESGenerate a notification for each invalid numeric field detected by InfoSphere CDC. v NODo not generate a notification for each invalid numeric field detected by InfoSphere CDC. v NBGenerate a notification for certain types of invalid numeric fields detected by InfoSphere CDC. notifications are generated for each invalid numeric fields except those that are not initialized. Default SettingYES Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
Tracing system parameters

Tracing system parameters let you perform diagnostic activities with InfoSphere CDC. See also: CommTrace ProgramTrace on page 446 traceActive on page 446 TraceLevel on page 446 trcCleanup on page 447 trcCOMM on page 447 trcFiles on page 447 trcFncCalls on page 448 trcJrlSync on page 448 trcReplStatus on page 448 trcScan on page 448 trcSQL on page 448 trcThread on page 448
CommTrace
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to turn tracing of the communications module on or off. Applies ToTarget The CommTrace system parameter can be set to either ON or OFF: v ONActivates a communications module trace. v OFFDo not activate a communications module trace. Default SettingOFF
445
Notes: v The trace should only be produced if requested by DataMirror technical support. v Activating a trace adversely affects performance. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
ProgramTrace
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to activate or deactivate InfoSphere CDC from tracing the update module. Applies ToTarget The ProgramTrace system parameter can be set to either ON or OFF: v ONActivate an update module trace. v OFFDo not activate an update module trace. Default SettingOFF Notes: v The trace is encrypted and should only be produced if requested by IBM Support. v Activating a trace adversely affects performance. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
traceActive
TraceLevel
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set the level of detail produced by a program trace. Applies ToTarget The TraceLevel system parameter can be set to either 1, 2, or 3: v 1Produces a trace with the highest level of detail.
446
v 2Produces a trace with a medium level of detail. v 3Produces a trace with the lowest level of detail. Default Setting3 Note: Contact IBM Support for the suggested level of detail. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
trcCleanup
trcCOMM
trcFiles
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to identify the location of the file that contains information produced by an update or communications module trace. Applies ToSource and Target Default SettingInfoSphere CDC installation folder. Guidelines You must specify the full path of the folder where you want to place the trace file. Note: You can enable tracing using the ProgramTrace and CommTrace system parameters.
447
Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference CommTrace on page 445 ProgramTrace on page 446
trcFncCalls
trcJrlSync
trcReplStatus
trcScan
trcSQL
trcThread
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier For information about setting this system parameter, see your IBM representative.
448
Applies ToSource
Data type system parameters

Data type system parameters let you control how InfoSphere CDC handles certain data types. See also: TrimVarchar
TrimVarchar
Lock detection system parameters

Lock detection system parameters let you control how InfoSphere CDC applies data when it detects a locked table or row. See also: DeadlockRetrys DM_LOCK_DETECTION DM_LOCK_TIMEOUT on page 450
DeadlockRetrys
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to identify the number of attempts InfoSphere CDC applies a table or row-level operation (clear table, insert, update, or delete) to the target table after detecting a deadlock. If the operation cannot be applied after the specified number of attempts has been made, InfoSphere CDC cancels the operation and generates an error notification in Event Log. Applies ToTarget Default Setting3 attempts Related concepts Viewing replication events on page 393 System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
DM_LOCK_DETECTION
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to turn lock detection on or off. If InfoSphere CDC attempts to modify a table or row that has been locked by another process, then
449
turning lock detection ON enables InfoSphere CDC to wait for a specific amount of time before attempting to apply the data again. Applies ToSource and Target The DM_LOCK_DETECTION system can be set to either ON or OFF: v ONEnables table and row lock detection. v OFFDisables table and row lock detection. InfoSphere CDC waits until the locked row becomes available. Default SettingON Note: You can specify the time to wait using the DM_LOCK_TIMEOUT system parameter. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73 Related reference DM_LOCK_TIMEOUT
DM_LOCK_TIMEOUT
VersionTransformation Server for Microsoft SQL Server version 5.3 and earlier Use this system parameter to set the amount of time (in seconds) that InfoSphere CDC waits before attempting to modify a locked user or metadata table. When InfoSphere CDC attempts to modify a locked table, it places a notification in the Event Log. These notifications identify the specific table and row that InfoSphere CDC could not modify. Applies ToTarget Default Setting30 seconds Minimum Setting1 second Maximum Setting60 seconds Notes: v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. v Table locking notification is supported for tables containing user data and replication metadata tables. Related concepts System parameters for Transformation Server for Microsoft SQL Server (version 5.3 and earlier) on page 425 Setting system parameters on source and target datastores on page 73
450
System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Notes: v If you make changes to a system parameter during active replication, you must stop and restart InfoSphere CDC for the changes to take effect. v When upgrading to a later version of InfoSphere CDC, any preexisting settings for system parameters are maintained. In this section, you will learn: General product system parameters Notification system parameters on page 452 Maximize throughput system parameters on page 454 Encoding system parameters on page 455 Supplemental logging system parameters on page 456 Disk resource system parameters on page 457 Apply process system parameters on page 459

General product system parameters let you control basic features of InfoSphere CDC and information you may have specified during installation. See also: mirror_auto_restart_interval_minutes
mirror_auto_restart_interval_minutes
VersionInfoSphere CDC for Sybase version 6.3 Fix Pack 3 TFE 9 and later. Use this parameter to indicate how frequently (in minutes) InfoSphere CDC will attempt to automatically restart continuous mirroring for persistent subscriptions. InfoSphere CDC will continue in its attempts to restart mirroring at a defined interval until it is either successful, an unrecoverable error occurs or the process is manually stopped. Applies ToSource Default0 minutes
451
Minimum0 minutes Maximum60 minutes

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: events_max_retain global_shutdown_after_no_heartbeat_response_minutes global_conversion_not_possible_warning implicit_transformation_warning on page 453
events_max_retain
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647
global_shutdown_after_no_heartbeat_response_minutes
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Related concepts System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) on page 451 Setting system parameters on source and target datastores on page 73
global_conversion_not_possible_warning
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later
452
Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse Related concepts System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) on page 451 Setting system parameters on source and target datastores on page 73 Related reference global_default_after_database_minimum_timestamp on page 460 global_default_before_database_minimum_timestamp on page 461
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue
453
Maximize throughput system parameters

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: global_max_batch_size mirror_interim_commit_threshold refresh_commit_after_max_operations on page 455
global_max_batch_size
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter to specify the maximum number of rows that InfoSphere CDC can place in an array and apply to the target database during refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached. You can use this parameter during mirroring only if mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is empty. Before InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then InfoSphere CDC cannot allocate enough memory and will shut down. Management Console references this area to present replication latency information. Applies ToTarget Default Setting25 rows Maximum Setting2147483647 rows Minimum Setting1 row
mirror_interim_commit_threshold
VersionInfoSphere CDC for Microsoft SQL Server version 6.3 Fix Pack 3 and later.
454
By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter. The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations. Applies ToTarget Default Setting0 Minimum Setting0
refresh_commit_after_max_operations
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later This system parameter identifies the number of rows comprising each transaction during refresh. To reduce the workload on the target database during refresh, InfoSphere CDC periodically commits the changes to the target database rather than performing the refresh as a single large transaction. Applies ToTarget Default Setting1000 Maximum Setting2147483647 Minimum Setting1 Related concepts System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) on page 451 Setting system parameters on source and target datastores on page 73
Encoding system parameters

For some system parameters, you can set the default method for treating data in defined Unicode columns, and you can set the default character encoding for your database. See also: global_unicode_as_char on page 456
455
global_unicode_as_char
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later This system parameter indicates the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Set this parameter to one of the following: v trueInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. Setting this system parameter to false ensures that InfoSphere CDC handles non-single-byte character data in the same way as previous InfoSphere CDC releases. Note: Setting this parameter to false does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you may have to apply user exit programs or other customizations to properly represent data in Unicode columns. For more information about user exit programs, see the InfoSphere CDC End-User Documentation for your platform. Applies ToSource Default Settingfalse Note: The following SQL Server data types are considered to be Unicode columns and are therefore affected by the value assigned to this system parameter: v nchar v nvarchar Related concepts System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) on page 451 Setting system parameters on source and target datastores on page 73 Common encoding conversion scenarios on page 188
Supplemental logging system parameters

Some system parameter control the database logging mechanism used by InfoSphere CDC. See also: mirror_logging_by_empty_triggers on page 457 auto_configure_supplemental_logging on page 576 mirror_logging_by_empty_triggers on page 576
456
mirror_logging_by_empty_triggers
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later This system parameter allows you to choose empty triggers as your supplemental logging method for Microsoft SQL Server 2000. Set this parameter to one of the following: v trueEmpty triggers are used as your supplemental logging method for Microsoft SQL Server 2000. v falseThe Distribution Database is used as your supplemental logging method. This method of supplemental logging is available for Microsoft SQL Server 2000 and Microsoft SQL Server 2005. If you choose false and are using Microsoft SQL Server 2000, you must add your database to replication/publication with the following steps: 1. Set up Microsoft Replication and verify that the Distribution database exists. 2. Add the database to Microsoft Replication using the following query: EXEC sp_replicationdboption @dbname = 'your_db_name', @optname = 'publish', @value = 'true' Where your_db_name is your database name. Note that you can use the following query to check if your database is enabled for Microsoft Replication: exec sp_helpreplicationdboption Applies ToSource Default Settingtrue Related concepts System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) on page 451 Setting system parameters on source and target datastores on page 73
Disk resource system parameters

Some system parameters control memory usage in InfoSphere CDC. For improved performance, if you are able to allocate more than the default value of 512 MB for the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource system parameters to use the increased memory. See also: mirror_global_disk_quota_mb mirror_global_disk_quota_gb on page 458 staging_store_can_run_independently on page 459 staging_store_disk_quota_gb on page 459
mirror_global_disk_quota_mb
VersionInfoSphere CDC for Microsoft SQL Server version 6.3
457
Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions queues staged on the source and LOBs, which are staged on the target (for the record 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting100
mirror_global_disk_quota_gb
VersionInfoSphere CDC for Microsoft SQL Server version 6.5 Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1
458
staging_store_can_run_independently
VersionInfoSphere CDC for Microsoft SQL Server version 6.5 Use this system parameter to determine if subscriptions will exclusively use the InfoSphere CDC staging store to accumulate change data or if they will be allowed to use independent log readers and log parsers to receive data directly from the database logs. Set this parameter to one of the following values: v trueSpecifies that subscriptions can use either the staging store to accumulate change data or use independent log readers and log parsers to receive data directly from the database logs. v falseSpecifies that subscriptions will use the InfoSphere CDC staging store to accumulate change data. Changes to this system parameter value will only take effect after the replication engine is restarted. If you change the value from true to false, you will need to clear the staging store before starting replication. Applies ToSource Default Settingtrue
staging_store_disk_quota_gb
VersionInfoSphere CDC for Microsoft SQL Server version 6.5 Use this system parameter to specify the maximum amount of disk space that will be utilized by the InfoSphere CDC staging store on your source system. If you have enabled the Continuous Capture feature and you are accumulating change data in your staging store when subscriptions are stopped, you should take into consideration the additional disk utilization that this feature requires. Applies ToSource Default Setting100 GB Maximum Setting2147483647 GB Minimum Setting1 GB
Apply process system parameters

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column on page 460 global_default_after_database_minimum_timestamp on page 460 global_default_before_database_minimum_timestamp on page 461
459
mirror_end_on_error on page 461 mirror_expected_errors_list on page 461 refresh_end_on_error on page 462 refresh_expected_errors_list on page 462 refresh_loader_drop_index on page 462 refresh_with_referential_integrity on page 463 userexit_max_lob_size_kb on page 463
convert_not_nullable_column
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter to control how InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and InfoSphere CDC will generate a warning in the event log. When set to false, InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of InfoSphere CDC on the target database. Note: If you decided to set this system parameter to false and have specified this as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list system parameter, then InfoSphere CDC will ignore the error and not shutdown. Set this parameter to one of the following: v trueNull value will be replaced with default value for non-nullable column, and a warning event will be logged. v falseNull data will be applied as-is to non-nullable column and database will usually return an error code. Applies ToSource and Target Default SettingTrue
global_default_after_database_minimum_timestamp
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later In environments where the timestamp range in your source database differs from the target database, this system parameter allows you to control the default values that InfoSphere CDC sets on the target for out-of-range date-time values. Use this system parameter to control the value substituted by InfoSphere CDC in the target database when a value is being set on a target date-time column that is greater than the maximum accepted value for the target database. Note: To determine if a value is out-of-range, InfoSphere CDC converts the value to a timestamp data type and then validates the timestamp to determine if it is within range. Default Setting1901-01-01 00:00:00.000
460
Related reference global_conversion_not_possible_warning on page 452
global_default_before_database_minimum_timestamp
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later In environments where the timestamp range in your source database differs from the target database, this system parameter allows you to control the default values that InfoSphere CDC sets on the target for out-of-range date-time values. Use this system parameter to control the value substituted by InfoSphere CDC in the target database when a value is being set on a target date-time column that is less than the minimum accepted value for the target database. Note: To determine if a value is out-of-range, InfoSphere CDC converts the value to a timestamp data type and then validates the timestamp to determine if it is within range. Default Setting1901-01-01 00:00:00.000 Related reference global_conversion_not_possible_warning on page 452
mirror_end_on_error
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v trueEnd mirroring after an apply error on the target database. v falseDo not end mirroring after an apply error on the target database. Applies ToTarget Default SettingTrue Related concepts System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) on page 451 Setting system parameters on source and target datastores on page 73
mirror_expected_errors_list
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes.
461
Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
refresh_end_on_error
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter to indicate if you want to end a refresh after an apply error occurs. Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs. Applies ToTarget Default SettingTrue Related concepts System Parameters for InfoSphere CDC for Microsoft SQL Server (version 6.0 and later) on page 451 Setting system parameters on source and target datastores on page 73
refresh_expected_errors_list
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
refresh_loader_drop_index
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later This system parameter indicates whether or not InfoSphere CDC will drop all indexes on the tables being refreshed and then rebuild the indexes after the refresh. In most environments, this will improve refresh performance. If the refresh fails for any reason, InfoSphere CDC will write SQL statements to a file which will allow you to manually rebuild the indexes for all tables in your database. The location of the file is specified in the Management Console event log. Applies ToTarget Default Settingtrue
462
refresh_with_referential_integrity
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter to indicate whether or not you want the data removed from all the target tables being refreshed before repopulating any of them. This is most useful when there are referential integrity constraints on the tables being refreshed. Set this parameter to one of the following: v trueIndicates that InfoSphere CDC will first remove all data in reverse of the specified refresh order. When specifying the refresh order, in general parent tables should appear before the referenced child tables. The product will then remove data from the child tables before the parent tables. v falseIndicates that InfoSphere CDC will not first remove all data from your tables and will refresh the tables in the specified order. Applies ToSource Default Settingfalse
userexit_max_lob_size_kb
VersionInfoSphere CDC for Microsoft SQL Server version 6.0 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb
463
464
System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Note: If you make changes to a system parameter during active replication, you must stop and restart replication for the changes to take effect. In this section, you will learn: General product system parameters Apply process system parameters on page 475 Cascading replication system parameters on page 484 Database journal (trigger) system parameters on page 485 Maximize throughput system parameters on page 487 Tracing system parameters on page 492 Refresh loader system parameters on page 495 User exit system parameters on page 499 Table mapping system parameters on page 500 Notification system parameters on page 501 Disk resource system parameters on page 506

General product system parameters let you control basic features of InfoSphere CDC and information you may have specified during installation. See also: CODE_PAGE on page 466 DEFAULT_ORACLE_HOME on page 466 DEFAULT_ORACLE_SID on page 466 DEFAULT_ORACLE_USER on page 467 DM_COMMS_HOME on page 467 D_MIRROR_HOME on page 467 D_MIRROR_LOG on page 467 DM_DYNAMIC_PARAMETER_CHECK_INT on page 468 DM_MAX_MONITOR_ENTRIES on page 468 DM_TS_MAX_POOL_SIZE_MB on page 469 DM_TS_POOL_BLOCK_SIZE_MB on page 469 <subscription>_MAX_POOL_SIZE_MB on page 470
465
<subscription>_POOL_BLOCK_SIZE_MB on page 470 LD_LIBRARY_PATH on page 471 LIBPATH on page 471 ORACLE_HOME on page 471 ORACLE_SID on page 472 PASSWORD on page 472 PUBLISH_METADATA on page 472 RLD_SYSTEM_TXQSIZE on page 473 <subscription>_TXQSIZE on page 473 SHLIB_PATH on page 474 STARTUP_TIMEOUT on page 474 TCP_KEEPALIVE_SECS on page 474 USER on page 475
CODE_PAGE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the code page associated with NLS_LANG. This value is set during installation and should not be modified except under the guidance of a IBM Support. Applies ToSource and Target Default SettingThe system code page when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference NLS_LANG on page 481
DEFAULT_ORACLE_HOME
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this parameter to specify the installation directory for the Oracle database instance that is started by default. Modify this parameter only if you installed InfoSphere CDC in multiple database instances. Applies ToSource Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DEFAULT_ORACLE_SID
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier
466
Use this system parameter to specify the Oracle SID for the Oracle database instance that is started by default. Modify this parameter only if you installed InfoSphere CDC in multiple database instances. Applies ToSource Default SettingThe Oracle SID specified when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DEFAULT_ORACLE_USER
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the name of the user for the Oracle database instance that is started by default. Modify this parameter only if you installed InfoSphere CDC in multiple database instances. Applies ToSource Default SettingThe Oracle user specified when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DM_COMMS_HOME
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier For information about setting this system parameter, see your IBM representative.
D_MIRROR_HOME
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the directory (full path) where InfoSphere CDC is installed on the server. Applies ToSource and Target Default SettingThe installation directory specified when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
D_MIRROR_LOG
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the directory (full path) where InfoSphere CDC log files are located.
467
Applies ToSource and Target Default SettingThe log subdirectory in the installation directory specified when installing InfoSphere CDC. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DM_DYNAMIC_PARAMETER_CHECK_INT
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify how often, in seconds, InfoSphere CDC checks for changes to the values of dynamic system parameters during active replication to a subscription. For example, to check once a day, set this parameter to 216,000. The following system parameters are dynamic: v D_MIRROR_TRACE v D_MIRROR_TRACE_ON_ERROR (on the target only) v DM_PRINT_DIAGNOSTICS v STATISTICS_INTERVAL v SYNCHRONIZATION_COMMIT_GROUP_SIZE v SYNCHRONIZATION_INTERVAL Applies ToSource and Target Default Setting300 seconds (5 minutes) Minimum Setting0. InfoSphere CDC does not check for changes to dynamic system parameters. Maximum Setting2,147,483,648 (maximum integer) Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DM_MAX_MONITOR_ENTRIES
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to increase or decrease the number of subscriptions that InfoSphere CDC can support in the Monitor in Management Console. InfoSphere CDC allocates an entry for each source and target datastore within a subscription. For example, if you have a datastore that is being used as a source datastore within 20 subscriptions and as a target datastore within 10 subscriptions, then you must set this system parameter to at least 30. InfoSphere CDC will allocate 30 entries for this datastore. Applies ToSource Default Setting20 entries. By default, InfoSphere CDC can handle 20 subscriptions.
468
Minimum Setting1 entry Maximum Setting1000 entries
DM_TS_MAX_POOL_SIZE_MB
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter when you need to resize the staging store component of InfoSphere CDC. You can specify a value in megabytes (MB). After specifying the size of the staging store, you should specify the number of blocks you want InfoSphere CDC to create using the DM_TS_POOL_BLOCK_SIZE_MB system parameter. Applies ToSource This setting must be large enough to store data for the largest predicted transaction that occurs in the Oracle database. If the size of the active staging store is not large enough to accommodate all data, InfoSphere CDC issues an error message (Message ID 307) in the event log and shuts down. The staging store size should be at least 150% of the largest predicted transaction. Note: After changing the value of this parameter, you must set the journal position to the last applied position by running the SETJRNPOS command. Default Setting25% of the default setting for the RLD_SYSTEM_TXQSIZE system parameter which is 128 MB. For more information about the SETJRNPOS command, see the "SETJRNPOSSet journal position in the commands" section of the InfoSphere CDC for Oracle databases End-User Documentation. To set the journal position, see "Running the Bookmark Viewer Command and Setting the Journal Position on the Source" in the "Installing InfoSphere CDC" section of the InfoSphere CDC for Oracle databases End-User Documentation. Related reference DM_TS_POOL_BLOCK_SIZE_MB RLD_SYSTEM_TXQSIZE on page 473
DM_TS_POOL_BLOCK_SIZE_MB
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter when you are in the process of resizing the staging store component of InfoSphere CDC and need to specify a block size you want InfoSphere CDC to create for the staging store. You must have already specified the size of the staging store (in MB) using the DM_TS_MAX_POOL_SIZE_MB system parameter. The value you specify for DM_TS_POOL_BLOCK_SIZE_MB indicates the block size you want InfoSphere CDC to create for the staging store. The size you had specified with the DM_TS_MAX_POOL_SIZE_MB system parameter is adjusted based on the block size you specify. Applies ToSource
469
Default SettingNone. If you do not specify a block size for this system parameter, then InfoSphere CDC will create a maximum of 4 blocks (no larger than 20 MB each) of space for the staging store. For example, you may have specified 100 MB for the staging store using the DM_TS_MAX_POOL_SIZE_MB system parameter. In this scenario, InfoSphere CDC will create a maximum 5 blocks of 20 MB each. Related reference DM_TS_MAX_POOL_SIZE_MB on page 469
<subscription>_MAX_POOL_SIZE_MB
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter when you want to resize the staging store for a specific subscription. You can specify a value in megabytes (MB). After specifying the size of the staging store, you should specify the block size you want InfoSphere CDC to create using the <subscription>_POOL_BLOCK_SIZE_MB system parameter. Applies ToSource Default Setting--25% of the default setting for the RLD_SYSTEM_TXQSIZE system parameter which is 128 MB. This setting must be large enough to store data for the largest predicted transaction that occurs in the Oracle database. If the size of the active staging store is not large enough to accommodate all data, InfoSphere CDC issues an error message (Message ID 307) in the event log and shuts down. The staging store size should be at least 150% of the largest predicted transaction. Note: After changing the value of this parameter, you must set the journal position to the last applied position by running the SETJRNPOS command. For more information about the SETJRNPOS command, see the "SETJRNPOSSet journal position in the commands" section of the InfoSphere CDC for Oracle databases End-User Documentation. To set the journal position, see "Running the Bookmark Viewer Command and Setting the Journal Position on the Source" in the "Installing InfoSphere CDC" section of the InfoSphere CDC for Oracle databases End-User Documentation. Related reference RLD_SYSTEM_TXQSIZE on page 473 <subscription>_POOL_BLOCK_SIZE_MB
<subscription>_POOL_BLOCK_SIZE_MB
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter when you are in the process of resizing the staging store component for a specific subscription and need to specify a block size you want InfoSphere CDC to create for the staging store. You must have already specified the size of the staging store (in MB) using the <subscription>_TS_POOL_BLOCK_SIZE_MB system parameter. The value you specify for <subscription>_TS_POOL_BLOCK_SIZE_MB indicates the block size you want InfoSphere CDC to create for the staging store. The size you
470
had specified with the <subscription>_TS_POOL_BLOCK_SIZE_MB system parameter is adjusted based on the block size you specify. Applies ToSource Default SettingNone. If you do not specify a block size for this system parameter, then InfoSphere CDC will create a maximum of 4 blocks (no larger than 20 MB each) of space for the staging store. For example, you may have specified 100 MB for the staging store using the <subscription>_TS_POOL_BLOCK_SIZE_MB system parameter. In this scenario, InfoSphere CDC will create a maximum 5 blocks of 20 MB each. Related reference <subscription>_MAX_POOL_SIZE_MB on page 470
LD_LIBRARY_PATH
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the path to the InfoSphere CDC libraries and the database libraries for Solaris and Linux operating systems. This value is set during installation and should not be modified. Applies ToSource and Target Default SettingThe path to the InfoSphere CDC libraries and the Oracle libraries when InfoSphere CDC was installed Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
LIBPATH
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the path to the InfoSphere CDC libraries and the database libraries (for AIX operating systems). This value is set during installation and should not be modified. Applies ToSource and Target Default SettingThe path to the InfoSphere CDC libraries and the database libraries when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
ORACLE_HOME
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the Oracle home directory. Applies ToSource
471
Default SettingThe Oracle home directory specified when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
ORACLE_SID
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the Oracle SID. Applies ToSource Default SettingThe Oracle SID specified when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
PASSWORD
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to identify the encrypted database password, which can be set using the dmsetpass command. For information about dmsetpass, see dmsetpassSet Password in the Commands section of the InfoSphere CDC for Oracle documentation for version 6.2 and below. Applies ToSource This parameter was set during installation and should not be modified. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
PUBLISH_METADATA
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to enable or disable the display of InfoSphere CDC metadata tables in Management Console. Applies ToSource Set this parameter to one of the following: v OFFInfoSphere CDC metadata tables are not displayed in Management Console. v ONInfoSphere CDC metadata tables are displayed in the Add/Remove Tables dialog box, making them available to be selected for replication. Default SettingOFF
472
Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
RLD_SYSTEM_TXQSIZE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the size, in megabytes (MB), for the active transaction queue store maintained by InfoSphere CDC. The active transaction queue store contains data for concurrent transactions that have been extracted from the Oracle redo log. Applies ToSource This setting must be large enough to store data for all concurrent transactions that occur in the Oracle database. If the size of the active transaction queue store is not large enough to accommodate all data, InfoSphere CDC issues an error message and shuts down. Default Setting128 MB Minimum Setting5 MB Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
<subscription>_TXQSIZE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the size, in megabytes (MB), you want to allocate per subscription for the active transaction queue store. This area represents the amount of space required to store data for a single transaction, extracted from the Oracle redo log. This system parameter is useful when you want to allocate a specific amount of queue storage for a specific subscription you have added in Management Console. If you want all other subscriptions to use the same storage size, then use the RLD_SYSTEM_TXQSIZE to allocate queue storage size. Applies ToSource Default SettingThere is no default value for this system parameter. If you decide not to specify a value in megabytes for this system parameter, then InfoSphere CDC will use the value you specified for the RLD_SYSTEM_TXQSIZE system parameter. Notes: v The subscription name precedes the name of the system parameter (TXQSIZE). For example, sub1TXQSIZE. v The name of the system parameter is not case-sensitive. If you have added two subscriptions in Management Console named SUB1 and sub1, then both subscriptions will use the same value specified for the system parameter.
473
This system parameter applies only to the Redo Log edition of InfoSphere CDC for Oracle. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference RLD_SYSTEM_TXQSIZE on page 473 v
SHLIB_PATH
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the path to the InfoSphere CDC libraries and the database libraries for HP-UX operating systems. This value is set during installation and should not be modified. Applies ToSource and Target Default SettingThe path to the InfoSphere CDC libraries and the database libraries when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
STARTUP_TIMEOUT
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the maximum waiting period, in seconds, for process handling to complete during InfoSphere CDC startup. It indicates how long the InfoSphere CDC communication module waits for the database initialization program to start before timing out. Applies ToSource and Target. Target only for InfoSphere CDC for Teradata. Default Setting120 Minimum Setting60 Maximum Setting3600 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
TCP_KEEPALIVE_SECS
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this parameter to specify the time interval, during idle periods, to wait before sending a keep alive message over the network. If a connection is idle for the specified time interval, InfoSphere CDC sends a keep alive message to keep the connection open.
474
Applies ToSource and Target Setting this system parameter is needed in environments that have firewalls with timeout connection values, to prevent them from closing the connection. Set this parameter to a value lower than the firewall timeout, so that the firewall does not close the connection during data replication. To set this system parameter, do the following: 1. Create a file named dmcommparms.cfg in the <InfoSphere CDC install dir>/lib directory. 2. Insert the following line in the file: TCP_KEEPALIVE_SECS = <value>; where value is the setting for this system parameter. For example, to set to 1 minute, enter: TCP_KEEPALIVE_SECS = 60; Default Setting300 seconds (5 min) Minimum Setting0 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
USER
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the Oracle user name that was specified during installation. You can also set this user using the dmsetpass command. For information about dmsetpass, see the dmsetpassSet Password in the Commands section of the InfoSphere CDC for Oracle documentation for version 6.2 and earlier. Applies ToSource Default SettingThe InfoSphere CDC user specified when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convertNotNullableColumns on page 476 D_MIRROR_MIRROR_ERROR_LIST on page 476 D_MIRROR_MIRROR_ERROR_STOP on page 477 D_MIRROR_REFRESH_ERROR_LIST on page 477 D_MIRROR_REFRESH_ERROR_STOP on page 478 DM_ADAPTIVE_APPLY_SOFT_DELETES on page 478
475
DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME> on page 479 DM_ADAPTIVE_APPLY_MIMIC_SOURCE_OPERATION on page 479 DM_ARRAY_BIND_MAX on page 480 FILTER_NOCHANGE_UPDATES_FOR_AUDIT on page 480 NLS_LANG on page 481 NLS_NCHAR on page 481 NOT_NULL_DATE_DEFAULT on page 481 TRIM_CHAR_TO_VARCHAR on page 481 TRIM_VARCHAR_TO_VARCHAR on page 482 TRIM_TO_NULL on page 482 UNICODE_HANDLING on page 483
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to indicate whether or not NULL values will be converted to default values when replicating data that contains NULL values to non-nullable target columns. Applies ToTarget Set this parameter to one of the following: v OFFAn error message will be generated in Event Log. Replication will continue or not based on whether the MirrorError or RefreshError system parameters are set to END or ON. v ONInfoSphere CDC will automatically insert an appropriate default value in the target column. No error message is generated in Event Log and replication continues. Depending on the convertNotNullableMsg system parameter setting, a warning message may be generated in Event Log. The default value depends on the data type of the subscription column. For example, zero for numeric data types, blank character for character data types, 1901-01-01 for date data types, and so on. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference D_MIRROR_MIRROR_ERROR_STOP on page 477 D_MIRROR_REFRESH_ERROR_STOP on page 478 implicit_transformation_warning on page 501
D_MIRROR_MIRROR_ERROR_LIST
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to allow certain errors to be ignored during mirroring.
476
Applies ToTarget If the D_MIRROR_MIRROR_ERROR_STOP system parameter is set to ON, use this parameter to allow certain errors to be ignored during mirroring. The value assigned to this parameter is a comma-delimited list of Oracle or Sybase database error numbers. For example, to ignore primary key violations, but to stop mirroring on any other update errors, set D_MIRROR_MIRROR_ERROR_LIST=1. This value corresponds to the Oracle error "ORA-00001: unique constraint violated (<schema>.<constraint>)". Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference D_MIRROR_MIRROR_ERROR_STOP
D_MIRROR_MIRROR_ERROR_STOP
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this parameter to indicate whether or not mirroring continues after an error has occurred during a row insert, delete, or update operation. Applies ToTarget Set this parameter to one of the following: v ONMirroring stops after an error has occurred. v OFFMirroring continues after an error has occurred. Default SettingON Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference D_MIRROR_MIRROR_ERROR_LIST on page 476
D_MIRROR_REFRESH_ERROR_LIST
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to allow certain errors to be ignored during data refresh. Applies ToTarget If the D_MIRROR_REFRESH_ERROR_STOP on page 543 system parameter is set to ON, use this parameter to allow certain errors to be ignored during data refresh. The value assigned to this parameter is a comma-delimited list of Oracle or Sybase database error numbers. For example, to ignore primary key violations, but to stop refresh on any other update errors, set D_MIRROR_REFRESH_ERROR_LIST=1. This value corresponds to the Oracle error "ORA-00001: unique constraint violated (<schema>.<constraint>)".
477
Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference D_MIRROR_MIRROR_ERROR_STOP on page 477
D_MIRROR_REFRESH_ERROR_STOP
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to indicate whether or not InfoSphere CDC should continue to perform a refresh after encountering an error during a row insert operation. Applies ToTarget Set this parameter to one of the following: v ONData refresh stops after an error has occurred. v OFFData refresh continues after an error has occurred. Default SettingON Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference D_MIRROR_REFRESH_ERROR_LIST on page 477
DM_ADAPTIVE_APPLY_SOFT_DELETES
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to enable InfoSphere CDC to apply a soft delete on all target tables mapped using Adaptive Apply in a subscription. Applies ToTarget Set this parameter to one of the following: v ONWhen there is a delete on the source table, InfoSphere CDC either: updates the rows on all target tables if the rows exist, or inserts the rows on all target tables if the rows do not exist. v OFFWhen there is a delete on the source table, InfoSphere CDC either: deletes the rows on all target tables if the rows exist, or does nothing and issues an informational message in the Event log if the rows do not exist.
478
Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Enabling the apply of soft deletes (InfoSphere CDC for Oracle databases) on page 330
DM_ADAPTIVE_APPLY_<SCHEMA>.<TABLENAME>
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to enable InfoSphere CDC to apply a soft delete on a specific target table mapped using Adaptive Apply in a subscription. Applies ToTarget Set this parameter to one of the following: v ONWhen there is a delete on the source table, InfoSphere CDC either: updates the row on the target table if the row exists, or inserts the row on the target table if it does not exist. v OFFWhen there is a delete on the source table, InfoSphere CDC either: deletes the row on the target table if the row exists, or does nothing and issues an informational message in the Event log if the row does not exist. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Enabling the apply of soft deletes (InfoSphere CDC for Oracle databases) on page 330
DM_ADAPTIVE_APPLY_MIMIC_SOURCE_OPERATION
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to modify the how InfoSphere CDC applies data to the target when you have mapped your source and target tables using Adaptive Apply. If you enable this system parameter, InfoSphere CDC avoids performing a SELECT query on the target table and you may benefit with performance improvement. For information about setting this system parameter, see your IBM representative. Applies ToTarget Set this parameter to one of the following: v ONInfoSphere CDC avoids performing a SELECT query on the target table. v OFFInfoSphere CDC performs a SELECT query on the target table. Default SettingOFF
479
DM_ARRAY_BIND_MAX
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the maximum number of rows that InfoSphere CDC can place in an array and apply to the target database. InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached. Applies ToTarget Default Setting25 Minimum Setting1 Maximum SettingMaximum number of rows (integer) Guidelines Before InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then InfoSphere CDC cannot allocate enough memory and will shut down. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
FILTER_NOCHANGE_UPDATES_FOR_AUDIT
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to indicate whether or not updates that have identical before and after column images (that is, the row has been updated to the same value), are replicated to the target table for any tables configured for LiveAudit replication. Applies ToSource Set this parameter to one of the following: v OFFIf a row in a source table is updated to the same value, InfoSphere CDC replicates the value to the target table. v ONIf a row in a source table is updated to the same value, InfoSphere CDC does not replicate the value to the target table. This parameter only affects tables that are configured for LiveAudit replication. For non-audit tables, only updates that change the column data are replicated to the target tables.
480
Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
NLS_LANG
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the database character set preceded with a period. For more information about setting this system parameter, see your IBM representative. Applies ToSource and Target Default SettingThe database character set, preceded with a period, corresponding to the language selected when the database was installed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
NLS_NCHAR
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to set the database national character set. For information about setting this system parameter, see your IBM representative.
NOT_NULL_DATE_DEFAULT
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Applies ToTarget Specifies the default value that InfoSphere CDC assigns to a NULL date being replicated to a non-nullable date column on the target database. If this parameter is not specified, InfoSphere CDC uses the Default Setting. Default Setting1901-01-01 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference TRIM_TO_NULL on page 482
TRIM_CHAR_TO_VARCHAR
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify whether or not trailing blank characters are trimmed from source columns of CHAR data type when replicating data to target columns of VARCHAR data type.
481
Applies ToTarget Set this parameter to one of the following: v OFFTrailing blanks are not trimmed. v ONTrailing blanks are trimmed. If TRIM_TO_NULL =OFF, InfoSphere CDC inserts a single blank character in the target column. If TRIM_TO_NULL =ON and the target column is nullable, InfoSphere CDC inserts NULL in the column. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference TRIM_TO_NULL
TRIM_VARCHAR_TO_VARCHAR
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify whether or not trailing blank characters are trimmed from source columns of VARCHAR data type when replicating data to target columns of VARCHAR data type. Applies ToTarget Set this parameter to one of the following: v OFFTrailing blanks are not trimmed. v ONTrailing blanks are trimmed. If TRIM_TO_NULL =OFF, InfoSphere CDC inserts a single blank character in the target column. If TRIM_TO_NULL =ON and the target column is nullable, InfoSphere CDC inserts NULL in the column. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference TRIM_TO_NULL
TRIM_TO_NULL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify how source columns that contain blank characters only are handled during data replication. Applies ToTarget Set this parameter to one of the following: v OFFFor data mapped to VARCHAR columns, trailing blanks are trimmed or not to a single blank depending on the TRIM_CHAR_TO_VARCHAR and TRIM_VARCHAR_TO_VARCHAR system parameters. For data mapped to CHAR columns, setting this parameter to OFF has no effect.
482
v ONFor data mapped to CHAR columns, if the target column is nullable, InfoSphere CDC inserts NULL in the column. For CHAR data mapped to VARCHAR columns, if TRIM_CHAR_TO_VARCHAR =ON and the target column is nullable, InfoSphere CDC inserts NULL in the column. For VARCHAR data mapped to VARCHAR columns, if TRIM_VARCHAR_TO_VARCHAR =ON and the target column is nullable, InfoSphere CDC inserts NULL in the column. If the target column is non-nullable, source columns that contain blank characters only are handled according to the convertNotNullableColumns system parameter. The table below explains how the TRIM_ system parameters affect the data replicated to the target for source columns that contain blank characters only.
TRIM_ parameter settings TRIM_CHAR_ TO_ VARCHAR ON ON OFF OFF ON ON OFF OFF TRIM_ VARCHAR_ TRIM_ TO_ TO_ VARCHAR NULL ON OFF ON OFF ON OFF ON OFF ON ON ON ON OFF OFF OFF OFF Target data CHAR to VARCHAR NULL NULL Source data Source data VARCHAR to VARCHAR NULL Source data NULL Source data Any data type to CHAR NULL NULL NULL NULL Blanks Blanks Blanks Blanks
Single blank Single blank Single blank Source data Source data Source data Single blank Source data
Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference TRIM_VARCHAR_TO_VARCHAR on page 482 TRIM_CHAR_TO_VARCHAR on page 481
UNICODE_HANDLING
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to indicate the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Applies ToSource The following Oracle data types are considered to be Unicode columns, and are therefore affected by the value assigned to this system parameter: v NCHAR
483
v NVARCHAR2 v NCLOB This system parameter is set to either CHAR or NOCHANGE: v CHARInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v NOCHANGEInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. NOCHANGE ensures InfoSphere CDC will handle non-single-byte character data in the same way as previous InfoSphere CDC releases. Note: If replicating data to a non-Oracle target, NOCHANGE does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non single-byte character data, you may need to apply user exit programs or other customizations to properly represent data in Unicode columns. For more information about user exit programs, see your InfoSphere CDC for Oracle documentation. Default SettingNOCHANGE Note: NOCHANGE does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you many need to apply user exit programs or other customization to properly represent the data in Unicode columns. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187
Cascading replication system parameters

Cascading replication system parameters control InfoSphere CDC cascading replication. See also: CASCADE_OMIT_TARGETS PREVENT_RECURSION on page 485
CASCADE_OMIT_TARGETS
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to indicate whether or not cascading replication will be disabled for specific subscriptions. Applies ToSource The value assigned to this parameter is a comma-separated list of subscription names. Changes applied by InfoSphere CDC are not replicated to these subscriptions, even if you set the system parameter PREVENT_RECURSION to OFF. The list of subscriptions cannot exceed 1023 bytes in length.
484
Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference PREVENT_RECURSION
PREVENT_RECURSION
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this parameter to indicate whether or not to prevent cascading replication for bidirectional configurations. Applies ToSource Set this parameter to one of the following: v ONChanges applied by InfoSphere CDC are not be replicated back to the source database from where it came from. v OFFChanges made by InfoSphere CDC are replicated, except when filtered out by the CASCADE_OMIT_TARGETS system parameter. Default SettingON Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference CASCADE_OMIT_TARGETS on page 484
Database journal (trigger) system parameters

Database journal or trigger system parameters let you manage the InfoSphere CDC journal table. See also: REPORT_POSITION_INTERVAL MONITOR_PURGE_INTERVAL on page 486 MONITOR_REFRESH_PERIOD on page 486
REPORT_POSITION_INTERVAL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify how often (in seconds) the source informs the target about its position in the current journal during times of no activity. During times of no activity, when there are no journal entries to be processed pertaining to the current subscription, the source informs the target of its current position so that the target can advance its bookmarks accordingly. By specifying a low setting for this parameter, the target can reflect more accurately how far replication has progressed. Applies ToSource
485
After a shutdown and restart, you can use this system parameter to prevent InfoSphere CDC from rereading entries that do not apply to the current replication configuration. The value of this parameter affects the information that is displayed in progress and bookmark messages. A high value for this parameter may result in information that is not up-to-date being displayed. Default Setting5 Minimum Setting1 Maximum Setting300 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
MONITOR_PURGE_INTERVAL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the time interval between journal purges. When this time interval has elapsed, InfoSphere CDC removes from its journals all records that have been committed on all targets to which they are replicated. Applies ToSource Specify this parameter in the format #h#m#s, where # is the number of hours, minutes, and seconds, respectively. For example, 1h30m represents 1 hour and 30 minutes. If a time specification value is 0, you can omit it. Default Setting1h Minimum Setting1m Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
MONITOR_REFRESH_PERIOD
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this parameter to specify the time interval between journal polls. InfoSphere CDC performs journal polls to check for new changes on the source. Applies ToSource Note: If you replicate large volumes of data, set this parameter to its minimum value so that InfoSphere CDC checks for changes more frequently. Specify this parameter in the format #h#m#s, where # is the number of hours, minutes, and seconds, respectively. For example, 1h30m represents 1 hour and 30 minutes. If a time specification value is 0, you can omit it.
486
Default Setting5s Minimum Setting1s Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: COMMIT_GROUP_SIZE COMMIT_LEVEL on page 488 COMMIT_INTERVAL on page 488 MAINTAIN_TRANSACTION_CONSISTENCY on page 489 SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 489 SYNCHRONIZATION_INTERVAL on page 490 TRANSACTION_GROUP_SIZE on page 490 TRANSACTION_INTERVAL on page 491 TRANSACTION_RECORDS_THRESHOLD on page 491
COMMIT_GROUP_SIZE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the minimum number of rows InfoSphere CDC should apply to the database before a commit is issued. InfoSphere CDC issues a commit on the target when the transaction that contains the rows completes. Use the COMMIT_GROUP_SIZE and COMMIT_INTERVAL system parameters together. InfoSphere CDC issues a commit when either when the number of rows specified by COMMIT_GROUP_SIZE has been applied to the target, or when the time interval specified by COMMIT_INTERVAL has elapsed. Setting only one of these system parameters without the other can result in uncommitted data on the target. Applies ToTarget Default Setting5000 Minimum Setting0. InfoSphere CDC does not use commit groups to apply data to the target.
487
Guidelines Set this parameter to 0 if D_MIRROR_MIRROR_ERROR_STOP=OFF. If a rollback occurs, InfoSphere CDC rolls back all outstanding rows in the commit group. Since InfoSphere CDC is set to continue on error, you may lose data. Note: Use this parameter only if InfoSphere CDC is not running under commitment control (COMMIT_LEVEL =0).
COMMIT_LEVEL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to indicate the level of commitment control for InfoSphere CDC to process transactions. Applies ToTarget Set this parameter to one of the following: v 0Disables commitment control for transaction processing. No attempt to maintain transaction consistency is performed in the event that replication is interrupted. v 2When replication is interrupted, updates in a transaction that is partially applied on the source and target databases will be rolled back to the last transaction that was successfully committed. This level of commitment control provides true transaction consistency, and ensures that a transaction will not be partially applied on the target database. Replication resumes after the last transaction that was successfully committed. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
COMMIT_INTERVAL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the time interval between commits, in seconds, to limit the number of commits InfoSphere CDC issues on the target database. Use the COMMIT_GROUP_SIZE and COMMIT_INTERVAL system parameters together. InfoSphere CDC issues a commit when either when the number of rows specified by COMMIT_GROUP_SIZE has been applied to the target, or when the time interval specified by COMMIT_INTERVAL has elapsed. Setting only one of these system parameters without the other can result in uncommitted data on the target. When the COMMIT_INTERVAL time expires, InfoSphere CDC issues a commit on the target database for transactions that completed within that time interval. Applies ToTarget Default Setting60 Minimum Setting0. InfoSphere CDC issues a commit on a target database for each completed transaction.
488
Guidelines Set this parameter to 0 if D_MIRROR_MIRROR_ERROR_STOP=OFF. If a rollback occurs, InfoSphere CDC rolls back all outstanding rows in the commit group. Since InfoSphere CDC is set to continue on error, you may lose data. Note: Use this parameter only if InfoSphere CDC is not running under commitment control (COMMIT_LEVEL =0). Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference COMMIT_LEVEL on page 488 COMMIT_GROUP_SIZE on page 549 D_MIRROR_MIRROR_ERROR_STOP on page 477
MAINTAIN_TRANSACTION_CONSISTENCY
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to Indicate whether or not to maintain commitment control. Applies ToSource Set this parameter to one of the following: v OFFCommitment control is disabled. In this case, the COMMIT_LEVEL system parameter is treated as 0. v ONCommitment control is enabled. In this case, the COMMIT_LEVEL system parameter must be 0 or 2. Note: To enable commitment control, you must set MAINTAIN_TRANSACTION_CONSISTENCY=ON and COMMIT_LEVEL=2 before configuring any tables for mirroring. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference COMMIT_LEVEL on page 488
SYNCHRONIZATION_COMMIT_ GROUP_SIZE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the number of transactions applied to the database before InfoSphere CDC performs synchronization between the source and target. Applies ToSource and Target
489
The SYNCRONIZATION_COMMIT_GROUP_SIZE and SYNCHRONIZATION_INTERVAL system parameters are intended to be used together. Synchronization occurs either when the number of transactions (specified by SYNCRONIZATION_COMMIT_GROUP_SIZE) have been applied or when the time interval (specified by SYNCHRONIZATION_INTERVAL) has elapsed, whichever comes first. Default Setting128 Minimum Setting0. InfoSphere CDC does not use commit groups to perform synchronization. Maximum Setting2,147,483,648 (maximum integer) DynamicYes Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference SYNCHRONIZATION_INTERVAL
SYNCHRONIZATION_INTERVAL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the interval, in seconds, at which synchronization is performed between the source and target. Synchronization is achieved when the target reports to the source the position of the last committed change. Applies ToSource The SYNCRONIZATION_INTERVAL and SYNCHRONIZATION_COMMIT_ GROUP_SIZE system parameters are intended to be used together. Synchronization occurs either when the number of transactions (specified by SYNCHRONIZATION_COMMIT_ GROUP_SIZE ) have been applied or when the time interval (specified by SYNCRONIZATION_INTERVAL) has elapsed, whichever comes first. Default Setting1 Minimum Setting1 Maximum Setting300 DynamicYes Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 489
TRANSACTION_GROUP_SIZE
490
Use this system parameter to specify the number of complete transactions applied to the database before InfoSphere CDC issues a commit. Use the TRANSACTION_GROUP_SIZE, TRANSACTION_INTERVAL, and TRANSACTION_RECORDS_THRESHOLDS system parameters together. InfoSphere CDC issues a commit after applying the number of transactions specified by the TRANSACTION_GROUP_SIZE, or when the time interval specified by TRANSACTION_INTERVAL has elapsed. Setting only one of these system parameters without the other can result in uncommitted transactions on the target. Applies ToTarget Default Setting500 Minimum Setting0 Guidelines To increase the throughput, set to a number of transactions that would be received when busy during the TRANSACTION_INTERVAL. Note: Use this parameter only if InfoSphere CDC is running under commitment control. The COMMIT_LEVEL system parameter should be set to2 on the target database, and the MAINTAIN_TRANSACTION_CONSISTENCY system parameter should be set to ON on the source database.
TRANSACTION_INTERVAL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the time interval, in seconds, that can elapse between transactions before InfoSphere CDC issues a commit. If there are no transactions received by the target system, then InfoSphere CDC issues a commit immediately. Use this system parameter with the TRANSACTION_GROUP_SIZE system parameter. InfoSphere CDC issues a commit after applying the number of transactions specified by the TRANSACTION_GROUP_SIZE system parameter, or when the time interval specified by TRANSACTION_INTERVAL system parameter has elapsed. Setting only one of these system parameters without the other can result in uncommitted transactions on the target. Applies ToTarget Default Setting1 Minimum Setting0 Guidelines InfoSphere CDC issues a commit only when a commit is received by the target system and you have reached the transaction group size, or exceeded the time interval, or exceeded the records threshold.
TRANSACTION_RECORDS_THRESHOLD
491
Use this system parameter to specify the maximum number of operations within a transaction or group of transactions before InfoSphere CDC issues a commit Applies ToTarget Default Setting3000 Minimum Setting0

Tracing system parameters let you perform diagnostic activities with InfoSphere CDC. See also: D_MIRROR_SP_TRACE D_MIRROR_TRACE D_MIRROR_TRACE_FILE_SIZE on page 493 D_MIRROR_TRACE_ON_ERROR on page 493 DM_PRINT_DIAGNOSTICS on page 494 D_MIRROR_ALARM_TRACE on page 494
D_MIRROR_SP_TRACE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to enable tracing for your stored procedure user exit. Applies ToTarget Set this parameter to one of the following: v OFFTracing is disabled. v ONTracing is enabled and InfoSphere CDC creates the appropriate trace files in the log directory. These trace files are not encrypted. It is a plain ASCII text file and can be read directly for troubleshooting purposes. Default SettingOFF DynamicNo
D_MIRROR_TRACE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to indicate whether or not tracing is enabled. Applies ToSource and Target Set this parameter to one of the following: v OFFTracing is disabled. This setting has no effect when D_MIRROR_TRACE_ON_ERROR=ON.
492
v ONTracing is enabled and InfoSphere CDC creates the appropriate trace files in the log directory. These trace files are encrypted, and are meant to be sent to IBM technical support for troubleshooting purposes. When enabling this setting, also set the size of the trace file to an appropriate value using the D_MIRROR_TRACE_FILE_SIZE system parameter. To avoid disk space problems, set the size of the trace file to a value that is not too high. Default SettingOFF DynamicYes Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference D_MIRROR_TRACE_FILE_SIZE D_MIRROR_LOG on page 467 DIRPATH_LOGGING on page 498 D_MIRROR_ALARM_TRACE on page 494
D_MIRROR_TRACE_FILE_SIZE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the maximum size of a trace file in bytes. InfoSphere CDC creates two trace files. When the first trace file reaches its maximum size, InfoSphere CDC creates a second file. When the second trace file reaches its maximum size, InfoSphere CDC starts overwriting the first file. Applies ToSource and Target Default Setting10,000,000 bytes Minimum Setting1,000,000 bytes Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
D_MIRROR_TRACE_ON_ERROR
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify whether or not InfoSphere CDC enables tracing automatically when an error occurs. Applies ToSource and Target Set this parameter to one of the following: v OFFInfoSphere CDC does not enable tracing when an error occurs. v ONInfoSphere CDC enables tracing when an error occurs. InfoSphere CDC creates the appropriate trace files in the InfoSphere CDC log directory. These trace files are encrypted, and are meant to be sent to IBM technical support for troubleshooting purposes.
493
When enabling this setting, also set the size of the trace file to an appropriate value using the D_MIRROR_TRACE_FILE_SIZE system parameter. To avoid disk space problems, set the size of the trace file to a value that is not too high. Default SettingOFF DynamicYes (on the target only) Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference D_MIRROR_TRACE_FILE_SIZE on page 493
DM_PRINT_DIAGNOSTICS
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to Indicate whether or not to generate diagnostic messages in the InfoSphere CDC log files. Applies ToSource Set this parameter to one of the following: v OFFDiagnostic messages will not be generated. v ONDiagnostic messages will be generated. Note: If you enable tracing, it may cause large trace files to be created, which can consume a large amount of disk space and affect performance. To avoid running into disk space shortage problems, use this parameter only if advised by IBM technical support. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
D_MIRROR_ALARM_TRACE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to Indicate whether or not tracing for notification is enabled. Applies ToSource and Target Set this parameter to one of the following: v OFFTracing for notification is disabled. v ONTracing for notification is enabled. Tracing for notification is enabled when D_MIRROR_TRACE system parameter is also set to ON. The notification tracing will be located in the same trace file used for
494
regular tracing located in the directory specified by the D_MIRROR_LOG system parameter. The trace files are encrypted and are meant to be sent to IBM for troubleshooting purposes. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference D_MIRROR_TRACE on page 492
Refresh loader system parameters

Some system parameters affect how InfoSphere CDC applies refresh operations. See also: DIRPATH_BUF_ROWS DIRPATH_BUF_SIZE on page 496 DIRPATH_CACHE_DATE_SIZE on page 497 DIRPATH_LOAD on page 497 DIRPATH_LOGGING on page 498 DIRPATH_DO_RECOVERY on page 498
DIRPATH_BUF_ROWS
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the number of rows allocated in the internal buffer used for direct path loading. By setting this parameter to a value greater than 0, you can improve direct path loading performance. Applies ToTarget The table below explains how the DIRPATH_BUF_ROWS and DIRPATH_BUF_SIZE system parameters affect the size of the internal buffer that InfoSphere CDC uses for direct path loading.
DIRPATH_BUF_ SIZE 0 DIRPATH_BUF_ ROWS 0 Internal buffer size Determined dynamically, based on the size of the table being loaded. As specified by DIRPATH_BUF_ROWS. InfoSphere CDC allocates an internal buffer that is large enough to store the number of rows specified by DIRPATH_BUF_ROWS. As specified by DIRPATH_BUF_SIZE. As specified by DIRPATH_BUF_SIZE.
Greater than 0
Greater than 0 Greater than 0
0 Greater than 0
495
Default Setting0 Minimum Setting0 Maximum Setting231 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference DIRPATH_BUF_SIZE
DIRPATH_BUF_SIZE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the size, in bytes, for the internal buffer used for direct path loading. By setting this parameter to a value greater than 0, you can improve direct path loading performance. Applies ToTarget The table below explains how the DIRPATH_BUF_SIZE and DIRPATH_BUF_ROWS system parameters affect the size of the internal buffer that InfoSphere CDC uses for direct path loading.
DIRPATH_BUF_ SIZE 0 DIRPATH_BUF_ ROWS 0 Internal buffer size Determined dynamically, based on the size of the table being loaded. As specified by DIRPATH_BUF_ROWS. InfoSphere CDC allocates an internal buffer that is large enough to store the number of rows specified by DIRPATH_BUF_ROWS. As specified by DIRPATH_BUF_SIZE. As specified by DIRPATH_BUF_SIZE.
Greater than 0
Greater than 0 Greater than 0
0 Greater than 0
Default Setting0 Minimum Setting0 Maximum Setting231
496
Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference DIRPATH_BUF_ROWS on page 495
DIRPATH_CACHE_DATE_SIZE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the number of DATE (date and timestamp) values to be cached per table being refreshed, during direct path loading. If the table being refreshed contains DATE data type columns, you can improve direct path loading performance by setting this parameter to a value higher than the default setting. If the table being refreshed does not contain any DATE data type columns, this parameter has no effect. Applies ToTarget Default Setting0. DATE values are not cached. Minimum Setting0 Maximum Setting2^32 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DIRPATH_LOAD
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to enable or disable direct path loading. Applies ToTarget Set this parameter to one of the following: v ONDirect path loading is enabled. InfoSphere CDC uses Oracle Call Interface (OCI) functions to perform data refresh. By using OCI functions, InfoSphere CDC can load multiple rows by loading a direct path stream that contains data for multiple rows. Note: If you want to enable direct path loading, then you need perform a refresh on each subscription to send data to the target datastore. v OFFDirect path loading is disabled. Note: This setting is required in cascading replication configurations, to make sure that data changes are correctly replicated to the target tables. Default SettingON
497
DIRPATH_LOGGING
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Applies ToTarget Indicates whether or not full image redo logging is performed. This system parameter corresponds to the Oracle NOLOGGING keyword. Set this parameter to one of the following: v OFFFull image redo logging is not performed. Oracle generates a minimum number of redo log entries, thus providing improved performance. However, in case of instance failure, records that were inserted are marked as logically corrupted and cannot be recovered. v ONFull image redo logging is performed. Oracle inserts data with full image redo logging, which ensures that the necessary information is available in case of instance failure. For more information about image redo logging, see your Oracle documentation. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DIRPATH_DO_RECOVERY
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to modify how InfoSphere CDC handles rows that have conflicting unique index values. In Direct Path Load, InfoSphere CDC places an index in direct load state when it detects one or more conflicts after performing a refresh of all rows. Applies ToTarget v OFFNo rows are removed and the index remains in direct load state and ROWID of duplicate rows are stored in the exception table as indicated in the event log. v ONAll rows with conflicting unique index values will be removed and the index will be enabled. Default SettingOFF
498
User exit system parameters

Some system parameters control user exits. See also: D_MIRROR_SP_CONNECTION DM_FROM_CODEPAGE_V4USEREXIT DM_TO_CODEPAGE_V4USEREXIT on page 500
D_MIRROR_SP_CONNECTION
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to indicate whether or not a second connection to the Oracle database is established for a stored procedure user exit program to run. Applies ToTarget Set this parameter to one of the following: v OFFA second connection to the database is not established. The stored procedure user exit program and InfoSphere CDC will use the same, shared connection to the Oracle database. This setting ensures that changes to tables made by InfoSphere CDC are visible to the stored procedure user exit program. v ONA second connection to the database is established. The stored procedure user exit program will use this separate, second connection, to the Oracle database. Attention: If any stored procedure user exit program is issuing a commit or rollback, you must set this parameter to ON, otherwise data may be lost, or errors may be generated when applying data to the target database. Setting this parameter to ON does not affect stored procedure user exit programs for conflict resolution, or stored procedure user exit programs invoked within an expression, using the %STPROC column function. They will always use the same connection to the database as InfoSphere CDC. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DM_FROM_CODEPAGE_V4USEREXIT
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Applies ToTarget
499
Set this parameter only if using before or after images in C user exit programs defined in InfoSphere CDC Version 4.x. In InfoSphere CDC Version 4.x, the before and after images in C user exit programs were received in the code page of the source. In Version 5.1 and greater, they are received in the code page of the target. To use the user exit program as defined in Version 4.x, data must be translated back from the code page of the target to the code page of the source. Therefore, specify for this parameter the code page to translate from (the code page of the target). If this parameter is not set, no translation will be performed from the code page of the source to the code page of the target. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DM_TO_CODEPAGE_V4USEREXIT
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Applies ToTarget Set this parameter only if using before or after images in C user exit programs defined in InfoSphere CDC Version 4.x. In InfoSphere CDC Version 4.x, the before and after images in C user exit programs were received in the code page of the source. In Version 5.1 and higher, they are received in the code page of the target. To use the user exit program as defined in Version 4.x, data must be translated back from the code page of the target to the code page of the source. Therefore, specify for this parameter the code page to translate to (the code page of the source). If this parameter is not set, no translation will be performed from the code page of the target to the code page of the source. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
Table mapping system parameters

Some system parameters control table mappings. See also: TS_DELETE_ASSIGNED_OBJECTS_DURING_DESCRIBE
TS_DELETE_ASSIGNED_OBJECTS_DURING_DESCRIBE
500
Use this system parameter (when describing source tables to subscriptions) to specify whether or not to remove references to target tables when the mapped source table no longer exists. Applies ToTarget Set this parameter to one of the following: v OFFInfoSphere CDC does not remove references to target tables when the assigned source table no longer exists. v ONInfoSphere CDC removes references to target tables when the assigned source table no longer exists. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: implicit_transformation_warning DEADBAND_PERCENTAGE on page 502 DM_STATUS_INTERVAL on page 503 HEARTBEAT_TIMEOUT on page 504 LOG_EMAIL_USERNAME on page 504 MONITOR_SAMPLE_INTERVAL on page 505 STATISTICS_INTERVAL on page 505
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis.
501
v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
DEADBAND_PERCENTAGE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Applies ToTarget Identifies the size of the range around each latency threshold setting. Based on latency thresholds defined, a latency message is generated when latency has risen above or fallen below a threshold. Latency is calculated at regular intervals, where the interval is the current setting for the MONITOR_SAMPLE_INTERVAL system parameter. You can set notifications in response to a generated latency message. This system parameter, which is expressed as a percentage, allows you to pad a threshold equally on both sides to create a range around the threshold. By adjusting this system parameter, the size of the range around the threshold can be increased or decreased, and the threshold itself can be made thicker or thinner. A latency message is generated only when latency has risen above the upper limit of the range or fallen below the lower limit of the range. By changing the value assigned to this system parameter, you can control the number of latency messages placed in the Event Log. For example, assume that a latency threshold is 5 minutes and this system parameter is set to 10. A 10% range is applied around the 5 minute threshold. The following calculations are performed to determine the lower and upper limits (in minutes) of the range around the threshold: v Padding = 10% of 5 minutes = 0.5 minutes (rounded up to 1 minute) v Padding is rounded up or down to the nearest whole minute: Upper limit of range = 5 minutes + 1 minute (padding) = 6 minutes Lower limit of range = 5 minutes - 1 minute (padding) = 4 minutes As a result, a latency message will be generated only when latency rises above 6 minutes or falls below 4 minutes. Given sample latency over a ten minute period where latency is calculated every minute, three latency messages are generated. This graph illustrates latency message generation with the DEADBAND_PERCENTAGE value set to 10%:
502
If the number of latency messages generated over the ten minute period for the 10% (3 latency messages) and 3% (5 latency messages) settings are averages, an additional 288 latency messages would be generated each day if this system parameter is not changed from its default setting to 10%. Since there are two latency thresholds that you can set (a warning threshold and a problem threshold), two separate ranges are defined when padding is at least one minute. In this case, each range is attached to its threshold, and the two ranges can overlap with no change in behavior. If a value outside the acceptable range is specified, the default setting is used. Default Setting3% Minimum Setting3% Maximum Setting10% Note: If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Disk resource system parameters on page 506 Setting latency thresholds and notifications on page 374
DM_STATUS_INTERVAL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify how often progress messages should be issued in seconds. These messages are displayed in Event Log to indicate how replication is advancing and to provide detailed information about InfoSphere CDC replication activities. Applies ToSource and Target
503
Note: Low values of this parameter may result in many messages displayed in Event Log. In this situation, clear Event Log on a regular basis. Default Setting0 seconds. No progress notifications will be issued. Minimum Setting0 seconds. No progress notifications will be issued. Maximum Setting7200 seconds Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
HEARTBEAT_TIMEOUT
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this parameter to specify the number of minutes of communication inactivity to wait before active InfoSphere CDC processes for a subscription are stopped. Heartbeat is a feature that manages InfoSphere CDC processes when a problem with communications or a process has been detected through the absence of communications over a specified period of time. For each active subscription, internal heartbeat messages are sent regularly between the source and the target to determine communications and process status. If a reply to a message is not received by the source or target within the specified timeout interval, then InfoSphere CDC determines that a problem has occurred, and attempts to stop all its source and target processes for the subscription. In addition, messages (message identifiers 2612 and 3165) are placed in Event Log when heartbeat timeouts occur. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Viewing replication events on page 393
LOG_EMAIL_USERNAME
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the user name that receives e-mail messages in response to invoking the dmreadlog command or the warning message that is generated when Event Log exceeds the threshold value set by the LOG_MAX_SIZE system parameter. Applies ToSource and Target
504
In UNIX environments, the value assigned to this parameter is a comma-separated list of user names. The value of this parameter cannot exceed 30 bytes in length. To suppress all e-mail messages, set this parameter to NOMAIL. Default SettingThe InfoSphere CDC account (UNIX user) specified when InfoSphere CDC was installed Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Related reference STATISTICS_INTERVAL
MONITOR_SAMPLE_INTERVAL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to identify the period of time, in seconds, between consecutive updates to a storage area that is used to maintain replication latency metrics. Management Console references this area to present replication latency information. Applies ToSource and Target On the target, this setting also represents how often the storage area is sampled to determine if latency has risen above or fallen below specified threshold settings. InfoSphere CDC generates latency messages when latency rises above or falls below the thresholds. In response to a generated message, you can set latency notifications. If a value smaller than the minimum setting is specified, the minimum setting is used. If a value larger than the maximum setting is specified, the maximum setting is used. Default Setting5 seconds Minimum Setting0 seconds. Replication latency metrics are not updated. Maximum Setting3600 seconds Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 Setting latency thresholds and notifications on page 374
STATISTICS_INTERVAL
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify how often, in seconds, InfoSphere CDC issues messages that contain statistics information. These messages are displayed in Event Log. Applies ToSource and Target
505
Note: Use this parameter only if advised by IBM technical support. Default Setting0. InfoSphere CDC does not provide statistics information. Minimum Setting0. InfoSphere CDC does not provide statistics information. Maximum Setting2,147,483,647 (maximum integer) DynamicYes Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465

Some system parameters control memory usage in InfoSphere CDC. For improved performance, if you are able to allocate more than the default value of 512 MB for the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource system parameters to use the increased memory. See also: LOG_MAX_SIZE
LOG_MAX_SIZE
VersionInfoSphere CDC for Oracle databases version 6.2 and earlier Use this system parameter to specify the threshold size of Event Log in KB. A warning message is generated in Event Log when its size exceeds specified threshold. The messages in Event Log are deleted automatically when the size of Event Log is ten times the value specified by this parameter. Applies ToSource and Target If you do not want to specify a threshold size, set this parameter to NOMAX. Default Setting5000 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465
506
System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Note: If you make changes to a system parameter during active replication, you must stop and restart replication for the changes to take effect. In this section, you will learn: General product system parameters Transaction log location system parameters on page 508 Notification system parameters on page 512 Maximize throughput system parameters on page 514 Encoding system parameters on page 516 Disk resource system parameters on page 517 Apply process system parameters on page 520

General product system parameters let you control basic features of InfoSphere CDC and information you may have specified during installation. See also: mirror_auto_restart_interval_minutes mirror_set_table_data_capture_timeout on page 508
VersionInfoSphere CDC for Oracle version 6.3 Fix Pack 3 TFE 9 and later. Use this parameter to indicate how frequently (in minutes) InfoSphere CDC will attempt to automatically restart continuous mirroring for persistent subscriptions. InfoSphere CDC will continue in its attempts to restart mirroring at a defined interval until it is either successful, an unrecoverable error occurs or the process is manually stopped. Applies ToSource Default0 minutes Minimum0 minutes
507
Maximum60 minutes
mirror_set_table_data_capture_timeout
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to indicate how long (in seconds) InfoSphere CDC waits before declaring a failure when preparing a table for mirroring. Applies ToSource Default30 seconds Minimum0 seconds Maximum90 seconds
Transaction log location system parameters

Use these system parameters to indicate the location of your database transaction logs. See also: mirror_archive_log_directory mirror_asm_oracle_path mirror_online_log_directory on page 509 oracle_archive_dir on page 509 oracle_archive_destination_id on page 509 oracle_archive_logs_only on page 510 oracle_log_path_userexit on page 510 oracle_log_shipping on page 510 oracle_using_log_transport_services on page 511
mirror_archive_log_directory
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to override the directory for archiving log files for mirroring. Specify a directory that should be used instead of the one Oracle has specified. Applies ToSource Default SettingNo directory; instead, InfoSphere CDC will use the directory specified by Oracle.
mirror_asm_oracle_path
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter if the Oracle database uses ASM to manage its datafile or redo logs on a Linux system. Replace the ORCL label that references the common directory of the ASM-managed devices with the actual directory path.
508
mirror_online_log_directory
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to override the directory for reading online log files. Specify a directory that should be used instead of the one Oracle has specified. Applies ToSource Default SettingNo directory; instead, InfoSphere CDC will use the directory specified by Oracle.
oracle_archive_dir
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to specify the fully qualified path to the Oracle archive log when you are shipping your archive logs to another system. InfoSphere CDC only uses this value if you do not specify a Java class user exit in the oracle_log_path_userexit system parameter. For example, you can specify the following value: /archivelog/mycdcsystem/ Note: For RAC environments where the thread ID is not included in the archive log file name, InfoSphere CDC will read the archive logs from subdirectories that are named using the thread number. For example, /archivelog/mycdcsystem/1 for thread 1 and /archivelog/mycdcsystem/2 for thread 2. Applies ToSource Related reference oracle_log_path_userexit on page 510
oracle_archive_destination_id
VersionInfoSphere CDC for Oracle databases version 6.3 and later Note: You must indicate that you are using Oracle Data Guard log transport services with the oracle_using_log_transport_services system parameter before you can specify a value here. Use this system parameter to indicate the destination ID of the archive destination on the secondary system where you have configured the archived redo log repository. Set this system parameter to a numeric value between 1 and 10. For more information on using Oracle Data Guard and log transport services, see your Oracle documentation. Default Setting1 Applies ToSource
509
Related reference oracle_using_log_transport_services on page 511 oracle_log_shipping oracle_archive_dir on page 509
oracle_archive_logs_only
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to indicate that InfoSphere CDC will only use Oracle archive logs, not online redo logs. Set this parameter to one of the following: v trueInfoSphere CDC will only use Oracle archive logs. v falseInfoSphere CDC will use Oracle online redo logs and Oracle archive logs. Default Settingfalse Applies ToSource Related reference oracle_log_shipping
oracle_log_path_userexit
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to specify a Java class user exit that returns the fully qualified path to the Oracle archive log. You must implement the ArchiveLogPathUserExit user exit class as a Java class user exit and define the method that returns the fully qualified path to the system where you shipped the archive logs. The name of the archive log must be included in the path. You can customize the logic in the user exit to suit your business requirements. A sample user exit class, SampleArchiveLogPathUserExit, is installed with InfoSphere CDC. For more information on sample user exits and implementing a Java class user exit, see your InfoSphere CDC for Oracle documentation. Applies ToSource Related tasks To configure a user exit for a Java class on page 222 Related reference oracle_archive_dir on page 509
oracle_log_shipping
VersionInfoSphere CDC for Oracle databases version 6.3 and later
510
Use this system parameter to indicate whether or not InfoSphere CDC replication processes will 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. You can ship your archive logs in one of two ways: v Use Oracle Data Guard log transport services to ship your logs to an archived redo log repository on a secondary system that is accessible to InfoSphere CDC. In addition to this parameter, use the following system parameters to configure the product to run with this type of log shipping: oracle_using_log_transport_services oracle_archive_destination_id oracle_archive_dir oracle_archive_logs_only v Use scripts or some other method to ship your archive logs to a secondary system that is accessible to InfoSphere CDC. In addition to this parameter, use the following system parameters to configure the product to run with this type of log shipping: oracle_archive_dir oracle_log_path_userexit oracle_archive_logs_only Note: For both types of log shipping, the parameters used and the values specified may vary depending on your business requirements. Set this parameter to one of the following: v trueInfoSphere CDC replication processes will use copies of Oracle archive logs that are shipped to a secondary system. v falseInfoSphere CDC replication processes will not use copies of Oracle archive logs that are shipped to a secondary system. Default Settingfalse Applies ToSource Related reference oracle_archive_dir on page 509 oracle_log_path_userexit on page 510 oracle_archive_logs_only on page 510 oracle_using_log_transport_services oracle_archive_destination_id on page 509
oracle_using_log_transport_services
VersionInfoSphere CDC for Oracle databases version 6.3 and later Note: You must enable log shipping with the oracle_log_shipping system parameter before you can specify a value here.
511
Use this system parameter to indicate whether or not InfoSphere CDC will read logs from an archived redo log repository on a secondary system populated with Oracle Data Guard log transport services. When using log transport services to ship your logs: v The first archiving destination, the one with the lowest destination ID, must use the same file names as the log shipping destination. v The log shipping destination must use the ARCH archiver. For more information on how to configure Data Guard, see your Oracle documentation. Set this parameter to one of the following: v trueInfoSphere CDC will rely on Oracle Data Guard log transport services to ship archive logs to an archived redo log repository on a secondary system. v falseInfoSphere CDC will rely on a log shipping process managed by the user to ship archive logs to the secondary system. Default Settingfalse Applies ToSource Related reference oracle_archive_destination_id on page 509 oracle_log_shipping on page 510 oracle_archive_dir on page 509

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: events_max_retain global_conversion_not_possible_warning on page 513 global_shutdown_after_no_heartbeat_response_minutes on page 513 implicit_transformation_warning on page 513
events_max_retain
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647
512
Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations
513
on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: mirror_interim_commit_threshold mirror_sess_hist_age_threshold on page 515 mirror_src_ora_version on page 515 refresh_commit_after_max_operations on page 515 userexit_max_lob_size_kb on page 516
VersionInfoSphere CDC for Oracle version 6.3 Fix Pack 3 and later. By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter.
514
The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations. Applies ToTarget Default Setting0 Minimum Setting0
mirror_sess_hist_age_threshold
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to identify the number of days of session history to maintain. If the value is set to a positive number, the session history will be purged accordingly. A negative number results in the retention of all log information. Default Setting3 Minimum Setting -1 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
mirror_src_ora_version
VersionInfoSphere CDC for Oracle databases version 6.3 and later This system parameter identifies the database version of the primary database. If the primary database is version 10g or higher, then you must set this parameter on both the primary and backup systems. Set this parameter to the full database version number. For example, 10.2.0.1.0. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later This system parameter identifies the number of rows comprising each transaction during refresh. To reduce the workload on the target database during refresh, InfoSphere CDC periodically commits the changes to the target database rather than performing the refresh as a single large transaction. Applies ToTarget Default Setting1000
515
Maximum Setting2147483647 Minimum Setting1 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507

For some system parameters, you can set the default method for treating data in defined Unicode columns, and you can set the default character encoding for your database. See also: global_unicode_as_char
VersionInfoSphere CDC for Oracle databases version 6.3 and later This system parameter indicates the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Set this parameter to one of the following: v trueInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte
516
character data. Setting this system parameter to false ensures that InfoSphere CDC handles non-single-byte character data in the same way as previous InfoSphere CDC releases. Note: Setting this parameter to false does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you may have to apply user exit programs or other customizations to properly represent data in Unicode columns. For more information about user exit programs, see the InfoSphere CDC End-User Documentation for your platform. Applies ToSource Default Settingfalse For information about how data in each Unicode source column is treated and setting multibyte and Unicode character set conversions, see Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187. Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507

Some system parameters control memory usage in InfoSphere CDC. For improved performance, if you are able to allocate more than the default value of 512 MB for the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource system parameters to use the increased memory. See also: mirror_global_disk_quota_mb mirror_global_disk_quota_gb on page 518 staging_store_can_run_independently on page 518 staging_store_disk_quota_gb on page 519 staging_store_disk_quota_mb on page 519
VersionInfoSphere CDC for Oracle databases version 6.3 Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions queues staged on the source and LOBs, which are staged on the target (for the record 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable.
517
The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting100 Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.5 and later Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1
VersionInfoSphere CDC for Oracle databases version 6.5 and later Use this system parameter to determine if subscriptions will exclusively use the InfoSphere CDC staging store to accumulate change data or if they will be allowed to use independent log readers and log parsers to receive data directly from the database logs.
518
Set this parameter to one of the following values: v trueSpecifies that subscriptions can use either the staging store to accumulate change data or use independent log readers and log parsers to receive data directly from the database logs. v falseSpecifies that subscriptions will use the InfoSphere CDC staging store to accumulate change data. Changes to this system parameter value will only take effect after the replication engine is restarted. If you change the value from true to false, you will need to clear the staging store before starting replication. Applies ToSource Default Settingtrue
VersionInfoSphere CDC for Oracle databases version 6.5 and later Use this system parameter to specify the maximum amount of disk space that will be utilized by the InfoSphere CDC staging store on your source system. If you have enabled the Continuous Capture feature and you are accumulating change data in your staging store when subscriptions are stopped, you should take into consideration the additional disk utilization that this feature requires. Applies ToSource Default Setting100 GB Maximum Setting2147483647 GB Minimum Setting1 GB
staging_store_disk_quota_mb
VersionInfoSphere CDC for Oracle databases version 6.3 Use this system parameter to specify the maximum amount of disk space that will be utilized by the InfoSphere CDC staging store on your source system. If you have enabled the Continuous Capture feature and you are accumulating change data in your staging store when subscriptions are stopped, you should take into consideration the additional disk utilization that this feature requires. Applies ToSource Default Setting2147483647 MB Maximum Setting2147483647 MB Minimum Setting100 MB
519

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column global_max_batch_size mirror_end_on_error on page 521 mirror_expected_errors_list on page 521 refresh_end_on_error on page 522 refresh_expected_errors_list on page 522 refresh_in_unicode on page 523 refresh_with_referential_integrity on page 523 trim_char_to_varchar on page 523 trim_varchar_to_varchar on page 524 userexit_max_lob_size_kb on page 524
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to control how InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and InfoSphere CDC will generate a warning in the event log. When set to false, InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of InfoSphere CDC on the target database. Note: If you decided to set this system parameter to false and have specified this as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list system parameter, then InfoSphere CDC will ignore the error and not shutdown. Set this parameter to one of the following: v trueNull value will be replaced with default value for non-nullable column, and a warning event will be logged. v falseNull data will be applied as-is to non-nullable column and database will usually return an error code. Applies ToSource and Target Default SettingTrue Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later
520
Use this system parameter to specify the maximum number of rows that InfoSphere CDC can place in an array and apply to the target database during refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached. You can use this parameter during mirroring only if mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is empty. Before InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then InfoSphere CDC cannot allocate enough memory and will shut down. Management Console references this area to present replication latency information. Applies ToTarget Default Setting25 rows Maximum Setting2147483647 rows Minimum Setting1 row
mirror_end_on_error
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v trueEnd mirroring after an apply error on the target database. v falseDo not end mirroring after an apply error on the target database. Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue mirroring when it encounters primary key violations in your Oracle target database, set this
521
parameter to mirror_expected_errors_list=1. The integer error code of 1 corresponds to the Oracle error: ORA-00001: unique constraint violated (<schema>.<constraint>). If you also want to ignore ORA-01407: cannot update (string) to NULL, set this parameter to mirror_expected_errors_list=1,1407. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to indicate if you want to end a refresh after an apply error occurs. Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs.
Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue refresh when it encounters primary key violations in your Oracle target database, set this parameter to mirror_expected_errors_list=1. The integer error code of 1 corresponds to the Oracle error: ORA-00001: unique constraint violated (<schema>.<constraint>). If you also want to ignore ORA-01407: cannot update (string) to NULL, set this parameter to mirror_expected_errors_list=1,1407. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
522
refresh_in_unicode
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter when you want InfoSphere CDC to refresh a target table that contains multibyte object names. Set this parameter to one of the following: v trueInfoSphere CDC will refresh the target table that contains multibyte object names. v falseInfoSphere CDC will not refresh a target table that contains multibyte object names. Applies ToTarget Default Settingfalse Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to indicate whether or not you want the data removed from all the target tables being refreshed before repopulating any of them. This is most useful when there are referential integrity constraints on the tables being refreshed. Set this parameter to one of the following: v trueIndicates that InfoSphere CDC will first remove all data in reverse of the specified refresh order. When specifying the refresh order, in general parent tables should appear before the referenced child tables. The product will then remove data from the child tables before the parent tables. v falseIndicates that InfoSphere CDC will not first remove all data from your tables and will refresh the tables in the specified order. Applies ToSource Default Settingfalse
trim_char_to_varchar
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v v trueInfoSphere CDC strips the data of trailing blanks. falseInfoSphere CDC does not strip the string data of trailing blanks.
Applies ToTarget
523
Default Settingfalse Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
trim_varchar_to_varchar
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v trueInfoSphere CDC strips the data of trailing blanks. v falseInfoSphere CDC does not strip the string data of trailing blanks. Applies ToTarget Default Settingfalse Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.3 and later) on page 507
VersionInfoSphere CDC for Oracle databases version 6.3 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb Related concepts System parameters for InfoSphere CDC Event Server on page 653 Setting system parameters on source and target datastores on page 73
524
System parameters for InfoSphere CDC for Oracle databases (trigger) (version 6.3 and later)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Note: If you make changes to a system parameter during active replication, you must stop and restart replication for the changes to take effect. In this section, you will learn: General product system parameters Notification system parameters on page 526 Maximize throughput system parameters on page 527 Database journal (trigger) system parameters on page 528 Encoding system parameters on page 529 Disk resource system parameters on page 530 Apply process system parameters on page 531

VersionInfoSphere CDC for Oracle - Trigger version 6.3 Fix Pack 3 TFE 9 and later. Use this parameter to indicate how frequently (in minutes) InfoSphere CDC will attempt to automatically restart continuous mirroring for persistent subscriptions. InfoSphere CDC will continue in its attempts to restart mirroring at a defined interval until it is either successful, an unrecoverable error occurs or the process is manually stopped. Applies ToSource Default0 minutes Minimum0 minutes
525
Maximum60 minutes

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: events_max_retain global_conversion_not_possible_warning global_shutdown_after_no_heartbeat_response_minutes implicit_transformation_warning on page 527
events_max_retain
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later
526
Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: mirror_interim_commit_threshold on page 528
527
VersionInfoSphere CDC for Oracle - Trigger version 6.3 Fix Pack 3 and later. By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter. The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations. Applies ToTarget Default Setting0 Minimum Setting0
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later This system parameter identifies the number of rows comprising each transaction during refresh. To reduce the workload on the target database during refresh, InfoSphere CDC periodically commits the changes to the target database rather than performing the refresh as a single large transaction. Applies ToTarget Default Setting1000 Maximum Setting2147483647 Minimum Setting1

Database journal or trigger system parameters let you manage the InfoSphere CDC journal table. See also: mirror_journal_schema on page 529
528
mirror_journal_schema
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to enable multiple instances of InfoSphere CDC to share the same trigger and journal table. To enable this system parameter, you must specify the name of the journal that you want shared with another instance of InfoSphere CDC. For example, if you have created an instance INSTANCE1 that specifies the journal SCHEMA1, and created another instance INSTANCE2 that specifies the journal SCHEMA2, then you would set the system parameter mirror_journal_schema on INSTANCE2 so that it points to the journal SCHEMA1. This enables both instances to share the same trigger and journal table. You can only set a value for this system parameter before mapping your tables and setting the subscription for mirroring. The value of this system parameter must refer to the name of an existing journal table. Applies ToSource Default SettingNot applicable

VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later This system parameter indicates the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Set this parameter to one of the following: v trueInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. Setting this system parameter to false ensures that InfoSphere CDC handles non-single-byte character data in the same way as previous InfoSphere CDC releases. Note: Setting this parameter to false does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you may have to apply user exit programs or other customizations to properly represent data in
529
Unicode columns. For more information about user exit programs, see the InfoSphere CDC End-User Documentation for your platform. Applies ToSource Default Settingfalse For information about how data in each Unicode source column is treated and setting multibyte and Unicode character set conversions, see Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187.

Some system parameters control memory usage in InfoSphere CDC. For improved performance, if you are able to allocate more than the default value of 512 MB for the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource system parameters to use the increased memory. See also: mirror_global_disk_quota_mb mirror_global_disk_quota_gb on page 531
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions queues staged on the source and LOBs, which are staged on the target (for the record 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting100
530
VersionInfoSphere CDC for Oracle databases (trigger) version 6.5 Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column global_max_batch_size on page 532 mirror_end_on_error on page 532 mirror_expected_errors_list on page 533 refresh_end_on_error on page 533 refresh_expected_errors_list on page 533 refresh_in_unicode on page 534 refresh_with_referential_integrity on page 534 trim_char_to_varchar on page 535 trim_varchar_to_varchar on page 535 userexit_max_lob_size_queue_kb on page 535
531
Use this system parameter to control how InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and InfoSphere CDC will generate a warning in the event log. When set to false, InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of InfoSphere CDC on the target database. Note: If you decided to set this system parameter to false and have specified this as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list system parameter, then InfoSphere CDC will ignore the error and not shutdown. Set this parameter to one of the following: v trueNull value will be replaced with default value for non-nullable column, and a warning event will be logged. v falseNull data will be applied as-is to non-nullable column and database will usually return an error code. Applies ToSource and Target Default SettingTrue
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to specify the maximum number of rows that InfoSphere CDC can place in an array and apply to the target database during refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached. You can use this parameter during mirroring only if mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is empty. Before InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then InfoSphere CDC cannot allocate enough memory and will shut down. Management Console references this area to present replication latency information. Applies ToTarget Default Setting25 rows Maximum Setting2147483647 rows Minimum Setting1 row
mirror_end_on_error
532
Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v trueEnd mirroring after an apply error on the target database. v falseDo not end mirroring after an apply error on the target database. Applies ToTarget Default SettingTrue
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue mirroring when it encounters primary key violations in your Oracle target database, set this parameter to mirror_expected_errors_list=1. The integer error code of 1 corresponds to the Oracle error: ORA-00001: unique constraint violated (<schema>.<constraint>). If you also want to ignore ORA-01407: cannot update (string) to NULL, set this parameter to mirror_expected_errors_list=1,1407. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to indicate if you want to end a refresh after an apply error occurs. Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs.
Applies ToTarget Default SettingTrue
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must
533
correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue refresh when it encounters primary key violations in your Oracle target database, set this parameter to mirror_expected_errors_list=1. The integer error code of 1 corresponds to the Oracle error: ORA-00001: unique constraint violated (<schema>.<constraint>). If you also want to ignore ORA-01407: cannot update (string) to NULL, set this parameter to mirror_expected_errors_list=1,1407. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
refresh_in_unicode
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter when you want InfoSphere CDC to refresh a target table that contains multibyte object names. Set this parameter to one of the following: v trueInfoSphere CDC will refresh the target table that contains multibyte object names. v falseInfoSphere CDC will not refresh a target table that contains multibyte object names.
Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to indicate whether or not you want the data removed from all the target tables being refreshed before repopulating any of them. This is most useful when there are referential integrity constraints on the tables being refreshed. Set this parameter to one of the following: v trueIndicates that InfoSphere CDC will first remove all data in reverse of the specified refresh order. When specifying the refresh order, in general parent tables should appear before the referenced child tables. The product will then remove data from the child tables before the parent tables. v falseIndicates that InfoSphere CDC will not first remove all data from your tables and will refresh the tables in the specified order. Applies ToSource Default Settingfalse
534
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v v trueInfoSphere CDC strips the data of trailing blanks. falseInfoSphere CDC does not strip the string data of trailing blanks.
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v trueInfoSphere CDC strips the data of trailing blanks. v falseInfoSphere CDC does not strip the string data of trailing blanks.
userexit_max_lob_size_queue_kb
VersionInfoSphere CDC for Oracle databases (trigger) version 6.3 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb
535
536
System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Note: If you make changes to a system parameter during active replication, you must stop and restart replication for the changes to take effect. In this section, you will learn: General product system parameters Apply process system parameters on page 542 Cascading replication system parameters on page 548 Database journal (trigger) system parameters on page 548 Maximize throughput system parameters on page 549 Tracing system parameters on page 552 Notification system parameters on page 554 Disk resource system parameters on page 559 Refresh loader system parameters on page 560

General product system parameters let you control basic features of InfoSphere CDC and information you may have specified during installation. See also: CODE_PAGE on page 538 D_MIRROR_HOME on page 538 D_MIRROR_LOG on page 538 DM_DYNAMIC_PARAMETER_CHECK_INT on page 538 DM_MAX_MONITOR_ENTRIES on page 539 DSQUERY on page 539 LD_LIBRARY_PATH on page 540 LIBPATH on page 540 PUBLISH_METADATA on page 540 SYBASE on page 541 SYBASE_OCS on page 541 SHLIB_PATH on page 541 STARTUP_TIMEOUT on page 541 USER on page 542
537
CODE_PAGE
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the code page associated with NLS_LANG. This value is set during installation and should not be modified except under the guidance of a IBM Support. Applies ToSource and Target Default SettingThe system code page when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference NLS_LANG on page 544
D_MIRROR_HOME
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the directory (full path) where InfoSphere CDC is installed on the server. Applies ToSource and Target Default SettingThe installation directory specified when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
D_MIRROR_LOG
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the directory (full path) where InfoSphere CDC log files are located. Applies ToSource and Target Default SettingThe log subdirectory in the installation directory specified when installing InfoSphere CDC. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
DM_DYNAMIC_PARAMETER_CHECK_INT
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier
538
Use this system parameter to specify how often, in seconds, InfoSphere CDC checks for changes to the values of dynamic system parameters during active replication to a subscription. For example, to check once a day, set this parameter to 216,000. The following system parameters are dynamic: v v v v v v D_MIRROR_TRACE D_MIRROR_TRACE_ON_ERROR (on the target only) DM_PRINT_DIAGNOSTICS STATISTICS_INTERVAL SYNCHRONIZATION_COMMIT_GROUP_SIZE SYNCHRONIZATION_INTERVAL
Applies ToSource and Target Default Setting300 seconds (5 minutes) Minimum Setting0. InfoSphere CDC does not check for changes to dynamic system parameters. Maximum Setting2,147,483,648 (maximum integer) Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
DM_MAX_MONITOR_ENTRIES
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to increase or decrease the number of subscriptions that InfoSphere CDC can support in the Monitor in Management Console. InfoSphere CDC allocates an entry for each source and target datastore within a subscription. For example, if you have a datastore that is being used as a source datastore within 20 subscriptions and as a target datastore within 10 subscriptions, then you must set this system parameter to at least 30. InfoSphere CDC will allocate 30 entries for this datastore. Applies ToSource Default Setting20 entries. By default, InfoSphere CDC can handle 20 subscriptions. Minimum Setting1 entry Maximum Setting1000 entries
DSQUERY
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the name of the Sybase server. Applies ToSource and Target
539
LD_LIBRARY_PATH
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the path to the InfoSphere CDC libraries and the database libraries for Solaris and Linux operating systems. This value is set during installation and should not be modified. Applies ToSource and Target Default SettingThe path to the InfoSphere CDC libraries and the Sybase libraries when InfoSphere CDC was installed Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
LIBPATH
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the path to the InfoSphere CDC libraries and the database libraries (for AIX operating systems). This value is set during installation and should not be modified. Applies ToSource and Target Default SettingThe path to the InfoSphere CDC libraries and the database libraries when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
PUBLISH_METADATA
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to enable or disable the display of InfoSphere CDC metadata tables in Management Console. Applies ToSource Set this parameter to one of the following: v OFFInfoSphere CDC metadata tables are not displayed in Management Console. v ONInfoSphere CDC metadata tables are displayed in the Add/Remove Tables dialog box, making them available to be selected for replication. Default SettingOFF
540
Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
SYBASE
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the Sybase home directory. This value is set during the installation and should not be modified. Applies ToSource and Target Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
SYBASE_OCS
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the Sybase Open Client directory. This value is set during the installation and should not be modified. Applies ToSource and Target Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
SHLIB_PATH
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the path to the InfoSphere CDC libraries and the database libraries for HP-UX operating systems. This value is set during installation and should not be modified. Applies ToSource and Target Default SettingThe path to the InfoSphere CDC libraries and the database libraries when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
STARTUP_TIMEOUT
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the maximum waiting period, in seconds, for process handling to complete during InfoSphere CDC startup. It indicates how long the InfoSphere CDC communication module waits for the database initialization program to start before timing out.
541
Applies ToSource and Target. Target only for InfoSphere CDC for Teradata. Default Setting120 Minimum Setting60 Maximum Setting3600 Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
USER
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the database user name that was specified during installation. You can also set this user using the dmsetpass command. Applies ToSource Default SettingThe InfoSphere CDC user specified when InfoSphere CDC was installed. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convertNotNullableColumns D_MIRROR_MIRROR_ERROR_STOP on page 543 D_MIRROR_REFRESH_ERROR_STOP on page 543 FILTER_NOCHANGE_UPDATES_FOR_AUDIT on page 544 NLS_LANG on page 544 TRANSACTION_GROUP_SIZE on page 544 TRANSACTION_INTERVAL on page 545 TRANSACTION_RECORDS_THRESHOLD on page 546 TRIM_CHAR_TO_VARCHAR on page 546 TRIM_VARCHAR_TO_VARCHAR on page 546 TRIM_TO_NULL on page 547
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to indicate whether or not NULL values will be converted to default values when replicating data that contains NULL values to non-nullable target columns.
542
Applies ToTarget Set this parameter to one of the following: v OFFAn error message will be generated in Event Log. Replication will continue or not based on whether the MirrorError or RefreshError system parameters are set to END or ON. v ONInfoSphere CDC will automatically insert an appropriate default value in the target column. No error message is generated in Event Log and replication continues. Depending on the convertNotNullableMsg system parameter setting, a warning message may be generated in Event Log. The default value depends on the data type of the subscription column. For example, zero for numeric data types, blank character for character data types, 1901-01-01 for date data types, and so on. Default SettingOFF
D_MIRROR_MIRROR_ERROR_STOP
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this parameter to indicate whether or not mirroring continues after an error has occurred during a row insert, delete, or update operation. Applies ToTarget Set this parameter to one of the following: v ONMirroring stops after an error has occurred. v OFFMirroring continues after an error has occurred. Default SettingON Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference D_MIRROR_REFRESH_ERROR_STOP
D_MIRROR_REFRESH_ERROR_STOP
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to indicate whether or not InfoSphere CDC should continue to perform a refresh after encountering an error during a row insert operation. Applies ToTarget Set this parameter to one of the following: v ONData refresh stops after an error has occurred. v OFFData refresh continues after an error has occurred. Default SettingON
543
Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference D_MIRROR_MIRROR_ERROR_STOP on page 543
FILTER_NOCHANGE_UPDATES_FOR_AUDIT
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to indicate whether or not updates that have identical before and after column images (that is, the row has been updated to the same value), are replicated to the target table for any tables configured for LiveAudit replication. Applies ToSource Set this parameter to one of the following: v OFFIf a row in a source table is updated to the same value, InfoSphere CDC replicates the value to the target table. v ONIf a row in a source table is updated to the same value, InfoSphere CDC does not replicate the value to the target table. This parameter only affects tables that are configured for LiveAudit replication. For non-audit tables, only updates that change the column data are replicated to the target tables. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
NLS_LANG
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the database character set preceded with a period. For more information about setting this system parameter, see your IBM representative. Applies ToSource and Target Default SettingThe database character set, preceded with a period, corresponding to the language selected when the database was installed. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
TRANSACTION_GROUP_SIZE
544
Use this system parameter to specify the number of complete transactions applied to the database before InfoSphere CDC issues a commit. Use the TRANSACTION_GROUP_SIZE, TRANSACTION_INTERVAL, and TRANSACTION_RECORDS_THRESHOLDS system parameters together. InfoSphere CDC issues a commit after applying the number of transactions specified by the TRANSACTION_GROUP_SIZE, or when the time interval specified by TRANSACTION_INTERVAL has elapsed. Setting only one of these system parameters without the other can result in uncommitted transactions on the target. Applies ToTarget Default Setting500 Minimum Setting0 Guidelines To increase the throughput, set to a number of transactions that would be received when busy during the TRANSACTION_INTERVAL. Note: Use this parameter only if InfoSphere CDC is running under commitment control. The COMMIT_LEVEL system parameter should be set to2 on the target database, and the MAINTAIN_TRANSACTION_CONSISTENCY system parameter should be set to ON on the source database. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
TRANSACTION_INTERVAL
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the time interval, in seconds, that can elapse between transactions before InfoSphere CDC issues a commit. If there are no transactions received by the target system, then InfoSphere CDC issues a commit immediately. Use this system parameter with the TRANSACTION_GROUP_SIZE system parameter. InfoSphere CDC issues a commit after applying the number of transactions specified by the TRANSACTION_GROUP_SIZE system parameter, or when the time interval specified by TRANSACTION_INTERVAL system parameter has elapsed. Setting only one of these system parameters without the other can result in uncommitted transactions on the target. Applies ToTarget Default Setting1 Minimum Setting0 Guidelines InfoSphere CDC issues a commit only when a commit is received by the target system and you have reached the transaction group size, or exceeded the time interval, or exceeded the records threshold.
545
TRANSACTION_RECORDS_THRESHOLD
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the maximum number of operations within a transaction or group of transactions before InfoSphere CDC issues a commit Applies ToTarget Default Setting3000 Minimum Setting0 Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
TRIM_CHAR_TO_VARCHAR
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify whether or not trailing blank characters are trimmed from source columns of CHAR data type when replicating data to target columns of VARCHAR data type. Applies ToTarget Set this parameter to one of the following: v OFFTrailing blanks are not trimmed. v ONTrailing blanks are trimmed. If TRIM_TO_NULL =OFF, InfoSphere CDC inserts a single blank character in the target column. If TRIM_TO_NULL =ON and the target column is nullable, InfoSphere CDC inserts NULL in the column. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference TRIM_TO_NULL on page 547
TRIM_VARCHAR_TO_VARCHAR
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify whether or not trailing blank characters are trimmed from source columns of VARCHAR data type when replicating data to target columns of VARCHAR data type. Applies ToTarget
546
Set this parameter to one of the following: v OFFTrailing blanks are not trimmed. v ONTrailing blanks are trimmed. If TRIM_TO_NULL =OFF, InfoSphere CDC inserts a single blank character in the target column. If TRIM_TO_NULL =ON and the target column is nullable, InfoSphere CDC inserts NULL in the column. Default SettingOFF Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference TRIM_TO_NULL
TRIM_TO_NULL
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify how source columns that contain blank characters only are handled during data replication. Applies ToTarget Set this parameter to one of the following: v OFFFor data mapped to VARCHAR columns, trailing blanks are trimmed or not to a single blank depending on the TRIM_CHAR_TO_VARCHAR and TRIM_VARCHAR_TO_VARCHAR system parameters. For data mapped to CHAR columns, setting this parameter to OFF has no effect. v ONFor data mapped to CHAR columns, if the target column is nullable, InfoSphere CDC inserts NULL in the column. For CHAR data mapped to VARCHAR columns, if TRIM_CHAR_TO_VARCHAR =ON and the target column is nullable, InfoSphere CDC inserts NULL in the column. For VARCHAR data mapped to VARCHAR columns, if TRIM_VARCHAR_TO_VARCHAR =ON and the target column is nullable, InfoSphere CDC inserts NULL in the column. If the target column is non-nullable, source columns that contain blank characters only are handled according to the convertNotNullableColumns system parameter. The table below explains how the TRIM_ system parameters affect the data replicated to the target for source columns that contain blank characters only.
TRIM_ parameter settings TRIM_CHAR_ TO_ VARCHAR ON ON OFF OFF ON ON OFF TRIM_ VARCHAR_ TRIM_ TO_ TO_ VARCHAR NULL ON OFF ON OFF ON OFF ON ON ON ON ON OFF OFF OFF Target data CHAR to VARCHAR NULL NULL Source data Source data VARCHAR to VARCHAR NULL Source data NULL Source data Any data type to CHAR NULL NULL NULL NULL Blanks Blanks Blanks
Single blank Single blank Single blank Source data Source data Single blank
547
TRIM_ parameter settings OFF OFF OFF
Target data Source data Source data Blanks
Default SettingOFF Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference TRIM_CHAR_TO_VARCHAR on page 546 TRIM_VARCHAR_TO_VARCHAR on page 546

Cascading replication system parameters control InfoSphere CDC cascading replication. See also: PREVENT_RECURSION
PREVENT_RECURSION
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this parameter to indicate whether or not to prevent cascading replication for bidirectional configurations. Applies ToSource Set this parameter to one of the following: v ONChanges applied by InfoSphere CDC are not be replicated back to the source database from where it came from. v OFFChanges made by InfoSphere CDC are replicated, except when filtered out by the CASCADE_OMIT_TARGETS system parameter. Default SettingON Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537

Database journal or trigger system parameters let you manage the InfoSphere CDC journal table. See also: REPORT_POSITION_INTERVAL
REPORT_POSITION_INTERVAL
548
Use this system parameter to specify how often (in seconds) the source informs the target about its position in the current journal during times of no activity. During times of no activity, when there are no journal entries to be processed pertaining to the current subscription, the source informs the target of its current position so that the target can advance its bookmarks accordingly. By specifying a low setting for this parameter, the target can reflect more accurately how far replication has progressed. Applies ToSource After a shutdown and restart, you can use this system parameter to prevent InfoSphere CDC from rereading entries that do not apply to the current replication configuration. The value of this parameter affects the information that is displayed in progress and bookmark messages. A high value for this parameter may result in information that is not up-to-date being displayed. Default Setting5 Minimum Setting1 Maximum Setting300 Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: COMMIT_GROUP_SIZE COMMIT_INTERVAL on page 550 SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 551 SYNCHRONIZATION_INTERVAL on page 552
COMMIT_GROUP_SIZE
549
Use this system parameter to specify the minimum number of rows InfoSphere CDC should apply to the database before a commit is issued. InfoSphere CDC issues a commit on the target when the transaction that contains the rows completes. Use the COMMIT_GROUP_SIZE and COMMIT_INTERVAL system parameters together. InfoSphere CDC issues a commit when either when the number of rows specified by COMMIT_GROUP_SIZE has been applied to the target, or when the time interval specified by COMMIT_INTERVAL has elapsed. Setting only one of these system parameters without the other can result in uncommitted data on the target. Applies ToTarget Default Setting5000 Minimum Setting0. InfoSphere CDC does not use commit groups to apply data to the target. Guidelines Set this parameter to 0 if D_MIRROR_MIRROR_ERROR_STOP=OFF. If a rollback occurs, InfoSphere CDC rolls back all outstanding rows in the commit group. Since InfoSphere CDC is set to continue on error, you may lose data. Note: Use this parameter only if InfoSphere CDC is not running under commitment control (COMMIT_LEVEL =0). Related concepts System parameters for InfoSphere CDC for Oracle databases (version 6.2 and earlier) on page 465 System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference COMMIT_INTERVAL on page 488 COMMIT_LEVEL on page 488 D_MIRROR_MIRROR_ERROR_STOP on page 477 COMMIT_INTERVAL D_MIRROR_MIRROR_ERROR_STOP on page 543
COMMIT_INTERVAL
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the time interval between commits, in seconds, to limit the number of commits InfoSphere CDC issues on the target database. Use the COMMIT_GROUP_SIZE and COMMIT_INTERVAL system parameters together. InfoSphere CDC issues a commit when either when the number of rows specified by COMMIT_GROUP_SIZE has been applied to the target, or when the time interval specified by COMMIT_INTERVAL has elapsed. Setting only one of these system parameters without the other can result in uncommitted data on the target. When the COMMIT_INTERVAL time expires, InfoSphere CDC issues a commit on the target database for transactions that completed within that time interval.
550
Applies ToTarget Default Setting60 Minimum Setting0. InfoSphere CDC issues a commit on a target database for each completed transaction. Guidelines Set this parameter to 0 if D_MIRROR_MIRROR_ERROR_STOP=OFF. If a rollback occurs, InfoSphere CDC rolls back all outstanding rows in the commit group. Since InfoSphere CDC is set to continue on error, you may lose data. Note: Use this parameter only if InfoSphere CDC is not running under commitment control (COMMIT_LEVEL =0). Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference COMMIT_GROUP_SIZE on page 549 D_MIRROR_MIRROR_ERROR_STOP on page 543
SYNCHRONIZATION_COMMIT_ GROUP_SIZE
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the number of transactions applied to the database before InfoSphere CDC performs synchronization between the source and target. Applies ToSource and Target The SYNCRONIZATION_COMMIT_GROUP_SIZE and SYNCHRONIZATION_INTERVAL system parameters are intended to be used together. Synchronization occurs either when the number of transactions (specified by SYNCRONIZATION_COMMIT_GROUP_SIZE) have been applied or when the time interval (specified by SYNCHRONIZATION_INTERVAL) has elapsed, whichever comes first. Default Setting128 Minimum Setting0. InfoSphere CDC does not use commit groups to perform synchronization. Maximum Setting2,147,483,648 (maximum integer) DynamicYes
551
Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference SYNCHRONIZATION_INTERVAL
SYNCHRONIZATION_INTERVAL
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the interval, in seconds, at which synchronization is performed between the source and target. Synchronization is achieved when the target reports to the source the position of the last committed change. Applies ToSource The SYNCRONIZATION_INTERVAL and SYNCHRONIZATION_COMMIT_ GROUP_SIZE system parameters are intended to be used together. Synchronization occurs either when the number of transactions (specified by SYNCHRONIZATION_COMMIT_ GROUP_SIZE ) have been applied or when the time interval (specified by SYNCRONIZATION_INTERVAL) has elapsed, whichever comes first. Default Setting1 Minimum Setting1 Maximum Setting300 DynamicYes Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference SYNCHRONIZATION_COMMIT_ GROUP_SIZE on page 551

Tracing system parameters let you perform diagnostic activities with InfoSphere CDC. See also: D_MIRROR_ALARM_TRACE D_MIRROR_TRACE on page 553 D_MIRROR_TRACE_FILE_SIZE on page 553 D_MIRROR_TRACE_ON_ERROR on page 554
D_MIRROR_ALARM_TRACE
552
Use this system parameter to Indicate whether or not tracing for notification is enabled. Applies ToSource and Target Set this parameter to one of the following: v OFFTracing for notification is disabled. v ONTracing for notification is enabled. Tracing for notification is enabled when D_MIRROR_TRACE system parameter is also set to ON. The notification tracing will be located in the same trace file used for regular tracing located in the directory specified by the D_MIRROR_LOG system parameter. The trace files are encrypted and are meant to be sent to IBM for troubleshooting purposes. Default SettingOFF
D_MIRROR_TRACE
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to indicate whether or not tracing is enabled. Applies ToSource and Target Set this parameter to one of the following: v OFFTracing is disabled. This setting has no effect when D_MIRROR_TRACE_ON_ERROR=ON. v ONTracing is enabled and InfoSphere CDC creates the appropriate trace files in the log directory. These trace files are encrypted, and are meant to be sent to IBM technical support for troubleshooting purposes. When enabling this setting, also set the size of the trace file to an appropriate value using the D_MIRROR_TRACE_FILE_SIZE system parameter. To avoid disk space problems, set the size of the trace file to a value that is not too high. Default SettingOFF DynamicYes Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference D_MIRROR_TRACE_FILE_SIZE
D_MIRROR_TRACE_FILE_SIZE
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the maximum size of a trace file in bytes. InfoSphere CDC creates two trace files. When the first trace file reaches its maximum size, InfoSphere CDC creates a second file. When the second trace file reaches its maximum size, InfoSphere CDC starts overwriting the first file.
553
Applies ToSource and Target Default Setting10,000,000 bytes Minimum Setting1,000,000 bytes Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
D_MIRROR_TRACE_ON_ERROR
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify whether or not InfoSphere CDC enables tracing automatically when an error occurs. Applies ToSource and Target Set this parameter to one of the following: v OFFInfoSphere CDC does not enable tracing when an error occurs. v ONInfoSphere CDC enables tracing when an error occurs. InfoSphere CDC creates the appropriate trace files in the InfoSphere CDC log directory. These trace files are encrypted, and are meant to be sent to IBM technical support for troubleshooting purposes. When enabling this setting, also set the size of the trace file to an appropriate value using the D_MIRROR_TRACE_FILE_SIZE system parameter. To avoid disk space problems, set the size of the trace file to a value that is not too high. Default SettingOFF DynamicYes (on the target only) Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference D_MIRROR_TRACE_FILE_SIZE on page 553

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: implicit_transformation_warning on page 555 DEADBAND_PERCENTAGE on page 555 DM_STATUS_INTERVAL on page 557 HEARTBEAT_TIMEOUT on page 557 LOG_EMAIL_USERNAME on page 558 MONITOR_SAMPLE_INTERVAL on page 558 STATISTICS_INTERVAL on page 559
554
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
DEADBAND_PERCENTAGE
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Applies ToTarget Identifies the size of the range around each latency threshold setting. Based on latency thresholds defined, a latency message is generated when latency has risen above or fallen below a threshold. Latency is calculated at regular intervals, where the interval is the current setting for the MONITOR_SAMPLE_INTERVAL system parameter. You can set notifications in response to a generated latency message. This system parameter, which is expressed as a percentage, allows you to pad a threshold equally on both sides to create a range around the threshold. By adjusting this system parameter, the size of the range around the threshold can be increased or decreased, and the threshold itself can be made thicker or thinner. A latency message is generated only when latency has risen above the upper limit of the range or fallen below the lower limit of the range. By changing the value assigned to this system parameter, you can control the number of latency messages placed in the Event Log. For example, assume that a latency threshold is 5 minutes and this system parameter is set to 10. A 10% range is applied around the 5 minute threshold. The
555
following calculations are performed to determine the lower and upper limits (in minutes) of the range around the threshold: v Padding = 10% of 5 minutes = 0.5 minutes (rounded up to 1 minute) v Padding is rounded up or down to the nearest whole minute: Upper limit of range = 5 minutes + 1 minute (padding) = 6 minutes Lower limit of range = 5 minutes - 1 minute (padding) = 4 minutes As a result, a latency message will be generated only when latency rises above 6 minutes or falls below 4 minutes. Given sample latency over a ten minute period where latency is calculated every minute, three latency messages are generated. This graph illustrates latency message generation with the DEADBAND_PERCENTAGE value set to 10%:
If the number of latency messages generated over the ten minute period for the 10% (3 latency messages) and 3% (5 latency messages) settings are averages, an additional 288 latency messages would be generated each day if this system parameter is not changed from its default setting to 10%. Since there are two latency thresholds that you can set (a warning threshold and a problem threshold), two separate ranges are defined when padding is at least one minute. In this case, each range is attached to its threshold, and the two ranges can overlap with no change in behavior. If a value outside the acceptable range is specified, the default setting is used. Default Setting3% Minimum Setting3%
556
Maximum Setting10% Note: If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Setting latency thresholds and notifications on page 374 Disk resource system parameters on page 559
DM_STATUS_INTERVAL
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify how often progress messages should be issued in seconds. These messages are displayed in Event Log to indicate how replication is advancing and to provide detailed information about InfoSphere CDC replication activities. Applies ToSource and Target Note: Low values of this parameter may result in many messages displayed in Event Log. In this situation, clear Event Log on a regular basis. Default Setting0 seconds. No progress notifications will be issued. Minimum Setting0 seconds. No progress notifications will be issued. Maximum Setting7200 seconds Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
HEARTBEAT_TIMEOUT
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this parameter to specify the number of minutes of communication inactivity to wait before active InfoSphere CDC processes for a subscription are stopped. Heartbeat is a feature that manages InfoSphere CDC processes when a problem with communications or a process has been detected through the absence of communications over a specified period of time. For each active subscription, internal heartbeat messages are sent regularly between the source and the target to determine communications and process status. If a reply to a message is not received by the source or target within the specified timeout interval, then InfoSphere CDC determines that a problem has occurred, and attempts to stop all its source and target processes for the subscription. In addition, messages (message identifiers 2612 and 3165) are placed in Event Log when heartbeat timeouts occur. Applies ToSource Default Setting15 minutes
557
Minimum Setting3 minutes Maximum Setting999 minutes Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
LOG_EMAIL_USERNAME
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the user name that receives e-mail messages in response to invoking the dmreadlog command or the warning message that is generated when Event Log exceeds the threshold value set by the LOG_MAX_SIZE system parameter. Applies ToSource and Target In UNIX environments, the value assigned to this parameter is a comma-separated list of user names. The value of this parameter cannot exceed 30 bytes in length. To suppress all e-mail messages, set this parameter to NOMAIL. Default SettingThe InfoSphere CDC account (UNIX user) specified when InfoSphere CDC was installed Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Related reference STATISTICS_INTERVAL on page 559
MONITOR_SAMPLE_INTERVAL
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to identify the period of time, in seconds, between consecutive updates to a storage area that is used to maintain replication latency metrics. Management Console references this area to present replication latency information. Applies ToSource and Target On the target, this setting also represents how often the storage area is sampled to determine if latency has risen above or fallen below specified threshold settings. InfoSphere CDC generates latency messages when latency rises above or falls below the thresholds. In response to a generated message, you can set latency notifications. If a value smaller than the minimum setting is specified, the minimum setting is used. If a value larger than the maximum setting is specified, the maximum setting is used. Default Setting5 seconds
558
Minimum Setting0 seconds. Replication latency metrics are not updated. Maximum Setting3600 seconds Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537 Setting latency thresholds and notifications on page 374
STATISTICS_INTERVAL
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify how often, in seconds, InfoSphere CDC issues messages that contain statistics information. These messages are displayed in Event Log. Applies ToSource and Target Note: Use this parameter only if advised by IBM technical support. Default Setting0. InfoSphere CDC does not provide statistics information. Minimum Setting0. InfoSphere CDC does not provide statistics information. Maximum Setting2,147,483,647 (maximum integer) DynamicYes Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537

Some system parameters control memory usage in InfoSphere CDC. For improved performance, if you are able to allocate more than the default value of 512 MB for the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource system parameters to use the increased memory. See also: LOG_MAX_SIZE
LOG_MAX_SIZE
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the threshold size of Event Log in KB. A warning message is generated in Event Log when its size exceeds specified threshold. The messages in Event Log are deleted automatically when the size of Event Log is ten times the value specified by this parameter. Applies ToSource and Target If you do not want to specify a threshold size, set this parameter to NOMAX.
559
Default Setting5000 Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.0 and earlier) on page 537
Refresh loader system parameters

Some system parameters affect how InfoSphere CDC applies refresh operations. See also: D_HOME_BCP D_MIRROR_BCP D_MIRROR_BCP_ROWS on page 561 D_MIRROR_FASTBCP on page 561 DM_BCP_PACKET_SIZE on page 561
D_HOME_BCP
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the directory where InfoSphere CDC will place a BCP log file. The log file contains the statements that were used to recreate the indexes after the BCP operation was completed. Applies ToSource and Target Default SettingThe directory specified by the D_MIRROR_LOG system parameter.
D_MIRROR_BCP
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to indicate if BCP refresh operations are enabled. Under BCP, a block of data is accumulated and applied to target tables in a single operation. InfoSphere CDC accumulates records on the Sybase server, and then performs a bulk copy when the block contains a specific number of records. Applies ToTarget Set this parameter to one of the following: v ONInfoSphere CDC uses the Sybase Bulk Copy (BCP) library to perform data refresh. The bulk copy is generally faster. However, all updates performed under BCP cannot be reversed. v OFFInfoSphere CDC uses SQL inserts to perform data refresh. This setting lets InfoSphere CDC roll back the previous copy operation. Default SettingON Note: To enable InfoSphere CDC to refresh target tables using BCP, make sure that this parameter is set to ON, and that D_MIRROR_FASTBCP is set to OFF. If D_MIRROR_FASTBCP is set to ON as well, then fast BCP refresh is enabled.
560
D_MIRROR_BCP_ROWS
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the number of rows that the server will buffer before InfoSphere CDC commits to the database in a single operation. You need to consider the amount of storage available to buffer rows. For example, to copy blocks of 500 rows to target tables, you would set D_MIRROR_BCP_ROWS to a value of 500. Applies ToTarget Default Setting50000 rows. If the system parameter D_MIRROR_BCP is set to OFF or if D_MIRROR_BCP_ROWS is set to a negative number, then the server will buffer 50000 rows before InfoSphere CDC commits these blocks to target tables. Note: If you specify a value of zero, then the server will buffer all the rows in the table before committing data to the database.
D_MIRROR_FASTBCP
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to enable or disable fast BCP refresh operations. Fast BCP applies records in blocks, but provides better performance than BCP. Applies ToTarget Set this parameter to one of the following: v ONEnables InfoSphere CDC to apply records to target tables using fast BCP. When you enable this parameter, InfoSphere CDC removes all indexes from the target table, loads the data into the table, and then rebuilds the indexes. If InfoSphere CDC cannot rebuild the indexes because of an error (for example, a duplicate value encountered in a unique index) then InfoSphere CDC generates an error in the Event Log and the command to rebuild the index is saved in a file in the log directory. You must also set the D_MIRROR_BCP system parameter to ON to enable fast BCP. v OFFDisables InfoSphere CDC from using fast BCP. Default SettingOFF
DM_BCP_PACKET_SIZE
VersionInfoSphere CDC for Sybase databases version 6.0 and earlier Use this system parameter to specify the length (bytes) of the network packets you want InfoSphere CDC to send to the Sybase server when a BCP refresh is enabled. The value of this parameter impacts the speed at which the load of data will occur. You should specify network packet sizes larger than the default to improve the performance of BCP refresh operations. Applies ToTarget Default Setting512 bytes
561
Minimum Setting512 bytes Maximum Setting65535 bytes Note: The number of bytes cannot be greater than the maximum network packet size value you have specified for the Sybase database. While Sybase documentation states that this is a negotiated value, the connection will fail if the size specified for this system parameter is larger than the Sybase database setting. Therefore, the maximum value for the Sybase database should be set to a value that allows large packet sizes. For more information about the Sybase configuration variables related to network communication, see your Sybase documentation.
562
System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Note: If you make changes to a system parameter during active replication, you must stop and restart replication for the changes to take effect. In this section, you will learn: General product system parameters Notification system parameters on page 564 Maximize throughput system parameters on page 566 Encoding system parameters on page 567 Disk resource system parameters on page 568 Apply process system parameters on page 570 Supplemental logging system parameters on page 456

VersionInfoSphere CDC for Sybase version 6.3 Fix Pack 3 TFE 9 and later. Use this parameter to indicate how frequently (in minutes) InfoSphere CDC will attempt to automatically restart continuous mirroring for persistent subscriptions. InfoSphere CDC will continue in its attempts to restart mirroring at a defined interval until it is either successful, an unrecoverable error occurs or the process is manually stopped. Applies ToSource Default0 minutes Minimum0 minutes Maximum60 minutes
563

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: events_max_retain global_conversion_not_possible_warning global_shutdown_after_no_heartbeat_response_minutes on page 565 implicit_transformation_warning on page 555
events_max_retain
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647 Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse
564
Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563 Related reference global_default_after_database_minimum_timestamp on page 571 global_default_before_database_minimum_timestamp on page 571
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue
565

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: global_max_batch_size mirror_interim_commit_threshold refresh_commit_after_max_operations on page 567
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to specify the maximum number of rows that InfoSphere CDC can place in an array and apply to the target database during refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached. You can use this parameter during mirroring only if mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is empty. Before InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then InfoSphere CDC cannot allocate enough memory and will shut down. Management Console references this area to present replication latency information. Applies ToTarget Default Setting25 rows Maximum Setting2147483647 rows Minimum Setting1 row
VersionInfoSphere CDC for Sybase version 6.3 Fix Pack 3 and later.
566
By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter. The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations. Applies ToTarget Default Setting0 Minimum Setting0
VersionInfoSphere CDC for Sybase databases version 6.3 and later This system parameter identifies the number of rows comprising each transaction during refresh. To reduce the workload on the target database during refresh, InfoSphere CDC periodically commits the changes to the target database rather than performing the refresh as a single large transaction. Applies ToTarget Default Setting1000 Maximum Setting2147483647 Minimum Setting1 Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563

VersionInfoSphere CDC for Sybase databases version 6.3 and later
567
This system parameter indicates the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Set this parameter to one of the following: v trueInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. Setting this system parameter to false ensures that InfoSphere CDC handles non-single-byte character data in the same way as previous InfoSphere CDC releases. Note: Setting this parameter to false does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you may have to apply user exit programs or other customizations to properly represent data in Unicode columns. For more information about user exit programs, see the InfoSphere CDC End-User Documentation for your platform. Applies ToSource Default Settingfalse Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563

VersionInfoSphere CDC for Sybase databases version 6.3 Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions queues staged on the source and LOBs, which are staged on the target (for the record being applied). InfoSphere CDC will manage disk space utilization across all components as required.
568
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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting100 Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
VersionInfoSphere CDC for Sybase databases version 6.5 Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1
569
VersionInfoSphere CDC for Sybase databases version 6.5 Use this system parameter to determine if subscriptions will exclusively use the InfoSphere CDC staging store to accumulate change data or if they will be allowed to use independent log readers and log parsers to receive data directly from the database logs. Set this parameter to one of the following values: v trueSpecifies that subscriptions can use either the staging store to accumulate change data or use independent log readers and log parsers to receive data directly from the database logs. v falseSpecifies that subscriptions will use the InfoSphere CDC staging store to accumulate change data. Changes to this system parameter value will only take effect after the replication engine is restarted. If you change the value from true to false, you will need to clear the staging store before starting replication. Applies ToSource Default Settingtrue
VersionInfoSphere CDC for Sybase databases version 6.5 Use this system parameter to specify the maximum amount of disk space that will be utilized by the InfoSphere CDC staging store on your source system. If you have enabled the Continuous Capture feature and you are accumulating change data in your staging store when subscriptions are stopped, you should take into consideration the additional disk utilization that this feature requires. Applies ToSource Default Setting100 GB Maximum Setting2147483647 GB Minimum Setting1 GB

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: global_default_after_database_minimum_timestamp on page 571 global_default_before_database_minimum_timestamp on page 571 convert_not_nullable_column on page 572
570
mirror_end_on_error on page 572 mirror_expected_errors_list on page 572 refresh_end_on_error on page 573 refresh_expected_errors_list on page 573 refresh_loader_drop_index on page 574 refresh_with_referential_integrity on page 574 trim_char_to_varchar on page 574 trim_varchar_to_varchar on page 575 userexit_max_lob_size_kb on page 575
global_default_after_database_minimum_timestamp
VersionInfoSphere CDC for Sybase databases version 6.3 and later In environments where the timestamp range in your source database differs from the target database, this system parameter allows you to control the default values that InfoSphere CDC sets on the target for out-of-range date-time values. Use this system parameter to control the value substituted by InfoSphere CDC in the target database when a value is being set on a target date-time column that is greater than the maximum accepted value for the target database. Note: To determine if a value is out-of-range, InfoSphere CDC converts the value to a timestamp data type and then validates the timestamp to determine if it is within range. Default Setting1901-01-01 00:00:00.000 Related reference global_conversion_not_possible_warning on page 564
global_default_before_database_minimum_timestamp
VersionInfoSphere CDC for Sybase databases version 6.3 and later In environments where the timestamp range in your source database differs from the target database, this system parameter allows you to control the default values that InfoSphere CDC sets on the target for out-of-range date-time values. Use this system parameter to control the value substituted by InfoSphere CDC in the target database when a value is being set on a target date-time column that is less than the minimum accepted value for the target database. Note: To determine if a value is out-of-range, InfoSphere CDC converts the value to a timestamp data type and then validates the timestamp to determine if it is within range. Default Setting1901-01-01 00:00:00.000
571
Related reference global_conversion_not_possible_warning on page 564
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to control how InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and InfoSphere CDC will generate a warning in the event log. When set to false, InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of InfoSphere CDC on the target database. Note: If you decided to set this system parameter to false and have specified this as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list system parameter, then InfoSphere CDC will ignore the error and not shutdown. Set this parameter to one of the following: v trueNull value will be replaced with default value for non-nullable column, and a warning event will be logged. v falseNull data will be applied as-is to non-nullable column and database will usually return an error code. Applies ToSource and Target Default SettingTrue Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
mirror_end_on_error
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v trueEnd mirroring after an apply error on the target database. v falseDo not end mirroring after an apply error on the target database. Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
572
Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue mirroring when it encounters a duplicate key violation in your Sybase target database, set this parameter to mirror_expected_errors_list=2601. The integer error code of 2601 corresponds to the Sybase error: The SQL error code is 2601. The SQL state is: 23000. The error message is: [CDC][Sybase JDBC Driver][Sybase]Attempt to insert duplicate key row in object TBL with unique index TBL_13600048452.. If you also want to ignore an error code of 3459, set this parameter to mirror_expected_errors_list=2601,3459. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to indicate if you want to end a refresh after an apply error occurs. Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs.
Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue refresh when it encounters a duplicate key violation in your Sybase target database, set this parameter to mirror_expected_errors_list=2601. The integer error code of 2601 corresponds to
573
the Sybase error: The SQL error code is 2601. The SQL state is: 23000. The error message is: [CDC][Sybase JDBC Driver][Sybase]Attempt to insert duplicate key row in object TBL with unique index TBL_13600048452.. If you also want to ignore an error code of 3459, set this parameter to mirror_expected_errors_list=2601,3459. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
VersionInfoSphere CDC for Sybase databases version 6.3 and later This system parameter indicates whether or not InfoSphere CDC will drop all indexes on the tables being refreshed and then rebuild the indexes after the refresh. In most environments, this will improve refresh performance. If the refresh fails for any reason, InfoSphere CDC will write SQL statements to a file which will allow you to manually rebuild the indexes for all tables in your database. The location of the file is specified in the Management Console event log. Applies ToTarget Default Settingtrue
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to indicate whether or not you want the data removed from all the target tables being refreshed before repopulating any of them. This is most useful when there are referential integrity constraints on the tables being refreshed. Set this parameter to one of the following: v trueIndicates that InfoSphere CDC will first remove all data in reverse of the specified refresh order. When specifying the refresh order, in general parent tables should appear before the referenced child tables. The product will then remove data from the child tables before the parent tables. falseIndicates that InfoSphere CDC will not first remove all data from your tables and will refresh the tables in the specified order.
Applies ToSource Default Settingfalse
574
Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v trueInfoSphere CDC strips the data of trailing blanks. v falseInfoSphere CDC does not strip the string data of trailing blanks. Applies ToTarget Default Settingfalse Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v trueInfoSphere CDC strips the data of trailing blanks. v falseInfoSphere CDC does not strip the string data of trailing blanks.
Applies ToTarget Default Settingfalse Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb
575
Related concepts System parameters for InfoSphere CDC for Sybase databases (version 6.3 and later) on page 563
Supplemental logging system parameters

Some system parameter control the database logging mechanism used by InfoSphere CDC. See also: mirror_logging_by_empty_triggers on page 457 auto_configure_supplemental_logging mirror_logging_by_empty_triggers
auto_configure_supplemental_logging
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to specify how supplemental logging is performed. Set this parameter to one of the following: v trueInfoSphere CDC uses the value of the mirror_logging_by_empty_triggers system parameter to enable logging. v falseIndicates that you must either create an empty trigger or set the table's replication flag (using sp_setreptable 'table-name', true). Default Settingtrue
mirror_logging_by_empty_triggers
VersionInfoSphere CDC for Sybase databases version 6.3 and later Use this system parameter to choose empty triggers as your supplemental logging method for Sybase. InfoSphere CDC only uses this system parameter if auto_configure_supplemental_logging is set to true. Set this parameter to one of the following: v true Indicates that an empty trigger will be created (if one does not exist) to enable supplemental logging. v falseIndicates that the table's replication flag will be set. Note: If the table's replication flag is set and Sybase Replication Server is not replicating the table, a warning will be written to the ASE error log each time an insert is performed. In this case you must create an empty subscription (see http://infocenter.sybase.com/help/index.jsp?topic=/ com.sybase.infocenter.dc35817.1510/html/rsunix_config/CHDCGDAG.htm) Applies ToSource Default Settingtrue
576
System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with InfoSphere CDC replication configuration. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Notes: v If you make changes to a system parameter during active replication, you must stop and restart replication to for the changes to take effect. v When upgrading to a later version of Transformation Server, any preexisting settings for system parameters are maintained. In this section, you will learn: General product system parameters Replication system parameters on page 580 Cascading replication system parameters on page 582 Database journal (trigger) system parameters on page 582 Remote journal system parameters on page 585 Commitment control system parameters on page 586 Multibyte character set system parameters on page 587 Latency system parameters on page 588 Notification system parameters on page 590 Data type system parameters on page 593 Date and time column function system parameters on page 593 Row and column filtering system parameters on page 594 Event log system parameters on page 595 Lock detection system parameters on page 597

General product system parameters let you control basic features of InfoSphere CDC and information you may have specified during installation. In this section, you will learn: Authorization Code on page 578 Enable *MAXOPT3 Option on page 578 Record Format Check on page 578 Startup Timeout on page 579 TCP_KEEPALIVE_SECS on page 579
577
Authorization Code
VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to adjust the authorization code issued by IBM. You may need to modify your authorization code when: v Moving from a temporary license to a permanent license v Machine classes have changed v Upgrading to a new version of InfoSphere CDC Applies ToSource and Target Note: You can also modify the authorization using the Authorization Code Setup utility Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Enable *MAXOPT3 Option

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier For information about setting this system parameter, see your IBM representative. Applies ToSource Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Record Format Check

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable or disable InfoSphere CDC from checking record formats of the physical and logical files. Applies ToTarget The Record Format Check system parameter can be set to either *YES or *NO: v *YESEnables InfoSphere CDC to check the record formats of the physical and logical files. Only a physical file that has the same record format as the logical file can be selected as a destination of mirrored data using a unique key. v *NODisables InfoSphere CDC from checking the record formats of the physical and logical files. You can select a physical file to be the destination of mirrored data using a unique key that does not have the same record format as the logical file.
Default Setting*YES
578
Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Startup Timeout
VersionInfoSphere CDC for DB2 for i version 6.2 and earlier For information about setting this system parameter, see your IBM representative. Applies ToSource and Target Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
TCP_KEEPALIVE_SECS
VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to determine the time (in seconds) InfoSphere CDC waits before sending a keep alive notification over the network. During idle periods, InfoSphere CDC sends a keep alive notification to keep the connection open. Applies ToSource and Target Default Setting300 seconds (5 min) Minimum Setting0 Guidelines It is important you set this system parameter when you have a firewall connection that has been configured to timeout. This prevents the firewall from closing the connection. To set this system parameter, do the following: 1. Create a data area named DMCOMMS by issuing the following command: CRTDTAARA DTAARA(<InfoSphere CDC product library>/DMCOMMS) TYPE(*CHAR) LEN(2000) 2. Set the timeout value by issuing the following command: CHGDTAARA DTAARA(<InfoSphere CDC product library>/DMCOMMS (521 10)) VALUE('<value>') where value is a 10-digit number that represents the setting for this system parameter. For example, to set to 1 minute, issue:
CHGDTAARA DTAARA(DMIRROR/DMCOMMS (521 10)) VALUE(0000000060)
To prevent the firewall from closing during active data replication, set this parameter to a value lower than the configured firewall timeout.
579

Replication system parameters let you control how InfoSphere CDC behaves after detecting errors during replication. You can also control how often InfoSphere CDC communicates the status of replication activities, and how InfoSphere CDC should apply a refresh operation. See also: Allow Refresh While Active End on Error During Mirroring End on Error During Refresh on page 581 Refresh After Restore on page 581
Allow Refresh While Active

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable or disable InfoSphere CDC from refreshing a target table while changes are being made to the source table. After InfoSphere CDC completes the refresh, it sends any remaining changes that were made on the source table during the refresh to the target table. Applies ToSource The Allow Refresh While Active system parameter can be set to either *YES or *NO: v *YESEnables InfoSphere CDC to refresh the target table while there are active changes being made on the source table. v *NODisables InfoSphere CDC from performing a refresh when there are active changes being made on the source table. Default Setting*YES Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
End on Error During Mirroring

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to end or continue mirroring when InfoSphere CDC encounters one or more errors. Applies ToTarget The End on Error During Mirroring system parameter can be set to either *YES or *NO: v *YESInfoSphere CDC ends mirroring immediately after it detects an error.
580
v *NOInfoSphere CDC reports the error and continues mirroring after it detects the error. This is the recommended setting for this parameter. Default Setting*NO Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
End on Error During Refresh

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to end or continue a refresh operation after InfoSphere CDC encounters one or more errors. Applies ToTarget The End on Error During Refresh system parameter can be set to either *YES or *NO: v *YESInfoSphere CDC ends a refresh operation immediately after it detects an error. This is the recommended setting for this parameter. v *NOInfoSphere CDC reports the error and continues with the refresh operation after it detects the error. Default Setting*YES Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Refresh After Restore

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to set when InfoSphere CDC refreshes tables that have been restored. Applies ToSource The Refresh After Restore system parameter can be set to either *IMMED or *DELAY: v *IMMEDInfoSphere CDC starts a Refresh of the restored tables immediately. v *DELAYInfoSphere CDC delays the start of a Refresh of the restored tables until the next time a refresh operation is started. InfoSphere CDC also delays the start of a Refresh Before Mirror. Default Setting*IMMED
581

Cascading replication system parameters control InfoSphere CDC cascading replication. See also: Enable Cascading Replicates
Enable Cascading Replicates

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable or disable cascading replication. Applies ToSource The Enable Cascading Replicates system parameter can be set to either *YES or *NO: v *YESEnables InfoSphere CDC to send replicated data from one target system to another target system. v *NODisables InfoSphere CDC from sending replicated data from one target system to another target system. Default Setting*YES Guidelines Set this system parameter to *NO if there are one or more tables being maintained at the same time on two servers. Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577

Database journal or trigger system parameters let you manage the InfoSphere CDC journal table. See also: Default Journal Library Default Journal Name on page 583 Replicate User Defined Journal Entries on page 583 Report Position Interval on page 584 Synchronization Interval on page 584
Default Journal Library

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier
582
Use this system parameter to identify the library where the default InfoSphere CDC journal resides. For more information about journals, see InfoSphere CDC for IBM i Commands Reference. Applies ToSource The Default Journal Library system parameter can be set to either the name of the library, *LIBL , or *CURLIB: v The name of a library. v *LIBLSpecifies the set of libraries in your library list. The libraries are searched in order for the first occurrence of the specified default journal. v *CURLIBSpecifies the current library. Default Setting*CURLIB . Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Default Journal Name

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to identify the name of the InfoSphere CDC default journal. By default, tables mirrored by InfoSphere CDC use this journal. For more information about journals, see InfoSphere CDC for IBM i Commands Reference. Applies ToSource Default SettingDMCJRN Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Replicate User Defined Journal Entries

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable or disable InfoSphere CDC processing user-defined journal entries for replication. For information about processing user-defined journal entries for replication, see InfoSphere CDC for IBM i Commands Reference. Applies ToSource The Replicate User Define Journal Entries system parameter can be set to either *NO or *YES: v *NODisables InfoSphere CDC from processing user-defined journal entries for replication. v *YESEnables InfoSphere CDC to process user-defined journal entries for replication.
583
Default Setting*NO Guidelines Setting this system parameter to *YES can impact overall performance.
Report Position Interval

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to set how often (in milliseconds) InfoSphere CDC informs the target system about its log position. When the source system is in idle mode and there are no log entries for the subscription, the source system informs the target system of its current log position. The target system uses this information to advance its bookmarks. Applies ToSource Default Setting5000 milliseconds (5 seconds) Minimum Settings1000 milliseconds (1 second) Maximum Settings300000 milliseconds (5 minutes) Guidelines v If the number of milliseconds is set low, then the target system can provide accurate progress notifications that indicate how far replication has progressed. v If the number of milliseconds is set high, it may affect the accuracy of the information displayed in progress and bookmark notifications. Notes: v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. v This system parameter can also prevent InfoSphere CDC from rereading log entries that do not apply to the table currently being replicated.
Synchronization Interval
VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to set how often (in seconds) InfoSphere CDC performs log synchronization between the source and the target. Synchronization is achieved when the source reports to the target the position of the last committed change. Applies ToSource Default Setting60 seconds Minimum Settings1 second Maximum Settings3000 seconds (50 minutes) Guidelines
584
If you are replicating large volumes of data, set this system parameter to a lower number of seconds to remove obsolete logs more frequently. Note: If a value outside the acceptable range is specified, the default setting is used.
Remote journal system parameters

Remote journal system parameters let you control if InfoSphere CDC uses remote or local journaling when running source replication activities. See also: Data Origin TCP/IP Name Data Origin Port Relational Database Directory Entry on page 586
Data Origin TCP/IP Name

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable Management Console and InfoSphere CDC (installed on the InfoSphere CDC/400 Source System) to use the IP address or host name of the InfoSphere CDC/400 Data Origin Server (where your source files reside). Applies ToInfoSphere CDC/400 Data Origin Server v IP AddressEnables Management Console to use the IP address or host name of the InfoSphere CDC/400 Data Origin Server. This lets InfoSphere CDC (installed on the InfoSphere CDC/400 Source System) to retrieve source files from the InfoSphere CDC/400 Data Origin Server. The value can be either the host name or the IP address of the InfoSphere CDC/400 Data Origin Server. v *LOCAL Management Console uses the IP address or host name of the InfoSphere CDC/400 Source System. Setting this system parameter to *LOCAL disables InfoSphere CDC from performing replication activities with a remote journal. Default Setting*LOCAL Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Data Origin Port

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable Management Console and InfoSphere CDC (installed on the InfoSphere CDC/400 Source System) to use the port number of the InfoSphere CDC/400 Data Origin Server. The value that you specify for this system parameter must match the TCP listener port number of the InfoSphere CDC/400 Data Origin Server. Applies ToInfoSphere CDC/400 Data Origin Server
585
Default Setting0 GuidelinesYou must enable the Data Origin TCP/IP Name system parameter to either the IP address or the host name of the InfoSphere CDC/400 Data Origin Server for this system parameter to take affect.
Relational Database Directory Entry

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to specify the relational database directory entry added to the InfoSphere CDC/400 Source System which references the relational database directory entry on the InfoSphere CDC/400 Data Origin Server. Applies ToInfoSphere CDC/400 Data Origin Server Default Setting*NONE GuidelinesYou must enable the Data Origin TCP/IP Name system parameter to either the IP address or the host name of the InfoSphere CDC/400 Data Origin Server for this system parameter to take affect.

Commitment control system parameters let you control how InfoSphere CDC issues commits to the target system. See also: Commitment Control
Commitment Control
VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable or disable InfoSphere CDC from using commitment control. Enabling commitment control maintains transaction consistency during replication and ensures that all transactions are applied to the target system. If there is a communications or server failure, and you have enabled this system parameter, then InfoSphere CDC rolls back the partially applied transaction to the last commit. Applies ToTarget The Commitment Control system parameter can be set to *NONE or *LEVEL1: v *NONEDisables commitment control for transaction processing. InfoSphere CDC does not maintain transaction consistency during replication and in the event of a communications or server failure. To ensure consistency across different platforms and previous releases of InfoSphere CDC, disabling commitment control is the default setting for this parameter. v *LEVEL1Enables InfoSphere CDC to use commitment control against the target system after applying all rows. This setting provides true transaction consistency by ensuring that entire transactions are committed to the target database even in the event of a communications or server failure.
586
Default Setting*NONE Guidelines If you select *LEVEL1, you must disable the system parameter Refresh While Active on the source. Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577 Related reference Allow Refresh While Active on page 580

Multibyte character set system parameters let you control how InfoSphere CDC treats character sets during replication. See also: Unicode Handling
Unicode Handling
VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to indicate the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Applies ToSource The following IBM DB2 for i data types are considered to be Unicode columns and are affected by the value assigned to this system parameter: v GRAPHIC or VARGRAPHIC with code page 1208 (UTF-8) v CHARACTER or VARCHAR with code page 1208 (UTF-8) This system parameter is set to either CHAR or NOCHANGE: v CHARInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v NOCHANGEInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. NOCHANGE ensures InfoSphere CDC will handle non-single-byte character data in the same way as previous InfoSphere CDC releases. Default SettingNOCHANGE Note: NOCHANGE does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated
587
non-single-byte character data, you many need to apply user exit programs or other customization to properly represent the data in Unicode columns. For more information about user exit programs, see your InfoSphere CDC for IBM i documentation. Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577 Related tasks To set handling for Unicode character encoding on page 194

Latency system parameters let you control how often InfoSphere CDC generates a latency notification and updates latency statistics in the Event Log. See also: Deadband Percentage Monitor Sample Interval on page 590
Deadband Percentage
VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Applies ToTarget Identifies the size of the range around each latency threshold setting. Based on latency thresholds defined, a latency message is generated when latency has risen above or fallen below a threshold. Latency is calculated at regular intervals, where the interval is the current setting for the MONITOR_SAMPLE_INTERVAL system parameter. You can set notifications in response to a generated latency message. This system parameter, which is expressed as a percentage, allows you to pad a threshold equally on both sides to create a range around the threshold. By adjusting this system parameter, the size of the range around the threshold can be increased or decreased, and the threshold itself can be made thicker or thinner. A latency message is generated only when latency has risen above the upper limit of the range or fallen below the lower limit of the range. By changing the value assigned to this system parameter, you can control the number of latency messages placed in the Event Log. For example, assume that a latency threshold is 5 minutes and this system parameter is set to 10. A 10% range is applied around the 5 minute threshold. The following calculations are performed to determine the lower and upper limits (in minutes) of the range around the threshold: v Padding = 10% of 5 minutes = 0.5 minutes (rounded up to 1 minute) v Padding is rounded up or down to the nearest whole minute: Upper limit of range = 5 minutes + 1 minute (padding) = 6 minutes Lower limit of range = 5 minutes - 1 minute (padding) = 4 minutes As a result, a latency message will be generated only when latency rises above 6 minutes or falls below 4 minutes. Given sample latency over a ten minute period where latency is calculated every minute, three latency messages are generated.
588
This graph illustrates latency message generation with the DEADBAND_PERCENTAGE value set to 10%:
If the number of latency messages generated over the ten minute period for the 10% (3 latency messages) and 3% (5 latency messages) settings are averages, an additional 288 latency messages would be generated each day if this system parameter is not changed from its default setting to 10%. Since there are two latency thresholds that you can set (a warning threshold and a problem threshold), two separate ranges are defined when padding is at least one minute. In this case, each range is attached to its threshold, and the two ranges can overlap with no change in behavior. If a value outside the acceptable range is specified, the default setting is used. Default Setting3% Minimum Setting3% Maximum Setting10% Note: If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults.
589
Monitor Sample Interval

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to set how often (in seconds) InfoSphere CDC updates replication latency metrics. InfoSphere CDC samples the target system to determine if latency has risen above or fallen below the specified threshold settings. Applies ToSource and Target Default Setting5 seconds Minimum Setting0 seconds. Replication latency metrics are not updated. Maximum Setting3600 seconds (one hour) Notes: v InfoSphere CDC generates latency notifications when latency rises above or falls below the thresholds and places these in the Event Log. v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults.

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: Heartbeat Timeout Messages on Column Not Null Capable on page 591 Messages on Invalid Numerics on page 591 Progress Status Interval on page 592
Heartbeat Timeout
VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to increase or decrease the communication timeout interval (in minutes) before InfoSphere CDC detects a communication problem and attempts to stop active replication processes. InfoSphere CDC sends internal heartbeat notifications between the source and target systems to verify communications and the status of replication processes for each active subscription. If the source or target do not receive a reply to a notification within the specified timeout interval, then InfoSphere CDC determines that a problem has occurred and attempts to stop all its source and target processes for each active subscription.
590
InfoSphere CDC places notifications (message identifiers DMU3165 and DMU0647) in the Event Log when a heartbeat timeout occurs. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Note: If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Messages on Column Not Null Capable

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable or disable InfoSphere CDC from generating a message each time it attempts to replicate NULL to a target column that is non-nullable. Applies ToTarget The Messages on Column Not Null Capable system parameter can be set to either *YES or *NO: v *YESEnables InfoSphere CDC to generate a message each time it attempts to replicate NULL to a target column that is non- nullable. v *NODisables InfoSphere CDC from generating a message each time it attempts to replicate NULL to a target column that is non-nullable. For all instances, you are notified by a message. Default Setting*YES Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Messages on Invalid Numerics

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable or disable InfoSphere CDC from generating a message each time it detects an invalid numeric field. Applies ToTarget The Messages on Invalid Numerics system parameter can be set to either *YES, *NO, or *NB: v *YESInfoSphere CDC generates a message for each invalid numeric field detected.
591
v *NOInfoSphere CDC does not generate a message for each invalid numeric field detected. If you are sure that numeric data does not have to be validated, set this parameter to *NO to maintain existing performance levels. v *NBInfoSphere CDC does not generate a message when blank or uninitialized numeric fields are detected. Messages for other types of invalid numeric data are still generated. Default Setting*YES Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577 Related reference Numeric Column Validation on page 593
Progress Status Interval

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to set how often (in seconds) InfoSphere CDC issues progress notifications. InfoSphere CDC generates notifications on the source and target and these provide information about replication activities. On the source, progress notifications identify: v v v The bookmark sent by the source The corresponding log name The subscription name to which the bookmark was sent
On the target, progress notifications identify: v v v The bookmark received by the target The corresponding log name The source ID from which the bookmark was received
Applies ToSource and Target Default Setting0 seconds. No progress messages are issued. Minimum Setting0 seconds Maximum Setting7200 seconds Notes: v InfoSphere CDC places progress notifications in the Event Log. v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults.
592
Data type system parameters

Data type system parameters let you control how InfoSphere CDC handles certain data types. See also: Numeric Column Validation
Numeric Column Validation

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable or disable InfoSphere CDC from checking decimal and numeric columns for valid formats before applying numeric data to the target table. Applies ToTarget The Numeric Column Validation system parameter can be set to either *YES or *NO: v *YESEnables InfoSphere CDC to validate invalid packed/zoned data before applying it to the target table. If invalid packed/zoned data is found, then InfoSphere CDC generates a message is generated set the field to 0 automatically. *NODisables InfoSphere CDC from validating packed/zoned data before applying it to the target table. If you are sure that numeric data does not have to be validated, set this parameter to *NO to maintain existing performance levels.
Default Setting*YES Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Date and time column function system parameters

Date and time column function system parameters let you control how InfoSphere CDC handles date and time in tables. See also: Default Date On Error
Default Date On Error

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to set which date InfoSphere CDC returns when an invalid date is passed to the %TODATE column function. Applies ToTarget
593
The Default Date On Error system parameter can be set to *NEW or *OLD: v *NEWReturns the date 1901-01-01. v *OLDReturns the date 0001-01-01. Default Setting*NEW Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577 Related reference Date conversion%TODATE on page 262
Row and column filtering system parameters

Row and column filtering system parameters let you control what kind of data InfoSphere CDC applies to the target system. See also: Audit Filtered Transactions Critical Column Filtering on page 595
Audit Filtered Transactions

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to set which images you want to audit after InfoSphere CDC applies a row update that satisfies a row-filtering expression. By default, InfoSphere CDC audits both the before and after images after applying a row update that satisfies a row-filtering expression. Applies ToSource The Audit Filtered Transactions system parameter can be set to either *YES or *NO: v *YESAudits both the before and after images when a row update results in only one of these images satisfying a defined row-filtering expression. v *NOAudits only the after image that satisfies or does not satisfy a defined row-filtering expression. Default Setting*YES Guidelines v You can use this system parameter to override a row-filtering expression when it is necessary to audit both before and after images in the target table, but only one of these images satisfies the row-filtering expression. In this scenario, you can use two journal codes (FP and FB) to identify the images in the target audit table that do not satisfy the row-filtering expression. You may want to enable this system parameter to *YES when: v Using LiveAudit to audit changes made on the source table. v Recording both the before and after images in the target audit table when a row update operation is applied to the assigned publication table. v Using row-filtering expressions to filter rows placed in the target audit table.
594
Notes: v Previous releases of InfoSphere CDC do no support this system parameter. v The listed default setting (*YES) applies only to new InfoSphere CDC installations on an IBM i server. The default setting for InfoSphere CDC upgrades is *NO. This setting maintains existing InfoSphere CDC behavior prior to support for this system parameter. Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577 About journal control fields on page 197
Critical Column Filtering

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to enable critical column selection. Applies ToSource The Critical Column Filtering system parameter can be set to either *YES or *NO: v *YESEnables critical column selection. v *NODisables critical column selection. Default Setting*NO Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
Event log system parameters

Event log system parameters let you control how InfoSphere CDC interacts with notify message queues. See also: Notify Message Queue Notify Message Queue Library on page 596 Notify Message Threshold on page 596
Notify Message Queue

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to identify the name of the message queue that InfoSphere CDC uses to send notifications when the number of errors exceeds the notify message threshold system parameter. Applies ToSource and Target Default SettingQSYSOPR
595
Note: You can set the notify message threshold using the Notify Message Threshold system parameter. Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577 Related reference Notify Message Threshold
Notify Message Queue Library

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to identify the name of the library where the notify message queue resides. Applies ToSource and Target You can set the Notify Message Queue Library system parameter to one of the following: v The name of a library v *LIBLSpecifies the set of libraries in your library list. The libraries are searched in order for the first occurrence of the specified message queue. v *CURLIBSpecifies the current library. Default Setting*LIBL Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577 Related reference Notify Message Queue on page 595
Notify Message Threshold

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to identify the number of errors that InfoSphere CDC generates before it sends a notification to the notify message queue. Applies ToSource and Target Default Setting1 error
596
Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577 Related reference Notify Message Queue on page 595

Lock detection system parameters let you control how InfoSphere CDC applies data when it detects a locked table or row. See also: Lock Timeout Value
Lock Timeout Value

VersionInfoSphere CDC for DB2 for i version 6.2 and earlier Use this system parameter to set the amount of time (in seconds) that InfoSphere CDC waits before attempting to modify a locked user or metadata table. When InfoSphere CDC attempts to modify a locked table, it places a notification in the Event Log. These notifications identify the specific table and row that InfoSphere CDC could not modify. Applies ToSource and Target Default Setting30 seconds Minimum Setting2 seconds Maximum Setting60 seconds Notes: v If a table or row is locked, InfoSphere CDC waits for a specified timeout period to expire before attempting to apply data again. v If you set a value outside the acceptable range, then InfoSphere CDC uses the defaults. Related concepts System parameters for InfoSphere CDC for DB2 for i (version 6.2 and earlier) on page 577
597
598
System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Note: If you make changes to a system parameter during active replication, you must stop and restart replication for the changes to take effect. When upgrading to a later version of InfoSphere CDC, any preexisting settings for system parameters are maintained. In this section, you will learn: General product system parameters Access Server system parameters on page 603 Cascading replication system parameters on page 606 Commitment control system parameters on page 607 Database translation log system parameters on page 610 Fastload system parameters on page 611 Latency system parameters on page 615 Lock detection system parameters on page 615 Multibyte character set system parameters on page 617 Notification system parameters on page 618 Replication system parameters on page 619 Tracing system parameters on page 621 Teradata TPump system parameters on page 622

General product system parameters let you control basic features of InfoSphere CDC and information you may have specified during installation. See also: audit_auth_ code on page 600 auth_ code on page 600 db_password on page 600 db_user on page 601 debug on page 601 engine_ port on page 601 log_file_quota on page 601
599
log_total_quota on page 601 md_db_url on page 602 md_schema on page 602 scrape_timeout on page 602 startup_timeout on page 602 target_debug on page 602 target_initial_codepage on page 603 ts_password on page 603 ts_product on page 603
audit_auth_ code
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the authorization code used to enable the LiveAudit feature in InfoSphere CDC. When assigning the authorization code to this system parameter, authorization codes are case-sensitive; therefore, the code assigned to this parameter must be identical to the one obtained from IBM. Applies ToSource and Target for InfoSphere CDC for DB2 UDB Does Not Apply ToInfoSphere CDC for Teradata Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
auth_ code
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the authorization code that is required to replicate and receive data with InfoSphere CDC. When assigning the authorization code to this system parameter, authorization codes are case-sensitive; therefore, the code assigned to this parameter must be identical to the one obtained from IBM. Applies ToSource and Target for InfoSphere CDC for DB2 UDB Does Not Apply ToInfoSphere CDC for Teradata Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
db_password
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier
600
For information about setting this system parameter, see your IBM representative.
db_user
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier For information about setting this system parameter, see your IBM representative.
debug
engine_ port
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the port number on the server that is being used for communications with client workstations running Management Console and other replication servers. This port number was specified during InfoSphere CDC installation. It can be changed by modifying this system parameter or using the Change Listener Port utility. For more information about this utility, see the appropriate InfoSphere CDC installation and user manual. The port number that you specify must be unused, and the same port number cannot be used for any other application installed on the same server. Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Default Setting11111 Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
log_file_quota
log_total_quota
601
md_db_url
md_schema
scrape_timeout
startup_timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter specifies the maximum waiting period, in seconds, for process handling to complete during InfoSphere CDC startup. This system parameter indicates how long the communication module waits for the database initialization program to start before timing out. Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Default Setting120 seconds Minimum Setting60 seconds Maximum Setting3,600 seconds Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
target_debug
602
target_initial_codepage
ts_password
ts_product
Access Server system parameters

Access Server system parameters are for managing Access Server. See also: accessserver_udp_ listenport agent_assert on page 604 agent_debug on page 604 agent_jdbcdb2_driver on page 604 agent_jdbcdb2_driver_net on page 604 agent_jdbcpb_driver on page 604 agent_jdbcpb_driver_net on page 604 agent_max_connections_num on page 605 agent_message_version on page 605 agent_msg_resources_file on page 605 agent_src_engine_address on page 605 agent_src_engine_port on page 605 agent_src_engine_socket_tmout on page 605 agent_trace_in_message on page 605 agent_trace_out_message on page 606 agent_udp_ listenport on page 606
accessserver_udp_ listenport
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the UDP listener port number used by Access Server to receive auto-discovery broadcast InfoSphere CDC from different datastores in your configuration. The port number that you specify must not
603
already be in use on the client workstation, and must be the same port number specified in Management Console when logging on. If the port number is changed on a client workstation running Management Console, this system parameter must be set to the updated port number. Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Default Setting10101 Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
agent_assert
agent_debug
agent_jdbcdb2_driver
agent_jdbcdb2_driver_net
agent_jdbcpb_driver
agent_jdbcpb_driver_net
604
agent_max_connections_num
agent_message_version
agent_msg_resources_file
agent_src_engine_address
agent_src_engine_port
agent_src_engine_socket_tmout
agent_trace_in_message
605
agent_trace_out_message
agent_udp_ listenport
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the port number on the replication server used by the UDP listener for auto-discovery broadcasts sent from Access Server. The port number that you specify must be unique. Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Default Setting2222 Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73

Cascading replication system parameters control InfoSphere CDC cascading replication. See also: cascade_replication
cascade_replication
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates whether or not replicated data received from the source can be replicated (or cascaded) to other servers. This system parameter is set on the server that receives replicated data and can cascade the data to one or more other servers. It is applicable when implementing cascading replication. Applies ToSource for InfoSphere CDC for DB2 UDB Does Not Apply ToInfoSphere CDC for Teradata Set this parameter to one of the following: v NPrevent replicated data received from the source from being cascaded to other servers. v YAllow replicated data received from the source to be cascaded to other servers.
606
Default SettingY Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73

Commitment control system parameters let you control how InfoSphere CDC issues commits to the target system. See also: commit_group_size commit_ interval on page 608 refresh_commit_ block_size on page 609 scraper_trans_ num_limit on page 609 source_default_ commit_level on page 609 target_default_commit_level on page 610
commit_group_size
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter specifies the number of rows that must be applied to the target database before a commit is issued. Normally, commits issued to the target database are in response to commits issued by applications running on the source. This system parameter should only be used when you want manage commits by controlling how often they are issued to the target database. This approach can be used to reduce the overhead of frequent commits to the database. However, managing commits in this manner may result in inconsistent data in the source and target databases over time. To manage commits to the target database by setting the commit group size, you must disable commitment control on the target, by setting the target_default_commit_level on page 610 system parameter. To properly calibrate database commits in your environment, you must work with this system parameter and the dobatch on page 619 system parameter. If the commit interval frequently expires before a commit group with the specified number of applied rows has been formed, a smaller number of rows are committed. In this case, you can decrease the commit group size or increase the commit interval. However, when a commit group contains an insufficient number of applied rows for it to be committed, you must set the commit interval to ensure data is committed within a reasonable period of time. If this system parameter is set to 0, then: v Commits are issued at regular intervals when a non-zero commit interval is specified. v A commit is issued for each applied row when a zero commit interval is specified. When commit_group_size and dobatch on page 619 are both set to zero, InfoSphere CDC internally sets this system parameter to 1 row (default setting) to ensure commits are issued.
607
Applies ToTarget, InfoSphere CDC for DB2 UDB only Default Setting1 row. A commit is issued for each applied row. Minimum Setting0 Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
commit_ interval
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter specifies the amount of time, in seconds, between consecutive commits issued to the target database. Normally, commits issued to the target database are in response to commits issued by applications running on the source. This system parameter should only be used when you want to manage commits by controlling how often they are issued to the target database. This approach can be used to reduce the overhead of frequent commits to the database. However, managing commits in this manner may result in inconsistent data in the source and target databases over time. To manage commits to the target database by setting the interval between consecutive commits, you must disable commitment control on the target, by setting the target_default_commit_level on page 610 system parameter. To properly calibrate database commits in your environment, you must work with this system parameter and the commit_group_size on page 607 system parameter. For commit groups that have an insufficient number of applied rows for a commit to be issued, use this system parameter to prevent applied rows in the commit group from being uncommitted for a long period of time. In particular, you can use it to force commits during periods of transaction inactivity. However, if you set the commit interval so that it frequently expires before a commit group with the specified number of applied rows has been formed, a smaller number of rows are committed. In this case, you can increase the commit interval or decrease the commit group size. If this system parameter is set to 0, then: v A commit is issued every 5 seconds (default setting) when the size of the commit group is more than one row. In this case, InfoSphere CDC internally sets this system parameter to 5 seconds (default setting) to ensure that a commit group which cannot be committed due to an insufficient number of applied rows is committed in 5 seconds. v A commit is issued for each applied row when a zero commit group size is specified. When commit_group_size and dobatch on page 619 are both set to zero, InfoSphere CDC internally sets commit_group_size to 1 row (default setting) to ensure commits are issued. Applies ToTarget, InfoSphere CDC for DB2 UDB only Default Setting5 seconds Minimum Setting0
608
Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
refresh_commit_ block_size
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the number of records to be inserted into a target table during a refresh operation before a commit is issued to make those records persistent. If the tables that you are replicating are relatively large, it is recommended that you increase the block size to improve performance. Applies ToTarget Default Setting1,000 records Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
scraper_trans_ num_limit
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the number of row level entries that are staged in memory before they are sent to the target. This parameter should be set to the largest commitment cycle size on your server. Commitment cycle size is the number of transactions in one commitment cycle. For example, the size of the following commitment cycle is six:
insert insert insert insert insert commit into into into into into <table> <table> <table> <table> <table> <values> <values> <values> <values> <values>
Applies ToSource, InfoSphere CDC for DB2 UDB only Default Setting1,000,000 row level entries Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
source_default_ commit_level
609
This system parameter indicates the commitment control level for transactions mirrored from the source. Applies ToSource, InfoSphere CDC for DB2 UDB Does Not Apply ToInfoSphere CDC for Teradata Set this parameter to one of the following: v 0Disables commitment control for transaction processing. No attempt to maintain transaction consistency is performed during mirroring. v 2Only records in a committed transaction are mirrored to the target. This setting provides true transaction consistency by ensuring that only committed transactions are sent to the target. Default Setting0
target_default_commit_level
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates the commitment control level for transactions applied on the target. Applies ToTarget, InfoSphere CDC for DB2 UDB Does Not Apply ToInfoSphere CDC for Teradata Set this parameter to one of the following: v 2A commit to the target database is performed when all records in a transaction have been received and applied. This setting provides true transaction consistency by ensuring that entire transactions are committed to the target database. If a communications or server failure occurs, a partially applied transaction in the target database is rolled back to the last transaction that was committed. v 0Disables commitment control for transaction processing. No attempt to maintain transaction consistency is performed during mirroring. Default Setting2 Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
Database translation log system parameters

Database transaction log system parameters let you control how InfoSphere CDC cleans the logs of the distribution database. You can also control often InfoSphere CDC reports its log position to the target and performs log synchronization between the source and the target. See also: report_position_interval on page 611
610
report_position_interval
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter specifies how often, in seconds, the source informs the target about its position in the current log during inactive periods. During inactive periods, when there are no log entries pertaining to the current subscription, the source informs the target of its current position so that the target can advance its bookmarks accordingly. By specifying a low setting for this parameter, the target can reflect more accurately how far replication has progressed. This system parameter can also prevent the reprocessing of entries that do not apply to the table currently being replicated. The value of this parameter affects the information that is displayed in Management Console. A high setting for this parameter may result in presented information that is not up-to-date. Applies ToSource, InfoSphere CDC for DB2 UDB Does Not Apply ToInfoSphere CDC for Teradata Default Setting5 seconds Minimum Setting1 second Maximum Setting300 seconds Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
Fastload system parameters

Fastload system parameters allow you to configure the Teradata Fastload utility. InfoSphere CDC for Teradata uses the Fastload utility to load replicated data into Teradata databases. See also: refresh_del_fastload_file dofastload on page 612 fastload_backup_path on page 613 fastload_in_whole on page 613 fastload_path on page 613 make_fastload_log_file on page 614 max_fastload_ file_size on page 614
refresh_del_fastload_file
611
This system parameter indicates whether or not Teradata FastLoad files are deleted after using the utility to refresh data in a Teradata database under standard replication. You can keep these files for future reference or delete them to increase available disk space. To refresh data in a Teradata database using the Teradata FastLoad utility, set dofastload =Y. For more information about the Teradata FastLoad utility, see your Teradata documentation. Applies ToTarget, InfoSphere CDC for Teradata only Set this parameter to one of the following: v NKeep the Teradata FastLoad files after data has been refreshed in a Teradata database. v YDelete the Teradata FastLoad files after data has been refreshed in a Teradata database. Default SettingY Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
dofastload
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter enables or disables a Fast Bulk Copy (BCP) refresh. Generally, a BCP refresh provides a better level of performance than a batch refresh (see dobatch on page 619) or the standard row-by-row refresh. Applies ToTarget, InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata Set this parameter to one of the following: v NDo not perform a BCP refresh. v YPerform a BCP refresh. In addition, you must: 1. Set the fastload_path on page 613 system parameter to the path of the temporary file. 2. Set the fastload_backup_path on page 613 system parameter to the path of the stored backup image. 3. Ensure there are no large object (LOB) data types within your user data. BCP refresh cannot work with tables containing LOB data types. If a LOB column is found, a standard (row-by-row) refresh is performed. To determine if there is an error in the loading process for BCP refresh, examine the message appended to the loadmsg file in your InfoSphere CDC installation directory. Default SettingN
612
fastload_backup_path
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the path to a stored backup image of the loaded data for a BCP refresh. The database user that owns the InfoSphere CDC metadata tables must have read and write permissions to the files whose locations are identified by the fastload_pathand fastload_backup_path system parameters. Applies ToTarget, InfoSphere CDC for DB2 UDB only Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
fastload_in_whole
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates how data is transferred to the Teradata FastLoad utility in order to refresh data in a Teradata database. Data can be refreshed in a single bulk operation or incrementally. The size of each data file passed to the Teradata FastLoad utility is determined by the max_fastload_ file_size on page 614 system parameter. For more information about the utility, see your Teradata documentation. Applies ToTarget, InfoSphere CDC for Teradata only Set this parameter to one of the following: v NSubmit a data file to the Teradata FastLoad utility immediately after the file has been filled with replicated data. v YSubmit all data to the Teradata FastLoad utility after it has been received from the publication server. Default SettingN Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
fastload_path
613
This system parameter identifies the path to the temporary file used for a Fast Bulk Copy (BCP) refresh. During a BCP refresh, a copy image of the loaded data is saved in this temporary file. The database user that owns the InfoSphere CDC metadata tables must have read and write permissions to the files whose locations are identified by the fastload_path on page 613 and fastload_backup_path on page 613 system parameters. Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
make_fastload_log_file
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates whether or not Teradata FastLoad log files are created. Log files contain messages generated during refresh operations performed by the Teradata FastLoad utility. You can create log files and examine their contents to determine whether or not refresh operations were successful. Log files are named DM_<username>_<tablename>.log , where <username> is the database user name that owns the subscription table being refreshed and <tablename> is the name of the subscription table. These files are placed in the directory identified by the fastload_path on page 613 system parameter. The database user name and InfoSphere CDC installation directory were specified during the installation process. Applies ToTarget, InfoSphere CDC for Teradata only Set this parameter to one of the following: v NDo not create Teradata FastLoad log files to track data refresh operations. v YCreate the Teradata FastLoad log files to track data refresh operations. For more information about the Teradata FastLoad utility, see your Teradata documentation. Default SettingN Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
max_fastload_ file_size
614
This system parameter identifies the size, in bytes, that the data file must reach before the Teradata FastLoad utility refreshes data in a Teradata database. If the amount of refreshed data is larger than the specified size, InfoSphere CDC closes the data file after it has been filled and passes it to the Teradata FastLoad utility so that data is refreshed in the Teradata database. Additional data files are used to ensure the remaining data is refreshed. Applies ToTarget, InfoSphere CDC for Teradata only Default Setting2,000,000,000 bytes Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73

Latency system parameters let you control how often InfoSphere CDC generates a latency notification and updates latency statistics in the Event Log. See also: monitor_sample_interval
monitor_sample_interval
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the period of time, in seconds, between consecutive updates to a storage area that is used to maintain replication latency metrics. Management Console references this area to present replication latency information. Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Default Setting5 seconds Minimum Setting0 seconds. Replication latency metrics are not updated. Maximum Setting3,600 seconds (1 hour) Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73

Lock detection system parameters let you control how InfoSphere CDC applies data when it detects a locked table or row. See also: dm_lock_detection on page 616
615
dm_lock_timeout
dm_lock_detection
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates whether or not table and row locking detection is enabled. If a table or row has been locked by another process while InfoSphere CDC attempts to modify that table or row, InfoSphere CDC waits for a specific amount of time, specified by dm_lock_timeout, before attempting to apply data again. InfoSphere CDC generates messages, which can be displayed in Event Log, when an attempt is made to modify a locked target table or row. These messages identify the specific table or row that could not be modified. Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Set this parameter to one of the following: v YEnables table and row locking detection. v NDisables table and row locking detection. InfoSphere CDC waits until the locked table or row becomes available. Default SettingY Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
dm_lock_timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Specifies the amount of time, in seconds, InfoSphere CDC waits for a locked table or row to become available. This system parameter is applicable only when table and row locking detection is enabled, using the dm_lock_detection system parameter. Default Setting30 seconds Minimum Setting1 second Maximum Setting60 seconds
616

Multibyte character set system parameters let you control how InfoSphere CDC treats character sets during replication. See also: unicode_handling
unicode_handling
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates the default method of treating data in defined Unicode columns. For information about how data in each Unicode source column is treated, see Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Applies ToSource for InfoSphere CDC for DB2 UDB The following DB2 UDB data types are considered to be Unicode columns, and are therefore affected by the value assigned to this system parameter: v GRAPHIC v VARGRAPHIC v LONG VARGRAPHIC with code page 1200 (UCS-2 big endian) This system parameter is set to either CHAR or NOCHANGE: v CHARInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v NOCHANGEInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. NOCHANGE ensures InfoSphere CDC will handle non-single-byte character data in the same way as previous InfoSphere CDC releases. Notes: v NOCHANGE does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you may have to apply user exit programs or other customization to properly represent data in Unicode columns. For more information about user exit programs, see your InfoSphere CDC for DB2 UDB documentation.
617
v If you are using IBM DB2 UDB Version 7 database, a BCP refresh locks the replication data tablespace during loading. For this reason, metadata is not updated during a BCP refresh if the metadata tables are located in the same tablespace as the replicated data. For more information on how to avoid this situation, see the appropriate InfoSphere CDC commands reference or user manual. Default SettingNOCHANGE Note: NOCHANGE does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you many need to apply user exit programs or other customization to properly represent the data in Unicode columns. Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: dm_status_interval heartbeat_timeout on page 619
dm_status_interval
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter specifies how often, in seconds, progress messages are issued. Progress messages are displayed in Event Log to provide detailed and regular information about InfoSphere CDC replication activities. On the source, these messages identify the current bookmark that was sent by the source, its corresponding log name, and the subscription name to which the bookmark was sent. On the target, progress messages identify the current bookmark that was received by the target, its corresponding log name, and the source ID from which the bookmark was received. Applies ToSource and Target for InfoSphere CDC for DB2 UDB, Target only for InfoSphere CDC for Teradata Default Setting0 seconds. No progress messages are issued. Minimum Setting0 seconds Maximum Setting7200 seconds
618
heartbeat_timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter specifies the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource, InfoSphere CDC for DB2 UDB Does Not Apply ToInfoSphere CDC for Teradata Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73

Replication system parameters let you control how InfoSphere CDC behaves after detecting errors during replication. You can also control how often InfoSphere CDC communicates the status of replication activities, and how InfoSphere CDC should apply a refresh operation. See also: dobatch source_default_active_refresh on page 620 target_mirror_number_of_errors_before_abort on page 620 target_print_refresh_details on page 620 target_refresh_number_of_errors_before_abort on page 621
dobatch
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter enables or disables a batch refresh. Generally, a batch refresh provides a better level of performance than the standard row-by-row refresh. Applies ToTarget, InfoSphere CDC for DB2 UDB
619
Does Not Apply ToInfoSphere CDC for Teradata Set this parameter to one of the following: v YPerform a batch refresh. In addition, you must ensure that there are no large objects (LOB) data types within your user data. A batch refresh cannot work with tables containing LOB data types. If a LOB column is found, a standard (row-by-row) refresh is performed. v NDo not perform a batch refresh. Default SettingY Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
source_default_active_refresh
target_mirror_number_of_errors_before_abort
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates how many errors to accept on the target before stopping mirroring. To perform mirroring through any number of errors, set this parameter to -1. Applies ToTarget Attention: If you set this parameter to values greater than 0, data inconsistencies between the source and target tables may occur. Default Setting0 Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
target_print_refresh_details
620
target_refresh_number_of_errors_before_abort
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates how many errors to accept on the target before stopping a refresh. To perform refresh through any number of errors, set this parameter to -1. Applies ToTarget Attention: Do not set this parameter to 0. This setting stops the refresh after the first record has been successfully refreshed. Default Setting1

Tracing system parameters let you perform diagnostic activities with InfoSphere CDC. See also: message_handler_trace_level message_trace_level target_trace_logical_messages target_trace_physical_messages on page 622 trace_level on page 622 trace_on on page 622
message_handler_trace_level
message_trace_level
target_trace_logical_messages
621
target_trace_physical_messages
trace_level
trace_on
Teradata TPump system parameters

Teradata TPump system parameters allow you to configure the Teradata TPump utility. InfoSphere CDC for Teradata uses the TPump utility to load replicated data into Teradata databases. See also: tpump_arc_data_files tpump_files_root_folder on page 623 tpump_logging on page 624 tpump_max_file_size on page 624 tpump_script_params_file on page 625 tpump_script_val_file on page 625 tpump_ timeout on page 626
tpump_arc_data_files
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter enables or disables the archiving of data (.dat) and script (.script) files that are used by the Teradata TPump utility. InfoSphere CDC generates the data and script files that are used by the Teradata TPump utility to load data into Teradata databases. Data files contain the replicated data that is loaded into Teradata, and script files specify what is contained in the data files and how data is loaded. These files are named DM_<timestamp>.dat and DM_<timestamp>.script, where <timestamp> is the number of milliseconds from midnight on January 1, 1970 to the time when the file was created. Applies ToTarget, InfoSphere CDC for Teradata only
622
Set this parameter to one of the following: v NDisables the archiving of Teradata TPump data and script files. Teradata TPump data and script files are deleted immediately after data has been loaded into a Teradata database. v YEnables the archiving of Teradata TPump data and script files. For more information about the Teradata TPump utility in InfoSphere CDC, see your InfoSphere CDC for Teradata documentation. Default SettingN Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
tpump_files_root_folder
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the main directory that is created to accommodate all Teradata TPump files. This setting specifies where all Teradata TPump files are located. Subdirectories under the main directory are labeled with the name of the source ID that is used to receive replicated data. This means that for each source ID, Teradata TPump files are maintained in a separate directory. Applies ToTarget, InfoSphere CDC for Teradata only The three subdirectories that are defined are as follows: v <tpump_files_root_folder>\<source_id>\TPump Contains all data (.dat) and script (.script) files that are generated by InfoSphere CDC and used by the Teradata TPump utility to load data into Teradata databases. Data files contain the replicated data that is loaded into Teradata, and script files specify what is contained in the data files and how data is loaded. These files are named DM_<timestamp>.dat and DM_<timestamp>.script , where <timestamp> is the number of milliseconds from midnight on January 1, 1970 to the time when the file was created. v <tpump_files_root_folder>\<pubid>\TPump\archive Contains all archived data (.dat) and script (.script) files. v <tpump_files_root_folder>\<pubid>\TPump\log Contains all Teradata TPump log files. For more information about log files, see tpump_logging on page 624. These files are named DM_<timestamp>.log , where <timestamp> is the number of milliseconds from midnight on January 1, 1970 to the time when the file was created. where <tpump_files_root_folder> is the value assigned to this system parameter, and <source_id> is the source ID defined in Management Console that is used to receive replicated data. For example, if <tpump_files_root_folder> is d:\test, and <source_id> is NEWYORK, then the following three Teradata TPump subdirectories are created for the NEWYORK source ID: d:\test\NEWYORK\TPump, d:\test\NEWYORK\TPump\ archive, and d:\test\NEWYORK\TPump\log.
623
For more information about the Teradata TPump utility in InfoSphere CDC, see your InfoSphere CDC for Teradata documentation. Default SettingInfoSphere CDC installation directory Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
tpump_logging
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates whether or not Teradata TPump log files are created. The tpump_files_root_folder on page 623system parameter specifies the location of these files. Log files are named DM_<timestamp>.log, where <timestamp> is the number of milliseconds from midnight on January 1, 1970 to the time when the file was created. Applies ToTarget, InfoSphere CDC for Teradata only Set this parameter to one of the following: v YCreate Teradata TPump log files to track data loading operations. v NDo not create Teradata TPump log files to track data loading operations. For more information about the Teradata TPump utility in InfoSphere CDC, see your InfoSphere CDC for Teradata documentation. Default SettingY Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
tpump_max_file_size
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter identifies the size, in bytes, that the data file (.dat) must reach before the Teradata TPump utility loads data into a Teradata database. Data files contain the replicated data that is loaded into Teradata. To optimize performance, you should set this system parameter so that the amount of time it takes for the Teradata TPump utility to load data into a Teradata database is approximately equivalent to the time it takes for the data file to reach the specified size. As a result, the next load operation can start shortly after the current load operation has been completed. Therefore, if the amount of time to load data is longer than the amount of time to fill the data file in preparation for the next load, decrease the number of bytes assigned to this system parameter. In addition to setting this system parameter, you must also set with the tpump_ timeout on page 626 system parameter to specify when the Teradata TPump
624
utility loads data into a Teradata database. If the timeout period frequently expires before the data file reaches its specified size, you can increase the timeout period or decrease the data file size to allow loads to also be determined by data file size. However, when a data file contains an insufficient amount of data for a load to be performed, the timeout period must be set to ensure data is loaded within a reasonable period of time. For information about where the data file is located, see tpump_files_root_folder on page 623. For more information about the Teradata TPump utility in InfoSphere CDC, see yourInfoSphere CDC for Teradata documentation. Applies ToTarget, InfoSphere CDC for Teradata only Default Setting100,000 bytes Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
tpump_script_params_file
tpump_script_val_file
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier Identifies the name of the XML file that InfoSphere CDC uses to generate script (.script) files during replication. Teradata TPump script files specify what is contained in the data files and how data in these files is loaded into Teradata databases. The file identified by this system parameter contains a set of Teradata TPump command parameter settings. You can modify the settings in this file so that the script files generated by InfoSphere CDC during replication are customized for your working environment. For more information about customizing the generated script files using the XML file identified by this system parameter, see your InfoSphere CDC for Teradata documentation. Do not change the default setting for this system parameter. Instead, modify the tpumpscripttsdefaults.xml file so that it contains the command parameter settings that you want. If you want to specify a different XML, this file must exist in the InfoSphere CDC installation directory and contain the correct XML markup to generate valid script files. Generally, the default values in the tpumpscripttsdefaults.xml file are suitable for most working environments. If you want to modify the settings in this file, you must be familiar with XML and Teradata TPump. For more information about Teradata TPump commands and command parameters, see your Teradata documentation. Applies ToTarget, InfoSphere CDC for Teradata only
625
Default Settingtpumpscripttsdefaults.xml Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
tpump_ timeout
VersionInfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata version 6.0 and earlier This system parameter indicates the amount of time, in seconds, between consecutive Teradata TPump data loads into a Teradata database. You can use this system parameter to force data to be loaded when the data file (see tpump_max_file_size on page 624) contains insufficient data for a load to be performed. It can be used to prevent data in a data file from not being loaded for a long period of time. In particular, you can use this system parameter to force loads during periods of slow transaction activity. However, if you set the timeout period so that it frequently expires before a data file can reach the specified size, a smaller amount of data is loaded. In this case, you can increase the timeout period or decrease the data file size to allow loads to also be determined by data file size. For more information about the Teradata TPump utility in InfoSphere CDC, see your InfoSphere CDC for Teradata documentation. Applies ToTarget, InfoSphere CDC for Teradata only Minimum Setting0 seconds. Disables the timeout so that a load is only performed when the data file reaches the size specified by the tpump_max_file_size system parameter. Default Setting5 seconds Related concepts System parameters for InfoSphere CDC for DB2 UDB and InfoSphere CDC for Teradata (version 6.0 and earlier) on page 599 Setting system parameters on source and target datastores on page 73
626
System parameters for InfoSphere CDC for DB2 for LUW (version 6.1 and later)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Notes: v If you make changes to a system parameter during active replication, you must stop and restart InfoSphere CDC for the changes to take effect. v When upgrading to a higher version of InfoSphere CDC, any preexisting settings for system parameters are maintained. In this section, you will learn: General product system parameters Notification system parameters on page 628 Maximize throughput system parameters on page 630 Encoding system parameters on page 631 Disk resource system parameters on page 632 Apply process system parameters on page 634

VersionInfoSphere CDC for IBM DB2 UDB version 6.3 Fix Pack 3 TFE 9 and later. Use this parameter to indicate how frequently (in minutes) InfoSphere CDC will attempt to automatically restart continuous mirroring for persistent subscriptions. InfoSphere CDC will continue in its attempts to restart mirroring at a defined interval until it is either successful, an unrecoverable error occurs or the process is manually stopped. Applies ToSource Default0 minutes
627
Minimum0 minutes Maximum60 minutes

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: events_max_retain global_conversion_not_possible_warning global_shutdown_after_no_heartbeat_response_minutes on page 629 implicit_transformation_warning on page 629
events_max_retain
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse
628
Related concepts System parameters for InfoSphere CDC for DB2 for LUW (version 6.1 and later) on page 627 Setting system parameters on source and target datastores on page 73
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Related concepts System parameters for InfoSphere CDC for DB2 for LUW (version 6.1 and later) on page 627 Setting system parameters on source and target datastores on page 73
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue
629

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: mirror_interim_commit_threshold refresh_commit_after_max_operations
VersionInfoSphere CDC for IBM DB2 UDB version 6.3 Fix Pack 3 and later. By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter. The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations. Applies ToTarget Default Setting0 Minimum Setting0
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later This system parameter identifies the number of rows comprising each transaction during refresh. To reduce the workload on the target database during refresh, InfoSphere CDC periodically commits the changes to the target database rather than performing the refresh as a single large transaction. Applies ToTarget
630
Default Setting1000 Maximum Setting2147483647 Minimum Setting1 Related concepts System parameters for InfoSphere CDC for DB2 for LUW (version 6.1 and later) on page 627 Setting system parameters on source and target datastores on page 73

VersionInfoSphere CDC for DB2 for LUW version 6.1 and later This system parameter indicates the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Set this parameter to one of the following: v trueInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. Setting this system parameter to false ensures that InfoSphere CDC handles non-single-byte character data in the same way as previous InfoSphere CDC releases. Note: Setting this parameter to false does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you may have to apply user exit programs or other customizations to properly represent data in Unicode columns. For more information about user exit programs, see the InfoSphere CDC End-User Documentation for your platform. Applies ToSource Default Settingfalse
631

Some system parameters control memory usage in InfoSphere CDC. For improved performance, if you are able to allocate more than the default value of 512 MB for the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource system parameters to use the increased memory. See also: mirror_global_disk_quota_mb mirror_global_disk_quota_gb staging_store_can_run_independently on page 633 staging_store_disk_quota_gb on page 633 staging_store_disk_quota_mb on page 634
VersionInfoSphere CDC for DB2 for LUW version 6.3 Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions queues staged on the source and LOBs, which are staged on the target (for the record 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting100
VersionInfoSphere CDC for DB2 for LUW version 6.5
632
Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1
VersionInfoSphere CDC for DB2 for LUW version 6.5 Use this system parameter to determine if subscriptions will exclusively use the InfoSphere CDC staging store to accumulate change data or if they will be allowed to use independent log readers and log parsers to receive data directly from the database logs. Set this parameter to one of the following values: v trueSpecifies that subscriptions can use either the staging store to accumulate change data or use independent log readers and log parsers to receive data directly from the database logs. v falseSpecifies that subscriptions will use the InfoSphere CDC staging store to accumulate change data. Changes to this system parameter value will only take effect after the replication engine is restarted. If you change the value from true to false, you will need to clear the staging store before starting replication. Applies ToSource Default Settingtrue
VersionInfoSphere CDC for DB2 for LUW version 6.5
633
Use this system parameter to specify the maximum amount of disk space that will be utilized by the InfoSphere CDC staging store on your source system. If you have enabled the Continuous Capture feature and you are accumulating change data in your staging store when subscriptions are stopped, you should take into consideration the additional disk utilization that this feature requires. Applies ToSource Default Setting100 GB Maximum Setting2147483647 GB Minimum Setting1 GB
staging_store_disk_quota_mb
VersionInfoSphere CDC for DB2 for LUW version 6.1 to version 6.3 Use this system parameter to specify the maximum amount of disk space that will be utilized by the InfoSphere CDC staging store on your source system. If you have enabled the Continuous Capture feature and you are accumulating change data in your staging store when subscriptions are stopped, you should take into consideration the additional disk utilization that this feature requires. Applies ToSource Default Setting2147483647 MB Maximum Setting2147483647 MB Minimum Setting100 MB

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column global_max_batch_size on page 635 mirror_end_on_error on page 635 mirror_expected_errors_list on page 636 refresh_end_on_error on page 636 refresh_expected_errors_list on page 637 refresh_loader_drop_index on page 637 refresh_with_referential_integrity on page 637 userexit_max_lob_size_kb on page 638
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later
634
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter to specify the maximum number of rows that InfoSphere CDC can place in an array and apply to the target database during refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached. You can use this parameter during mirroring only if mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is empty. Before InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then InfoSphere CDC cannot allocate enough memory and will shut down. Management Console references this area to present replication latency information. Applies ToTarget Default Setting25 rows Maximum Setting2147483647 rows Minimum Setting1 row
mirror_end_on_error
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later
635
Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v trueEnd mirroring after an apply error on the target database. v falseDo not end mirroring after an apply error on the target database. Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for DB2 for LUW (version 6.1 and later) on page 627 Setting system parameters on source and target datastores on page 73
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue mirroring when it encounters error codes 4250 and 4452 in your DB2 LUW target database, set this parameter to mirror_expected_errors_list=4250,4452. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter to indicate if you want to end a refresh after an apply error occurs. Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs. Applies ToTarget Default SettingTrue
636
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue refresh when it encounters error codes 4250 and 4452 in your DB2 LUW target database, set this parameter to mirror_expected_errors_list=4250,4452. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later This system parameter indicates whether or not InfoSphere CDC will drop all indexes on the tables being refreshed and then rebuild the indexes after the refresh. In some environments, this may improve refresh performance. If the refresh fails for any reason, InfoSphere CDC for DB2 for LUW provides two commands (dmviewrepairsql and dmrunrepairsql) that allow you to recover and rebuild (or optionally clear) the index. You can also manually recreate all table indexes. Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter to indicate whether or not you want the data removed from all the target tables being refreshed before repopulating any of them. This is most useful when there are referential integrity constraints on the tables being refreshed. Set this parameter to one of the following: v trueIndicates that InfoSphere CDC will first remove all data in reverse of the specified refresh order. When specifying the refresh order, in general parent
637
tables should appear before the referenced child tables. The product will then remove data from the child tables before the parent tables. v falseIndicates that InfoSphere CDC will not first remove all data from your tables and will refresh the tables in the specified order. Applies ToSource Default Settingfalse
VersionInfoSphere CDC for DB2 for LUW version 6.1 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb
638
System parameters for InfoSphere CDC for Teradata (version 6.2 and later)
System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Notes: v If you make changes to a system parameter during active replication, you must stop and restart InfoSphere CDC for the changes to take effect. v When upgrading to a higher version of InfoSphere CDC, any pre-existing settings for system parameters are maintained. In this section, you will learn: Notification system parameters Maximize throughput system parameters on page 641 Encoding system parameters on page 642 Disk resource system parameters on page 643 Apply process system parameters on page 644 Teradata TPump system parameters on page 648 Fastload system parameters on page 651

events_max_retain
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000
639
Minimum Setting -1 Maximum Setting2147483647
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should
640
check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: global_max_batch_size mirror_interim_commit_threshold on page 642
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to specify the maximum number of rows that InfoSphere CDC can place in an array and apply to the target database during mirroring. InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached. You can use this parameter during mirroring only if mirror_end_on_error is true and mirror_expected_errors_list is empty. Before InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then InfoSphere CDC cannot allocate enough memory and will shut down. Management Console references this area to present replication latency information. Applies ToTarget Default Setting25 rows
641
Maximum Setting2147483647 rows Minimum Setting1 row Note: This parameter can only be used if mirror_td_apply_method has been set to JDBC. Related reference mirror_td_apply_method on page 646
VersionInfoSphere CDC for Teradata version 6.3 Fix Pack 3 and later. By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter. The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations. Applies ToTarget Default Setting0 Minimum Setting0

For some system parameters, you can set the default method for treating data in defined Unicode columns, and you can set the default character encoding for your database. See also: mbcs_support_is_on tpump_utf16_support_workaround_is_on on page 643
mbcs_support_is_on
VersionInfoSphere CDC for Teradata version 6.5.1 and later This system parameter is used to enable or disable MBCS support. If the Teradata user default encoding is LATIN, set this parameter to "False". Applies ToTarget
642
Default SettingTrue
tpump_utf16_support_workaround_is_on
VersionInfoSphere CDC for Teradata version 6.5.1 and later Use this system parameter to enable or disable MBCS support. This system parameter should be set to "true" if mbcs_support_is_on is set to "true". If the Teradata user default encoding is LATIN, set this parameter to "false". Applies ToTarget Default Settingtrue

VersionInfoSphere CDC for Teradata version 6.3 Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions queues staged on the source and LOBs, which are staged on the target (for the record 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807
643
Maximum Setting9223372036854775807 Minimum Setting100
VersionInfoSphere CDC for Teradata version 6.5 Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column mirror_end_on_error on page 645 mirror_expected_errors_list on page 645 mirror_td_apply_method on page 646 refresh_end_on_error on page 646 refresh_expected_errors_list on page 647 trim_char_to_varchar on page 647 trim_varchar_to_varchar on page 648 userexit_max_lob_size_kb on page 648
VersionInfoSphere CDC for Teradata version 6.2 and later
644
mirror_end_on_error
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v trueEnd mirroring after an apply error on the target database. v falseDo not end mirroring after an apply error on the target database.
Applies ToTarget Default SettingTrue Note: This parameter can only be used if mirror_td_apply_method has been set to JDBC. Related reference mirror_td_apply_method on page 646
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes.
645
For example, if you want InfoSphere CDC to continue mirroring when it encounters error codes 5407 and 3706 in your Teradata target database, set this parameter to mirror_expected_errors_list=5407,3706. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget Note: You can only use this parameter if mirror_td_apply_method has been set to JDBC. Related reference mirror_td_apply_method refresh_expected_errors_list on page 647
mirror_td_apply_method
VersionInfoSphere CDC for Teradata version 6.2 and later The default configuration InfoSphere CDC for Teradata uses batches of TPump scripts to replicate the mirroring changes to the target Teradata database. In order to realize the full potential of TPump, relatively large time windows must be set for batches, which could result in higher latency. InfoSphere CDC for Teradata can be configured to use JDBC instead of TPump. Use this system parameter to choose the JDBC method for mirroring. The value for this parameter will be applied to all existing and subsequent subscriptions in the instance. Existing subscriptions will need to be restarted for this change to take effect. Notes: v To avoid confusion, use only one type of mirroring method for all subscriptions in a given InfoSphere CDC instance. v Teradata JDBC driver version 13.00.00.06 or later is required for JDBC support. Set this parameter to one of the following: v JDBCEnables mirroring using the JDBC apply method. Use global_max_batch_size to tune or adjust the performance of the JDBC apply method. v TPUMPEnables mirroring using the TPUMP apply method. Default SettingTPUMP Related reference global_max_batch_size on page 641 mirror_expected_errors_list on page 645 refresh_expected_errors_list on page 647 mirror_end_on_error on page 645
VersionInfoSphere CDC for Teradata version 6.2 and later
646
Use this system parameter to indicate if you want to end a refresh after an apply error occurs. Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs. Applies ToTarget Default SettingTrue
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. For example, if you want InfoSphere CDC to continue refresh when it encounters error codes 5407 and 3706 in your Teradata target database, set this parameter to mirror_expected_errors_list=5407,3706. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget Note: You can only use this parameter if mirror_td_apply_method has been set to JDBC. Related reference mirror_td_apply_method on page 646 mirror_expected_errors_list on page 645
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v v trueInfoSphere CDC strips the data of trailing blanks. falseInfoSphere CDC does not strip the string data of trailing blanks.
647
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v v trueInfoSphere CDC strips the data of trailing blanks. falseInfoSphere CDC does not strip the string data of trailing blanks.
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb
Teradata TPump system parameters

Teradata TPump system parameters allow you to configure the Teradata TPump utility. InfoSphere CDC for Teradata uses the TPump utility to load replicated data into Teradata databases. See also: mirror_tpump_files_root_folder_path mirror_tpump_max_file_size_mb on page 649 mirror_tpump_script_val_file_name on page 650 mirror_tpump_timeout_seconds on page 650 mirror_tpump_update_on_key_column on page 651
mirror_tpump_files_root_folder_path
VersionInfoSphere CDC for Teradata version 6.2 and later Identifies the main directory that is created to accommodate all Teradata TPump files. This setting specifies where all Teradata TPump files are located. Subdirectories under the main directory are labeled with the name of the publisher identifier that
648
is used to receive replicated data. This means that for each publisher identifier, Teradata TPump files are maintained in a separate directory. The three subdirectories that are defined are as follows: v <tpump_files_root_folder>\<pubid>\TPump Contains all data (.dat) and script (.script) files that are generated by InfoSphere CDC and used by the Teradata TPump utility to load data into Teradata databases. Data files contain the replicated data that is loaded into Teradata, and script files specify what is contained in the data files and how data is loaded. These files are named DM_<timestamp>.dat and DM_<timestamp>.script, where <timestamp> is the number of milliseconds from midnight on January 1, 1970 to the time when the file was created. v <tpump_files_root_folder>\<pubid>\TPump\archive Contains all archived data (.dat) and script (.script) files. v <tpump_files_root_folder>\<pubid>\TPump\log Contains all Teradata TPump log files. For more information about log files, see tpump_logging below. Log files are named DM_<timestamp>.log, where <timestamp> is the number of milliseconds from midnight on January 1, 1970 to the time when the file was created. where: <tpump_files_root_folder> is the value assigned to this system parameter. <pubid> is the publisher identifier defined in Management Console that is used to receive replicated data. For example, if: <tpump_files_root_folder> is d:\test, and <pubid> is NEWYORK then the following three Teradata TPump subdirectories are created for the NEWYORK publisher identifier: d:\test\NEWYORK\TPump d:\test\NEWYORK\TPump\archive d:\test\NEWYORK\TPump\log
Default SettingThe InfoSphere CDC installation directory. Applies ToTarget
mirror_tpump_max_file_size_mb
VersionInfoSphere CDC for Teradata version 6.2 and later Identifies the size, in megabytes, that the data file (.dat) must reach before the Teradata TPump utility loads data into a Teradata database. Data files contain the replicated data that is loaded into Teradata. To optimize performance, you should set this system parameter so that the amount of time it takes for the Teradata TPump utility to load data into a Teradata database is approximately equivalent to the time it takes for the data file to reach the specified size. As a result, the next load operation can start shortly after the current load operation has been completed. Therefore, if the amount of time to load data is
649
longer than the amount of time to fill the data file in preparation for the next load, decrease the number of bytes assigned to this system parameter. In addition to working with this system parameter, you must also work with the tpump_ timeout on page 626 system parameter to specify when the Teradata TPump utility loads data into a Teradata database. If the timeout period frequently expires before the data file reaches its specified size, you can increase the timeout period or decrease the data file size to allow loads to also be determined by data file size. However, when a data file contains an insufficient amount of data for a load to be performed, the timeout period must be set to ensure data is loaded within a reasonable period of time. Default Setting50 Mb
mirror_tpump_script_val_file_name
VersionInfoSphere CDC for Teradata version 6.2 and later Identifies the name of the XML file that InfoSphere CDC uses to generate script (.script) files during replication. Teradata TPump script files specify what is contained in the data files and how data in these files is loaded into Teradata databases. The file identified by this system parameter contains a set of Teradata TPump command parameter settings. You can modify the settings in this file so that the script files generated by InfoSphere CDC during replication are customized for your working environment. For more information about customizing the generated script files using the XML file identified by this system parameter, see your InfoSphere CDC for Teradata documentation. Do not change the default setting for this system parameter. Instead, modify the tpumpscripttsdefaults.xml file so that it contains the desired command parameter settings. If you want to specify a different XML, this file must exist in the InfoSphere CDC installation directory and contain the correct XML markup to generate valid script files. Generally, the default values in the tpumpscripttsdefaults.xml file are suitable for most working environments. If you want to modify the settings in tpumpscripttsdefaults.xml, you must be familiar with XML and Teradata TPump. For more information about Teradata TPump commands and command parameters, see your Teradata documentation. Default Settingconf/tpumpscripttsdefaults.xml. This file is located in the conf directory in your InfoSphere CDC installation directory.
mirror_tpump_timeout_seconds
VersionInfoSphere CDC for Teradata version 6.2 and later Indicates the amount of time, in seconds, between consecutive Teradata TPump data loads into a Teradata database. You can use this system parameter to force data to be loaded when the data file (see tpump_max_file_size on page 624) contains insufficient data for a load to be performed. It can be used to prevent data in a data file from not being loaded for a
650
long period of time. In particular, you can use this system parameter to force loads during periods of slow transaction activity. However, if you set the timeout period so that it frequently expires before a data file can reach the specified size, a smaller amount of data is loaded. In this case, you can increase the timeout period or decrease the data file size to allow loads to also be determined by data file size. Minimum Setting0 seconds (disables the timeout so that a load is only performed when the data file reaches the size specified by the tpump_max_file_size system parameter) Default Setting5 seconds
mirror_tpump_update_on_key_column
VersionInfoSphere CDC for Teradata version 6.2 and later Use this system parameter to improve performance in the TPump apply process by not including key columns in the update statements in the TPump scripts. This parameter should only be used when you are sure that no key changes will occur in the source data stream. Set this parameter to one of the following: v trueIncludes key columns in the update statements in TPump scripts. v falseExcludes key columns from the update statements in TPump scripts. Default Settingtrue
Fastload system parameters

Fastload system parameters allow you to configure the Teradata Fastload utility. InfoSphere CDC for Teradata uses the Fastload utility to load replicated data into Teradata databases. See also: refresh_allow_fast_loader refresh_max_fastload_file_size_mb on page 652 use_jdbc_for_refresh on page 652
refresh_allow_fast_loader
VersionInfoSphere CDC for Teradata version 6.5.1 and later This system parameter is used to enable or disable the use of Teradata FastLoad for refresh. If set to "true", Teradata FastLoad will be used for refresh. If set to "false", JDBC apply will be used for refresh. Applies ToTarget Default Settingtrue
651
refresh_max_fastload_file_size_mb
VersionInfoSphere CDC for Teradata version 6.2 and later Identifies the size, in megabytes, that the data file must reach before the Teradata FastLoad utility refreshes data in a Teradata database. If the amount of refreshed data is larger than the specified size, InfoSphere CDC closes the data file after it has been filled and passes it to the Teradata FastLoad utility so that data is refreshed in the Teradata database. Additional data files are used to ensure the remaining data is refreshed. Default Setting100 mb Maximum9223372036854775807 (or 263 - 1) mb Minimum1 mb
use_jdbc_for_refresh
VersionInfoSphere CDC for Teradata version 6.5.1 and later This system parameter is used to enable or disable the use of JDBC apply method for refresh. If set to "true", JDBC apply will be used for refresh. Applies ToTarget Default Settingfalse
652
System parameters for InfoSphere CDC Event Server

System parameters let you control the behavior of InfoSphere CDC Event Server. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC Event Server. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC Event Server. InfoSphere CDC Event Server provides system parameters that control the behavior of your target datastores. If you make changes to a system parameter during active replication, you must stop and restart InfoSphere CDC Event Server for the changes to take effect. When upgrading to a higher version of InfoSphere CDC Event Server, any pre-existing settings for system parameters are maintained. In this section, you will learn: Notification system parameters Apply process system parameters on page 654 Disk resource system parameters on page 658

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: events_max_retain global_conversion_not_possible_warning implicit_transformation_warning on page 654
events_max_retain
VersionInfoSphere CDC Event Server version 6.3 and later Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647
VersionInfoSphere CDC Event Server version 6.3 and later
653
Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse Related concepts System parameters for InfoSphere CDC Event Server on page 653
VersionInfoSphere CDC Event Server version 6.3 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column on page 655
654
mirror_commit_on_transaction_boundary mirror_end_on_error on page 656 mirror_expected_errors_list on page 656 mirror_interim_commit_threshold on page 656 refresh_end_on_error on page 657 refresh_expected_errors_list on page 657 userexit_max_lob_size_kb on page 657
VersionInfoSphere CDC Event Server version 6.3 and later Use this system parameter to control how InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and InfoSphere CDC will generate a warning in the event log. When set to false, InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of InfoSphere CDC on the target database. Note: If you decided to set this system parameter to false and have specified this as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list system parameter, then InfoSphere CDC will ignore the error and not shutdown. Set this parameter to one of the following: v trueNull value will be replaced with default value for non-nullable column, and a warning event will be logged. v falseNull data will be applied as-is to non-nullable column and database will usually return an error code. Applies ToSource and Target Default SettingTrue
mirror_commit_on_transaction_boundary
VersionInfoSphere CDC Event Server version 6.3 and later This system parameter indicates whether or not the commits that InfoSphere CDC does on the target will always correspond with a commit that occurred on the source database. If you choose to ignore the commitment control of the source database, InfoSphere CDC allows you to see the partial results of large transactions. Set this parameter to one of the following: v trueDoes not ignore the commitment control of the source database. Only records in a committed transaction are mirrored to the target. This setting provides true transaction consistency by ensuring that only committed transactions are sent to the target. v falseIgnores the commitment control of the source database. This value disables commitment control for transaction processing. No attempt to maintain transaction consistency is performed during mirroring.
655
Applies ToTarget Default SettingFalse
mirror_end_on_error
VersionInfoSphere CDC Event Server version 6.3 and later Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v v trueEnd mirroring after an apply error on the target database. falseDo not end mirroring after an apply error on the target database.
VersionInfoSphere CDC Event Server version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC for Event Server version 6.3 Fix Pack 3 and later. By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter. The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations.
656
Applies ToTarget Default Setting0 Minimum Setting0
VersionInfoSphere CDC Event Server version 6.3 and later Use this system parameter to indicate if you want to end a refresh after an apply error occurs. Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs. Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC Event Server on page 653 Setting system parameters on source and target datastores on page 73
VersionInfoSphere CDC Event Server version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC Event Server version 6.3 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb
657

Some system parameters control memory usage in InfoSphere CDC. For improved performance, if you are able to allocate more than the default value of 512 MB for the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource system parameters to use the increased memory. See also: mirror_global_disk_quota_mb mirror_global_disk_quota_gb
VersionInfoSphere CDC Event Server version 6.3 Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions queues staged on the source and LOBs, which are staged on the target (for the record 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting100
VersionInfoSphere CDC Event Server version 6.5 Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter to store in scope change data that has not been committed in your database. Once the database transaction is
658
committed, the disk space used by the transaction is released. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1
659
660
System parameters for InfoSphere CDC for InfoSphere DataStage

System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Notes: 1. If you make changes to a system parameter during active replication, you must stop and restart InfoSphere CDC for the changes to take effect. 2. When upgrading to a later version of InfoSphere CDC, any preexisting settings for system parameters are maintained. In this section, you will learn: Notification system parameters Disk resource system parameters on page 663 Apply process system parameters on page 665 InfoSphere DataStage system parameters on page 668

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: ds_output_timestamp_utc events_max_retain on page 662 global_conversion_not_possible_warning on page 662 global_shutdown_after_no_heartbeat_response_minutes on page 662 implicit_transformation_warning on page 663
ds_output_timestamp_utc
VersionInfoSphere CDC for InfoSphere DataStage version 6.5 Use this system parameter to specify if you want the DM_TIMESTAMP column to be updated with the UTC timestamp (by default, this is the GMT time zone) or to be updated with the local time zone. Set this parameter to one of the following: v trueThe DM_TIMESTAMP column is updated with the timestamp using the GMT time zone (UTC time).
661
falseThe DM_TIMESTAMP column is updated with the timestamp using the local time zone.
events_max_retain
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse Related concepts System parameters for InfoSphere CDC for InfoSphere DataStage on page 661
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource
662
Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes Related concepts System parameters for InfoSphere CDC for InfoSphere DataStage on page 661
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue

VersionInfoSphere CDC for InfoSphere DataStage version 6.3 Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions
663
queues staged on the source and LOBs, which are staged on the target (for the record 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting100
VersionInfoSphere CDC for InfoSphere DataStage version 6.5 Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1
664

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column mirror_end_on_error mirror_expected_errors_list on page 666 mirror_interim_commit_threshold on page 666 refresh_end_on_error on page 666 refresh_expected_errors_list on page 667 refresh_with_referential_integrity on page 667 trim_char_to_varchar on page 667 trim_varchar_to_varchar on page 668
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to control how InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and InfoSphere CDC will generate a warning in the event log. When set to false, InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of InfoSphere CDC on the target database. Note: If you decided to set this system parameter to false and have specified this as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list system parameter, then InfoSphere CDC will ignore the error and not shutdown. Set this parameter to one of the following: v trueNull value will be replaced with default value for non-nullable column, and a warning event will be logged. v falseNull data will be applied as-is to non-nullable column and database will usually return an error code. Applies ToSource and Target Default SettingTrue
mirror_end_on_error
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v trueEnd mirroring after an apply error on the target database. v falseDo not end mirroring after an apply error on the target database.
665
Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for InfoSphere DataStage on page 661
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC for IBM InfoSphere DataStage version 6.3 Fix Pack 3 and later. By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter. The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations. Applies ToTarget Default Setting0 Minimum Setting0
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to indicate if you want to end a refresh after an apply error occurs.
666
Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs. Applies ToTarget Default SettingTrue Related concepts System parameters for InfoSphere CDC for InfoSphere DataStage on page 661
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to indicate whether or not you want the data removed from all the target tables being refreshed before repopulating any of them. This is most useful when there are referential integrity constraints on the tables being refreshed. Set this parameter to one of the following: v trueIndicates that InfoSphere CDC will first remove all data in reverse of the specified refresh order. When specifying the refresh order, in general parent tables should appear before the referenced child tables. The product will then remove data from the child tables before the parent tables. v falseIndicates that InfoSphere CDC will not first remove all data from your tables and will refresh the tables in the specified order. Applies ToSource Default Settingfalse
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table.
667
Set this parameter to one of the following: v trueInfoSphere CDC strips the data of trailing blanks. v falseInfoSphere CDC does not strip the string data of trailing blanks. Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v trueInfoSphere CDC strips the data of trailing blanks. v falseInfoSphere CDC does not strip the string data of trailing blanks. Applies ToTarget Default Settingfalse
InfoSphere DataStage system parameters

InfoSphere DataStage system parameters when your LOB data is truncated. See also: userexit_max_lob_size_kb
VersionInfoSphere CDC for InfoSphere DataStage version 6.3 and later. This system parameter determines when InfoSphere CDC truncates LOB data and is related to the InfoSphere DataStage subscription-level properties that you can set for each subscription in Management Console. InfoSphere CDC first truncates your LOB data based on this system parameter and then truncates your data again using the subscription-level properties. For more information on how to set the subscription-level properties, see Setting properties for a subscription that targets InfoSphere DataStage on page 155. This system parameter should be set at least as large as the largest subscription-level property while taking into account the units and the type of character data (single-byte or multibyte). For example, if the largest subscription-level property is set to 8,000 characters and you are using a Japanese system with the possibility of 2 bytes per character (up to 16,000 bytes), you should set this system parameter to at least 16 kB. Default Setting128 kB Applies ToTarget
668
System parameters for InfoSphere CDC for Informix

System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Notes: 1. If you make changes to a system parameter during active replication, you must stop and restart InfoSphere CDC for the changes to take effect. 2. When upgrading to a later version of InfoSphere CDC, any preexisting settings for system parameters are maintained. In this section, you will learn: General product system parameters Notification system parameters on page 670 Maximize throughput system parameters on page 671 Encoding system parameters on page 672 Disk resource system parameters on page 673 Apply process system parameters on page 675

VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 Fix Pack 3 TFE 9 and later. Use this parameter to indicate how frequently (in minutes) InfoSphere CDC will attempt to automatically restart continuous mirroring for persistent subscriptions. InfoSphere CDC will continue in its attempts to restart mirroring at a defined interval until it is either successful, an unrecoverable error occurs or the process is manually stopped. Applies ToSource Default0 minutes Minimum0 minutes
669
Maximum60 minutes

Notification system parameters let you control if you should generate InfoSphere CDC messages in the Event Log for specific events. See also: events_max_retain global_conversion_not_possible_warning global_shutdown_after_no_heartbeat_response_minutes implicit_transformation_warning on page 671
events_max_retain
VersionInfoSphere CDC for Informix version 6.5 Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for Informix version 6.3 and later
670
Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true. Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: mirror_interim_commit_threshold on page 672
671
VersionInfoSphere CDC for IBM Informix Dynamic Server version 6.3 Fix Pack 3 and later. By default, InfoSphere CDC guarantees transactional delivery of change data to the target. This ensures that if any data from a source transaction is committed to the target, then all other in scope operations from that source transaction are committed as well. In cases where large transactions are done on the source system, it can be more efficient to break a large transaction into smaller transactions when applying data to the target. You can configure this behavior using this system parameter. The default value of 0 for this system parameter indicates that the product guarantees transactional delivery of change data to the target. A value greater than 0 indicates that you want InfoSphere CDC to break up large transactions into smaller transactions. For example, a value of 2000 indicates that InfoSphere CDC will split up large source transactions so that each transaction committed to the target database contains no more than 2000 operations. Applies ToTarget Default Setting0 Minimum Setting0
VersionInfoSphere CDC for Informix version 6.3 and later This system parameter identifies the number of rows comprising each transaction during refresh. To reduce the workload on the target database during refresh, InfoSphere CDC periodically commits the changes to the target database rather than performing the refresh as a single large transaction. Applies ToTarget Default Setting1000 Maximum Setting2147483647 Minimum Setting1

For some system parameters, you can set the default method for treating data in defined Unicode columns, and you can set the default character encoding for your database. See also: global_unicode_as_char on page 673
672
VersionInfoSphere CDC for Informix version 6.3 and later This system parameter indicates the default method of treating data in defined Unicode columns. For each InfoSphere CDC installation on a server, this system parameter defines the system default method of treating data in Unicode columns. If a Unicode column is set to System Default on the Encoding tab of the Mapping Details view in Management Console, InfoSphere CDC uses the method for processing Unicode columns that you select in this system parameter. Set this parameter to one of the following: v trueInfoSphere CDC treats all data in Unicode columns as single-byte characters. Use this setting when Unicode columns contain single-byte character data. v falseInfoSphere CDC treats all data in Unicode columns as a continuous bit stream. Use this setting when Unicode columns contain non-single-byte character data. Setting this system parameter to false ensures that InfoSphere CDC handles non-single-byte character data in the same way as previous InfoSphere CDC releases. Note: Setting this parameter to false does not ensure that replicated non-single-byte character data in Unicode columns are represented properly on the target. For replicated non-single-byte character data, you may have to apply user exit programs or other customizations to properly represent data in Unicode columns. For more information about user exit programs, see the InfoSphere CDC End-User Documentation for your platform. Applies ToSource Default Settingfalse For information about how data in each Unicode source column is treated and setting multibyte and Unicode character set conversions, see Replicating multibyte (MBCS) and double-byte (DBCS) character data on page 187.

VersionInfoSphere CDC for Informix version 6.3
673
Use this system parameter to globally set a disk quota (in MB) for all capture components. Capture components include the temporary files and transactions queues staged on the source and LOBs, which are staged on the target (for the record 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting100
VersionInfoSphere CDC for Informix version 6.5 Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1
674
VersionInfoSphere CDC for Informix version 6.5 Use this system parameter to determine if subscriptions will exclusively use the InfoSphere CDC staging store to accumulate change data or if they will be allowed to use independent log readers and log parsers to receive data directly from the database logs. Set this parameter to one of the following values: v trueSpecifies that subscriptions can use either the staging store to accumulate change data or use independent log readers and log parsers to receive data directly from the database logs. v falseSpecifies that subscriptions will use the InfoSphere CDC staging store to accumulate change data. Changes to this system parameter value will only take effect after the replication engine is restarted. If you change the value from true to false, you will need to clear the staging store before starting replication. Applies ToSource Default Settingtrue
VersionInfoSphere CDC for Informix version 6.5 Use this system parameter to specify the maximum amount of disk space that will be utilized by the InfoSphere CDC staging store on your source system. If you have enabled the Continuous Capture feature and you are accumulating change data in your staging store when subscriptions are stopped, you should take into consideration the additional disk utilization that this feature requires. Applies ToSource Default Setting100 GB Maximum Setting2147483647 GB Minimum Setting1 GB

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column on page 676 global_max_batch_size on page 676 mirror_end_on_error on page 677
675
mirror_expected_errors_list on page 677 refresh_end_on_error on page 677 refresh_expected_errors_list on page 678 refresh_with_referential_integrity on page 678 trim_char_to_varchar on page 678 trim_varchar_to_varchar on page 678 userexit_max_lob_size_kb on page 679
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter to control how InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and InfoSphere CDC will generate a warning in the event log. When set to false, InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of InfoSphere CDC on the target database. Note: If you decided to set this system parameter to false and have specified this as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list system parameter, then InfoSphere CDC will ignore the error and not shutdown. Set this parameter to one of the following: v trueNull value will be replaced with default value for non-nullable column, and a warning event will be logged. v falseNull data will be applied as-is to non-nullable column and database will usually return an error code. Applies ToSource and Target Default SettingTrue
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter to specify the maximum number of rows that InfoSphere CDC can place in an array and apply to the target database during refresh or mirroring. InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached. You can use this parameter during mirroring only if mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is empty. Before InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then InfoSphere CDC cannot allocate enough memory and will shut down. Management Console references this area to present replication latency information.
676
Applies ToTarget Default Setting25 rows Maximum Setting2147483647 rows Minimum Setting1 row
mirror_end_on_error
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database. Set this parameter to one of the following: v trueEnd mirroring after an apply error on the target database. v falseDo not end mirroring after an apply error on the target database. Applies ToTarget Default SettingTrue
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when applying data changes to the target during mirroring. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter to indicate if you want to end a refresh after an apply error occurs. Set this parameter to one of the following: v trueEnd a refresh after an apply error occurs. v falseDo not end a refresh after an apply error occurs. Applies ToTarget Default SettingTrue
677
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter when you want InfoSphere CDC to ignore one or more database errors when refreshing data to the target. The error specified must correspond to the integer error code (database-vendor specific) returned by the SQLException class in JDBC (Java Database Connectivity). Specify multiple errors with a comma separated list of integer error codes. Note: Latency may increase when using this system parameter since InfoSphere CDC will not use JDBC array apply in order to track the errors specified. Applies ToTarget
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter to indicate whether or not you want the data removed from all the target tables being refreshed before repopulating any of them. This is most useful when there are referential integrity constraints on the tables being refreshed. Set this parameter to one of the following: v trueIndicates that InfoSphere CDC will first remove all data in reverse of the specified refresh order. When specifying the refresh order, in general parent tables should appear before the referenced child tables. The product will then remove data from the child tables before the parent tables. v falseIndicates that InfoSphere CDC will not first remove all data from your tables and will refresh the tables in the specified order.
Applies ToSource Default Settingfalse
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v trueInfoSphere CDC strips the data of trailing blanks. v falseInfoSphere CDC does not strip the string data of trailing blanks. Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for Informix version 6.3 and later
678
Use this system parameter to specify whether or not InfoSphere CDC should strip or leave trailing blanks on string data of the column in the target table. Set this parameter to one of the following: v trueInfoSphere CDC strips the data of trailing blanks. v falseInfoSphere CDC does not strip the string data of trailing blanks. Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for Informix version 6.3 and later Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb
679
680
System parameters for InfoSphere CDC for Netezza databases

System parameters let you control the behavior of InfoSphere CDC. If your replication environment requires a particular configuration, then you can use system parameters to modify the behavior of default operations in InfoSphere CDC. The default system parameter settings are appropriate for most installations. Maintain these default settings until you become familiar with the configuration of InfoSphere CDC. InfoSphere CDC provides system parameters that control the behavior of your source and target datastores. Notes: 1. If you make changes to a system parameter during active replication, you must stop and restart InfoSphere CDC for the changes to take effect. 2. When upgrading to a later version of InfoSphere CDC, any preexisting settings for system parameters are maintained. In this section, you will learn: Notification system parameters Maximize throughput system parameters on page 683 Disk resource system parameters on page 683 Apply process system parameters on page 684

events_max_retain
VersionInfoSphere CDC for Netezza databases version 6.5.2 Use this system parameter to control the maximum number of events that InfoSphere CDC will store in the event log. If InfoSphere CDC generates more events than the specified maximum, then the earliest events will be deleted. Default Setting10000 Minimum Setting -1 Maximum Setting2147483647
681
VersionInfoSphere CDC for Netezza databases version 6.5.2 Use this system parameter to control whether or not InfoSphere CDC generates a warning in the Management Console Event Log in the following situations: v Data conversion is not possible for a specific data value. v Converted data types are encountered that are out of range. Set this parameter to one of the following: v trueGenerates a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. v falseDoes not generate a warning in the Event Log if data conversion is not possible for a specific data value or converted data types are encountered that are out of range. Applies ToTarget Default Settingfalse
VersionInfoSphere CDC for Netezza databases version 6.5.2 Use this system parameter to specify the duration, in minutes, of communication inactivity before active InfoSphere CDC processes for a subscription are stopped. If a value outside the acceptable range is specified, the default setting is used. Applies ToSource Default Setting15 minutes Minimum Setting3 minutes Maximum Setting999 minutes
VersionInfoSphere CDC for Netezza databases version 6.5.2 Use this system parameter when you want InfoSphere CDC to generate a warning message in the Event Log to identify possible problems with data transformations on the target table. When this system parameter is enabled, data transformations that meet the criteria for warnings are logged to the Event Log. For example, InfoSphere CDC will generate a warning if it had to truncate data in a column with variable length encoding in order to fit it into the target column. Each time you restart InfoSphere CDC, InfoSphere CDC will generate one warning for each column in a table even if the conversions may be different each time. You should check the Event Log for new warnings related to data conversion to ensure data consistency between your source and target tables. Note: This system parameter applies only when the convert_not_nullable_column parameter has been set to true.
682
Set this parameter to one of the following: v trueGenerates a warning message in the Event Log the first time an issue is detected on a per column per table basis. v falseNo warning message is generated in the Event Log. Applies ToTarget Default SettingTrue

InfoSphere CDC system parameters allow you to significantly reduce the workload of the target database during mirroring. The InfoSphere CDC apply process groups transactions on the target to reduce the workload. Every commit on the target database will correspond with a commit on the target. However, it may not perform every commit that was done on the source. For example, if the source does three small transactions containing one operation each, the target may commit all three operations as part of a single transaction. You can use this grouping of system parameters to significantly reduce the resources required by the target database. The default settings are appropriate for most databases, but if your target system has limited resources and an increase in latency is acceptable, you can adjust the settings appropriately. See also: acceptable_latency_in_minutes
acceptable_latency_in_minutes
VersionInfoSphere CDC for Netezza databases version 6.5.2 Use this system parameter to indicate the maximum latency that would be acceptable in your business environment. InfoSphere CDC temporarily buffers data during replication in order to minimize its workload on the Netezza database. This buffering can increase latency. If the latency reaches the point indicated by this system parameter InfoSphere CDC will stop buffering the data. It is primarily the number of tables being replicated that impacts the additional workload that will occur when InfoSphere CDC stops buffering the data. Increasing this parameter may significantly reduce the workload from InfoSphere CDC when you are replicating a large number of tables. Applies ToTarget Default Setting5 minutes Maximum Setting1440 minutes Minimum Setting1 minute

Some system parameters control memory usage in InfoSphere CDC. For improved performance, if you are able to allocate more than the default value of 512 MB for the InfoSphere CDC Java Virtual Machine, then you can adjust the disk resource system parameters to use the increased memory.
683
See also: mirror_global_disk_quota_gb
VersionInfoSphere CDC for Netezza databases version 6.5.2 Use this system parameter to globally set a disk quota (in GB) 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 the disk quota controlled by this system parameter 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. Note that InfoSphere CDC stores the data in memory to improve performance and will only persist the data to disk if memory is unavailable. The default setting of this system parameter is such that the product will only stop replicating after this disk quota exhausts all available disk space on your system. If you would prefer the product to stop replicating after it uses a specific amount of disk space, you can set the value with this system parameter. Applies ToSource and Target Default Setting9223372036854775807 Maximum Setting9223372036854775807 Minimum Setting1

Some system parameters adjust the way InfoSphere CDC applies rows, column data, and error handling. See also: convert_not_nullable_column userexit_max_lob_size_kb on page 685
VersionInfoSphere CDC for Netezza databases version 6.5.2 Use this system parameter to control how InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and InfoSphere CDC will generate a warning in the event log. When set to false, InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of InfoSphere CDC on the target database.
684
Note: If you decided to set this system parameter to false and have specified this as an error for InfoSphere CDC to ignore using the mirror_expected_errors_list system parameter, then InfoSphere CDC will ignore the error and not shutdown. Set this parameter to one of the following: v trueNull value will be replaced with default value for non-nullable column, and a warning event will be logged. v falseNull data will be applied as-is to non-nullable column and database will usually return an error code. Applies ToSource and Target Default SettingTrue
VersionInfoSphere CDC for Netezza databases version 6.5.2 Use this system parameter to set the maximum size of LOB data (in kb) that InfoSphere CDC can pass to a user exit. Applies ToTarget Default Setting128 kb Maximum Setting9223372036854775807 kb Minimum Setting1 kb
685
686
Commands for Access Server

Access Server provides a set of commands that let you manage datastores and user accounts from a Windows, UNIX, or Linux command prompt. Note the following about the commands: v You can run the commands from the bin directory in your Access Server installation directory. v Use the -? flag to display help information. For example, dmcreateuser -? In this section, you will learn: Datastore commands User account commands on page 691 Other commands on page 698
Datastore commands
This section contains commands that help you create and manage your datastores. See also: dmchangeconnectionpasswordChanging the connection parameters to a datastore dmcreatedatastoreAdding a datastore on page 688 dmdeleteconnectionDeleting a datastore connection on page 689 dmdeletedatastoreDeleting a datastore on page 690 dmlistuserdatastoresGenerating a report list of datastores assigned to a user on page 690
dmchangeconnectionpasswordChanging the connection parameters to a datastore

Use this command to change connection parameters to a datastore for a user account. When changing a connection for a user, you must identify the name and password of the database you want users to use for replication. This database resides on the same server as your InfoSphere CDC installation. When the user establishes a connection to the datastore, they are in fact connecting to this database.
Syntax
DMCHANGECONNECTIONPASSWORD userName datastoreName database databaseOwner databasePassword [-accessserver hostname port adminuser adminpassword]
Parameters
userName Specifies the name of the user for which you want to create a connection. datastoreName Specifies the name of the datastore you want the user to connect to.
687
database Specifies the name of the database that you want users to replicate to or from. Not all datastore connections are to a database. Use "" if not required. databaseOwner Specifies the user name of the database. Not all datastore connections are to a database. Use "" if not required. databasePassword Specifies the password to log into the database. Not all datastore connections are to a database. Use "" if not required. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
dmcreatedatastoreAdding a datastore
Use this command to add a new datastore. Adding a datastore in Management Console means that you are in the process of making an installation of InfoSphere CDC and the database you want users to replicate to or from available for connection by other users. When adding a datastore, you must specify information about where your installation of InfoSphere CDC resides.
Syntax
DMCREATEDATASTORE datastoreName description hostname port [-accessserver hostname port adminuser adminpassword]
Parameters
datastoreName Specifies the name of the datastore you want to add. description Specifies a brief description about this datastore. hostname Specifies the hostname of the server where you have installed InfoSphere CDC. port Specifies the port numbe r of the server where you have installed InfoSphere CDC.
688
-accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
dmdeleteconnectionDeleting a datastore connection

Use this command to delete an existing connection between a datastore and a user.
Syntax
DMDELETECONNECTION userName datastoreName [-accessserver hostname port adminuser adminpassword]
Parameters
username Specifies the unique name of the user you want to delete the connection for. datastoreName Specifies the name of the datastore you want to delete the connection for. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command).
689
adminpassword The password for the specified SYSADMIN user.
dmdeletedatastoreDeleting a datastore
Use this command to delete a datastore.
Syntax
DMDELETEDATASTORE datastoreName [-accessserver hostname port adminuser adminpassword]
Parameters
datastoreName Specifies the name of the datastore you want to delete. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
dmlistuserdatastoresGenerating a report list of datastores assigned to a user

Use this command to generate a list of datastores assigned to a specific user.
Syntax
DMLISTUSERDATASTORES username [-accessserver hostname port adminuser adminpassword]
Parameters
username Specifies the name of the user you want to generate a list for. This list specifies the datastores assigned to this user. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this
690
command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
User account commands

This section contains commands that help you create and manage your user accounts. See also: dmchangeuserpasswordChanging the password on a user account dmcreateuserAdding a user account on page 692 dmdeleteuserDeleting a user on page 694 dmdisableuserDisabling a user account on page 694 dmenableuserEnabling a user on page 695 dmlistusersListing user accounts on page 695 dmresetuserResetting a user account on page 697 dmunlockuserUnlocking a user account on page 698
dmchangeuserpasswordChanging the password on a user account

Use this command to change the password on a user account that you had created. This user will require the password in order to log into Management Console. To change passwords, you must be a System Administrator and have the privilege to manage datastores and user accounts.
Syntax
DMCHANGEUSERPASSWORD username password [-accessserver hostname port adminuser adminpassword]
Parameters
userName Specifies the name of the user that you are changing the password for. password Specifies the password you want the user to supply when logging into Management Console. If you have enabled complex passwords, then you must specify a password that meets the requirements. -accessserver hostname port adminuser adminpassword
691
The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
dmcreateuserAdding a user account

Use this command to add a new user. Adding a user account is necessary to provide users with the ability to log in to Management Console.
Syntax
DMCREATEUSER username fullname description password role manager changePassword passwordNeverExpires [-accessserver hostname port adminuser adminpassword]
Parameters
username Specifies the unique name for the user you want to create an account for. fullname Specifies the full name of the user. description Specifies a description about the user. password Specifies the password you want the user to supply when logging into Management Console. If you have enabled complex passwords, then you must specify a password that meets the requirements. role Specifies the role you want to assign to the user. Enable one of the following values: v SYSADMINSpecifies that a user assigned to this role is working in a System Administrator account and can perform all available operations in Management Console. Only users that require full operational access to the Monitoring and Configuration perspectives should be assigned to this role. System Administrators can also modify system parameters to calibrate their replication environment. v ADMINSpecifies that a user assigned to this role is working in an Administrator account and can perform all available operations in Management Console, but cannot modify system parameters. Users assigned to this role can access both the Monitoring and Configuration perspectives.
692
v OPERATORSpecifies a that user assigned to this role is working in an Operator account and has access to both the Monitoring and Configuration perspectives. Operators can add, import and export projects, but they cannot create new subscriptions. Users assigned to the Operator role can start, stop, and monitor replication activities. They can also view the tables selected for refresh and start a refresh on a subscription. Operators can view notifications sent by subscriptions or datastores. However, users assigned to this role cannot configure replication and select or remove tables from a refresh. v MONITORSpecifies that a user assigned to this role is working in a Monitoring account and only has access to the Monitoring perspective in Management Console. Users assigned to the Monitor role can view the event log, view statistics, and view table mappings. Monitors can view the replication state and status of a subscription and can view latency threshold information. However, users assigned to this role cannot start or stop replication, configure replication, refresh tables, or view notifications sent by subscriptions and datastores. manager Specifies that a user assigned the role of SYSADMIN also has privileges to manage datastores and user accounts in the Access Manager perspective of Management Console. If you want to enable this privilege for a System Administrator, then specify a value of TRUE. Otherwise, specify a value FALSE. Note: You must enable this privilege with a value of TRUE if you are creating a user account for the UNIX or Linux platforms that will allow you to log in to Management Console for the first time after the installation. changePassword Specifies you want the user to change their password when logging into Management Console for the first time. If you want the user to change the password, specify a value of TRUE. Otherwise, if you want the user to login using the same password you have assigned to them, then specify a value of FALSE. passwordNeverExpires Specifies that you want to override any existing password expiry policies set in Management Console so that the password never expires. If you want to override an existing password expiry policy, specify a value of TRUE. Otherwise, if you want the password to expire, then specify a value of FALSE. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. -accessserver Specify -accessserver. This parameter indicates that you want to connect to a remote installation of Access Server. hostname The fully qualified host name of the remote system where Access Server is installed.
693
adminuser A user with system administrator (SYSADMIN) privileges (see the role parameter above) and the ability to manage users and datastores (see the manager parameter above). adminpassword The password for the specified SYSADMIN user.
dmdeleteuserDeleting a user
Use this command to delete a user.
Syntax
DMDELETEUSER username [-accessserver hostname port adminuser adminpassword]
Parameters
username Specifies the name of the user you want to delete. accessserver hostname port adminuser adminpassword These parameters are optional. Specifies that you want to connect to a remote installation of Access Server. If you have installed Access Server on the same machine as Management Console, then these parameters are not required.
dmdisableuserDisabling a user account

Use this command to disable a user account. This prevents the user from logging into Management Console.
Syntax
DMDISABLEUSER username [-accessserver hostname port adminuser adminpassword]
Parameters
username Specifies the name of the user you want to disable. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command).
694
adminpassword The password for the specified SYSADMIN user.
dmenableuserEnabling a user
Use this command to enable a user account. This lets the user log into Management Console.
Syntax
DMENABLEUSER username [-accessserver hostname port adminuser adminpassword]
Parameters
username Specifies the name of the user you want to enable. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
dmlistusersListing user accounts

Use this command to generate a list of users and properties on the account.
Syntax
DMLISTUSERS [-accessserver hostname port adminuser adminpassword]
Parameters
-accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command.
695
hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
Output
User Specifies the name of the user. Role Specifies the role assigned to the user. v SYSADMINSpecifies that a user assigned to this role is working in a System Administrator account and can perform all available operations in Management Console. Only users that require full operational access to the Monitoring and Configuration perspectives should be assigned to this role. System Administrators can also modify system parameters to calibrate their replication environment. v ADMINSpecifies that a user assigned to this role is working in an Administrator account and can perform all available operations in Management Console, but cannot modify system parameters. Users assigned to this role can access both the Monitoring and Configuration perspectives. v OPERATORSpecifies a that user assigned to this role is working in an Operator account and has access to both the Monitoring and Configuration perspectives. Operators can add, import and export projects, but they cannot create new subscriptions. Users assigned to the Operator role can start, stop, and monitor replication activities. They can also view the tables selected for refresh and start a refresh on a subscription. Operators can view notifications sent by subscriptions or datastores. However, users assigned to this role cannot configure replication and select or remove tables from a refresh. v MONITORSpecifies that a user assigned to this role is working in a Monitoring account and only has access to the Monitoring perspective in Management Console. Users assigned to the Monitor role can view the event log, view statistics, and view table mappings. Monitors can view the replication state and status of a subscription and can view latency threshold information. However, users assigned to this role cannot start or stop replication, configure replication, refresh tables, or view notifications sent by subscriptions and datastores. Manager Specifies if the user assigned to the role of System Administrator has also been assigned privileges to manage datastores and user accounts. TRUE indicates that the System Administrator has been given these privileges. FALSE indicates that the System Administrator has not been given these privileges. Disabled Specifies if the account has been disabled. TRUE indicates that the account is disabled. FALSE indicates the account is enabled.
696
Locked Specifies if the account has been locked. This is automatically set to TRUE if the number of failed login attempts exceeds the locking policy you may have set. PwdChange Specifies if the user is required to change their password the next time the user logs into Management Console. TRUE indicates the user is required to change the password. FALSE indicates the user can use the same password assigned to them. Expires Specifies if the user account overrides any existing password expiry policy set in Management Console. TRUE indicates the password supplied will not expire and overrides any expiry policy. FALSE indicates the password does expire based on an expiry policy.
dmresetuserResetting a user account

Use this command to reset a user account. When you reset a user account, the following properties are returned to their defaults: v v v v v the the the the the password is set to an empty string account is enabled account is unlocked user must change their password at next login password is set to follow the password expiry policy
Syntax
DMRESETUSER username [-accessserver hostname port adminuser adminpassword]
Parameters
username Specifies the name of the user account that needs to be reset. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
697
dmunlockuserUnlocking a user account

Use this command to unlock a user account. A user account is automatically locked after the number of failed login attempts exceeds the locking policy you may have set in the Access Server Options dialog box in Management Console.
Syntax
DMUNLOCKUSER username [-accessserver hostname port adminuser adminpassword]
Parameters
username Specifies the name of the user you want to unlock. -accessserver hostname port adminuser adminpassword The following parameters are optional and are only required if you are running this command remotely from the system where you have installed Access Server. The -accessserver parameter indicates that you want to connect to a remote installation of Access Server. It indicates that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
Other commands
This section contains miscellaneous commands for Access Server. See also: dmaccessserverStart Access Server dmaddconnectionAdding a datastore connection to a user on page 699 dmlistdatastoreusersGenerating a report list of users assigned to a datastore on page 700 dmshowversionShow InfoSphere CDC Access Server version on page 700 onlineOpen command environment on page 701
dmaccessserverStart Access Server

Use this command to start Access Server services for Windows and to start Access Server processes for UNIX and Linux.
Syntax
DMACCESSSERVER
698
Parameters
None.
dmaddconnectionAdding a datastore connection to a user

Use this command to set connection parameters to a datastore for a user. When adding a connection for a user, you must identify the name and password of the database you want users to use for replication. This database resides on the same server as your InfoSphere CDC installation. When the user establishes a connection to the datastore, they are in fact connecting to this database.
Syntax
DMADDCONNECTION userName datastoreName database databaseOwner databasePassword alwaysPrompt showParams writeProtected saveParams [-accessserver hostname port adminuser adminpassword]
Parameters
userName Specifies the name of the user for which you want to create a connection. datastoreName Specifies the name of the datastore you want the user to connect to. database Specifies the name of the database that you want users to replicate to or from. Not all datastore connections are to a database. Use "" if not required. databaseOwner Specifies the user name of the database. Not all datastore connections are to a database. Use "" if not required. databasePassword Specifies the password to log into the database. Not all datastore connections are to a database. Use "" if not required. alwaysPrompt Specifies that you want the user to always be prompted for a connection each time the user tries to connect to the datastore. If you want the user to be prompted for a connection, then specify a value of TRUE. Otherwise, specify a value of FALSE. showParams Specifies that you want all the connection parameters displayed to the user (except for the password) each time the user tries to connect to the datastore. If you want the parameters displayed, then specify a value of TRUE. Otherwise, specify a value of FALSE. writeProtected Specifies that you want all the connection parameters displayed to the user in read-only format each time the user tries to connect to the datastore. If you want the parameters displayed in read-only format, specify a value of TRUE. Otherwise, specify a value of FALSE. saveParams Specifies that you want the user to be able to save connection parameters when connecting to the datastore. If you want to enable parameter saving, then specify a value of TRUE. Otherwise, specify a value of FALSE. -accessserver hostname port adminuser adminpassword
699
These parameters are optional and indicate that you want to run this command for an installation of Access Server that is physically remote from the Access Server installation where you are running this command. In other words, you must install Access Server and run this command on a system to which you have direct physical access. If you have installed Access Server on the same machine as Management Console, then these parameters are not required. hostname The fully qualified host name of the remote system where Access Server is installed. port The port number of the remote system where Access Server is installed. adminuser A user with system administrator (SYSADMIN) privileges (see role parameter in the dmcreateuser command) and the ability to manage users and datastores (see manager parameter in the dmcreateuser command). adminpassword The password for the specified SYSADMIN user.
dmlistdatastoreusersGenerating a report list of users assigned to a datastore

Use this command to generate a list of users assigned to a specific datastore.
Syntax
DMLISTDATASTOREUSERS adminUser adminPassword datastoreName
Parameters
adminUser Specifies the name of the System Administrator. adminPassword Specifies the password of the System Administrator. datastoreName Specifies the name of the datastore you want to generate a list for. This list specifies the names of the users assigned to this datastore.
dmshowversionShow InfoSphere CDC Access Server version

Use this command to display the InfoSphere CDC Access Server version and build number. Run this command before you contact your IBM representative.
Syntax
DMSHOWVERSION
Parameters
None.
700
onlineOpen command environment

This command opens a command environment where you can submit Management Console commands. For more information on the commands that are available, see Management Console - API and Commands Reference.
Syntax
ONLINE
Parameters
None.
701
702
Using Support Assistant and contacting IBM Support

Management Console Support Assistant, or simply Support Assistant, allows you to collect diagnostic data such as configuration, log, and runtime information for Management Console, Access Server, and optionally for specific datastores in your environment. If tracing is enabled, it can also collect trace information for Management Console, Access Server, and your datastores. By default with the Standard collection method, Support Assistant collects diagnostic data and tracing information for Management Console and Access Server. If you specify a Detailed collection method for datastores, Support Assistant collects diagnostic and trace data for the time period you specify. You must enable tracing before running Support Assistant so that Management Console saves tracing information while you reproduce your support issue.Support Assistant will collect the trace information for Management Console and Access Server, and if you enable Detailed collection for the specified datastores, it will collect the trace information for the time period that you specify. Support Assistant collects diagnostic data and trace information and places this data in a compressed file with a .zip extension. It is your responsibility to send this file to IBM Support which is used to diagnose and troubleshoot your support issue. Preparing to collect diagnostic data and tracing information Contacting IBM Support on page 706
Preparing to collect diagnostic data and tracing information

Before using Support Assistant to collect diagnostic data and tracing information, review and complete the tasks in the following workflow to ensure the collected data is adequate for efficient problem diagnosis and resolution: 1. Enable tracing for Management Console and Access Server. See the related topic below for more information on how to do this. 2. Enable tracing for your datastores if this is requested by IBM Support. Tracing for your datastores may result in significant performance degradation and is often recommended only after consultation with IBM Support. See the related topic below for more information on how to do this. 3. Reproduce the problem you encountered in Management Console or with your InfoSphere CDC datastore. 4. Start collecting diagnostic data and tracing information with Support Assistant. Support Assistant collects this information in a compressed file that you will send to IBM Support. See the related topic below for more information on how to do this. Important: In order to minimize impact on your InfoSphere CDC datastore performance, you should disable full trace for your datastores after reproducing your support issue. See also: To enable tracing for Management Console and Access Server on page 704
703
To enable tracing for datastores for InfoSphere CDC version 6.3 and above (optional) To start the collection of diagnostic data and tracing information with Support Assistant on page 705
To enable tracing for Management Console and Access Server

Once tracing is enabled for Management Console and Access Server, log files are generated which can be collected by Support Assistant. 1. Click Help > Service Information > Trace Options 2. Select the Enable the collection of tracing information check box to activate tracing. 3. In the Trace Methods area, select one of the following options: v Capture Access Server messagesSelect this option to diagnose configuration and monitoring problems between Management Console, Access Server and datastores. This is the default setting. v Capture Management Console messages Select this option to diagnose problems between a single Management Console, Access Server, and datastores. v Capture Access Server logging information Select this option to diagnose Access Serverspecific problems. Only select this option when instructed by IBM Support. 4. Click OK. Related concepts Using Support Assistant and contacting IBM Support on page 703 Related tasks To enable tracing for datastores for InfoSphere CDC version 6.3 and above (optional)
To enable tracing for datastores for InfoSphere CDC version 6.3 and above (optional)
Contact DataMirror Support for information on enabling tracing for other versions of InfoSphere CDC. The instructions below do not apply to InfoSphere CDC for z/OS. For InfoSphere CDC for z/OS, tracing should only be enabled once IBM Support has reviewed the SPOOLed output and can provide advice on the trace points to enable if it is necessary to further the investigation. Note: Tracing for your datastores should only be used when directed by IBM Support since it may significantly degrade InfoSphere CDC replication engine performance. For performance reasons, tracing for your datastores should be turned off immediately after you reproduce your problem in Management Console. 1. Add the global_trace_until system parameter to each datastore (InfoSphere CDC version 6.3 and above) that encountered a support issue. This system parameter will enable tracing until the specified date and time. 2. Enter a date and time or only a date value in the Value box. Ensure you enclose the date and time values with quotes. For example, "1/14/08" or "1/14/08 1:34 PM". When you enter a specific date and time, full tracing is enabled until that specified period. If you choose to only specify a date, then
704
tracing is turned on by default until 12 AM. For example, if you specify "1/14/08" then tracing is turned on until January 14, 2008 at 12 AM. If you specify both date and time "1/14/08 1:34 PM", then tracing is turned on until January 14, 2008 at 1:34 PM. You can also delete the system parameter to turn off tracing. 3. Click OK. Due to the performance impact of tracing on your datastores, you should ensure that tracing is turned off after reproducing your support issue in Management Console. Related concepts Using Support Assistant and contacting IBM Support on page 703 Related tasks To enable tracing for Management Console and Access Server on page 704 To add a system parameter on page 74 To delete a system parameter on page 74
To start the collection of diagnostic data and tracing information with Support Assistant
Important: Before you start the collection of diagnostic data and tracing information with Support Assistant you must follow the workflow and complete the tasks outlined in Preparing to collect diagnostic data and tracing information on page 703. 1. Click Help > Service Information > Support Assistant 2. In the Collection area, select the Enable collection check box for each datastore for which you want to collect diagnostic data and tracing information. Support Assistant automatically collects diagnostic data and tracing information for Management Console and Access Server. 3. Click Options to open the Datastore Collection dialog box. 4. In the Collection Method area, choose one of the following options: v StandardIndicates that Support Assistant will collect standard diagnostic data for the specified datastores. Tracing information for your datastores is not collected with this option. v DetailedIndicates that Support Assistant will collect detailed diagnostic data for the specified datastores. This method of data collection may take substantially longer than the Standard collection method. If IBM Support requests that you collect tracing information for the specified datastores, you must enable tracing on your datastores before you reproduce the problem and before you use Support Assistant to collect the tracing data. See the appropriate related topic below for more information on how to enable tracing for your datastore. 5. For the Detailed collection method in the Time Period area, select the time period when you want Support Assistant to collect diagnostic data and tracing information for the specified datastores. Support Assistant automatically collects all diagnostic data and tracing information for Management Console and Access Server. 6. Click OK. 7. In the Output area, click Browse to select the directory where you want Support Assistant to place the generated .zip file after collection is complete.
Using Support Assistant and contacting IBM Support
705
8. To remove additional diagnostic files from the directory you selected in the previous step after collection is complete and only leave the .zip file, select the Clean-up diagnostic files after collection check box. 9. Click Collect Now to start the collection process. 10. After collection is complete, Support Assistant displays the path to the .zip file on your system. Click Locate File... to open the directory that contains the compressed file. If you selected a Detailed collection method for one or more datastores in Step 4 on page 705, Support Assistant will also display the path to one or more additional .zip files on the systems where each datastore is installed. Make note of the location of these files before you close this dialog box. It is your responsibility to retrieve the .zip files and send them to IBM Support. Note: .zip files with a *.inprocess extension are still collecting data from your datastore and are not ready to be sent to IBM Support. Collection is complete when the *.inprocess extension is removed. Related concepts Preparing to collect diagnostic data and tracing information on page 703
Contacting IBM Support

In addition to collecting diagnostic information with Support Assistant, you should also attempt to provide answers to as many of the following questions as possible before contacting IBM Support: v What is the problem you are experiencing and can you reproduce it? v What did you do to reproduce the problem with tracing enabled? v Which datastores are affected? v Which subscriptions are affected? v Which tables or rows are affected? v Can you provide a screen capture of the error? The following support page contains the latest troubleshooting information and details on how to open a service request with IBM Support: v http://www.ibm.com/software/data/infosphere/support/change-data-capture/ For contact information in your region: v http://www.ibm.com/planetwide/ Related concepts Preparing to collect diagnostic data and tracing information on page 703
706
Glossary
Access Manager. A functional area of the Management Console used by the administrator to configure the security model of InfoSphere CDC users and their permissions. Access Server. A background process on a Windows or UNIX workstation that implements the InfoSphere CDC security model. adaptive apply. A method of applying data to a target table which allows the target table to have incorrect data. As data changes are replicated from the source table the target table will become more accurate. after image. The updated content of a source-table column after the source operation has completed. auditing. The process of tracking table and row-level operations (insert, update, delete and clear operations) that have been applied to a source table. The tracking occurs in a target table. before image. The content of a replication source-table column prior to the source operation. bidirectional replication. Replication in which changes that are made to one copy of a table are replicated to a second copy of that table, and changes that are made to the second copy are replicated back to the first copy. You must choose which copy of the table wins if a conflict occurs. bookmark. Information that InfoSphere CDC uses to maintain transactional data consistency. cascading replication. A replication topology where changes are first replicated to a target table, and then the changes made to that target table are further replicated to one or more additional target tables (often located in another database). column function. An expression within a derived expression that performs enhanced data manipulation. Typically, column functions calculate statistical aggregations, such as COUNT, SUM, AVG, or MAX, based on the values of existing columns, and then place the results in new columns. column mapping. The action of choosing which source columns are replicated to which target columns. commitment control. A feature that maintains transaction consistency during replication and ensures that all transactions are applied to the target system. conflict detection. The process of detecting whether the same row was updated by users or application programs in both the source and target tables at essentially the same time. continuous mirroring. A method of mirroring data where a change applied to a source table is immediately replicated to the target table. You should use continuous mirroring when it is important that source and target tables are synchronized at all times. critical column. A change to a critical column indicates that the source operation is important and should be replicated to the target environment. If a source row is updated but no critical columns are changed then this change won't be replicated to the target table. The changes to the non-critical columns will be replicated to the target the next time an important update is done. data type. Defines the type of data stored in a specific database column, such as date, numeric, or character data. Significant differences in data types exist between different platforms' databases. datastore. An instance of a InfoSphere CDC engine. Instances are created using the configuration tool provided for each engine derived column. A column that is calculated from other source column values using a derived expression. differential refresh. A process that will synchronize the target table with the current contents of the source table by applying only the differences between the target and the source table. expressions. An expression that defines the value placed in a column for each row inserted or updated in a target table. filtering columns. The process of identifying which source columns you want to include or exclude for replication. in scope objects. Objects that will be considered, or included, for replication to the backup system. journal control fields. A set of fields that contain different information about a journal entry associated with a source table change. Journal control fields can be assigned to target columns, as journal entry information is replicated with source table data. In Management Console, journal control fields are denoted with an ampersand (&) before the name of the field latency. The latency of the target table indicates how closely synchronized it is with the source table. For
707
example, if all the changes that have occurred more than thirty seconds ago on the source system have been applied to the target table, but some changes that were done in the last thirty seconds have not yet been applied, then the table would be thirty seconds latent. LiveAudit. A feature that maintains an audit trail of table changes in the mapped target table. Management Console. The administrator applications that provide the necessary support to configure, manage, and monitor an entire replication configuration from a central location. member identifiers. An expression identifying the member in a multimember IBM i source table that is the source of replicated data. You require member identifiers to identify the member for each replicated record so that data in the target table is not erased during a refresh. metadata. The internal set of tables that maintain the entities, attributes, and characteristics of your replication configuration. mirroring. The process of continuous replication of changed data from the source system to the target system scheduled end (net change) mirroring. Scheduled End (Net Change) mirroring replicates changes (to the target) up to a user-specified point in the source database log and then ends replication. Use this type of mirroring when business requirements dictate that you only replicate your data periodically and you have a clearly defined end point for the state of your target database when replication ends. Scheduled End (Net Change) mirroring allows you to end replication at the following points in your source database log: v Current time or Now v User-specified date and time v User-specified log position These user specified end points ensure that your target database is in a known state when replication ends. notifications. A mechanism that generates a notification in response to a generated product message. A notification can be conveyed through different methods (e-mail notification, user exit program notification, and so on). This mechanism allows a user to monitor replication activity in their network. out of scope objects. Objects that will not be considered for, or will be excluded from, replication to the target system. persistent subscription. InfoSphere CDC will ensure that a persistent subscription is restarted when the engine is restarted after shutdown or after the subscription ends with a recoverable error.
propagation control. The process of preventing the replication of data from a particular source. This is useful if you are using a bidirectional replication configuration and prevents subscriptions from unnecessarily repeating operations like inserting data. recursion. The process by which a perpetual series of repetitive changes applied to the same record occurs between two or more tables in a bidirectional replication scenario. recursion prevention. When performing bidirectional replication, the ability to avoid a change to one table from being repetitively applied to both tables without termination. refresh. A process that will synchronize the target table with the current contents of the source table. refresh order. The order in which source tables will be refreshed. replication. The process of maintaining a on-going synchronization between the contents of source tables and target tables The process of sending changes from source table(s) to the target system. In InfoSphere CDC this term encompasses all methods of transferring data (refresh and mirroring). replication method. A property of table mapping that indicates whether it performs mirroring or refresh row filtering. The process of determining which rows in a source table to replicate. Typically, an expression tests one or more column values in each row and returns a boolean result that replicates or discards the row. source database. A database from which replication transfers captured changes. subscription. A group of table mappings. subscription promotion. The process of copying replication definitions from one environment to another environment without having to recreate the definitions. subscription state. An indicator of the activity involving a subscription defined in Management Console. The subscription state indicates whether replication operations to a subscription are starting, refresh, mirror continuous, mirror net-change, ending, inactive, or unknown. subscription status. The subscription status indicates how replication is progressing. The subscription status can be Normal, Error, or Unknown. summarization. A method of applying data to a target table where numeric data in the table is incremented or decremented based on the type of row-level operation (insert, update, or delete) applied to the table.
708
Summarization allows you to aggregate data without having to define expressions that will maintain the equivalent results. system parameter. A setting that can be modified to change a certain behavior of InfoSphere CDC. table mapping. A component of a subscription that connects a source replication object with a target replication object and specifies communication paths, such as queues or TCP/IP connections. target database. A database to which replication software applies changes captured from a source database. throughput. A measure of the rate at which data changes are retrieved, sent, and applied on the target system. transaction consistency. While mirroring data, transaction consistency is the guarantee that if part of a transaction has been committed to the target database, then all other in-scope operations from that source transaction will have been committed as well. transformation. The process of manipulating replicated data from a source to a target.
Glossary
709
710
Notices
This information was developed for products and services offered in Canada. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
711
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Canada Limited Office of the Lab Director 8200 Warden Avenue Markham, Ontario L6G 1C7 CANADA Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy,
712
modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp. _enter the year or years_. All rights reserved. If you are viewing this information softcopy, the photographs and color illustrations may not appear.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Netezza is a trademark or registered trademark of Netezza Corporation, an IBM Company. UNIX is a registered trademark of The Open Group in the United States and other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Other company, product, or service names may be trademarks or service marks of others.
Notices
713
714
Printed in USA

CDC Admin Guide

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CDC Admin Guide

Hochgeladen von

Copyright:

Verfügbare Formate

IBM InfoSphere Change Data Capture

InfoSphere Change Data Capture Management Console, Version 6.5.2

IBM InfoSphere Change Data Capture

InfoSphere Change Data Capture Management Console, Version 6.5.2

Setting up user accounts . . . . . . . 25

Whats new . . . . . . . . . . . . . 5 Before you start Management Console . 7

Understanding the Management Console interface . . . . . . . . . . 13 Setting preferences . . . . . . . . . 15

Copyright IBM Corp. 2008, 2011

To delete a project . Exporting and importing To export projects . To import projects .

Setting up datastores for replication . . 71 Setting up and configuring subscriptions . . . . . . . . . . . . 49

Managing tables available for replication . . . . . . . . . . . . . 79

InfoSphere Change Data Capture: Management Console Administration Guide

. 133 . 133 . 133 . 134 . 134 . . . . 135 135 135 135

Replicating Data Definition Language (DDL) changes . . . . . . . . . . . 137

. 149 . 150 . 151 . 151 . 152 . 152

Customizing InfoSphere DataStage table mappings . . . . . . . . . . 155

Understanding data types supported by InfoSphere CDC . . . . . . . . . 159

Using journal control fields for auditing replication activities . . . . 197

Mapping columns . . . . . . . . . 173

Setting data translations on column mappings . . . . . . . . . . . . . 183

Controlling table operations . . . . . 213

Replicating multibyte (MBCS) and double-byte (DBCS) character data . . 187

Configuring user exits . . . . . . . 219

228 229 230 231

Setting member identifiers. . . . . . 195

InfoSphere Change Data Capture: Management Console Administration Guide

Column functions . . . . . . . . . 245

Controlling row operations . . . . . 327

Customizing JMS message destination mappings . . . . . . . . 331

Setting JMS message header properties . . . . . . . . . . . . . 339

Filtering rows and columns . . . . . 315

Configuring replication . . . . . . . 343

Setting conflict detection and resolution . . . . . . . . . . . . . 319

InfoSphere Change Data Capture: Management Console Administration Guide

. 353 . 353 353

Starting and ending replication. . . . 355

Setting notifications . . . . . . . . 365

Promoting subscription changes . . . 377

Monitoring subscriptions . . . . . . 387

InfoSphere Change Data Capture: Management Console Administration Guide

InfoSphere Change Data Capture: Management Console Administration Guide

System parameters for InfoSphere CDC Event Server . . . . . . . . . 653

System parameters for InfoSphere CDC for InfoSphere DataStage . . . . 661

InfoSphere Change Data Capture: Management Console Administration Guide

666 666 666 667 667 667 668 668 668

Apply process system parameters convert_not_nullable_column . userexit_max_lob_size_kb . .

. 684 . 684 . 685

Commands for Access Server . . . . 687

System parameters for InfoSphere CDC for Informix . . . . . . . . . . 669

Using Support Assistant and contacting IBM Support . . . . . . . 703

System parameters for InfoSphere CDC for Netezza databases . . . . . 681

Glossary . . . . . . . . . . . . . 707 Notices . . . . . . . . . . . . . . 711

InfoSphere Change Data Capture: Management Console Administration Guide

Overview of InfoSphere CDC

Copyright IBM Corp. 2008, 2011

InfoSphere Change Data Capture: Management Console Administration Guide

Understanding the InfoSphere CDC workflow

Overview of InfoSphere CDC

InfoSphere Change Data Capture: Management Console Administration Guide

Flagging a source table for refresh on page 343

Upgrading InfoSphere CDC

Copyright IBM Corp. 2008, 2011

InfoSphere Change Data Capture: Management Console Administration Guide