Overview of Compare and Repair
In addition to regularly monitoring the health and performance of replication, it is good practice to compare the source and target data on a regular schedule to ensure that all of the data is still synchronized. Post detects out-of-sync conditions for the rows that it is processing, but there can be hidden out-of-sync conditions. Examples of these are DML applied on the target or an incomplete backup restore. These conditions can go undetected until Post applies an operation that affects the out-of-sync row. The SharePlex Compare and Repair feature enables you to detect hidden out-of-sync conditions and then repair them.
Note: To understand how hidden out-of-sync conditions can occur, see Understand the concept of synchronization.
SharePlex provides the following commands for comparing and repairing out-of-sync data:
- compare: Compares an individual source table to its target table or compares a wildcarded set of tables in the same schema.
- compare using: Takes input from a file to compare some or all of the tables in the active replication configuration.
- repair: Repairs an individual target table or a wildcarded set of tables in the same schema.
- repair using: Takes input from a file to repair some or all of the tables in the active replication configuration.
Supported sources
Oracle
Supported targets
Oracle
Overview of the server and client processes
The compare and repair commands are always issued on the source system. The command spawns a server process on the source system and then sends a message through the SharePlex queues to spawn a client process on the target system.
The server and client processes then begin communication with each other. Depending on the syntax options included in the command, the processes may be multithreaded on the target. The two processes compare the source and target tables and then write the results to a log file.
How locks are managed
During a comparison, SharePlex obtains a brief exclusive lock on the source table to get read consistency for its row selection. On the target system, SharePlex obtains an exclusive lock on the target table and retains the lock for the duration of the comparison of that table. This prevents the table from being modified while SharePlex is processing it.
After locking the tables, the rows are read and sorted in identical fashion on both source and target. Next, a batch of rows is read and a check sum is performed. If the check sums match, another batch of rows is processed the same way. If any check sums do not match, the processes determine which rows are out-of-synchronization and then they create the SQL statements to repair them. If a repair command is issued, SharePlex repairs the rows.