移行オプションの詳細

オフラインでのバックアップと復元は、データベースをオンプレミスから AWSに移行する最も基本的な方法です。

Db2 オンプレミスデータベースは、リトルエンディアンプラットフォーム上にある必要があります。

オフラインバックアップを作成し、バックアップイメージを Amazon S3 に転送し、バックアップからデータベースを復元するには、ダウンタイムが必要です。

HADR フェイルオーバーは、リトルエンディアンプラットフォームで実行される非 DPF インスタンスに最適です。

ソースデータベース上のすべてのトランザクションをログに記録する必要があります。

HADR は、ログストリーミングによるソースデータベース (プライマリデータベース) からターゲットデータベース (スタンバイデータベース) へのデータ変更のレプリケートをサポートしています。HADR は、プライマリデータベースとスタンバイデータベース間の通信に TCP/IP を使用します。

ビジネス検証が完全に終了したら、HADR を停止することなく終了し、オンプレミスの Db2 データベースは廃止できます。

トランザクションログの配信によりバックアップと復元を使用することは、リトルエンディアンプラットフォーム上の Db2 DPF インスタンスにとって最適です。Db2 DPF データベースのサイズが大きくなる傾向があるため、通常のバックアップや復元 (オプション 1) に対する停止時間は 12 時間を超える可能性があります。HADR は Db2 DPF データベースではサポートされていません。

ソースデータベース上のすべてのトランザクションをログに記録する必要があります。

トランザクションログの配信によるバックアップと復元を使用して、停止期間を最小限に抑えることができます。

ログ配信によるバックアップと復元は、非 DPF インスタンスでも使用できます。ただし、フェイルオーバーによる HADR オプションは、非 DPF インスタンスに実装する方が簡単です。

HADR フェイルオーバー (オプション 2) とは異なり、逆同期は自動ではありません。逆同期を手動でセットアップします。

ビジネス検証が完全に終了したら、オンプレミスの Db2 データベースを廃止できます。

オンプレミスの Db2 がソースで、Amazon EC2 の Db2 がターゲットです。どちらのデータベースもオンラインです。

オンプレミスの Db2 データベースは、任意のプラットフォームファミリーに配置できます。

ソースデータベース上のすべてのトランザクションをログに記録する必要があります。

IBM MQ は、高性能で可用性が高く、確実なメッセージ配信を提供します。

メッセージは、ターゲットデータベースで変更がコミットされると IBM MQ から削除されます。

双方向レプリケーションはフォールバックオプションです。ただし、追加のセットアップが必要です。

スキーマの移行が必要です。詳細については、「スキーマの移行」セクションを参照してください。

Q レプリケーションには、バージョン 11.5 以降の追加ライセンスが必要です。

カットオーバーが成功したら、レプリケーションを停止し、IBM MQ インスタンスを廃止します。必要に応じて、オンプレミスデータベースを廃止することもできます。

オンプレミスの Db2 データベースは、任意のプラットフォームファミリーに配置できます。

ソースデータベース上のすべてのトランザクションをログに記録する必要があります。

各書き込みは (ベーステーブル、CD テーブル、および UOW テーブルで) 複数回実行する必要があるため、ソースデータベースのオーバーヘッドは高いと見なされます。一般的に、書き込みトラフィックが少ないシステムには SQL レプリケーションをお勧めします。

双方向レプリケーションはフォールバックオプションです。ただし、追加のセットアップが必要です。

スキーマの移行が必要です。詳細については、「スキーマの移行」セクションを参照してください。

Q レプリケーションとは異なり、SQL レプリケーションはすべての Db2 エディションに含まれています。追加のライセンスは必要ありません。

カットオーバーが成功したら、レプリケーションを停止し、必要に応じてオンプレミスデータベースを廃止します。

AWS DMS レプリケーションインスタンスは、データベースの移行を実行します。

AWS DMS ソースエンドポイントとターゲットエンドポイントを使用すると、 AWS DMS インスタンスは移行のためにソースデータベースとターゲットデータベースに接続できます。

AWS DMS タスクはソースエンドポイントに接続し、データをターゲットエンドポイントにレプリケートします。

データの検証を有効にして、ソースからターゲットにデータが正確に移行されることを確認します。

Amazon CloudWatch を使用してログ記録を有効にできます。

通常、Optim High Performance Unload では Db2 EXPORT コマンドよりも数倍速く Db2 データをアンロードできます。データファイルをディスクから直接読み取ることで、Db2 データベースマネージャーをバイパスできます。また、コントロールファイルで複数の SELECT ステートメントまたは複数のファイル形式を指定するときに、Db2 テーブルを複数回スキャンしないようにします。

Optim High Performance Unload は、バックアップイメージから Db2 データをアンロードすることもできます。つまり、別のマシンで Optim High Performance Unload を実行し、ソースデータベースサーバーのパフォーマンスへの影響を軽減できます。これは、大きな履歴テーブルまたはテーブルパーティションにとっては非常に便利です。

データ出力ファイルは、Db2 EC2 サーバーからアクセス可能な Amazon S3 に転送できます。

Db2 ロードは Amazon S3 への直接アクセスをサポートします。例えば、次のコマンドを使用できます。

db2 load from DB2REMOTE://<storage access alias>//<storage-path>/<file-name> replace into mytable

スキーマの移行が必要です。詳細については、「スキーマの移行」セクションを参照してください。

InfoSphere Optim High Performance Unload には追加のライセンスが必要です。

ターゲットデータベースにフェデレーションリンクを作成し、ソースデータベースにリンクする必要があります。

テーブルごとに、オンプレミスのソーステーブルにリンクするニックネームが作成されます。テーブルが多数含まれる場合は、自動化スクリプトを使用してニックネームとロードステートメントを生成することをお勧めします。

LOAD FROM CURSOR を使用してステージングストレージをバイパスし、テーブルを異なるストリームに分割して並列的に実行できます。負荷が大きい場合は、ネットワークの輻輳をモニタリングすることをお勧めします。

カーソル定義で SELECT ステートメントを操作することで、完全なテーブルを選択したり、ロードする必要のないデータをスキップしたり、範囲ベースのパーティションテーブルを複数のロードステートメント (四半期ごとや毎月など) に分割したりできます。

スキーマの移行が必要です。詳細については、「スキーマの移行」セクションを参照してください。

スキーマの移行が必要です。詳細については、「スキーマの移行」セクションを参照してください。

db2move コマンドを使用して、データをテーブルからファイルにアンロードし、そのデータを Db2 テーブルにロードできます。これは、db2move ユーティリティがソースデータベース内のすべてのテーブルをダウンロードし、いくつかのコマンドを使用してターゲットデータベースにロードできるため便利です。