移行後の検証(行数/チェックサム)

Oracle

-- Compare row counts on source and target
SELECT 'customer' table_name, COUNT(*) row_count FROM customer;

-- To find content differences at object level, DBMS_COMPARISON (via db link)
BEGIN DBMS_COMPARISON.CREATE_COMPARISON(
  comparison_name => 'COMPARE_CUSTOMER',
  schema_name => 'SHOP', object_name => 'CUSTOMER',
  dblink_name => 'TARGET_DB'); END;
/
-- SELECT DBMS_COMPARISON.COMPARE('COMPARE_CUSTOMER', scan_info) FROM dual;

最も手早い確認は、両側でテーブルごとに COUNT(*) を比較すること。行レベルの実際の内容の差異を見つけるには DBMS_COMPARISON パッケージを使用する。データベースリンク経由でソースとターゲットのテーブルを行ごとに比較し、差異を報告/収束できる。チェックサムには ORA_HASH または STANDARD_HASH で列のダイジェストを取得できる。

PostgreSQL

-- Row count
SELECT count(*) FROM customer;

-- Ordered digest (checksum) of the whole table content — compare on both sides
SELECT md5(string_agg(t.row_md5, '' ORDER BY t.row_md5)) AS digest
FROM (SELECT md5(customer::text) AS row_md5 FROM customer) t;

最初の手順は各テーブルの count(*) を比較すること。内容の検証では、各行のテキスト表現の md5 を取り、ソート順に連結して再度ハッシュする。これにより両側で順序に依存しないチェックサムが得られる。大容量データでは、変更され得る列/キー列のみでダイジェストを取る。再現性のために PK での並べ替えが重要。

MySQL

-- Built-in table checksum (run on both servers and compare)
CHECKSUM TABLE customer;

-- Row count
SELECT COUNT(*) FROM customer;

-- Preferred tool for live/large environments (compares row chunks online):
-- pt-table-checksum h=source,D=shop  (Percona Toolkit)

MySQL では CHECKSUM TABLE がテーブル内容の単一のチェックサムを返す。ソースとターゲットで実行して比較する(エンジン/バージョンが同じである必要がある)。行数には COUNT(*) を使用する。稼働中の本番環境やレプリケーションの整合性確認では、Percona Toolkit の pt-table-checksum が業界標準。チャンク単位で、オンラインかつ低負荷で比較する。

SQL Server

-- Full row-level comparison (official tool that produces differences)
tablediff -sourceserver S1 -sourcedatabase shop -sourcetable customer \
  -destinationserver S2 -destinationdatabase shop -destinationtable customer

-- Quick aggregate checksum (single query, compare on both sides):
SELECT COUNT_BIG(*) row_count, CHECKSUM_AGG(BINARY_CHECKSUM(*)) digest FROM dbo.customer;

SQL Server で行レベルの差異を見つける公式のコマンドラインツールは tablediff(どの行が追加/変更されたかを報告し、オプションの -f で修正スクリプトを書き出す)。手早い全体確認には、CHECKSUM_AGG(BINARY_CHECKSUM(*)) が単一のテーブルダイジェストを返す。両側を COUNT_BIG(*) と合わせて比較する(行の順序に依存しない)。

MongoDB

// Compare document counts (on source and target)
db.customer.countDocuments({});

// For a content checksum, dbHash (md5 digest at collection/DB level):
db.runCommand({ dbHash: 1, collections: ["customer"] });
// -> compare the md5 field across both environments.

最初の確認は、countDocuments() で両側のドキュメント数を比較すること(estimatedDocumentCount は高速だがメタデータに依存する。正確な数には countDocuments を使用する)。内容の検証では、dbHash コマンドがコレクション/データベースレベルで md5 ダイジェストを生成する。2 つの環境のハッシュを比較する。インデックスは getIndexes() で別途確認する。

Redis

# Compare key counts (on source and target)
redis-cli DBSIZE

# For a memory/data summary and key distribution:
redis-cli INFO keyspace     # db0:keys=... information
# For full content verification: DUMP each key and compare with the target
# (e.g. redis-cli --scan | xargs -I{} redis-cli DUMP {})

Redis での基本的な検証は、DBSIZE で総キー数を比較すること。データベースごとの分布は INFO keyspace で確認できる。Redis には組み込みのテーブルチェックサムがない。厳密な内容の検証が必要な場合は、キーごとに DUMP のシリアライズを取得して両側を比較する(TTL の差異に注意)。riot compare ツールも使用できる。

Elasticsearch

# Compare document counts (on source and target clusters)
GET customer/_count

# Details: for health/segment/storage comparison
GET _cat/indices/customer?v&h=index,docs.count,store.size
# Content by sampling: compare GET customer/_doc/<id> for the same _ids

Elasticsearch での基本的な検証は、GET <index>/_count で両クラスタのドキュメント数を比較すること(_cat/indices の docs.count も手早い概要を示す)。比較は _count を基準にする。_cat/indices の docs.count は Lucene レベルでカウントする(nested のサブドキュメントを含む。例: nested 項目を 2 つ持つ 1 ドキュメントは 3 とカウントされる)ため、_count と異なることがある。内容の検証では、同じ _id の集合でドキュメントをサンプリングするか、ハッシュフィールドで比較する。

DBAtlas で開く →