Limitations and Workarounds - connect_cdc_mimix_share

Connect CDC Limitation and Work-arounds

Connect CDC has the following restrictions:

Automatic target table limitations:
Apply Index should not be selected for Teradata, if the source table has a non-primary index on its first column.
The maximum supported length of a character value that can be updated into a Teradata target table is 32,000 bytes. If the character value is greater than 31,000 bytes, then the mapping in which the table is defined, must be specified as using prepared statements, which is the default.
Connect CDC cannot replicate database column values longer than 2 GB. If you connect to a very large model, parsing may take a long time.
Currently, a manual resolution of a collision is not available.
A denial-of-service attack on Connect CDC Listener can cause it to shutdown unexpectedly. A denial-of-service attack is an attack on a network that floods it with useless traffic. Use encryption to minimize the risk.
A refresh on a journal list can fail on a AS/400 V7R1 server if the list had been previously created on V6 or V5. This error displays when you click Refresh list on the Journal Operations dialog or on the Process Definition Properties dialog. This is because IBM changed the internal system record format (made it longer) that is used to write records to a file with the “outflow” format. This error occurs when you have a metabase on a release previous to V7R1, where the DSPOBJD file still exists with the older, shorter format. The workaround is to remove the DSPOBJD (older) file and then refresh the journal list.
Note: This error only occurs if a DSPOBJD file still exists from a prior version. In addition, you only need to manually delete the DSPOBJD file one time.

Gate Conditions

Whether modular operator % is converted during the execution of a gate condition on a Copy request depends on whether the database supports the use of %.

Likewise, the conversion of ! to NOT during the execution of a gate condition on a Copy request depends on the database. If your gate conditions contain modular operators, check your database syntax to see if they are supported.

Bi-directional Replication

To avoid unnecessary collisions with bi-directional replication, the following are recommended:

Hosts participating in bi-directional replication must have synchronized clocks.
The time a change is made affects which change wins during automatic collision resolution.
In the case of log-based Change Selectors, they must be kept running, if possible, even when requests are stopped.

If a Change Selector has been stopped for any length of time, start the Change Selector before starting the request. Give the Change Selector time to catch up before the Connect CDC apply component begins applying updates from other source tables.

Log-based change capture will always have a time lag since meta-information is not captured at the same time the changes are made. There is a time difference between when the update is made and when it can be read from the log. Thus, meta- information cannot be updated until you can read it in the log. This may cause a problem; for example, a change could be captured and sent to its target tables even though an apply component already updated the same row in the time elapsed since the change was made.

Connect CDC MonCon

Some limitations exist specifically in Connect CDC MonCon:

When running a Synchronization request, the data movement status may not always match the source status where more than one target server exists.
For example, during the copy phase of synchronization, the status would be indicted this way:

When one target finishes, the status under data movement changes from copy to replicate, which matches the state of the target that finished, even though the source continues to remain in the copy state until all targets are complete.
A bidirectional request may appear to be active on a host even before capture has been enabled for all tables belonging to the request on that host. This happens because currently Connect CDC can display a request that is active but cannot indicate the direction in which the request is active.

Consider a bidirectional request between two hosts X and Y. When the request is started and data starts flowing from X to Y, the request will appear to be active on Y even though capture has not yet been enabled on all tables on Y. The request really is active on Y but at this point Y is only acting as a target, not as a source. Capture eventually gets enabled on all tables on Y and it starts acting as a source in addition to being a target.

Note: Unidirectional requests do not exhibit any such problem since a host acts as either a source or a target, not both.

When you perform a Model Update for an Informix source with data being inserted into the affected tables, you may see the following:
The envelope temporarily changes from "open green" to "open red" and then changes back to "open green" in a few seconds during Model Update.
You may see error messages:

For an incremental Model Update, the messages may point to rp_crq. For a full Model update, the messages may point to rp_trans.

<machine name>: 20040628 103729.695 [ERROR] Unable to get next row from capture queues.
                  <machine name>: 20040628 103914.446 [ERROR] Error executing query statement 'select
                  {+INDEX(omnirep:rpuser.rp_crq zrp_crq)} rp_m_dbid, rp_m_tran_id, rp_m_tran_sq, rp_m_type, rp_m_owner, rp_m_table, rp_o_dbid, rp_o_tran_id, rp_o_tran_sq, rp_r_tstamp, rp_1st_shdw from omnirep:rpuser.rp_crq where rp_m_tran_id between ? and ? and rp_r_tstamp between ? and ? and
                  rp_request_id = 18 order by rp_m_tran_id, rp_m_tran_sq':
                  <machine name>: 20040628 103914.456 ERROR DETAILS >>> [Error:-710] [State:IX000] Message: Table (rpuser.rp_crq) has been dropped, altered or renamed.
                  However, the Model Update process is working correctly; Model Update is not affected.

OmniConsole

An unknown state is represented in the following manner:

“inactive” for a Copy request
“inactive and capture disabled” state for Replication request
“inactive and capture disabled” state for Synchronization request

WebMonCon

Name	Description
Port	If another application (such as Oracle) is using port 8080, WebMonCon does not start. Change the port that the Jetty server uses by changing the startjettyserver.bat (or the .sh) script from: *java -jar start.jar* - to (to use 5700 as the port number): *java -Djetty.port=5700 -jar start.jar* - You can now start WebMonCon in your browser using: `http://<system name>:5700/WebMonCon`
Logging	If you need to turn on logging for debugging purposes, contact your customer service representative for help in choosing a category.