Oracle DatabaseからEDB Postgresへの移行！そのプロセスと勘所（後編）
2019.11.21
- クラウド・マルチクラウド
- 内製化支援
中編に引き続き、後編では、移行に至るまでのプロセスのうち、拡張ツールの検討とデータ移行についてご紹介します。
３．拡張ツールの検討（全文検索機能）
本システムでは、全文検索としてOracle Textを利用していましたが、EDB Postgresはダブルバイト対応の全文検索機能を備えていなかったため、拡張パッケージの利用を検討しました。
選定は、PostgreSQL用の全文検索拡張パッケージとして有名であった「PGroonga」と「pg_bigm」に絞って行いました。
実際に保管するレコード数を再現した環境下にて、以下観点での検証結果を参考に評価しました。
- 検索速度
- Index作成速度
- ヒット数の違い
- パッケージの更新頻度
以上の内容で検証・評価した結果、「PGroonga」を選定しました。
理由は、Indexの作成速度が速かった点、ヒット数がOracle Textにより近かった点、パッケージの更新が継続的に行われていたことです。
４．データ移行
今回、ストアドプログラムの改修や、セマンティクス定義の違いによるテーブル定義の見直しなどを行ったため、MTKを利用せず手動にてデータ移行をしました。
データ移行方法のイメージですが、新環境側は既に構築・テストが完了している状態で、移行対象は業務データのみとし、Oracle Databaseに格納されたデータをExportしたものを、EDB*Loaderを利用してEDB Postgresに取り込みました。
移行は、以下の流れで実施しました。
- 移行データ抽出
・（旧環境の）業務データをExportする。（バイナリ形式・CSV形式）
・移行元テーブル群のレコード数をカウントする。 - 移行データ取込
・（新環境の）インデックスを削除、各テーブルのレコードを削除する。
・（新環境に）業務データファイルをImportする。（バイナリ形式、CSV形式）
・シーケンスを更新する。 - 事後検証
・移行先テーブル群のレコード数をカウントする。（抽出時と件数を突き合わせ）
・インデックスを作成し、全テーブルをアナライズする。
以上が、Oracle DatabaseからEDB Postgresへの移行プロセスにて行ったことです。
OracleからEDB Postgresに移行して感じたこと
今回、EDB Postgresに移行して感じたことが４点ありました。
1. 事前検証・動作検証は必須
MTK実行時にはエラーとして検出されなかったが、正常に動作しないトリガーが存在しました。また製品による挙動の違いがあるため、当然ながら動作確認が必須であると再認識しました。
2. 互換性がない機能への注意
暗黙的型変換など、Oracle Databaseが備えている便利な機能は互換性が保たれない傾向が見受けられたため、EDB Postgresに移行する際は注意が必要だと感じました。
3. Oracle Database開発資材の活用
Oracle Databaseと多くの互換性をもつことから、移行前の開発資材や知見を活用することができ、効率的な開発ができると感じました。
4. 製品の安定性
移行から１年以上が経過しても、障害もなく安定稼働を続けており、性能面においても問題は出ていないことから、製品の安定性が高いと感じました。
まとめ
今回は、Oracle Database からEDB Postgresへの移行事例をご紹介しました。
EDB Postgresは、Oracle Databaseと多くの互換性を持っているため、Oracle Databaseでの開発経験があれば、容易に対応が可能でした。また、利用料も安価であることから、利用者・開発者双方にメリットがあると考えました。
また、本案件のように現在物理環境で稼働しているシステムをクラウドに移行したいという声は多く挙がっているため、今後もEDB Postgresを選択肢のひとつとして浸透させていきたいと思います。
このように弊社は、既存のサービスだけに囚われずに新たなサービスを模索し続け、高品質なトータルITソリューション・サービスをご提供いたします。
本稿は、2019年7月23日開催「アシストフォーラム2019」での講演内容をTECH REPORT用に編集したものです。
- 記載されている会社名、製品名は、各社の登録商標または商標です。
