Data Transmission Service:Oracle データを DataHub に移行

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

ネットワークと接続性

• ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。帯域幅が不足すると、移行速度が低下します。

• ソースデータベースが Express Connect 経由で接続された Oracle RAC データベースである場合は、ソースデータベースを構成する際に VIP を指定してください。

• ソースデータベースが Express Connect、VPN Gateway、Smart Access Gateway、Database Gateway、または Cloud Enterprise Network (CEN) 経由で接続された Oracle RAC データベースである場合は、Single Client Access Name (SCAN) IP アドレスではなく、単一の VIP を使用してください。VIP を指定した後、Oracle RAC データベースのノードフェールオーバーはサポートされません。

データ型制約

• ソース Oracle データベースの VARCHAR2 フィールドに空の文字列 (Oracle では NULL と評価されます) が含まれており、対応するターゲットフィールドに非 NULL 制約がある場合、移行タスクは失敗します。

オブジェクト要件

• 移行するテーブルには、プライマリキーまたは一意制約が必要であり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複するデータレコードが表示される可能性があります。

• Oracle 12c 以降の場合、テーブル名は 30 バイトを超えることはできません。

• ターゲットデータベースで変更 (テーブルまたは列の名前変更など) があるテーブルを移行する場合、単一タスクで最大 1,000 テーブルをサポートします。1,000 を超えるテーブルの場合は、複数のタスクを構成してバッチで移行するか、データベース全体を移行してください。

増分移行の要件

• REDO ロギングとアーカイブロギングを有効にする必要があります。

• ログ保持要件:

  • 増分データ移行のみ: REDO ログとアーカイブログを 24 時間以上保存します。

  • 完全なデータ移行と増分データ移行: REDO ログとアーカイブログを少なくとも 7 日間保存します。完全なデータ移行が完了した後、保持期間を 24 時間以上に短縮します。

• DTS が REDO ログとアーカイブログを取得できない場合、タスクが失敗する可能性があります。極端な場合、データ不整合またはデータ損失が発生する可能性があります。ログ保持要件が満たされていない場合、DTS のサービスレベルアグリーメント (SLA) はサービスの信頼性またはパフォーマンスを保証しません。

移行中の操作

• スキーマ移行および完全なデータ移行中に、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。

• 完全なデータ移行中のみ、ソースデータベースにデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベース間でデータ不整合が発生する可能性があります。データ整合性を維持するには、移行タイプとしてスキーマ移行、完全なデータ移行、および増分データ移行を選択します。

• データ移行中に LONGTEXT フィールドを更新しないでください。そうしないと、データ移行タスクが失敗します。

その他の制限

• 宛先 DataHub プロジェクトの単一の文字列は、長さが 2 MB を超えることはできません。

• テーブルのみを移行オブジェクトとして選択できます。DTS はトリガーの移行をサポートしていません。

• オフピーク時間にデータを移行してください。完全なデータ移行中、DTS はソースデータベースとターゲットデータベースの両方の読み取りおよび書き込みリソースを消費するため、サーバー負荷が増加する可能性があります。

• 完全なデータ移行中、同時 INSERT 操作により、ターゲットクラスターのテーブルに断片化が発生します。完全なデータ移行が完了した後、ターゲットクラスターの使用済み表領域のサイズはソースデータベースよりも大きくなります。

• DTS は、過去 7 日以内に失敗した移行タスクの再開を試みます。 ワークロードをターゲットデータベースに切り替える前に、失敗したタスクを停止またはリリースしてください。 または、REVOKE 文を実行して、DTS がターゲットデータベースへのアクセスに使用するアカウントから書き込み権限を取り消してください。 そうしないと、失敗したタスクが再開された後に、ソースデータベースのデータがターゲットデータベースのデータを上書きします。

• 移行中に他のソースからのデータがターゲットデータベースに書き込まれると、ソースデータベースとターゲットデータベース間でデータ不整合が発生する可能性があります。

ステップ 1: データ移行タスクページを開く

1. Data Management (DMS) コンソールにログインします。

2. 上部ナビゲーションバーで、[DTS] をクリックします。

3. 左側のナビゲーションウィンドウで、[DTS (DTS)] > [データ移行] を選択します。

DMS コンソールのモードとレイアウトによって操作が異なる場合があります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。

新しい DTS コンソールのデータ移行タスクページも利用できます。

ステップ 2: リージョンを選択し、タスクを作成する

1. 「[データ移行タスク]」の隣にあるドロップダウンリストから、データ移行インスタンスが存在するリージョンを選択します。

   新しい DTS コンソールでは、左上隅でリージョンを選択します。

2. [タスクの作成] をクリックします。

ステップ 3: ソースデータベースとターゲットデータベースの構成

タスクの作成ページで、ソースデータベースとターゲットデータベースを構成します。

ステップ 4: 接続性のテスト

1. ページの下部で、[接続性のテストと続行] をクリックします。

2. 自己管理 Oracle データベースにホワイトリストが構成されている場合は、DTS サーバーの CIDR ブロックをホワイトリストに追加し、[接続をテストして続行] をクリックします。DTS では、データベースの種類によってホワイトリストの構成方法が異なります:

   • Alibaba Cloud データベースインスタンス (ApsaraDB RDS for MySQL や ApsaraDB for MongoDB など): DTS は DTS サーバーの CIDR ブロックを IP アドレスホワイトリストに自動的に追加します。

   • ECS 上の自己管理データベース: DTS は CIDR ブロックを ECS セキュリティグループルールに自動的に追加します。ECS インスタンスがデータベースにアクセスできることを確認してください。複数の ECS インスタンスの場合は、各セキュリティグループに CIDR ブロックを手動で追加します。

   • データセンターまたはサードパーティクラウド内の自己管理型データベース: DTS サーバーの CIDR ブロックをデータベースのIP アドレス ホワイトリストに手動で追加します。詳細については、「DTS サーバーの CIDR ブロック」をご参照ください。

ステップ 5: 移行オブジェクトと詳細設定の構成

移行オブジェクト

パラメーター	説明
移行タイプ	[スキーマ移行] と [増分データ移行] を選択します。[フルデータ移行] は選択できません。 説明 [増分データ移行] を選択しない場合、データ整合性を維持するため、移行中にソースデータベースにデータを書き込まないでください。
追加カラムの命名ルール	DTS が DataHub にデータを移行する際、宛先トピックに追加カラムが追加されます。追加カラムの名前が宛先トピック内の既存カラムと重複する場合、移行タスクは失敗します。要件に応じて、[新規ルール] または [以前のルール] を選択します。 警告 このパラメーターを設定する前に、追加カラムが送信先トピック内の既存のカラムと名前の競合を起こしていないか確認してください。名前の競合は、タスクの失敗やデータ損失を引き起こす可能性があります。詳細については、「追加カラムの名前付けルールを変更する」をご参照ください。
競合テーブルの処理モード	事前チェックしてエラーを報告]：宛先データベースにソースデータベースと同じ名前のテーブルが存在するかどうかをチェックします。同一のテーブル名が存在する場合、事前チェックでエラーが返され、タスクを開始できません。 説明 同一のテーブル名が存在し、移行先のテーブルを削除または名前変更できない場合は、オブジェクト名マッピング機能を使用して移行後のテーブルの名前を変更します。詳細については、「オブジェクト名をマップする」をご参照ください。エラーを無視して続行: 同一テーブル名の事前チェックをスキップします。 警告 [エラーを無視して続行] を選択すると、データ不整合が発生する可能性があります。スキーマが一致する場合、DTS は同じプライマリキーを持つデータレコードをスキップします。スキーマが異なる場合、特定のカラムのみが移行されるか、タスクが失敗します。
宛先インスタンスにおけるオブジェクト名の大文字・小文字の扱い	宛先インスタンスにおけるデータベース名、テーブル名、およびカラム名の大文字・小文字の扱いです。デフォルトでは、[DTS デフォルトポリシー宛先インスタンスのオブジェクト名の大文字と小文字の指定] が選択されています。詳細については、「」をご参照ください。
ソースオブジェクト	[ソースオブジェクト] セクションから 1 つ以上のオブジェクトを選択し、 アイコンをクリックして [選択済みオブジェクト] セクションに追加します。 説明 移行オブジェクトとして選択できるのはテーブルのみです。
選択済みオブジェクト	- 単一のオブジェクト名を変更するには、[選択済みオブジェクト] セクションでそのオブジェクトを右クリックします。詳細については、「単一オブジェクト名のマッピング」をご参照ください。- 複数のオブジェクト名を一度に変更するには、[選択済みオブジェクト] セクションの右上隅にある [一括編集] をクリックします。詳細については、「複数のオブジェクト名を一度にマッピング」をご参照ください。 説明 データベース名のマッピングはサポートされていません。オブジェクト名を変更すると、依存オブジェクトが移行中に失敗する可能性があります。オブジェクト名には、テーブル名およびカラム名が含まれます。- WHERE 条件でデータをフィルターするには、[選択済みオブジェクト] セクションでテーブルを右クリックし、ダイアログボックスでフィルター条件を設定します。詳細については、「フィルター条件の設定」をご参照ください。- ShardKey パラメーターを設定するには、[選択済みオブジェクト] セクションでテーブルを右クリックし、ダイアログボックス内の [すべてのテーブルを同期] のチェックを解除します。

ステップ 6: 事前チェックの実行とタスクの開始

1. タスク設定を保存し、事前チェックを実行します。

   • DTS タスクの API パラメーターを表示するには、[次へ: タスク設定の保存と事前チェック] の上にマウスを移動して、[OpenAPI パラメーターのプレビュー] をクリックします。

   • ページ下部の[次へ: タスク設定を保存して事前チェック]をクリックします。

   - DTS は、移行タスクを開始する前に事前チェックを実行します。事前チェックに合格した後でのみ、タスクを開始できます。 - 事前チェックが失敗した場合は、失敗した各項目の横にある [詳細の表示] をクリックします。原因を分析して問題を修正し、再度事前チェックを実行します。 - 事前チェック中にアラートが生成された場合： - アラート項目を無視できない場合は、失敗した項目の横にある [詳細の表示] をクリックして問題を修正し、再度事前チェックを実行します。 - アラート項目を無視できる場合は、[アラートの詳細を確認] をクリックします。「詳細の表示」ダイアログボックスで、[無視] をクリックし、次に [OK] をクリックします。[事前チェックを再実行] をクリックして、事前チェックを再実行します。アラート項目を無視すると、データの不整合が発生し、ビジネスが潜在的なリスクにさらされる可能性があります。

2. [成功率] が 100% に達するまで待ち、[次へ: インスタンスの購入] をクリックします。

3. 「[インスタンスの購入]」ページで、以下のパラメーターを設定します。

   パラメーター	説明
   [リソースグループ設定]	データ移行インスタンスのリソースグループです。デフォルト値: [デフォルト リソースグループ]。詳細については、「Resource Management とは？
   インスタンスタイプ	インスタンスクラスは移行速度を決定します。ご使用のシナリオに基づいて、インスタンスクラスを選択してください。詳細については、「データ移行インスタンスの仕様」をご参照ください。

4. [Data Transmission Service (従量課金) サービス規約] チェックボックスを選択します。

5. データ移行タスクを開始するには、[Buy And Start] をクリックします。タスクリストでタスクの進捗状況を確認できます。