ソースデータベースが自己管理 Oracle データベースである場合は、データ移行タスクを設定する前にこのトピックの注意事項と制限事項を確認し、タスクが期待どおりに実行されるようにしてください。
Oracle ソースからの移行シナリオの概要
次のシナリオに基づいて、データ移行タスクの注意事項と制限事項を確認してください:
自己管理 Oracle データベースから PolarDB for PostgreSQL (Oracle 互換) へのデータ移行
注意事項と制限事項は次のとおりです:
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 ソースデータベースが専用回線経由で接続されている場合は、接続情報に仮想 IP アドレス (VIP) の 1 つを設定する必要があります。これにより、Oracle Real Application Clusters (RAC) は専用回線経由でデータ移行タスクに接続できます。 自己管理 Oracle データベースが RAC アーキテクチャを使用し、専用回線、VPN Gateway、Smart Access Gateway、データベースゲートウェイ (DG)、Cloud Enterprise Network (CEN)、または ECS インスタンスから接続されている場合、Single Client Access Name (SCAN) IP アドレスを設定することはできません。接続情報には VIP の 1 つのみを設定できます。この方法を使用する場合、RAC のノード切り替えはサポートされません。 移行するデータに `varchar2` 型の空の文字列が含まれており、Oracle がそれを null として扱う場合、対応するターゲットデータベースのフィールドに非 NULL 制約があると、移行タスクは失敗します。 移行対象のテーブルで FGA (Fine-Grained Audit) ポリシーが有効になっている場合、DTS は ORA_ROWSCN 疑似列を認識できず、移行ジョブが失敗します。
説明 移行対象のテーブルの FGA ポリシーを無効にするか、これらのテーブルからデータを移行しないことを選択できます。 移行オブジェクトの要件: 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。
説明 プライマリキーまたは一意制約のないテーブルのプライマリキーとして Oracle ROWID を使用することもできます。 自己管理 Oracle データベースがバージョン 12c 以降の場合、移行するテーブルの名前は 30 バイトを超えてはなりません。 テーブルレベルでオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数のバッチに分割し、バッチごとに個別のタスクを設定するか、データベース全体を移行するタスクを設定します。
増分移行の場合、Redo ログとアーカイブ ログ: ソースデータベースの操作に関する制限事項: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータとターゲットデータが不整合になります。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。 大きなテキストフィールドを個別に更新することはサポートされておらず、タスクが失敗する原因となります。
|
その他の制限事項 | データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行してください。完全なデータ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースの一部を消費するため、データベースの負荷が増加する可能性があります。 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを停止または解放する必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消します。これにより、タスクが自動的に再開された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 外部テーブルの移行はサポートされていません。 ターゲットの PolarDB for PostgreSQL (Oracle 互換) クラスターは、ソース Oracle データベースの ROWID に対応するために、pg_oid_1498503_index などの一意なインデックスを生成します。したがって、ターゲットクラスターはソース Oracle データベースよりも多くのインデックスを持ちます。 ターゲットの PolarDB for PostgreSQL (Oracle 互換) クラスターは、文字列終端文字 ('\0') の書き込みをサポートしていません。移行するデータにこの終端文字が含まれている場合、DTS はそれをターゲットデータベースに書き込みません。これにより、データの不整合が発生します。 ソース Oracle データベースの CHECK 制約がターゲットの PolarDB for PostgreSQL (Oracle 互換) クラスターに移行されると、非 NULL 制約に変換されます。 ソースデータベースとターゲットデータベースの文字セットに互換性があることを確認してください。そうでない場合、データの不整合やタスクの失敗が発生する可能性があります。 DTS のスキーマ移行機能を使用してください。そうしないと、互換性のないデータの型が原因でタスクが失敗する可能性があります。 ソースデータベースとターゲットデータベースのタイムゾーンは同じである必要があります。 増分移行中に Oracle Data Pump を使用してソースデータベースにデータをインポートすることはサポートされていません。これにより、データが失われる可能性があります。 ユーザー定義型は、ターゲットの PolarDB for PostgreSQL (Oracle 互換) クラスターに移行できます。Oracle によって自動的に生成される型オブジェクト (組み込みオブジェクト) は移行されません。
説明 PolarDB for PostgreSQL (Oracle 互換) クラスターはすでに Oracle の組み込みオブジェクトをサポートしているため、移行する必要はありません。 DTS はデータコンテンツを検証しますが、シーケンスなどのメタデータの検証はサポートしていません。このメタデータは自分で検証する必要があります。 ワークロードを宛先インスタンスに切り替えた後、新しいシーケンスはソースシーケンスの最大値から増分されません。切り替え前に宛先データベースのシーケンス値を更新する必要があります。詳細については、「宛先データベースのシーケンス値を更新する」をご参照ください。 タスクに完全移行または増分移行が含まれ、移行対象のテーブルに外部キー、トリガー、またはイベントトリガーが含まれている場合、DTS はセッションレベルで session_replication_role パラメーターを一時的に replica に設定します。これは、ターゲットデータベースアカウントが特権アカウントであるか、スーパーユーザー権限を持っている場合に発生します。アカウントにこれらの権限がない場合は、ターゲットデータベースでパラメーターを手動で replica に設定する必要があります。この期間中に、ソースデータベースでカスケード更新または削除操作が発生すると、データの不整合が発生する可能性があります。DTS 移行タスクが解放された後、session_replication_role パラメーターを origin に戻すことができます。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
自己管理 Oracle データベースから MySQL へのデータ移行
ターゲットデータベースが ApsaraDB RDS for MySQL インスタンスや自己管理 MySQL データベースなどの MySQL データベースである場合、注意事項と制限事項は次のとおりです:
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 ソースデータベースが専用回線経由で接続されている場合は、接続情報に仮想 IP アドレス (VIP) の 1 つを設定する必要があります。これにより、Oracle Real Application Clusters (RAC) は専用回線経由でデータ移行タスクに接続できます。 自己管理 Oracle データベースが RAC アーキテクチャを使用し、専用回線、VPN Gateway、Smart Access Gateway、データベースゲートウェイ (DG)、Cloud Enterprise Network (CEN)、または ECS インスタンスから接続されている場合、Single Client Access Name (SCAN) IP アドレスを設定することはできません。接続情報には VIP の 1 つのみを設定できます。この方法を使用する場合、RAC のノード切り替えはサポートされません。 移行するデータに `varchar2` 型の空の文字列が含まれており、Oracle がそれを null として扱う場合、対応するターゲットデータベースのフィールドに非 NULL 制約があると、移行タスクは失敗します。 移行対象のテーブルで FGA (Fine-Grained Audit) ポリシーが有効になっている場合、DTS は ORA_ROWSCN 疑似列を認識できず、移行ジョブが失敗します。
説明 移行対象のテーブルの FGA ポリシーを無効にするか、これらのテーブルからデータを移行しないことを選択できます。 移行オブジェクトの要件: 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 自己管理 Oracle データベースがバージョン 12c 以降の場合、移行するテーブルの名前は 30 バイトを超えてはなりません。 テーブルレベルでオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数のバッチに分割し、バッチごとに個別のタスクを設定するか、データベース全体を移行するタスクを設定します。
増分移行の場合、Redo ログとアーカイブ ログ: ソースデータベースの操作に関する制限事項: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータとターゲットデータが不整合になります。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。 大きなテキストフィールドを個別に更新することはサポートされておらず、タスクが失敗する原因となります。
|
その他の制限事項 | 増分移行中に Oracle Data Pump を使用してソースデータベースにデータをインポートすることはサポートされていません。これにより、データが失われる可能性があります。 外部テーブルの移行はサポートされていません。 PACKAGE、PACKAGE_BODY、MATERIALIZED_VIEW、SYNONYM、TYPE、TYPE_BODY、FUNCTION、PROCEDURE、SEQUENCE、VIEW、TABLE_COMMENT、COLUMN_COMMENT、および TRIGGER の移行はサポートされていません。 移行するデータに、珍しい文字や絵文字など、4 バイトのストレージを必要とするコンテンツが含まれている場合、ターゲットデータベースとテーブルは `utf8mb4` 文字セットを使用する必要があります。
説明 DTS を使用してスキーマ移行を行う場合は、ターゲットデータベースのインスタンスレベルのパラメーター character_set_server を `utf8mb4` に設定します。 データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行してください。完全なデータ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースの一部を消費するため、データベースの負荷が増加する可能性があります。 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを停止または解放する必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消します。これにより、タスクが自動的に再開された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 DDL 文がターゲットデータベースへの書き込みに失敗した場合、DTS タスクは実行を継続します。失敗した DDL 文については、タスクログを確認する必要があります。タスクログの表示方法の詳細については、「タスクログのクエリ」をご参照ください。 ソースデータベースとターゲットデータベースの文字セットに互換性があることを確認してください。そうでない場合、データの不整合やタスクの失敗が発生する可能性があります。 DTS のスキーマ移行機能を使用してください。そうしないと、互換性のないデータの型が原因でタスクが失敗する可能性があります。 ソースデータベースとターゲットデータベースのタイムゾーンは同じである必要があります。 大文字と小文字のみが異なる名前のフィールドをターゲットの MySQL データベースの同じテーブルに書き込むと、MySQL の列名は大文字と小文字を区別しないため、移行結果が期待どおりにならない場合があります。 データ移行が完了した後 (インスタンスの ステータス が 完了 になった後)、analyze table <table_name> コマンドを実行して、すべてのデータがターゲットテーブルに書き込まれたことを確認します。たとえば、ターゲットの MySQL データベースでプライマリ/セカンダリのフェールオーバーがトリガーされた場合、データはメモリにのみ書き込まれ、データが失われる可能性があります。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | ターゲットデータベースが ApsaraDB RDS for MySQL の場合 ApsaraDB RDS for MySQL インスタンスは、英語のテーブル名の大文字と小文字を区別しません。大文字の英字を使用してテーブルを作成すると、ApsaraDB RDS for MySQL はテーブルを作成する前にテーブル名を小文字に変換します。 ソース Oracle データベースに、名前は同じで大文字と小文字が異なるテーブルが含まれている場合、スキーマ移行中にオブジェクト名の競合が発生し、オブジェクトがすでに存在することを示すメッセージが表示されることがあります。これが発生した場合は、DTS が提供するオブジェクト名マッピング機能を使用して、移行オブジェクトを設定するときに競合するオブジェクトの名前を変更します。テーブル名を大文字に変換します。詳細については、「テーブルと列のマッピング」をご参照ください。 DTS は ApsaraDB RDS for MySQL インスタンスにデータベースを自動的に作成します。移行するデータベースの名前が ApsaraDB RDS for MySQL の命名規則に準拠していない場合は、移行タスクを設定する前に ApsaraDB RDS for MySQL インスタンスにデータベースを作成する必要があります。詳細については、「データベースの管理」をご参照ください。
|
自己管理 Oracle データベースから PolarDB for MySQL へのデータ移行
ターゲットクラスターが PolarDB for MySQL クラスターである場合、注意事項と制限事項は次のとおりです:
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 ソースデータベースが専用回線経由で接続されている場合は、接続情報に仮想 IP アドレス (VIP) の 1 つを設定する必要があります。これにより、Oracle Real Application Clusters (RAC) は専用回線経由でデータ移行タスクに接続できます。 自己管理 Oracle データベースが RAC アーキテクチャを使用し、専用回線、VPN Gateway、Smart Access Gateway、データベースゲートウェイ (DG)、Cloud Enterprise Network (CEN)、または ECS インスタンスから接続されている場合、Single Client Access Name (SCAN) IP アドレスを設定することはできません。接続情報には VIP の 1 つのみを設定できます。この方法を使用する場合、RAC のノード切り替えはサポートされません。 移行するデータに `varchar2` 型の空の文字列が含まれており、Oracle がそれを null として扱う場合、対応するターゲットデータベースのフィールドに非 NULL 制約があると、移行タスクは失敗します。 移行対象のテーブルで FGA (Fine-Grained Audit) ポリシーが有効になっている場合、DTS は ORA_ROWSCN 疑似列を認識できず、移行ジョブが失敗します。
説明 移行対象のテーブルの FGA ポリシーを無効にするか、これらのテーブルからデータを移行しないことを選択できます。 移行オブジェクトの要件: 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 自己管理 Oracle データベースがバージョン 12c 以降の場合、移行するテーブルの名前は 30 バイトを超えてはなりません。 テーブルレベルでオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数のバッチに分割し、バッチごとに個別のタスクを設定するか、データベース全体を移行するタスクを設定します。
増分移行の場合、Redo ログとアーカイブ ログ: ソースデータベースの操作に関する制限事項: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータとターゲットデータが不整合になります。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。 大きなテキストフィールドを個別に更新することはサポートされておらず、タスクが失敗する原因となります。
|
その他の制限事項 | 増分移行中に Oracle Data Pump を使用してソースデータベースにデータをインポートすることはサポートされていません。これにより、データが失われる可能性があります。 外部テーブルの移行はサポートされていません。 PACKAGE、PACKAGE_BODY、MATERIALIZED_VIEW、SYNONYM、TYPE、TYPE_BODY、FUNCTION、PROCEDURE、SEQUENCE、VIEW、TABLE_COMMENT、COLUMN_COMMENT、および TRIGGER の移行はサポートされていません。 移行するデータに、珍しい文字や絵文字など、4 バイトのストレージを必要とするコンテンツが含まれている場合、ターゲットデータベースとテーブルは `utf8mb4` 文字セットを使用する必要があります。
説明 DTS を使用してスキーマ移行を行う場合は、ターゲットデータベースのインスタンスレベルのパラメーター character_set_server を `utf8mb4` に設定します。 データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行してください。完全なデータ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースの一部を消費するため、データベースの負荷が増加する可能性があります。 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを停止または解放する必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消します。これにより、タスクが自動的に再開された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 DDL 文がターゲットデータベースへの書き込みに失敗した場合、DTS タスクは実行を継続します。失敗した DDL 文については、タスクログを確認する必要があります。タスクログの表示方法の詳細については、「タスクログのクエリ」をご参照ください。 ソースデータベースとターゲットデータベースの文字セットに互換性があることを確認してください。そうでない場合、データの不整合やタスクの失敗が発生する可能性があります。 DTS のスキーマ移行機能を使用してください。そうしないと、互換性のないデータの型が原因でタスクが失敗する可能性があります。 ソースデータベースとターゲットデータベースのタイムゾーンは同じである必要があります。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
特殊なケース | ターゲットデータベースが PolarDB for MySQL の場合: PolarDB for MySQL クラスターは、英語のテーブル名の大文字と小文字を区別しません。大文字の英字を使用してテーブルを作成すると、PolarDB for MySQL はテーブルを作成する前にテーブル名を小文字に変換します。 ソース Oracle データベースに、名前は同じで大文字と小文字が異なるテーブルが含まれている場合、スキーマ移行中にオブジェクト名の競合が発生し、オブジェクトがすでに存在することを示すメッセージが表示されることがあります。これが発生した場合は、DTS が提供するオブジェクト名マッピング機能を使用して、移行オブジェクトを設定するときに競合するオブジェクトの名前を変更します。テーブル名を大文字に変換します。詳細については、「テーブルと列のマッピング」をご参照ください。 DTS は PolarDB for MySQL にデータベースを自動的に作成します。移行するデータベースの名前が PolarDB for MySQL の命名規則に準拠していない場合は、移行タスクを設定する前に PolarDB for MySQL にデータベースを作成する必要があります。詳細については、「データベースの管理」をご参照ください。
|
自己管理 Oracle データベースから AnalyticDB for PostgreSQL へのデータ移行
ターゲットインスタンスが AnalyticDB for PostgreSQL インスタンスである場合、注意事項と制限事項は次のとおりです:
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 ソースデータベースが専用回線経由で接続されている場合は、接続情報に仮想 IP アドレス (VIP) の 1 つを設定する必要があります。これにより、Oracle Real Application Clusters (RAC) は専用回線経由でデータ移行タスクに接続できます。 自己管理 Oracle データベースが RAC アーキテクチャを使用し、専用回線、VPN Gateway、Smart Access Gateway、データベースゲートウェイ (DG)、Cloud Enterprise Network (CEN)、または ECS インスタンスから接続されている場合、Single Client Access Name (SCAN) IP アドレスを設定することはできません。接続情報には VIP の 1 つのみを設定できます。この方法を使用する場合、RAC のノード切り替えはサポートされません。 移行するデータに `varchar2` 型の空の文字列が含まれており、Oracle がそれを null として扱う場合、対応するターゲットデータベースのフィールドに非 NULL 制約があると、移行タスクは失敗します。 移行対象のテーブルで FGA (Fine-Grained Audit) ポリシーが有効になっている場合、DTS は ORA_ROWSCN 疑似列を認識できず、移行ジョブが失敗します。
説明 移行対象のテーブルの FGA ポリシーを無効にするか、これらのテーブルからデータを移行しないことを選択できます。 移行オブジェクトの要件: 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 自己管理 Oracle データベースがバージョン 12c 以降の場合、移行するテーブルの名前は 30 バイトを超えてはなりません。 テーブルレベルでオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数のバッチに分割し、バッチごとに個別のタスクを設定するか、データベース全体を移行するタスクを設定します。
増分移行の場合、Redo ログとアーカイブ ログ: ソースデータベースの操作に関する制限事項: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータとターゲットデータが不整合になります。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。 大きなテキストフィールドを個別に更新することはサポートされておらず、タスクが失敗する原因となります。
|
その他の制限事項 | テーブルレベルの移行のみがサポートされています。追記最適化 (AO) テーブルは、ターゲットテーブルとしてサポートされていません。 部分的なテーブル移行に列マッピングを使用する場合、またはソースとターゲットのテーブルスキーマに一貫性がない場合、ソースには存在するがターゲットには存在しない列のデータは失われます。 ターゲットの AnalyticDB for PostgreSQL インスタンスは、文字列終端文字 ('\0') の書き込みをサポートしていません。移行するデータにこの終端文字が含まれている場合、DTS はそれをターゲットデータベースに書き込みません。これにより、データの不整合が発生します。 外部テーブルの移行はサポートされていません。 PACKAGE、PACKAGE_BODY、MATERIALIZED_VIEW、SYNONYM、TYPE、TYPE_BODY、PROCEDURE、および INDEX の移行はサポートされていません。 増分移行中に Oracle Data Pump を使用してソースデータベースにデータをインポートすることはサポートされていません。これにより、データが失われる可能性があります。 移行対象のテーブルにプライマリキーが含まれている場合、ターゲットテーブルのプライマリキー列はソーステーブルのプライマリキー列と同じである必要があります。移行対象のテーブルにプライマリキーが含まれていない場合、ターゲットテーブルのプライマリキー列と分散キーは同じである必要があります。 ターゲットテーブルの一意なキー (プライマリキー列を含む) には、その分散キーのすべての列が含まれている必要があります。 データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行してください。完全なデータ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースの一部を消費するため、データベースの負荷が増加する可能性があります。 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを停止または解放する必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消します。これにより、タスクが自動的に再開された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
自己管理 Oracle データベースから Message Queue for Apache Kafka または自己管理 Kafka クラスターへのデータ移行
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 ソースデータベースが専用回線経由で接続されている場合は、接続情報に仮想 IP アドレス (VIP) の 1 つを設定する必要があります。これにより、Oracle Real Application Clusters (RAC) は専用回線経由でデータ移行タスクに接続できます。 自己管理 Oracle データベースが RAC アーキテクチャを使用し、専用回線、VPN Gateway、Smart Access Gateway、データベースゲートウェイ (DG)、Cloud Enterprise Network (CEN)、または ECS インスタンスから接続されている場合、Single Client Access Name (SCAN) IP アドレスを設定することはできません。接続情報には VIP の 1 つのみを設定できます。この方法を使用する場合、RAC のノード切り替えはサポートされません。 移行するデータに `varchar2` 型の空の文字列が含まれており、Oracle がそれを null として扱う場合、対応するターゲットデータベースのフィールドに非 NULL 制約があると、移行タスクは失敗します。 移行対象のテーブルで FGA (Fine-Grained Audit) ポリシーが有効になっている場合、DTS は ORA_ROWSCN 疑似列を認識できず、移行ジョブが失敗します。
説明 移行対象のテーブルの FGA ポリシーを無効にするか、これらのテーブルからデータを移行しないことを選択できます。 移行オブジェクトの要件: 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 自己管理 Oracle データベースがバージョン 12c 以降の場合、移行するテーブルの名前は 30 バイトを超えてはなりません。 テーブルレベルでオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数のバッチに分割し、バッチごとに個別のタスクを設定するか、データベース全体を移行するタスクを設定します。
増分移行の場合、Redo ログとアーカイブ ログ: ソースデータベースの操作に関する制限事項: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータとターゲットデータが不整合になります。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。 大きなテキストフィールドを個別に更新することはサポートされておらず、タスクが失敗する原因となります。
|
その他の制限事項 | 増分移行中に Oracle Data Pump を使用してソースデータベースにデータをインポートすることはサポートされていません。これにより、データが失われる可能性があります。 外部テーブルの移行はサポートされていません。 INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK、TABLE_COMMENT、および COLUMN_COMMENT の移行はサポートされていません。 データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行してください。完全なデータ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースの一部を消費するため、データベースの負荷が増加する可能性があります。 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを停止または解放する必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消します。これにより、タスクが自動的に再開された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 移行中に、ターゲットの Kafka クラスターがスケールアウトまたはスケールインされた場合は、インスタンスを再起動する必要があります。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|
自己管理 Oracle データベース間のデータ移行
ターゲットデータベースも Oracle データベースである場合、注意事項と制限事項は次のとおりです:
タイプ | 説明 |
ソースデータベースの制限事項 | 帯域幅要件: ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が影響を受けます。 ソースデータベースが専用回線経由で接続されている場合は、接続情報に仮想 IP アドレス (VIP) の 1 つを設定する必要があります。これにより、Oracle Real Application Clusters (RAC) は専用回線経由でデータ移行タスクに接続できます。 自己管理 Oracle データベースが RAC アーキテクチャを使用し、専用回線、VPN Gateway、Smart Access Gateway、データベースゲートウェイ (DG)、Cloud Enterprise Network (CEN)、または ECS インスタンスから接続されている場合、Single Client Access Name (SCAN) IP アドレスを設定することはできません。接続情報には VIP の 1 つのみを設定できます。この方法を使用する場合、RAC のノード切り替えはサポートされません。 移行するデータに `varchar2` 型の空の文字列が含まれており、Oracle がそれを null として扱う場合、対応するターゲットデータベースのフィールドに非 NULL 制約があると、移行タスクは失敗します。 移行対象のテーブルで FGA (Fine-Grained Audit) ポリシーが有効になっている場合、DTS は ORA_ROWSCN 疑似列を認識できず、移行ジョブが失敗します。
説明 移行対象のテーブルの FGA ポリシーを無効にするか、これらのテーブルからデータを移行しないことを選択できます。 移行オブジェクトの要件: 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが表示される可能性があります。 自己管理 Oracle データベースがバージョン 12c 以降の場合、移行するテーブルの名前は 30 バイトを超えてはなりません。 テーブルレベルでオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数のバッチに分割し、バッチごとに個別のタスクを設定するか、データベース全体を移行するタスクを設定します。
増分移行の場合、Redo ログとアーカイブ ログ: ソースデータベースの操作に関する制限事項: スキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータとターゲットデータが不整合になります。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択します。 大きなテキストフィールドを個別に更新することはサポートされておらず、タスクが失敗する原因となります。
|
その他の制限事項 | 増分移行中に Oracle Data Pump を使用してソースデータベースにデータをインポートすることはサポートされていません。これにより、データが失われる可能性があります。 外部テーブルの移行はサポートされていません。 スキーマ移行タスクは、スキーマの移行をサポートしていません。 データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行してください。完全なデータ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースの一部を消費するため、データベースの負荷が増加する可能性があります。 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。その結果、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを停止または解放する必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消します。これにより、タスクが自動的に再開された場合に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整されるとき、DTS インスタンスのパラメーターのみが変更されます。データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。
|