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

このページでは、既知の制限事項（ 主キーや 外部キーとトリガーなどのエンティティの処理に関する特別な考慮事項など）と、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
    • JA16SJIS
    • 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 の上限を超える行は移行されず、移行ジョブでエラーとして表示されます。
  • 移行の開始後に作成されたテーブルは自動的に移行されません。まず、コンバージョン ワークスペースでスキーマを取得し、変換された定義を宛先に適用して、移行ジョブを更新する必要があります。

データ型の制限

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 コンバージョン ワークスペースによって、移行先テーブルに不足している主キーが自動的に作成されます。

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

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

移行元データベースに存在する外部キーとトリガーにより、データの整合性の問題が発生したり、移行ジョブが失敗したりする可能性があります。これらの問題を回避するには、 移行ユーザーの 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 個の移行ジョブを維持できます。この上限に達した後で他の作業を行うには、移行ジョブ（完了したジョブを含む）または接続プロファイルを削除できます。