1. ホーム
  2. 製品
  3. ソフトウェア
  4. 富士通のソフトウェアとは
  5. 特集
  6. PostgreSQLインサイド
  7. PostgreSQL技術インデックス
  8. データベース移行で押さえておくべきこと ～移行プロセスについて～

データベース移行で押さえておくべきこと ～移行プロセスについて～
PostgreSQLインサイド

近年、運用保守コストの削減や、ベンダーロックインの回避、エコシステムの構築を理由に、商用データベースからオープンソースソフトウェア（以降、OSSと略す）系のデータベースへの移行を検討されるケースが増えています。この記事では、Oracle DatabaseからPostgreSQLへのデータベース移行における、安全な移行プロセスの進め方について説明します。なお、双方のデータベースの基本的な違いについては、「データベース移行で押さえておくべきこと ～アーキテクチャーと機能の違い～」で紹介しています。

1. 移行プロセスの概要

企業や組織にとって重要なデータを扱うデータベースの移行には、まずはじめに、慎重な検討、および、利点とリスクについての総合的な判断が必要です。データベース移行が決まったら、詳細な計画を立て、その上で、データベースリソースやアプリケーションなどの実際の移行作業を行います。移行後に、パフォーマンス劣化などの不具合が生じて移行工数を増大させたり、コスト追加を発生させたりしないようにするためにも、前工程での、質の高いアセスメントと見積りによる評価が非常に重要になります。

データベースの移行プロセスの概要について説明します。

図1：移行プロセスの概要
図1：移行プロセスの概要

  1. STEP1
    アセスメント
    移行対象となる資産や、データ容量、データベース構成などを調査し、修正が必要な個所を洗い出します。その後、技術的な影響を分析し、移行プロジェクトの作業の難易度を評価します。
  2. STEP2
    見積り
    このステップでは、アセスメント結果に基づいて、移行プロジェクトのコストとデータ移行にかかる時間を見積もります。併せて、移行時に必要な設備と一時的なライセンス、トレーニングスタッフなどの他のコストも考慮する必要があります。これらの見積もりに基づいて、プロジェクトオーナーは、実現可能性を判断し、この移行プロジェクトを続行するかどうかを決定します。
  3. STEP3
    移行準備
    見積もったコストを元に、スケジュールや移行作業の体制を検討します。また、移行作業に必要な開発環境、運用環境、および、資産を準備します。
  4. STEP4
    移行作業の実施
    以下の開発プロセスに従って、移行作業を実施します。
    • データベース構成の設計と構築
    • データベースの運用設計
    • アプリケーション設計
    • 実装（プログラミング）
    • テスト

2. 移行プロセスの詳細

以下の移行プロセスについて、順を追って詳細を説明します。

2.1. アセスメント

アセスメントは、技術的な影響を分析し、移行プロジェクトの作業の難易度を評価するための移行プロジェクトの最初のステップです。移行作業の難易度は、さまざまな要因によって大きく異なります。したがって、移行手順で何を処理する必要があるかを理解するために、現行システムをデータベース構成、データ容量、およびデータベーススキーマなどの資産の観点から検討する必要があります。また、移行を完了するための難易度も評価する必要があります。「1. 移行プロセスの概要」で説明したように、移行前の計画段階でのアセスメントは非常に重要です。
データベース移行の際の主な考慮項目の1つに、システムの性能への影響があります。移行後のシステム性能が重要な要件である場合は、この段階での性能検証が必要になります。そのためには、いくつかのスキーマとアプリケーションを移行して、システムの性能要件を満たせるかどうかを評価します。
この後のステップでは、エンジニアのスキルと生産性に基づいて移行計画を作成します。そのため、Oracle DatabaseからPostgreSQLへの移行を初めて行う場合は、このステップでエンジニアのスキルと生産性を評価することを推奨します。
アセスメントの調査対象と、移行箇所やその難易度を見極めるための主な観点を以下に示します。

表1 アセスメントの調査対象と主な調査観点

調査対象 主な調査観点
データベース構成

データベース構成の設計および構築の難易度を見極めるため、以下の観点で調査します。

  • シングル・インスタンス構成かクラスタ構成か？
  • 連携するデータベースがあるか？
SQL

SQLの修正箇所や難易度を見極めるため、以下の観点で調査します。

  • データ型
  • DDL、DML
  • トランザクション制御文
  • セッション制御文
  • システム制御文
  • 演算子、条件、式、関数
PL/SQL

PL/SQLの修正箇所や難易度を見極めるため、以下の観点で調査します。

  • データ型
  • パッケージ
  • サブプログラム
  • トランザクションの処理と制御
  • GOTO文
アプリケーション

アプリケーション用インターフェイスの修正の影響を見極めるため、以下の観点で調査します。

  • JDBC
  • ODBC
  • OCI
  • Pro*C
データ

データ移行にかかる時間を見極めるため、以下の観点で調査します。

  • 表の索引や制約の数
  • データ容量
  • データ移行方式
運用

データベースの運用に与える技術的な影響を見極めるため、以下の観点で調査します。

  • データベース監視
  • データベース認証
  • バックアップとリカバリー
  • 高可用性と高信頼性
性能要件

システムの性能要件を確認するため、以下の観点で調査します。

  • オンライン処理性能（通常時、高負荷時）
  • バッチ処理性能

2.2. 見積り

移行プロジェクトの作業コストと、データ移行にかかる時間を見積もります。その後、プロジェクトオーナーが移行の実現可能性を判断し、この移行プロジェクトを続行するかどうか決定します。見積もり方法は次の通りです。

移行作業コスト

アセスメントで洗い出した移行が必要な個所や難易度から、設計、修正、および、テストにかかる作業量を割り出します。割り出した作業量と修正難易度、エンジニアのスキルや生産性などから、移行に必要な作業コストを見積もります。
テスト工数を見積もる際には、データベース移行時の特有な問題に備えて、十分に時間的なバッファを確保することをお勧めします。なお、データベースを移行する際にデータベースの詳細な仕様差を調査しますが、それでもテスト工程で動作させてみるまでは、その仕様差に気づけない場合があります。例えば、以下のようなケースに遭遇する可能性があります。

  • 演算時の切り捨てや切り上げの仕様差などが原因で、SQLで実行した数値演算結果が異なる
  • データ型の精度や表示形式の違いにより、SQLで抽出した日時と時刻の出力結果が異なる

データ移行時間

データ移行時間も併せて見積もりを行う必要があります。現行システムのデータ量が大規模な場合は、データ移行にも時間がかかります。また、同じデータ量でも選択した移行方式や環境によって移行にかかる時間は異なります。したがって、テスト環境を構築してデータ移行のリハーサルを実施し、リハーサルの結果を元に本番環境のデータ移行時間を見積もる必要があります。

2.3. 移行準備

前ステップで見積もった結果を元に、移行作業のスケジュールを作成し、開発体制を構築します。また、移行作業に必要となる環境や資産を準備します。

移行作業スケジュールの作成

見積結果に基づいて、プロジェクトのスケジュールと開発体制を含む移行計画を作成します。現行システムから移行先システムへの切り替えに必要なダウンタイムなど、稼働中の計画も必要です。

準備

移行作業においては、本番用の運用環境と開発環境の両方を使用します。それぞれの環境において、現行システムと移行先システムの2つの環境を準備します。

  • 本番用の運用環境
    現在稼働中の現行システム、および、移行後に使用する移行先システムのための環境です。
  • 開発環境
    設計、コーディング、テストなどの移行作業を行う環境です。開発環境にも、現行システムと移行先システムの2つの環境が必要です。現行システムで利用しているハードウェアやソフトウェアの構成と同等のものを、移行先システムに準備します。現行システムの対象資産を移行するためにツールを使用する場合は、そのツールを使用するための環境設定も適宜実施します。

資産

本番環境の現行システムの資産（アプリケーション、運用に関するバッチ処理、データなど）を開発環境の現行システムにも準備します。ただし、データベースの移行を実施する上で影響のない部分については、適宜簡略化することが可能です。例えば、開発環境のデータベースに格納するデータには、本番環境のサンプルデータを利用することもあれば、本番環境と同様の特徴を持つテストデータを利用することもあります。

2.4. 移行作業の実施

ここからは、すべての資産をOracle DatabaseからPostgreSQLに移行するための、実際の作業のステップになります。なお、このステップは、通常のシステム開発のプロセスと同等の作業になります。

2.4.1 データベース構成の設計と構築

多くの場合、移行先システムのデータベース構成は、システム要件を満たし、現行システムのデータベースと同等のシステムを提供するよう設計します。特に、設計時にはOracle DatabaseとPostgreSQLのアーキテクチャーの違いを考慮する必要があります。次の表は、2種類の一般的なデータベース構成について説明しています。特に高可用構成の場合は注意が必要です。なお、参考として、OSSのPostgreSQLをエンタープライズ向けに強化した製品「FUJITSU Software Enterprise Postgres（以降、Enterprise Postgresと略す）」の情報も併せて示します。

表2 一般的なデータベース構成

データベース構成 説明
シングル・インスタンス構成 1つのサーバーで1つのデータベースを管理する構成です。 特に検討すべきことはありません。
クラスタ構成（高可用構成） 最小限のダウンタイムで信頼性を提供するための、複数のサーバーを組み合わせた構成です。 データベースのクラスタ化については、Oracle DatabaseはReal Application Clustersなどで実現しますが、PostgreSQLはPgpool-IIなどで対応が可能です。
【参考】
Enterprise Postgresは障害時に高速な切り替えが可能なデータベース多重化機能が利用できます。

2.4.2 データベース運用設計

移行先システムのデータベースの運用について設計します。データベースの運用はデータベースごとに異なるため、PostgreSQLのアーキテクチャーや機能に準じて、新たに設計する必要があります。運用設計には、主に以下のような観点が必要です。

バックアップとリカバリー

PostgreSQLは、論理バックアップ、物理バックアップ、また、継続的アーカイブを用いたオンラインバックアップなどに対応しています。さらに、周辺ツールのpg_rmanを利用したバックアップとリカバリーの管理も行えます。PostgreSQLのバックアップとリカバリーについては、以下の記事で紹介していますので併せてご覧ください。

データベースの監視

データベースの監視は、運用中のデータベースにおける突然の停止、性能劣化、ディスク領域不足などの事象への迅速な対応や、トラブルの未然防止などを目的に設計します。その際、データベースのアーキテクチャーに沿って、様々な観点で、常時監視あるいは定期監視を行う必要があります。PostgreSQLのデータベース監視については、以下の記事で紹介していますので併せてご覧ください。

監査ログ

PostgreSQLでは、拡張モジュールのpgauditが利用できます。なお、Enterprise Postgresでは、実際の業務利用を想定し、SQL文の実行結果情報を取得するなどの機能強化が行われています。以下の記事で紹介していますので併せてご覧ください。

メンテナンス（チューニング）

PostgreSQLでは、データベースのパフォーマンスを診断するために、統計情報ビューのpg_stat_statementsを参照する方法やサーバーログを利用する方法があります。また、周辺ツールのpg_statsinfoやpgBadgerなどを活用する方法もあります。検出されたパフォーマンス上の問題に対し、総合的な観点で原因を特定して対処する方針を決めます。PostgreSQLのメンテナンス（チューニング）については、以下の記事で紹介していますので併せてご覧ください。

高可用性

PostgreSQLでは、主にストリーミングレプリケーションをベースとした冗長化機能を用いますが、運用においては、平常時だけでなく高負荷時や異常時のシステム要件を満たすよう設計します。そのため、監視、異常検知、アプリケーションからの透過的接続などの考慮を含めた設計が必要になります。参考として、Enterprise Postgresの高可用の考え方や対策を以下の記事で紹介していますので併せてご覧ください。

データベース認証

OracleとPostgreSQLの認証方式や設定方法が異なります。詳細については、PostgreSQLのマニュアルを参照してください。なお、マニュアルの章番号はバージョンによって変わることがありますのでご注意ください。

データベースのバージョンアップ

PostgreSQLは、バグ修正やセキュリティ対応のマイナーバージョンアップと、機能追加や性能改善を伴うメジャーバージョンアップがあります。周辺ツールのpg_upgradeによるデータ移行が可能です。また、同期レプリケーション構成の場合は、ローリングアップデートが可能です。詳細については、PostgreSQLのマニュアルを参照してください。なお、マニュアルの章番号はバージョンによって変わることがありますのでご注意ください。

2.4.3 アプリケーション設計

Oracle DatabaseのSQLやアプリケーションなどを移行先のPostgreSQLで実行するための移行方式を設計します。ここでは、SQL、PL/SQL、アプリケーション、バッチ処理、および、データの資産移行の際に注意すべき点を説明します。

SQL

以下の分類で、Oracle DatabaseのSQLをPostgreSQLに移行する際の注意点を示します。

表3 データ型の移行に関する注意点

構文 説明
文字データ PostgreSQLでは、CHARなどの一部の文字型はサポートされていますが、最大サイズの指定方法に違いがあります。 VARCHAR2、NVARCHAR2、CLOB、NCLOB、LONGなどの一部の文字型はサポートされていないため、TEXT型などPostgreSQLの類似の文字型の利用、あるいは、代替方法の検討が必要です。なお、orafce拡張モジュールを利用することで、VARCHAR2、NVARCHAR2が利用できます。その際にも、最大サイズの指定方法に違いがあるため検討が必要です。
【参考】
Enterprise PostgresはOrafce（Oracle Databaseと互換性がある関数やデータ型を提供するOSS）を同梱し、標準サポートしています。
数値データ Oracle DatabaseとPostgreSQLで違いがあるため修正が必要です。有効桁数や切り捨てなどの違いにも注意が必要です。
日時データ Oracle DatabaseとPostgreSQLで同じ型が使用できます。ただし、精度やタイムゾーン指定、表示形式に違いがあるため注意が必要です。
特殊なデータ BLOBデータ型などのラージ・オブジェクト（LOB）は、PostgreSQLの対応する型に変更します。 XMLデータ型やJSONデータ型は、どちらのデータベースでも使用できますが、機能に違いがあるため修正が必要です。その他の型については、対応する型がPostgreSQLにありません。使用方法を踏まえてどの型に移行するか検討してください。
ROWIDデータ型 ROWID型、UROWID型と同等な型はPostgreSQLにありません。serial型や順序（シーケンス）で代替するなど、行を特定する方法を検討してください。
SQL演算子とファンクションのメタデータ 同等の型はPostgreSQLにはありません。使用方法を踏まえてどの型に移行するか検討してください。

表4 DDL文の移行に関する注意点

構文 説明
スキーマ Oracle DatabaseのCREATE SCHEMA文では、実際にスキーマは作成されません。一方、PostgreSQLのCREATE SCHEMA文は新しいスキーマを作成します。指定したスキーマ名と同じ名前のスキーマがすでに存在する場合、PostgreSQLのCREATE SCHEMA文はエラーを返すため注意が必要です。
データベース・リンク Oracle Databaseはデータベース・リンクの作成機能があります。PostgreSQLで外部の表への操作を行う場合、ユーザーは外部データラッパを使用します。外部データラッパはPostgreSQLやOracle Databaseなどとの接続が可能であり、CREATE EXTENSIONコマンドでデータベースへ登録を行うことで使用できます。
データベース・トリガー

PostgreSQLでは、Oracle Databaseと同様にトリガーが使用可能です。ただし、Oracle DatabaseとPostgreSQLでは以下の点に違いがあるため注意が必要です。

  • トリガーの記述方法、オプション
  • トリガーを記述する言語
  • トリガーを起動可能なイベント
索引（インデックス） Oracle Databaseには、Bツリー索引、ビットマップ索引、ファンクション索引、アプリケーション・ドメイン索引があります。PostgreSQLではこれらのうち、Bツリー索引が使用可能です。Bツリー索引以外を使用している場合、PostgreSQLがサポートする索引に変更するか、索引を削除する必要があります。また、索引キーの長さや、索引キーに指定できるデータ型に違いがありますので注意してください。
マテリアライズド・ビュー PostgreSQLでもOracle Databaseと同様にマテリアライズド・ビューが使用可能です。しかし、PostgreSQLのマテリアライズド・ビューは、Oracle Databaseのマテリアライズド・ビューとは機能やリフレッシュ方法、構文などに違いがあるため注意が必要です。
ユーザー定義の演算子（オペレーター） PostgreSQLでもOracle Databaseと同様に新しい演算子をユーザーが定義することが可能です。ただし、構文に違いがあるため注意が必要です。
順序（シーケンス） PostgreSQLでもOracle Databaseと同様に順序が使用可能です。ただし、構文に違いがあるため注意が必要です。
ストアド・ファンクション、 ストアド・プロシージャ PostgreSQLでもOracle Databaseと同様にストアド・ファンクションおよびストアド・プロシージャが使用可能です。ただし、構文や使用可能な言語に違いがあるため注意が必要です。
リレーショナル表（表、テーブル） PostgreSQLでも、リレーショナル表相当の表は使用可能です。ただし、指定可能なデータ型や構文に違いがあるため注意が必要です。また、Oracle Databaseと同様にPostgreSQLでも表のパーティションの定義が可能です。ただし、Oracle Databaseとは指定できる分割の種類、機能、構文などに違いがあるため注意が必要です。
ビュー PostgreSQLでもOracle Databaseと同様にビューが使用可能です。ただし、PostgreSQLのビューは、WITH READ ONLYオプション相当の機能がありません。また構文にも違いがあるため注意が必要です。
ロール PostgreSQLでは、Oracle Databaseと同様にロールが使用可能です。ただし、構文に違いがあるため注意が必要です。
ユーザー Oracle Databaseとは違い、PostgreSQLのユーザーはロールの一種です。この差異により、ユーザーを作成するSQL文などにも違いがあるため注意する必要があります。また、PostgreSQLでは、ユーザーの認証管理は設定ファイルのpg_hba.confで行います。
その他のDDL文

以下の機能はPostgreSQLにはありません。代替方法の検討を行う必要があります。

  • クラスタ
  • 索引構成表
  • オブジェクト表
  • パッケージ
  • シノニム

表5 DML文の移行に関する注意点

構文 説明
SELECT / INSERT / UPDATE / DELETE PostgreSQLでも、基本的な構文はOracle Databaseと同じです。ただし、細かな構文には違いがあるため注意が必要です。
MERGE PostgreSQLにはMERGE文はありません（注1）。しかし、INSERT文のON CONFLICT句を使用することで同様の処理（UPSERT）を実現することができます。
CALL PostgreSQLにもCALL文は存在します。ただし、構文はOracle Databaseとは違いがあるため注意が必要です。
EXPLAIN PLAN Oracle DatabaseのEXPLAIN PLAN文は、PostgreSQLのEXPLAIN文に相当します。ただし、実行結果が表に格納されないこと、および、構文に違いがありますので、使用する場合に注意が必要です。
LOCK TABLE Oracle DatabaseのLOCK TABLE文は、PostgreSQLではLOCK文と呼ばれます。ただし、一部のロックモードの名前や構文に違いがあるため注意が必要です。
  • （注1）
    PostgreSQL 15から使用可能となりました。

表6 ファンクションの移行に関する注意点

構文 説明
単一行ファンクション 数値ファンクション

数値ファンクションはPostgreSQLでも一部を除きそのまま使用できます。ただし、パラメーターの違いや戻り値の精度が違う場合があるため注意が必要です。なお、以下のファンクションは別のファンクションへの書き換えが必要です。

  • BITAND
  • REMAINDER
文字値を戻す文字ファンクション

文字値を戻す文字ファンクションはPostgreSQLでも一部を除きそのまま使用できます。ただし、パラメーターが違う場合があるため注意が必要です。なお、以下のファンクションは別のファンクションへの書き換えが必要です。

  • NCHR
  • NLS_INITCAP
  • NLS_LOWER
  • NLS_UPPER
  • SOUNDEX
  • TRANSLATE ... USING
数値を戻す文字ファンクション 数値を戻す文字ファンクションはPostgreSQLでも一部を除きそのまま使用できます。
日時ファンクション 日時ファンクションはPostgreSQLでも一部を除きそのまま使用できます。ただし、精度やタイムゾーンに対応していないなど、違う場合があるため注意が必要です。
一般的な比較ファンクション 一般的な比較ファンクションはPostgreSQLでもそのまま使用できます。
変換ファンクション 変換ファンクションはPostgreSQLでも一部を除きそのまま使用できます。ただし、精度やパラメーターが違う場合があるため注意が必要です。
収集ファンクション 収集ファンクションに相当するファンクションは、PostgreSQLにはありません。なお、CARDINALITYはSQLで同等の情報を取得できますが、その他の収集ファンクションについては代替方法を検討する必要があります。
XMLファンクション XMLファンクションはPostgreSQLでも一部を除きそのまま使用できます。ただし、パラメーターに違いがあるため注意が必要です。
JSONファンクション JSONファンクションはPostgreSQLにも存在しますが、Oracle Databaseのファンクションとは異なります。そのため、処理内容に合わせて移行方法を検討する必要があります。
エンコーディング・ファンクションおよびデコーディング・ファンクション エンコーディング・ファンクションおよびデコーディング・ファンクションのうち、DECODEはPostgreSQLにも存在しますが、Oracle Databaseのファンクションとは異なります。そのため、移行方法を検討する必要があります。その他については代替方法を検討する必要があります。
NULL関連ファンクション NULL関連ファンクションはPostgreSQLでも一部を除きそのまま使用できます。
環境ファンクションおよび識別子ファンクション 環境ファンクションおよび識別子ファンクションのうち、USERはPostgreSQLにある同等の関数（SESSION_USER）に修正することで対応できます。その他については代替方法を検討する必要があります。
その他の単一行ファンクション

以下の単一行ファンクションに相当するファンクションは、PostgreSQLにはありません。代替方法を検討する必要があります。

  • キャラクタ・セット・ファンクション
  • 照合ファンクション
  • ラージ・オブジェクト・ファンクション
  • 階層ファンクション
  • データ・マイニング・ファンクション
集計ファンクション 集計ファンクションは、一部を除きPostgreSQLでもそのまま使用可能です。ただし、戻り値やオプションなどが違う場合があるため注意が必要です。
分析ファンクション 分析ファンクションは、一部を除きPostgreSQLでもそのまま使用可能です。ただし、戻り値やオプションなどが違う場合があるため注意が必要です。
オブジェクト参照ファンクション オブジェクト参照ファンクションに相当するファンクションは、PostgreSQLにはありません。代替方法を検討する必要があります。
モデル・ファンクション モデル・ファンクションに相当するファンクションは、PostgreSQLにはありません。代替方法を検討する必要があります。
OLAPファンクション OLAPファンクションに相当するファンクションは、PostgreSQLにはありません。代替方法を検討する必要があります。
データ・カートリッジ・ファンクション データ・カートリッジ・ファンクションに相当するファンクションは、PostgreSQLにはありません。代替方法を検討する必要があります。
ユーザー定義ファンクション PostgreSQLにもユーザー定義ファンクションはあります。しかし、ユーザー定義ファンクションの処理内容をPostgreSQLで実行できるように構文などを修正する必要があります。

表7 その他SQL文の移行に関する注意点

構文 説明
トランザクション制御文 COMMIT PostgreSQLでもOracle Databaseと同様にCOMMIT文が使用できます。ただし、構文に違いがあるため注意が必要です。
ROLLBACK PostgreSQLでもOracle Databaseと同様にROLLBACK文が使用できます。ただし、構文に違いがあるため注意が必要です。また、TO SAVEPOINT句を指定している場合、PostgreSQLではROLLBACK TO SAVEPOINT文を使用します。
SAVEPOINT PostgreSQLでもOracle Databaseと同様にSAVEPOINT文が使用できます。ただし、同じ名前のセーブポイントを作成した場合の動作に違いがあるため注意が必要です。
SET TRANSACTION PostgreSQLにもSET TRANSACTION文はあります。ただし、PostgreSQLのSET TRANSACTION文は、Oracle DatabaseでISOLATION LEVEL句を指定した場合の機能です。また、構文に違いがあるため注意が必要です。USE ROLLBACK SEGMENT句などの他の句を使用している場合、移行方法の検討が必要です。
SET CONSTRAINT PostgreSQLでもOracle Databaseと同様にSET CONSTRAINT文の機能が使用できます。ただし、PostgreSQLではSET CONSTRAINTS文に変える必要があります。
セッション制御文 ALTER SESSION PostgreSQLには、Oracle DatabaseのALTER SESSION文に相当する文はありません。代替方法を検討する必要があります。
SET ROLE Oracle DatabaseとPostgreSQLでは、SET ROLE文の処理が異なります。Oracle DatabaseのSET ROLE文は、そのセッションに対してロールを使用可能または使用禁止にします。PostgreSQLのSET ROLE文は、現在のセッションにおけるユーザー識別子を変更します。そのため、代替方法を検討する必要があります。
システム制御文 PostgreSQLにもALTER SYSTEM文がありますが、Oracle DatabaseとPostgreSQLではデータベースのアーキテクチャーが違うため、PostgreSQLに合わせた方法に変更する必要があります。
演算子

多くの演算子はPostgreSQLでもそのまま使用できます。しかし、以下の演算子は修正が必要です。

  • 階層問合せ演算子(PRIOR、CONNECT_BY_ROOT)
  • MINUS
  • MULTISET演算子(MULTISET、MULTISET EXCEPT、MULTISET INTERSECT、MULTISET UNION)

また、連結演算子の「||」は、連結する文字列の中にNULLが含まれている場合の動作に差異があるため、注意が必要です。
式

多くの式はPostgreSQLでもそのまま使用できます。しかし、以下の式は修正が必要です。

  • CURSOR式
  • モデル式
  • オブジェクト・アクセス式
  • プレースホルダ式
  • 型コンストラクタ式

また、日時式や期間式などは構文や結果の形式などに違いがあるため注意が必要です。
条件

多くの条件はPostgreSQLでもそのまま使用できます。しかし、以下の条件は修正が必要です。

  • ^=（不当性のテスト）
  • 浮動小数点条件（IS [NOT] NAN、IS [NOT] INFINITE）
  • モデル条件（IS ANY条件、IS PRESENT条件）
  • 多重集合条件（IS A SET条件、IS EMPTY条件、MEMBER条件、SUBMULTISET条件）
  • REGEXP_LIKE条件
  • XML条件（EQUALS_PATH条件、UNDER_PATH条件）
  • IS OF type条件

また、PostgreSQLでは、ANY、SOME、ALLに式リストが使用できません。
その他の注意点 識別子 Oracle DatabaseとPostgreSQLでは、非引用識別子の大文字小文字の扱いが異なります。PostgreSQLでは非引用識別子は小文字として解釈されるため、アプリケーションなどで大文字小文字を区別する場合は修正が必要です。
暗黙的なデータ変換 PostgreSQLでも暗黙的なデータ変換は使用できます。しかし、Oracle Databaseと比較して変換できる範囲が小さいため、明示的なデータ変換を行うなどの修正が必要となる場合があります。
長さが0の文字値 Oracle Databaseでは、長さが0の文字値をNULLとして扱います。一方、PostgreSQLでは長さが0の文字値とNULLは別の値として扱います。長さが0の文字値をNULLと判定することを前提としている場合、データやアプリケーションなどの修正が必要です。
照合順（ソート順）

Oracle DatabaseとPostgreSQLでは、照合順が全てのパターンにおいて同じ結果にならない場合があります。その場合は、業務影響が少ないパターンで近似するものを選ぶ必要があります。照合順序には、各国語を合わせると複数ありますが、日本語を含む場合は以下の2種類のみとなります。

  • UTF8文字で辞書順
  • Cロケールによる、UTF8文字コードのバイナリー順
PL/SQL

以下に、Oracle DatabaseのPL/SQLをPostgreSQLのPL/pgSQLに移行する際の注意点を示します。

表8 PL/SQLの移行に関する注意点

構文 説明
基本構文 ブロック ブロック、エラー処理、変数などの基本的な構文要素は、PostgreSQLでも使用できます。
エラー処理
変数
データ型 スカラー・データ型 SQLデータ型については、「表3 データ型の移行に関する注意点」を参照してください。BOOLEAN型はPostgreSQLでもそのまま使用できます。その他の型については、代替方法を検討する必要があります。
コンポジット・データ型 コレクション型に相当する型はPostgreSQLにはありません。一時表などで代替します。レコード変数はPostgreSQLでも使用できますが、細かな仕様で違いがあるため注意が必要です。
制御文 条件文 IF文、CASE文はPostgreSQLでも使用できます。
LOOP文 基本LOOP文、WHILE LOOP文、FOR LOOP文はPostgreSQLでも使用できます。ただし、FOR LOOP文のREVERSE句には仕様差があるため注意が必要です。
GOTO文 GOTO文はPostgreSQLでは使用できません。GOTO文を使わないよう検討する必要があります。
静的SQL カーソル カーソルはPostgreSQLでも使用できますが、細かい仕様差があるため注意が必要です。
トランザクションの処理および制御 COMMIT文、ROLLBACK文はPostgreSQLでも使用できますが、トランザクション制御の仕様に違いがあるため注意が必要です。例えば、エラー処理(EXCEPTION句)を含むブロックでは、COMMIT文、ROLLBACK文がエラーになります。
動的SQL EXECUTE IMMEDIATE文 EXECUTE IMMEDIATE文はPostgreSQLのEXECUTE文に変更が必要です。
OPEN FOR文 OPEN FOR文はPostgreSQLでも使用できますが、細かい仕様差があるため注意が必要です。
サブプログラム（ファンクション内ファンクションなど） サブプログラムはPostgreSQLで使用できないため、別のプロシージャやファンクションなどに変更する必要があります。また、共通変数も使用できないため、代替方法を検討する必要があります。
トリガー トリガーはPostgreSQLでも使用できますが、細かい仕様差があるため注意が必要です。
パッケージ パッケージはPostgreSQLで使用できないため、プロシージャやファンクションなどに変更する必要があります。また、パッケージ内のサブプログラムやパッケージ変数も使用できないため、代替方法を検討する必要があります。
Oracle社が提供するPL/SQLパッケージ 代替方法を検討する必要があります。なお、DBMS_OUTPUT、UTL_FILEなどの一部パッケージは、代替機能としてorafce拡張モジュールが使用できます。ただし、細かい仕様差があるため注意が必要です。
アプリケーション

Oracle Databaseのアプリケーション用インターフェイスの中には、PostgreSQLで利用できないものがあります。また同じインターフェイスが利用できる場合でも、APIの仕様が異なる場合があります。そのような場合には、代替方法を検討する必要があります。PostgreSQLでは、標準で利用可能なインターフェイスとして、C言語用ライブラリー（libpq）やC言語による埋め込みSQL（ECPG）があり、さらに、JDBCドライバー（Type4）、ODBCドライバーなどのPostgreSQL専用の各種言語用のインターフェイスも利用できます。その利用については、仕様の確認が必要です。

運用に関するバッチ処理

運用に関するバッチ処理（スクリプトファイルなど）に記述されているデータベース運用コマンドは、Oracle DatabaseとPostgreSQLで大きく仕様が異なります。各コマンドに対して代替処理を検討する必要があります。

データ

データの移行は、基本的には以下の手順で行います。

  1. 現行システムのデータベースからデータを抽出し、ファイルに格納する

  2. 手順1.のファイルのデータ形式を移行先システムのデータベースの形式に変換する

  3. 手順2.のファイルを移行先システムに格納する

データ移行の設計においては、次の点を考慮してください。

  • 手順1.において、ファイル形式にCSVファイルを利用することを推奨します。CSVファイルは、手順3.においてPostgreSQLにデータを格納する時にCOPY文を利用することができます。COPY文はデータを効率良く格納することができます。
  • 対象データがOracle Database固有のデータ型、または、対象データに外字が含まれている場合、手順1.のデータの抽出方法から検討する必要があります。
  • 手順2.においてデータ形式を変換する際、ヘッダー行の有無やNULL値の表現方法について注意する必要があります。

2.4.4 実装（プログラミング）

「2.4.2 データベース運用設計」、および、「2.4.3 アプリケーション設計」で決定された移行方法に従って、現行システムの資産を修正します。これらの資産には、データベースを操作するためのSQL、PL/SQL、アプリケーション、および、運用に関するバッチ処理が含まれます。
また、データについても、設計プロセスで決定された方法で移行を行います。

2.4.5 テスト

移行先システムでの実装が完了したら、システムが期待どおりに動作することを確認するために動作検証を行います。また、データベースが変更されたことによる影響を判断し、システムの機能要件と非機能要件を満たしているかを評価します。評価のために次のテストを実施することをお勧めします。

スキーマの検証（プログラムテスト）

表、索引、ストアドファンクション、ストアドプロシージャなどの現行システム上の資産が、すべて移行先システムに移行されたことを確認します。
確認方法の例としては、Oracle Databaseのシステム表とビューからデータベースオブジェクト定義を取得し、同様に、PostgreSQLのシステムカタログとシステムビューからデータベースオブジェクト定義を取得します。これら取得した定義を比較して、必要なすべてのオブジェクトが移行されたことを確認します。

データ検証

データが現行システムのデータベースから移行先システムのデータベースへ正常に移行されたことを確認します。
確認方法の例としては、双方のデータベースの表データをCSVなどの同じ形式のファイルに出力します。これらのファイルを比較して、移行前と移行後のデータの間に違いがないことを確認します。

アプリケーション機能テスト

移行先システムのアプリケーションが機能要件を満たしていることを確認します。機能要件に基づいてテストケースシナリオを作成し、すべてのシナリオについてのテストを完了させて、結果が期待どおりかどうかを確認します。

パフォーマンステスト

移行先システムがパフォーマンス要件を満たしていることを確認します。パフォーマンス要件に基づいてテストケースシナリオを作成し、すべてのシナリオについてのテストを完了させて、結果が期待どおりかどうかを確認します。
移行先システムがパフォーマンス要件を満たしていない場合は、原因を分析し、問題を解決します。パフォーマンスの問題を解決するためには、データベースのパラメーターを最適化したり、SQL文を適切に変更したりします。具体的には以下の記事を参考にしてください。

運用テスト

移行先システムが期待どおりに業務を運用できることを確認します。以下のような観点でテストケースシナリオを作成し、すべてのシナリオについてのテストを完了し、結果が期待どおりであるかどうかを確認します。

  • データベースの開始と停止を確認します。
  • データのバックアップの取得と管理について確認します。
  • VACUUMや索引（インデックス）再構築を行うことで、ディスクの使用状況の確認と領域割り当てについて確認します。
  • 監査ログの出力情報を確認します。
  • データベースへの接続の状態を確認します。たとえば、長時間接続されたままになっていないか、特定の処理がリソースを占有していないかを確認して、パフォーマンスの低下を防止します。
  • パッチ適用について確認します。
  • 高可用性環境における保守のため、ノードの切り替え、切断、フェイルバックなどを確認します。
  • データベースの監視が正しく行われることを確認します。
回復テスト

移行先システムに異常系のトラブルが発生した場合でも、業務を回復し継続できることを確認します。以下のような異常系のテストケースシナリオを作成し、すべてのシナリオについてのテストを完了し、業務をすぐに再開できるかどうかを確認します。

  • ディスクやネットワーク機器などのハードウェア障害から回復します。
  • バックアップからデータ復旧します。
  • アプリケーションの異常系の動作を確認します。たとえば、リソースを占有する接続がある場合は、その接続を切断して待機状態になっていた他の接続待ちを解消します。
  • ディスク容量が不足した場合の処理を確認します。
  • 高可用性環境における、フェイルオーバーの処理を確認します。

Oracle DatabaseからPostgreSQLへの移行を前提として、安全な移行プロセスの進め方について述べました。移行すべき資産ごとの移行の方向性も示しましたので、実際に移行作業を行う際の指標としてご利用頂けると幸いです。

参考

Enterprise Postgresは、OSSのPostgreSQLを拡張し、エンタープライズ利用に向けて信頼性、性能、セキュリティを強化したデータベースであり、ワンストップの長期サポートにも対応しています。また、他社データベースからの移行支援サービスとして、アプリケーションの移行アセスメントから資産移行、導入までのトータルなサポートを提供しています。

2023年5月8日更新

こちらもおすすめ

オンデマンド（動画）セミナー

    • PostgreSQLに関連するセミナー動画を公開中。いつでもセミナーをご覧いただけます。
      • 【事例解説】運送業務改革をもたらす次世代の運送業界向けDXプラットフォームの構築
      • ハイブリッドクラウドに最適なOSSベースのデータベースご紹介

PostgreSQLについてより深く知る

PostgreSQLに興味をお持ちのお客様はこちらのコンテンツもお勧めです。ぜひご覧ください。

Enterprise Postgres 製品情報

Enterprise Postgresの特長や機能などの製品情報をご案内しています。

 Enterprise Postgresの製品情報を見る

【無料】体験版ダウンロード

Enterprise Postgresの全機能を無料で90日間お試し頂ける体験版がダウンロードできます。

 無料体験版をダウンロードする

Enterprise Postgres 17

最新バージョン「17」について解説します。

 Enterprise Postgres 17のこだわりを知る

PostgreSQLインサイド

PostgreSQLを企業利用するために必要な技術面、コミュニティー面、サポート面を解説します。

 PostgreSQLインサイドを見る

本コンテンツに関するお問い合わせ

お電話でのお問い合わせ

Webでのお問い合わせ

当社はセキュリティ保護の観点からSSL技術を使用しております。

ページの先頭へ