5.1.1. オブジェクトの命名ルール¶

PostgreSQLではオブジェクトの命名ルールとして以下があります。

• 文字（a～zおよび発音区別符号付き文字と非Latin文字)、アンダースコア（_）で始め、

  2文字目以降には文字、アンダースコア、数字（0～9）あるいはドル記号($)を使用することが可能
• 長さはNAMEDATALEN-1バイト

  （NAMEDATALEN は、src/include/pg_config_manual.hに指定されている。デフォルトは64）

デフォルト設定の場合、PostgreSQLの方が長い識別子を許容するため長さの制限は問題となりませんが、Oracleでオブジェクトの名前にシャープ記号(#)がついている場合は注意が必要です。

5.1.2. 予約語¶

Oracleでは予約語ではありませんが、PostgreSQLでは予約語である単語があります。

予約語と同じ名前のオブジェクトや変数を使用している場合は、名前を変更する必要があります。

以下にPostgreSQLでは予約語となる単語の一例を記載します。

• BINARY
• COLLATE
• FREEZE
• OFFSET
• WINDOW

5.2.1. 移行ツールによる作業量の軽減¶

基本的なデータ型については、Ora2Pgにより適切なPostgreSQLのデータ型への自動変換が可能です。 移行先の型をパラメータで制御したり、データ型毎に任意の変換先のデータ型を指定することも可能です。

5.2.2. DBMSの相違による手作業の作業量の把握¶

データ型の変換後の仕様差異による注意点や、ツールでは自動変換できないケースへの対応について記載します。

CREATE TABLE DATA_TYPE (
        C1 ROWID,
        C2 BFILE,
        C3 XMLType,
        C4 UROWID
);

CREATE TABLE data_type (
        c1 oid,
        c2 bytea,
        c3 xml,
        c4 UROWID  -- 自動変換不可のためそのまま出力
) ;

DATA_TYPE    ROWID:int

CREATE TABLE data_type (
        c1 int,
        c2 bytea,
        c3 xml,
        c4 UROWID
) ;

6.1.1. 移行対象の選定作業¶

データベースの根幹をなすオブジェクトであるテーブルについては、テーブルの種別や構成する列の定義に対して移行可否を検討します。

6.1.2. 移行ツールによる作業量の軽減¶

基本的なテーブルの構文はOra2Pgで変換が可能です。 PostgreSQLが対応していないオプションについては変換時に削除されます。

6.1.3. DBMSの相違による手作業の作業量の把握¶

6.2.1. 移行ツールによる作業量の軽減¶

基本的な構文に違いはありませんが、PostgreSQLでは使用できないオプションについては 削除する必要があります。

Ora2Pgを使用して移行した場合、不要なオプションについては削除が可能です。 また、制約の定義については主にALTER TABLE構文として出力されますが、 制約によってはCREATE TABLE文に含めるかALTER TABLE構文として外出しするかを 制御可能です。他に、制約の名称に関する制御を行うオプション等も存在します。

6.2.2. DBMSの相違による手作業の作業量の把握¶

6.3.1. 移行対象の選定作業¶

Oracleの索引タイプに着目し、PostgreSQLへの移行可否を検討します。

• 移行可能・・・移行対象。索引定義の対象数を把握します。
• 移行不可・・・移行対象外。事前に性能面での影響確認の必要があります。

6.3.2. 移行ツールによる作業量の軽減¶

6.3.3. DBMSの相違による手作業の作業量の把握¶

6.4.1. 移行対象の選定作業¶

Oracleで使用頻度が高いと思われるビューの定義に対する、PostgreSQL移行時の移行可否は以下のとおりです。

6.4.2. 移行ツールによる作業量の軽減¶

上記項目に対する移行ツールの変換対応は以下のとおりです。

6.4.3. DBMSの相違による手作業の作業量の把握¶

上記項目で手作業が必要なものに対する作業内容は以下のとおりです。

6.5.1. 移行対象の選定作業¶

マテリアライズドビューの種類に着目し、PostgreSQLへの移行可否を検討します。

• 移行可能 ・・・ 移行対象。対象数を把握する。
• 移行不可 ・・・ 移行対象外。影響確認の必要がある。

6.5.2. 移行ツールによる作業量の軽減¶

Ora2Pgでの構文変換は、以下の範囲では100%の変換率です。

• 物理領域のオプションは除去されます。
• リフレッシュのオプションは除去されます。(※PostgreSQLに存在しない)
• SELECT句は変換されません。

以下の表では、マテリアライズドビューで想定される使用目的に応じて、移行の方針立ての参考にするために利用用途別にツールでの変換内容をまとめています。

6.5.3. DBMSの相違による手作業の作業量の把握¶

DBMSの構造や使用などの主要な相違点や対処方法を整理しました。

リフレッシュの設定はPostgreSQLでは手動で設定する必要があります。

• REFRESH MATERIALIZED VIEW コマンドを定期的に実行する。

[2] デフォルト値で設定されているもの(DDLに記述がない)による把握

6.6.1. 移行対象の選定作業¶

使用頻度が高いと思われる、DMLに対するトリガはOracle、PostgreSQLともに定義が可能です。

CREATE文やALTER文などのDDLに対するトリガは、PostgreSQL 9.3以降であればイベントトリガとして定義することが可能です。

Oracleで定義が可能なログオン、ログオフに対するトリガはPostgreSQLでは対応していません。

DMLとDDLに対するトリガを整理し、移行する対象を選定します。

6.6.2. 移行ツールによる作業量の削減¶

Ora2Pgにおいて、移行対象のオブジェクト種別に"TRIGGER"を指定することで、DMLに対するトリガを作成するCREATE TRIGGER文が出力されます。

また、OracleのCREATE TRIGGER文の中に書かれていた処理内容にもとづき、PostgreSQLのトリガに使用するためのファンクションを作成するCREATE FUNCTION文も同時に出力されます。※

※ OracleとPostgreSQLとでは、OracleがCREATE TRIGGER文の中にトリガ処理内容を直接記述できるのに対して、PostgreSQLではファンクションとして与える必要がある、という違いがあります。

しかし、OracleとPostgreSQLではファンクションの定義に使用する言語や、組み込みファンクションに違いがあるため、そのままでは動作しない場合があります。

作成されたファンクションについては、内容を確認をする必要があります。

6.6.3. DBMSの相違による手作業の作業量¶

OracleではCREATE TRIGGER文の中にトリガ処理内容を直接記述できるのに対して、PostgreSQLではファンクションとして与える必要があります。

しかし、前述の通りPostgreSQLとOracleとでは、ファンクションに使用する言語や、組み込みファンクションに違いがあります。

そのため、各ファンクションの中身の確認や、処理が異なる場合の修正が手作業として必要になります。

6.7.1. 移行対象の選定作業¶

シーケンス（順序）についてはOracleとPostgreSQLで大幅な機能差異はなく、比較的単純に移行が可能です。 Oracleのシーケンスの定義構文で指定可能なオプションについて、PostgreSQLへの移行可否を整理します。

6.7.2. 移行ツールによる作業量の軽減¶

Oracleの構文で指定可能なオプションについては、ほぼ同等の内容をPostgreSQLでも指定可能ですが、一部書き換えを行う必要があります。 Ora2Pgを使用することで、下記のような差分については自動変換が可能です。

• PostgreSQLではNOCACHEを指定できません。キャッシュを無効にするにはCACHEを省略、もしくは1に設定します。
• PostgreSQLにはORDER/NOORDERオプションは存在しないため、指定されている場合はDDLから削除する必要があります。
• NOで始まるキーワード(NOMAXVALUE、NOMINVALUE、NOCYCLE)は、PostgreSQLではNOの後にスペースを入れる(NO MAXVALUE、NO MINVALUE、NO CYCLE)必要があります。

6.7.3. DBMSの相違による手作業の作業量の把握¶

OracleとPostgreSQLのシーケンスに関する主な仕様差異を説明します。 必要に応じて手作業での修正が必要になります。

6.8.1. 移行対象の選定作業¶

PostgreSQLでは、シノニムをサポートしてませんが、 以下のような目的で使用している一部のシノニムについては、ビューなどで代替することが可能です。

Oracleで使用していたシノニムの内、代替手段を使用して移行するシノニムを整理します。

6.8.2. 移行ツールによる作業量の削減¶

Ora2Pgにおいて、移行対象のオブジェクト種別に"SYNONYM"を指定することで上記の代替手段の内、2のビューを使用した移行について実施するこが可能です。

• Ora2Pgを使用することで、シノニムの対象となっているテーブルに対するビューが作成されます。
• また、作成されたビューに対する所有者の設定と権限の設定が行われます。
• Ora2Pgで作成されたビューの名前については、適宜修正する必要があります。

6.8.3. DBMSの相違による手作業の作業量¶

代替手段の内、1の検索パスを設定する方法については、手作業により移行することが必要となります。

6.9.1. 移行対象の選定作業¶

PostgreSQLにはOracleのデータベースリンクに相当するオブジェクトは存在しませんが、代替案として 他のデータベースにアクセスする仕組である FDW、dblink の２種類が用意されています。

[Oracle構文]

データベースリンクを通して、他のOracleデータベースのテーブルにアクセスします。

-- データベースリンクの作成
CREATE DATABASE LINK dblink1
CONNECT TO user1 IDENTIFIED BY password1  USING‘remotedb'

-- リモートDBの問い合わせ
SELECT * FROM remote_tbl@dblink1

[FDW構文]

-- fdwモジュールの拡張定義
CREATE EXTENSION postgres_fdw;

-- 外部サーバの定義
CREATE SERVER dblink1
   FOREIGN DATA WRAPPER postgres_fdw
   OPTIONS(host'remote_db',port'5432',dbname'remotedb');

-- 外部サーバのユーザマップの定義
 CREATE USER MAPPING FOR postgres
   SERVER dblink1
   OPTIONS(user'user1',password'password1');

-- 外部表の定義
CREATE FOREIGN TABLE remote_tbl
(
 remote_id       integer,
 remote_name     text
)
SERVER postgres_server
OPTIONS(schema_name'postgres',table_name'remote_tbl');

-- リモートDBの問い合わせ
SELECT * FROM remote_tbl;

[dblink構文]

-- リモートDBの接続
    SELECT dblink_connect
       ('dblink1',hostaddr=remote_db port=5432
        dbname=remotedb  user=user1 password=password1);

-- リモートDBの問い合わせ
    SELECT * FROM
        dblink('dbname=dblink_name',
               'select remote_id, remote_name from remote_tbl')
        AS t1(remote_id integer, remote_name text);

-- リモートDBの切断
    SELECT dblink_disconnect('dblink1');

6.9.2. 移行ツールによる作業量の削減¶

6.9.3. DBMSの相違による手作業の作業量¶

FDWを使うためには以下の作業が必要です。

[IMPORT構文]

IMPORT FOREIGN SCHEMA <接続先スキーマ名>
  FROM SERVER <外部サーバ名> INTO <内部スキーマ名>;

.

7.1.1. 移行対象の選定作業¶

スキーマについてはOracleとPostgreSQLで違いがあります。

Oracleではユーザとスキーマが1対1で対応していますが、PostgreSQLではユーザとスキーマが対応づいていません。

また、CREATE SCHEMA文の構文や意味も変わるため注意が必要です。

7.1.2. 移行ツールによる作業量の削減¶

Ora2Pgでスキーマを出力するよう設定すれば、定義されていたスキーマのDDLが出力されます。 ただし、移行不要なスキーマが出力される場合がありますので、サンプルのスキーマなど不要なスキーマ定義文がないか確認し、必要に応じて削除を行ってください。

7.1.3. DBMSの相違による手作業の作業量の把握¶

Ora2Pgでスキーマを出力するよう設定すれば、手作業での移行は不要です。

また、SQLに明示的にスキーマ名を指定しない場合でも、search_pathパラメータを変更していなければ、ユーザ名と同じ名前のスキーマを優先してオブジェクトを検索するので設定変更も不要です。

7.2.1. 移行対象の選定作業¶

PostgreSQLでは、Oracleと同様にユーザを作成することが可能です。※

※ PostgreSQLにおいては、ユーザはログイン権限を持つロールのことであり、Oracleのユーザとは考え方が異なります。 ただし、Oracleと同様にCREATE USER文により、ユーザ(ログイン権限を持つロール)を作成することが可能です。

Oracleで使用しているユーザを整理し、PostgreSQLでも引き続き使用するユーザを選定します。

7.2.2. 移行ツールによる作業量の削減¶

Ora2Pgにおいて、移行対象のオブジェクト種別に"GRANT"を指定することで、Oracleで使用していたユーザを作成する CREATE USER 文が出力されます。

しかし、Ora2Pgではパスワードが引き継がれないため、それらの移行を検討する必要があります。

7.2.3. DBMSの相違による手作業の作業量¶

7.3.1. 移行対象の選定作業¶

Oracleで使用しているロールを整理し、PostgreSQLでも引き続き使用するロールを選定します。

7.3.2. 移行ツールによる作業量の削減¶

Ora2Pgにおいて、移行対象のオブジェクト種別に"GRANT"を指定することでOracleで使用していたロールの移行が可能です。

7.3.3. DBMSの相違による手作業の作業量¶

Ora2Pgで出力されるSQLの中にある CREATE ROLE文だけでは権限が設定されませんので、同時に出力されるGRANT文を使用する必要があります。

権限については、権限のページを参照して下さい。

7.4.1. 移行対象の選定作業¶

権限には大きく分けるとシステム権限とオブジェクト権限の2種類があります。

PostgreSQLでも同様の権限設定は可能ですが、SELECT権限等の一部を除いてそのまま移行することはできません。

また、PostgreSQLでシステム権限を設定する場合、GRANT文ではなくCREATE ROLE文やCREATE USER文を使用するものがあります。

7.4.2. 移行ツールによる作業量の軽減¶

Ora2Pgで出力する対象としてGRANTを指定した場合、PostgreSQLでそのまま定義可能な権限についてはGRANT文を出力します。

しかし、SELECT権限等のごく一部であるため、必要な定義が出力されているかの確認を実施する必要があります。

7.4.3. DBMSの相違による手作業の作業量の把握¶

設定している権限の種類、設定量に応じて作業量を考慮する必要があります。

以下に、定義される頻度が高いと思われる権限の対応例を示します。

7.5.1. 移行対象の選定作業¶

PostgreSQLとOracleとでは、データベースを構成するファイル構造が異なるため、 I/O負荷の分散や容量の管理などの運用に差異が発生します。

それらの差異を踏まえて、移行後のテーブルスペースの構成を検討します。

7.5.2. 移行ツールによる作業量の削減¶

Ora2Pgにおいて、移行対象のオブジェクト種別に"TABLESPACE"を指定することでOracleで使用していたテーブルスペースを作成するCREATE TABLESPACE文と、 各テーブルペースにテーブルや索引を割り当てるALTER TABLE文やALTER INDEX文が出力されます。

ただし、CREATE TABLESPACE文で指定されたディレクトリパスは、Oracleにもとづいているため、修正する必要があります。

7.5.3. DBMSの相違による手作業の作業量¶

前述の通り PostgreSQL と Oracle とでは、データベースを構成するファイル構造が異なります。

そのため、テーブルスペースを単純に移行しても、期待する性能とはならない場合があります。

以下のような観点で、運用を検討し、必要に応じてテーブルスペースの構成を手作業で変更します。