JP4483342B2 - システム復旧方法 - Google Patents

Description

本発明は、データベースを格納するストレージ装置ならびにそのストレージ装置を管理する計算機システムに関し、特にデータベースにおいて使用されるテーブルに対する操作の復旧方法に関する。

大規模な情報処理システムにおいては、情報処理システムで使用されるデータを効率よく管理するためにデータベースが使用される。一般的にデータベースは複数のテーブルを有し、情報処理システムでは、これらのテーブルをプログラム（以下「データ変換バッチ」ともいう）を実行することで目的のデータを有するテーブルに変換し（以下「テーブル変換」とも言う）、変換後のテーブルを使用する。

この際、情報処理システムでは、データ変換バッチを実行する計算機が、あるテーブルを構成するデータをデータが格納されているストレージ装置から取得する。そして、計算機がテーブル変換を実行し、変換後のテーブルをストレージ装置に書き込む。このとき、変換されたテーブルは、そのテーブルの用途ごとに、ストレージ装置の特定の記憶領域（以下「ボリューム」とも称する）に格納される。

上述のテーブル変換時にデータ変換バッチを実行する計算機の処理が異常終了すると、計算機が変換処理を行っているテーブルのデータが不整合となり、この不整合が情報処理システム全体のデータの不整合に繋がる。この場合、情報処理システムにおいては、不整合が生じたテーブルのデータをテーブル変換の実行前のデータに復元し、テーブル変換の再実行を行う必要がある。

上述のデータ復元処理を行うため、従来のシステム管理者は、テーブルを管理するため、計算機で実行されるプログラム（以下「データベースマネジメントシステム（ＤＢＭＳ）」とも称する）を計算機で実行して、変換されるテーブルを作成する際の実行履歴（以下「ログ」）をあらかじめ取得する。そして障害発生時には、計算機がそのログを利用してテーブルの復旧を行っていた（例えば、非特許文献１参照。）。

その他の方法としては、システム管理者は、変換する前のテーブルを格納するボリュームの複製（以下「バックアップ」）をストレージ装置において事前に作成しておき、障害発生時にはそのボリュームのバックアップを用いて変換前のテーブルを復元することで、迅速にテーブルの初期状態への復旧を行っていた。

「データベース処理」、Ｄ・Ｍ・クロエンケ著、１９９６年、ｐ．５２４

従来の方法においては、次のような問題点が残されている。
ログのみを用いる復旧方法では、テーブル変換を実行中に計算機でログを取得するために計算機にログを取得するための負荷がかかり、テーブル変換処理の速度が向上しない。また、テーブル復旧時には、計算機がログのデータに基づいてテーブルのデータを最初から逐次復旧するため、復旧に時間を要し、迅速な復旧の点で問題があった。

また、バックアップを用いる復旧方法では、バックアップを取得するタイミングがテーブル変換の実行前であるので、システムの管理者がテーブルのデータの状態をできるだけ最近の状態、すなわち計算機の異常処理による終了の直前までに実行された処理が反映された状態に復旧することが難しいという問題があった。

本発明の目的は、システムの障害発生時に、システムの高速な復旧、かつ、システムをできるだけ最近の状態に復旧する方法を提供することにある。

本発明の一実施形態として、以下の構成を考える。すなわち計算機とストレージ装置を有する計算機システムである。本計算機システムにおいて、計算機は、データ変換バッチ実行プログラムが実行するデータ変換バッチの実行前にバックアップを、ならびに、各バッチが終了するたびに、関わるテーブルを格納するボリュームのスナップショットを作成するよう、ストレージ装置に指示する。

この際、計算機では、バックアップ又はスナップショットを取得した時点を回復ポイントとして記録する。このような構成においてバッチ実行中に障害が発生した場合、計算機システムでは、指定された回復ポイントに記載のバックアップまたはスナップショットからボリューム全体を書き戻す。さらに、計算機システムは、バッチ群の実行前に作成したバックアップボリュームからメタデータを取得し、取得したメタデータから障害が発生したバッチに関わる部分、ならびに、そのとき実行中であったバッチに関わる部分のテーブルを特定し、該部分を書きかえる。または、計算機システムは、回復ポイントに記載されたバッチの状態情報ならびにログを用いて、障害が発生したバッチに関わる部分、ならびに、そのとき実行中であったバッチに関わる部分のデータを特定し、整合性検証を行ない、該部分をログを用いて書きかえる。

このとき、メタデータは、テーブルがデータベースシステム上でどこに格納されているかを表現するデータであり、テーブルのデータ本体を含んでもよい。

本発明により、高速かつより最近の状態へのシステムの復旧を行なうことができる。

以下、本発明の実施の形態を詳細に説明する。ただし、本発明が以下の実施形態に限定されることは無く、本発明には以下に示す実施形態と均等な構成も含まれる。

図１は、本実施形態におけるプログラム構成及びデータ構成の例を示す図である。本図

では例として、ある会社の社員データが格納される社員マスタテーブルをテーブル変換して作成される、部門ごとのサマリテーブル及び社歴ごとのサマリテーブルがストレージ装置の同一のボリュームに格納される場合について説明する。

尚、以下に説明する各構成要素はプログラムであり、これらは計算機やストレージ装置の演算装置で実行される。ただし、以下の構成要素の一部が専用のハードウェアによって実現されていても良い。

図１において、管理コンソール１００はシステム管理プログラム１１０の操作を行なう。システム管理プログラム１１０は、バッチ管理部１１４、ストレージ管理部１１６及びこれらのプログラムを管理するためのシステム復旧管理部１１２を有する。システム復旧管理部１１２は回復ポイント１８２に関する処理を行う。回復ポイント１８２については後述する。

データ変換バッチ実行プログラム１４０は、データ変換バッチ＆実行スケジュール１８０（以下「データ変換バッチ１８０」）を読み出し、データアクセス部１４２を用いて、ストレージ装置１６０上のボリューム１７０に格納されているテーブルのデータを処理する。また、データアクセス部１４２は、システム復旧管理部１１２からの指示に基づいて、ボリューム１７０に格納されているメタデータ１７９及びバックアップボリューム１７２に格納されたデータを編集する。

ストレージ装置１６０のバックアップリストア処理部１６２は、ボリューム１７０のバックアップであるバックアップ１７２を作成し、かつ、バックアップ１７２からボリューム１７０を復元（以下「リストア」）する。ボリューム１７０には、社員マスタ１７６、部別サマリ１７７、社歴サマリ１７８及びこれらのテーブルに関するメタデータ１７９が格納される。なお、各テーブル１７６、１７７及び１７８は１つに限定されず、１以上の任意の個数のサブテーブルから構成されるテーブルでも良い。又、データ変換の元となるテーブル１７６は、データ変換されたテーブル１７７及び１７８と同じボリュームに格納されていても居なくても良い。また、ボリュームの数は１以上の任意の個数をとることができる。

図２は、本実施形態の計算機システムの構成例を示す図である。
計算機システムは、サーバ計算機２００、クライアント計算機２１０及びストレージ装置１６０を有する。

サーバ計算機２００とクライアント計算機２１０は、ＬＡＮハブ（又はスイッチ）２３０及びケーブルを介して相互に接続されている。ＬＡＮハブ（又はスイッチ）２３０とネットワークをまとめてＬＡＮと呼ぶこともある。尚、サーバ計算機２００とクライアント計算機２１０とを接続するネットワークはＬＡＮで無くても良い。

サーバ計算機２００とストレージ装置１６０は、ＳＡＮハブ（又はスイッチ）２４０及びネットワークを介して相互に接続される。ＳＡＮハブ（又はスイッチ）２４０及びネットワークをＳＡＮ(Storage Area Network)と言うこともある。尚、サーバ計算機２００とストレージ装置１６０とを接続するネットワークはＳＡＮで無くても良い。

サーバ計算機２００は、図１で示したシステム管理プログラム１１０及びデータ変換バッチ実行プログラム１００を実行する計算機である。サーバ計算機２００は、ＣＰＵ２０１、主記憶２０２、ＣＤ−ＲＯＭ装置２０３、ＳＡＮ Ｉ／Ｆ２０４、ＬＡＮ Ｉ／Ｆ２０５及びディスク装置２０６を有する。そして、これらの装置がコントローラによって相互に接続されている。

図１で示したシステム管理プログラム１１０およびデータ変換バッチ実行プログラム１００などのプログラム、また、データ変換バッチ１８０、回復ポイント１８２などのデータは、ディスク装置２０６に格納されている。ＣＰＵ２０１は、これらのプログラムを主記憶２０２にロードして実行する。

なお、これらのプログラムとデータは、ストレージ装置１６０のディスク装置２２４（ａ）、２２４（ｂ）、２２４（ｃ）、２２４（ｄ）、２２４（ｅ）に格納することにしてもよい。または、これらのプログラムとデータを、クライアント計算機２１０のディスク装置２１６に格納することにしてもよい。

クライアント計算機２１０は、ユーザやシステム管理者が操作し、サーバ計算機２００に指示を与えるための計算機である。クライアント計算機２１０は、ＣＰＵ２１１、主記憶２１２、ＣＤ−ＲＯＭ装置２１３、ＬＡＮ Ｉ／Ｆ２１４、ディスク装置２１６及び装置間相互を接続するコントローラを有する。

クライアント計算機２１０のディスク装置２１６には、管理コンソール（プログラム）１００が格納されている。ユーザやシステム管理者は、管理コンソール１００を実行することにより、サーバ計算機２００でのシステム管理プログラム１１０及びデータ変換バッチプログラム１４０の実行を指示する。

ストレージ装置１６０は、ＳＡＮ Ｉ／Ｆ２２１、ストレージ制御プロセッサ２２２、メモリ２２３、ディスク装置２２４（ａ）、２２４（ｂ）、２２４（ｃ）、２２４（ｄ）、２２４（ｅ）及びこれらを相互に接続するコントローラとを有する。ディスク装置２２４は、ボリューム１７０、１７２を格納する。ボリュームとディスク装置はｎ対ｎで対応している。具体的に言えば、ボリュームは、ディスク装置２２４が有する物理的な記憶領域の一部又は全部に対応する。したがって、１つのボリュームは、１つ又は複数のディスク装置２２４が有する記憶領域から構成される。

バックアップリストア処理部１６２は、メモリ２２３に格納され、ストレージ制御プロセッサ２２２により、サーバ計算機２００の指示を受けて実行されるプログラムである。

なお、本実施形態は、サーバ計算機２００とクライアント計算機２１０を有する構成としたが、これを一台の計算機で行うようにしてもよい。また、サーバ計算機２００とクライアント計算機２１０は、それぞれ複数から構成されていてもよい。また、本実施形態では、ストレージ装置２２０は一台であったが、これが複数接続されていてもよい。

まず、本実施形態における計算機システムの処理の流れの概略を説明する。尚、以下の説明でプログラムが主語になる場合は、実際はそのプログラムを実行する装置が処理を実行する。尚、以下の例では、データ変換バッチは、複数のバッチ（部別サマリ、社歴サマリ等）を並行して実行するプログラムであるとする。

まずシステム管理者はテーブル変換の処理（以下「テーブル変換のバッチ」又は単に「バッチ」とも言う）の実行を、クライアント計算機２１０を介してサーバ計算機２００に指示する。指示を受けたシステム復旧管理部は、バッチ実行前のボリュームのバックアップを作成する。その後、データ変換バッチ実行プログラム１４０は、部別サマリを作成するバッチ、社歴サマリを作成するバッチ、その他バッチを起動し、並列に実行する。

ここで、バックアップとは、ボリュームに格納されたデータを全て別のボリュームに複製する処理を指す。一方、スナップショットとは、ボリュームに格納されたデータを他のボリュームに複製せずに、上位装置に対して仮想的にボリュームに格納されているデータを他のボリュームに即座に複製したように見せる処理を指す。

ここで、あるボリュームのデータを仮想的に他のボリュームに複製したように見せる処理には、幾つか種類がある。例えば、あらかじめ複数のボリュームに同じデータを保存しておき、スナップショット処理時に瞬時に複数のボリュームのうちの一つをあるボリュームの複製として他の装置に提供する方法である。又、ボリュームにアクセスするための変換テーブルを複数用意し、一方をスナップショット用とする。そして、スナップショットの処理後にボリュームに対するデータの更新があった場合には、更新前のデータを別の記憶領域に保存しておき、その保存されたデータにアクセスできるように、スナップショット用の変換テーブルの内容を変更する方法もある。

更に、スナップショット用の変換テーブルはそのままにし、通常使用する変換テーブルの内容を変更（すなわち、データの更新があった場合には、更新後のデータを別の領域に格納し、変換テーブルの内容をその更新後のデータへアクセスできるように変更）する方法もある。

その後、例えば部別サマリを作成するバッチが正常に終了すると、システム復旧管理部は、ボリュームのスナップショットを作成する。この場合、他のバッチは実行が継続されても、一時中断されても良い。ボリュームのスナップショット作成開始後または作成完了後に、データ変換バッチ実行プログラム１４０は、一時中断された社歴サマリを作成するバッチ、その他バッチの並列実行を継続する。

その後、例えば社歴サマリを作成するバッチが異常終了し、その他バッチは実行される事態が発生したとする。この場合、システム復旧管理部は処理中の全バッチを停止し、部別サマリ作成後のスナップショットに格納されたデータ及び実行前のバックアップされたデータから、部別サマリが正常に作成されかつ社歴サマリおよびその他テーブルを作成するバッチが実行される前の状態のボリュームを復元する。

復元後、システム管理者はサーバ計算機２００にバッチの再実行を指示する。指示を受けたシステム復旧管理部は、実行前のボリュームのバックアップを同様に作成し、社歴サマリを作成するバッチ及びその他バッチ（停止されたバッチ）を起動し、再実行する。

図５は、メタデータ１７９の内容例を示す図である。メタデータ１７９は、ボリューム１７０内に格納されるデータを管理するための情報である。メタデータ１７９は、ヘッダ部分５０１、部別サマリ１７７に関するページ５０２及びページ５０３並びに社歴サマリテーブル１７８に関するページ５０４及びページ５０５の部分を有する。他のテーブルについての情報も有するが、ここでは説明を省略する。メタデータ１７９は、ＤＢＭＳがテーブルを管理するに必要な情報を含む。尚、メタデータ１７９にはテーブルを構成するデータ本体を含んでもよい。

ヘッダ部分５０１には、ページ５０２、５０３、５０４、５０５に関して、これらのページのディスク装置上での物理的または論理的位置などに関する管理情報が含まれている。尚、メタデータ１７９（ａ）は、部別サマリ１７７及び社歴サマリ１７８の作成前に作成されたボリューム１７０のバックアップがボリューム１７２（ａ）に格納される場合のメタデータ１７９の例である。このメタデータ１７９（ａ）は、ボリューム１７２（ａ）に格納される。

メタデータ１７９（ｂ）は、部別サマリ１７７作成完了時点かつ社歴サマリ１７８が作成中の状態で作成されたボリューム１７０のスナップショットがボリューム１７２（ｂ）に格納される場合のメタデータ１７９の例である。このメタデータ１７９（ｂ）は、ボリューム１７２（ｂ）に格納される。メタデータ１７９（ｂ）は、メタデータ１７９（ａ）と異なり、作成中のテーブルに関する部分のデータの更新が行われ、５０１の社歴サマリならびに部別サマリに関する部分、ならびに、ページ１〜ページ４の５０２〜５０５の部分が書き換わっている（５２１〜５２５）。

メタデータ１７９（ｃ）は、社歴サマリ１７８作成中に障害が発生し、その障害からシステムを復旧した復旧後の状態のボリューム１７０に格納されたメタデータ１７９の例である。

図６は、クライアント計算機２１０が有する表示画面に表示されるユーザインターフェイスの例を示す図である。管理コンソール１００は、その表示画面に回復ポイント１８２の情報を表示する。回復ポイント１８２とは、計算機システムにおいてデータの復旧が出来る時点を示す情報である。システム管理者は、回復ポイントとして示された時点の状態まで計算機システムのデータを回復することが出来る。

回復ポイント１８２には、データを復旧できる複数の時点を指定するために必要な情報がリストやテーブルと言った形式で保存されている。この回復ポイント１８２は、サーバ計算機２００（又はクライアント計算機２１０）が有する記憶媒体に格納される。以下、回復ポイント１８２がテーブル形式でデータを格納している場合について説明する。

回復ポイント１８２は、データベースに作成されるテーブルの数に対応するレコードを有する。各レコードは、フィールドとして順序番号６１０、処理テーブル名６２０、ステータス６３０及び関連するバックアップ６４０を有する。順序番号６１０には、各テーブルの作成順を示す情報が登録される。ここで、複数のテーブルが並行して作成されている場合には、任意の順番で番号が割り当てられ、処理が終了した順番に番号が改めて割り振られる。尚、テーブル変換処理が行われる前のボリュームのバックアップについては、本例では番号「０」が割り振られる。

処理テーブル名６２０には、データ変換の処理対象となるテーブルを示す情報、本例ではテーブル名（部別サマリ等）が登録される。ステータス６３０には、そのテーブルの変換処理が終了しているかどうか、あるいは障害が発生して変換処理が中断しているかどうか等の情報が格納される。

バックアップ６４０には、各テーブルの変換処理の開始前に作成されるバックアップまたは各テーブルの変換処理が終了した際に作成されるスナップショットが保存されるバックアップ用のボリューム１７２（以下「バックアップ１７２」）を指定する情報が格納される。本例においては、初期状態、すなわち全てのテーブルの変換処理が始まる前の状態のボリューム１７０のバックアップ１７２は１７２（ａ）であるので、レコード６４１のバックアップ６４０にはバックアップ１７２（ａ）を示す情報が登録される。

尚、上述したように、レコードの順序は、テーブルの変換処理が終了するたびに、終了したものが終了した順に上位に、作成中のものがその下に来るように再配置され、その再配置に併せてステータス６３０及びバックアップ６４０に登録される情報が更新される。

管理コンソール１００は、回復ポイント１８２に登録されている内容を図６に示すように表示画面に表示する。障害からの回復作業時には、システム管理者は表示された画面を見ながら回復するポイントを複数のレコードから選択し、表示画面上の復旧ボタン６５０をポインティングデバイス等で指定する。管理コンソール１００は、システム管理者が選択した回復ポイントの情報に基づいて、指定されたポイントのデータ状態に計算機システムを回復するよう、サーバ計算機２００に指示を出す。

以下、本実施形態におけるデータ変換バッチの処理手順について説明する
図７は、データ変換バッチの開始時の処理フローの例を示す図である。尚、本実施形態では、データ変換バッチによって、複数のテーブル変換のバッチが並行して実行されるとする。

まず、システム管理者がデータ変換バッチの開始をサーバ計算機２００に指示する。指示を受けたシステム復旧管理部１１２は、ストレージ管理部１１６を介して、データ変換バッチ実行前のボリューム１７０のバックアップ１７２（ａ）の作成をバックアップリストア処理部１６２に指示する。指示を受けたバックアップリストア処理部１６２は、ボリューム１７０のバックアップ１７２（ａ）を作成する。このときメタデータ１７９についてもバックアップ１７２（ａ）に保持される（ステップ７００）。

システム管理プログラム１００は、バッチ管理部１１４を用いてデータ変換バッチ実行プログラム１４０から通知される各バッチの実行状況を受信することで、各データ変換バッチの実行状態の監視を開始する（ステップ７１０）。データ変換バッチ実行プログラム１４０は、データ変換バッチ１８０を読み込み、定義されている内容に基づいて、各テーブルのデータ変換バッチの処理を開始する。又データ変換バッチ実行プログラム１４０は、各バッチの実行状態をバッチ管理部１１４に通知する（ステップ７２０）。

システム復旧管理部１１２は、バックアップリストア処理部１６２のバックアップ結果およびバッチ管理部１１４がデータ変換バッチ実行プログラム１４０から通知されたバッチ実行状態に基づいて、回復ポイント１８２に、作成されるテーブルに対応するレコード（本例ではレコード６４１、６４２及び６４３）を作成し、レコード６４１のフィールド６４０を「バックアップ１７２（ａ）」、レコード６４２およびレコード６４３のステータス６３０に「作成中」（バッチが実行中であることを示す）の情報を追加し、回復ポイント１８２を更新する（ステップ７３０）。

図３は、データ変換バッチの処理を実行している最中の計算機システムにおけるバックアップ処理の処理フローを示す図である。
データ変換バッチ実行プログラム１４０がデータ変換バッチの実行を開始すると、バッチ管理部１１４は、データ変換バッチ実行プログラム１４０から通知される各バッチの実行状態を受信することでデータ変換バッチのバッチ実行状態を監視する（ステップ３００）。

データ変換バッチ実行プログラム１４０は、あるテーブル、本実施形態では部別サマリ１７７を作成するバッチの実行状態が変化したことを検知する(ステップ３１０)。その変化が正常終了であれば（ステップ３２０）、データ変換バッチ実行プログラム１４０は、ボリューム１７０にまだ書き出されていない部別サマリ１７７に関するデータを、ストレージ管理部１１６を介して計算機からボリューム１７０に完全に書き出す（ステップ３３０）。

その後、システム復旧管理部１１２は部別サマリ１７７作成後の状態のボリューム１７０のスナップショット１７２（ｂ）の作成をバックアップリストア処理部１６２に指示する。指示を受けたバックアップリストア指示部１６２は、部別サマリ１７７作成後の状態のボリューム１７０のスナップショット１７２（ｂ）を作成する。このとき、メタデータ１７９も、スナップショット１７２（ｂ）内に作成される（ステップ３４０）。

一方、データ変換バッチプログラム１４０は、あるデータ変換バッチが正常に終了すると、バッチ管理部１１４を通じてシステム復旧管理部１１２に部別サマリ１７７を作成するバッチの終了を通知する（ステップ３５０）。通知を受けたシステム復旧管理部１１２は、回復ポイント１８２の部別サマリ１７７に関するレコード６４２のステータス６３０の内容を「作成完了」とし、回復ポイント１８２のレコードのソートを行う。具体的には、システム復旧管理部１１２は、最初に終了したバッチとしてレコード６４１の直下（あるいは他に終了したバッチのレコードの下）にレコード６４２を配置する（ステップ３６０）。

その後、データ変換バッチプログラム１４０は、あるテーブル、本実施例では社歴サマリ１７８を作成するバッチの実行状態が変化したことを検知する(ステップ３１０)。その変化が正常終了でないことすなわち異常終了であることを検知した場合（ステップ３２０）、データ変換バッチプログラム１４０は、社歴サマリ１７８を作成するバッチが異常終了したことを、バッチ管理部１１４を通じてシステム復旧管理部１１２に通知する（ステップ３７０）。

異常終了を通知されたバッチ管理部１１４は、実行中の他のバッチを停止し、バッチの監視処理を停止する。このとき、システム復旧管理部１１２は、回復ポイント１８２の社歴サマリ１７８に関するレコード６４３のステータスを「障害」とし、レコードのソートを行い、次に（異常）終了したバッチであるので、バッチ処理が完了しているレコード６４２の直下に配置する。

ステップ３６０の処理後、すべてのバッチが終了していなければ（ステップ３８０）、バッチ管理部１１４は、データ変換バッチ実行プログラムの状態の監視を引き続き続ける（ステップ３００）。すべてのバッチ終了を検知すると（ステップ３８０）、バッチ管理部１１４は、バッチの監視処理を停止する。

以下、本実施形態のシステムでテーブルのデータを復旧する手順について説明する。
図４は、計算機システムがテーブル変換処理の障害の発生により停止した場合の復旧処理の処理フローを示す図である。

クライアント計算機２１０の管理コンソール１００は、サーバ計算機２００のシステム復旧管理部１１２を介して回復ポイント１８２の情報を読み出し、システム管理者に提示する。システム管理者は、表示された回復ポイントの一覧から所望の回復ポイントを選択し、管理コンソール１００の復旧ボタン６５０をポインティングデバイス等で指定する。

管理コンソール１００は、システム管理者の指定を認識したら、選択された回復ポイントの情報及び回復処理の開始の指示を、システム復旧管理部１１２へ送信する。指示を受信したシステム復旧管理部１１２は、管理コンソール１００から受信した情報に基づいて復旧処理を開始する。

尚、本実施形態では、部別サマリ１７７については正常に作成が完了し、社歴サマリ１７８について障害が発生し正常に作成されていない状態で計算機システムが停止したと仮定する。したがって、システム管理者は、部別サマリ１７７については正常に完了し、かつ、社歴サマリ１７８については初期状態に戻すような回復ポイントである、部別サマリ作成完了後の状態であるレコード６４２を選択するものとする。

システム管理者は、回復ポイント１８２のステータスを見ることで、上記のような判断が可能となる。特に、回復ポイント１８２では、作成されたテーブル順にレコードが並べ替えられているので、システム管理者はどこまでのテーブルの作成が終了しているか容易に判断できる。尚、システム管理者は必ずしも直前に作成されたテーブルまでの復旧を行わなくても良く、その前等を選択しても良い（ステップ４００）。

復旧処理を開始したシステム復旧管理部１１２は、まずレコード６４２の更新時に作成したスナップショット１７２（ｂ）のデータに基づいて、ボリューム１７０を復元する。具体的には、スナップショット１７２（ｂ）として作成されたボリュームをボリューム１７０と置き換える、または、スナップショット１７２（ｂ）で保持されている更新前のデータをボリューム１７０に上書きする。このとき、ボリューム１７０に格納されているメタデータ１７９は、メタデータ１７９（ｂ）である（ステップ４１０）。

その後、システム復旧管理部１１２は、データアクセス部１４２を介して、ボリューム１７０に復元されたメタデータ１７９（ｂ）及びバックアップ１７２（ａ）に格納されているバッチ処理稼動前の初期状態のメタデータ１７９（ａ）を取得する（ステップ４２０）。その後、システム復旧管理部１１２は、取得したメタデータ１７９（ａ）及び（ｂ）から、作成中に障害が発生したテーブル（本実施形態では社歴サマリ１７８）に関連する部分、具体的にはメタデータ１７９（ａ）中のヘッダ５０１中の５０７、ページ５０４及び５０５、同様にメタデータ１７９（ｂ）中のヘッダ５２０中の５２７、ページ５２４及び５２５の書かれている位置を識別する（ステップ４３０）。

ここで、ボリューム１７０に格納されているメタデータ１７９（ｂ）に示されるページ５２７、５２４、５２５は、テーブル社歴サマリ１７８作成中に障害が発生したためデータの整合性が保たれていない。そこで、社歴サマリ１７８についてのみデータ変換バッチの処理前の状態に戻すべく、システム復旧管理部１１２は、データアクセス部１４２を用いて、ボリューム１７０に復元されたメタデータ１７９（ｂ）の項目５２７、５２４及び５２５の内容を、初期状態のバックアップ１７２（ａ）に格納されたメタデータ１７９（ａ）の項目５０７、５０４及び５０５の内容に各々書きかえる（ステップ４４０）。

ステップ４４０完了後のメタデータ１７９のレコード例を５００（ｃ）に示す。このとき、該テーブル、社歴サマリテーブルについて、中身が空のテーブルであれば、書き換えではなくメタデータ部分を削除してもよい。

この作業によって、部別サマリ１７７に関しては、作成完了後のメタデータ、具体的にはメタデータ１７９（ｂ）の５２８、５２２及び５２３が保たれ、社歴サマリ１７８に関しては、社歴サマリ１７８作成前のメタデータ、具体的には５０７、５０４及び５０５に修正される。作業終了後、システム復旧管理部１１２は、回復ポイントの社歴サマリに関する情報ならびに実行中ステータスとなっていたバッチに関する情報を更新し（ステップ４６０）、管理コンソール１００に復旧処理完了を通知する。

復旧処理完了を通知されたシステム管理者は、再びデータ変換バッチの開始をサーバ計算機に指示する。指示を受けたデータ変換バッチ実行プログラムは、回復ポイントの情報を用いてテーブルの作成が完了していないバッチを識別し、それらの再実行（最初から処理を再度行う）を開始する。以下同様に、システム復旧管理部１１２は、ストレージ管理部１１６を介して、データ変換バッチ実行前のボリューム１７０のバックアップ１７２（ａ）の作成をバックアップリストア処理部１６２に指示する。

そして、指示を受けたバックアップリストア処理部１６２は、ボリューム１７０のバックアップ１７２（ａ）を作成する。ただし、このときのボリューム１７０は、部別サマリ１７７については、作成完了後のデータを含んでいる（ステップ７００）。その後、サーバ計算機２００は、図７で示したバッチ処理の実行を継続する。

第一の実施形態では、あるテーブル変換処理の異常終了に伴って一旦中断された他のテーブル変換処理等は、再度最初から変換処理をやり直していた。しかし、これでは処理に長時間かかるテーブル変換処理等については、再実行することによって処理時間が大幅に伸びてしまう。そこで第二の実施形態では、その点を考慮し、一旦中断されたテーブル変換処理をその中断された個所から再実行することを考える。

第二の実施の形態は、構成の大部分は第一の実施の形態と同じである。しかし、一旦中断されたバッチの処理を処理途中の段階から再開するために、サーバ計算機２００でバッチに関する状態情報１９１（バッチの実行状況等を把握するための情報）及びバッチに関するログ１９０を取得・保存している点が第一の実施形態と異なる。状態情報１９１は、主記憶２０２に格納される。以下、第一の実施形態と異なる部分のみ説明する。

本実施例では、図１において、ボリューム１７０は、実施例１に加えて、ログ１９０を格納する。ここで、ログとはＤＢＭＳで作成するログであって、ＤＢに対する書き込みなどのデータ操作に関する情報が時系列で処理時間とともに格納されている。ＤＢＭＳはそのログを用いることで、テーブルのロールバックおよびロールフォワード処理を行なうことができる。バックアップ１７２（ａ）、スナップショット１７２（ｂ）等についても、ログ１９０を格納する。なお、ログ１９０は当該ストレージ装置ではなく別のストレージ装置に格納されていてもよい。また、状態情報１９１はボリューム１７０に格納されていてもよい。

まず、本実施形態の処理の流れを簡単に説明する。システム管理者がデータ変換バッチの実行を指示すると、システム復旧管理部は、実行前のボリューム１７０のバックアップを作成する。その後、データ変換バッチ実行プログラム１４０は、部別サマリを作成するバッチ、社歴サマリを作成するバッチ、その他バッチを起動し、並列に実行する。

その後、事前に指定された時間間隔またはコミットまたはバッチの終了等の契機で、システム復旧管理部１１２はバッチの実行状況を状態情報１９１として記録し、ボリューム１７０のスナップショットを作成する。その後、システム復旧管理部１１２は、回復ポイントを更新し、データ変換プログラムにバッチの状態情報を記録させる。その後、データ変換バッチ実行プログラム１４０は、引き続いて、実行中のバッチを並列に実行する。

その後、例えば部別サマリを作成するバッチの正常終了後、社歴サマリを作成するバッチが異常終了し、その他バッチは実行されているとする。システム復旧管理部１１２は全バッチを停止し、部別サマリ作成後の任意のバックアップまたはスナップショットから、部別サマリが正常に作成されかつ社歴サマリおよびその他テーブルが作成中のバックアップ取得時点へボリュームを復元する。

このとき、作成中の社歴サマリならびにその他バッチが作成中のテーブルのデータの整合性を保つように、システム復旧管理部は、先に指定したバックアップまたはスナップショットまたはその他ボリュームに格納されるログ１９０を用いて、ボリュームを復元する。

復元後、システム管理者はバッチの再実行を指示する。この指示に基づいて、システム復旧管理部は実行前のバックアップを同様に作成し、社歴サマリを作成するバッチ及びその他バッチを起動し、実行する。このとき、バックアップ作成時に記録したバッチの状態情報を用いて、バッチのバックアップ作成時の中途からの実行を可能にする。

図１０は、クライアント計算機が有する表示画面に表示されるユーザインターフェイスの例を示す図である。管理コンソール１００は、その表示画面に回復ポイント１８２の情報を表示する。

回復ポイント１８２の各レコードは、第一の実施例で示すフィールド６２０及び６３０の代わりに、時間１０２０、契機１０３０及び対応ステータス１０４０のフィールドを有する。尚、第一の実施例と異なり、本実施例の回復ポイント１８２は、取得されたバックアップまたはスナップショット毎にレコードを有する。これにより、きめ細かいデータの復旧が可能となる。又、実施時間が長いデータ変換バッチについて、最初からやり直す必要が無くなる。

時間１０２０には、バックアップまたはスナップショットの取得時刻を示す情報が登録される。契機１０３０には、バックアップまたはスナップショットを取得した契機（実行開始時・コミット・終了・定時）を示す情報が登録される。

対応ステータス１０４０には、バッチ状態１０７０に対応するステータス番号を示す情報が登録される。図１０の下部は、回復ポイント１８２のサブテーブルが表示画面に表示されている例を示す。

このサブテーブルは、回復ポイント１８２の対応ステータス１０４０に登録されるステータス番号毎にレコードを有する。各レコードは、対応するステータス番号が登録されるフィールド１０４０及び対応するステータス番号で記述されるバッチの状態を示す情報が登録されるフィールド１０７０を有する。

具体的にフィールド１０７０には、各テーブルを作成する各バッチについて、そのバッチ中の各変換処理ステップの実行処理行数・「実行中」・「実行終了」・「実行処理前」などの実行処理状態・実行時に利用する中間ファイルなどのバッチの実行状態に関する情報（状態情報１９１）が格納される。

なお、本実施例では回復ポイント１８２とそのサブテーブルを分割して管理しているが、これらは単一の表形式をとってもよく、または、さらに分割された複数の表形式をとってもよい。

管理コンソール１００は、回復ポイント１８２に登録されている内容を図１０に示すように表示画面に表示する。障害からの回復作業時には、システム管理者は表示された画面を見ながら回復するポイントを複数のレコードから選択し、表示画面上の復旧ボタン１０６０をポインティングデバイス等で指定する。管理コンソール１００は、システム管理者が選択した回復ポイントの情報に基づいて、指定されたポイントのデータ状態に計算機システムを回復する。

以下、本実施形態におけるデータ変換バッチの処理手順について説明する
データ変換バッチの開始時の処理フローは第一の実施例で説明したフロー（図７）と同一である。

ただし、ステップ７３０において、システム復旧管理部１１２は、バックアップリストア処理部１６２のバックアップ結果およびバッチ管理部１１４がデータ変換バッチ実行プログラム１４０から通知されたバッチ実行状態に基づいて、回復ポイント１８２に、実行開始を示すレコード（本例ではレコード１０４１）を作成する。そして、システム復旧管理部１１２は、レコード１０４１のフィールド１０２０に開始時間、契機１０３０に「実行開始時」、上部状態１０７０の各バッチを示すフィールドに「実行開始：０行」の情報を追加し、回復ポイント１８２を更新する。

図８は、本実施例における、データ変換バッチの処理を実行している最中の計算機システムにおけるバックアップ処理の処理フロー例を示す図である。

データ変換バッチ実行プログラム１４０がデータ変換バッチの実行を開始すると、バッチ管理部１１４は、データ変換バッチ実行プログラム１４０から通知される各バッチの実行状態を受信することで、データ変換バッチのバッチ実行状態を監視する。この際、バッチ管理部１１４は、各バッチの状態情報１９１も随時取得している（ステップ８００）。

データ変換バッチ実行プログラム１４０は、あるバッチがコミットを発行、実行状態の変化又は設定時間が経過したこと等を検知する（ステップ８１０）。その状態変化が異常終了でないことを検知、すなわち、あるバッチのコミット発行、正常終了、又は設定時間の経過であれば（ステップ８２０）、データ変換バッチ実行プログラム１４０は、ステップ８１０時点で取得されているバッチの状態情報及びボリュームにまだ書き出されていない実行中のバッチに関するデータを、ストレージ管理部１１６を介して計算機からボリューム１７０に完全に書き出す。これによりデータの整合性が保たれる(ステップ８３０)。

次に、システム復旧管理部１１２は現在の状態のボリューム１７０のスナップショット１７２の作成をバックアップリストア処理部１６２に指示する。尚、ステップ８１０で検知された状態変化がコミットの場合、スナップショット１７２（ｂ）が作成される。指示を受けたバックアップリストア指示部１６２は、ボリューム１７０のスナップショット１７２（ｂ）を作成する（ステップ８４０）。

次にデータ変換バッチプログラム１４０は、バッチ管理部１１４を通じてシステム復旧管理部１１２に現在の各バッチの状態を通知する（ステップ８５０）。通知を受けたシステム復旧管理部１１２は、回復ポイント１８２に、レコード（作成されたボリューム１７２がスナップショット１７２（ｂ）だった場合、図１０のレコード１０４２）を追加し、バッチ状態１０７０の各バッチに関するステータスを更新する（ステップ８６０）。

ステップ８２０において、状態変化がバッチの終了であれば、レコード１０４３が、状態変化が設定時間の経過であればレコード１０４４が追加される。このとき、回復ポイント１８２のバックアップ・スナップショット作成時間１０２０に記録されているバックアップ・スナップショット作成時間は、ログ１９０に記録されている時間と同期している必要がある。

一方、データ変換バッチ実行プログラム１４０が検知した状態変化が異常終了であれば（ステップ８２０）、データ変換バッチ実行プログラム１４０は、データ変換バッチ処理が異常終了したことを、バッチ管理部１１４を通じてシステム復旧管理部１１２に通知する（ステップ８７０）。その後、バッチ管理部１１４は、実行中の全てのバッチを停止し、バッチの監視処理を停止する。

このとき、システム復旧管理部１１２は、回復ポイント１８２にレコード１０４５を追加し、異常終了したバッチであるので、バッチ状態１０７０の社歴サマリ作成バッチに関するステータスを「障害により停止」とする。その後、バッチ管理部１１４は、バッチの監視処理を停止する。

以下、本実施形態の計算機システムでテーブルのデータを復旧する手順について説明する。
図９は、計算機システムが障害の発生により停止した場合の復旧処理の処理フローを示す図である。

管理コンソール１００は、システム復旧管理部１１２を介して回復ポイント１８２を読み出し、システム管理者に提示する。システム管理者は、表示された回復ポイントの一覧から所望の回復ポイントを選択し、管理コンソール１００の復旧ボタン１０６０をポインティングデバイス等で指定する。

管理コンソール１００は、システム管理者の指定を認識し、選択された回復ポイントの情報及び回復処理の開始の指示を、システム復旧管理部１１２へ送信する。指示を受信したシステム復旧管理部１１２は、管理コンソール１００から受信した情報に基づいて復旧処理を開始する。

尚、本実施形態では、部別サマリ１７７については正常に作成が完了し、社歴サマリ１７８について障害が発生し正常に作成されていない状態でシステムが停止したと仮定する。そのため、システム管理者は、部別サマリ１７７については正常に完了し、かつ、社歴サマリ１７８についてはその作成中の最新状態に戻すような回復ポイントである、部別サマリ作成完了後の最新の状態であるレコード１０４４を選択するものとする（ステップ９００）。

復旧処理を開始したシステム復旧管理部１１２は、まずレコード１０４４の更新時に作成したバックアップ１７２（ｄ）のデータに基づいて、ボリューム１７０を復元する（ステップ９１０）。

その後、システム復旧管理部１１２は、選択されたレコード１０４４に対応するスナップショット１７２（ｄ）（あるいは他のボリューム）からログ１９０を取得する。又、システム復旧管理部１１２は、選択されたレコード１０４４のバックアップ取得時間１０２０に記録された時間の直前と直後にログ１９０に記録された履歴を抽出する。具体的には、システム復旧管理部１１２は、選択したレコード１０４４のフィールド時間１０２０およびバッチ状態１０７０に登録された情報により、当該ログのバックアップ取得時間前のエントリを選択する(ステップ９２０)。その後、システム復旧管理部１１２は、選択したログの履歴をもとに、復元したボリューム１７０中のテーブルデータとログ１９０の選択された部分の内容を照合することで整合性を検証する（ステップ９３０）。

その後、整合性が維持されていない場合、システム復旧管理部１１２は、ログがテーブルデータに反映されていなければ、ロールアップ処理を行うことにより、ログ中の履歴をボリューム１７０上のデータに反映する（ステップ９４０）。

この作業によって、部別サマリ１７７に関しては、作成完了後のデータが保たれ、社歴サマリ１７８に関しては、社歴サマリ１７８作成中で回復ポイント１０４４のバッチ状態１０７０時点のデータが復元される。作業終了後、または、整合性が維持されていた場合、システム復旧管理部１１２は、管理コンソール１００に復旧処理完了を通知する(ステップ９５０)。

以下、本実施形態のシステムでバッチを再開する手順について説明する。
図１１は、計算機システムがデータ変換バッチの障害の発生により停止した場合の再開処理の処理フローを示す図である。

障害の復旧処理の完了を確認したシステム管理者は、データ変換バッチの再開をサーバ計算機２００に指示する。指示を受けたシステム復旧管理部１１２は、ストレージ管理部１１６を介して、データ変換バッチ実行前のボリューム１７０のバックアップ１７２（ａ）の作成をバックアップリストア処理部１６２に指示する。

指示を受けたバックアップリストア処理部１６２は、ボリューム１７０のバックアップ１７２（ａ）を作成する。ただし、このときのボリューム１７０は、部別サマリ１７７については、作成完了後のデータを含み、社歴サマリ１７８については、作成途中のデータを含んでいる（ステップ１１００）。
次に、システム復旧管理部１１２は、システム監視・バックアップ処理（ステップ８００以降）を開始する(ステップ１１１０)。

その後、データ変換バッチ実行プログラム１４０は、データ変換バッチ１８０及びバッチ状態情報１９１を主記憶２０２から読み出す（ステップ１１２０）。そしてデータ変換バッチ実行プログラム１４０は、バッチ状態情報１９１に記録されたバッチ状態よりデータ変換バッチ１８０の実行状態を決定し、バッチの実行を途中（回復ポイントの時点）から再開する（ステップ１１３０）。

その後データ変換バッチ実行プログラム１４０は、各バッチの開始と、各テーブルを作成する各バッチに関する、そのバッチ中の各変換処理ステップの実行処理行数・「実行中」・「実行終了」・「実行処理前」などの実行処理状態・実行時に利用する中間ファイルなどのバッチの実行状態についての状態情報をバッチ管理部１１４に通知する。通知を受けたバッチ管理部１１４は、通知された内容をシステム復旧管理部に通知する。通知を受けたシステム復旧管理部１１２は、通知内容に基づいて回復ポイント１１２に新たなレコードを追加し、各フィールドを更新する（ステップ１１４０）。

なお、実施例１および実施例２に示した方法は、排他的な関係にあるのではなく、その複合形をとってもよい。すなわち実施例１のメタデータによる回復と実施例２のログを用いた回復を併用することもできる。

計算機システムの論理的な構成例を示す図である。 計算機システムのハードウェア構成例を示す図である。 バックアップ作成手順の例を示すフローチャートである。 データ復旧の処理手順の例を示すフローチャートである。 メタデータの例を示す図である。 ユーザインターフェイス及び回復ポイントの例を示す図である。 データ変換バッチの開始手順の例を示すフローチャートである。 バックアップ作成手順の例を示すフローチャートである。 データ復旧の処理手順の例を示すフローチャートである。 ユーザインターフェイス及び回復ポイントの例を示す図である。 データ変換バッチの再開始手順の例を示すフローチャートである。

符号の説明

１００…管理コンソール、１１０…システム管理プログラム、１１２…システム復旧管理部、１１４…バッチ管理部、１１６…ストレージ管理部、１４０…データ変換バッチ実行プログラム、１４２…データアクセス部、１６０…ストレージ装置、１６２…バックアップリストア処理部、１７０…ボリューム、１７２（ａ）…バックアップ、１７２（ｂ）…バックアップ、１８０…データ変換バッチ、１８２…回復ポイント、１９０…ログ、１９１…バッチ状態情報。

Claims (2)

1. クライアント計算機に接続される計算機と、
   前記計算機に接続されるストレージ装置とを有し、
   前記ストレージ装置が備えるボリュームにデータベースが格納され、
   前記計算機は、
   前記ボリュームに格納される第一のテーブルのデータを基に前記ボリューム内に作成された複数の第二のテーブルに対する複数のバッチ処理を並列に行い、
   前記複数のバッチ処理の実行前に、前記ボリュームのバックアップデータの作成の指示を前記ストレージ装置に送信することにより、前記ストレージ装置にバックアップデータを作成させ、
   前記複数のバッチ処理のいずれか一つの処理が終了するごとに、前記ボリュームのスナップショットの作成の指示を前記ストレージ装置に送信することにより、前記ストレージ装置に前記スナップショットを作成させ、
   前記スナップショットの作成が指示された時刻における前記複数のバッチ処理の実行状況を記憶し、
   前記複数のバッチ処理の実行状況と前記スナップショットが対応付けられる回復ポイントを管理し、
   前記複数のバッチ処理に含まれる各々のバッチ処理の実行による前記複数の第二のテーブルを書き換える指示と、バックアップデータの作成の指示と、スナップショット作成の指示に関する情報と、各々の指示がなされた時刻をログとして管理し、
   前記複数のバッチ処理のうちいずれか一つが異常終了した場合、
   前記クライアント計算機から指定された前記回復ポイントに対応する前記スナップショットと前記バックアップデータを用いて、前記ボリュームを前記クライアント計算機から指定された前記回復ポイントに対応するスナップショットの作成時の状態に復元する指示を前記ストレージ装置に送信することにより、前記ストレージ装置に前記ボリュームを前記クライアント計算機から指定された前記回復ポイントに対応するスナップショットの作成時の状態に書き換えさせ、
   前記復元されたボリュームに格納される複数の第二のテーブルの内容と前記ログに含まれる各々のバッチ処理の実行による前記複数の第二のテーブルを書き換える指示を照合することにより、前記クライアント計算機から指定された回復ポイントに対応する前記複数のバッチ処理の実行状況で実行済みになっているにもかかわらず、前記復元したボリュームの第二のテーブルに反映されていない前記複数のバッチ処理に含まれる各々のバッチ処理の実行による前記複数の第二のテーブルを書き換える指示を抽出し、
   前記抽出された前記複数のバッチ処理に含まれる各々のバッチ処理の実行による前記複数の第二のテーブルを書き換える指示を前記復元されたボリュームに格納される複数の第二のテーブルに反映することにより、
   前記計算機は前記指定された回復ポイントからバッチ処理を再開する
   事を特徴とする計算機システム。
   
2. 前記計算機は、複数の前記バッチ処理の状態を示す情報を有する情報テーブルを有し、前記情報テーブルの内容を前記計算機に接続される表示部に表示することを特徴とする請求項１記載の計算機システム。

Images