Compare Data

Compare Data checks that the Target Database holds the same data as the Source Database while the replication keeps running. No data is exported or copied: a compare process calculates a hash for every row it reads in the Source Database, the Apply Process calculates the hash of the same row in the Target Database and the two hashes are compared. The rows that differ, or are missing in the Target Database, are listed in a report and can be repaired with one click.

The feature lives in one window, the “Compare” window of a Capture Process. This page shows the window and explains how to read its report. How a comparison works is explained in How Data Comparison Works, what it needs and what it cannot compare in Requirements and Limits. The two pages below describe the work step by step: Task Configuration (create, change and delete the tasks) and Tasks Control (run, stop, resume, compare selected tables or only the changes, and repair).

Open the Compare window

Click “Compare” on the card of a Capture Process on the dashboard. The window belongs to that Capture Process and shows its comparison tasks, one tab for each of them. The same functions are available in repcli and in the REST API (see Data Comparison).

How a comparison works

Three parts of Repstance work together. The compare process is a separate process of the Repstance server, started with the task, but it is integrated with the Capture Process: it reads the rows of the Source Database, calculates a hash of every row and hands the result over through the Capture Process. The Capture Process carries it in the stream of the replicated changes and the Apply Process compares the hashes with the Target Database. This is why the Capture Process and the Apply Process have to be running while a task runs. The steps, the chunks and the way a row is hashed are explained in How Data Comparison Works.

The terms

A task is a named list of tables with the settings for each of them. A Capture Process can have several tasks, each is a tab of the Compare window. The rows of a table are read and compared in portions called chunks. A row that exists in both databases but has different values is a failed row, a row that exists in the Source Database but not in the Target Database is a missed row, and the repair brings both in line with the Source Database. “Data Validation %”, the key of a table and the other terms are explained in How Data Comparison Works and Requirements and Limits.

What the report shows

The report is the main part of the window. It shows the task of the selected tab. The numbers in the picture are explained below it:

The columns of the table (9):

Run modes at a glance

The “Run” button opens a dialog with the run modes that fit the state of the task: “Full Validation”, “Resume” and “Incremental”. Untick tables to compare only some of them, click “Stop” to stop a running task and “Repair” to fix the differences. The buttons and the dialogs are described in Tasks Control, the run modes with their numbers in repcli and in the REST API in Start/Stop Task.

Good to know

The Capture Process and the Apply Process have to be running while a task runs, and only the tables that the Capture Process replicates can be compared. A task cannot be added or changed while a comparison is running, and “Incremental” needs the trail files of the Capture Process (see Tasks Control). What a comparison needs, what it compares and what it does not report is listed in Requirements and Limits. The same functions are available from the command line and in the REST API, see Data Comparison.