A copy that "finished without errors" can still be wrong: a batch that failed halfway, a filter that was too strict, a row updated at the source while the job was running. Counting rows on both sides won't tell you which ones. Comparing by key will.
Compare by key, not by count
dbSlice's Compare reads the source and the target ordered by the same key and reports three kinds of difference:
| Difference | What it usually means |
|---|---|
| Missing in target | A batch failed, a filter excluded it, or it was inserted after the copy |
| Extra in target | Deleted at the source, or inserted directly in the target |
| Different values | Updated at the source after the copy, or changed by a type conversion |
With the column mapping you compare only the columns that matter, so a column that is expected to differ (a load timestamp, for example) doesn't flood the report.
Save the keys, fix only those rows
Since 2.3.20260903 the divergent keys can be saved to a text file. That list is the input for the fix:
- Open the key list.
- Use it in a
SELECT … WHERE id IN (…)as the source of a sync. - Upsert just those rows into the target.
On a table with hundreds of millions of rows, re-syncing a few hundred keys takes seconds; reloading the table can take hours.
Make it a habit
- Compare after every rehearsal, not only on cutover night.
- Freeze a boundary (a timestamp or a maximum key) when the source is still receiving writes, or every difference
may be timing, not a defect.
- Save the comparison as a status job and run it from the command line, so the check repeats the same way
every time.
More in the SQL Server to PostgreSQL sync guide.
