移行ツールによる作業量の軽減¶マテリアライズドビュー定義(DDL)をPostgreSQL用の定義に変換する作業が必要です。Ora2Pgで自動変換することで手作業量を軽減することができます。Ora2Pgでの構文変換は、以下の範囲では100%の変換率です。物理領域のオプションは除去されます。リフレッシュのオプションは除去されます。(※PostgreSQLに存在しない)SELECT句は変換されません。以下の表では、マテリアライズドビューで想定される使用目的に応じて、移行の方針立ての参考にするために利用用途別にツールでの変換内容をまとめています。DBMSの相違による手作業の作業量の把握¶DBMSの構造や使用などの主要な相違点や対処方法を整理しました。リフレッシュの設定はPostgreSQLでは手動で設定する必要があります。コマンドを定期的に実行する。高いと思われる、DMLに対するトリガはOracle、PostgreSQLともに定義が可能です。9.3以降であればイベントトリガとして定義することが可能です。Oracleで定義が可能なログオン、ログオフに対するトリガはPostgreSQLでは対応していません。作成不可DMLとDDLに対するトリガを整理し、移行する対象を選定します。TRIGGER文が出力されます。FUNCTION文も同時に出力されます。TRIGGER文の中にトリガ処理内容を直接記述できるのに対して、PostgreSQLではファンクションとして与える必要がある、という違いがあります。OracleとPostgreSQLではファンクションの定義に使用する言語や、組み込みファンクションに違いがあるため、そのままでは動作しない場合があります。作成されたファンクションについては、内容を確認をする必要があります。TRIGGER文の中にトリガ処理内容を直接記述できるのに対して、PostgreSQLではファンクションとして与える必要があります。前述の通りPostgreSQLとOracleとでは、ファンクションに使用する言語や、組み込みファンクションに違いがあります。そのため、各ファンクションの中身の確認や、処理が異なる場合の修正が手作業として必要になります。移行対象の選定作業¶シーケンス(順序)についてはOracleとPostgreSQLで大幅な機能差異はなく、比較的単純に移行が可能です。Oracleのシーケンスの定義構文で指定可能なオプションについて、PostgreSQLへの移行可否を整理します。デフォルト値が異なる。RAC構成で必要となるパラメータであるため影響なし。移行ツールによる作業量の軽減¶Oracleの構文で指定可能なオプションについては、ほぼ同等の内容をPostgreSQLでも指定可能ですが、一部書き換えを行う必要があります。Ora2Pgを使用することで、下記のような差分については自動変換が可能です。PostgreSQLではNOCACHEを指定できません。キャッシュを無効にするにはCACHEを省略、もしくは1に設定します。PostgreSQLにはORDER/NOORDERオプションは存在しないため、指定されている場合はDDLから削除する必要があります。CYCLE)必要があります。DBMSの相違による手作業の作業量の把握¶OracleとPostgreSQLのシーケンスに関する主な仕様差異を説明します。必要に応じて手作業での修正が必要になります。CACHEについてはOracleが20、PostgreSQLが1(キャッシュ無効)と異なっています。差異があるため注意が必要です。そこから各セッションが値を順次取得します。キャッシュに指定された数のシーケンス値を各セッションが確保します。そのため、シーケンス値に抜け番号が発生したり、採番された値が全体では時系列で並ばなくなることがあります。各セッションからシーケンス値が1つずつ確保されるようにします。値の範囲はPostgreSQLの方が狭くなります。格納値の調整を行う必要が出てきます。影響があるケースはほぼないと思われます。PostgreSQLでは関数呼び出しを行う必要があります。アプリケーションから明示的に発行をしている場合、書き換える必要があります。トリガを使用して疑似的に自動採番を実装している場合があります。トリガを廃止して列の定義にDEFAULT句を追加することを検討します。以下のような目的で使用している一部のシノニムについては、ビューなどで代替することが可能です。Oracleで使用していたシノニムの内、代替手段を使用して移行するシノニムを整理します。Oracleのシノニムと同じ名前でビューを作成する。ビューに対し権限を設定する。移行ツールによる作業量の削減¶Ora2Pgにおいて、移行対象のオブジェクト種別に"SYNONYM"を指定することで上記の代替手段の内、2のビューを使用した移行について実施するこが可能です。Ora2Pgを使用することで、シノニムの対象となっているテーブルに対するビューが作成されます。作成されたビューに対する所有者の設定と権限の設定が行われます。Ora2Pgで作成されたビューの名前については、適宜修正する必要があります。代替手段の内、1の検索パスを設定する方法については、手作業により移行することが必要となります。2種類が用意されています。リモートDBのテーブルを外部表と定義してテーブルと同様に扱います。クエリにdblink関数(引数:DB接続情報,SELECT文)を使用します。FDWは標準的なSQLで操作ができ、トランザクション管理や問い合わせの最適化などの機能面でdblinkより優れています。様々なデータベースやデータファイルとの連携も可能です。そのために、Oracleデータベースリンクの代替としては、FDWの方が適しています。[Oracle構文]データベースリンクを通して、他のOracleデータベースのテーブルにアクセスします。remote_tbl@dblink1[FDW構文]FDWモジュールをPostgreSQLに機能拡張することで様々な外部データにアクセスできます。外部表を通して、通常の表と同様にSQLで操作します。remote_tbl;[dblink構文]他のデータベースへの問い合わせを行うための関数群です。dblinkは、DB接続、切断、カーソルOPEN/CLOSE/FETCH単位に制御する関数が存在しています。移行ツールによる作業量の削減¶データベースリンク定義(DDL)からFDW関連定義の雛形が生成されます。DBMSの相違による手作業の作業量¶FDWを使うためには以下の作業が必要です。DBMSの種類に応じたfdw専用モジュールを入手します。入手したfdw専用モジュールを拡張定義として登録します。連携先のDB接続情報を定義します。連携元と先のユーザマッピングを定義します。連携先のテーブルを専用スキーマに外部表として定義します。データベースリンク名が指定されているSQLを外部表の指定に修正します。接続先DBのスキーマのテーブルを外部表としてインポートすることが可能です。非スキーマ・オブジェクトは、スキーマに含まれないデータベースで扱うことのできる構成要素です。代表的なものとして、ユーザや権限があります。移行対象の選定作業¶スキーマについてはOracleとPostgreSQLで違いがあります。Oracleではユーザとスキーマが1対1で対応していますが、PostgreSQLではユーザとスキーマが対応づいていません。SCHEMA文の構文や意味も変わるため注意が必要です。ユーザ名と同一名のスキーマについて¶Oracleではユーザ名と同じ名前のスキーマが自動的に作成されます。PostgreSQLではユーザ名と同じスキーマが自動的に作成されることはありませんが、明示的に定義することは可能です。スキーマ指定をしない場合に使用するスキーマを変更することも可能です。Oracleと同様のスキーマを作成したい場合はこれらの作業を移行計画に含めておく必要があります。移行ツールによる作業量の削減¶Ora2Pgでスキーマを出力するよう設定すれば、定義されていたスキーマのDDLが出力されます。移行不要なスキーマが出力される場合がありますので、サンプルのスキーマなど不要なスキーマ定義文がないか確認し、必要に応じて削除を行ってください。DBMSの相違による手作業の作業量の把握¶Ora2Pgでスキーマを出力するよう設定すれば、手作業での移行は不要です。SQLに明示的にスキーマ名を指定しない場合でも、search_pathパラメータを変更していなければ、ユーザ名と同じ名前のスキーマを優先してオブジェクトを検索するので設定変更も不要です。SCHEMA文について¶PostgreSQLにも同様の文がありますが、構文・意味合いが異なります。SCHEMA文と同様の処理を行いたい場合は、以下の手順で同等の処理を実施します。SCHEMA文でスキーマを作成します。SCHEMA文に指定していたテーブルやビューを作成する文を、該当するスキーマを指定して個別に実行します。移行対象の選定作業¶PostgreSQLでは、Oracleと同様にユーザを作成することが可能です。PostgreSQLにおいては、ユーザはログイン権限を持つロールのことであり、Oracleのユーザとは考え方が異なります。USER文により、ユーザ(ログイン権限を持つロール)を作成することが可能です。Oracleで使用しているユーザを整理し、PostgreSQLでも引き続き使用するユーザを選定します。Ora2Pgではパスワードが引き継がれないため、それらの移行を検討する必要があります。USERのオプションに含まれない、権限の付与なども必要な作業となります。ユーザの移行については、運用を検討し、権限なども移行する必要があります。ユーザの移行時に検討・対応が必要となるポイントは以下の通りです。移行対象の選定作業¶Oracleで使用しているロールを整理し、PostgreSQLでも引き続き使用するロールを選定します。移行ツールによる作業量の削減¶Ora2Pgにおいて、移行対象のオブジェクト種別に"GRANT"を指定することでOracleで使用していたロールの移行が可能です。ROLE文だけでは権限が設定されませんので、同時に出力されるGRANT文を使用する必要があります。権限については、権限のページを参照して下さい。権限には大きく分けるとシステム権限とオブジェクト権限の2種類があります。PostgreSQLでも同様の権限設定は可能ですが、SELECT権限等の一部を除いてそのまま移行することはできません。USER文を使用するものがあります。移行ツールによる作業量の軽減¶Ora2Pgで出力する対象としてGRANTを指定した場合、PostgreSQLでそのまま定義可能な権限についてはGRANT文を出力します。SELECT権限等のごく一部であるため、必要な定義が出力されているかの確認を実施する必要があります。設定している権限の種類、設定量に応じて作業量を考慮する必要があります。以下に、定義される頻度が高いと思われる権限の対応例を示します。オブジェクト権限の移行例¶Oracleの権限PostgreSQLでの定義例テーブルに対するALTERテーブルの所有者のみ可能であるため、以下のように設定します。I/O負荷の分散や容量の管理などの運用に差異が発生します。それらの差異を踏まえて、移行後のテーブルスペースの構成を検討します。INDEX文が出力されます。TABLESPACE文で指定されたディレクトリパスは、Oracleにもとづいているため、修正する必要があります。とでは、データベースを構成するファイル構造が異なります。そのため、テーブルスペースを単純に移行しても、期待する性能とはならない場合があります。以下のような観点で、運用を検討し、必要に応じてテーブルスペースの構成を手作業で変更します。Oracleでは、1つのテーブルを別々のディスクに格納された複数のテーブルスペースに割り当てることにより、I/O分散が可能です。PostgreSQLでは基本的に1つのテーブルは1つのテーブルスペースに格納する必要があります。同様の負荷分散を行いたい場合は、パーティショニングなどの検討を行います。Oracleでは、個々のテーブルが使用できるディスク容量が不足する場合、後から追加されたディスクにテーブルスペースを確保し、そのテーブルスペースをテーブルに追加することが可能です。PostgreSQLでは個々のテーブルに対してテーブルスペースを追加することができません。追加したディスクに新たなテーブルスペースを作成し、テーブルが使用するテーブルスペースを変更する必要があります。そのため、初めから十分な容量を検討しておくことが重要です。Consortium。