コンバージョン ワークスペースを使用すると、移行元のデータベースのスキーマとオブジェクトを、移行先のデータベースと互換性のある SQL 構文に変換できます。このページでは、Database Migration Service のコンバージョン ワークスペースの概要について説明します。
コンバージョンの概要では、スキーマ変換の進捗状況を横断的に確認できます。
確定的なコードとスキーマの変換でサポートされるオブジェクトには、確定的なスキーマ変換でサポートされている Oracle オブジェクトが一覧表示されます。
インタラクティブな SQL エディタでは、コンバージョン ワークスペース エディタで直接変更できるオブジェクトについて説明します。
Gemini を活用した変換機能では、生成 AI サポートを統合してスキーマ変換プロセスを迅速化する方法について説明します。
変換マッピング ファイルのセクションでは、確定的スキーマ変換のルールをオーバーライドするために使用できるカスタマイズ ディレクティブの概要について説明します。
以前の変換ワークスペースでは、インタラクティブな SQL エディタをサポートしていない以前のワークスペースについて説明します。
Oracle の移行ではサポートされていないデータ型があります。詳細については、 データ型の既知の制限事項をご覧ください。
コンバージョンの進捗状況の概要
コンバージョン ワークスペースの包括的な概要情報: 未解決または解決済みのコンバージョンの問題の合計数、Gemini による拡張、コンバージョン プロセスの全体的な健全性に関する分析情報を確認できます。
![コンバージョン ワークスペースの画面。[コンバージョンの概要] タブには、変換されたオブジェクトの数、コンバージョンに関する問題、Gemini による拡張コンバージョンが表示されます。](https://cloud.google.com/static/database-migration/docs/images/htm/conversion_workspace_overview.png?authuser=6&hl=ja)
このビューを使用すると、スキーマ内のオブジェクトをタイプ、問題の重大度、必要なアクション、変換ステータスでフィルタできます。
コンバージョンの概要を使用してコンバージョン結果を調べる方法については、 コンバージョン ワークスペースの操作をご覧ください。
決定論的コードとスキーマの変換
変換ワークスペースを作成すると、Database Migration Service は、一連の確定的変換ルールを使用して最初のスキーマ変換をすぐに実行します。このルールでは、特定の Oracle データ型とオブジェクトが特定の PostgreSQL データ型とオブジェクトにマッピングされます。このプロセスは、使用可能な Oracle データベース オブジェクトの非常に特定のサブセットをサポートしています。
確定的コード変換では、次の Oracle データベース オブジェクトがサポートされています。
サポートされている Oracle スキーマ要素
- 制約
- インデックス（テーブルと同じスキーマで作成されたインデックスのみ）
- マテリアライズド ビュー
- オブジェクトの種類（部分的にサポート）
- シーケンス
- 類義語
- テーブル
- ビュー
サポートされている Oracle コード要素
- トリガー（テーブルレベルのみ）
- パッケージ
- 関数
- ストアド プロシージャ
インタラクティブ SQL エディタ
インタラクティブな SQL エディタを使用すると、変換された PostgreSQL 構文を Database Migration Service で直接変更できます。コンバージョンに関する問題を解決したり、ニーズに合わせてスキーマを調整したりできます。一部のオブジェクトは、組み込みエディタで変更できません。
編集可能な Oracle オブジェクト
ソース データベースのコードとスキーマを変換したら、インタラクティブ エディタを使用して、特定のタイプのオブジェクトに対して生成された SQL を変更できます。エディタでサポートされている Oracle オブジェクトは次のとおりです。
- テーブル トリガー（権限が必要）
- マテリアライズド ビュー
- パッケージ
- 関数、ストアド プロシージャ
- 類義語
- ビュー
- 制約
- インデックス
- シーケンス
また、一部のオブジェクトは変換されますが、Database Migration Service 内で直接編集することはできません。このようなオブジェクトを変更するには、 変換されたスキーマとコードを適用した後、移行先データベースで直接更新を行う必要があります。
編集がサポートされていないオブジェクト:
- ユーザー定義オブジェクト タイプ
- テーブル
- スキーマ
Gemini でコードとスキーマの変換を高速化する
Database Migration Service は、Gemini for Workspace をコンバージョン ワークスペースに統合し、次の領域でコンバージョン プロセスを高速化および改善します。 Google Cloud
Gemini を活用した自動変換で決定的変換の結果を強化し、AI の力を活用して PostgreSQL コードで必要な手動調整の数を大幅に減らします。
コンバージョン アシスタントを使用してコードの説明機能を提供します。コンバージョン アシスタントは、コンバージョン ロジックの理解、コンバージョンの問題の修正案の提案、変換されたコードの最適化に役立つ一連の専用プロンプトです。
Gemini コード変換の候補を使用すると、コンバージョンの問題の修正を迅速に行うことができます。これは、コンバージョンの問題を修正する際に Gemini モデルが学習し、ワークスペース内の他の不具合のあるオブジェクトの変更を提案するメカニズムです。
Gemini によるコンバージョンの詳細については、次のページをご覧ください。
コンバージョン マッピング ファイル
コンバージョン ロジックは、コンバージョン マッピング ファイルでカスタマイズできます。変換マッピング ファイルは、Oracle オブジェクトを PostgreSQL オブジェクトに変換する方法に関する正確な指示（変換ディレクティブ）を含むテキスト ファイルです。
サポートされているコンバージョン ディレクティブ
Database Migration Service は、変換マッピング ファイルの次の変換ディレクティブをサポートしています。
EXPORT_SCHEMA
EXPORT_SCHEMA は、すべてのコンバージョン マッピング ファイルに必須のディレクティブです。Database Migration Service では、移行元のスキーマが正しい移行先スキーマに変換されるように、この指示が必要です。コンバージョン マッピング ファイルに次の行が含まれていることを確認します。
EXPORT_SCHEMA 1
SCHEMA
Database Migration Service は、変換ディレクティブで変更する必要があるオブジェクトを含むスキーマを特定できる必要があります。SCHEMA ディレクティブを使用すると、コンバージョン フローが次のように調整されます。
- Database Migration Service は、このスキーマのみを変換します。1 つの変換ワークスペースで他のスキーマを変換する必要がある場合は、異なるスキーマの複数のファイルをアップロードする必要があります。
- ファイルで指定された他のカスタマイズ ディレクティブはすべて、この特定のスキーマ内のオブジェクトにのみ適用されます。
形式は次のようにします。
SCHEMA SCHEMA_NAME
ここで、SCHEMA_NAME はソース データベースのスキーマの名前です。
- このディレクティブをコンバージョン マッピング ファイルに含めると、すべてのカスタマイズがこの特定のスキーマに含まれるオブジェクトにのみ適用されます。他のスキーマ内のオブジェクトをカスタマイズする場合は、複数のコンバージョン マッピング ファイルを作成して、コンバージョン ワークスペースにアップロードする必要があります。
- このディレクティブをスキップする場合は、他のコンバージョン ディレクティブによって変更されるオブジェクトに明示的なスキーマ名を指定する必要があります。たとえば、
REPLACE_TABLESディレクティブにSOURCE_TABLE_NAMEを使用する代わりに、"SCHEMA_NAME.SOURCE_TABLE_NAME"を使用する必要があります。
DATA_TYPE
このディレクティブを使用すると、サポートされているデータ型を Oracle 構文と PostgreSQL 構文の間に明示的にマッピングできます。このディレクティブでは、マッピングのリストをカンマ区切りで指定する必要があります。定義全体を 1 行で指定する必要がありますが、構成ファイルには複数の DATA_TYPE ディレクティブを含めることができます。形式は次のようにします。
DATA_TYPE ORACLE_DATA_TYPE1:PGSQL_DATA_TYPE1 DATA_TYPE ORACLE_DATA_TYPE2:PGSQL_DATA_TYPE2...
ここで、ORACLE_DATA_TYPE と PGSQL_DATA_TYPE は、移行で使用する Oracle と PostgreSQL のバージョンでサポートされているデータ型です。サポートされているバージョンについては、 シナリオの概要をご覧ください。
例:
DATA_TYPE REAL:double precision,SMALLINT:integer
Oracle と PostgreSQL のデータ型の詳細については、以下をご覧ください。
- Oracle のドキュメントの Oracle のデータ型。
- PostgreSQL ドキュメントの PostgreSQL のデータ型。
MODIFY_TYPE
MODIFY_TYPE ディレクティブを使用すると、Database Migration Service が移行元テーブルの特定の列をどのデータ型に変換するかを制御できます。このディレクティブでは、マッピングのリストをカンマ区切りで指定します。定義全体を 1 行で指定する必要がありますが、構成ファイルには複数の MODIFY_TYPE ディレクティブを含めます。形式は次のようにします。
MODIFY_TYPE SOURCE_TABLE_NAME1:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE MODIFY_TYPE SOURCE_TABLE_NAME2:COLUMN_NAME:EXPECTED_END_RESULT_DATA_TYPE...
ここで
- SOURCE_TABLE_NAME は、データ型を変更する列を含むテーブルの名前です。
- COLUMN_NAME は、コンバージョン マッピングをカスタマイズする列の名前です。
- EXPECTED_END_RESULT_DATA_TYPE は、変換された列で使用する PostgreSQL データ型です。
例:
MODIFY_TYPE events:dates_and_times:DATETIME,users:pseudonym:TEXT
PG_INTEGER_TYPE
デフォルトでは、Database Migration Service は NUMBER(p,s) 型を PostgreSQL の DECIMAL(p,s) 型に変換します。
この動作は、PG_INTEGER_TYPE ディレクティブで変更できます。値を 1 に設定し、精度とスケール（NUMBER(p,s)）の NUMBER 型をすべて、精度桁数に基づいて PostgreSQL の smallint、integer、または bigint 型に変換します。
コンバージョン マッピング ファイルに次の設定を含めます。
PG_INTEGER_TYPE 1
PG_NUMERIC_TYPE
精度とスケール（NUMBER(p,s)）型を持つすべての NUMBER を PostgreSQL の real 型または float 型に変換する場合は、このディレクティブを 1 に設定します（精度桁数に基づきます）。
このディレクティブを 0 に設定すると、NUMBER(p,s) 値は元の値をそのまま保持し、内部 PostgreSQL データ型を使用します。
コンバージョン マッピング ファイルに次の設定を含めます。
PG_NUMERIC_TYPE 1
DEFAULT_NUMERIC
精度のない NUMBER のデフォルトの変換は、
PG_INTEGER_TYPE ディレクティブも使用しているかどうかによって異なります。
PG_INTEGERディレクティブを使用する場合、精度のないNUMBERはDECIMAL値に変換されます。PG_INTEGERディレクティブを使用しない場合、精度のないNUMBERはBIGINT値に変換されます。
この動作を変更し、DEFAULT_NUMERIC ディレクティブを使用して、指定された精度ポイントのない NUMBER 型に使用するデータ型を指定できます。形式は次のようにします。
DEFAULT_NUMERIC POSTGRESQL_NUMERIC_DATA_TYPE
POSTGRESQL_NUMERIC_DATA_TYPE は、integer、smallint、bigint のいずれかです。
例:
DEFAULT_NUMERIC integer
REPLACE_COLS
REPLACE_COLS ディレクティブを使用して、変換されたスキーマ内の列の名前を変更できます。このディレクティブでは、マッピングのリストをカンマ区切りで指定します。形式は次のようにします。
REPLACE_COLS SOURCE_TABLE_NAME1(SOURCE1_TABLE1_COLUMN_NAME1:DESTINATION_TABLE1_COLUMN_NAME1,SOURCE_TABLE1_COLUMN_NAME2:DESTINATION_TABLE1_COLUMN_NAME2),SOURCE_TABLE_NAME2(SOURCE_TABLE2_COLUMN_NAME1:DESTINATION_TABLE2_COLUMN_NAME1,SOURCE_TABLE2_COLUMN_NAME2:DESTINATION_TABLE2_COLUMN_NAME2)...
ここで
- SOURCE_TABLE_NAME は、名前を変更する列を含むテーブルの名前です。
- SOURCE_COLUMN_NAME は、名前を変更するソース内の列の名前です。
- DESTINATION_COLUMN_NAME は、変換されたスキーマで使用する列の新しい名前です。
例:
REPLACE_COLS events(dates_and_times:event_dates),users(pseudonym:nickname)
REPLACE_TABLES
REPLACE_TABLES ディレクティブを使用して、テーブルの名前を変更したり、新しいスキーマに移動したりできます。このディレクティブでは、スペース区切りのマッピングのリストを指定します。各ユースケースの構文について詳しくは、以下のセクションをご覧ください。
テーブルの名前変更
変換されたスキーマ内のテーブルの名前を変更するには、次の形式を使用します。
REPLACE_TABLES SOURCE_TABLE_NAME1:DESTINATION_TABLE_NAME1 SOURCE_TABLE_NAME2:DESTINATION_TABLE_NAME2
ここで
- SOURCE_TABLE_NAME は、変換されたスキーマで名前を変更するソーステーブルの名前です。
- DESTINATION_TABLE_NAME は、変換されたスキーマで使用するテーブルの新しい名前です。
例:
REPLACE_TABLES "events:login_events" "users:platform_users"
スキーマ間でテーブルを移動する
このディレクティブを使用すると、新しいテーブル名にスキーマ接頭辞を追加して、スキーマ間でテーブルを移動できます。このメカニズムは、変換ファイル全体で SCHEMA ディレクティブを使用する方法に関係なく使用できます。次に例を示します。
REPLACE_TABLES "events:NEW_SCHEMA_NAME.login_events"
データ型のカスタマイズ用のアリアス
変換ディレクティブを使用して Database Migration Service が異なるデータ型を変換する方法を変更する場合（
DATA_TYPE、
MODIFY_TYPE、
PG_NUMERIC_TYPE ディレクティブなどを使用する場合）、ソース SQL データ型の代わりにエイリアスを使用できます。
次のセクションを開くと、Database Migration Service でサポートされているデータ型のエイリアスのリストが表示されます。
データ型のエイリアス
| エイリアス | PostgreSQL 型に変換された |
|---|---|
bigint、int8 |
BIGINT |
bool、boolean |
BOOLEAN |
bytea |
BYTEA |
char、character |
CHAR |
character varying、varchar |
VARCHAR |
date |
DATE |
decimal、numeric |
DECIMAL |
double precision、float8 |
DOUBLE PRECISION |
real、float4 |
REAL |
int、integer、int4 |
INTEGER |
int2 |
SMALLINT |
interval |
INTERVAL |
json |
JSON |
smallint |
SMALLINT |
text |
TEXT |
time |
TIME |
timestamp |
TIMESTAMP |
timestamptz |
TIMESTAMPTZ |
timetz |
TIMETZ |
uuid |
UUID |
XML |
XML |
コンバージョン マッピング ファイルの例
サポートされているすべてのスキーマ変換ディレクティブを使用するコンバージョン マッピング ファイルのサンプルを次に示します。
EXPORT_SCHEMA 1 SCHEMA root PG_NUMERIC_TYPE 0 PG_INTEGER_TYPE 1 DEFAULT_NUMERIC integer DATA_TYPE NUMBER(4\,0):integer MODIFY_TYPE events:dates_and_times:TIMESTAMP REPLACE_COLS events(dates_and_times:event_dates),users(pseudonym:nickname) REPLACE_TABLES events:login_events users:platform_users
このファイルを使用すると、次のような結果が得られます。
EXPORT_SCHEMA 1は必須のディレクティブです。SCHEMA rootを使用すると、コンバージョン フローに対して次のような調整が行われます。- Database Migration Service は、
rootスキーマ内のエンティティの変換のみを行います。他のスキーマは変換されません。 - このファイル内の他のすべてのカスタマイズ ディレクティブは、
rootスキーマで定義された列とデータ型にのみ適用されます。
- Database Migration Service は、
PG_INTEGER_TYPE 1を使用すると、Database Migration Service はrootスキーマのテーブルにあるすべての Oracle 数値データ型を、ANSI ポータブル数値型ではなく PostgreSQL 固有の型に変換します。DEFAULT_NUMERICを使用すると、Database Migration Service は、指定された小数点のないNUMBER値を PostgreSQL のINTEGER型に変換します。これは、rootスキーマのテーブルにあるNUMBER値にのみ適用されます。DATA_TYPE NUMBER(4\,0):integerを使用すると、Database Migration Service は特定のNUMBER(4,0)値を PostgreSQL のINTEGERに変換します。MODIFY_TYPEディレクティブを使用すると、Database Migration Service は、実際のソース列の形式に関係なく、eventsソーステーブルのdates_and_times列のデータを PostgreSQLDATETIME型に変換します。REPLACE_COLS events(dates_and_times:event_dates),users(pseudonym:nickname)を使用すると、変換されたスキーマ内の次の列の名前が Database Migration Service によって変更されます。- ソースの
eventsテーブルのdates_and_times列は、変換されたスキーマの同じテーブルでevent_datesに名前が変更されます。 - ソースの
usersテーブルのpseudonym列は、変換されたスキーマの同じテーブルでnicknameに名前が変更されます。
rootスキーマのeventsテーブルとusersテーブルにのみ適用されます。- ソースの
REPLACE_TABLES events:login_events users:platform_usersは、変換されたスキーマ内の次のテーブルの名前を変更します。eventsテーブルの名前がlogin_eventsに変更されました。usersテーブルの名前がplatform_usersに変更されました。
rootスキーマのeventsテーブルとusersテーブルにのみ適用されます。
従来のコンバージョン ワークスペース
以前のコンバージョン ワークスペースは、より制限の多い古いタイプのコンバージョン ワークスペースです。従来の変換ワークスペースは、Gemini 拡張変換機能やインタラクティブ SQL エディタをサポートしていません。これらのファイルは、Ora2Pg 移行ツールで移行元のスキーマを変換する場合にのみ使用できます。
移行には、従来型のコンバージョン ワークスペースの使用はおすすめしません。シナリオで以前のコンバージョン ワークスペースを使用する必要がある場合は、 以前のコンバージョン ワークスペースを使用するをご覧ください。
次のステップ
コンバージョン ワークスペースの使用方法については、以下をご覧ください。