移行の際のポイント

当初は「テキスト出力→OracleでSQL*Loaderのダイレクトモードを使用」という一般的な移行方法を念頭においていたこともあり、同一サーバでの移行も不可能ではないと考えていました。それがデータ量とその格納形式から、「一時的とはいえテキスト出力を介すことは現実的ではない」という結論に達し、さらに「移行速度が目標に達しない」という困難な課題を生んでしまいました。

その結果を受け入れられた理由は、下記のような点でした。

ポイント：アプリケーションがすべて自社内で構築されたものであり、その変更や複数バージョンを準備して柔軟に切替えることができた。

最終的にはこれが決め手となり、「並行稼働しつつ、データを順次移行する」という柔軟な手段を選択することが可能になりました。アプリケーションが自社開発ものであり、その動作や運用を柔軟に変更可能であったことは、データの移行作業において大きなポイントであったことは間違いありません。

これらのポイントを含め、事前に技術的に解消すべき点がいくつかありました。そこで次回では、その問題点や移行に関する技術的なポイントについて説明します。

アプリケーションとデータベース移行の関係

本題の中で技術支援を行う立場から最終的に移行方法を決断する際に一番大きなポイントであった点として「アプリケーションが柔軟に修正可能であったこと」をあげています。データ移行とアプリケーションはどういった関わりを持つかと考えてみますと、下記にあげるポイントで密接に関係すると考えられます。

データ型の決定
移行方法
運用

最初に仕様を決定し、それに基づいてアプリケーションが作成されるのが一般的ですが、その仕様がデータベースを変更する際に変わる可能性がでてくるわけです。その際にエンドユーザ(またはデータ移行の担当）、アプリ作成、運用管理が別々の担当(または業者）が行っていたとすると、こういったやり取りが起こるかもしれません。

移行担当A：「移行するにあたり、表"TAB"の列"COL1"はtext型からchar(5)に変更します」
アプリケーション担当B：「ちょっと待ってください。char(5)では後ろのスペースを削らないといけないので修正にはさらに2人日必要です（当然費用もね……）」

移行担当C：「移行中に列"COL2"のインデックスが無くなります。移行終了後に作成します」
アプリケーション担当D：「それでは検索処理が遅くて使い物になりません」
移行担当C：「では、ダミーの値を入れて移行前の行を擬似的に作成しましょう」
アプリケーション担当E：「それだと登録処理を変更する必要が…（当然費用もね……）」

   このような具合に結論がでるまでの調整がいろいろと大変です。

   それも運用を中断し、すべてのデータ移行が期間内に完全に終了できればよいのですが平行稼働だとその期間は専用の別アプリケーションも準備する必要があるなど、費用面でも大きな負担となってくるでしょう。また運用側も一時的な対応を迫られるため、オペレーションミスなどの危険が増すことも考えられます。

   ホスティングしている場合にはサーバ入替えの手続きも必要でしょう。これらがオーバーヘッドとなるかどうかは移行作業の意志決定の速度において大きな違いとなることでしょう。

   データベースの移行はデータの入替えだけでは済みません。何かと大変なのです。