スタッフの日記

ＩＴ資産にかけるコストを少なくするようになってきている為でしょうか。
OracleからオープンソースのPostgreSQLに変えたいというニーズは昔からあるものの、最近は以前に比べ急増してきているように感じます。
Oracleのソフトウェア費用が高いことに加え、仮想化環境におけるライセンスの考え方により、必要以上に費用が掛かってしまうことが理由とされています。
ところがPostgreSQLに変えたくとも、変えられない場合が多く見受けられます。
PostgreSQLへの移行に関する問題点をいくつか列挙しますので、PostgreSQLへの移行を検討する際の一助となればと思います。

(1) SQL
アプリケーションにて自前のSQL文を使用している場合、Oracle固有のSQL文があった場合、SQL文の修正または新規のSQL文の作成が必要になります。
SQL文の修正または新規のSQL文の作成が多いほど、PostgreSQLへの移行は困難になります。
アプリケーションにおけるすべてのSQL文が対象となるため、対象の把握が困難な場合があります。プログラムで動的にSQLを生成している場合は特に注意が必要です。

(2) ストアドプロシージャ
OracleとPostgreSQLでは、構文、エラーハンドリング、トランザクションの管理などが大きく違うため、大規模な修正や新規ストアドプロシージャの作成が必要になることが度々発生します。
アプリケーションがストアドプロシージャに多く依存している場合は、PostgreSQLへの移行へのハードルが極めて高くなります。
なお、ストアドプロシージャの修正の難易度や修正に要する工数は、ora2pgというプログラムにてある程度は確認できます。

(3) データベース構成
大規模データベースでは、性能や耐障害性を考慮して、Oracle RAC構成を採用しているケースが多いかと思います。
PostgreSQLに移行する場合、どんなクラスタ構成を採用しても、更新処理ができるノードが１つしか存在しない点に留意するがあります。（Oracle RACではどのノードでも更新処理が可能）
また、更新結果が更新ログの転送により他のノードに伝播されるため、タイムラグが発生することにより、別のトランザクションで更新結果が反映されていないデータを読み取ってしまうリスクもあります。
更新処理が多い場合はネックとなるかもしれません。

(4) データベース運用
データベース監視や運用については、Oracleの考え方がほぼ援用できませんし、データディクショナリも全く違うので、運用設計からやり直しとなります。
自前のスクリプトで情報採取を行い監視していた場合ですと、すべて新規作成となります。

(5) コスト
今後のOracleソフトウェア費用よりも、PostgreSQLのソフトウェア費用にPostgreSQLへの移行費用を加えた金額が小さくなることを見込んで、PostgreSQLへの移行を検討するものと思います。
(PostgreSQLへの移行費用は、コンサルティング費用、データ移行とアプリケーションの改修の合計とします)
多くの場合、アプリケーションの改修費用がかさみ、PostgreSQLへの移行費用が大きくなりがちです。
ソフトウェア費用を節約するため、サポート契約なしで素のPostgreSQLを利用することを考えるかもしれませんが、バグデータベースへのアクセスやPostgreSQLのノウハウの提供がサポート契約により得られることを考えると、ある程度の規模以上の企業ではサポート契約なしにPostgreSQLを使用することは必須ではないでしょうか。
そのため、ソフトウェアの利用期間などを考慮すると、Oracleのままでも問題ない、多額のコストをかけてPostgreSQLに移行する利点はないと判断するケースもあります。

以上