Checking Consistency 4and Repairing Inconsistent Rows

To perform a consistency check, use the cdr check replicate or cdr check replicateset command. Use the –repair option to repair the inconsistent rows. A 4consistency report is displayed for your review.

You can perform a consistency check and synchronization on a single replicate 4or a replicate set. When you synchronize a replicate set, Enterprise Replication 4synchronizes tables in an order that preserves referential integrity constraints 4(for example, child tables are synchronized after parent tables).

The following restrictions apply to performing consistency checking:

4
• The Enterprise Replication network connection must be active between the 4Connect server, reference server and the target servers while performing consistency 4checking and repair.
4
• The replicate must not be in a suspended or stopped state during consistency 4checking.
4
• The replicate must not be set up for time based replication.

If synchronization during a consistency check cannot repair a row, the 4inconsistent row is recorded in an ATS or RIS file. For more information, 4see Repairing Failed Transactions with ATS and RIS Files.

Preparing the checksum 4Support Functions

Before you can use the cdr check replicate command, 4you must prepare the Enterprise Replication checksum support functions.

4
1. Download the checksum support functions from the IBM developerWorks Website: http://www.ibm.com/software/data/developer/informix.
4
2. Compile the function code according to the platform-specific instructions 4listed in the accompanying readme file. You can read this file prior to downloading 4the function code.
4
3. Register the checksum support functions in each database that you plan 4to include in consistency checking. You can register the functions using the 4BladeManager utility or CREATE FUNCTION statements.

Interpreting the Consistency Report

Inconsistencies listed in the consistency report do not necessarily indicate 4a failure of replication. Data on different database servers is inconsistent 4while replicated transactions are in progress. For example, the following 4consistency report indicates that two rows are missing on the server g_serv2:

------   Statistics for repl1 ------
4Node                  Rows     Extra   Missing  Mismatch Processed
4---------------- --------- --------- --------- --------- ---------
4g_serv1                 67         0         0         0         0
4g_serv2                 65         0         2         0         0
4
4WARNING: replicate is not in sync

The missing rows could be in the process of being replicated from g_serv1 to g_serv2.

If you choose to repair inconsistent rows during a consistency check, the 4report shows the condition of the replicate at the time of the check, plus 4the actions taken to make the replicate consistent. For example, the following 4report shows two missing rows on g_serv2 and that two 4rows were replicated from g_serv1 to correct this inconsistency:

------   Statistics for repl1 ------
4Node                  Rows     Extra   Missing  Mismatch Processed
4---------------- --------- --------- --------- --------- ---------
4g_serv1                 67         0         0         0         2
4g_serv2                 65         0         2         0         0
4
4WARNING: replicate is not in sync

The warning indicates that inconsistencies were discovered. The report 4does not indicate whether the replicate became consistent after the repair 4process.

The verbose form of the consistency report also displays the primary key 4for each inconsistent row.

For more information about the contents of the consistency report, see cdr check replicate.