(57)【要約】【課題】サービス停止時間なくデータベース移行を行う。【解決手段】ＡＰサーバ１１の参照先を、移行元ＤＢ１３及び移行先ＤＢ１４の両方にアクセス可能であり、データの移行を記録する移行表２６を有する仮想ＤＢ装置１５に変更した後、仮想ＤＢ装置１５が、ＡＰサーバ１１からのリクエストに対して、移行表２６を参照して、当該リクエストの主キーに紐付けられたデータが移行済みであるか否かを判断し、移行されていない主キーへのリクエストであれば、移行元ＤＢ１４へ当該リクエストを送って処理すると共に、当該主キーに紐付くデータを上記移行先ＤＢ１４へ追加し、かつ、上記移行表に当該主キーについて移行済みである旨を記録し、移行されている主キーへのリクエストであれば、上記移行先ＤＢ１４を有するサーバへ当該リクエストを送って処理する。【選択図】図１
2014219868.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションサーバが参照するデータベースを、移行元データベースを有する旧サーバから移行先データベースを有する新サーバに切り替えるデータベースの移行方法であり、
上記アプリケーションサーバの参照先を、上記移行元データベース及び上記移行先データベースの両方にアクセス可能であり、データの移行記録を記録する移行表を有する仮想データベース装置に変更するステップ、
上記仮想データベース装置が、上記アプリケーションサーバからのリクエストに対して、上記移行表を参照して、当該リクエストの主キーに紐付けられたデータが移行済みであるか否かを判断し、
移行されていない主キーへのリクエストであれば、上記移行元データベースへ当該リクエストを送って処理すると共に、当該主キーに紐付くデータを上記移行先データベースへ追加し、かつ、上記移行表に当該主キーについて移行済みである旨を記録し、
移行されている主キーへのリクエストであれば、上記移行先データベースを有するサーバへ当該リクエストを送って処理する、
ことで、リクエストへの応答を繰り返して移行と履歴の記録を行うステップ、
上記アプリケーションサーバの参照先を、上記移行先データベースを有する新サーバに変更するステップ
を行う、データベースの移行方法。
【請求項２】
上記の移行と履歴の記録を行うステップの後に、
未移行項目のデータを抽出し、一括して上記移行元データベースから上記移行先データベースへ移行させるステップ、
を行う、請求項１に記載のデータベースの移行方法。
【請求項３】
アプリケーションサーバからの要求に対して、仮想的なデータベースサーバとして動作する第一入出力部と、
上記要求を処理するデータベースのデータについて、移行元データベースから移行先データベースの移行の有無を記録する移行表と、
上記移行表において未移行であるデータについて、上記移行元データベースに対して上記要求を送信する仮想的なアプリケーションサーバとして動作するとともに、その要求に対する応答にあたるデータを上記移行先データベースに記録する第二入出力部とを有する
仮想データベース装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データベース（ＤＢ）の移行方法に関する。
【背景技術】
【０００２】
システムを長期間に亘って使用しようとしても、いずれサーバ機器の販売やサポートが終了してしまい、サーバ機器を新たなハードウェアに替えなければならなくなる。このため、データベースはいずれかの段階で移行させなければならなくなる。
【０００３】
また、近年はオープンソースソフトウェア（Open Source Software：OSS）のデータベースが充実してきており、コストの削減などを目的としてデータベースを移行する機会が増えている。
【０００４】
しかし、データベースを利用するサービスが実行されている間は、常にデータの検索や更新が行われるため、最終的に接続先を切り替える際には一旦サービスを停止してからデータを移行する必要がある。データベースの規模が大きくなるほど、このデータ移行にかかる時間は膨大になり、サービスを停止する時間が長くなってしまう。
【０００５】
これに対して、特許文献１のような方法が提案されている。サービスの運用中に移行前のデータベース装置のスナップショットデータを取得して、これを移行先のデータベース装置に書き込みながら、移行前のデータベース装置を運用し続ける。一旦移行先データベース装置に、前の時点でのスナップショットデータを書き込み終わった後に、さらに運用が進行した後の移行前のデータベース装置のスナップショットデータを取得し、前の時点のデータのままである、移行先のデータベース装置のスナップショットデータも取得して、この差分データを取得する。移行段階では、この差分データのみを移行先のデータベース装置に書き込むだけで済む。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−２３２８６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１の装置でも、最後に差分データを書き込む時間はサービスを停止しなければならない。この時間は全データを一括して書き込む従来の方式よりは短縮できるものの、データベースの更新頻度が高いほど、その停止時間が無視できないものとなった。
【０００８】
そこでこの発明は、サービス停止時間をなくしてデータベースの移行を行えるようにすることを目的とする。
【課題を解決するための手段】
【０００９】
この発明は、
アプリケーションサーバが参照するデータベース（ＤＢ）を、移行元データベースを有するサーバから移行先データベースを有するサーバに切り替えるデータベースの移行方法であり、
上記アプリケーションサーバの参照先を、上記移行元データベース及び上記移行先データベースの両方にアクセス可能な仮想データベース装置に変更するステップ、
上記仮想データベース装置が、上記アプリケーションサーバからのリクエストに対して、上記移行元データベースのデータの移行履歴を記録する移行表を参照して、当該リクエストの主キーが移行されているか否かを判断し、
移行されていない主キーへのリクエストであれば、上記移行元データベースを有するサーバへ当該リクエストを送って処理すると共に、当該主キーに紐付くレコードを上記移行先データベースへ追加し、かつ、上記移行表に当該主キーについての移行履歴を記録し、
移行されている主キーへのリクエストであれば、上記移行先データベースを有するサーバへ当該リクエストを送って処理することで、リクエストへの応答を繰り返して移行と履歴の記録を行うステップ、
上記アプリケーションサーバの参照先を、上記仮想データベース装置から上記移行先データベースに変更するステップ
を行う、データベースの移行方法により、上記の課題を解決したのである。
【００１０】
上記仮想データベース装置が、リクエストを処理するごとに順次上記移行先データベースへのデータの移行を進めるため、大半のデータはアプリケーションサーバのサービスを中断させることなく運用しながら移行させることができる。
【００１１】
所定の期間に亘ってリクエストを処理しながら移行させるが、リクエストの無い主キーに紐付けられたデータだけは移行されない。その残された分は上記移行表を参照すれば判明する。そこで、所定の期間が経過しても未移行項目のデータが残っている場合には、アプリケーションサーバの参照先を上記仮想データベース装置から上記移行先データベースのサーバに変更する前に、その残された未移行項目のデータのみを上記移行元データベースから上記移行先データベースへ移行させるステップを行う。未移行項目のデータの移行は、アプリケーションサーバからのリクエストと同様に、仮想DBが逐次移行元データベースへアクセスして移行するため、サービスは停止しない。
【発明の効果】
【００１２】
この発明により、データがアクセスされるたびにデータを移行することで、システムにかかる負荷を抑えてデータ移行を実現することができる。また、頻繁にアクセスされないデータであっても、仮想DBがアクセスを行うことで、全データをサービス断なく移行することができる。
【図面の簡単な説明】
【００１３】
【図１】（ａ）この発明を実施する際の移行過程における論理構成例図、（ｂ）この発明を実施する際の移行過程における物理構成例図
【図２】この発明で導入する仮想データベース装置の機能ブロック図
【図３】この発明にかかる移行方法の全体像を示すチャート
【図４】移行過程におけるフローチャート例
【図５】（ａ）移行過程における移行を伴う処理例の手順図、（ｂ）移行過程に置ける移行済みの項目への処理例の手順図
【図６】移行表の例を示すテーブル群
【図７】ＳＱＬの命令文の違いによる処理チャート
【図８】最終移行処理のフローチャート
【発明を実施するための形態】
【００１４】
以下、この発明について詳細に説明する。この発明は、アプリケーションサーバが参照するデータベースを、移行元データベースを有するサーバ（旧サーバ）から移行先データベースを有するサーバ（新サーバ）へ移行する移行方法である。
【００１５】
この発明を実施するにあたっては、上記アプリケーションサーバが参照するデータベースを、アドレスの変更により速やかに変えられる環境にあることが望ましい。アプリケーションサーバ自身が宛先であるデータベースのアドレスを変更することで実現してもよいし、ネットワーク内に存在するロードバランサが指定するアドレスを書き換えることで実現してもよい。また、データベースを有するサーバが多重化されている場合は、ロードバランサが指定するアドレスを書き換えることで、多重化されているうちの一つのサーバにのみ接続させるようにすることで、移行処理を進めやすくすると好ましい。
【００１６】
この発明を実施するシステムの論理構成の例を図１（ａ）に、物理構成の例を図１（ｂ）に示す。アプリケーションサーバ１１（図中「ＡＰ」と略記するときがある。）は、外部からのリクエストに応じて、下記のデータベースに対して命令文を実行するサーバである。このアプリケーションサーバ１１は、ロードバランサ１２（図中「ＬＢ」と略記するときがある。）の制御により多重化していてもよい。なお、図では２つのサーバ（１１ａ、１１ｂ）で多重化しているが、数は特に限定されるものではなく、より多数のサーバで多重化されていてもよい。
【００１７】
この発明で用いるデータベースは、アプリケーションサーバ１１とは別のアドレスを有するサーバに格納されている。移行元データベース１３（図中「移行元ＤＢ」と略記するときがある。）を有する旧サーバから移行先データベース１４を有する新サーバ（図中「移行先ＤＢ」と略記するときがある。）へデータを移行させる際に、アプリケーションサーバ１１のサービスを停止する時間を出来る限り短縮することが本発明の目的である。移行作業開始前の段階では、移行先データベース１４を有する新サーバが取り付けられておらず、移行作業完了後は移行元データベース１３を有する旧サーバが取り外される。ここで、旧サーバ及び新サーバを、それぞれが有する移行元データベース１３及び移行先データベース１４として抜き出して記載する。
【００１８】
この発明におけるデータ移行の際には、これらの移行元データベース１３を有する旧サーバ及び移行先データベース１４を有する新サーバは、仮想データベース装置１５を介してアプリケーションサーバ１１からのアクセスを受け取る。仮想データベース装置１５は、移行元データベース１３や移行先データベース１４が有するデータベースとしてのデータそのもののコピーは有さないが、移行元データベース１３が有するデータのうち、どの項目のデータが移行済みであるかを記録し、参照可能な移行表をテーブルデータとして保持しており、この移行表を参照して、移行元データベース１３と移行先データベース１４に対してリクエストを行うサーバである。この移行表は移行済みであるか否かだけでなく、どの時点で移行されたかを示す移行日時も記録してあると、後述する最終処理の判断が容易であるため望ましい。また、移行後のデータがさらに更新されている場合にその更新日時も記録してあると、移行作業にエラーが生じたときにデータを戻す際に参照できるためより望ましい。
【００１９】
なお、上記のような論理構成であるネットワークの実際の物理構成としては、図１（ｂ）に示すように、ルータやＬ３スイッチなどからなり外部ネットワークに繋がるルーティング装置１７に、上記のアプリケーションサーバ１１ａ，１１ｂ、ロードバランサ１２，移行元データベース１３を有する旧サーバ、移行先データベース１４を有する新サーバ、仮想データベース装置１５が接続される。
【００２０】
仮想データベース装置１５の機能ブロック図を図２に示す。ソフトウェア上のインターフェースである入出力部は、アプリケーションサーバ１１に応答する仮想データベースとしての第一入出力部２２と、移行元データベース１３及び移行先データベース１４に対する仮想的なアプリケーションサーバである第二入出力部２３との二つを有する。なお、図では機能的に記載しているため別個になっているが、実際の物理インターフェースは一つでもよい。また、上記の移行表２６を含む記憶部２４を有している。少なくとも上記移行表２６は、磁気ディスクや不揮発メモリなど、電源断があっても消失しない記憶手段によって記憶されていることが望ましい。さらに、これらの入出力部２２，２３と記憶部２４とを制御するＣＰＵにあたる制御部２５を有する。第一入出力部２２からのリクエストを受けた制御部２５は、記憶部２４にアクセスして移行表２６をチェックした上で、第二入出力部２３に対して、移行元データベース１３、移行先データベース１４、又はその両方に対して適切なリクエストをするように伝達し、その応答を第一入出力部２２へと返し、必要に応じて移行表２６への書き込みを行う。なお、移行表２６は仮想データベース装置１５とは別のサーバに格納されていてもよい。
【００２１】
ただし、移行元データベース１３と移行先データベース１４のデータベースソフトの種類やバージョンが異なっていたりすることにより、データベースの形式が異なる場合には、移行元データベース１３のデータをそのままで移行先データベース１４に移行することはできない。このため、移行元データベース１３と移行先データベース１４とのデータベースの形式が異なる場合には、この移行元データベース１３のデータ形式から移行先データベース１４のデータ形式に変換するソフトウェアである変換部２８を設け、移行するデータを移行元データベース１３の形式から一旦変換部２８で変換した上で、移行先データベース１４に書き込む。
【００２２】
移行の手順の概要を図３に示す（Ｓ１００〜）。作業開始前では移行先データベース１４を有する新サーバと仮想データベース装置１５が接続されておらず、作業にあたってこれらをネットワークに接続する（Ｓ１０１）。具体的には、ルーティング装置１７の端子や、それに繋がるハブなどに物理的にケーブルを用いて接続する。単純に、端子へ接続すればよいだけであるため、この接続作業の際に必要なアプリケーションサーバ１１のサービス切断時間は０になる。
【００２３】
その上で、アプリケーションサーバ１１がリクエストを送るデータベースの宛先アドレスを、移行元データベース１３を有する旧サーバから、仮想データベース装置１５に変更する（Ｓ１０２）。この変更は、アプリケーションサーバ１１自身が参照するアドレスを書き換えることで実現してもよい。また、ネットワークにロードバランサ１２が存在する場合には、ロードバランサ１２がデータベースの宛先としてアプリケーションサーバ１１からのリクエストを受け付けている共有アドレスの振り分け先であるアドレスを書き換えることでも実現できる。アプリケーションサーバ１１のサービス切断時間をなくすため、ロードバランサ１２が振り分けるアドレスを変更する方がより好ましい。
【００２４】
アプリケーションサーバ１１の参照先が仮想データベース装置１５に変更されると、以後は、アプリケーションサーバ１１がリクエストを送るたびに、仮想データベース装置１５が応答するとともに順次移行作業を進行させる（Ｓ１０３）。また、一定期間経過後、必要に応じて最終移行処理を行う（Ｓ１０４）。これらについて詳しくは後述する。
【００２５】
移行元データベース１３から移行先データベース１４へのデータ移行が完了したら、アプリケーションサーバ１１がリクエストを送るデータベースの宛先アドレスを、仮想データベース装置１５から、移行先データベース１４を有する新サーバに変更する（Ｓ１０５）。この変更も、アプリケーションサーバ１１自身が参照するアドレスを書き換えることで実現してもよい。また、ネットワークにロードバランサ１２が存在する場合には、ロードバランサ１２がデータベースの宛先としてアプリケーションサーバ１１からのリクエストを受け付けている共有アドレスの振り分け先であるアドレスを書き換えることでも実現できる。開始時と同様に、アプリケーションサーバ１１のサービス切断時間をなくすため、ロードバランサ１２が振り分けるアドレスを変更する方がより好ましい。
【００２６】
上記アプリケーションサーバ１１の宛先が変更されたら、仮想データベース装置１５と移行元データベース１３を有する旧サーバを、ネットワークから切り離してよい（Ｓ１０６）。これもルーティング装置１７の端子や、それに繋がるハブなどから物理的にケーブルを抜いて切断する。単純に、端子から切断すればよいだけであるため、この切断作業の際に必要なアプリケーションサーバ１１のサービス切断時間は０になる。以上で移行作業は完了する（Ｓ１０７）。
【００２７】
上記の工程のうち、アプリケーションサーバ１１の宛先が仮想データベース装置１５に変更されてから始まる、Ｓ１０３における仮想データベース装置１５の実際の移行処理について、図４のフローと図５（ａ）（ｂ）の概略図を用いて説明する。
【００２８】
アプリケーションサーバ１１からリクエストを受けた仮想データベース装置１５は（Ｓ２０１）、移行元データベース１３から移行先データベース１４へのデータ移行の履歴を記録した移行表２６を、リクエストの主キーで検索する（Ｓ２０２）。この移行表２６の例を図６（ａ）（ｂ）に示す。移行表２６は、少なくとも、移行作業開始時点における移行元データベース１３で用いられている主キーごとに、当該主キーのデータの移行が既にされているか否かを判別可能なフラグを有していることが必要である。このフラグは、移行日時を兼ねていてもよい。その場合、移行がされていなければ、移行日時の項目はｎｕｌｌとなる。また、移行作業開始時点における移行元データベース１３を構成するテーブルと同数のテーブルを有していることが好ましい。なお、移行表２６では、移行元データベース１３に含まれている複数のテーブルをより少ない数のテーブルに統合してもよいが、その場合でも主キーにより移行元データベース１３のどのデータに対応するかが判別可能である必要がある。
【００２９】
移行表２６における当該主キーの項目に、移行日時が記録されていたり、あるいは専用の移行フラグが「済み」になっていれば（Ｓ２０３→ＹＥＳ）、当該主キーに紐付けられたデータは移行済みであると判断して移行は行わない（Ｓ２２１〜）。一方、移行日時が記録されていなかったり、専用の移行フラグが未移行のままであったりしたら（Ｓ２０３→ＮＯ）、当該主キーに紐付けられたデータは未移行であると判断して（Ｓ２１１〜）、移行の処理を行う。Ｓ２１１以降のフローの概略図が図５（ａ）であり、Ｓ２２１以降のフローの概略図が図５（ｂ）である。
【００３０】
上記の移行を行うＳ２１１以下の処理について説明する。すなわち、当該主キーに紐付けられた項目のデータが未移行である場合である。仮想データベース装置１５の第二入出力部２３は、移行元データベース１３に対して仮想的なアプリケーションサーバとしてのリクエストを送信する（Ｓ２１１）。第二入出力部２３が移行元データベース１３から応答を受け取ったら（Ｓ２１２）、第一入出力部２２はアプリケーションサーバ１１に対して仮想的なデータベースとしての応答を行う（Ｓ２１３）。その応答と前後して、又はそれと並行して、第二入出力部２３は移行先データベース１４に対して、その応答に対応する内容を当該主キーの項目として対応するテーブルに追加し（Ｓ２１４）、そのテーブルに対応する移行表２６の当該主キー項目に移行フラグを立てたり、移行日時を書き込んだりして、当該主キー項目のデータの移行が完了したことを記録する（Ｓ２１５）。以後、移行前の項目についてリクエストが有るたびに同様の処理を繰り返して、移行が進む。
【００３１】
一方、上記のＳ２２１以下の処理について説明する。すなわち、当該主キーに紐付けられた項目のデータが移行済である場合である。仮想データベース装置１５の第二入出力部２３は、移行先データベース１４に対して仮想アプリケーションサーバとしてのリクエストを送信する（Ｓ２２１）。第二入出力部２３が移行先データベース１４から応答を受け取ったら（Ｓ２２２）、第一入出力部２２はアプリケーションサーバ１１に対して仮想データベースとしての応答を行う（Ｓ２２３）。すなわち、移行元データベース１３に対しては特にリクエストを送信しない。なお図示しないが、Ｓ２２３と前後して、移行表２６の当該主キーの項目に設けた更新日時を更新してもよい。これにより、移行先データベース１４の更新日時管理が併せて可能となる。
【００３２】
より具体的には、上記のリクエストに応じた移行処理（Ｓ１０３）は、ＳＱＬの命令文によって異なる。そのフロー例を図７に示す。
【００３３】
ＳＱＬの命令文がＩＮＳＥＲＴで追加処理である場合は、そもそも移行元データベース１３に該当する項目が無いので、移行表２６を確認するまでもなく、移行先データベース１４に値を追加する。その上で、移行表２６に当該値を追加して、アプリケーションサーバ１１に応答する。
【００３４】
ＳＱＬの命令文がＤＥＬＥＴＥで削除処理である場合には、主キーで移行表２６を検索して、移行フラグが立っているなど既に移行されていると判別できれば、移行先データベース１４の値を削除するとともに、移行表２６の当該主キーの値も削除して、アプリケーションサーバ１１に応答する。当該主キーについて移行表２６に移行フラグが立っていないなど、未だに移行されていないと判別されれば、移行元データベース１３の値を削除した上で、アプリケーションサーバ１１に応答する。
【００３５】
ＳＱＬの命令文がSELECTで検索処理である場合には、主キーで移行表２６を検索して、移行フラグが立っているなど既に移行されていると判別できれば、移行先データベース１４の値を検索して、結果をアプリケーションサーバ１１に応答する。当該主キーについて移行表２６に移行フラグが立っていないなど未だに移行されていないと判別されれば、移行元データベース１３の値を検索して、結果をアプリケーションサーバ１１に応答する。さらにその上で、移行先データベース１４のテーブルに値を追加して、移行表２６のテーブルの当該主キーの項目を移行済みとする。
【００３６】
ＳＱＬの命令文がＵＰＤＡＴＥで更新処理である場合には、主キーで移行表２６を検索して、移行フラグが立っているなど既に移行されていると判別できれば、移行先データベース１４の当該主キーのデータを更新して、結果をアプリケーションサーバ１１に応答する。当該主キーについて移行表２６に移行フラグが立っていないなど未だに移行されていないと判別されれば、移行元データベース１３の当該主キーのデータを更新した上で、移行先データベース１４に当該主キーのデータを追加して、移行表２６のテーブルの当該主キーの項目を移行済みとして、アプリケーションサーバ１１に応答する。ここで、移行元データベース１３のデータは更新しなくても利用可能であるが、移行途中でエラーが起きるなどの問題が起きたときに、移行元データベース１３に戻せるように、移行元データベース１３も更新しておくと望ましい。
【００３７】
以上のような手順を一定期間に亘って続けることで、その間に一度でもリクエストがあった項目については、上記図７のような手順により、移行元データベース１３に記録されているデータが移行先データベース１４へ移行される。また、新規な項目は移行先データベース１４に書き込まれる。これにより、大半のデータが移行でき、場合によっては予め定めた期間を待たずして全てのデータについてリクエストがあって全面移行が完了する場合もある。しかし、一部にリクエストされる頻度が少ないデータが含まれて、完全にはデータが移行しきらないこともある。そこで、最後のデータ移行から所定の期間が経過しても、未移行データの移行が進まなくなり、移行作業が事実上収束してしまった時点で、仮想データベース装置１５はアプリケーションサーバ１１からのリクエストを処理しながら、次の最終移行処理を行うとよい。この最終移行処理のフローを、図８を用いて説明する。
【００３８】
まず（Ｓ１０４，Ｓ３００）、移行表２６の移行日時を確認する。この移行日時のうち最も新しいものが、所定の期間よりも前であるか否かを判断する。所定の期間とは、例えば１週間や１ヶ月、半年など、データベースの規模や頻度により適宜選択する。この最新移行日時が所定の期間より近ければ、データベースの移行はまだ進行しており、収束前であると判断して（Ｓ３０１→ＮＯ）、最終移行処理は行わずにそのままとする（Ｓ３０９）。一方、最新移行日時が所定の期間よりも前であれば（Ｓ３０１→ＹＥＳ）、移行表２６のうち、移行フラグが立っていない、或いは移行日時が登録されていないなど、未移行である項目を抽出する（Ｓ３０２）。この作業の代わりに移行元データベース１３と移行先データベース１４とのデータ比較を行うことでも未移行項目を抽出することができるが、サーバにかかる負荷と時間が膨大になるおそれが高いため、移行表２６の検索抽出によって簡便に未移行項目を抽出すると好ましい。抽出の結果、未移行項目が無い，すなわち移行元データベース１３の全データが移行済みであれば（Ｓ３０３→ＮＯ）、最終移行処理を行う必要なく、後述の切替処理へと移る（Ｓ３０８、Ｓ１０５，Ｓ１０６）。
【００３９】
未移行項目が残っているならば（Ｓ３０３→ＹＥＳ）、抽出された未移行項目について（Ｓ３０４〜Ｓ３０７）、その時点における移行元データベース１３の当該項目のデータを、移行先データベース１４に記載し（Ｓ３０５）、移行表２６に移行フラグや移行日時を登録する（Ｓ３０６）という工程を順次実行していく。これにより、全未移行項目の移行を完了させる。それらの工程が完了した後、上記の通り（Ｓ１０５）、アプリケーションサーバ１１又はロードバランサ１２の設定を変更して、アプリケーションサーバ１１の参照先アドレスを、仮想データベース装置１５から、移行先データベース１４を有する新サーバに切り替える（Ｓ３０８）。切替が終わったら、仮想データベース装置１５及び移行元データベース１３を有する旧サーバはネットワークから切り離してよい（Ｓ１０６）。以上で移行作業は完了する（Ｓ１０７）。
【符号の説明】
【００４０】
１１，１１ａ，１１ｂ  アプリケーションサーバ
１２  ロードバランサ
１３  移行元データベース
１４  移行先データベース
１５  仮想データベース装置
１７  ルーティング装置
２２  第一入出力部
２３  第二入出力部
２４  記憶部
２５  制御部
２６  移行表
２８  変換部
【図１】
2014219868.tif 000003
【図２】
2014219868.tif 000004
【図３】
2014219868.tif 000005
【図４】
2014219868.tif 000006
【図５】
2014219868.tif 000007
【図６】
2014219868.tif 000008
【図７】
2014219868.tif 000009
【図８】
2014219868.tif 000010