回答

SQLサーバー間での大容量データの転送には、バルクインサート、ETLプロセス（抽出-変換-ロード）、レプリケーション、およびバックアップ/復元メカニズム、db-linkや組み込みのエクスポート/インポートツールを含むいくつかの戦略が使用されます。

最適なのはバッチ（パッケージ）メカニズムを使用することです。SQL Serverの例では、大きなファイルをロードするためのBULK INSERTや、複雑なETLシナリオのためのSSIS/Integration Servicesがあります。より移植性のあるオプションでは、LIMIT/OFFSETロジックを使用したスクリプトと転送位置の固定が行われます。信頼性のために、以下のような方法がよく使用されます：

チェックサム付きのデータバッチ転送
完全性チェック用の一時的なステージングテーブル
転送のステージをログに記録すること。

例

-- データベース間でのバッチ転送（PostgreSQL）
INSERT INTO target_db.public.data_table (col1, col2)
SELECT col1, col2 FROM source_db.public.data_table
WHERE transferred = FALSE
LIMIT 10000;

知識問題

レプリケーションとエクスポート/インポートの違いは何ですか？なぜレプリケーションが大規模な履歴アーカイブの移行に適さない場合があるのでしょうか？

回答：レプリケーションは最新の変更を同期させるもので、「ライブ」データに対して効率的に機能します。履歴アーカイブの移行には、レプリケーションは十分に迅速でも柔軟でもないため、カスタム変換をサポートせず、一度に大量のデータを転送するという問題を解決できないことが多い。このため、ETLがよりよく使用されます。

実際のエラー例

事例

企業が複数の地域データベースを単一ストレージに統合しました。バッチなしでの大量インポート中にシステムが「ハング」し、メモリ不足により部分コミットと手動の状態復旧を引き起こしました。進捗をログに記録するバッチ出力への移行で修正されました。

事例

BULK INSERTを使用して大きなファイルを転送する際にチェックスムーズを適切に管理できなかったため、一部の情報が損傷しましたが、この事実は数週間後に発見されました。解決策は、各バッチの前後でチェックサムを再計算し、不一致があった場合には自動的に再試行することでした。

事例

標準のエクスポート/インポートを介して1億行以上を移行する試みの中で、ある開発者はロック管理を考慮しませんでした：ターゲットサーバーでのテーブルロックにより、ビジネスプロセスが数時間停止しました。結論として、このようなタスクには夜間ウィンドウと段階的なコピーを使用し、一時的なインデックスの再構築を行うことが必要です。