LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

脱Oracle Database、PostgreSQL移行はなぜデータベース層の作業が重いのか

商用Oracle Databaseで基幹系のデータベースを運用している企業の間で、PostgreSQLへの移行を検討する動きが広がっています。背景にあるのはライセンス費・保守費の負担、コア数課金の仕組み、監査対応といった運用コストの重さです。移行先としてPostgreSQLが選ばれやすいのは、オープンソースでライセンス費が発生しない点に加え、AWS・Google Cloud・Microsoft Azureの各社がマネージド型のPostgreSQLサービスを提供しており、移行先の選択肢が広い点にあります^*4*6*7。

アプリケーション層の改修を伴う移行と異なり、データベース層に絞った移行ではスキーマとデータベース内のロジックの変換が作業の中心になります。Microsoftのガイドでも、データベーススキーマ移行・データベースコード移行・データ移行・アプリケーションコード移行・移行検証・性能チューニング・クラウド最適化を主要な工程として整理しており、データベース層(スキーマとコード)の変換が独立した工程として位置づけられています^*7*8。本稿ではアプリケーション側の改修には触れず、データベース層の移行に絞って整理します。

Oracle固有機能がPostgreSQL移行の壁になる理由――PL/SQL・パッケージ・シノニム・データ型

Oracle DatabaseとPostgreSQLはいずれもリレーショナルデータベースですが、内部の設計思想は異なります。PostgreSQL公式ドキュメントは「Oracleから移植する際は多くのデータ型名を変換する必要がある」と説明し、VARCHAR2はvarcharまたはtextへ、NUMBERはnumericへ置き換えることを案内しています^*1。日付型やタイムゾーンの扱いにも差があり、テーブル定義をそのままでは持ち込めません。

手続き言語の面では、OracleのPL/SQLとPostgreSQLのPL/pgSQLは構造化された命令型言語という点で似ていますが、細部の挙動が異なります。PostgreSQL公式ドキュメントは、関数本体を文字列リテラルとして記述しドル引用符を使う点、REVERSE付きの整数FORループでは数え方の方向が異なるためループの境界値を入れ替える必要がある点を明記しています^*1。EXCEPTION句で例外を捕捉すると、そのブロックのBEGIN以降のデータベース変更が自動的にロールバックされる点も特徴です^*1。

PostgreSQLにはOracleのパッケージという概念がありません。PostgreSQL公式ドキュメントは、パッケージの代わりにスキーマで関数をグループ化し、パッケージ変数の代替として一時テーブルを使う方法を案内しています^*1。長年パッケージ単位でロジックを整理してきたシステムほど、設計変更の影響が大きくなります。

シノニムやシーケンスの扱いも見直しが必要です。OracleのROWID疑似列はPostgreSQLに同等の機能がなく、AWSのドキュメントでは変換時にROWIDを別のデータ型で代替するオプションが用意されています^*3。DECODEやNVL、LISTAGGといったOracle組み込み関数も、PostgreSQLの標準機能だけでは同じ挙動を再現できない場合があり、Oracle互換関数を提供するOrafce拡張を使う選択肢があります^*3*8。ヒント句やOracle方言のSQL構文も、変換時に洗い出す対象です。

移行アセスメントの4工程――スキーマ変換・コード変換・データ移行・性能検証

Microsoftの移行ガイドは、Oracleからの移行をデータベーススキーマ移行・データベースコード移行・データ移行・アプリケーションコード移行・移行検証・性能チューニング・クラウド最適化という一連の工程として整理しています^*7*8。データベース層に絞ると、次の4つの工程が実務上の中心になります。

1つ目はスキーマ変換です。テーブル定義や列のデータ型、制約、インデックスをPostgreSQL互換の定義へ変換します。AWS DMSのスキーマ変換機能では、NUMBER型の列を精度に応じてSMALLINT・INTEGER・BIGINTへ自動でマッピングする設定が用意されています^*3。Google CloudのDatabase Migration Serviceも、対話型の変換ワークスペース上でスキーマやテーブルをPostgreSQL構文へ変換する機能を提供しています^*6。

2つ目はコード変換です。ストアドプロシージャ・ファンクション・トリガーといったロジックをPL/pgSQLへ書き換えます。AWS SCTはOracleのデータベースオブジェクトの大部分を自動で移行でき、手作業の負担を軽減できるとAWS自身が説明しています^*4。自動変換できなかった箇所は移行アセスメントレポート上で要対応項目として示され、目視での書き換えが必要になります^*4。

3つ目はデータ移行です。Microsoftのガイドは「オフライン」方式と「ライブ」方式の2種類を挙げています。オフライン方式は移行に要する時間だけシステムを停止する分、手順は比較的単純です。ライブ方式は初期データの一括ロードと変更分の継続的な反映(CDC)を組み合わせるため、停止時間を抑えられる一方で構成は複雑になります^*8。Google CloudのDatabase Migration Serviceも、一回限りの移行とCDCで継続的に反映する移行の2方式を用意しています^*6。

4つ目は性能検証です。Microsoftのガイドは、テーブル件数の比較・データ型と構造の確認・行単位の値比較・複雑なクエリの結果一致確認を段階的に実施することを推奨しています^*8。データベース層の移行では、変換後のスキーマやSQLが移行前と同等の応答時間で動くかどうかの検証が欠かせません。

移行方式の選び方――一括移行と段階移行、Oracle互換機能の活用

移行方式には大きく一括移行と段階移行の2つの進め方があります。一括移行(いわゆるビッグバン方式)は、検証環境で変換とテストを済ませたうえで、一度の切替でOracleからPostgreSQLへ本番を移す進め方です。切替のタイミングを1回に絞れる分、事前の変換精度と性能検証の網羅性が求められます。

段階移行は、Oracle互換機能を活用しながら移行対象を段階的に広げる進め方です。PostgreSQLの拡張機能であるOrafceは、Oracle組み込み関数と互換のルーチンを提供しており、AWS DMSのスキーマ変換設定でもOrafceのルーチンをオンにすることで、Oracle固有の関数呼び出しを書き換えずに済ませられる場合があります^*3。Microsoftのガイドも、Orafceのようなpostgres拡張機能群を「コード移行を効率化する有力な味方」と位置づけ、元のロジックや挙動を保ったまま移行の複雑さ・時間・コストを抑えられる利点を挙げています^*8。

ただしOracle互換機能は、Oracleで使われている構文や関数の一部をカバーする位置づけです。移行対象のシステムが依存している機能の範囲によって、どこまで互換機能で吸収できるかは変わります。移行方式を決める前に、対象データベースが使っている機能の洗い出しを済ませておくことが前提になります。

移行先の選択肢――自前PostgreSQL・Aurora PostgreSQL・Cloud SQL・Azure Database for PostgreSQL

移行先の選択肢は、自前で構築するPostgreSQLと、クラウド各社のマネージド型PostgreSQLに分かれます。自前PostgreSQLはOS・ミドルウェアの選定からバックアップ・監視の設計まで自社の裁量で決められる一方、運用の手間は自社で引き受ける形になります。

AWSはAmazon Aurora PostgreSQL-Compatible Editionを移行先とし、AWS SCTとAWS DMSでスキーマ変換とデータ移行を進める手順を公式のプレイブックとして公開しています^*4。Google CloudはCloud SQL for PostgreSQLを移行先とし、継続的移行と一回限りの移行の両方式に対応しています。対象ソースはAmazon RDS for OracleやOracle RAC(Real Application Clusters)を含みますが、Oracle Autonomous Databaseは移行元として対応していません^*6。

Microsoft AzureはAzure Database for PostgreSQL フレキシブルサーバーを移行先として案内しています。オープンソースのPostgreSQLコミュニティビルドをベースにしており、コミュニティ版のリリースと互換性を保ちながら運用できる点を特徴として挙げています^*7。いずれのクラウドサービスも、移行によるコスト効率化とライセンス体系の簡素化を移行のメリットとして位置づけています^*7。

マネージド型を選ぶ場合は、バックアップやフェイルオーバーの仕組みが提供元ごとに異なる点、拡張機能(Orafceなど)の利用可否がサービスやバージョンによって異なる点を確認しておく必要があります^*3。自前構築とマネージド型のどちらを選ぶかは、運用体制の規模やクラウド利用の方針とあわせて検討する事項です。

外注時に確認すべき点――既存SQL資産の棚卸しと性能リグレッション検証

Oracle DatabaseからPostgreSQLへのデータベース層の移行を外部に委託する場合、確認しておきたい点がいくつかあります。まず、既存のSQL資産の棚卸し範囲です。ストアドプロシージャ・ファンクション・トリガー・パッケージ・シノニム・シーケンスといったオブジェクトの一覧化と、それぞれの変換難易度の評価をどこまで請け負うかを事前にすり合わせます。AWS SCTのようなツールを使ったアセスメントレポートでは、自動変換できた項目と手作業が必要な項目が仕分けされるため、このレポートを起点に工数を見積もる進め方が実務的です^*4。

次に、性能リグレッション検証の範囲です。スキーマとコードを変換しただけでは、変換前と同じ応答時間が保証されるわけではありません。インデックス構成やクエリの実行計画はデータベースエンジンが変われば変わるため、主要な業務クエリについて変換前後の実行時間を比較する工程を委託範囲に含めるかどうかを確認します。Microsoftのガイドも、テーブル件数比較や行単位の値比較に加え、複雑なクエリの結果一致確認を移行検証の一部として挙げています^*8。

データ移行の方式(オフラインかライブか)も、外注先とすり合わせておく項目です。オフライン方式なら停止時間の見積もり、ライブ方式ならCDCによる差分反映の仕組みと切替タイミングの検証範囲を確認します^*6*8。ora2pgのようなオープンソースツールを使う場合は、変換後のPL/pgSQLコードをレビューする体制が委託先にあるかどうかも見ておく点です^*5。移行対象のオブジェクト数や既存システムの複雑さによって、必要な工数は変わります。現状のデータベース構成を棚卸ししたうえで、外注範囲の切り分けを検討することが実務的です。

まとめ：脱Oracle DatabaseでPostgreSQL移行を進める3つの判断軸

本稿ではOracle DatabaseからPostgreSQLへのデータベース層の移行について、公式情報をもとに整理しました。要点は3つに集約できます。第一に、移行の難所はPL/SQLパッケージ・シノニム・組み込み関数・データ型といったOracle固有機能の書き換えにあり、この作業量が全体の負担を左右します^*1*3。第二に、移行アセスメントはスキーマ変換・コード変換・データ移行・性能検証の4工程で進めるのが公式の案内であり、AWS SCT・ora2pg・Database Migration Serviceといったツールがそれぞれの工程を支援します^*4*5*6。第三に、移行先は自前PostgreSQLに加えAurora PostgreSQL・Cloud SQL for PostgreSQL・Azure Database for PostgreSQLの選択肢があり、既存SQL資産の棚卸しと性能リグレッション検証をどこまで任せるかが外注範囲を決める判断軸になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：PostgreSQL「Porting from Oracle PL/SQL」（PostgreSQL Documentation）（https://www.postgresql.org/docs/current/plpgsql-porting.html）
2. *2　出典：AWS「What is the AWS Schema Conversion Tool?」（AWS Schema Conversion Tool User Guide）（https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html）
3. *3　出典：AWS「Understanding Oracle to PostgreSQL conversion settings」（AWS Database Migration Service User Guide）（https://docs.aws.amazon.com/dms/latest/userguide/schema-conversion-oracle-postgresql.html）
4. *4　出典：AWS「AWS Schema Conversion Tool」（Oracle to Aurora PostgreSQL Migration Playbook、Database Migration Guide）（https://docs.aws.amazon.com/dms/latest/oracle-to-aurora-postgresql-migration-playbook/chap-oracle-aurora-pg.tools.awssct.html）
5. *5　出典：Ora2Pg公式サイト「Ora2Pg : Migrates Oracle to PostgreSQL」（https://ora2pg.darold.net/）
6. *6　出典：Google Cloud「Oracle to Cloud SQL for PostgreSQL migration overview」（Database Migration Service Documentation）（https://docs.cloud.google.com/database-migration/docs/oracle-to-postgresql/scenario-overview）
7. *7　出典：Microsoft「Migrating Oracle to Azure Database for PostgreSQL flexible server」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/postgresql/migrate/oracle-migration/concepts-oracle-migration）
8. *8　出典：Microsoft「Oracle to Azure Database for PostgreSQL flexible server Migration Stages」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/postgresql/migrate/oracle-migration/concepts-oracle-migration-stages）

Tweet