データベースの移行コストと工数に影響する作業
データベース移行で事前に検討すべき項目は、データベースに格納されているオブジェクト定義やストアドプログラム、データはもちろんですが、図1にあるように可用性を確保するためのシステム構成、バックアップや監視といったシステム運用に加えて、周辺システムとのデータ連携やアプリケーションから実行されるSQLなど多岐に渡ります。これらのうち「異なるデータベース間の移行でコストと工数に大きく影響するものは？」と聞かれて真っ先に思い浮かぶ作業は、ストアドプログラムやSQLの改修ではないでしょうか。
弊社も参画するPostgreSQL エンタープライズ・コンソーシアム（以下、PGECons）が公開する「Oracle DatabaseからPostgreSQLへの移行」の技術情報（※1）から、まずはSQLの改修にかかる工数を見ていきましょう。PGEConsで実施した移行テストではOracle Databaseのストアドプログラムを利用していないアプリケーションを対象としており、アプリケーションの置き換え作業は「接続方式の修正」「SQLの改修」「テスト」の3つのステップで行われています。図2は各ステップで要した時間の割合を表しており、テスト工程が全体の91%を占め、SQLの改修に要した時間はわずか6％にとどまる結果となりました。
（※1）詳細は、PGEConsドキュメント「アプリケーション移行実践編」をご参照ください。
また、同種のデータベースにおけるバージョンアップ作業もデータベース移行に該当します。これはバージョンアップによって構文の解釈などの仕様変更が生じるため、同種のデータベースとはいえSQLの改修が必要になるからです。Oracle Database 9iから11gR2へのバージョンアップ時にSQLの改修工数が全体の3.5%を占めたケースがあり、異なるデータベース間の移行においても全体のわずか数パーセントの割合に留まっていることを考えると、移行への影響は一般的に考えられているほど大きくはないと言えます。
一方、ストアドプログラムの改修は移行のコストと工数に大きく影響する作業と言えます。実際に移行プロジェクトを進める中で、事前に把握していなかった非互換によって改修が必要なものが後から判明し、移行作業が難航したり、移行そのものを断念せざるを得ないケースがあります。異なるデータベース間の移行でこのような事態を回避するには、既存のシステムで利用するストアドプログラムのうち改修が必要なものがどの程度あるのか、またそれぞれの改修ボリュームや対処策から改修難易度を評価し、移行プロジェクトを進められるかどうかを判断する必要があります。ストアドプログラムの詳細を把握するには、スクリプトを使って手作業でデータベースから情報を収集して精査することもできますが、EDB Postgresでは同梱のデータベース移行ツール「EDB Migration Toolkit」（以下、MTK）を活用することで、ストアドプログラムの移行性を簡単に確認することができます。
