Data Transmission Service:Db2 for LUW データベースから AnalyticDB for PostgreSQL インスタンスへデータを移行する

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

• ソース Db2 for LUW データベースの合計データサイズよりも大きな利用可能なストレージ容量を持つ AnalyticDB for PostgreSQL インスタンス。インスタンスの作成については、「インスタンスの作成」をご参照ください。

• 移行されたデータを受け取るためのデータベースを、宛先の AnalyticDB for PostgreSQL インスタンス内に作成済みであること。詳細については、「ベクトルデータのインポート」をご参照ください。

• 必要な権限を持つデータベースアカウント（「必要な権限」をご参照ください）。

増分データ移行のみの場合：

• ソース Db2 for LUW データベースでアーカイブ ログ記録が有効化されており、logarchmeth1 または logarchmeth2 を使用して構成されます。構成の詳細については、「logarchmeth1」および「logarchmeth2」をご参照ください。

対応するデータベースバージョンについては、「データ移行シナリオの概要」をご参照ください。

課金

必要な権限

アカウントの作成および権限付与手順については、以下をご参照ください。

• Db2 for LUW: Db2 データベースのインストール用のグループおよびユーザー ID の作成 および 権限の概要

• AnalyticDB for PostgreSQL：「データベースアカウントの作成」および「ユーザーおよび権限の管理」

制限事項

スキーマ移行中、DTS はソースデータベースから外部キーを宛先データベースへ移行します。

完全なデータ移行および増分データ移行中、DTS はセッションレベルで一時的に外部キー制約チェックおよびカスケード操作を無効化します。移行中にソースデータベースでカスケード操作または削除操作を実行すると、データの不整合が発生する可能性があります。

ソースデータベースの制限事項

• ソースサーバーには十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度が低下します。

• テーブルには PRIMARY KEY またはすべてのフィールドが一意である UNIQUE 制約が必要です。これを満たさない場合、宛先データベースに重複レコードが含まれる可能性があります。

• オブジェクト名マッピングを使用してオブジェクトをリネームし、1,000 個を超えるテーブルを移行する場合は、移行タスクを複数に分割するか、データベース全体を移行してください。個別に選択した 1,000 個を超えるテーブルをリネーム対象として指定したタスクは、リクエストエラーで失敗します。

• 増分データ移行の場合：

  • ソースデータベースでデータログ機能が有効化されている必要があります。無効化されている場合、DTS は事前チェックに失敗します。

  • 増分移行のみの場合：データログは 24 時間以上保持する必要があります。

  • 完全移行＋増分移行の場合：データログは少なくとも 7 日間保持する必要があります。完全移行が完了した後は、保持期間を 24 時間以上に短縮できます。

  • 保持期間が不足している場合、DTS がデータログを読み取れず、タスクが失敗する可能性があります。まれに、データの不整合または損失が発生することもあります。このケースは DTS のサービスレベルアグリーメント（SLA）の適用範囲外となります。

• 完全なデータ移行中は、ソースデータベースに対して DDL 操作を実行しないでください。このフェーズ中にスキーマを変更すると、タスクが失敗します。

• 増分移行を伴わない完全なデータ移行のみを実行する場合、移行中にソースデータベースへの書き込みを避けてください。データ整合性を保証するには、スキーマ移行、完全なデータ移行、および増分データ移行を同時に実行してください。

その他の制限事項

• 増分データ移行では、Db2 for LUW の変更データキャプチャ（CDC）レプリケーション技術が使用されます。CDC には独自のデータ型制限があります。「SQL レプリケーションにおける一般的なデータ制限」をご参照ください。

• 移行対象として選択できるのはテーブルのみです。Append-optimized（AO）テーブルは宛先テーブルタイプとしてサポートされていません。

• スキーマ移行および増分データ移行中、外部キーは宛先データベースへ移行されません。

• 完全なデータ移行中の同時 INSERT 操作により、テーブルスペースのフラグメントが発生します。完全移行完了後の宛先テーブルスペースは、ソースより大きくなります。

• 移行中に DTS 以外のツールが宛先データベースへ書き込むと、データの不整合が発生する可能性があります。移行完了後は、オンライン DDL 操作に Data Management（DMS）をご利用ください。「ロックフリー DDL 操作の実行」をご参照ください。

• 非完全テーブル移行で列マッピングを使用する場合、またはソースと宛先のスキーマが異なる場合、宛先に存在しないソース列のデータは失われます。

• 可能であれば、ピーク時間帯を避けて移行を実行してください。完全なデータ移行では、両方のデータベースで読み取りおよび書き込みリソースが使用されるため、サーバー負荷が増加します。

自主管理 Db2 for LUW 固有の制限事項

• 移行タスク実行中にソースデータベースでプライマリ／セカンダリのフェールオーバーが発生した場合、タスクは失敗します。

• DTS は移行遅延を、宛先データベースで最後に移行されたレコードのタイムスタンプとソースデータベースの現在時刻の差として算出します。ソースで長期間 DML 操作が行われていない場合、表示される遅延値は不正確になる可能性があります。遅延値を更新するには、ソースで DML 操作を実行してください。データベース全体を選択した場合、1 秒ごとに更新されるハートビートテーブルを作成することを推奨します。

増分移行でサポートされる SQL 操作

移行タスクの作成

以下の手順に従って、自主管理 Db2 for LUW データベースから AnalyticDB for PostgreSQL インスタンスへの DTS 移行タスクを設定および開始します。

ステップ 4：移行対象および高度な設定の構成

以下のパラメーターを設定します。

移行タイプ

許容可能なダウンタイムに応じて、移行タイプを選択してください。

オプション	使用タイミング
スキーマ移行 ＋ 完全なデータ移行	移行前にソースデータベースへの書き込みを停止できる場合に使用します。初期データのロードが完了すると、タスクは終了します。
スキーマ移行 ＋ 完全なデータ移行 ＋ 増分データ移行（推奨）	移行中もソースデータベースを本番運用状態に維持する必要がある場合に使用します。増分移行は、切り替え（cut over）まで継続的に変更をキャプチャおよび適用します。

増分データ移行 を選択しない場合、データの不整合を防ぐため、移行中にソースデータベースへの書き込みを避けてください。

その他の設定

パラメーター	説明
同期対象の DDL および DML 操作	増分移行に含める SQL 操作。サポートされる操作については、「増分移行でサポートされる SQL 操作」をご参照ください。オブジェクト単位の SQL 操作フィルターを設定するには、選択済みオブジェクト セクション内のオブジェクトを右クリックし、ダイアログボックスで操作を選択してください。
競合テーブルの処理モード	事前チェックおよびエラー報告：宛先テーブルとソーステーブルの名前が一致する場合、DTS は事前チェックに失敗します。タスク開始前に、オブジェクト名マッピングを使用して競合テーブルをリネームしてください。「オブジェクト名のマッピング」をご参照ください。エラーを無視して続行：DTS は名前競合チェックをスキップします。ソースおよび宛先テーブルのスキーマが一致する場合、プライマリキー値が一致するレコードは移行されません。スキーマが異なる場合、一致する列のみが移行されるか、タスクが失敗する可能性があります。慎重に使用してください。
宛先インスタンスにおけるオブジェクト名の大文字小文字設定	宛先のデータベース、テーブル、および列名の大文字小文字を制御します。デフォルトは DTS デフォルトポリシー です。タスク実行中にエラーが発生しないよう、宛先データベースのデフォルトの大小文字規則（例：小文字）に合わせて設定してください。「宛先インスタンスにおけるオブジェクト名の大文字小文字の指定」をご参照ください。
ソースオブジェクト	1 つ以上のオブジェクトを選択し、 アイコンをクリックして 選択済みオブジェクト に追加します。テーブルのみを選択可能です。
選択済みオブジェクト	オブジェクトをリネームするには、右クリックしてオブジェクト名マッピング機能を使用します。複数のオブジェクトを一度にリネームするには、一括編集 をクリックします。「オブジェクト名のマッピング」をご参照ください。WHERE 句による行フィルターを設定するには、オブジェクトを右クリックして条件を指定します。「SQL 条件を使用したデータのフィルタリング」をご参照ください。

オブジェクト名マッピングおよびソースと宛先のスキーマの違いにより、宛先に存在しないソース列のデータが失われる可能性があります。

次のステップ

• 移行されたデータを検証するには、「データ検証の有効化」をご参照ください。

• 移行完了後は、DMS を使用して宛先データベースでオンライン DDL 操作を実行できます。「ロックフリー DDL 操作の実行」をご参照ください。

• ソースと宛先で異なる命名規則を使用する場合、「オブジェクト名のマッピング」をご参照ください。