コンバージョン ワークスペースでは、移行元のデータベースのスキーマとオブジェクトを、移行先のデータベースと互換性のある 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?hl=ja)
![コンバージョン ワークスペースの画面。[コンバージョンの概要] タブには、変換されたオブジェクトの数、変換の問題、Gemini による変換の拡張機能が表示されます。](https://cloud.google.com/static/database-migration/docs/images/htm/conversion_workspace_overview.png?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 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 は、このスキーマのみを変換します。単一の変換ワークスペースで他のスキーマを変換する必要がある場合は、スキーマが異なる複数のファイルをアップロードする必要があります。
- ファイルで指定された他のすべてのカスタマイズ ディレクティブは、この特定のスキーマ内のオブジェクトにのみ適用されます。
形式は次のようにします。
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)
値を PostgreSQLINTEGER
に変換します。MODIFY_TYPE
ディレクティブにより、Database Migration Service は、実際のソース列の形式に関係なく、events
ソーステーブルのdates_and_times
列のデータを PostgreSQL のDATETIME
型に変換します。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 移行ツールで移行元スキーマを変換する場合にのみ使用できます。
移行に従来のタイプのコンバージョン ワークスペースを使用することはおすすめしません。シナリオで以前のコンバージョン ワークスペースを使用する必要がある場合は、 以前のコンバージョン ワークスペースを使用するをご覧ください。
次のステップ
コンバージョン ワークスペースの使用については、以下をご覧ください。