JP2019020793A - データベース移行システム - Google Patents

Abstract

【課題】異なるデータベース構造間の複数のデータベース間でのデータ移行作業において、シームレスに移行が行うことを目的とする。【解決手段】複数のデータベースと接続され、複数のデータベース間のデータ移行を管理するデータ移行管理システムであって、複数のデータベースの組み合わせ毎に、移行元データベースのデータ構造、移行先データベースのデータ構造に応じた移行プランを示す移行情報テーブルを有し、第１のテーブルの第１のデータベースから第２のデータベースへの移行要求を受領したときに、当該移行要求に対応する移行プランを前記移行情報テーブルから選択し、選択した移行プランに基づき、前記第１のテーブルを変換した上で、変換後の前記第１のテーブルを前記第２のデータベースに移行することを特徴とするデータ移行管理システム。【選択図】 図２

Description

本発明は、異なるデータベース間において、データを移行するための移行方式および技術に関する。

BI(ビジネスインテリジェンス)分野において、様々なプラットフォームが提案されてきた。それらのプラットフォームは、機能面や性能など利用者のニーズによって最適なものが選択されるべきであるが、一からの構築には時間やコストがかかることによって、ニーズが満たせない問題があった。PaaS（Platform as a Service）はその問題を解決する提供形態である。PaaSの存在によって、利用者はプラットフォーム開発に時間やコストを割かれることなく、アプリケーション開発やデータマネジメントなどの領域に注力することができる。

本技術分野の従来技術としては、例えば、特開２０１３―４１５２６号広報（特許文献１）がある。特許文献１には、移行元データベースと移行先データベースのデータ構造に基づき、移行元データベースと移行先データベースで共通項目を抽出し共通項目のデータ移行を実行するプログラムと、移行元データベースと移行先データベースで異なる指定項目について変換した上で移行を実行するプログラムと、から移行ツールを生成する移行する技術が記載されている。

特開２０１３―４１５２６号広報

データを取り扱うBI分野においては、プラットフォームを含めたコンテンツの提供スピードが重要になる。これは、データをもとにした経営判断や事業判断がデータ鮮度に依存するためである。また、BIツールの適合性や、処理速度など利用者のニーズに柔軟に対応することも必要である。

特許文献１をはじめ、データベースの移行作業の自動化や移行用ツールを生成するための技術が多数提案されている。それらの技術は、データベースの構造が共通するデータベース間だけでなく、異なる構造においても、データベース移行を可能にしている。しかし、これらの技術の前提として、柔軟に変更される利用者のニーズは組み込まれておらず、そのために高頻度で発生する移行作業を考慮していない。

本発明は、上記の問題を踏まえ、異なるデータベース構造間の複数のデータベース間でのデータ移行作業において、シームレスに移行が行うことを目的とする。より具体的には、本発明は、複数でかつ高頻度に発生する移行作業において、介在する人の削減、手間の軽減を実現する。

本発明おけるデータ移行管理システムは、複数のデータベースと接続され、複数のデータベース間のデータ移行を管理するデータ移行管理システムであって、複数のデータベースの組み合わせ毎に、移行元データベースのデータ構造、移行先データベースのデータ構造に応じた移行プランを示す移行情報テーブルを有し、第１のテーブルの第１のデータベースから第２のデータベースへの移行要求を受領したときに、当該移行要求に対応する移行プランを前記移行情報テーブルから選択し、選択した移行プランに基づき、前記第１のテーブルを変換した上で、変換後の前記第１のテーブルを前記第２のデータベースに移行することを特徴とするデータ移行管理システムである。

本発明によれば、利用者が高頻度でデータベース間の移行を実施したい場合においても、迅速に移行作業が可能であり、かつ移行の手間を軽減することができる。

本発明の一実施形態のシステム構成図である。 本発明の一実施形態のシステム構成図である。 本発明の一実施形態における実行計画テーブルの例である。 本発明の一実施形態におけるスケジュールテーブルの例である。 本発明の一実施形態における移行情報テーブルの例である。 本発明の一実施形態における変換情報テーブルの例である 本発明の一実施形態における全体処理の流れ（１）を示すフローチャートである。 本発明の一実施形態における全体処理の流れ（２）を示すフローチャートである。 本発明の一実施形態における移行案件管理システムの処理を示すフローチャートの例である。 本発明の一実施形態における移行作業実行システムの処理を示すフローチャートの例である。

以下、図面に従い、本発明の実施形態を説明する。

図１は、本発明の実施形態における
本発明の実施形態のシステムは、
ネットワークで互いに接続された、移行案件管理ステム１０、移行作業実行システム２０、ＤＢ（データベース）システム３０の３つのシステムにより構成されている。

図２を用いて、各システムの詳細を説明する
移行案件管理システム１０は、テーブル管理者１からのデータ移行要求を受理し、移行作業実行システムへ実行命令を行うシステムであり、制御部、移行情報入力部１２、メール送受信装置１４、実行結果出力部１６、実行計画テーブル１８を備える。

テーブル管理者１は、自己の端末を介して、移行案件管理システムに、データ移行要求を入力する。たとえば、データベースシステム３０に格納のされているデータのうち、第１のＤＢに格納されている第１のテーブルを第２のＤＢに移行させる要求などを入力する。

データベースシステムに格納されているデータは、テーブル毎に管理者（権限）が設定されており、このデータ移行要求は、各テーブル管理者１が自身の所有するテーブル（つまり権限の付与されているテーブル）について、データ移行要求を出すことができる。
一方、ＤＢ管理者２は、各テーブル管理者の要請により、ＤＢシステムの管理を行う。たとえば、テーブル管理者１から発行されたデータ移行要求の実行について、その進捗を管理する。

制御部１１は、移行案件管理システムを制御するとともに、各装置・別システムに対して命令を行う機能を有する。

移行情報入力部１２は、テーブル管理者からの移行作業依頼を受付け、制御部に伝える機能を有する。メール送受信装置１４は、移行案件管理システムにおいて、実行結果出力部から送られてきた内容を、テーブル管理者およびＤＢ管理者へメール配信する機能を有する。実行結果出力部１６は、移行案件管理システムにおいて、制御部１１から引き渡された内容に応じて、実行結果を生成する部分である。実行計画テーブル１８は、移行案件管理システムにおいて、移行案件の実行計画（申請者や受付状況など）を管理するテーブルである。詳細は後述する。

続いて、移行作業実行システム２０について説明する。移行作業実行システム２０は、移行案件管理システム１０からの命令を受領し、ＤＢシステム３１、３２、３３への参照要求や更新作業を執り行うシステムである。移行作業実行システム２０は、制御部２１、プログラム実行部２８、スケジュールテーブル２２、移行情報テーブル２４、変換情報テーブル２６を備える。

制御部２１は、移行作業実行システム２０を制御するとともに、各装置・別システムに対して命令を行う機能を備える。スケジュールテーブル２２は、移行作業のスケジュールを管理するテーブルである。移行情報テーブル２４は、移行作業実行システムにおいて、移行対象のテーブル情報を管理するテーブルである。変換情報テーブル２６移行作業実行システムにおいて、移行作業時の置換リストを管理するテーブルである。各テーブルの詳細は後術する。プログラム実行部２８ＤＢシステムに対して、プログラムの実行を指示する機能を備える。
次に、データベースシステム３０について説明する。

本発明の実施形態では、データベースシステム３０は、ＤＢシステム（ローグレード）３１、ＤＢシステム３２（ミドルグレード）、などの種別の異なる複数のＤＢシステムを有する。ユーザ（テーブル管理者）は、複数のＤＢシステムから、テーブルを格納（インポート）するＤＢシステム選択することができる。

図３に、実行計画テーブル１８の例を示す。実行計画テーブルは、前述したように移行案件管理システムに格納されており、テーブル管理者から受領したデータ移行要求毎に、移行の実行計画（申請者や受付状況など）を管理するテーブルである。案件番号は、移行要求前に付与される管理番号である。申請者ＩＤ、承認者ＩＤは、当該データ移行要求の申請者と承認者のＩＤである。計画日時は、当該データ移行要求を受領した日時を示す。ステータスは、移行案件管理システム各移行要求に対応するステータスを示す。移行プランは、当該移行要求が移行作業実行システムの移行情報テーブルで管理される複数の移行プランのいずれに対応するかを示す情報である。移行元テーブルは、テーブル管理者から指定のあった移行対象のテーブルの移行元データベースにおけるテーブル名ある。一方移行先テーブルは、移行対象のテーブルの移行先データベースでのテーブル名である。実行計画テーブルはデータ移行の実行状況に応じて、逐次的に更新される。更新日時は各データ移行に対応する情報が最後に更新された日時を示す。

図４は、スケジュールテーブル２２の例を示す。スケジュールテーブル２２は移行作業実行システム２０に格納され、移行作業のスケジュールを管理するテーブルである。スケジュールＩＤは、上述の案件番号毎に付与される管理番号である。案件番号は、スケジュールＩＤに対応する案件番号が示される。開始予定時刻、終了予定時刻は、各データ移行の実行開始、実行終了が予定されている時刻である。一方、開始時刻、終了時刻は、各データ移行が実際に実行開始、実行終了した時刻である。ステータスは、移行作業実行システム２０における各データ移行のステータスを占めす。スケジュールテーブルはデータ移行の実行状況に応じて、逐次的に更新される。更新日時は各データ移行に対応する情報が最後に更新された日時を示す。
図５は、移行情報テーブル２４の例を示す。本実施形態では、各ＤＢシステムは、それぞれ異なる種類のデータ構造で格納されている。データ構造のＤＢシステム間でデータ移行を実行する場合、データ形式を変換する必要がある。移行情報テーブル、移行元ＤＢシステム、移行先ＤＢシステムの組合せ毎に、データ形式を変換に必要な情報を管理するテーブルである。移行プランは移行元ＤＢシステム、移行先ＤＢシステムの組合せ毎に付与された識別情報である。移行元ＤＢは、移行元ＤＢシステムの名称、移行先ＤＢは、移行先ＤＢシステムの名称である。移行先接続情報１、移行先接続情報２、接続情報（ＩＰ Address）、接続情報（PASS）は、データ移行に際して、移行元ＤＢシステム、移行先ＤＢシステムに移行作業実行システム２０がアクセスするために必要な情報を示す。移行元圧縮率は、移行元ＤＢシステムにおけるデータ圧縮率、移行先圧縮率は移行先ＤＢシステムにおけるデータ圧縮率である。移行先格納形式は、移行先データベースの格納形式を示す。

図６は、変換情報テーブル２６の例を示す。データ構造が異なるＤＢシステム間でデータ移行を実行する場合、上述のとおり、移行先データベースにデータを格納する前に、データを変換する必要がある。図６は移行プラン毎に、移行元データベースで格納されていた文字列の種別と、移行先データベースへの格納前に変換すべき文字列の種別の対応を示すものである。

図７、図８を用いて、データ移行手続処理の流れを説明する。

Ｓ１０５において、移行情報管理システムは、テーブル管理者１からログイン受付けると、移行情報の入力画面を表示する。

次に、Ｓ１１０において、移行情報管理システムは、テーブル管理者が入力した移行情報を、実行計画テーブルへ書き込む。案件番号は値が重複しないよう発番し、ステータスには「受付済」となる。更新日時にはその時点の時刻を書き込む。

次に、Ｓ１１５において、移行情報管理システムは、テーブル管理者からの移行情報更新をトリガーに、ＤＢ管理者に移行作業の申請があった旨の通知メールを配信する。その際、本文には実行計画テーブルに更新された値の一部（案件番号、申請者ＩＤ、計画日時、コメント、移行プラン、更新日時）と承認画面へのリンクを掲載する。

次に、Ｓ１２０において、移行情報管理システムは、ＤＢ管理者のログインを受け付け、実行計画テーブルの案件番号に紐付いた案件一覧を表示する。

続いて、Ｓ１２５において、移行情報管理システムは、ＤＢ管理者が選択した案件番号をキーに実行計画テーブルを更新する。承認者ＩＤにはＤＢ管理者のIDが入り、ステータスは「実行待」となる。更新日時にはその時点の時刻を書き込む。

次に、Ｓ１３０において、移行情報管理システムは、ＤＢ管理者からの移行情報更新をトリガーに、移行チェック内部処理を移行作業実行システムに指示する。その際、引数として実行計画テーブルの移行情報を移行作業実行システムに受け渡す。

次に、Ｓ１３２において、移行情報管理システムは、移行作業実行システムから、移行元ＤＢの対象容量および圧縮率を取得する。また、移行先空き容量および圧縮率を取得する。

次に、Ｓ１３５において、移行情報管理システムは、算出された安全想定容量と移行先空き容量を比較し、安全想定容量が移行先空き容量よりも小さければ、移行先ＤＢに十分な空きがあるとみなし、次の条件分岐に遷移する。逆に安全想定容量が移行先空き容量よりも大きければ、移行先ＤＢに十分な空きがないとみなし、案件差し戻し処理に遷移する（Ｓ１３５の詳細は図９を用いて後述する）。

次に、Ｓ１３７において、移行情報管理システムは、算出されたインポート処理想定時間と許容時間を比較し、インポート処理想定時間が許容時間よりも小さければ、通常運用への影響が無いものとし、移行処理を指示のフローに遷移する。逆にインポート処理想定時間が許容時間より大きければ定常運用の影響があると判断し、案件差し戻し処理に遷移する。

次に、Ｓ１４０において、移行情報管理システムは、移行チェック判定の結果から、移行処理を移行作業実施システムに指示する（Ｓ１４０の詳細は図１０を用いて後述する）。

次に、Ｓ１４２において、移行情報管理システムは、移行作業実施システムから、移行処理の結果受け取る。

次に、Ｓ１４５において、移行情報管理システムは、移行処理の結果をもとに、実行計画テーブルへ書き込む。ステータスには「実行完了」もしくは「エラー」となる。更新日時にはその時点の時刻を書き込む。

次に、Ｓ１５０において、移行情報管理システムは、移行チェック判定の結果を、実行計画テーブルのコメントへ書き込む。

次に、Ｓ１５５において、移行情報管理システムは、移行チェック判定の結果をもとに、実行計画テーブルへ書き込む。ステータスには「差し戻し」が入る。更新日時にはその時点の時刻を書き込む。

次に、Ｓ１６０において、移行情報管理システムは、ＤＢ管理者に移行結果の通知メールを配信する。その際、本文には移行結果に紐付いたメッセージと、実行計画テーブルに更新された値の一部（案件番号、申請者ＩＤ、計画日時、コメント、移行プラン、更新日時）と承認画面へのリンクを掲載する。

なお、移行結果に紐付いたメッセージは、たとえば以下のようなものである。(1)案件番号XXXXXが差し戻されました。ＤＢ管理者は内容を確認し、承認作業を実施してください。<ステータス：差し戻し> (2)案件番号XXXXXが正常に完了しました。ＤＢ管理者は内容を確認し、承認作業を実施してください。<ステータス：実行完了> (3)案件番号XXXXXにて予期しないエラーが発生しました。ＤＢ管理者は内容を確認し、承認作業を実施してください。また、必要におうじてＤＢシステムのログを確認してください。<ステータス：エラー>
続いて、Ｓ１６５において、移行情報管理システムは、ＤＢ管理者のログインを受け付け、実行計画テーブルの案件番号に紐付いた案件一覧を表示する。

次に、Ｓ１７０において、移行情報管理システムは、ＤＢ管理者が選択した案件番号をキーに実行計画テーブルを更新する。承認者ＩＤにはＤＢ管理者のIDが入り（IDは上書きされる）、ステータスは「完了」もしくは「完了（異常）」となる。更新日時にはその時点の時刻を書き込む。また、結果に応じてＤＢ管理者はコメントに値を追加する。

次に、Ｓ１７５において、移行情報管理システムは、ＤＢ管理者の移行情報更新をトリガーに、テーブル管理者に移行結果の通知メールを配信する。その際、本文には実行計画テーブルに更新された値の一部（案件番号、ステータス、画日時、コメント、移行プラン、更新日時）と承認画面へのリンクを掲載する。

図９を用いて、図７で説明したＳ130移行手続における移行チェック内部処理を説明する。

Ｓ２１０において、移行案件管理システムから移行チェック内部処理指示を受領した移行作業実行システムは、移行情報テーブルを参照する。次に、Ｓ２２０で、移行作業実行システムは、移行先ＤＢに空き容量を問合せ移行作業実行システムより、ＤＢシステム（移行先）へ空き容量を問い合わせる。

Ｓ２２５において、移行作業実行システムは、ＤＢシステム（移行先）より、問合せ結果を受け取る。Ｓ２３０において、移行作業実行システムは、移行元ＤＢの対象テーブル容量および圧縮率から、データをエクスポート処理した際の単純想定容量を算出する（移行元ＤＢの対象テーブル容量÷（移行元ＤＢ）圧縮率＝単純想定容量）。つぎに、Ｓ２４０で、移行作業実行システムは、単純想定容量に安全係数と移行先ＤＢの圧縮率を掛けた、安全想定容量を算出する。なお、ここでの安全係数はデータ容量を過少見積りすることによって、移行作業実施後にエラーになるリスクを軽減するためにある。また、安全係数は任意にＤＢ管理者が設定できるものとするが、安全係数の持つ意味を考慮し、その値は１以上２未満とする（単純想定容量×安全係数×（移行先ＤＢ）圧縮率＝安全想定容量）。

次に、Ｓ２５０において、移行作業実行システムは、安全想定容量にデータ量あたりの処理時間を掛け、インポート処理想定時間を算出する（安全想定容量×データ量あたりの処理時間＝インポート処理想定時間）。なお、ここでのデータ量あたりの処理時間は任意にＤＢ管理者が設定できるものとする。これは、ＤＢシステムのマシンスペックによって処理時間が異なるためである。また、許容時間も、任意にＤＢ管理者が設定できるものとする。これは、運用設計によって許容時間が異なるためである。移行作業実行システムは、算出した値を、移行チェック内部処理の結果として移行案件管理システムに送る。

図１０を用いて、移行作業実行システムはにおける移行処理を説明する。

この処理は、図８のＳ140において移行処理管理システムが発行した移行処理指示を、移行処理実行システムが受領することを契機に実行される。

Ｓ３１０において、 移行処理実行システムがは、移行元ＤＢより、移行対象テーブルのテーブル定義を取得する。ここではＳＱＬによって記述された、ＣＲＥＡＴＥ文をＤＤＬとして移行作業実施システムにダウンロードする。次に、Ｓ３２０において、移行処理実行システムは、移行元ＤＢより、移行対象テーブルのデータを取得する。ファイル形式は任意でＤＢ管理者が変更できるものする。次に、Ｓ３３０において、移行処理実行システムは、変換情報テーブルをもとに、事前に取得した移行元ＤＢのテーブル定義（ＤＤＬ）の内容を修正する。これは異なるＤＢ構造を持つ場合において、データ型やＤＤＬの表記が異なるためである。なお、変換情報テーブルは事前にＤＢ管理者が作成する。つぎに、Ｓ３４０において、移行処理実行システムは、移行作業実施システムから、ＤＢシステムに対して命令するためのプログラムを生成する。次に、Ｓ３５０において、移行処理実行システムは、移行元ＤＢから取得し移行作業実施システム上に確保したデータを、移行先ＤＢへ転送する。次に、Ｓ３６０で、移行処理実行システムは、スケジュールテーブルに従い、プログラムを実行する。移行処理実行システムは、データ移行の進捗を移行処理結果として、データ移行管理システムに送信する。

Claims (3)

1. 複数のデータベースと接続され、複数のデータベース間のデータ移行を管理するデータ移行管理システムであって、
   複数のデータベースの組み合わせ毎に、移行元データベースのデータ構造、移行先データベースのデータ構造に応じた移行プランを示す移行情報テーブルを有し、
   第１のテーブルの第１のデータベースから第２のデータベースへの移行要求を受領したときに、
   当該移行要求に対応する移行プランを前記移行情報テーブルから選択し、選択した移行プランに基づき、前記第１のテーブルを変換した上で、変換後の前記第１のテーブルを前記第２のデータベースに移行することを特徴とする
   データ移行管理システム。
2. 請求項１に記載のデータ移行管理ステムであって、
   前記移行情報テーブルは、前記移行プラン毎に、移行元データベースの文字列の種類と、当該文字列を移行先データベースに格納する際に変化すべき文字列の種類との対応関係を管理し、当該対応関係に基づき、前記第１のテーブルの変換を行うことを特徴とする
   データ移行管理システム。
3. 請求項１に記載のデータ移行管理ステムであって、
   前記移行情報テーブルは、移行元データベースの圧縮率と、移行先データベースの圧縮率を管理し、
   前記第１のテーブルの前記第１のデータベースから前記第２のデータベースへの移行要求を受領したときに、
   前記移行情報テーブルに示される前記第１のデータベースの圧縮率と前記第２のデータベースの圧縮率に基づき、当該移行要求が実行可能かを判断する
   データ移行管理システム。

Images