-
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