Data Transmission Service (DTS) は、スキーマ移行、完全なデータ移行、増分データ移行の 3 つのフェーズで、自己管理 Oracle データベースから AnalyticDB for MySQL V3.0 クラスターにデータを移行します。これら 3 つのフェーズをすべて実行することで、移行中のダウンタイムなしでサービスを継続できます。
仕組み
DTS は Oracle ソースからデータを取得し、以下の 3 つの連続したフェーズで AnalyticDB for MySQL に書き込みます。
スキーマ移行 — DTS は、宛先クラスターでテーブル構造を変換して作成します。外部キーは移行されません。
完全なデータ移行 — DTS は、ソースから宛先にすべての既存データをコピーします。同時に INSERT 操作を行うと、宛先クラスターでテーブルの断片化が発生する可能性があります。
増分データ移行 — DTS は Oracle の REDO ログとアーカイブ・ログを読み取って進行中の変更をキャプチャし、ほぼリアルタイムで宛先に適用します。DML 操作 (INSERT、UPDATE、DELETE) のみがキャプチャされます。
DTS が AnalyticDB for MySQL V3.0 に書き込む際、UPDATE 文は自動的に REPLACE INTO に変換されます。プライマリキーに対する UPDATE 操作は、DELETE + INSERT に変換されます。
前提条件
開始する前に、以下が準備できていることを確認してください：
ソース Oracle データベースの合計サイズよりも大きい利用可能なストレージを持つ AnalyticDB for MySQL V3.0 クラスター。詳細については、「クラスターの作成」をご参照ください。
ソース Oracle データベースがアーカイブログモードで実行されており、アーカイブ REDO ログファイルにアクセス可能で、適切な保持期間が設定されていること。詳細については、「アーカイブ REDO ログファイルの管理」をご参照ください。
ソース Oracle データベースで補足ログが有効になっており、
SUPPLEMENTAL_LOG_DATA_PKとSUPPLEMENTAL_LOG_DATA_UIがYesに設定されていること。ソース Oracle データベースで以下の SQL コマンドを実行して、アーカイブログと補足ログを有効にします：-- アーカイブログを有効化 (アーカイブログモードが必要) -- 現在のモードを確認: SELECT LOG_MODE FROM V$DATABASE; -- データベースレベルで補足ログを有効化 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -- プライマリキーの補足ログを有効化 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; -- 一意なインデックスの補足ログを有効化 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS; -- 補足ログのステータスを確認 SELECT SUPPLEMENTAL_LOG_DATA_MIN, SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI FROM V$DATABASE; -- 期待される結果: SUPPLEMENTAL_LOG_DATA_PK = YES, SUPPLEMENTAL_LOG_DATA_UI = YES詳細については、「補足ログ」および「Oracle データベースの設定」をご参照ください。
Oracle データベースの移行における DTS の機能と制限に精通していること。Advanced Database & Application Migration (ADAM) は、クラウドへのスムーズな移行を確実にするために、データベース評価に使用されます。「Oracle データベースの準備」および「概要」をご参照ください。
必要な権限を持つソース Oracle データベース上のデータベースアカウント。詳細については、「必要な権限」をご参照ください。
読み取り/書き込み権限を持つ宛先 AnalyticDB for MySQL V3.0 クラスター上のデータベースアカウント。
サポートされている Oracle データベースのバージョンについては、「データ移行シナリオの概要」をご参照ください。
必要な権限
移行タスクを設定する前に、各データベースのデータベースアカウントを作成し、以下の権限を付与してください。これらの権限を持つアカウントが既に存在する場合は、このステップをスキップしてください。
| データベース | スキーマ移行 | 完全なデータ移行 | 増分データ移行 |
|---|---|---|---|
| 自己管理 Oracle データベース | スキーマオーナー権限 | スキーマオーナー権限 | 詳細な権限 |
| AnalyticDB for MySQL V3.0 クラスター | ターゲットデータベースに対する読み取り/書き込み権限 |
アカウントを作成して権限を付与するには：
自己管理 Oracle データベース：詳細については、「データベースアカウントの準備」、「CREATE USER」、および「GRANT」をご参照ください。
AnalyticDB for MySQL V3.0 クラスター：詳細については、「データベースアカウントの作成」をご参照ください。
制限事項
タスクを設定する前に、以下の制限事項を確認してください。
スキーマ移行中、DTS はソースから宛先に外部キーを移行しません。
完全なデータ移行および増分データ移行中、DTS はセッションレベルで外部キーの制約チェックとカスケード操作を一時的に無効にします。移行中にソースでカスケード更新および削除操作を行うと、データの不整合が発生する可能性があります。
ソースデータベースの制限事項
| カテゴリ | 制限事項 |
|---|---|
| 帯域幅 | ソースサーバーには十分なアウトバウンド帯域幅が必要です。そうでない場合、移行速度が低下します。 |
| Express Connect 経由の Oracle RAC | データベースに仮想 IP アドレス (VIP) を指定してください。 |
| Express Connect、VPN Gateway、Smart Access Gateway、データベースゲートウェイ、または Cloud Enterprise Network (CEN) 経由の Oracle RAC | Single Client Access Name (SCAN) IP アドレスではなく、単一の VIP を使用してください。VIP を指定した後、Oracle RAC データベースのノードフェイルオーバーはサポートされません。 |
| VARCHAR2 の空文字列 | Oracle は空の VARCHAR2 文字列を null として評価します。宛先フィールドに NOT NULL 制約がある場合、移行タスクは失敗します。 |
| テーブル制約 | テーブルには、すべてのフィールドが一意である PRIMARY KEY または UNIQUE 制約が必要です。これらの制約がない場合、宛先に重複レコードが含まれる可能性があります。 |
| Oracle 12c 以降 | テーブル名は 30 バイトを超えることはできません。 |
| テーブル名の変更制限 | テーブルを移行オブジェクトとして選択し、テーブル名または列名を変更する必要がある場合：単一のタスクは最大 1,000 テーブルまでサポートします。1,000 テーブルを超える場合は、複数のタスクを設定するか、データベース全体を移行してください。 |
| 増分移行：ログ保持 | REDO ログとアーカイブ・ログは少なくとも 7 日間保持する必要があります。保持期間が短いとタスクが失敗し、例外的な場合にはデータの不整合や損失が発生する可能性があります。保持期間が不十分な場合、DTS のサービスレベルアグリーメント (SLA) は信頼性やパフォーマンスを保証しません。 |
| 増分移行：ソース操作 | 増分移行中に Oracle Data Pump を使用してソースにデータを書き込まないでください。データ損失が発生する可能性があります。 |
| 移行中の DDL | スキーマ移行または完全なデータ移行中に、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。タスクは失敗します。 |
| 完全なデータ移行：ソースへの書き込み | 完全なデータ移行のみ (増分移行なし) の間は、ソースにデータを書き込まないでください。ソースと宛先の間でデータの不整合が発生する可能性があります。 |
宛先クラスターの制限事項
| カテゴリ | 制限事項 |
|---|---|
| ディスク使用率 | AnalyticDB for MySQL V3.0 クラスター内のいずれかのノードのディスク使用率が 80% を超えると、DTS タスクで例外が発生し、タスクが遅延します。移行を開始する前に必要な容量を見積もり、送信先クラスターに十分なストレージ容量があることを確認してください。 |
| プライマリキー | ターゲットデータベースでカスタムプライマリキーを指定するか、テーブルのフィールド設定時に [プライマリキー列] を設定します。プライマリキーがない場合、移行が失敗することがあります。 |
| バックアップの競合 | DTS タスクの実行中に送信先クラスターでバックアップが実行されると、DTS タスクは失敗します。 |
| 外部テーブル | 外部テーブルは移行できません。 |
| 文字セット | ソースデータベースとターゲットデータベースの文字セットには互換性が必要です。互換性のない文字セットを使用すると、データの不整合やタスクの失敗を引き起こす可能性があります。 |
| タイムゾーン | ソースデータベースとターゲットデータベースのタイムゾーンは同じである必要があります。 |
| 失敗したタスクのリカバリ | DTS は過去 7 日以内に失敗したタスクの再開を試みます。ワークロードを送信先クラスターに切り替える前に、失敗したタスクを停止またはリリースするか、REVOKE 文を実行して DTS アカウントから書き込み権限を取り消してください。そうしないと、再開されたタスクによって送信先のデータが上書きされる可能性があります。 |
| DDL 実行の失敗 | 送信先で DDL 文の実行が失敗した場合でも、DTS タスクは実行を継続します。失敗した文はタスクログで確認できます。詳細については、「タスクログの表示」をご参照ください。 |
| スキーマ移行 | DTS のスキーマ移行機能を使用することで、互換性のないデータ型が原因で発生するタスクの失敗を回避できます。 |
| パフォーマンスへの影響 | 完全なデータ移行は、ソースサーバーと送信先サーバーの両方で負荷を増大させます。移行はオフピーク時間に実行してください。 |
| テーブルの断片化 | 完全なデータ移行中に INSERT 操作を同時に実行すると、テーブルの断片化が発生します。完全なデータ移行後、送信先で使用される表領域はソースよりも大きくなります。 |
| DTS テクニカルサポート | DTS タスクが失敗した場合、テクニカルサポートは 8 時間以内の復元を試みます。復元中、タスクが再起動されたり、(データベースパラメーターではなく) タスクパラメーターが変更されたりすることがあります。変更される可能性のあるパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。 |
課金
| 移行タイプ | インスタンス設定料金 | インターネットトラフィック料金 |
|---|---|---|
| スキーマ移行と完全なデータ移行 | 無料 | 送信先のアクセス方法が[パブリック IP アドレス]に設定されている場合に課金されます。詳細については、「課金概要」をご参照ください。 |
| 増分データ移行 | 課金概要課金対象。詳細については、「」をご参照ください。 | — |
増分移行でサポートされる SQL 操作
| 操作タイプ | SQL ステートメント |
|---|---|
| DML | INSERT、UPDATE、DELETE |
UPDATE 文は、AnalyticDB for MySQL V3.0 に書き込まれる際に REPLACE INTO に変換されます。プライマリキーに対する UPDATE 操作は、DELETE + INSERT に変換されます。
データ型のマッピング
Oracle から MySQL へのデータ型マッピングについては、「異種データベース間のデータ型マッピング」をご参照ください。
移行タスクの作成
この手順は 5 つのステップで構成されています：
データ移行ページに移動します。
ソースと宛先のデータベースを設定します。
移行オブジェクトと詳細設定を構成します。
事前チェックを実行し、インスタンスを購入します。
移行タスクをモニタリングします。
ステップ 1: データ移行ページへの移動
以下のいずれかの方法でデータ移行ページを開きます。
DTS コンソール
DTS コンソールにログインします。
左側のナビゲーションウィンドウで、[データ移行] をクリックします。
左上隅で、移行インスタンスが存在するリージョンを選択します。
DMS コンソール
実際の操作は、DMS コンソールのモードおよびレイアウトによって異なる場合があります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。
DMS コンソールにログインします。
トップナビゲーションバーで、ポインターを [データ + AI] > [DTS (DTS)] > [データ移行] に移動します。
[データ移行タスク] の右側にあるドロップダウンリストから、移行インスタンスが存在するリージョンを選択します。
ステップ 2: ソースと宛先のデータベースの設定
[タスクの作成] をクリックします。
タスク名とソースデータベースを設定します。
警告ソースと宛先のデータベースを設定した後、次に進む前にページの上部に表示される [使用制限] をお読みください。
パラメーター 説明 [タスク名] DTS は自動的に名前を生成します。タスクを識別するために、わかりやすい名前を指定してください。名前は一意である必要はありません。 [既存の接続を選択] リストから登録済みのデータベースインスタンスを選択するか、手動で接続を設定します。 データベースタイプ [Oracle] を選択します。 アクセス方法 ソースデータベースへのアクセス方法を選択します。この例では、ECS 上のセルフマネージドデータベースを使用します。その他のアクセス方法については、「準備の概要」をご参照ください。 インスタンスのリージョン ソース Oracle データベースが存在するリージョン。 ECS インスタンス ID ソース Oracle データベースをホストする Elastic Compute Service (ECS) インスタンスの ID。 [ポート番号] ソース Oracle データベースのサービスポート。デフォルト: 1521。 Oracle タイプ データベースアーキテクチャを選択します：[非 RAC インスタンス] ([SID] が必要) または [RAC または PDB インスタンス] ([サービス名] が必要)。この例では [RAC または PDB インスタンス] を使用します。 データベースアカウント 必要な権限を持つソース Oracle データベースのアカウント。 データベースパスワード ソースデータベースアカウントのパスワード。 宛先データベースを設定します。
パラメーター 説明 [既存の接続を選択] 登録済みのデータベースインスタンスを選択するか、手動で接続を設定します。 データベースの種類 [AnalyticDB for MySQL 3.0] を選択します。 アクセス方法 [Alibaba Cloud インスタンス] を選択します。 インスタンス リージョン 宛先 AnalyticDB for MySQL V3.0 クラスターが存在するリージョン。 [インスタンス ID] 宛先クラスターの ID。 [データベースアカウント] 読み取り/書き込み権限を持つ宛先クラスターのデータベースアカウント。 データベース パスワード 宛先データベースアカウントのパスワード。 [接続をテストして続行] をクリックし、[DTS サーバーの CIDR ブロック] ダイアログボックスで [接続をテスト] をクリックします。
DTS サーバーの CIDR ブロックが、ソースおよびターゲットデータベースのセキュリティ設定に追加されていることを確認してください。詳細については、「DTS サーバーの CIDR ブロックを追加する」をご参照ください。
ステップ 3: 移行オブジェクトと詳細設定の構成
[オブジェクトの設定] ページで、移行パラメーターを設定します。
パラメーター 説明 [移行タイプ] 要件に基づいて移行タイプを選択します： - [スキーマ移行] + [完全なデータ移行]：増分変更なしで既存のデータを移行します。 - [スキーマ移行] + [完全なデータ移行] + [増分データ移行]：移行中に宛先を同期させ、ダウンタイムなしでスムーズな切り替えを可能にします。 説明[スキーマ移行] をスキップする場合は、ターゲットテーブルを手動で作成し、オブジェクト名マッピングを有効にしてください。[増分データ移行] をスキップする場合は、移行中にソースに書き込まないでください。
[同期する DDL および DML 操作] 移行する DDL または DML 操作。特定のテーブルの操作を選択するには、[選択したオブジェクト] でテーブルを右クリックします。 [テーブルのマージ] [いいえ] (デフォルト)：テーブルをマージせずに移行します。[はい]：各テーブルに __dts_data_source列を追加し、選択したすべてのソーステーブルを 1 つの宛先テーブルにマージします。詳細については、「複数テーブルのマージ機能を有効にする」をご参照ください。警告[テーブルのマージ] が有効になっている場合、ソーステーブルで DDL スキーマ変更を実行しないでください。
[競合するテーブルの処理モード] [事前チェックしてエラーを報告] (デフォルト)：宛先テーブルがソーステーブルと名前を共有している場合、事前チェックが失敗します。[エラーを無視して続行]：名前の競合チェックをスキップします。 警告[エラーを無視して続行] を選択すると、データの不整合が発生する可能性があります。完全なデータ移行中、競合するレコードは更新されずに宛先に保持されます。増分移行中、競合するレコードは上書きされます。
[宛先インスタンスでのオブジェクト名の大文字/小文字] 宛先のデータベース、テーブル、列名の大文字/小文字を制御します。デフォルト：[DTS のデフォルトポリシー]宛先インスタンスにおけるオブジェクト名の大文字/小文字の指定。詳細については、「」をご参照ください。 ソースオブジェクト 移行するオブジェクトを選択し、 
をクリックして [選択したオブジェクト] に移動します。列、テーブル、データベースがすべてサポートされています。[選択したオブジェクト] 単一のオブジェクトを右クリックして名前を変更します。右上隅の [編集] をクリックして、一度に複数のオブジェクトの名前を変更します。詳細については、「データベース、テーブル、列名のマッピング」をご参照ください。 説明オブジェクトの名前を変更すると、依存オブジェクトの移行が失敗する可能性があります。条件によってテーブルデータをフィルタリングするには、テーブルを右クリックして WHERE 条件を指定します。詳細については、「フィルター条件の指定」をご参照ください。
[次へ: 詳細設定] をクリックし、詳細パラメーターを設定します。
パラメーター 説明 [タスクスケジューリング用の専用クラスター] DTS はデフォルトで共有クラスターを使用します。専用クラスターを使用するには、別途購入してください。詳細については、「DTS 専用クラスターとは [接続失敗時の再試行時間] タスク開始後に接続が失敗した場合に DTS が再試行する時間。有効な値：10〜1,440 分。デフォルト：720 分。30 分以上に設定してください。この期間内に DTS が再接続すると、タスクは再開されます。そうでない場合、タスクは失敗します。 説明複数のタスクが同じソースまたは宛先を共有する場合、最後に設定された再試行時間がすべてに適用されます。DTS は再試行中にインスタンスに対して課金します。
[その他の問題での再試行時間] 失敗した DDL または DML 操作を DTS が再試行する時間。有効な値：1〜1,440 分。デフォルト：10 分。10 分以上に設定してください。[接続失敗時の再試行時間] より短くする必要があります。 [完全データ移行の帯域幅制限を有効化] 完全なデータ移行中の読み取り/書き込みリソース使用量を制限します。[ソースデータベースへのクエリ数/秒 (QPS)]、[完全なデータ移行の RPS]、および[完全移行時のデータ移行速度 (MB/s)] を設定します。「完全なデータ移行」が選択されている場合のみ利用可能です。 [増分データ移行の帯域幅制限を有効化] 増分移行中のリソース使用量を制限します。[増分データ移行の RPS] および [増分移行のデータ移行速度 (MB/s)] を設定します。「増分データ移行」が選択されている場合のみ利用可能です。 [環境タグ] DTS インスタンスを識別するためのオプションのタグ。 実際の書き込みコード 宛先に書き込まれるデータのエンコード形式。 [ETL の設定] 抽出・変換・書き出し (ETL) 機能を有効にします。詳細については、「ETL とは」および「データ移行タスクまたはデータ同期タスクで ETL を設定する」をご参照ください。 モニタリングとアラート通知 タスクの失敗またはしきい値を超えるレイテンシに対してアラートを設定します。有効にした場合、アラートのしきい値と通知設定を指定します。詳細については、「DTS タスクを作成するときにモニタリングとアラートを設定する」をご参照ください。 [次へ: データ検証] をクリックして、データ検証タスクを設定します。詳細については、「データ検証タスクの設定」をご参照ください。
(オプション) [次へ: データベースとテーブルフィールドの設定] をクリックして、宛先クラスターの各テーブルの [タイプ]、[プライマリキー列]、[分散キー]、[パーティションキー]、[パーティション分割ルール]、および [パーティションライフサイクル] を設定します。
このステップは、スキーマ移行が選択されている場合にのみ利用できます。[定義ステータス]を[すべて]に設定すると、すべてのフィールドを表示および変更できます。プライマリキー列は複合プライマリキー（複数の列）をサポートしています。少なくとも 1 つのプライマリキー列を分散キーとパーティションキーの両方として指定してください。CREATE TABLE を参照してください。
ステップ 4: 事前チェックの実行とインスタンスの購入
[次へ: タスク設定を保存して事前チェック] をクリックします。DTS は移行を開始する前に事前チェックを実行します。次に進む前に、失敗した項目をすべて解決してください：
失敗した項目については、[詳細の表示] をクリックして原因を確認し、問題を修正してから [再事前チェック] をクリックします。
無視できないアラート項目については、[詳細の表示] をクリックし、問題を修正してから事前チェックを再実行します。
無視できるアラート項目については、[アラート詳細の確認] > [無視] > [OK] をクリックし、その後 [再事前チェック] をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。
この設定の API パラメーターをプレビューするには、[次へ: タスク設定を保存して事前チェック] にカーソルを合わせ、[OpenAPI パラメーターのプレビュー] をクリックします。
[成功率] が [100%] に達するまで待ち、[次へ: インスタンスの購入] をクリックします。
[インスタンスの購入] ページで、インスタンスクラスを設定します。
パラメーター 説明 リソースグループ 移行インスタンスのリソースグループです。 デフォルト： デフォルトリソースグループ。 詳細については、「Resource Management とは インスタンスクラス インスタンスクラスによって移行速度が決まります。 詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。 [Data Transmission Service (Pay-as-you-go) 利用規約] を読み、同意してから、[購入して開始] > [OK] をクリックします。
ステップ 5: 移行タスクのモニタリング
[データ移行] ページでタスクの進捗状況を確認します。
完全移行のみ (増分なし)：タスクは完了すると自動的に停止します。ステータスは [完了] と表示されます。
増分移行あり：タスクは継続的に実行され、自動的には停止しません。ステータスは [実行中] と表示されます。データ整合性を確認し、ワークロードを宛先クラスターに切り替える前に、タスクを手動で停止してください。
移行結果の検証
タスクが [完了] に達した後、または宛先クラスターに切り替える前に、データが正しく移行されたことを確認します。
宛先 AnalyticDB for MySQL V3.0 クラスターに接続します。
ソースと宛先の間で、主要なテーブルの行数を比較します：
-- ソース Oracle データベースで実行 SELECT COUNT(*) FROM <schema_name>.<table_name>; -- 宛先 AnalyticDB for MySQL V3.0 クラスターで実行 SELECT COUNT(*) FROM <table_name>;レコードのサンプルをスポットチェックして、データの精度を確認します。
DTS タスクログを確認し、警告またはエラーがないかを確認してください。詳細については、「タスクログの表示」をご参照ください。
データ型の変換を伴う異種データベース間の移行では、切り替える前に必ず重要なテーブルを検証してください。