データベース移行で押さえておくべきこと ～アーキテクチャーと機能の違い～
PostgreSQLインサイド
近年、基幹システムの老朽化や複雑化、あるいは、運用保守コストの負担といった課題を解決するため、モダナイゼーションの必要性が高まっています。そのなかで、データ資産の活用を考慮しつつ、データベースをどのように移行するのかが重要なポイントになります。その際、運用保守コストの削減や、ベンダーロックインの回避、エコシステムの構築を理由に、商用データベースからオープンソースソフトウェア（以降、OSSと略す）系のデータベースへの移行を検討されるケースが増えています。
この記事では、Oracle DatabaseからPostgreSQLへの移行を取り上げ、押さえておくべきポイントとして、「アーキテクチャーと機能の違い」をテーマに説明します。
なお、対象となるOracle Databaseのバージョンは10g以降、PostgreSQLのバージョンは10以降を想定しています。
1. アーキテクチャーの基本的な違い
データベース移行の際に意識すべき主なアーキテクチャーの違いについて説明します。
表のファイル構造
PostgreSQLはOracle Databaseと同じく、オブジェクトリレーショナルデータベース管理システム（ORDBMS）であり、どちらも表（テーブル）のデータを別々の物理ファイルに保持します。ただし、PostgreSQLの物理ファイルの構成はOracle Databaseと異なります。
移行の際に注意すべきポイントは、PostgreSQLは1つのデータファイルに複数の表のデータを格納できないことです。
Oracle Database
表や索引などのオブジェクトは、データファイルと呼ばれる物理ファイルに格納します。データファイルは、表領域（テーブル空間）に対して割り当てます。Oracle Databaseでは以下のように表を格納することが可能です。
- 1つの表を、複数のデータファイルに分割して格納できる（データファイル名を指定できる）。
- 1つのデータファイルに複数の表のデータを格納できる。
PostgreSQL
1つの表に対して、1つ以上の物理ファイルを作成して格納します。ファイルの配置先は固定のディレクトリー配下です。ただし、表領域を使用することで、PostgreSQLは任意のディレクトリーにファイルを格納できます。ファイルの作成はPostgreSQLがコントロールするため、以下のようにOracle Databaseと異なる点があります。
- 1つの表を、複数のデータファイルに分割して格納できる（データファイル名は指定できない）。
- 1つのデータファイルに複数の表のデータを格納することはできない。
図1：表のファイル構造（概要）
同時実行制御
データベースのパフォーマンスを向上させるためには、データへの同時アクセスの管理が不可欠です。つまり、同一のオブジェクトデータへの過度のロックを防ぎながら柔軟なアクセス制御を行うことです。PostgreSQLは、Oracle Databaseと同様に読み取り一貫性を保ちながら同時実行性を実現していますが、採用している仕組みが異なります。
移行の際に注意すべきポイントは、PostgreSQLは更新または削除操作を実施したタイミングでは以前の行データが削除されないため、特に更新が多いシステムでは物理ファイルが肥大化し、パフォーマンスが劣化する可能性がある点です。
Oracle Database
DML（データ操作言語）によりデータを変更する場合は、以前のデータをUNDO表領域という専用の領域に保存します。削除された領域は再利用することが可能です。あるセッションによるデータの変更がコミットされていない時に、他のセッションが同じデータを参照する場合は、UNDOレコードの情報（参照時にコミット済である情報）を参照します。
PostgreSQL
同時実行制御を追記型アーキテクチャーにより実現しています。データを更新または削除する場合は、変更対象の行データに削除マークを付け、末尾に新しいデータを追加します。この時、以前の行データは削除されず、ロールバックに必要な情報として残されます。あるセッションによるデータの変更がコミットされていない時に、他のセッションが同じ情報を参照する場合は、以前の行データを参照します。
トランザクション
PostgreSQLは、Oracle Databaseと同様にトランザクションをサポートしていますが、自動コミットおよびエラー時の動作に違いがあります。
移行の際に注意すべきポイントは、Oracle Databaseは文単位で処理をコミットするのに対し、PostgreSQLはトランザクション単位で処理をコミットする点です。移行時にアプリケーションなどの修正が必要となる場合もあるため、この違いに注意してください。
Oracle Database
- 自動コミット
DDL（データ定義言語）では、自動コミットを行います。一方、DMLでは自動コミットを行いません。 - エラー時の動作
トランザクション内でエラーが発生しても、最後にCOMMITが実行されていれば、正常に実行できたDMLの処理を確定します。
PostgreSQL
- 自動コミット
DDLでは、自動コミットを行いません。一方、DMLでは明示的に指定しない限り、自動コミットを行います。 - エラー時の動作
トランザクション内でエラーが発生すると、最後にCOMMITが実行されても、ROLLBACKを実行した場合と同じ処理を行います。
排他制御（ロック機能）
PostgreSQLは、Oracle Databaseと同様に排他制御をサポートしていますが、排他制御の動作について、いくつか異なる部分があります。
移行の際に注意すべきポイントは、PostgreSQLはアプリケーション側で適切な設定をしない限り、ロックを取得できない場合は、ロックが取得できるまで待ち続ける点です。移行時にアプリケーションの修正が必要となる場合もあるため、この違いに注意してください。
Oracle Database
- ロックの単位と明示的なロックの取得方法
表ロックと行ロックの2種類があります。アプリケーションは以下のSQL文を使用して明示的なロックを取得します。- 表ロックはLOCK TABLE文で指定します。
- 行ロックはSELECT文にFOR UPDATE句またはFOR SHARE句を指定します。
- DDL実行時のロック
DDL実行時には、自動的に適切なロックを取得します。ロックを取得できない場合、エラーが発生します。
PostgreSQL
- ロックの単位と明示的なロックの取得方法
ロックの単位と明示的なロックの取得方法は、Oracle Databaseと同じです。 - DDL実行時のロック
DDL実行時には、自動的に適切なロックを取得します。ロックを取得できない場合、ロックが取得できるまで待ちます。
データストレージ容量の拡張
Oracle DatabaseとPostgreSQLでは、ストレージ容量を拡張する方法に違いがあります。PostgreSQLで容量を拡張する場合、拡張したい表などの全てのデータをコピーする必要があるため、データベース管理者は容量拡張を計画的に実施する必要があります。
Oracle Database
データベース管理者は表領域のサイズを増やすことでデータストレージ容量を拡張できます。
PostgreSQL
データベース管理者は表領域のサイズを増やすことができません。容量を拡張する場合は、新しいディスクに表領域を作成し、拡張したい表や索引などを移動することで対応します。そのため、移行先データベースシステムを設計する際には、データ容量をすぐに拡張する必要のないよう、以下のことを考慮することをお勧めします。
- 適切なディスク容量と表領域の構成を決定し、パーティションを使用するかどうかを検討し、適切なバキューム計画を検討します。
- 本番環境に移行した後にデータ容量を拡張する必要がある場合は、データのコピー時間を適切に考慮して、計画的に拡張を実施します。
更新履歴情報（REDOログ）
Oracle DatabaseとPostgreSQLでは、更新履歴情報の名前が異なります。Oracle Databaseでは更新履歴情報を記録するファイルはREDOログファイルと呼びますが、PostgreSQLでは先行書き込みログ（WAL）と呼びます。
名前は違いますが、PostgreSQLのWALはOracle DatabaseのREDOログファイルと同様の機能で使用されます。
エンコーディング（文字コード）
Oracle DatabaseとPostgreSQLでは、データベースに格納するデータやメッセージに対して、指定できるエンコーディングが異なります。移行元システムにおいて、PostgreSQLでサポートしていないエンコーディングを使用している場合は、PostgreSQLでサポートしているエンコーディングのいずれかに変更するよう検討する必要があります。
データベース環境設定ファイル
Oracle Databaseで使用している設定ファイルは、PostgreSQLでは使用できません。Oracle Databaseのパラメーター設定や接続先設定などを確認し、PostgreSQLの設定ファイルに適用する必要があります。
スキーマ
PostgreSQLは、Oracle Databaseのようなスキーマの概念をサポートしていますが、機能には違いがあります。
Oracle Databaseは、ユーザー名と同じ名前のスキーマが自動的に作成されます。PostgreSQLは、デフォルトで"public"スキーマが作成されますが、ユーザー名と同じ名前のスキーマは自動的に作成されません。
移行の際には、自動的に作成されるスキーマやスキーマの検索順の差異を考慮し、同じ処理が行えるようにスキーマを追加で作成するなどの検討が必要です。
PostgreSQLは、search_pathパラメーターでスキーマの検索順を適切に設定することが重要になります。PostgreSQLは、search_pathパラメーターを使用して、検索するスキーマのリストであるスキーマ検索パスを管理します。クエリの実行時にスキーマ名が指定されていないと、PostgreSQLは検索パスで指定された順序でスキーマを検索し、最初に一致するオブジェクトがクエリの実行に使用されます。また、各ユーザーが作成したスキーマはデフォルトで作成したユーザーが所有するため、他のユーザーがアクセスできるようにするには、適切な権限を付与する必要があります。
2. データベースの観点ごとの移行難易度
データベース移行を実現するためには、「1. アーキテクチャーの基本的な違い」で述べた主な相違点に加えて、様々な観点での影響を認識し、移行の際の難易度を考慮した正しい見積りを行う必要があります。ここでは移行難易度を以下の表のとおり、0から3で定義しました。移行難易度の数字が大きいほど移行コストがかかります。
| 移行難易度 | 移行難易度の説明 |
|---|---|
| 0 | PostgreSQLに互換性があるため、変更の必要はありません。 |
| 1 | PostgreSQLに機能の互換性がありますが、インターフェイスなどにいくつかの違いがあるため変更が必要になる場合があります。 |
| 2 | PostgreSQLは主な機能をサポートしていますが、関数や構文などの一部に互換性がなく、移行方法の調査や検討が必要になります。 |
| 3 | PostgreSQLに機能がなく、同等機能を実装するための代替方法の検討が必要になります。 |
ここからは、データベース特有の観点ごとに、移行難易度と調査・検討すべき点について説明します。また、参考として、OSSのPostgreSQLをエンタープライズ向けに強化した製品「FUJITSU Software Enterprise Postgres（以降、Enterprise Postgresと略す）」の情報も併せて示します。
基本アーキテクチャーに関する移行観点
| 項目 | 移行難易度 | 補足 | |
|---|---|---|---|
| エンコーディング（文字セット） | 2 | PostgreSQLはUNICODEとEUCをサポートしています。その他のエンコーディングを使用している場合には検討が必要です。 | |
| データベースの最大容量 | 0 | ||
| 表の定量制限 | 0 | ||
| 表の索引数 | 0 | ||
| 表の索引形式 | 2 | B-tree以外を使用している場合には検討が必要です。 | |
| データ型 | 文字型 | 2 | PostgreSQLはCHARなどの一部の文字型はサポートされていますが、最大サイズの指定方法に違いがあります。VARCHAR2、NVARCHAR2、CLOB、NCLOB、LONGなどの一部の文字型はサポートされていないため、TEXT型などPostgreSQLの類似の文字型の利用、あるいは、代替方法の検討が必要です。なお、拡張モジュールのorafceを利用することで、VARCHAR2、NVARCHAR2が利用できます。その際にも、最大サイズの指定方法に違いがあるため検討が必要です。 |
| 数値型 | 2 | PostgreSQLに同じ名前の型がある場合でも、有効桁数や切り捨てなどの違いなどがあるため検討が必要です。 | |
| 日時型 | 2 | PostgreSQLに同じ名前の型がある場合でも、精度、タイムゾーンの仕様、表示形式の違いがあるため、使用方法によっては検討が必要です。 | |
| バイナリデータ型 | 2 | Oracle Databaseと同じ型はPostgreSQLにないため、データ型の変更が必要です。 | |
| XML | 2 | PostgreSQLもXML型を使用できますが、Oracle Databaseのすべての機能をサポートしていないため、使用方法によっては検討が必要です。 | |
| JSON | 2 | PostgreSQLもJSON型を使用できますが、Oracle Databaseのすべての機能をサポートしていないため、使用方法によっては検討が必要です。 | |
| グローバリゼーションのサポート（多言語対応） | 1 | ||
性能に関する移行観点
| 項目 | 移行難易度 | 補足 |
|---|---|---|
| メモリーチューニング | 2 | PostgreSQLに最適な設定に変更する必要があります。 |
| SQL文チューニング | 2 | PostgreSQLは拡張モジュールのpg_hint_planを利用することでヒント句を使用できますが、Oracle Databaseと同等でないため、チューニングの際に検討が必要です。 |
| マテリアライズド・ビュー | 2 | PostgreSQLはマテリアライズド・ビューを使用できますが、リフレッシュ方法、反映タイミングが異なります。高速リフレッシュができないため、マテリアライズド・ビューのサイズが大きい場合は検討が必要です。 |
| 検索処理の並列化 | 1 | |
| インメモリカラムナ | 3 | PostgreSQLに機能はありません。 【参考】 Enterprise PostgresではVertical Clustered Index機能が利用できます。 |
可用性に関する移行観点
| 項目 | 移行難易度 | 補足 |
|---|---|---|
| 高可用性 | 2 | Oracle DatabaseのReal Application Clustersなどを使用したデータベースサーバーの冗長化構成に対して、PostgreSQLはアクティブ / スタンバイ構成を導入します。スタンバイは複数台で構成して、参照利用することが可能です。また、別途クラスタソフトウェアやPgpool-IIなどを導入する検討が必要です。 【参考】 Enterprise Postgresではデータベース多重化機能が利用できます。 |
| 災害対策 | 2 | PostgreSQLはストリーミングレプリケーション機能により遠隔地に複製データを送ることが可能です。現行システムでOracle Data GuardやOracle GoldenGateを利用している場合は、機能差を調査し対策を検討する必要があります。 【参考】 Enterprise Postgresでは、運用センターおよび災害対策センターでストリーミングレプリケーションを構成したときにでも更新ログ（WAL）の順序性を保証できるよう独自に強化されています。 |
運用性に関する移行観点
| 項目 | 移行難易度 | 補足 |
|---|---|---|
| 運用管理ツール | 2 | PostgreSQLに対応した様々なツールが利用可能です。 |
| DB構成の変更（カラム、索引の追加） | 0 | |
| 索引領域の再編成 | 1 | PostgreSQLはREINDEX文を利用することで、索引領域の再編成ができます。 |
| 高速ローダー（SQL*Loader） | 3 | PostgreSQLに機能はありません。COPYコマンドを利用すること、および、索引をデータ挿入後に行うことでロード時間のある程度の改善は可能です。 【参考】 Enterprise Postgresは独自の高速ローダーが利用できます。 |
| データレプリケーション | 1 | |
| 異種データベース間連携 | 2 | PostgreSQLはOracle Databaseとデータ連携が可能です。その他のデータベースとの連携については、連携方法からの検討が必要です。 |
| データベース・リンク | 2 | PostgreSQLは別インスタンスとデータ連携できます。 |
| パッチの適用 | 1 | PostgreSQLもクラスタ環境であればローリングアップデートが可能です。 |
セキュリティに関する移行観点
| 項目 | 移行難易度 | 補足 |
|---|---|---|
| 透過的データ暗号化 | 3 | PostgreSQLに機能はありません。代替策として、アプリケーションでの暗号化APIを利用することで格納データの暗号化までは可能です。また、ストレージの暗号化機能の利用も可能ですが、部分的な対応になります。 【参考】 Enterprise PostgresにはOracle Databaseと同等の透過的データ暗号化機能があります。 |
| データ・マスキング | 3 | PostgreSQLに機能はありません。代替策としてアプリケーションなどでの対策が必要です。ただし、データベースからデータを取り出したときにはマスキングされていないため、十分な検討が必要になります。 【参考】 Enterprise PostgresにOracle Databaseと同等の機能があります。 |
| 行レベルのアクセス制御 | 1 | |
| セキュリティ監査 | 2 | 拡張モジュールのpgAuditを利用することで対応が可能です。 【参考】 Enterprise Postgresは監査ログ機能が利用できます。 |
アプリケーション開発に関する移行観点
| 項目 | 移行難易度 | 補足 | |
|---|---|---|---|
| SQL規格への準拠 | 2 | PostgreSQLはSQL:2016の主な機能をサポートしています。 | |
| オプティマイザ | 2 | PostgreSQLはオプティマイザ機能をサポートしていますが、クエリヒントやSQLの実行計画管理の一部機能に互換性がありません。PostgreSQLとしてSQLが最適化されるよう検討が必要です。 | |
| インターフェイス | 埋め込みSQL（C言語） | 1 | |
| ODBC | 1 | ||
| JDBC | 2 | PostgreSQLはJDBC標準機能をサポートしていますが、サポートしているバージョンは確認が必要です。 | |
| .NET Framework | 2 | PostgreSQLは.NET Frameworkをサポートしています。Npgsqlが必要です。 | |
| ツール | 対話型SQL実行ツール | 2 | Oracle DatabaseのSQL*Plusに対して、PostgreSQLはpsqlを使用します。 |
| GUIツール | 2 | Oracle DatabaseのSQL Developerに対して、PostgreSQLはpgAdminを使用します。 | |
| 開発環境ツール | 2 | 使用している開発環境によっては、移行先システムに最適になるよう開発環境の変更が必要になります。 | |
| ストアド・プロシージャ、ストアド・ファンクション | 2 | Oracle DatabaseのPL/SQLに対して、PostgreSQLはPL/pgSQLが利用できますが、仕様差があり書き換えが必要になります。 | |
| アクセス制御 | 排他範囲 | 0 | どちらのデータベースも、表レベルのロックと行レベルのロックをサポートします。 |
| 排他指定 | 0 | どちらのデータベースも、クエリ（コマンド）ごとにロックの指定が可能です。 | |
| デッドロックの自動検出 | 0 | ||
| データアクセスの同時実行性と一貫性 | 0 | どちらのデータベースも、マルチバージョン制御による同時実行が可能です（他のトランザクションによる更新中のデータについて検索が可能です）。 | |
| コネクション管理（冗長構成時） | 基本管理機能 | 1 | |
| 生死監視機能 | 2 | Oracle DatabaseはOracle Real Application ClusersまたはOracle Active Data Guardで監視するのに対して、PostgreSQLはPgpool-IIなどで対応が可能です。 【参考】 Enterprise Postgresはデータベース多重化機能でも対応できます。ただし、監視の構成と動作は異なります。 |
|
| アプリケーションの接続性（サーバーの状態を意識しない接続） | 2 | Oracle DatabaseはOracle Real Application ClusersまたはOracle Active Data Guardで接続するのに対して、PostgreSQLはPgpool-IIなどで対応が可能です。 【参考】 Enterprise Postgresは独自のConnection Manager機能で対応できます。ただし、監視の構成と動作は異なります。 |
|
バックアップ、リカバリーに関する移行観点
| 項目 | 移行難易度 | 補足 |
|---|---|---|
| バックアップの単位 | 2 | PostgreSQLはデータベース、インスタンス、表、またはパーティションごとにデータベースをバックアップします。ただし、Oracle Databaseで利用可能な表領域単位でのバックアップはできません。 |
| バックアップ設定 | 1 | |
| リカバリー | 1 |
Oracle DatabaseからPostgreSQLへの移行を前提とした、双方のデータベースの違いについて述べました。また、移行作業を安全に進めるためにも、「データベース移行で押さえておくべきこと ～移行プロセスについて～」の記事を併せてお読みください。実際に移行作業を行う際の観点としてご利用頂けると幸いです。
参考
Enterprise Postgresは、OSSのPostgreSQLを拡張し、エンタープライズ利用に向けて信頼性、性能、セキュリティを強化したデータベースであり、ワンストップの長期サポートにも対応しています。また、他社データベースからの移行支援サービスとして、アプリケーションの移行アセスメントから資産移行、導入までのトータルなサポートを提供しています。
2022年6月10日公開
こちらもおすすめ
オンデマンド（動画）セミナー
-
- PostgreSQLに関連するセミナー動画を公開中。いつでもセミナーをご覧いただけます。
- 【事例解説】運送業務改革をもたらす次世代の運送業界向けDXプラットフォームの構築
- ハイブリッドクラウドに最適なOSSベースのデータベースご紹介
- PostgreSQLに関連するセミナー動画を公開中。いつでもセミナーをご覧いただけます。
PostgreSQLについてより深く知る
PostgreSQLに興味をお持ちのお客様はこちらのコンテンツもお勧めです。ぜひご覧ください。
本コンテンツに関するお問い合わせ
お電話でのお問い合わせ
-
富士通コンタクトライン（総合窓口）
0120-933-200受付時間：9時～12時および13時～17時30分（土曜日・日曜日・祝日・当社指定の休業日を除く）
