InfoSphere CDC for Oracle databases (Version 10.2.1) 5About InfoSphere CDC 8Capturing change data with single scrape 11What's new 12System requirements for InfoSphere CDC for Oracle databases 13Hardware and software requirements 14Running in a virtualization environment 15Disk space requirements 16RAM requirements 18Tablespace requirements 19Port requirements 20Before you install InfoSphere CDC for Oracle databases 21Required database, user accounts, and schemas 22Assessing disk space and memory requirements 23Understanding the importance of an appropriately configured disk subsystem 25Allocating sufficient disk space for database log files 26Sizing considerations for the staging store 28Understanding the InfoSphere CDC memory footprint 30Enabling supplemental logging 31Enabling InfoSphere CDC for Oracle databases to use a bulk load refresh 33Setting the database instance to ARCHIVELOG mode 34InfoSphere CDC and Automatic Storage Management (ASM) 35Starting the Oracle listener 36Setting up a remote connection 37To set up a remote connection 38Replicating DDL changes 39Calculating database connections required by InfoSphere CDC for Oracle databases 40Clustered tables 42Interval partitions 43Replicating XA transactions 44Database partition changes 45Creating queues in JMS providers 46Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC) environment 47Configuring InfoSphere CDC for Oracle databases in a RAC environment 49Configuring tnsnames.ora for InfoSphere CDC in a RAC environment 51Oracle ASM considerations in a RAC environment 53Creating an InfoSphere CDC for Oracle databases failover script for a RAC environment 54NFS lockd utility considerations 55Configuring InfoSphere CDC for Oracle databases for OS (operating system) clustering (UNIX andLinux) 56Performing a forced or manual failover of InfoSphere CDC for Oracle databases 57Preparing for a failover of InfoSphere CDC for Oracle databases 58Installing or upgrading InfoSphere CDC for Oracle databases 59Installing InfoSphere CDC for Oracle databases 60To install InfoSphere CDC for Oracle databases (UNIX and Linux) 61To override the locale for the installation (UNIX and Linux) 62Installing InfoSphere CDC for Oracle databases using a silent installation 63

To perform a silent installation of InfoSphere CDC for Oracle databases (UNIX and Linux) 64Upgrading InfoSphere CDC for Oracle databases 65To upgrade InfoSphere CDC for Oracle databases (UNIX and Linux) 66Configuring instances of InfoSphere CDC for Oracle databases 68Configuring InfoSphere CDC for Oracle databases instances for local log reading 69To add a new instance of InfoSphere CDC for Oracle databases that reads logs locally 70Configuring InfoSphere CDC for Oracle databases for remote log reading 74To add a new instance of InfoSphere CDC for Oracle databases that reads logs remotely 75Configuring InfoSphere CDC for Oracle databases for log shipping 79To add a new instance of InfoSphere CDC for Oracle databases with log shipping using DataGuard 80To add a new instance of InfoSphere CDC for Oracle databases with manual log shipping 84To ship logs using custom scripts 87Editing an instance of InfoSphere CDC for Oracle databases 89To edit an instance of InfoSphere CDC for Oracle databases 90Deleting an instance of InfoSphere CDC for Oracle databases 91To delete an instance of InfoSphere CDC for Oracle databases 92After you install and configure InfoSphere CDC for Oracle databases 93Granting required privileges to Oracle users using SQL scripts in /samples directory 94Privileges for Oracle users 95Starting InfoSphere CDC for Oracle databases 100To start InfoSphere CDC for Oracle databases (UNIX and Linux) 101Stopping InfoSphere CDC for Oracle databases 102To stop InfoSphere CDC for Oracle databases (UNIX and Linux) 103Performing an external refresh 104To perform an external refresh 107Maintaining active TCP connections in a network environment 108To maintain active TCP connections 109Enabling SQL statements in Management Console 110To enable SQL statements in Management Console 111InfoSphere CDC for Oracle databases metadata tables 112Data types supported by InfoSphere CDC 113System parameters for InfoSphere CDC for Oracle databases 114Commands for InfoSphere CDC for Oracle databases 115Using the InfoSphere CDC for Oracle databases commands 116Setting the TSINSTANCE environment variable 117Continuous Capture commands 118dmdisablecontinuouscapture - Disable Continuous Capture 119dmenablecontinuouscapture - Enable Continuous Capture 120Controlling replication commands 121dmendreplication - End replication 122dmrefresh - Refresh subscription 126dmstartmirror - Start mirroring 128Database transaction log commands 131dmarchivelogavailable - Mark archive log as available 132dmarchivelogremoved - Mark archive log as removed 134dmdecodebookmark - Display verbose information bookmark 135

dmsetbookmark - Set bookmark 136dmshowbookmark - Display bookmark information 138dmshowlogdependency - Show Log Dependency 140Supplemental logging commands 142dmshowsupplementalloggingdependency - Show supplemental logging dependency 143dmreducesupplementalloggingdependency - Reduce supplemental logging dependency 144dmsupplementallogevallist - Supplemental logging evaluation list 145Single scrape and staging store commands 146dmclearstagingstore - Remove cached operations from the staging store 147dmgetstagingstorestatus - Retrieve Staging Store status 148Exporting and importing configuration commands 149dmexportconfiguration - Export InfoSphere CDC Configuration 150dmimportconfiguration - Import InfoSphere CDC Configuration 151Managing tables for replication commands 152dmdescribe - Describe source tables 153dmflagforrefresh - Flag for Refresh 154dmmarktablecapturepoint - Mark a table capture point on a source table 155dmpark - Park table 157dmreaddtable - Update source table definition 158dmreassigntable - Update target table definition 159dmsetreplicationmethod - Set replication method 160Monitoring replication commands 162dmclearevents - Clear events 163dmgetsubscriptionstatus - Get subscription status 164dmshowevents - Display InfoSphere CDC events 165Other commands 167dmbackupmd - Back up metadata 168dmconfigurets - Configure InfoSphere CDC 169dmmarkexternalunloadstart - Start table data unload 170dmmarkexternalunloadend - End table data unload 171dmmdcommander 172dmmdconsole 173dmset - Set InfoSphere CDC system parameter 174dmshowversion - Show InfoSphere CDC version 175dmshutdown - Shut down InfoSphere CDC 176dmsupportinfo - Collect IBM Support information 179dmterminate - Terminate InfoSphere CDC processes 181dmts32 - Start InfoSphere CDC 182dmts64 - Start InfoSphere CDC 183User exits for InfoSphere CDC for Oracle databases 184Stored procedure user exits for table and row level operations 185Defining a stored procedure user exit 186Stored procedure user exit database connections 187Retrieving data with a stored procedure user exit 188Retrieving system values using the s$ prefix 189Retrieving journal control fields using the j$ prefix 192Retrieving data values using b$, a$, k$, and d$ prefixes 195

Example of a stored procedure user exit 198Sample Java class user exits for InfoSphere CDC for Oracle databases 200To compile the sample Java class user exits (UNIX and Linux) 201InfoSphere CDC API reference - Javadocs 202Conflict resolution audit table 203Structure of the conflict resolution audit table 204Row image format 206Truncated images 207Unaudited data types 208Uninstalling InfoSphere CDC for Oracle databases 209To uninstall InfoSphere CDC for Oracle databases (UNIX and Linux) 210Troubleshooting 211Using the IBM Support Assistant (ISA DC) 212To use ISA DC to collect data for a product problem (command line) 213To use ISA DC to collect data for a product problem (GUI) 216To use ISA DC to collect data for a question or an enhancement request (command line) 218To use ISA DC to collect data for a question or an enhancement request (GUI) 220Locating log files 222Troubleshooting and contacting IBM Support 223

-

-

-

-

-

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

The key components of the InfoSphere CDC architecture are described in thefollowing list:

Access Server—Controls all of the non-command line access to the replicationenvironment. When you log in to Management Console, you are connecting toAccess Server. Access Server can be closed on the client workstation withoutaffecting active data replication activities between source and target servers.Admin API—Operates as an optional Java™-based programming interface thatyou can use to script operational configurations or interactions.Apply agent—Acts as the agent on the target that processes changes as sent bythe source.Command line interface—Allows you to administer datastores and useraccounts, as well as to perform administration scripting, independent ofManagement Console.Communication Layer (TCP/IP)—Acts as the dedicated network connectionbetween the Source and the Target.

5

-

-

-

-

-

-

-

-

-

-

-

-

Source and Target Datastore—Represents the data files and InfoSphere CDCinstances required for data replication. Each datastore represents a database towhich you want to connect and acts as a container for your tables. Tables madeavailable for replication are contained in a datastore. Management Console—Allows you to configure, monitor and manage replicationon various servers, specify replication parameters, and initiate refresh andmirroring operations from a client workstation. Management Console also allowsyou to monitor replication operations, latency, event messages, and other statisticssupported by the source or target datastore. The monitor in Management Consoleis intended for time-critical working environments that require continuous analysisof data movement. After you have set up replication, Management Console can beclosed on the client workstation without affecting active data replication activitiesbetween source and target servers.Metadata—Represents the information about the relevant tables, mappings,subscriptions, notifications, events, and other particulars of a data replicationinstance that you set up.Mirror—Performs the replication of changes to the target table or accumulation ofsource table changes used to replicate changes to the target table at a later time. Ifyou have implemented bidirectional replication in your environment, mirroring canoccur to and from both the source and target tables.Refresh—Performs the initial synchronization of the tables from the sourcedatabase to the target. This is read by the Refresh reader.Replication Engine—Serves to send and receive data. The process that sendsreplicated data is the Source Capture Engine and the process that receivesreplicated data is the Target Engine. An InfoSphere CDC instance can operate asa source capture engine and a target engine simultaneously.Single Scrape—Acts as a source-only log reader and a log parser component. Itchecks and analyzes the source database logs for all of the subscriptions on theselected datastore. Not all InfoSphere CDC engines use Single Scrape. ForInfoSphere CDC for DB2® for i, there is a Scraper job (that acts as a log reader)and a Mirror job that performs the function of mirroring. Source transformation engine—Processes row filtering, critical columns, columnfiltering, encoding conversions, and other data to propagate to the target datastoreengine.Source database logs—Maintained by the source database for its own recoverypurposes. The InfoSphere CDC log reader inspects these in the mirroring process,but filters out the tables that are not in scope for replication. Target transformation engine—Processes data and value translations, encodingconversions, user exits, conflict detections, and other data on the target datastoreengine.

There are two types of target-only destinations for replication that are notdatabases:

JMS Messages—Acts as a JMS message destination (queue or topic) for row-level operations that are created as XML documents.InfoSphere DataStage—Processes changes delivered from InfoSphere CDC thatcan be used by InfoSphere DataStage jobs.

In this section, you will learn:

6

-

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

7

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/capturingchangedatawithsinglescrape.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.sysreq.doc/concepts/supportedsourceandtargets.html

-

-

-

-

-

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

The key components of the InfoSphere CDC architecture are described in thefollowing list:

Access Server—Controls all of the non-command line access to the replicationenvironment. When you log in to Management Console, you are connecting toAccess Server. Access Server can be closed on the client workstation withoutaffecting active data replication activities between source and target servers.Admin API—Operates as an optional Java™-based programming interface thatyou can use to script operational configurations or interactions.Apply agent—Acts as the agent on the target that processes changes as sent bythe source.Command line interface—Allows you to administer datastores and useraccounts, as well as to perform administration scripting, independent ofManagement Console.Communication Layer (TCP/IP)—Acts as the dedicated network connectionbetween the Source and the Target.

8

-

-

-

-

-

-

-

-

-

-

-

-

Source and Target Datastore—Represents the data files and InfoSphere CDCinstances required for data replication. Each datastore represents a database towhich you want to connect and acts as a container for your tables. Tables madeavailable for replication are contained in a datastore. Management Console—Allows you to configure, monitor and manage replicationon various servers, specify replication parameters, and initiate refresh andmirroring operations from a client workstation. Management Console also allowsyou to monitor replication operations, latency, event messages, and other statisticssupported by the source or target datastore. The monitor in Management Consoleis intended for time-critical working environments that require continuous analysisof data movement. After you have set up replication, Management Console can beclosed on the client workstation without affecting active data replication activitiesbetween source and target servers.Metadata—Represents the information about the relevant tables, mappings,subscriptions, notifications, events, and other particulars of a data replicationinstance that you set up.Mirror—Performs the replication of changes to the target table or accumulation ofsource table changes used to replicate changes to the target table at a later time. Ifyou have implemented bidirectional replication in your environment, mirroring canoccur to and from both the source and target tables.Refresh—Performs the initial synchronization of the tables from the sourcedatabase to the target. This is read by the Refresh reader.Replication Engine—Serves to send and receive data. The process that sendsreplicated data is the Source Capture Engine and the process that receivesreplicated data is the Target Engine. An InfoSphere CDC instance can operate asa source capture engine and a target engine simultaneously.Single Scrape—Acts as a source-only log reader and a log parser component. Itchecks and analyzes the source database logs for all of the subscriptions on theselected datastore. Not all InfoSphere CDC engines use Single Scrape. ForInfoSphere CDC for DB2® for i, there is a Scraper job (that acts as a log reader)and a Mirror job that performs the function of mirroring. Source transformation engine—Processes row filtering, critical columns, columnfiltering, encoding conversions, and other data to propagate to the target datastoreengine.Source database logs—Maintained by the source database for its own recoverypurposes. The InfoSphere CDC log reader inspects these in the mirroring process,but filters out the tables that are not in scope for replication. Target transformation engine—Processes data and value translations, encodingconversions, user exits, conflict detections, and other data on the target datastoreengine.

There are two types of target-only destinations for replication that are notdatabases:

JMS Messages—Acts as a JMS message destination (queue or topic) for row-level operations that are created as XML documents.InfoSphere DataStage—Processes changes delivered from InfoSphere CDC thatcan be used by InfoSphere DataStage jobs.

In this section, you will learn:

9

-

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

10

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/capturingchangedatawithsinglescrape.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.sysreq.doc/concepts/supportedsourceandtargets.html

Capturing change data with single scrape Single scrape is a source-only component of InfoSphere® CDC that allows multiplesubscriptions in an instance to share the same log reader and log parser thread.With single scrape, InfoSphere CDC only reads and parses the source databasetransaction log once to capture changes for all tables being mirrored for theinstance. Single scrape improves performance by reducing the footprint on your sourcesystem since it only requires a single log reader thread and a single log parserthread to service multiple subscriptions. This reduces disk I/O and decreases CPUutilization by InfoSphere CDC processes. Change data and the staging store After the InfoSphere CDC log reader captures the change data from the databaselogs and the data is parsed by the InfoSphere CDC log parser, change data isplaced in the staging store. Each subscription retrieves the changes for mirroringtables from the staging store whenever possible. The data in scope for a givensubscription is kept in the staging store until it is sent to the target database. Afterthe data is sent to the target it is removed from the staging store. To improveperformance when subscriptions are mirroring, InfoSphere CDC will keep thestaging store data in memory whenever possible. Related concepts: Sizing considerations for the staging store Assessing disk space and memory requirements About InfoSphere CDC

11

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/sizingconsiderationsforthestagingstore.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/assessingdiskspaceandmemoryrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/aboutcdc.html

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

Item For more information, see:Simplified configuration of a physicalstandby database.

To add a new instance of InfoSphereCDC for Oracle databases with logshipping using Data Guard

12

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_DataGuardllogshipping_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_DataGuardllogshipping_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_DataGuardllogshipping_unix.html

------

System requirements for InfoSphere CDC for Oracledatabases Before you install InfoSphere® CDC, ensure that the system you choose meets thenecessary operating system, hardware, software, communications, disk, andmemory requirements. In this section, you will learn:

Hardware and software requirements Running in a virtualization environment Disk space requirements RAM requirements Tablespace requirements Port requirements

13

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/hardwareandsoftwarerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/runninginavirtualizationenvironment.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/diskspacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/ramrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/tablespacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/portrequirements.html

Hardware and software requirements Click the following links to view hardware and software requirements forInfoSphere® CDC, Management Console, and Access Server: Linux, UNIX, Windows and System i® replication engines: https://ibm.biz/BdxwE7 Mainframe replication engine: https://ibm.biz/BdxwXB

14

https://ibm.biz/BdxwE7https://ibm.biz/BdxwXB

Running in a virtualization environment The InfoSphere® CDC products adhere to the Virtualization Policy for IBM®Software and can be run in any virtualization environment for only the supportedoperating systems and versions listed specifically within IBMInfoSphere DataReplication System Requirements. For more information on the policy, see http://www-01.ibm.com/software/support/virtualization_policy.html

15

http://www-01.ibm.com/software/support/virtualization_policy.htmlhttp://www-01.ibm.com/software/support/virtualization_policy.html

--

---

Disk space requirements

InfoSphere CDC may require additional disk space in the following situations:

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

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

Disk spaceInfoSphere® CDC source system:100 GB—Default value for theStaging Store Disk Quota for each instance of InfoSphere CDC.The minimum is 1 GB. Although the minimum is 1 GB, prepare formore disk space since there is a staging store on the source. Usethe InfoSphere CDC configuration tool to configure disk space forthis quota.5 GB—For installation files, data queues, and logfiles.Global disk quota—Disk space is required on your sourcesystem for this quota which is used to store in-scope change datathat has not been committed in your database. The amount of diskspace required is determined by your replication environment andthe workload of your source database. Use themirror_global_disk_quota_gb system parameter to configure theamount of disk space used by this quota.InfoSphere CDC target system:1 GB—The minimum amount ofdisk space allowed for the disk quota for each instance ofInfoSphere CDC. The minimum value for this quota is sufficient forall instances created on your target system. Use the InfoSphereCDC configuration tool to configure the disk space for this quota.5GB—For installation files, data queues, and log files.Global diskquota—Disk space is required on your target system for this quotawhich is used to store LOB data received from your InfoSphereCDC source system. The amount of disk space required isdetermined by your replication environment and the amount ofLOB data you are replicating. To improve performance, InfoSphereCDC will only persist LOB data to disk if RAM is not available onyour target system. Use the mirror_global_disk_quota_gb systemparameter to configure the amount of disk space used by thisquota.

16

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/hardwareandsoftwarerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/ramrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/tablespacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/portrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdc_unixandlinux.html

17

-

--

RAM requirements

Although InfoSphere CDC memory requirements will fluctuate, you must work withyour system administrator to ensure the allocated memory for each instance of theproduct is available at all times. This may involve deployment planning since otherapplications with memory requirements may be installed on the same server withInfoSphere CDC. Using values other than the defaults or allocating more RAM thanis physically available on your server should only be undertaken after consideringthe impacts on product performance. InfoSphere CDC source deployments may require additional RAM in the followingscenarios:

You are replicating large LOB data types with your InfoSphere CDC sourcedeployment. These data types are sent to target while being retrieved from thesource database. The target waits until all LOBs (for each record) are receivedbefore applying a row. LOBs are stored in memory as long as there is adequateRAM, otherwise they are written to disk on the target.You are replicating "wide" tables with hundreds of columns.You are performing large batch transactions in your source database rather thanonline transaction processing (OLTP).

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

RAMEach instance of InfoSphere® CDC requires memory for theJava™ Virtual Machine (JVM). The following default values formemory are assigned:1024 MB of RAM —Default value for each 64-bit instance ofInfoSphere CDC. 512 MB of RAM—Default value for each 32-bitinstance of InfoSphere CDC.Use the InfoSphere CDCconfiguration tool to configure the memory for each instance ofInfoSphere CDC.Note:InfoSphere CDC is predominantly a Java-based application.However, some portions of it are written in C. These portions ofInfoSphere CDC are not subject to the memory limits specified forthe JVM

18

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/hardwareandsoftwarerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/diskspacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/tablespacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/portrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdc_unixandlinux.html

Tablespace requirements

Related concepts: Hardware and software requirements Disk space requirements RAM requirements Port requirements

Oracle tablespace for InfoSphere® CDC metadata25 MB—This is only an estimate and depends on the size of your replicationconfiguration.

19

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/hardwareandsoftwarerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/diskspacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/ramrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/portrequirements.html

Port requirements InfoSphere® CDC requires that you allocate a port for communication with clientworkstations running Management Console and other servers. The port must beaccessible through a firewall, although you do not require access to the Internet.

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

Protocol Default port PurposeTCP 10901 Accepts connections

from:ManagementConsoleOtherinstallations ofInfoSphere CDC as asource ofreplicationCommandline utilities

20

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/maintainactivetcpconnnections.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/diskspacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/hardwareandsoftwarerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/ramrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/tablespacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdc_unixandlinux.html

----

-----------

-----

Before you install InfoSphere CDC for Oracledatabases This section contains information on the tasks that you must complete beforeinstalling InfoSphere® CDC. This section assumes that you have met all of thehardware, software, database, and port requirements. You must complete all of thetasks before installing InfoSphere CDC. In this section, you will learn:

Required database, user accounts, and schemas Assessing disk space and memory requirements Understanding the importance of an appropriately configured disk subsystem Allocating sufficient disk space for database log files Allocate sufficient disk space for your database online and archive logs.InfoSphere CDC requires access to archive database logs to read and sendaccumulated data changes for several scenarios. InfoSphere CDC requires thearchive logs any time the log position that InfoSphere CDC is replicating fallsoutside of the online logs. This can occur when there is a backlog of changes, orInfoSphere CDC has been shut down. When InfoSphere CDC exceeds thememory quota allocated, or shuts down, the changes in the staging store andtransaction queue will be persisted to disk.Sizing considerations for the staging store Understanding the InfoSphere CDC memory footprint Enabling supplemental logging Enabling InfoSphere CDC for Oracle databases to use a bulk load refresh Setting the database instance to ARCHIVELOG mode InfoSphere CDC and Automatic Storage Management (ASM) Starting the Oracle listener Setting up a remote connection Understanding Index Organized Tables (IOT) support Replicating DDL changes Calculating database connections required by InfoSphere CDC for Oracledatabases Clustered tables Interval partitions Replicating XA transactions Database partition changes Creating queues in JMS providers

21

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/requireddatabaseuseraccountsandschemas.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/assessingdiskspaceandmemoryrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/understandingtheimportanceofanappropriatelyconfigureddisksubsystem.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/whydoineedtoallocatesufficientdiskspace.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/sizingconsiderationsforthestagingstore.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/understandingtheinfospherecdcmemoryfootprint.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/enablingdatabasesupplementallogging.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/enablingitstouseabulkloadrefresh.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/settingthedatabaseinstancetoarchivelogmode.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/automaticstoragemanagement.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/startingtheoraclelistener.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/settinguparemoteconnection.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/understandingiotsupport.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/replicatingddlchangesoverview.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/calculatingdatabaseconnections.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/calculatingdatabaseconnections.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/oracleclusteredtables.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/intervalpartitions.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/replicatingxatransactions.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/databasepartitionchanges.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/creatingqueuesforjmsproviders.html

Required database, user accounts, and schemas Configuring database When you configure InfoSphere® CDC, you are prompted for the name of thedatabase to which you want InfoSphere CDC to replicate data. Before installingInfoSphere CDC, ensure that this database exists and that you have created andset up a database user that has access to it. Setting up a UNIX user account When you are installing InfoSphere CDC on a UNIX machine, you must set up anew, or decide on an existing UNIX account that you will use to install, configure, orupgrade InfoSphere CDC. You can install InfoSphere CDC in the directory of yourchoice, however, it must be owned by the UNIX account. Setting up an Oracle user account Create a user account for the Oracle database. When you configure a new instanceof InfoSphere CDC, you are prompted for the name of the Oracle database youwant InfoSphere CDC to connect to, the user name and password of the Oracleuser that has access to this database. Setting up an Oracle user with a read-only connection to thedatabase You can also create a user account that has a read-only connection to the Oracledatabase. This type of connection allows a user to read or query data from thedatabase and does not allow a user to write or make any modifications. As anadministrator, you can specify a read-only connection for a user when installing andconfiguring InfoSphere CDC. If you decide to create a read-only database user, youmust ensure that you have enabled supplemental logging for the Oracle databasebefore installing and configuring InfoSphere CDC. Reviewing required privileges for Oracle users Before configuring InfoSphere CDC, you should review the list of privileges requiredby Oracle users. You are required to grant these privileges to users by running SQLscripts which are located in the /samples directory of your installation folder. Youmust grant privileges after installing InfoSphere CDC so that you can access thenecessary SQL script. Configuring an Oracle schema Create a schema or choose an existing schema for your database metadata tables.You will have to specify this schema when you configure InfoSphere CDC. Related concepts: Enabling supplemental logging Privileges for Oracle users

22

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/enablingdatabasesupplementallogging.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/privilegesrequiredbytheoracledba.html

Assessing disk space and memory requirements InfoSphere® CDC requires disk space and memory when it processes change datafrom your source database. In order to process change data efficiently and replicatethese changes to your target system, it is very important that InfoSphere CDC hasadequate disk space and memory for each of the components described in thissection. Disk space requirements for the staging store The InfoSphere CDC staging store is located on your source system and is a cacheof change data read from the database logs. The size of the staging store willincrease as the product accumulates change data, and therefore you must plan yoursource environment accordingly, particularly disk space. The disk space allocated to the staging store is controlled by the Staging Store DiskQuota value that is set when you create an instance with the InfoSphere CDCconfiguration tool. In most cases, the default value is appropriate for InfoSphereCDC source systems. Since the staging store is only used on source systems, youcan reduce this value to the minimum of 1 GB if you are configuring a targetinstance of InfoSphere CDC. Note: You can also allocate disk space to the staging store with thestaging_store_disk_quota_gb system parameter in Management Console. Memory requirements for the JVM (Java Virtual Machine) As a Java-based product, InfoSphere CDC requires you to allocate the maximumamount of memory (RAM) to be used by the Java™ Virtual Machine (JVM). Thisprevents InfoSphere CDC from using all of the available memory on the systemwhere it is installed. The Maximum Memory Allowed value is set on a per-instance basis for eachinstance you create for your source or target database. In most cases the defaultvalues are appropriate for 32-bit and 64-bit instances. However, if your database isprocessing an extremely heavy workload, you may have to adjust the default values.The RAM allocated must be physically available on your system. Disk space requirements for the global disk quota The global disk quota on your source and target systems is used for all capturecomponents including temporary files, transaction queues, and LOBs which arestaged on the target before being applied. InfoSphere CDC will manage disk spaceutilization across all components as required. Most databases have a mechanism that allows you to roll back or undo changes toyour database by storing uncommitted changes. Similarly, InfoSphere CDC usesthis disk quota to store in-scope change data that has not been committed in yourdatabase. Once the database transaction is committed, the disk space used by thetransaction is released. Long running open transactions will contribute to the amountof disk space used. You can configure the amount disk space that is allocated to this quota with themirror_global_disk_quota_gb system parameter. The default setting of this systemparameter is such that InfoSphere CDC will only stop replicating after this disk quotaexhausts all available disk space on your system. If you would prefer InfoSphere

23

CDC to stop replicating after it uses a specific amount of disk space, you can specifythe value with this system parameter in Management Console. Related concepts: Sizing considerations for the staging store Configuring instances of InfoSphere CDC for Oracle databases Disk space requirements RAM requirements

24

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/sizingconsiderationsforthestagingstore.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdc_unixandlinux.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/diskspacerequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/ramrequirements.html

Understanding the importance of an appropriatelyconfigured disk subsystem There are many types of disk subsystems in use to meet either business orperformance needs. Not all of these disk subsystems are suitable for use bydatabases or InfoSphere® Data Replication out of the box. Some may need to betuned to ensure that appropriate input/output semantics are in place for reliablecontinuous operation. Symptoms of an unreliable disk subsystem Without appropriate disk subsystem configuration, both the database itself orInfoSphere Data Replication may exhibit any of a wide variety of input/output relatederrors, usually random in nature. Any one of them can stop replication. If thedatabase transaction logs themselves become corrupted due to this kind ofmisconfiguration, then the database itself may become unrecoverable, putting theentire business at risk. Having an appropriately configured disk subsystem istherefore essential to the operation of both database and InfoSphere DataReplication. What makes a disk subsystem unreliable? Typically, disk mounting options that interfere with or modify the read visibility ofwrite operations are the ones which will cause data to be read inaccurately, therebycausing applications such as databases and InfoSphere Data Replication to reporterrors and fail. The expectations of these semantics between the database andInfoSphere Data Replication must be compatible with those provided by the optionsused to mount the disk subsystem in order to avoid corruption issues. Somedatabases exhibit specific behaviors only with certain disk subsystem types, soproper care and attention is needed to properly configure the disk subsystem. Special notes regarding specific configurations Direct I/O on Linux—Due to the nature of the implementation of direct I/O (directio)on Linux, applications that read from files being written using direct I/O must employexactly the same direct I/O options as the writing application. If this is not done, thereading application may not ever see the data written by the writing application andthe reading application can therefore exhibit a stall. Linux versions of InfoSphereCDC prior to version 6.5.1 Interim Fix 17 for Oracle, version 6.5.2 Interim Fix 20 forOracle, and InfoSphere Data Replication versions prior to 10.2 for Oracle andSybase can exhibit this behaviour under certain conditions. The best resolution is toupgrade to the latest Interim Fix level for InfoSphere CDC or to version 10.2 or laterfor InfoSphere Data Replication.

25

Allocating sufficient disk space for database logfiles Allocate sufficient disk space for your database online and archive logs.InfoSphere® CDC requires access to archive database logs to read and sendaccumulated data changes for several scenarios. InfoSphere CDC requires thearchive logs any time the log position that InfoSphere CDC is replicating falls outsideof the online logs. This can occur when there is a backlog of changes, orInfoSphere CDC has been shut down. When InfoSphere CDC exceeds the memoryquota allocated, or shuts down, the changes in the staging store and transactionqueue will be persisted to disk. InfoSphere CDC is shut down for maintenance InfoSphere CDC requires the archive logs to capture changes when replication hasstopped on a subscription for maintenance activities. You require sufficient diskspace for the archive logs. For example, if you decide to restart mirroring on asubscription that stopped for one week, InfoSphere CDC must read through all thelog volume that was generated in this time period and capture accumulatedchanges. The database may have generated many archived log files while thesubscription was inactive.After time, also assess whether you want to keep the logsor refresh after a lengthy period of time with no replication. This would depend onthe number of and types of changes and the amount of data in the archive logs.Sometimes, it is more efficient to clean out the logs to prevent maintainingunnecessary data. While subscriptions are inactive for a period of time, the database generates manyarchive log files which need to be retained. Use the dmshowlogdependencycommand to indicate which log files to keep. For example, to display the completelist of database logs that are required for the MYINSTANCE instance andMYSUBSCRIPTIONNAME subscription, run this command:dmshowlogdependency -IMYINSTANCE -i -s MYSUBSCRIPTIONNAME Mirroring is run intermittently for a subscription When you set a subscription with a scheduled end to Now, InfoSphere CDCcaptures the data from the earliest marked log position up until the current logposition. The earliest marked log position is set by the oldest open transaction orUnit of Recovery (UR) in the database when InfoSphere CDC was last run or whenyou set a subscription to use mirroring in Management Console. When you startmirroring on the subscription in Management Console, InfoSphere CDC marks thecurrent position in the log and only those changes that InfoSphere CDCaccumulated between these log positions (earliest and current) are sent to the targettable. Because of the time period that may have elapsed between the earliest andcurrent log positions, there may be many archive log files that need to be retaineduntil InfoSphere CDC has processed them. A subscription experiences latency while continuouslymirroring changes to the target database During continuous mirroring, your subscription may begin to lag and may even beunable to keep up with current changes the database is writing to your archive logs.This is what happens when your subscription experiences latency. InfoSphere CDCrequires access to the archive logs so that it can continue to read the accumulated

26

changes from the log files and eventually catch up to the current position in thearchive log files. For very latent subscriptions, this can be log files that are hours,days, or even weeks old. To determine latency, use the Management ConsoleMonitoring perspective. The Monitoring perspective contains the Subscriptions viewand the Performance view. These views allow you to initiate replication and monitoryour replication activity.

27

Sizing considerations for the staging store This topic outlines scenarios that will increase the disk requirements for the stagingstore on your source system. All of these scenarios should be kept in mind whenyou are planning the disk space requirements for your replication environment. Latent subscriptions The amount of data within the staging store is related to the latency of yoursubscriptions. InfoSphere® CDC measures latency as the amount of time thatpasses between when data changes on a source table and when it changes on thetarget table. For example, if an application inserts and commits a row into the sourcetable at 10:00 and InfoSphere CDC applies that row to the target table at 10:15, thenthe latency for the subscription is 15 minutes. When all of your subscriptions are mirroring and have very little latency, the volumeof data that needs to be kept in the staging store will be relatively small. If all of yoursubscriptions are mirroring but some are latent, the staging store will contain all thedata generated by the logs for the latent subscriptions during the entire time they aremirroring. For example, if the difference in latency between the least latentsubscription and the most latent subscription is 3 hours, and your databasegenerates 100 GB of log data per hour, the staging store will require approximately300 GB of disk storage space. Inactive subscriptions An inactive (not currently replicating) subscription that contains tables with areplication method of Mirror will continue to accumulate change data in the stagingstore from the current point back to the point where mirroring was stopped. For thisreason, you should delete subscriptions that are no longer required, or change thereplication method of all tables in the subscription to Refresh to prevent theaccumulation of change data in the staging store on your source system. Continuous Capture Continuous Capture is a product feature that is designed to accommodate thosereplication environments in which it is necessary to separate the reading of thedatabase logs from the transmission of the logical database operations. This isuseful when you want to continue processing log data even if replication and yoursubscriptions stop due to issues such as network communication failures over afragile network, target server maintenance, or some other issue. You can enable ordisable Continuous Capture without stopping subscriptions. Continuous Capture results in additional disk utilization on the source machine inorder to accumulate change data from the database log file when these are notbeing replicated to the target machine. This change data is stored in the stagingstore. The additional disk utilization due to the accumulation of change data in thestaging store should be evaluated and understood before deciding to use thisfeature in your replication environment. Related concepts: Assessing disk space and memory requirements Continuous Capture commands

28

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/assessingdiskspaceandmemoryrequirements.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/stagingstoreandcontinuouscapture.html

29

Understanding the InfoSphere CDC memoryfootprint Current® versions of InfoSphere® CDC on Linux, UNIX, and Windows platforms arewritten in the Java™ programming language. The memory specified in theInfoSphere CDC configuration tool refers to the amount of memory that the JavaVirtual Machine (JVM) will allocate to InfoSphere CDC to run. This memory is strictlyenforced by the JVM itself and the JVM will ensure that it is not exceeded. The JVM itself also consumes some memory. The amount of this other memoryvaries considerably by Java version, bit length, and operating system. A simple Javaprogram consumes 13212 KB of overhead when run in a 32-bit Java 1.5 JVM onAIX®, but 173509 KB of overhead when run in a 32-bit Java 1.5 JVM on Linux. Inother words, the overhead on Linux is 13 times larger than the overhead on AIX,when controlling for the other variables. The amount of memory overhead consumed by the JVM itself can also change overtime. This is especially true for Linux and UNIX systems. For those systems, oncethe operating system allocates memory to a process, it is not reclaimed until theprocess ends. Thus, the total amount of memory for any given process never goesdown. Given these factors, you should expect that more memory is used by InfoSphereCDC than is allocated in the configuration tool. InfoSphere CDC has no control overthis memory usage and cannot track or otherwise manage it.

30

-

-

-

--

-

Enabling supplemental logging Oracle supplemental logging simply means that all columns or selected columns arespecified for extra logging. InfoSphere® CDC requires supplemental logging on thesource database at both the database level and table level. Database level supplemental logging is an Oracle requirement that ensures that theOracle redo log contains the information required to describe all data changescompletely. You must set this value explicitly in Oracle because the default level ofsupplemental logging is not sufficient. To check if minimal supplemental logging hasbeen enabled at the database level, run the following SQL statement: selectsupplemental_log_data_min from v$database;. If supplemental logging isenabled, the returned value will be YES or IMPLICIT. InfoSphere CDC also requires full supplemental logging at the table level for thosetables you have selected for InfoSphere CDC to replicate using the mirroringreplication method. As with previous versions of the product, you can rely onInfoSphere CDC to handle the supplemental logging. However, you can nowmanage your own supplemental logging requirements and if sufficient, InfoSphereCDC will use them. As before, in a read-only database environment, beforeconfiguring subscriptions that involve tables for mirroring, ensure that you havesufficient supplemental logging enabled for those tables. During InfoSphere CDCsubscription configuration, the application checks to see if the required logging isenabled. If sufficient table supplemental logging is not enabled, then InfoSphereCDC will return errors and does not complete the configuration.

For Direct Mappings InfoSphere CDC will require supplemental logging to be set toat least one of the following levels if you choose to manage your own supplementallogging:

Minimum level supplemental logging and table level supplemental logging on allcolumnsMinimum level supplemental logging and table level supplemental logging withconditional or unconditional log groupsDatabase-level supplemental logging on all columns

For Rules-based mappings, InfoSphere CDC requires: Database-level supplemental logging on keys and changes

To enable supplemental logging at the database level and table level, contact yourOracle database administrator. For more information on the command that enablessupplemental logging, see your Oracle documentation. InfoSphere CDC will not disable supplemental logging, whether or not it wasenabled through InfoSphere CDC. It is the user's responsibility to disablesupplemental logging when they deem it necessary. Related reference: dmshowlogdependency - Show Log Dependency dmshowsupplementalloggingdependency - Show supplemental logging dependency dmreducesupplementalloggingdependency - Reduce supplemental loggingdependency dmsupplementallogevallist - Supplemental logging evaluation list

31

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmshowlogdependency.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmshowsupplementalloggingdependency.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmreducesupplementalloggingdependency.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmreducesupplementalloggingdependency.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmsupplementallogevallist.html

32

1.

2.

Enabling InfoSphere CDC for Oracle databases touse a bulk load refresh If you want InfoSphere® CDC to use a bulk load refresh when applying data to thetarget database, then you must do the following:

Install an Oracle Client on the same server where you have installed andconfigured InfoSphere CDC. The Oracle Client must be able to connect to theOracle database.Add the same TNS names entry for your database to the tnsnames.ora file andselect this database when configuring InfoSphere CDC.

33

Setting the database instance to ARCHIVELOGmode InfoSphere® CDC requires uninterrupted access to Oracle redo logs. Therefore, youmust enable the archiving of Oracle redo logs. Make sure that the source databaseinstance is operating in ARCHIVELOG mode. This lets InfoSphere CDC read datafrom archived Oracle redo logs instead of online redo logs, in the event thatexcessive latency occurs during mirroring. To set the source database instance toARCHIVELOG mode, contact your database administrator. You can also verify ifarchive logging is enabled for the source database by issuing the following SQLstatement: select log_mode from v$database; If archive logging is enabled, thereturned value will be instance to ARCHIVELOG mode. For more information, seeyour Oracle documentation. CAUTION: If you do not set the database instance toARCHIVELOG mode, you may experience data loss. InfoSphere CDC must have direct access to the archive log files. You can installInfoSphere CDC on the same node that has access to the archive log files.However, if your database instance is managed by Oracle Automatic StorageManager (ASM), then you can install InfoSphere CDC any node. Please be awarethat reading archive and redo logs from ASM can be significantly slower thanreading the logs through the file system. If the database produces high volumes oflogs, you should consider multiplexing the logs by configuring a log destinationoutside ASM.

34

InfoSphere CDC and Automatic StorageManagement (ASM) If you are using ASM to manage your Oracle redo log files, the InfoSphere® CDCconfiguration tool requires a user name and password for the ASM instance. TheASM user must have both SYSDBA and SYSASM privileges to log in to ASM. ASM rebalancing, when adding or dropping disks, can be configured to occurautomatically or you can perform it manually. It is important to note that InfoSphereCDC cannot replicate while an ASM rebalancing is taking place. If an automaticrebalancing occurs while InfoSphere CDC is reading the database logs, InfoSphereCDC will stop replication. If possible, you should plan your ASM rebalancing andstop InfoSphere CDC accordingly. If you are deploying InfoSphere CDC in a RAC environment that uses ASM, thereare additional considerations. For more information, see the related topic listedbelow. Related concepts: Oracle ASM considerations in a RAC environment

35

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/oracleracandasmconsiderations.html

Starting the Oracle listener InfoSphere® CDC requires the Oracle listener to connect to the database. You muststart the Oracle listener before installing InfoSphere CDC. For more information onstarting the Oracle listener, see your Oracle documentation. Single Client Access Name (SCAN) configurations are supported.

36

-

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

To set up a remote connection

37

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/setuparemoteconnection.html

1.

2.

3.4.

5.

6.

7.

To set up a remote connection Procedure

Ensure you have installed an Oracle client on the local server and have added theTNS names entry to the tnsnames.ora file.Ensure you have installed and configured an instance of InfoSphere® CDC onthe local server. When configuring InfoSphere CDC, you must specify the sameTNS names entry. Ensure you have started InfoSphere CDC.At the command line on the local server, mount the archive log path from theremote server.If the absolute paths of the directories containing the archive logs differ betweenthe local server and the remote server, then you will need to override the mountpoint during instance configuration.If you are running in archive mode onlyInfoSphere CDC needs access to at least one archive log destination. Pleasemake sure you specified a mount point override for at least one archivedestination if the local path is different from the original path. If you are not running on archive mode only, InfoSphere CDC needs access to atleast one online and one archive destination. If paths on the remote server aredifferent from the ones on the local server, please provide appropriate overrides. At the command line on the local server, mount the redo log path from the remoteserver.If the absolute paths of the directories containing the online logs differ betweenthe local server and the remote server, then you will need to override the mountpoint during instance configuration.

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

38

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/remotelogreading.html

--

--

---

Replicating DDL changes SQL statements are divided into two categories: Data Definition Language (DDL)and Data Manipulation Language (DML). DDL statements are used to describe adatabase, to define its structure, to create its objects and to create the table's sub-objects. The following list provides some examples of types of DDL statements:

Creating tables (CREATE command)Modifying the structure of a table (ALTER command) without deleting and re-creating it, such as adding columns, removing columns or changing columndefinitions (for example, length or default values)Removing objects (such as tables) from the database (DROP command)Partitioning tables (PARTITION command)

DML statements are used to control the information contained within the database.The following lists provides some examples of types of DML statements:

Adding records to a table (INSERT command)Modifying information in a table (UPDATE command)Removing records from a table (DELETE command)

While all InfoSphere® CDC replication engines can replicate DML changes,InfoSphere CDC for Oracle databases version 6.5.1 and later also includes supportfor replicating DDL changes, enabling simplified and more automated changemanagement. Data changes continue to be replicated, but you no longer have tomanually update subscription information when the structure of a table changes ifyou are using the DDL replication feature. For example, new tables and columns areadded according to the DDL statement. Although a wide array of DDL operations exist, InfoSphere CDC replicates onlythose that are related to tables and characteristics of tables; it does not replicate thelarger context of the database. DDL replication is configured in Management Console. For more information, seeReplicating Data Definition Language (DDL) changes.

39

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.mcadminguide.doc/concepts/replicatingddlchangesoverview.html

-

-----

-

------

-

--

Calculating database connections required byInfoSphere CDC for Oracle databases As an administrator, you may find it necessary to calculate how many databaseconnections are needed before installing InfoSphere® CDC on either a source or atarget database. Calculating the upper bound (both permanent and temporary)database connections will help you plan your environment so that it canaccommodate InfoSphere CDC. Calculating connections required by InfoSphere CDC on asource database (22 + G)*I + (4 + A)*S + 3*R + L + CWhere: Note: Enter 0 for any value that does not apply to your deployment of InfoSphereCDC.

G = number of Management Console GUI and CHCCLP scripting applications thatare connected to your instances of InfoSphere CDC.I = number of InfoSphere CDC instances.A = number of RAC nodes if you are not using ASM with Oracle RAC.S = number of subscriptions in all of your InfoSphere CDC instances.R = number of RAC nodes if you are using ASM with Oracle RAC.L = number of subscriptions that contain LOB columns. Note that LOB columns forthe InfoSphere CDC for Oracle databasesand InfoSphere CDC for DB2® for LUWrefer to non-inline LOBS.C = number of InfoSphere CDC command line utilities that you plan to use.

Example: How to calculate required connections for asource database You want to set up InfoSphere CDC in the source environment as follows:

1 instance of Management Console.2InfoSphere CDC instances.2 RAC nodes and you are not using ASM.3 subscriptions.1 subscription that uses non-inline LOB columns.You do not plan to use any InfoSphere CDC command line utilities.

The number of connections required on the source database will be: (22+1)*2 + (4+2)*3 + 1 = 65 You should plan for a maximum of 65 database connections before installingInfoSphere CDC on a source database. Calculating connections required by InfoSphere CDC on atarget database (4+G)*I + 3*SWhere:

G = number of Management Console GUI and CHCCLP scripting applications thatare connected to your instances of InfoSphere CDC.I = number of InfoSphere CDC instances.S = number of subscriptions in all of your InfoSphere CDC instances.

Example: How to calculate required connections for a targetdatabase

40

---

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

The number of connections required on the target database will be: (4 + 1)*2 + 3*3 = 19 You should plan for a maximum of 19 database connectionsbefore installing InfoSphere CDC on the target database.

41

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

42

Interval partitions The replication of tables with interval partitions is supported by InfoSphere® CDCfor Oracle databases only when the tables are part of a Rules-based mapping forDDL Replication. Tables with interval partitions cannot be replicated as part of Direct mappings. For more information on Rule-based mappings and Direct mappings, see Workingwith rule sets.

43

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.mcadminguide.doc/concepts/workingwithrulesets.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.mcadminguide.doc/concepts/workingwithrulesets.html

-

Replicating XA transactions InfoSphere® CDC will replicate transactions involved in XA. InfoSphere CDC willmaintain any data dependencies between individual branches. Replication of XA transactions is supported on the following database versions:

IBM® DB2® LUW version 9.7 and later

44

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

45

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

46

Understanding InfoSphere CDC in an Oracle RealApplication Clusters (RAC) environment To deploy InfoSphere® CDC in an Oracle RAC environment, you can install theproduct on one node in the cluster or on a system outside of the cluster. In bothscenarios you must install InfoSphere CDC on the mount point of a SAN (StorageArea Network) or NFS (Network File System). InfoSphere CDC must have accessto all archived and online redo log files generated by all nodes in the cluster.Installing the product on a system outside of your RAC environment is the optimumconfiguration for failover scenarios where a node may fail. To integrate InfoSphere CDC into your RAC environment, you must first define anOracle service for the RAC environment in the tnsnames.ora file for each RAC node.You can then select this service when creating an instance of InfoSphere CDC foryour RAC environment with the InfoSphere CDC configuration tool. To complete theintegration, you can create an InfoSphere CDC failover script that automates thefailover process. An overview of InfoSphere CDC configuration in a RAC environment (with Active-Passive configuration) is provided in the following diagram:

Behavior of InfoSphere CDC in a RAC environment InfoSphere CDC queries the v$archived_log and v$log Oracle views to locate thedatabase log files and attempts to access the files in the first log destination asdefined in your Oracle database. If the log files are unavailable in the first

47

----

-

destination, InfoSphere CDC proceeds to the next destination until it finds therequired log files. To avoid latency, configure your Oracle database so that the firstdestination contains the required log files. InfoSphere CDC replicates data from all RAC nodes at once and the stream of datafrom individual nodes is sorted (to account for data that is scrambled by logparallelism) and merged together for transaction consistency. InfoSphere CDCdoes not replicate data if the main node is closed. While replicating data,InfoSphere CDC opens connections to the source database and if theseconnections are closed for any reason, InfoSphere CDC ends replication. InfoSphere CDC detects failed nodes in approximately 21 seconds. After the nodefails, InfoSphere CDC continues to replicate data if the Oracle Cluster ReadyServices (CRS) is running and recovers and finalizes the online logs from the failednode. InfoSphere CDC ensures data integrity when replicating data from all othernodes in your RAC environment. Once the node is restored, InfoSphere CDCautomatically starts replicating from the restored node. If the nodes in your RACenvironment have an unbalanced load, InfoSphere CDC may experience a latencyof several times the Oracle checkpoint interval (3 seconds). In this section, you will learn:

Configuring InfoSphere CDC for Oracle databases in a RAC environment Configuring tnsnames.ora for InfoSphere CDC in a RAC environment Oracle ASM considerations in a RAC environment Creating an InfoSphere CDC for Oracle databases failover script for a RACenvironment NFS lockd utility considerations

Related concepts: Configuring instances of InfoSphere CDC for Oracle databases Installing InfoSphere CDC for Oracle databases Related reference: dmconfigurets - Configure InfoSphere CDC

48

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdcforrac.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/definingaserviceintnsnamesora.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/oracleracandasmconsiderations.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/creatingafailoverscript.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/creatingafailoverscript.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/racandnfs.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdc_unixandlinux.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/installingcdc.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmconfigurets.html

-

-

-

-

-

Configuring InfoSphere CDC for Oracle databasesin a RAC environment InfoSphere® CDC can be installed in a node which is part of the Oracle RAC, or itmight be installed on a node outside of the RAC environment. In either case, youmust install InfoSphere CDC on the mount point of a SAN. This configurationassures that, in the case of a failure of one of the nodes of the Oracle RAC,InfoSphere CDC will not require any configuration changes to continue to work. If InfoSphere CDC is running on another node from the failed one, no userintervention is required. Instead, InfoSphere CDC will detect the node failure inapproximately 21 seconds and if Oracle Cluster Ready Services is running andrecovers, InfoSphere CDC will continue to replicate data (including the online logsfrom the failed node). If InfoSphere CDC was running on the failed node, then it must be restarted from adifferent node. No changes are needed because the same binaries andconfiguration metadata is accessible from all nodes. If this is the case, to achieve anoptimal configuration to perform failover of InfoSphere CDC, consider three possiblescenarios:

Active source RAC node failure. In this case, the RAC node where the activeInfoSphere CDC source instance fails.Active target RAC node failure. In this case, the RAC node where the activeInfoSphere CDC target instance fails.Both active RAC nodes (source and target) fail.

In addition, the following needs to be satisfied:

Ability to restart InfoSphere CDC from a different location (that is, InfoSphere CDCbinaries and configuration, and operational metadata need to be accessible).Reachability of InfoSphere CDC by external clients or processes (for example, forsubscriptions targeting the failed InfoSphere CDC instance).

With shared location configuration, restarting InfoSphere CDC requires no specialconfiguration changes. With respect to reachability, consider both the accessibility of the host whereInfoSphere CDC is running, and accessibility of the database. To ensureaccessibility of the host, create an entry in the /etc/hosts file for each node involvedin the environment using a common host name pointing to the IP address of thecurrent node. For example, in case of a two-node RAC environment, the /etc/hostsfile in the first node should have the following entry: #cdc_host In the second node, the /etc/hosts file should have the following entry: #cdc_host Thus, the cdc_host host name is invariable, but is actually pointing to the properphysical IP address, depending on which node InfoSphere CDC is running. Toensure accessibility to the database is to follow a similar strategy. A special entry intnsnames.ora file should be created using the common host name: SID_CDC= (DESCRIPTION=

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

(CONNECT_DATA=(server=DEDICATED)49

(SERVICE_NAME=SID)

)

) Using this configuration method, when InfoSphere CDC tries to connect to thedatabase it will connect to the Oracle instance listening in port 1521 on hostcdc_host, and cdc_host will point to the proper IP address depending on the nodewhere it is running. With the this approach, regardless which node fails, and which InfoSphere CDCsource or target have to failover, no changes in configuration are needed. All that isrequired is restarting InfoSphere CDC from the new location and perform somecleanup such as removing transaction queues, and cleaning staging store afterrestarting the instance from the new location. The same approach should be used to ensure accessibility from clients such asManagement Console. When defining datastores in Access Server, use host namesthat, in case of failovers, can be easily changeable to the new real physical location.Once the IP switch is complete, restart Access Server. No other configurationchange is needed to operate InfoSphere CDC.

50

---

Configuring tnsnames.ora for InfoSphere CDC in aRAC environment If you are using Oracle RAC without ASM, InfoSphere® CDC requires an identicalTNS entry in the tnsnames.ora file on each RAC node. InfoSphere CDC uses theTNS entry to connect to your RAC environment on the current active node. Forexample, your TNS entry may look something like this: CDC_SID =

(DESCRIPTION =

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

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = racsid.racsystem.com)

(INSTANCE_NAME = instancesid)

)

) Where:

racsystemvip—virtual IP for your RAC system.racsid.racsystem.com—global service name for your RAC system.instancesid—unique name of this instance in your RAC system.

When you are ready to create an InfoSphere CDC instance for your RACenvironment with the InfoSphere CDC configuration tool, select the global servicename that you defined in the tnsnames.ora file for InfoSphere CDC when promptedto select a TNS name. You must select a single node (considered the main node byInfoSphere CDC), not the entire RAC instance. Related concepts: Creating an InfoSphere CDC for Oracle databases failover script for a RACenvironment Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC)environment Configuring instances of InfoSphere CDC for Oracle databases Installing InfoSphere CDC for Oracle databases Related tasks: To add a new instance of InfoSphere CDC for Oracle databases with log shippingusing Data Guard To add a new instance of InfoSphere CDC for Oracle databases that reads logslocally To add a new instance of InfoSphere CDC for Oracle databases with manual logshipping To add a new instance of InfoSphere CDC for Oracle databases that reads logsremotely Related reference: dmconfigurets - Configure InfoSphere CDC

51

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/creatingafailoverscript.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/creatingafailoverscript.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/installinginanoraclerealapplicationclustersracenvironment.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/installinginanoraclerealapplicationclustersracenvironment.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdc_unixandlinux.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/installingcdc.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_DataGuardllogshipping_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_DataGuardllogshipping_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_locallogreading_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_locallogreading_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_manuallogshipping_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_manuallogshipping_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_remotelogreading_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/tasks/addanewinstance_remotelogreading_unix.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmconfigurets.html

52

Oracle ASM considerations in a RAC environment If you are using ASM in your RAC environment to manage your Oracle redo logfiles, the InfoSphere® CDC configuration tool requires that you specify the OracleSID of the local node where InfoSphere CDC is installed. The configuration tool canbe launched from the command line by issuing the dmconfigurets command. The local Oracle SID is required because ASM does not allow remote connectionsfrom Oracle client software such as SQL*NET. You must be logged in to the samehost where ASM is installed to connect to ASM. You should also note that in Oracle version 11g, the ORACLE_HOME environmentvariable for ASM is different from ORACLE_HOME for the database. You shouldtake this into consideration when configuring your RAC environment and creating aninstance of InfoSphere CDC. Related concepts: Configuring instances of InfoSphere CDC for Oracle databases InfoSphere CDC and Automatic Storage Management (ASM) Related reference: dmconfigurets - Configure InfoSphere CDC

53

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdc_unixandlinux.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/automaticstoragemanagement.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmconfigurets.html

---

--

---

-

-

Creating an InfoSphere CDC for Oracle databasesfailover script for a RAC environment If an Oracle RAC node fails but the system containing the node is still responsive,you can use a recovery script for InfoSphere® CDC that automates the followingtasks:

Stop replication on all subscriptions with the dmendreplication command.Shut down all InfoSphere CDC processes with the dmshutdown command.Modify the INSTANCE_NAME parameter in the tnsnames.ora file to point to thenext available RAC node.If required, restart the Oracle service listener.Delete the following staging area files in the InfoSphere CDC installation directory:

/txnstore/txq*/stagingstore/*/tmp/*

Restart the InfoSphere CDC instance on a different RAC node with the dmts32 ordmts64 commands.Restart replication on all subscriptions with the dmstartmirror command.

Related concepts: Configuring tnsnames.ora for InfoSphere CDC in a RAC environment Understanding InfoSphere CDC in an Oracle Real Application Clusters (RAC)environment Configuring instances of InfoSphere CDC for Oracle databases Related reference: dmendreplication - End replication dmshutdown - Shut down InfoSphere CDC dmts32 - Start InfoSphere CDC dmts64 - Start InfoSphere CDC dmstartmirror - Start mirroring

54

https://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/definingaserviceintnsnamesora.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/installinginanoraclerealapplicationclustersracenvironment.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/installinginanoraclerealapplicationclustersracenvironment.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/concepts/configuringcdc_unixandlinux.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmendreplication.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmshutdown.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmts32.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmts64.htmlhttps://www.ibm.com/support/knowledgecenter/SSTRGZ_10.2.1/com.ibm.cdcdoc.cdcfororacle.doc/refs/dmstartmirror.html

NFS lockd utility considerations If you have installed InfoSphere® CDC on a NFS share and you are using the lockdutility (network lock daemon) that is part of the NFS lock manager, InfoSphere CDCmay be adversely affected by the locking semantics used by this utility. An abnormalshut down of the active node may result in a lack of synchronization between theNFS daemon and the network lock daemon. This situation may affect the ability ofInfoSphere CDC to acquire file locks during start up on the new active node. Toresolve this issue, you must ensure that both daemons are synchronized and deletethe TSLOCK file in the InfoSphere CDC/var directory.

55

---

-

-

-

--

Configuring InfoSphere CDC for Oracle databasesfor OS (operating system) clustering (UNIX andLinux) InfoSphere® CDC supports Active/Passive two-node clusters on the UNIX andLinux platforms. Clustering provides continuous access to resources in the event ofa hardware failure, software failure, or some other interruption. To implement InfoSphere CDC clustering support in your environment, you mustcomplete all of the following prerequisite tasks. Note: Prerequisites that only apply to InfoSphere CDC as a clustered source or aclustered target are specified.

Install InfoSphere CDC on the shared drive of the cluster.Add a new instance of InfoSphere CDC.Ensure that the server port you specify during configuration of the instance isavailable and persistent on both nodes of the cluster. InfoSphere CDC listens onthis port.Ensure that all of the database logs required for replication are available. Thisprerequisite only applies to InfoSphere CDC as a clustered source.Ensure that every InfoSphere CDC source that connects to the target sees thetarget in the same way. The target must have a clustered IP address or use thesame host name for both nodes of the cluster. This prerequisite only applies toInfoSphere CDC as a clustered target.Optionally, schedule a regular backup of your InfoSphere CDC metadata andevent log messages. Note that metadata will only change when you add or modifysubscriptions. You can find more information about this prerequisite in the failoverprocedure for InfoSphere CDC in this section.

Note: You can run the dmshowlogdependency command with the –i flag to list thedatabase logs required for replication. In this section, you will learn:

Performing a forced or manual failover of InfoSphere CDC for Oracle databases Preparing for a failover of InfoSphere CDC for Oracle databases

Related concepts: Configuring InfoSphere CD