Srinivasan R Mottupalli

1. What is Latency in Change Data Capture? Latency information is normally for Mirroring subscription. As InfoSphere CDC measures latency as the amount of time that passes between when data changes on a source table and when it changes on the target table. For example, if an application inserts a row into the source table at 10:00 and CDC applies that row to the target able at 10:15, then the latency for the subscription is 15 minutes. 2. What is in-scope and out-of-scope tables in InfoSphere CDC terminology? The tables are inscope tables if they are replicated to the target by InfoSphere CDC. The tables are out-of-scope when those tables are not part of any replication. 3. How to ignore error that occurs during refresh/mirrorring? Prior 6.3 D_MIRROR_REFRESH_ERROR_STOP=OFF - refresh continues after an error has occurred. D_MIRROR_MIRROR_ERROR_STOP=OFF - mirroring continues after an error has occurred. Post 6.3 Set the following 2 system parameters via Management Console. mirror_end...

For any read-only DB connections (to Oracle) InfoSphere CDC does additional checking to see if the supplemental logging for the all the tables that are relevant to the subscriptions. This is an initial ONE TIME sanity check for any read-only connections when we change from REFRESH mode to MIRROR mode. InfoSphere CDC has the system parameter called " read_only_check_supplemental_logging " to enable or disable this ONE TIME sanity check because some customers can enable the supplemental logging ONLY for few selected columns. For such customers, this system parameter helps to by-pass this sanity check. After the instance goes to MIRROR mode, CDC does not look back this system parameter. So, it is harmless to keep this system parameter around OR one can choose to unset this parameter after CDC goes to the MIRROR mode. When this sanity check is disabled, it is assumed by InfoSphere CDC that the source database is providing the supplemental logging for all the columns in the tabl...

When Oracle 11g is used as a source for InfoSphere CDC, there was an observation that the control files are hammered with I/O at much higher frequency than that of Oracle 10g, causing the overall degrade in system performance. Following page gives quite a good amount of details about how Oracle uses control files and also provides the way to diminish this problem. http://www.confio.com/English/Tips/Control_File_Reads_Writes.php Before attempting to do anything with InfoSphere CDC, try doing the recommendation given in the above URL.

InfoSphere Change Data Capture (ISCDC) which is part of IBM InfoSphere Data Replication has the concept of Restart Position via bookmark which keeps advancing as the records are replicated and applied at the target that helps tracking CDC to keep the record of how much data have already been replicated so that CDC when restarted can start from this position. There was a customer using Oracle as a source from which the data was replicated, and it was observed that InfoSphere CDC was holding up transaction inspite of not having any open transactions in the V$TRANSACTION. Later it turned out to be that the open transaction was identified from the GV$TRANSACTION table. These are global transactions that can occur in the Oracle RAC environment. So, InfoSphere CDC holding up the transactions were found to be very much legitimate. Long transactions in the database (and hence restart position not advancing in the ISCDC) sometime is a concern because when ISCDC is to be restarted for som...

Although InfoSphere Change Data Capture does not allow mixed mode as of today, it has a flexibility to accomplish the mixed mode of log shipping by enabling the manual mode with a simple script. Automatic Mode : In automatic mode, ISCDC automatically reads the appropriate archived log files and replicates Manual Mode : In this mode, ISCDC allows user to register the available log file via the backend command " dmarchivelogavailable ". Such manually registered log files can be unregistered using " dmarchivelogremoved " command. This comes very handy when the user environment needs to ship the archived log files via Oracle Data Guard or by manually copying the files and ISCDC is expected to read and replicates the data. A simple ever running shell/perl script or any program can be written to keep monitoring for the new completed files and can keep registering the log files using the back-end command. For more information refer infocenter

When I count all my blogs right from the beginning of my career which is around 17 years ago up til now, this is my 2nd blog :-) I think, I have been too busy developing the database functionalities and tools development. I have spent more than a decade in RDBMS development (Integra4, Informix, Partly DB2). Now I work on the change data capture technology and care to sniff all the logs to safely get them to the other side. I hope, I don't stop at my 2nd blog and I wish to post some useful topics going forward.