ゼロから始めるPostgreSQL移行！Insight SQL Testingでつまずかずに完遂した話

これまで3年間、Oracle Databaseエンジニアとして構築支援やサポートに携わってきました。3年目を迎えた今、アシストの育成カリキュラムの一環で、4か月間インサイトテクノロジー社製品を担当することになりました。

元々の育成のカリキュラムとしては、セキュリティ製品であるInsight PISOのみを学ぶ予定でしたが、興味本位で先輩に同社のInsight SQL Testingとはどのような製品か聞いてみたところ「実際にOracle DatabaseからPostgreSQLへとデータベース移行にチャレンジしてみればどうか」という課題が出されました。

そこで本記事では、PostgreSQLにはほとんど触れたことのないOracle Databaseエンジニア3年目の目線から、SQLの非互換チェックが行えるツール「Insight SQL Testing」を活用し、Oracle DatabaseからPostgreSQLへのデータベース移行に挑戦した内容を、実体験を交えてご紹介します！

データベースを移行する際には次のような流れで進めます。

1. 移行先のデータベースを事前に作成する
2. データを移行する
3. システムを切り替える

また、移行作業では思わぬ課題やつまづくポイントが発生することがあるため、注意点について事前に確認しておくことが重要です。

システムを新しいサーバーへ移行する際には、事前に移行先となるデータベースを構築し、データを移行させなければなりません。その際に注意すべき点のひとつは、表のデータ型です。

同じデータベース間の移行やバージョンアップであれば、同じデータ型が利用できる場合がほとんどです。しかし異種データベース間の移行となると、そもそも同じデータ型が存在しなかったり、サイズなどの仕様が異なる場合があります。

Oracle DatabaseからPostgreSQLへの移行を前提に考えてみましょう。

1つ目は可変長の文字列型です。Oracle DatabaseにはVARCHAR2型という可変長のデータ型があります。しかし、PostgreSQLにVARCHAR2型は存在しません。そのため、代わりに可変長型のVARCHAR型やTEXT型を使用することになります。

2つ目は日付データ型です。Oracle DatabaseのDATE型では「年月日時分秒」の形式で格納されますが、PostgreSQLでは「年月日」までです。そのため、時刻情報まで含めて移行するには、PostgreSQLではTIMESTAMP型に置き換える必要があります。

このように各データベース製品によってデータ型に違いがあるため、一つひとつ確認し、適切なデータ型に置き換えていく必要があります。

データベースのバージョンアップや異種データベース製品への移行では、データ型の変換だけでは不十分です。なぜなら、現行システムで利用されているSQL文が、新しい環境でも正しく動作するかの確認と修正が必要不可欠だからです。

特に、Oracle DatabaseからPostgreSQLといった異なるデータベース製品間の移行では、移行先で実行できない構文もあるため、SQLの修正難易度が高くなります。

では、どんな観点でSQLをチェックする必要があるか確認してみましょう。

まず着目するのは、各データベース製品独自の記述により、移行先でSQLが実行できないケースです。

例えば、Oracle Databaseでは、クエリでNULL値を0に置き換えたい場合にNVL関数が使用できます。しかし、このNVL関数はOracle Database独自の関数であるため、PostgreSQLで使用するにはCOALESCE関数に置き換える必要があります。

この他にも、PL/SQLはOracle Databaseで独自に拡張された手続き言語であるため、PostgreSQLで利用できるPL/pgSQLで動かすにはプログラムを書き換える必要があります。

このように、データベース製品独自のSQL構文や関数や手続き言語の違いが存在するため、移行先ではSQLが実行できないことがあります。

次に着目すべきは、移行先で実行できるものの、仕様の違いによって結果が変わってしまうSQLです。データベース製品ごとに、同じSQL文や同じ関数を使用していても、出力される結果が変わる場合があります。

例えば、現在の時間を求めるCURRENT_DATE関数はOracle DatabaseにもPostgreSQLにも存在しますが、Oracle Databaseでは「年月日時分秒」の形式で出力されるのに対し、PostgreSQLでは「年月日」のみが表示されます。

このように、SQLは正常に実行できるものの、移行元とは異なる結果が出力される場合があるため、対象となるSQLを結果も含めて比較する必要があります。

最後に、SQLも実行でき、結果も変わらないものの、移行先のデータベースではSQLの実行時間が延びる場合があることを考慮しなければなりません。

例えばSQL文に関数や結合を多用していると、実行計画や内部動作の違いのため、実行時間が数倍遅くなるといったケースがあります。特定のSQL実行でCPUを占有し続けたり、DISKアクセスが発生し続けると、結果的にシステム全体のレスポンスが悪くなることにつながります。そのため、パフォーマンス観点でもSQLの見直しや個別のチューニングが必要になります。

このように複数の課題を挙げましたが、本番環境で実際に発行されるSQLの件数は、システムや時期にもよりますが1ヵ月で数千万件から数億件と言われています。この膨大な数のSQL文を収集し、一つひとつ互換性やエラーの有無を確認する作業は想像するだけでも途方に暮れてしまいます。

また、SQLを修正する際には移行前後のデータベース製品の仕様やSQLの記述方法を知っておく必要があり、SQLを個別に調査するにはさらに多くの時間が必要です。

そしてこのSQL修正作業を漏れなく、効率的に行いたい場合の解決策となり得るのが、これまで概要レベルでしか把握していなかった「Insight SQL Testing」です。このツールを活用することで、上記の課題を効率的に対応することができます。

Insight SQL Testingは、実際に発行されている大量のSQL文を収集し、データベース移行やバージョンアップの際に移行先の環境でも正しくSQLが動作するかを一括でテストできるSQLテストソフトウェアです。
異種データベース間の移行でも利用できるため、作業負担の低減や修正工数の削減が期待できます。そんなInsight SQL Testingの機能と特徴を紹介します。

Insight SQL Testingではダイレクトメモリアクセス（DMA）方式を採用しているため、サーバーのメモリから直接SQL文を取得でき、現行システムへの影響を抑えつつデータを収集できるのが特徴です。

移行元のデータベースサーバーに専用の収集モジュールを導入することで、本番環境で実際に発行されたSQL文を低負荷に収集できます。収集したSQLはInsight SQL Testingの蓄積サーバーに格納され、後続のテストや分析に活用されます。

Insight SQL Testingでは、移行元で収集したSQLを移行先のデータベースに対して一括実行することが可能です。GUI画面で操作するため、専門知識がなくても簡単にテストすることができます。

SQLの実行結果を成功／失敗でレポート表示するため、どのSQLを修正すべきか非常に明確になり、工数削減につながります。実行に失敗したSQLはInsight SQL Testing上で修正し、再テストすることができます。さらに、2DBモードを使えば双方のデータベース間でSQLの実行時間や結果を比較でき、性能劣化しているSQLも簡単に見つけることができます。

加えて、移行先がAWS環境上のデータベースであることが前提ですが、AWS Schema Conversion Tool (AWS SCT)といったスキーマ変換ツールを組み合わせることで、失敗したSQLの自動修正もできるため、スムーズにSQL修正・検証作業を行うことができます。

では、異種データベース間の移行を実践してみます。今回使用した環境のバージョン情報は以下の通りです。

事前にOracle Databaseに格納されている表をPostgreSQLへ移行する必要がありますが、今回はOracle DatabaseからPostgreSQLへのマイグレーションツールである「ora2pg」を使用して、オブジェクトおよびデータの移行を行いました。

Insight SQL Testingは収集したSQLを蓄積するためのサーバーと、SQLを収集するためのモジュールの2つが必要です。そのため、仮想環境やAWS環境上に蓄積サーバーとしてInsight SQL Testingをインストールします。

次に移行元のOracle Database側のサーバーには、アプリケーションが発行するSQLを収集するためのモジュールをインストールします。

その後、サーバーと移行元モジュールが通信可能になると、SQLの蓄積が可能となります。

画像1：Insight SQL Testingを使用のイメージ

収集されたSQLが移行先で実行できるかをチェックするには、Insight SQL TestingのGUI画面でアセスメントを実行します。この際、様々な設定が可能です。例えば、実行計画のみでSQLの実行可否だけ確認したり、もしDML文が含まれる場合はCOMMITするかROLLBACKをするかを選択できます。また、実行時間が遅くなったり、SQLの結果が異なる場合にはその結果を保存することも可能です。

実行ボタンを押すと処理が始まります。しばらく待つと、作成したアセスメントが閲覧可能となり、実行できなかったSQLも分かりやすく表示されます。

画像2：Oracle Database で実行されていたSQLをPostgreSQLで再実行した結果

レポート結果の緑は移行先でも実行可能なSQL、赤は移行先で実行不可のSQL、黄色は実行可能だが性能劣化したSQLを表します。

このように視覚的に修正すべきSQLが確認できるため、修正対象に優先度をつけやすく、非常に分かりやすい仕様です。

Insight SQL Testingの「2DBモード」は、2つの異なるデータベースを選択し、同じSQLをそれぞれでテスト・比較できる機能です。例えば移行元のOracle Database環境と移行先のPostgreSQLの両方でSQLを実行することで、結果や実行速度を比較することができます。

画像3：Insight SQL Testingの2DBモードのイメージ

この機能を活用することで、出力結果が一致しないSQLや、性能が劣化しているSQLを容易にチェックすることができます。システム移行の際に、正しい動作やパフォーマンスであるかを確認できるため、トラブルの未然防止や品質担保に大きく役立ちます。

画像4：Insight SQL Testingの2DBモードを試した結果

Insight SQL Testingではバージョン4.0から追加された生成AIを利用したSQL修正提案機能が利用できます。
適切なSQLの修正案が提案されることで、SQLを修正する技術者の作業負担を下げるだけでなく、私のように移行先のPostgreSQLに慣れていない技術者でも容易にSQLを変換し、短時間でマイグレーションを成功させることが期待できます。

実際に作業を行う中で、個人的に非常に役に立った機能をピックアップしてみます。

SQLの収集、修正、再実行はすべてInsight SQL TestingのGUI画面で操作することができるため、直感的に操作でき、非常に簡単でした。加えて、実行結果がレポートとして出力され、移行先で実行できなかったSQLや性能劣化してしまったSQLが一目で分かります。これにより、修正箇所や優先度を判断しやすく、作業をスムーズに進めることができました。

SQLを修正後、Insight SQL Testingで再実行できる点が非常に便利でした。

一度修正しても課題が残る可能性があるため、Insight SQL Testingを通じて何度もSQLのチェックと修正を繰り返せる点が便利でした。また、SQL修正後にアセスメントを再実行することで、最新の修正結果に基づくレポートを作成し直すことができます。

このように、修正後のSQLが移行先システムでも問題なく動作するかを事前にかつ容易に検証できる点が有用でした。

Insight SQL TestingではSQL収集時にプログラム名も取得します。これにより、SQLの発行元がわかるので、修正したSQLをどのアプリケーションに反映させる必要があるかが把握でき、非常に分かりやすい仕様でした。

Insight SQL Testingを使ってもなお、SQLの修正作業自体には若干苦労がありました。この点については上述のAmazon BedrockやAWS SCTの機能が有効であると、先輩に伺いました。

今回の検証では生成AIやAWS SCTを利用しませんでしたが、それらを活用することでInsight SQL Testingの画面上でシームレスにSQLの修正を行うことができます。

詳細はインサイトテクノロジー社の以下の記事をご参照ください。

https://www.insight-tec.com/news/press/202404_5061/

また、システムで発行されるSQLの件数が非常に多く、負担になりました。しかし、Insight SQL Testingでは収集したSQLをハッシュ値やSQL IDで自動的に分類し、重複を除外することが容易に実施できました。目視で同一SQLかどうかをチェックすることは数が多ければ多いほど負担が大きく、この分類機能がなければ非常に苦しんだはずです。

結果として頻繁に実行されている同一SQLが多くあることが確認できたため、大幅な工数の削減につながりました。

Oracle DatabaseによるSQLの知識があったため、手作業での修正もある程度は可能だと考えていました。しかし、そもそも本番環境で発行される大量のSQL文を収集すること自体が非常に困難だと感じました。その点、Insight SQL Testingにより事前にSQLを漏れなく収集できたのは、作業の効率化につながりました。

さらに、移行先の環境で実行できないSQLの抽出や、AIによる修正案の提案機能などにより、修正作業にかかる工数も大きく削減できます。移行後のデータベースでSQLが失敗する問題は移行の中止、またレスポンスが遅くなる問題は運用開始後のシステムトラブルの要因になりかねません。そのため、移行前にこれらのリスクを予めチェックできるのは非常に大きな安心材料となります。

今後Oracle DatabaseからPostgreSQLなど、異なるデータベースへの移行を検討される方には、事前準備の一環としてInsight SQL Testingの活用をぜひおすすめします。スムーズかつ確実なデータベース移行の実現に大きく貢献するツールですので、これからデータベース移行をご検討中の方は、ぜひお気軽に弊社までお問い合わせください。