transfer-reconciliation

Verify post-transfer row count parity and target table accessibility.

1.5k|222|Updated Jul 4, 2025
One-click install
npx skills add https://github.com/Datus-ai/Datus-agent --skill transfer-reconciliation
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: transfer-reconciliation
Source: https://github.com/Datus-ai/Datus-agent/tree/main/datus/resources/skills/transfer-reconciliation
Command: npx skills add https://github.com/Datus-ai/Datus-agent --skill transfer-reconciliation

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

After completing a data transfer or migration, manually verifying that all rows were moved correctly is time-consuming and prone to error, especially for derived queries or large datasets where re-scanning the source system is costly or impossible.

Core Features & Use Cases

  • Row Count Parity Check: Automatically compares tool-reported source and transferred row counts without re-querying the source system, eliminating unnecessary load on production data sources.
  • Target-Side Validation: Runs a lightweight COUNT(*) query on the target table to confirm the actual row count matches the transferred count, catching any issues with the transfer process itself.
  • Advisory Target Sample: Optionally reads a small sample of rows from the target table to confirm it is fully queryable and accessible after the transfer.
  • Use Case: For example, after transferring aggregated customer sales data from a production PostgreSQL database to a ClickHouse analytics warehouse, use this skill to automatically confirm row counts match and the target table is accessible without manual querying.

Quick Start

Use the transfer-reconciliation skill to validate row counts and target accessibility for your most recent data transfer run.

Frequently Asked Questions about transfer-reconciliation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate row count parity after a data migration without re-scanning the source system?

To validate transfer row count parity without re-scanning, compare tool-reported source and transferred row counts, then execute a lightweight COUNT(*) query on the target table to confirm the actual rows match.

What is post-transfer target sanity check for data migration workflows?

A post-transfer target sanity check confirms deliverable usability by executing target-side count queries and optionally sampling rows to ensure the migrated table is fully queryable and accessible.

How can I confirm my target table is queryable after transferring data to an analytics warehouse?

Confirm target table queryability by optionally reading a small sample of rows from the target table, verifying accessibility after the data transfer without placing unnecessary load on production sources.

Does transfer reconciliation work for validating large datasets moved to ClickHouse?

Yes, transfer reconciliation works for large datasets moved to ClickHouse by comparing reported row counts and running target-side sanity checks, avoiding costly source system re-queries.

What's the best way to verify data transfer validation without impacting production databases?

The best way to verify data transfer validation without impacting production databases is to compare tool-reported counts and run lightweight target-side count queries, eliminating source re-query load.

When should I not use row count parity checks for transfer validation?

Row count parity checks are limited to confirming counts and target accessibility; they should not be used when deep content verification, schema validation, or source-side row-level comparison is required.