既知の制限事項と推奨事項

このページでは、既知の制限事項（ 主キーや 外部キーとトリガーなどのエンティティの処理に関する特別な考慮事項を含む）と、Database Migration Service を使用した異種 Oracle 移行の 推奨事項について説明します。

移行されないデータ

  • ユーザーと権限は移行されません。
  • アクティブな移行ジョブ中に発生したスキーマの変更は、自動的に移行されません。移行中にスキーマを変更する場合は、まずスキーマの変更でコンバージョン ワークスペースを更新してから、関連する移行ジョブを更新する必要があります。詳細については、 更新されたスキーマまたはテーブルを移行ジョブに追加するをご覧ください。
  • SAVEPOINT ステートメントはサポートされていません。ロールバックが発生した場合にデータの不一致が発生する可能性があります。
  • Database Migration Service はユーザー定義データ型を複製しますが、ユーザー定義型の派生元の基本のデータ型のみを保存します。たとえば、VARCHAR2 データ型に基づいて USERNAME データ型を定義すると、データは VARCHAR として宛先に保存されます。

データベース、トランザクション、データの整合性

  • Database Migration Service は各トランザクションを発生時に複製しないため、移行は結果整合性になります。移行では、複数のテーブルからデータが取り込まれます。宛先にデータが読み込まれる順序は異なる場合がありますが、ソースへの書き込みが停止され、移行バッファがクリアされると、ソースと再調整されます。
  • 異種 Oracle 移行の場合、Database Migration Service は移行ジョブごとに 1 つのデータベースのみを移行できます。
  • Database Migration Service は Oracle マルチテナント アーキテクチャ（CDB/PDB）をサポートしていますが、移行ジョブごとに移行できるプラガブル データベースは 1 つだけです。
  • Oracle Label Security（OLS）は複製されません。
  • 移行プロセス中にソース データベースでロールバックされたトランザクションは、宛先で一時的に表示されることがあります（トランザクションが十分に長い場合）。
  • Database Migration Service は、Oracle Real Application Clusters（RAC）環境の単一クライアント アクセス名（SCAN）機能を使用するデータベースへの直接接続をサポートしていません。このような環境でパブリック IP 許可リスト接続を使用する場合の解決策については、 Oracle SCAN エラーのトラブルシューティングをご覧ください。

データのエンコード

  • Database Migration Service は、移行先データベースの UTF8 セット エンコードのみをサポートしています。UTF8 エンコード セットに含まれていない文字を含むスキーマ名とテーブル名はサポートされていません。
  • Database Migration Service は、Oracle データベース用に次の文字セット エンコードをサポートしています。
    • AL16UTF16
    • AL32UTF8
    • IN8ISCII
    • IW8ISO8859P8
    • JA16SJIS
    • JA16SJISTILDE
    • KO16MSWIN949
    • US7ASCII
    • UTF8
    • WE8ISO8859P1
    • WE8ISO8859P9
    • WE8ISO8859P15
    • WE8MSWIN1252
    • ZHT16BIG5

テーブル、スキーマ、その他のオブジェクト

  • 移行中、データ、スキーマ、メタデータに対するデータ定義言語（DDL）の変更はサポートされていません。移行中にスキーマを更新する場合は、変更をコンバージョン ワークスペースに pull し、コードを変換して、移行先をクリーンアップし、移行ジョブを再度実行する必要があります。
  • 英数字またはアンダースコア（_）以外の文字を含むテーブル列名はサポートされていません。
  • テーブルまたは列の名前の最大長は 30 文字です。 Database Migration Service は、この上限を超えるテーブルや、この上限を超える名前の列を含むテーブルを複製できません。
  • 索引構成表（IOT）はサポートされていません。
  • グローバル一時テーブルを使用するには、pgtt PostgreSQL 拡張機能をインストールして、宛先に作成する必要があります。
  • 列のタイプが BFILE の場合、ファイルへのパスのみが複製されます。ファイルの内容はレプリケートされません。
  • Oracle 11g では、データ型 ANYDATA または UDT の列のあるテーブルはサポートされておらず、テーブル全体が複製されません。
  • dbms_job または dbms_scheduler を使用してスケジュールされたジョブは移行されません。
  • マテリアライズド ビューの定義は移行されますが、マテリアライズド データは移行されません。移行が完了したら、マテリアライズド ビューを更新して、移行されたテーブルのデータを入力します。
  • シーケンス値は移行されますが、移行が完了する前にソース データベースの値が更新される可能性があります。移行が完了したら、移行先インスタンスのシーケンス値を更新して、移行元データベースの値と一致させます。
  • 移行ジョブは 10,000 テーブルに制限されています。
  • 行のサイズ上限は 100 MB です。100 MB の上限を超える行は移行されず、移行ジョブでエラーとして表示されます。
  • 移行の開始後に作成されたテーブルは、自動的に移行されません。まず、コンバージョン ワークスペースでスキーマを pull し、変換された定義を宛先に適用して、移行ジョブを更新する必要があります。
  • バイナリ列を含み、主キーがないソーステーブルは、継続的な移行でのデータ移行ではサポートされていません。
  • Oracle は仮想列の値を REDO ログに書き込まないため、データ移行中に仮想列（GENERATED ALWAYS AS (...) VIRTUAL）は複製されません。仮想列が複合主キーの一部である場合、レプリケーション中に主キーとして使用されるのは非仮想列のみです。

データ型の制限

Oracle の移行では、次のデータ型はサポートされていません。

  • ANYDATA（Oracle 11g では、ANYDATA を含むテーブルは完全にサポートされておらず、複製されません）。
  • BFILE
  • INTERVAL DAY TO SECOND
  • INTERVAL YEAR TO MONTH
  • LONG/LONG RAW
  • SDO_GEOMETRY
  • UDT
  • UROWID
  • XMLTYPE
  • TIMESTAMP のゼロ日付

主キーに関する考慮事項

主キーのないテーブルでは、一貫したレプリケーションが保証されません。Database Migration Service は、主キーを持つテーブルのみを移行します。ソース データベースに主キーのないテーブルが含まれている場合、Database Migration Service コンバージョン ワークスペースは、 ソースコードとスキーマを変換するときに、宛先テーブルに不足している主キーを自動的に作成します。この自動プロセスでは、ソーステーブルが次の条件を満たしている必要があります。

  • 主キーがまだない。
  • null 値を許容しない列がない UNIQUE 制約を設定しないでください。
  • null 値を許容しない列を含む UNIQUE インデックスを作成しないでください。

テーブルがこれらの要件を満たしていない場合は、 変換された PostgreSQL スキーマのテーブルに、不足している主キーを手動で追加する必要があります。 GENERATE_MISSING_PK 変換ディレクティブを使用して、主キーの自動生成を無効にすることもできます。

継続的な移行の場合: バイナリ列を含み、主キーがないソーステーブルは、継続的な移行でのデータ移行ではサポートされていません。

以前のコンバージョン ワークスペースを使用する場合は、移行を開始する前に、移行先データベースの変換されたテーブルに主キー制約を手動で作成する必要があります。詳細については、 以前のコンバージョン ワークスペースをご覧ください。

外部キーとトリガーに関する考慮事項

ソース データベースに外部キーとトリガーが存在すると、データの完全性の問題が発生したり、移行ジョブが失敗したりする可能性があります。これらの問題は、 移行ユーザーに REPLICATION オプションを使用して外部キーとトリガーをスキップすることで回避できます。または、移行先データベースのすべての外部キーとトリガーを削除し、移行が完了したら再作成することもできます。

トリガー

Database Migration Service によって複製されたデータには、移行元データベースのトリガーによって行われた変更がすでに組み込まれています。移行先でトリガーが有効になっていると、トリガーが再度実行されてデータが操作される可能性があり、データの完全性や重複の問題が発生する可能性があります。

外部キー

Database Migration Service はトランザクション方式でデータを複製しないため、テーブルが順序どおりに移行されない場合があります。外部キーが存在し、外部キーを使用する子テーブルが親テーブルよりも前に移行されると、レプリケーション エラーが発生することがあります。

推奨事項

  • 移行先の Cloud SQL データベースを作成するときは、移行のニーズを満たすのに十分なコンピューティング リソースとメモリリソースを使用してください。少なくともデュアルコア CPU を搭載したマシンタイプをおすすめします。

    たとえば、マシン名が db-custom で、2 個の CPU と 3,840 MB の RAM を搭載している場合、マシンタイプ名の形式は db-custom-2-3840 になります。

  • 移行中に、移行先の Cloud SQL データベースは書き込み可能になり、必要に応じてデータ操作言語（DML）の変更を適用できます。移行プロセスが中断したり、データの完全性に影響する可能性があるため、データベース構成やテーブル構造を変更しないでください。

割り当て

  • 接続プロファイルは最大 2,000 個、移行ジョブは最大 1,000 個まで存在できます。スペースを増やすには、移行ジョブ（完了したものを含む）と接続プロファイルを削除します。