This section provides instructions and guidelines on how to prevent or troubleshoot common problems while configuring or using Universal Cache.
▪Dependencies between components used in replication
▪Making changes to replication subscriptions
▪Subscriptions fail after performing hsb netcopy followed by a switchover
▪IBM InfoSphere CDC for solidDB® connection to solidDB® server times out
▪Bidirectional replication does not work between solidDB® and DB2®
Initial connections are not successful
The components for Universal Cache must be installed and configured in the order described in section Overview of installation and configuration steps. Review the steps below and ensure that the installation and configuration steps were followed.
Installation and configuration order
▪Frontend solidDB® server
▪IBM InfoSphere CDC for solidDB®
▪Backend data server
▪IBM InfoSphere CDC for the backend data server
▪Access Server
▪Management Console
Dependencies between components used in replication
To set up replication between databases, you need define and create various entities and components which are dependent on each other. These entities and components must be created in the following order and modified or deleted in the reverse order.
▪Databases
▪IBM InfoSphere CDC instances
▪Datastores
▪Subscriptions
▪Table mappings
Making changes to replication subscriptions
If you need to make changes to your replication subscriptions, you must first end replication on your subscriptions.
Subscriptions fail after performing hsb netcopy followed by a switchover
In High Availability (HotStandby) configurations, subscriptions where the solidDB® database is the source datastore might fail if a switchover is performed shortly after hsb netcopy.
The subscriptions might fail, for example, in the following cases:
After a failure or a maintenance break, primary server (node 1) and secondary server (node 2) are synchronized using ADMIN COMMAND 'hsb netcopy'.
Replication continues against the primary server (node 1) for few transactions.
The primary server (node 1) fails and switchover changes the secondary server (node 2) to be the new primary server.
Subscriptions fail and replication against the new primary server (node 2) cannot be restarted.
Causes
The command ADMIN COMMAND 'hsb netcopy' does not copy any log files. Subsequently, because IBM InfoSphere CDC replication is asynchronous in nature, IBM InfoSphere CDC for solidDB® might not have processed all the transactions up to the point from which the hsb netcopy was made. This means that the log position IBM InfoSphere CDC for solidDB® tries to use after the switchover might not be valid – the log entry for the last transaction on node 1 before the hsb netcopy might not exist on the new primary (node 2).
Workaround
To ensure that IBM InfoSphere CDC for solidDB® has access to a valid log entry in the new primary server (node 2) after a switchover:
▪Before performing hsb netcopy, copy the log files from the primary server (node 1) to the secondary server (node 2). This ensures that IBM InfoSphere CDC for solidDB® has access to the log positions of the transactions that were executed before the hsb netcopy was made.
or
▪Do not perform switchover shortly after hsb netcopy or wait for several transactions to be replicated to the backend database before performing the switchover. This ensures that log positions in the primary server (node 1) and secondary server (node 2) are synchronized.
or
▪If the switchover has already taken place (for example, due to a failure of node 1):
Recover the old primary server (node 1).
Perform a switchover to return the old primary server (node 1) back to a primary server.
Restart replication on the subscription.
Before performing another switchover (to make node 2 the new primary server), wait for several transactions to be replicated. This ensures that log positions in the primary server (node 1) and secondary server (node 2) are synchronized.
IBM InfoSphere CDC for solidDB® connection to solidDB® server times out
IBM InfoSphere CDC for solidDB® connections to the solidDB® server can be idle for long periods of time, causing connection idle timeouts. By default, the solidDB® server timeout for idle connections is set to 480 minutes (specified with the Srv.ConnectTimeOut parameter).
Workaround:
Set the connection idle timeout for the IBM InfoSphere CDC for solidDB® connection to infinite by using the non-standard solidDB® JDBC connection property solid_idle_timeout_min=0. The IBM InfoSphere CDC for solidDB® connection settings are specified with the IBM InfoSphere CDC configuration tool (dmconfigurets), using the Database area > Advanced button in Windows operating systems or the Configure advanced parameters > Modify settings option in Linux and UNIX operating systems.
Note The timeout setting specified for the IBM InfoSphere CDC for solidDB® instance does not impact the server setting (Srv.ConnectTimeOut) for other connections.
Bidirectional replication does not work between solidDB® and DB2®
Symptom
Bidirectional replication between solidDB® and DB2® for Linux, UNIX, and Windows does not work. You can create the subscriptions and table mappings successfully but data changes in the solidDB® database are not replicated to the DB2® database.
In some cases, starting replication (Start Mirroring) fails with the following type of error message:
Error 1465 BIDI5 Mar 13, 2013 3:04:11 PM
--- Subscription BIDI5 is terminating abnormally.
Error 1713 BIDI5 Mar 13, 2013 3:04:11 PM
IBM InfoSphere Change Data Capture to BIDI5 is initiating shutdown due to failure on the local system. See the previous messages for additional information.
Error 2913 BIDI5 Mar 13, 2013 3:04:11 PM LOAD operation is not supported by IBM InfoSphere Change Data Capture. Please refresh the the table [ DB2ADMIN.T42] when LOAD operation ends.
Recovery
To use bidirectional replication with DB2® for Linux, UNIX, and Windows, set the IBM InfoSphere CDC for DB2® system parameter ddl_awareness to false.
You can set system parameters in two ways:
▪On the computer where your IBM InfoSphere CDC for DB2® replication engine is installed, issue the following command:
dmset -I <INSTANCE_NAME> ddl_awareness=false
For example:
dmset -I backend_DB2 ddl_awareness=false
▪In the Configuration perspective of the Management Console, right-click on the datastore and select Properties > System Parameters. Click Add and enter the parameter name and its value (ddl_awareness=false).