AWS DMS のソースとしての IBM Db2 for Linux、Unix、Windows、Amazon RDS データベース (Db2 LUW) の使用
AWS Database Migration Service (AWS DMS) を使用して、IBM Db2 for Linux、Unix、Windows、Amazon RDS (Db2 LUW) データベースから、サポートされているすべてのターゲットデータベースにデータを移行できます。
AWS DMS がソースとしてサポートする Linux、Unix、Windows、RDS の Db2 のバージョンについては、「AWS DMS のソース」を参照してください。
Secure Sockets Layer (SSL) を使用して、Db2 LUW エンドポイントとレプリケーションインスタンスとの接続を暗号化できます。Db2 LUW エンドポイントで SSL を使用する方法の詳細については、「AWS Database Migration Service での SSL の使用」をご参照ください。
AWS DMS のソースとして Db2 LUW を使用する場合の前提条件
Db2 LUW データベースをソースとして使用する前に、次の前提条件が必要です。
変更データキャプチャ (CDC) とも呼ばれる継続的なレプリケーションを有効にするには、次を実行します。
-
データベースを AWS DMS で変更をキャプチャするために必要となる復元可能に設定します。データベース設定パラメータの
LOGARCHMETH1とLOGARCHMETH2のどちらかまたは両方がONに設定されている場合、データベースは復元可能です。データベースが復元可能になっていれば、必要に応じて AWS DMS は Db2
ARCHIVE LOGにアクセスできます。 -
DB2 トランザクション ログが使用可能であり、AWS DMS による処理に十分な保持期間があることを確認します。
-
DB2 ではトランザクションログレコードを抽出するのに
SYSADM認証またはDBADM認証が必要です。ユーザーアカウントに次のアクセス権限を付与します。SYSADM、またはDBADMDATAACCESS
注記
フルロードのみのタスクの場合、DMS ユーザーアカウントには DATAACCESS アクセス権限が必要です。
-
ソースとして IBM DB2 for LUW バージョン 9.7 を使用する場合は、追加接続属性 (ECA) を設定し、以下のように
CurrentLSNに設定します：CurrentLSN=、ここにLSNLSNCurrentLSN=。scan -
Amazon RDS for Db2 LUW をソースとして使用する場合、アーカイブログが AWS DMS で使用可能であることを確認する必要があります。AWS が管理する Db2 データベースでは、可能な限り迅速にアーカイブログは消去されるため、ログが利用できる保存期間を長く設定する必要があります。例えば、ログ保持を 24 時間に伸ばすには、次のコマンドを実行します。
db2 "call rdsadmin.set_archive_log_retention( ?, 'TESTDB', '24')"Amazon RDS for Db2 LUW プロシージャの詳細については、「Amazon Relational Database Service ユーザーガイド」の「Amazon RDS for Db2 ストアドプロシージャリファレンス」を参照してください。
Db2 LUW を AWS DMS のソースとして使用する場合の制限
AWS DMS は、クラスター化データベースをサポートしていません。ただし、クラスターの各エンドポイントに個別の Db2 LUW を定義することができます。例えば、クラスター内のいずれかのノードでフルロードの移行タスクを作成して、各ノードから個別のタスクを作成できます。
AWS DMS は、ソースの Db2 LUW データベースの BOOLEAN データ型をサポートしていません。
継続的なレプリケーション (CDC) を使用する場合は、次の制限が適用されます。
-
複数のパーティションを持つテーブルが切り捨てられると、AWS DMS コンソールに表示される DDL イベントの数は、パーティションの数に等しくなります。これは、Db2 LUW がパーティションごとに個別の DDL を記録するためです。
-
次の DDL アクションは、分割されたテーブルではサポート外です。
-
ALTER TABLE ADD PARTITION
-
ALTER TABLE DETACH PARTITION
-
ALTER TABLE ATTACH PARTITION
-
-
AWS DMS は、DB2 高可用性災害対策 (HADR) スタンバイ インスタンスからの継続的レプリケーション移行をサポートしていません。スタンバイはアクセスできません。
-
DECFLOAT データ型はサポート外です。したがって、DECFLOAT 列への変更は、継続的なレプリケーション中は無視されます。
-
RENAME COLUMN ステートメントはサポート外です。
-
多次元クラスタリング (MDC) テーブルの更新を実行すると、それぞれの更新は AWS DMS コンソールに INSERT + DELETE として表示されます。
-
タスクの設定 [レプリケーションに LOB 列を含める] が有効でない場合、LOB 列を持つテーブルは、継続的なレプリケーション中に中断されます。
-
Db2 LUW バージョン 10.5 以上の場合: 行外に格納されたデータを含む可変長文字列は無視されます。この制限は、VARCHAR や VARGRAPHIC などのデータ型を持つ列の拡張行サイズを使用して作成されたテーブルにのみ適用されます。この制限を回避するには、テーブルをページサイズの大きいテーブルスペースに移動します。詳細については、「What can I do if I want to change the pagesize of DB2 tablespaces
」を参照してください。 -
継続的レプリケーションの場合、DMS は DB2 LOAD ユーティリティによってページレベルでロードされたデータの移行をサポートしていません。代わりに、SQL 挿入を使用する IMPORT ユーティリティを使用します。詳細については、「インポートユーティリティとロードユーティリティの違い
」をご参照ください。 -
レプリケーションタスクの実行中、DMS が CREATE TABLE DDL をキャプチャするのは、テーブルが DATA CAPTURE CHANGE 属性で作成された場合のみです。
-
Db2 データベースパーティション機能 (DPF) を使用する場合、DMS には次の制限があります。
DMS は、DPF 環境内の Db2 ノード間でトランザクションを調整できません。これは、IBM DB2READLOG API インターフェイス内の制約によるものです。DPF では、DB2 のデータのパーティション化の方法に応じて、トランザクションが複数の Db2 ノードにまたがる場合があります。その結果、DMS ソリューションは各 Db2 ノードからトランザクションを個別にキャプチャする必要があります。
DMS は、複数の DMS ソースエンドポイントで
connectNodeを1に設定することで、DPF クラスターの各 Db2 ノードからローカルトランザクションをキャプチャできます。この設定は、DB2 サーバー設定ファイルdb2nodes.cfgで定義されている論理ノード番号に対応します。個々の Db2 ノードのローカルトランザクションは、大規模なグローバルトランザクションの一部である場合があります。DMS は、他の Db2 ノードのトランザクションと調整することなく、各ローカルトランザクションを個別にターゲットに適用します。この独立した処理は、特にパーティション間で行を移動する場合に複雑になる可能性があります。
DMS が複数の Db2 ノードからレプリケートする場合、DMS は各 Db2 ノードに独立してオペレーションを適用するため、ターゲットにおいて正しいオペレーション順序は保証されません。各 Db2 ノードから独立してローカルトランザクションをキャプチャすることが、特定のユースケースで機能することを確認する必要があります。
DPF 環境から移行する場合は、まずキャッシュされたイベントなしでフルロードタスクを実行し、次に CDC のみのタスクを実行することをお勧めします。
StartFromContextエンドポイント設定を使用して設定したフルロード開始タイムスタンプ、または LRI (ログレコード識別子) から、Db2 ノードごとに 1 つのタスクを実行することをお勧めします。レプリケーション開始点の決定については、「IBM Support documentation」の「Finding the LSN or LRI value for replication start」を参照してください。
-
継続的なレプリケーション (CDC) で、特定のタイムスタンプからレプリケーションを開始する場合は、
StartFromContext接続属性を必要なタイムスタンプに設定する必要があります。 -
データベースソリューションのスケーリングに使用できる DB2 LUW の拡張機能である Db2 PureScale 機能は、DMS では現時点ではサポートしていません。
Db2 LUW を AWS DMS のソースとして使用する場合のエンドポイントの設定
追加の接続属性の使用と同様、エンドポイントの設定を使用して、ソースの Db2 LUW データベースを設定できます。ソースエンドポイントを作成する際に、AWS DMS コンソールを使用するか、AWS CLI で --ibm-db2-settings '{" の JSON 構文を指定して EndpointSetting":
"value", ...}'create-endpoint コマンドを使用して設定を指定します。
次の表は、ソースとして Db2 LUW を使用できるエンドポイント設定を説明しています。
| 名前 | 説明 |
|---|---|
|
|
継続的なレプリケーション (CDC) では、 |
|
|
読み取りあたりの最大バイト数。NUMBER 値です。デフォルトは 64 KB です。 |
|
|
継続的なレプリケーション (CDC) を BOOLEAN 値として有効にします。デフォルトは true です。 |
|
|
継続的レプリケーション (CDC) の場合は、
ログファイルの LRI/LSN 範囲を特定するには、次の例に示すように
この例の出力は次のようになります。
その出力では、ログファイルは S0000002.LOG であり、StartFromContext LRI 値は、範囲の末尾にある 34 バイトです。
|
IBM Db2 LUW のソースデータ型
Db2 LUW を AWS DMS のソースとして使用するデータ移行では、ほとんどの Db2 LUW データ型がサポートされます。次の表に、AWS DMS を使用する場合にサポートされる Db2 LUW のソースデータ型と、AWS DMS のデータ型からのデフォルトマッピングを示します。Db2 LUW データ型の詳細については、「Db2 LUW のドキュメント
ターゲットにマッピングされるデータ型を表示する方法については、使用しているターゲットエンドポイントのセクションをご参照ください。
AWS DMS のデータ型の詳細については、「AWS Database Migration Service のデータ型」をご参照ください。
|
Db2 LUW データ型 |
AWS DMS データ型 |
|---|---|
|
INTEGER |
INT4 |
|
SMALLINT |
INT2 |
|
BIGINT |
INT8 |
|
DECIMAL (p,s) |
NUMERIC (p,s) |
|
FLOAT |
REAL8 |
|
DOUBLE |
REAL8 |
|
REAL |
REAL4 |
|
DECFLOAT (p) |
精度が 16 の場合は REAL8 で、精度が 34 の場合は STRING |
|
GRAPHIC (n) |
WSTRING、長さが 0 より大きく 127 以下の 2 バイト文字の固定長グラフィック文字列用 |
|
VARGRAPHIC (n) |
WSTRING、長さが 0 より大きく 16,352 以下の 2 バイト文字の可変長グラフィック文字列用 |
|
LONG VARGRAPHIC (n) |
CLOB、長さが 0 より大きく 16,352 以下の 2 バイト文字の可変長グラフィック文字列用 |
|
CHARACTER (n) |
STRING、長さが 0 より大きく 255 以下の 2 バイト文字の固定長文字列用 |
|
VARCHAR(n) |
STRING、長さが 0 より大きく 32,704 以下の 2 バイト文字の可変長文字列用 |
|
LONG VARCHAR (n) |
CLOB、長さが 0 より大きく 32,704 以下の 2 バイト文字の可変長文字列用 |
|
CHAR (n) FOR BIT DATA |
BYTES |
|
VARCHAR (n) FOR BIT DATA |
BYTES |
|
LONG VARCHAR FOR BIT DATA |
BYTES |
|
DATE |
DATE |
|
TIME |
TIME |
|
タイムスタンプ |
DATETIME |
|
BLOB (n) |
BLOB 最大長は 2,147,483,647 バイト |
|
CLOB (n) |
CLOB 最大長は 2,147,483,647 バイト |
|
DBCLOB (n) |
CLOB 最大サイズは 1,073,741,824 の 2 バイト文字 |
|
XML |
CLOB |
