JP3985430B2 - データベース管理装置及び方法 - Google Patents
データベース管理装置及び方法 Download PDFInfo
- Publication number
- JP3985430B2 JP3985430B2 JP2000166758A JP2000166758A JP3985430B2 JP 3985430 B2 JP3985430 B2 JP 3985430B2 JP 2000166758 A JP2000166758 A JP 2000166758A JP 2000166758 A JP2000166758 A JP 2000166758A JP 3985430 B2 JP3985430 B2 JP 3985430B2
- Authority
- JP
- Japan
- Prior art keywords
- database
- backup
- information
- management table
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データベースのバックアップ技術に関する。
【０００２】
【従来の技術】
データベースのバックアップ方式として、従来より差分バックアップ方式が用いられている。例えば従来のファイリング装置における差分バックアップ処理では、データベース（ファイルシステム）の内容に変化が生じる操作が行われたとき、その操作の内容をバックアップ情報として記録していた。例えば、データベース内容に変化が生じるのはファイルやディレクトリの追加、削除、その内容の変更などの操作が行われたときであり、そのような操作が確定された場合にのみ操作内容をバックアップするのが一般的である。差分バックアップは、データベースの内容全体をバックアップ（フルバックアップと呼ぶ）した時点から開始する。差分バックアップ情報は、データベースとは別の記憶媒体に保管され、障害が起こった場合などには、そのバックアップ情報を用いて復旧処理を行う。
【０００３】
復旧処理では、バックアップ情報に表された操作内容を時系列順に読み出し、前回のフルバックアップデータに対して時系列順にそれら操作を適用していくことにより、障害発生直前のデータベースイメージを再生する。
【０００４】
【発明が解決しようとする課題】
しかしながら、このような従来の差分バックアップ方式では、次のような問題が生じる。
【０００５】
まず、従来方式では、個々の操作内容の情報をそのまま保存する必要があるため、差分バックアップ処理を行っている間は、データベースシステムの処理速度が低下する。例えば、画像ファイルなどを追加する場合、「追加」という操作コードの他にその画像ファイル自体をバックアップ用の媒体にコピーするなどの処理が必要となるため処理に時間を要し、参照や追加、削除などデータベース本来のサービスの効率が落ちてしまうおそれがあった。
【０００６】
また従来方式では、差分バックアップ情報からデータベース復旧を行う際、操作内容の時系列を順に適用していく必要があるため、多大の処理時間を要するという問題があった。
【０００７】
本発明は、このような問題に鑑みなされたものであり、通常のサービス処理の効率をできるだけ落とさないよう、バックアップ処理の負荷を低減することのできるデータベース管理装置を提供することを目的とする。また、本発明は、障害の復旧に要する処理の時間を従来より低減できるデータベース管理装置を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するため、本発明に係るデータベース管理装置は、データベースに登録された各オブジェクトの実体データに関して、当該実体データの格納場所の情報を含む当該オブジェクトの管理情報を保持する管理テーブルと、前記データベースに対して行われた操作に応じて前記管理テーブルを更新する手段と、所定のバックアップタイミングごとに、その時点での前記管理テーブルの内容のコピーをスナップショット情報として保存するスナップショット手段と、前記バックアップタイミングごとに、その時点での前記管理テーブルの内容と前回バックアップタイミングに作成された前記スナップショット情報との間で各オブジェクトの実体データの格納場所の情報を比較することにより、前回から今回までの間で前記データベースに追加されたオブジェクトの実体データの有無を判定し、前記データベースに追加されたオブジェクトの実体データがあると判定された場合は、前記管理テーブルにおける当該追加されたオブジェクトの実体データの格納場所の情報に基づき、当該追加されたオブジェクトの実体データをバックアップするバックアップ手段とを備える。
【０００９】
また本発明に係るデータベース管理装置は、データベースに登録された各オブジェクトの実体データに関して、当該実体データの格納場所の情報を含む当該オブジェクトの管理情報を保持する管理テーブルと、所定の基準時点での前記データベースの前記管理テーブルの内容を記憶する手段と、前記データベースに対して行われた操作に応じて前記管理テーブルを更新する手段と、所定のバックアップタイミングにおいて、前記管理テーブルの内容と前記基準時点での前記管理テーブルの内容との間で各オブジェクトの実体データの格納場所の情報を比較することにより、前記基準時点から現時点までの間で前記データベースに追加されたオブジェクトの実体データの有無を判定し、前記データベースに追加されたオブジェクトの実体データがあると判定された場合は、前記管理テーブルにおける当該追加されたオブジェクトの実体データの格納場所の情報に基づき、当該追加されたオブジェクトの実体データをバックアップするバックアップ手段とを備える。
【００１０】
本発明では、データベースに対する操作の度にバックアップ処理を行う必要がないので、通常のデータベース処理の効率の低下を抑えることができる。また、リストアの際も、個々のデータベース操作を時系列順に反映させていくという煩雑な処理が要らないので、リストア処理が高速化できる。
【００１１】
好適な態様では、データベース管理装置は、前記データベースに対して行われる操作の頻度をモニタする手段と、前記バックアップ手段における前記バックアップタイミングを、前記操作の頻度に応じて自動設定するタイミング設定手段とを備える。
【００１２】
この態様によれば、バックアップタイミングをデータベース操作頻度に応じて決定できるため、データベースの使用状況に応じた適切なタイミングでバックアップ処理を実行することができる。
【００１３】
【発明の実施の形態】
以下、本発明の実施の形態（以下実施形態という）について、図面に基づいて説明する。
【００１４】
図１は、本発明に係るデータベースシステムの要部構成を示す図であり、特にバックアップ処理に関する構成を示したものである。以下では、オブジェクト群を階層構造を用いて管理するファイリングサービス機能を備えたシステムを例にとって説明する。
【００１５】
データベース１０は、管理対象の各種オブジェクトのデータを保持している。オブジェクトは、例えばファイルやディレクトリなどであり、オブジェクト間に親子関係が存在する。データベース１０は、個々のオブジェクトの実体データのファイルに加え、各オブジェクトの管理情報を保持する管理テーブル部１００を備えている。
【００１６】
管理テーブル部１００は、属性情報管理テーブル１１０、親子関係管理テーブル１２０、及び画像データ保管先管理テーブル１３０の３種のテーブルを備える。これら各テーブルで管理するデータ項目の例を図３に示す。この例では、設計部門での図面の画像データの管理の場合を例にとる。したがって、データベースで管理されるオブジェクトは、図面の画像データのファイルや、それらファイルを収容するためのディレクトリ（フォルダ）などである。
【００１７】
まず属性情報管理テーブル１１０は、データベース１０に登録されている個々のオブジェクトの属性情報を保持、管理するテーブルである。このテーブル１１０は、図３（ａ）に示すように、各オブジェクトごとに、オブジェクトＩＤ、オブジェクト名、更新日時、補助的な属性情報（「属性１」、「属性２」）の各データ項目を保持する。オブジェクトＩＤは、データベース１０が当該オブジェクトに対して付与した一意な識別情報である。オブジェクト名は、ユーザがそのオブジェクトに与えたファイル名やディレクトリ名などの名称である。更新日時は、そのオブジェクトが新たにデータベース１０に登録された時や、既登録のそのオブジェクトについて更新が加えられた時の日時、時刻を示し、更新が行われる度にその値は変更されていく。補助的な属性情報である「属性１」、「属性２」は、ユーザ側が自由に定義して利用できるデータ項目である。図３の例では、「属性１」は当該オブジェクト（図面画像ファイル又はディレクトリ）が関連する部品（例えばその図面が表す部品）の名前を、「属性２」は当該オブジェクトが関連する部門（例えばその図面やフォルダを所有する設計部門）の名前を、それぞれ示している。
【００１８】
親子関係管理テーブル１２０は、データベース１０に登録されているオブジェクト間の親子関係の管理のためのテーブルである。この例では、オブジェクト群の階層構造を、２オブジェクト間の親子関係の集まりとして管理している。このテーブル１２０は、図３（ｂ）に示すように、個々の親子関係ごとに、リンクＩＤ、親オブジェクトＩＤ、及び子オブジェクトＩＤの各項目を保持している。リンクＩＤは、データベース１０が当該親子関係に対して付与した一意的な識別情報である。親オブジェクトＩＤは、その親子関係における親（すなわち上位）のオブジェクトのオブジェクトＩＤである。子オブジェクトＩＤは、その親子関係における子（すなわち下位）のオブジェクトのオブジェクトＩＤである。図の例では、リンクＩＤ“１”の親子関係は、オブジェクトＩＤ“０００２”を持つオブジェクト「見取り図」がオブジェクトＩＤ“０００１”のオブジェクト「フォルダー」の子になっていることを示している。
【００１９】
画像データ保管先管理テーブル１３０は、個々のオブジェクトの実体データの保管先の情報を保持、管理するテーブルである。テーブル１３０には、図３（ｃ）に示すように、図面画像データを表す各オブジェクトごとに、そのオブジェクトのオブジェクトＩＤと、その画像データのデータファイル名とがペアになり、そのペアに対して一意的な「保管先ＩＤ」が付与されている。データファイル名は、その画像データのファイルの格納場所も含めたパス、あるいはネットワークアドレスなどの形で記述される。なお、ディレクトリなど、画像データファイルではないオブジェクトについては、当然ながらこの保管先管理テーブル１３０には管理情報が登録されない。
【００２０】
以上、管理テーブル部１００について説明した。ここで再び図１を参照し、本システムの残りの構成要素について説明する。
【００２１】
スナップショット情報記憶部２０は、ある時点での管理テーブル部１００のコピー（以下、スナップショット情報と呼ぶ）を記憶する記憶手段である。
【００２２】
バックアップ処理部３０は、データベース１０のバックアップに関する処理を行う手段である。本実施形態では、バックアップ処理部３０は、所定のバックアップタイミングごとに、その時点での管理テーブル部１００の内容と、スナップショット情報記憶部２０に記憶した前回のバックアップタイミングにおける管理テーブル部１００のスナップショット情報とを比較し、その比較に基づき、前回バックアップタイミングから現時点までの間のデータベース１００の変化を抽出する。そして、その変化内容を示すバックアップ情報を作成し、バックアップ情報保管部４０に保管する。また、バックアップ処理部３０は、バックアップ情報の作成・保管の後、その時点の管理テーブル１００のスナップショット情報を作成し、スナップショット情報記憶部２０に記憶する。このとき、前回のスナップショット情報に対して上書きを行うことにより、スナップショット情報記憶部２０の容量を節約できる。
【００２３】
バックアップタイミングは、例えば、システム管理者が予め設定したバックアップ間隔ごとなど、所定の規則に従って決定される。
【００２４】
バックアップ情報保管部４０には、各バックアップタイミングにて作成されたバックアップ情報が、時系列的な順序が認識可能な態様で保管される。障害復旧時には、このバックアップ情報保管部４０に保管されたバックアップ情報を用いてデータベース１０の復旧（リストア）が行われる。
【００２５】
図２は、本データベースシステムの障害復旧処理時の構成を示している。この構成において、リストア処理部５０は、データベース１０の復旧処理を行う手段であり、バックアップ情報保管部４０に保管された各バックアップ情報に示されるデータベース１０の変化内容を、時系列順にデータベース１０に適用していくことにより、データベース１０を復旧する。なお、この復旧処理のため、バックアップ処理部３０によるバックアップ処理を開始する時点（基準時点と呼ぶ）で、データベース１０のフルバックアップが行われ、データベース１０全体のコピーが保存されている。復旧処理は、このフルバックアップ時のコピーを基準に実行される。
【００２６】
次に、図４を参照して、本実施形態のシステムにおけるバックアップ処理について説明する。図４は、バックアップタイミングが到来したときのバックアップ処理部３０の処理手順を示すフローチャートである。所定の時間間隔（例えば１時間、１日など）ごとにバックアップを行うようシステムを設定した場合、システムは、前回のバックアップタイミングからその所定時間間隔が経過したとき、バックアップタイミングが到来したと判定して図４の処理を開始する。
【００２７】
ステップＳ１では、バックアップ処理部３０は、前回バックアップタイミングから現時点までの間にデータベース１０から削除されたオブジェクトを確定し、それらオブジェクトが削除された旨の情報をバックアップ情報保管部４０に登録する。この処理の詳細な手順を図５に示す。
【００２８】
図５に示すように、Ｓ１の処理では、まずスナップショット情報記憶部２０に記憶されたスナップショット情報中の属性情報管理テーブルから、そのテーブル中に含まれるオブジェクトＩＤ群を取得する（Ｓ１１）。これらは、前回のバックアップタイミングの時点でデータベース１０に登録されていた各オブジェクトのＩＤである。次に、このようにして取得した各オブジェクトＩＤをそれぞれ順に検索対象に選び、そのＩＤが管理テーブル部１００の属性情報管理テーブル１１０に存在するか否か検索する（Ｓ１２）。存在すれば、そのＩＤに該当するオブジェクトは現時点でもデータベース１０に登録されているということなので、ここではなにもしない。これに対し、Ｓ１２の判定結果がＮ（否定）の場合、そのオブジェクトＩＤに該当するオブジェクトは前回バックアップタイミングではデータベース１０に登録されていたが、今回の時点では登録されていないということになり、そのオブジェクトが前回から今回までの間に削除されたと判断できる。この場合、そのオブジェクトＩＤを、削除オブジェクト情報としてバックアップ情報保管部４０に保管する（Ｓ１３）。そして、Ｓ１１で取得した全オブジェクトＩＤについてＳ１２（及びＳ１３）の処理を繰り返す（Ｓ１４）。
【００２９】
このようにして作成された削除オブジェクト情報の例を図８（ａ）に示す。この図に示すように、削除オブジェクト情報は、前回のバックアップタイミングから現時点までの間にデータベース１０から削除されたオブジェクトのＩＤのリストとなる。
【００３０】
ステップＳ２では、前回バックアップタイミングから現時点までの間にデータベース１０に新たに追加されたオブジェクトを確定し、それらオブジェクトが追加された旨の情報をバックアップ情報保管部４０に登録する。Ｓ２の処理の詳細な手順を図６に示す。
【００３１】
Ｓ２の処理では、まず管理テーブル部１００の属性情報管理テーブル１１０から、そのテーブル中に含まれるオブジェクトＩＤ群を取得する（Ｓ２１）。これらは、現時点においてデータベース１０に登録されている各オブジェクトのＩＤである。次に、このようにして取得した各オブジェクトＩＤについて順番に、そのＩＤがスナップショット情報記憶部２０に記憶された前回バックアップタイミングの属性情報管理テーブルの中に存在するか否かを調べる（Ｓ２２）。存在すれば、（現在データベース１０中に存在する）そのＩＤに該当するオブジェクトは、前回バックアップタイミング現時点でもデータベース１０に登録されていたということなので、ここではなにもしない。これに対し、Ｓ２２の判定結果がＮ（否定）の場合、そのオブジェクトＩＤに該当するオブジェクトは、前回バックアップタイミングではデータベース１０に登録されていなかったが、今回の時点では登録されているということになり、そのオブジェクトが前回から今回までの間に追加されたと判断できる。この場合、そのオブジェクトＩＤに対応する一連の属性情報を属性情報管理テーブル１１０から取得し、追加オブジェクト情報としてバックアップ情報保管部４０に保管する（Ｓ２３）。そして、Ｓ２１で取得した全オブジェクトＩＤについてＳ２２（及びＳ２３）の処理を繰り返す（Ｓ２４）。
【００３２】
このようにして作成された追加オブジェクト情報の例を図８（ｂ）に示す。この図に示すように、追加オブジェクト情報は、前回のバックアップタイミングから現時点までにデータベース１０に新たに追加された各オブジェクトごとに、属性情報管理テーブル１１０に登録された情報（オブジェクトＩＤと、オブジェクト名や更新日時など）を列挙したものとなっている。
【００３３】
ステップ３では、前回バックアップタイミングから現時点までの間に、データベース１０から削除された親子関係を確定し、それら親子関係が削除された旨の情報をバックアップ情報保管部４０に登録する。この処理は、オブジェクトの削除の場合のバックアップ処理（Ｓ１：図５）と同様に行えばよい。すなわち、スナップショット情報記憶部２０に登録されていて、現在の管理テーブル部１００の親子関係管理テーブル１２０に存在しないリンクＩＤを求め、そのようなリンクＩＤを削除リンク情報としてバックアップ情報保管部４０に登録する。このようにして作成された削除リンク情報の例を図８（ｃ）に示す。削除リンク情報は、前回バックアップタイミングから現時点までの間に削除された親子関係のリンクＩＤのリストである。
【００３４】
ステップ４では、前回バックアップタイミングから現時点までの間に、データベース１０に新たに追加された親子関係を確定し、それら親子関係が追加された旨の情報をバックアップ情報保管部４０に登録する。この処理は、オブジェクトの追加の場合のバックアップ処理（Ｓ２：図６）と同様に行えばよい。すなわち、現在の管理テーブル部１００の親子関係管理テーブル１２０に登録されていて、スナップショット情報記憶部２０に存在しないリンクＩＤを求め、そのようなリンクＩＤと、それに対応する親子関係管理テーブル１２０の情報（親オブジェクトＩＤ及び子オブジェクトＩＤ）との組を、追加リンク情報としてバックアップ情報保管部４０に登録する。このようにして作成された追加リンク情報の例を図８（ｄ）に示す。
【００３５】
ステップ５では、前回バックアップタイミングから現時点までの間に、内容に変更が加えられたオブジェクトを確定し、それらオブジェクトが変更された旨の情報をバックアップ情報保管部４０に登録する。この処理の詳細な手順を図７に示す。
【００３６】
図７の処理では、まず管理テーブル部１００の属性情報管理テーブル１１０から、そのテーブル中に含まれるオブジェクトＩＤ群を取得する（Ｓ５１）。次に、このようにして取得した各オブジェクトＩＤについて順番に、そのＩＤがスナップショット情報記憶部２０に記憶された前回バックアップタイミングの属性情報管理テーブルの中に存在するか否かを調べる（Ｓ５２）。存在しない場合、ここではなにもしない。
【００３７】
これに対し、Ｓ５２の判定結果がＹ（肯定）、すなわち当該オブジェクトＩＤがスナップショット情報中に存在していた場合、次に当該オブジェクトＩＤに対応する「更新日時」を、属性情報管理テーブル１１０とスナップショット情報の双方から求め、それら両者が一致するかどうか判定する（Ｓ５３）。「更新日時」はオブジェクトの更新があると変わるものなので、それら両者が一致していた場合、それは当該オブジェクトは前回バックアップタイミングから現時点までに更新されていないことを意味する。したがって、Ｓ５３で双方の更新日時が一致したと判定された場合は、何も行わない。それに対し、Ｓ５３にて双方の更新日時が一致しないと判定された場合、当該オブジェクトＩＤに対応するオブジェクトは変更されたと判断でき、そのオブジェクトＩＤに対応する一連の属性情報を属性情報管理テーブル１１０から取得し、変更オブジェクト情報としてバックアップ情報保管部４０に保管する（Ｓ５４）。そして、Ｓ５１で取得した全オブジェクトＩＤについてＳ５２〜Ｓ５４の処理を繰り返す（Ｓ５５）。
【００３８】
このようにして作成された変更オブジェクト情報の例を図８（ｅ）に示す。この図に示すように、変更オブジェクト情報は、前回のバックアップタイミングから現時点までに更新の行われたオブジェクトごとに、そのオブジェクトについての、属性情報管理テーブル１１０に登録された情報（オブジェクトＩＤと、オブジェクト名や更新日時など）を列挙したものとなっている。
【００３９】
ステップＳ６では、前回バックアップタイミングから今回までの間に、データベース１０から削除された図面画像データ（すなわち、オブジェクトの実体データ）を確定し、その画像データが削除された旨の情報をバックアップ情報保管部４０に登録する。この処理は、オブジェクトの削除の場合のバックアップ処理（Ｓ１：図５）と同様に行えばよい。すなわち、まずスナップショット情報記憶部２０の前回タイミングの画像データ保管先管理テーブルには存在するが管理テーブル部１００の画像データ保管先管理テーブル１３０には存在しない保管先ＩＤを求め、その保管先ＩＤとこれに対応するオブジェクトＩＤ及びデータファイル名をスナップショット情報記憶部２０のから求め、これら情報の組を削除画像情報としてバックアップ情報保管部４０に登録する。このようにして作成された削除画像情報の例を図８（ｆ）に示す。
【００４０】
ステップＳ７では、前回バックアップタイミングから今回までの間に、データベース１０に新規追加された図面画像データを確定し、その画像データの追加を示す情報をバックアップ情報保管部４０に登録する。この処理は、オブジェクトの追加の場合のバックアップ処理（Ｓ２：図６）と同様でよい。すなわち、管理テーブル部１００の画像データ保管先管理テーブル１３０に存在するがスナップショット情報記憶部２０には存在しない保管先ＩＤを求め、その保管先ＩＤとこれに対応するオブジェクトＩＤ及びデータファイル名を、画像データ保管先管理テーブル１３０から求め、これら情報の組を追加画像情報としてバックアップ情報保管部４０に登録する。このようにして作成された削除画像情報の例を図８（ｇ）に示す。また、このとき、その保管先ＩＤに対応するデータファイル名が示す格納場所から図面画像データを取得し、バックアップ情報保管部４０に保存する。このとき、保存する画像データは、追加画像情報（図８（ｇ））の例えばオブジェクトＩＤをファイル名に組み込むなどの形で、追加画像情報との関連付けができるようにしておく。
【００４１】
以上の処理により、前回バックアップタイミングと今回との間でのデータベース１０の変化内容（すなわち差分）を表す情報がバックアップ情報保管部４０にに蓄積される。以上に示した図８（ａ）〜（ｇ）の各情報は、当該バックアップタイミングのものとして相互に関連付けられ、このバックタイミングの時刻情報と対応づけてバックアップ情報保管部４０に保存される。このような差分情報（バックアップ情報）の蓄積が完了すると、バックアップ処理部３０は、ステップ８にて、現時点の管理テーブル部１００の内容をスナップショット情報記憶部２０にコピーし、スナップショット情報を更新する。なお、図４では、ステップＳ１〜Ｓ７について１つの順序を示したが、これら各ステップは基本的には相互に独立しているので、どのような順に実行してもよい。
【００４２】
以上、バックアップ処理の手順について説明した。次に、システム障害解消時等に行うリストア（復旧）処理の手順を説明する。リストア処理は、基本的にはバックアップ処理と逆の手順を踏めばよい。以下、リストア処理の手順を図９を参照して説明する。図９は、リストアの指示が入力された場合の本システムのリストア処理部５０の処理手順を示すフローチャートである。
【００４３】
リストア処理を行う時点では、データベース１０は、管理テーブル部１００も含め、基準時点（すなわちバックアップ処理開始時点）のフルバックアップ状態の内容となっている。この状態でリストア指示が入力された場合、まずステップＳ６０で、リストア処理部５０は、バックアップ情報保管部４０から、最も古いバックアップ情報（差分情報）を取得する。取得されるバックアップ情報は、図８に示すような各情報を含んでいる。
【００４４】
ステップＳ６１では、Ｓ６０で取得したバックアップ情報の中の削除オブジェクト情報（図８（ａ）参照）から、オブジェクトＩＤを取り出し、管理テーブル部１００の属性情報管理テーブル１１０からそのオブジェクトＩＤに対応する行を削除する。図１０に、このＳ６１の詳細な手順を示す。図１０に示すように、Ｓ６１では、まず削除オブジェクト情報からオブジェクトＩＤをすべて取得する（Ｓ７１）。次に、取得した各オブジェクトＩＤをそれぞれ順に検索対象に選び、そのＩＤが管理テーブル部１００の属性情報管理テーブル１１０に存在するか否か検索する（Ｓ７２）。存在すれば、そのオブジェクトＩＤの行の属性情報を削除する（Ｓ７３）。Ｓ７２の結果がＮ（否定）ならば、何も行わない。そして、Ｓ７１で取得した全オブジェクトＩＤについてＳ７２及びＳ７３の処理を繰り返す（Ｓ７４）。
【００４５】
ステップＳ６２では、バックアップ情報の追加オブジェクト情報（図８（ｂ））から、各追加オブジェクトのオブジェクトＩＤとこれに対応する属性情報（オブジェクト名など）を取り出し、これらを管理テーブル部１００の属性情報管理テーブル１１０に追加する。
【００４６】
ステップＳ６３では、バックアップ情報の中の削除リンク情報（図８（ｃ））からリンクＩＤを取り出し、管理テーブル部１００の親子関係管理テーブル１２０からそのリンクＩＤに対応する行を削除する。
【００４７】
ステップＳ６４では、バックアップ情報の追加リンク情報（図８（ｄ））から、各行の情報（リンクＩＤ及び親オブジェクトＩＤ、子オブジェクトＩＤ）を取り出し、これらを管理テーブル部１００の親子関係管理テーブル１２０に追加する。
【００４８】
ステップＳ６５では、バックアップ情報の変更オブジェクト情報（図８（ｅ））から、各行の情報、すなわち変更されたオブジェクトのＩＤと、そのオブジェクトの変更後の各種属性情報、を取り出す。そして、取り出した情報を、管理テーブル部１００の属性情報管理テーブル１１０における同一オブジェクトＩＤの行に上書きすることにより、変更内容を反映させる。
【００４９】
ステップＳ６６では、バックアップ情報の中の削除画像情報（図８（ｆ））から保管先ＩＤを取り出し、管理テーブル部１００の画像データ保管先管理テーブル１３０からその保管先ＩＤに対応する行を削除する。更にこのとき、それら保管先ＩＤの行にある「データファイル名」に示される画像データのファイルをデータベース１００から削除する。
【００５０】
ステップＳ６７では、バックアップ情報の追加画像情報（図８（ｇ））から、各行の情報（リンクＩＤ及び親オブジェクトＩＤ、子オブジェクトＩＤ）を取り出し、これらを管理テーブル部１００の画像データ保管先管理テーブル１３０に追加する。更にこのとき、追加した保管先ＩＤに対応づけてバックアップしていた画像データを、その保管先ＩＤの行の「データファイル名」に示された格納場所に格納する。
【００５１】
以上のＳ６１〜Ｓ６７の処理により、バックアップ１回の間のデータベース１０の変化分が復旧される。なお、Ｓ６１〜Ｓ６７のステップはどのような順に実行してもよい。
【００５２】
次に、リストア処理部５０は、ステップＳ６８で、バックアップ情報保管部４０を調べ、未処理のバックアップ情報があるか否かを判定する。未処理のものがあれば、Ｓ６０に戻って次の未処理のバックアップ情報を取り出し、Ｓ６１以降の処理を行う。このような処理を繰り返し、Ｓ６８で未処理のバックアップ情報がなくなったと判定されると、一連のリストア処理が完了する。これにより、データベース１０は、障害発生直前のバックアップタイミングの状態まで復旧される。
【００５３】
なお、ここでは、障害発生直前の状態まで復旧する場合を例示したが、図９に示した処理の繰り返しを任意の時点でやめることにより、任意のバックアップタイミングの状態までの復旧も可能である。この場合、リストア処理部５０には、どのバックアップタイミングまでの復旧を行うか、ユーザから指示を受け付ける機構を設ければよい。
【００５４】
以上説明したように、本実施形態では、バックアップ処理は、各バックアップタイミングごとに間欠的に行われる。従来方式では、データベースに対して追加、削除などの操作が行われるごとにバックアップをしていたので、そのような追加等のデータベース操作自体のパフォーマンスが低下していた。これに対し、本実施形態では、バックアップ処理の頻度はデータベース操作の頻度よりもはるかに少なく設定できるので、バックアップ処理によるデータベース処理のパフォーマンス低下を極力抑えることができる。また、本実施形態では、バックアップのために個々のデータベース操作を記憶しておく必要がないので、バックアップのデータ量を従来より削減できる。また、リストアの際も、個々のデータベース操作を時系列順に反映させていくという煩雑な処理が要らないので、リストア処理が高速化できる。
【００５５】
なお、以上の実施形態では、所定の時間間隔ごとにバックアップ処理を行う場合を例示したが、本発明はこのような場合に限定されない。
【００５６】
例えば、データベース１０に対して行われる操作の頻度をバックアップ処理部３０等でモニタし、その操作頻度に応じてバックアップ処理の間隔を変えたり、バックアップタイミングを決定したりすることも好適である。
【００５７】
この方式の一つとして、データベース１０への操作の頻度が高くなるほど、バックアップ間隔を小さくするという方式が好適である。実施形態の方式では、最新のバックアップ以降の変化はバックアップしていないので、データベースが頻繁に更新されているときに障害が発生すると、失われてしまうデータベース操作内容が多くなる。そこで、操作頻度が高くなるほどバックアップ間隔を小さくすることにより、障害等により失われるデータを少なくすることができる。なお、この方式のバリエーションとして、所定のデータベース操作回数ごとに、前述のバックアップ処理を行う方式も考えられる。この方式でも、バックアップ間隔を操作頻度に追従させることができる。
【００５８】
また、別の方式として、比較的長時間（例えば数日から数ヶ月など）にわたる操作頻度の時系列的な推移のデータを採取し、そのデータに基づき、データベース１０に対する操作頻度が少ない時間帯を統計的に求め、その時間帯にバックアップタイミングを自動設定する方式も好適である。この方式によれば、バックアップ処理による通常データベース操作のパフォーマンス低下の影響を小さくすることができる。
【００５９】
また、以上の実施形態では、バックアップ処理は、前回のバックアップタイミングと今回のバックアップタイミングとの差分情報をバックアップ情報として、順次バックアップ情報保管部４０に蓄積するようにしているが、これ以外に、毎回、最初の時点（すなわち基準時点）との差分を取るという方式も可能である。すなわち、この方式では、基準時点の管理テーブル部１００のコピーをスナップショット情報記憶部２０に保持しておき、バックアップタイミングのたびに、管理テーブル部１００とその基準時点のスナップショット情報を比較して、その差分についての情報を前述の同様の形でバックアップ情報保管部４０に蓄積する。この方式では、バックアップ処理の際、バックアップ情報保管部４０にある前回の作成したバックアップ情報を破棄し、今回作成したバックアップ情報を上書きしても差し支えない。もちろん、記憶容量が許すなら、毎回のバックアップ情報を併存させておくことも可能である。復旧の際には、バックアップ情報を、基準時点のデータベース内容に反映させればよい。上記実施形態では、復旧処理の際、基準時点のデータベースに対して何回分かのバックアップ情報を順次適用していく必要があったが、この方式では、基準時点のデータベースに１つのバックアップ情報を適用するだけで所望の時点の状態までデータベースを復旧できる。なお、この方式にも、上述した操作頻度に基づくバックアップタイミングの制御を適用可能である。
【図面の簡単な説明】
【図１】 本発明に係るデータベースシステムのバックアップ処理に関する構成を示す図である。
【図２】 本発明に係るデータベースシステムのリストア（復旧）処理に関する構成を示す図である。
【図３】 管理テーブル部の各テーブルのデータ内容を示す図である。
【図４】 実施形態におけるバックアップ処理の手順を示す図である。
【図５】 データベースから削除されたオブジェクトについてのバックアップ処理手順を示す図である。
【図６】 データベースに追加されたオブジェクトについてのバックアップ処理手順を示す図である。
【図７】 変更されたオブジェクトについてのバックアップ処理手順を示す図である。
【図８】 バックアップ処理において作成される各種情報のデータ内容を示す図である。
【図９】 リストアの指示が入力された場合のリストア処理部５０の処理手順を示すフローチャートである。
【図１０】 削除されたオブジェクトに関するリストア処理手順を示す図である。
【符号の説明】
１０ データベース、２０ スナップショット情報記憶部、３０ バックアップ処理部、４０ バックアップ情報保管部、５０ リストア処理部、１００ 管理テーブル部、１１０ 属性情報管理テーブル、１２０ 親子関係管理テーブル、１３０ 画像データ保管先管理テーブル。
【発明の属する技術分野】
本発明は、データベースのバックアップ技術に関する。
【０００２】
【従来の技術】
データベースのバックアップ方式として、従来より差分バックアップ方式が用いられている。例えば従来のファイリング装置における差分バックアップ処理では、データベース（ファイルシステム）の内容に変化が生じる操作が行われたとき、その操作の内容をバックアップ情報として記録していた。例えば、データベース内容に変化が生じるのはファイルやディレクトリの追加、削除、その内容の変更などの操作が行われたときであり、そのような操作が確定された場合にのみ操作内容をバックアップするのが一般的である。差分バックアップは、データベースの内容全体をバックアップ（フルバックアップと呼ぶ）した時点から開始する。差分バックアップ情報は、データベースとは別の記憶媒体に保管され、障害が起こった場合などには、そのバックアップ情報を用いて復旧処理を行う。
【０００３】
復旧処理では、バックアップ情報に表された操作内容を時系列順に読み出し、前回のフルバックアップデータに対して時系列順にそれら操作を適用していくことにより、障害発生直前のデータベースイメージを再生する。
【０００４】
【発明が解決しようとする課題】
しかしながら、このような従来の差分バックアップ方式では、次のような問題が生じる。
【０００５】
まず、従来方式では、個々の操作内容の情報をそのまま保存する必要があるため、差分バックアップ処理を行っている間は、データベースシステムの処理速度が低下する。例えば、画像ファイルなどを追加する場合、「追加」という操作コードの他にその画像ファイル自体をバックアップ用の媒体にコピーするなどの処理が必要となるため処理に時間を要し、参照や追加、削除などデータベース本来のサービスの効率が落ちてしまうおそれがあった。
【０００６】
また従来方式では、差分バックアップ情報からデータベース復旧を行う際、操作内容の時系列を順に適用していく必要があるため、多大の処理時間を要するという問題があった。
【０００７】
本発明は、このような問題に鑑みなされたものであり、通常のサービス処理の効率をできるだけ落とさないよう、バックアップ処理の負荷を低減することのできるデータベース管理装置を提供することを目的とする。また、本発明は、障害の復旧に要する処理の時間を従来より低減できるデータベース管理装置を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するため、本発明に係るデータベース管理装置は、データベースに登録された各オブジェクトの実体データに関して、当該実体データの格納場所の情報を含む当該オブジェクトの管理情報を保持する管理テーブルと、前記データベースに対して行われた操作に応じて前記管理テーブルを更新する手段と、所定のバックアップタイミングごとに、その時点での前記管理テーブルの内容のコピーをスナップショット情報として保存するスナップショット手段と、前記バックアップタイミングごとに、その時点での前記管理テーブルの内容と前回バックアップタイミングに作成された前記スナップショット情報との間で各オブジェクトの実体データの格納場所の情報を比較することにより、前回から今回までの間で前記データベースに追加されたオブジェクトの実体データの有無を判定し、前記データベースに追加されたオブジェクトの実体データがあると判定された場合は、前記管理テーブルにおける当該追加されたオブジェクトの実体データの格納場所の情報に基づき、当該追加されたオブジェクトの実体データをバックアップするバックアップ手段とを備える。
【０００９】
また本発明に係るデータベース管理装置は、データベースに登録された各オブジェクトの実体データに関して、当該実体データの格納場所の情報を含む当該オブジェクトの管理情報を保持する管理テーブルと、所定の基準時点での前記データベースの前記管理テーブルの内容を記憶する手段と、前記データベースに対して行われた操作に応じて前記管理テーブルを更新する手段と、所定のバックアップタイミングにおいて、前記管理テーブルの内容と前記基準時点での前記管理テーブルの内容との間で各オブジェクトの実体データの格納場所の情報を比較することにより、前記基準時点から現時点までの間で前記データベースに追加されたオブジェクトの実体データの有無を判定し、前記データベースに追加されたオブジェクトの実体データがあると判定された場合は、前記管理テーブルにおける当該追加されたオブジェクトの実体データの格納場所の情報に基づき、当該追加されたオブジェクトの実体データをバックアップするバックアップ手段とを備える。
【００１０】
本発明では、データベースに対する操作の度にバックアップ処理を行う必要がないので、通常のデータベース処理の効率の低下を抑えることができる。また、リストアの際も、個々のデータベース操作を時系列順に反映させていくという煩雑な処理が要らないので、リストア処理が高速化できる。
【００１１】
好適な態様では、データベース管理装置は、前記データベースに対して行われる操作の頻度をモニタする手段と、前記バックアップ手段における前記バックアップタイミングを、前記操作の頻度に応じて自動設定するタイミング設定手段とを備える。
【００１２】
この態様によれば、バックアップタイミングをデータベース操作頻度に応じて決定できるため、データベースの使用状況に応じた適切なタイミングでバックアップ処理を実行することができる。
【００１３】
【発明の実施の形態】
以下、本発明の実施の形態（以下実施形態という）について、図面に基づいて説明する。
【００１４】
図１は、本発明に係るデータベースシステムの要部構成を示す図であり、特にバックアップ処理に関する構成を示したものである。以下では、オブジェクト群を階層構造を用いて管理するファイリングサービス機能を備えたシステムを例にとって説明する。
【００１５】
データベース１０は、管理対象の各種オブジェクトのデータを保持している。オブジェクトは、例えばファイルやディレクトリなどであり、オブジェクト間に親子関係が存在する。データベース１０は、個々のオブジェクトの実体データのファイルに加え、各オブジェクトの管理情報を保持する管理テーブル部１００を備えている。
【００１６】
管理テーブル部１００は、属性情報管理テーブル１１０、親子関係管理テーブル１２０、及び画像データ保管先管理テーブル１３０の３種のテーブルを備える。これら各テーブルで管理するデータ項目の例を図３に示す。この例では、設計部門での図面の画像データの管理の場合を例にとる。したがって、データベースで管理されるオブジェクトは、図面の画像データのファイルや、それらファイルを収容するためのディレクトリ（フォルダ）などである。
【００１７】
まず属性情報管理テーブル１１０は、データベース１０に登録されている個々のオブジェクトの属性情報を保持、管理するテーブルである。このテーブル１１０は、図３（ａ）に示すように、各オブジェクトごとに、オブジェクトＩＤ、オブジェクト名、更新日時、補助的な属性情報（「属性１」、「属性２」）の各データ項目を保持する。オブジェクトＩＤは、データベース１０が当該オブジェクトに対して付与した一意な識別情報である。オブジェクト名は、ユーザがそのオブジェクトに与えたファイル名やディレクトリ名などの名称である。更新日時は、そのオブジェクトが新たにデータベース１０に登録された時や、既登録のそのオブジェクトについて更新が加えられた時の日時、時刻を示し、更新が行われる度にその値は変更されていく。補助的な属性情報である「属性１」、「属性２」は、ユーザ側が自由に定義して利用できるデータ項目である。図３の例では、「属性１」は当該オブジェクト（図面画像ファイル又はディレクトリ）が関連する部品（例えばその図面が表す部品）の名前を、「属性２」は当該オブジェクトが関連する部門（例えばその図面やフォルダを所有する設計部門）の名前を、それぞれ示している。
【００１８】
親子関係管理テーブル１２０は、データベース１０に登録されているオブジェクト間の親子関係の管理のためのテーブルである。この例では、オブジェクト群の階層構造を、２オブジェクト間の親子関係の集まりとして管理している。このテーブル１２０は、図３（ｂ）に示すように、個々の親子関係ごとに、リンクＩＤ、親オブジェクトＩＤ、及び子オブジェクトＩＤの各項目を保持している。リンクＩＤは、データベース１０が当該親子関係に対して付与した一意的な識別情報である。親オブジェクトＩＤは、その親子関係における親（すなわち上位）のオブジェクトのオブジェクトＩＤである。子オブジェクトＩＤは、その親子関係における子（すなわち下位）のオブジェクトのオブジェクトＩＤである。図の例では、リンクＩＤ“１”の親子関係は、オブジェクトＩＤ“０００２”を持つオブジェクト「見取り図」がオブジェクトＩＤ“０００１”のオブジェクト「フォルダー」の子になっていることを示している。
【００１９】
画像データ保管先管理テーブル１３０は、個々のオブジェクトの実体データの保管先の情報を保持、管理するテーブルである。テーブル１３０には、図３（ｃ）に示すように、図面画像データを表す各オブジェクトごとに、そのオブジェクトのオブジェクトＩＤと、その画像データのデータファイル名とがペアになり、そのペアに対して一意的な「保管先ＩＤ」が付与されている。データファイル名は、その画像データのファイルの格納場所も含めたパス、あるいはネットワークアドレスなどの形で記述される。なお、ディレクトリなど、画像データファイルではないオブジェクトについては、当然ながらこの保管先管理テーブル１３０には管理情報が登録されない。
【００２０】
以上、管理テーブル部１００について説明した。ここで再び図１を参照し、本システムの残りの構成要素について説明する。
【００２１】
スナップショット情報記憶部２０は、ある時点での管理テーブル部１００のコピー（以下、スナップショット情報と呼ぶ）を記憶する記憶手段である。
【００２２】
バックアップ処理部３０は、データベース１０のバックアップに関する処理を行う手段である。本実施形態では、バックアップ処理部３０は、所定のバックアップタイミングごとに、その時点での管理テーブル部１００の内容と、スナップショット情報記憶部２０に記憶した前回のバックアップタイミングにおける管理テーブル部１００のスナップショット情報とを比較し、その比較に基づき、前回バックアップタイミングから現時点までの間のデータベース１００の変化を抽出する。そして、その変化内容を示すバックアップ情報を作成し、バックアップ情報保管部４０に保管する。また、バックアップ処理部３０は、バックアップ情報の作成・保管の後、その時点の管理テーブル１００のスナップショット情報を作成し、スナップショット情報記憶部２０に記憶する。このとき、前回のスナップショット情報に対して上書きを行うことにより、スナップショット情報記憶部２０の容量を節約できる。
【００２３】
バックアップタイミングは、例えば、システム管理者が予め設定したバックアップ間隔ごとなど、所定の規則に従って決定される。
【００２４】
バックアップ情報保管部４０には、各バックアップタイミングにて作成されたバックアップ情報が、時系列的な順序が認識可能な態様で保管される。障害復旧時には、このバックアップ情報保管部４０に保管されたバックアップ情報を用いてデータベース１０の復旧（リストア）が行われる。
【００２５】
図２は、本データベースシステムの障害復旧処理時の構成を示している。この構成において、リストア処理部５０は、データベース１０の復旧処理を行う手段であり、バックアップ情報保管部４０に保管された各バックアップ情報に示されるデータベース１０の変化内容を、時系列順にデータベース１０に適用していくことにより、データベース１０を復旧する。なお、この復旧処理のため、バックアップ処理部３０によるバックアップ処理を開始する時点（基準時点と呼ぶ）で、データベース１０のフルバックアップが行われ、データベース１０全体のコピーが保存されている。復旧処理は、このフルバックアップ時のコピーを基準に実行される。
【００２６】
次に、図４を参照して、本実施形態のシステムにおけるバックアップ処理について説明する。図４は、バックアップタイミングが到来したときのバックアップ処理部３０の処理手順を示すフローチャートである。所定の時間間隔（例えば１時間、１日など）ごとにバックアップを行うようシステムを設定した場合、システムは、前回のバックアップタイミングからその所定時間間隔が経過したとき、バックアップタイミングが到来したと判定して図４の処理を開始する。
【００２７】
ステップＳ１では、バックアップ処理部３０は、前回バックアップタイミングから現時点までの間にデータベース１０から削除されたオブジェクトを確定し、それらオブジェクトが削除された旨の情報をバックアップ情報保管部４０に登録する。この処理の詳細な手順を図５に示す。
【００２８】
図５に示すように、Ｓ１の処理では、まずスナップショット情報記憶部２０に記憶されたスナップショット情報中の属性情報管理テーブルから、そのテーブル中に含まれるオブジェクトＩＤ群を取得する（Ｓ１１）。これらは、前回のバックアップタイミングの時点でデータベース１０に登録されていた各オブジェクトのＩＤである。次に、このようにして取得した各オブジェクトＩＤをそれぞれ順に検索対象に選び、そのＩＤが管理テーブル部１００の属性情報管理テーブル１１０に存在するか否か検索する（Ｓ１２）。存在すれば、そのＩＤに該当するオブジェクトは現時点でもデータベース１０に登録されているということなので、ここではなにもしない。これに対し、Ｓ１２の判定結果がＮ（否定）の場合、そのオブジェクトＩＤに該当するオブジェクトは前回バックアップタイミングではデータベース１０に登録されていたが、今回の時点では登録されていないということになり、そのオブジェクトが前回から今回までの間に削除されたと判断できる。この場合、そのオブジェクトＩＤを、削除オブジェクト情報としてバックアップ情報保管部４０に保管する（Ｓ１３）。そして、Ｓ１１で取得した全オブジェクトＩＤについてＳ１２（及びＳ１３）の処理を繰り返す（Ｓ１４）。
【００２９】
このようにして作成された削除オブジェクト情報の例を図８（ａ）に示す。この図に示すように、削除オブジェクト情報は、前回のバックアップタイミングから現時点までの間にデータベース１０から削除されたオブジェクトのＩＤのリストとなる。
【００３０】
ステップＳ２では、前回バックアップタイミングから現時点までの間にデータベース１０に新たに追加されたオブジェクトを確定し、それらオブジェクトが追加された旨の情報をバックアップ情報保管部４０に登録する。Ｓ２の処理の詳細な手順を図６に示す。
【００３１】
Ｓ２の処理では、まず管理テーブル部１００の属性情報管理テーブル１１０から、そのテーブル中に含まれるオブジェクトＩＤ群を取得する（Ｓ２１）。これらは、現時点においてデータベース１０に登録されている各オブジェクトのＩＤである。次に、このようにして取得した各オブジェクトＩＤについて順番に、そのＩＤがスナップショット情報記憶部２０に記憶された前回バックアップタイミングの属性情報管理テーブルの中に存在するか否かを調べる（Ｓ２２）。存在すれば、（現在データベース１０中に存在する）そのＩＤに該当するオブジェクトは、前回バックアップタイミング現時点でもデータベース１０に登録されていたということなので、ここではなにもしない。これに対し、Ｓ２２の判定結果がＮ（否定）の場合、そのオブジェクトＩＤに該当するオブジェクトは、前回バックアップタイミングではデータベース１０に登録されていなかったが、今回の時点では登録されているということになり、そのオブジェクトが前回から今回までの間に追加されたと判断できる。この場合、そのオブジェクトＩＤに対応する一連の属性情報を属性情報管理テーブル１１０から取得し、追加オブジェクト情報としてバックアップ情報保管部４０に保管する（Ｓ２３）。そして、Ｓ２１で取得した全オブジェクトＩＤについてＳ２２（及びＳ２３）の処理を繰り返す（Ｓ２４）。
【００３２】
このようにして作成された追加オブジェクト情報の例を図８（ｂ）に示す。この図に示すように、追加オブジェクト情報は、前回のバックアップタイミングから現時点までにデータベース１０に新たに追加された各オブジェクトごとに、属性情報管理テーブル１１０に登録された情報（オブジェクトＩＤと、オブジェクト名や更新日時など）を列挙したものとなっている。
【００３３】
ステップ３では、前回バックアップタイミングから現時点までの間に、データベース１０から削除された親子関係を確定し、それら親子関係が削除された旨の情報をバックアップ情報保管部４０に登録する。この処理は、オブジェクトの削除の場合のバックアップ処理（Ｓ１：図５）と同様に行えばよい。すなわち、スナップショット情報記憶部２０に登録されていて、現在の管理テーブル部１００の親子関係管理テーブル１２０に存在しないリンクＩＤを求め、そのようなリンクＩＤを削除リンク情報としてバックアップ情報保管部４０に登録する。このようにして作成された削除リンク情報の例を図８（ｃ）に示す。削除リンク情報は、前回バックアップタイミングから現時点までの間に削除された親子関係のリンクＩＤのリストである。
【００３４】
ステップ４では、前回バックアップタイミングから現時点までの間に、データベース１０に新たに追加された親子関係を確定し、それら親子関係が追加された旨の情報をバックアップ情報保管部４０に登録する。この処理は、オブジェクトの追加の場合のバックアップ処理（Ｓ２：図６）と同様に行えばよい。すなわち、現在の管理テーブル部１００の親子関係管理テーブル１２０に登録されていて、スナップショット情報記憶部２０に存在しないリンクＩＤを求め、そのようなリンクＩＤと、それに対応する親子関係管理テーブル１２０の情報（親オブジェクトＩＤ及び子オブジェクトＩＤ）との組を、追加リンク情報としてバックアップ情報保管部４０に登録する。このようにして作成された追加リンク情報の例を図８（ｄ）に示す。
【００３５】
ステップ５では、前回バックアップタイミングから現時点までの間に、内容に変更が加えられたオブジェクトを確定し、それらオブジェクトが変更された旨の情報をバックアップ情報保管部４０に登録する。この処理の詳細な手順を図７に示す。
【００３６】
図７の処理では、まず管理テーブル部１００の属性情報管理テーブル１１０から、そのテーブル中に含まれるオブジェクトＩＤ群を取得する（Ｓ５１）。次に、このようにして取得した各オブジェクトＩＤについて順番に、そのＩＤがスナップショット情報記憶部２０に記憶された前回バックアップタイミングの属性情報管理テーブルの中に存在するか否かを調べる（Ｓ５２）。存在しない場合、ここではなにもしない。
【００３７】
これに対し、Ｓ５２の判定結果がＹ（肯定）、すなわち当該オブジェクトＩＤがスナップショット情報中に存在していた場合、次に当該オブジェクトＩＤに対応する「更新日時」を、属性情報管理テーブル１１０とスナップショット情報の双方から求め、それら両者が一致するかどうか判定する（Ｓ５３）。「更新日時」はオブジェクトの更新があると変わるものなので、それら両者が一致していた場合、それは当該オブジェクトは前回バックアップタイミングから現時点までに更新されていないことを意味する。したがって、Ｓ５３で双方の更新日時が一致したと判定された場合は、何も行わない。それに対し、Ｓ５３にて双方の更新日時が一致しないと判定された場合、当該オブジェクトＩＤに対応するオブジェクトは変更されたと判断でき、そのオブジェクトＩＤに対応する一連の属性情報を属性情報管理テーブル１１０から取得し、変更オブジェクト情報としてバックアップ情報保管部４０に保管する（Ｓ５４）。そして、Ｓ５１で取得した全オブジェクトＩＤについてＳ５２〜Ｓ５４の処理を繰り返す（Ｓ５５）。
【００３８】
このようにして作成された変更オブジェクト情報の例を図８（ｅ）に示す。この図に示すように、変更オブジェクト情報は、前回のバックアップタイミングから現時点までに更新の行われたオブジェクトごとに、そのオブジェクトについての、属性情報管理テーブル１１０に登録された情報（オブジェクトＩＤと、オブジェクト名や更新日時など）を列挙したものとなっている。
【００３９】
ステップＳ６では、前回バックアップタイミングから今回までの間に、データベース１０から削除された図面画像データ（すなわち、オブジェクトの実体データ）を確定し、その画像データが削除された旨の情報をバックアップ情報保管部４０に登録する。この処理は、オブジェクトの削除の場合のバックアップ処理（Ｓ１：図５）と同様に行えばよい。すなわち、まずスナップショット情報記憶部２０の前回タイミングの画像データ保管先管理テーブルには存在するが管理テーブル部１００の画像データ保管先管理テーブル１３０には存在しない保管先ＩＤを求め、その保管先ＩＤとこれに対応するオブジェクトＩＤ及びデータファイル名をスナップショット情報記憶部２０のから求め、これら情報の組を削除画像情報としてバックアップ情報保管部４０に登録する。このようにして作成された削除画像情報の例を図８（ｆ）に示す。
【００４０】
ステップＳ７では、前回バックアップタイミングから今回までの間に、データベース１０に新規追加された図面画像データを確定し、その画像データの追加を示す情報をバックアップ情報保管部４０に登録する。この処理は、オブジェクトの追加の場合のバックアップ処理（Ｓ２：図６）と同様でよい。すなわち、管理テーブル部１００の画像データ保管先管理テーブル１３０に存在するがスナップショット情報記憶部２０には存在しない保管先ＩＤを求め、その保管先ＩＤとこれに対応するオブジェクトＩＤ及びデータファイル名を、画像データ保管先管理テーブル１３０から求め、これら情報の組を追加画像情報としてバックアップ情報保管部４０に登録する。このようにして作成された削除画像情報の例を図８（ｇ）に示す。また、このとき、その保管先ＩＤに対応するデータファイル名が示す格納場所から図面画像データを取得し、バックアップ情報保管部４０に保存する。このとき、保存する画像データは、追加画像情報（図８（ｇ））の例えばオブジェクトＩＤをファイル名に組み込むなどの形で、追加画像情報との関連付けができるようにしておく。
【００４１】
以上の処理により、前回バックアップタイミングと今回との間でのデータベース１０の変化内容（すなわち差分）を表す情報がバックアップ情報保管部４０にに蓄積される。以上に示した図８（ａ）〜（ｇ）の各情報は、当該バックアップタイミングのものとして相互に関連付けられ、このバックタイミングの時刻情報と対応づけてバックアップ情報保管部４０に保存される。このような差分情報（バックアップ情報）の蓄積が完了すると、バックアップ処理部３０は、ステップ８にて、現時点の管理テーブル部１００の内容をスナップショット情報記憶部２０にコピーし、スナップショット情報を更新する。なお、図４では、ステップＳ１〜Ｓ７について１つの順序を示したが、これら各ステップは基本的には相互に独立しているので、どのような順に実行してもよい。
【００４２】
以上、バックアップ処理の手順について説明した。次に、システム障害解消時等に行うリストア（復旧）処理の手順を説明する。リストア処理は、基本的にはバックアップ処理と逆の手順を踏めばよい。以下、リストア処理の手順を図９を参照して説明する。図９は、リストアの指示が入力された場合の本システムのリストア処理部５０の処理手順を示すフローチャートである。
【００４３】
リストア処理を行う時点では、データベース１０は、管理テーブル部１００も含め、基準時点（すなわちバックアップ処理開始時点）のフルバックアップ状態の内容となっている。この状態でリストア指示が入力された場合、まずステップＳ６０で、リストア処理部５０は、バックアップ情報保管部４０から、最も古いバックアップ情報（差分情報）を取得する。取得されるバックアップ情報は、図８に示すような各情報を含んでいる。
【００４４】
ステップＳ６１では、Ｓ６０で取得したバックアップ情報の中の削除オブジェクト情報（図８（ａ）参照）から、オブジェクトＩＤを取り出し、管理テーブル部１００の属性情報管理テーブル１１０からそのオブジェクトＩＤに対応する行を削除する。図１０に、このＳ６１の詳細な手順を示す。図１０に示すように、Ｓ６１では、まず削除オブジェクト情報からオブジェクトＩＤをすべて取得する（Ｓ７１）。次に、取得した各オブジェクトＩＤをそれぞれ順に検索対象に選び、そのＩＤが管理テーブル部１００の属性情報管理テーブル１１０に存在するか否か検索する（Ｓ７２）。存在すれば、そのオブジェクトＩＤの行の属性情報を削除する（Ｓ７３）。Ｓ７２の結果がＮ（否定）ならば、何も行わない。そして、Ｓ７１で取得した全オブジェクトＩＤについてＳ７２及びＳ７３の処理を繰り返す（Ｓ７４）。
【００４５】
ステップＳ６２では、バックアップ情報の追加オブジェクト情報（図８（ｂ））から、各追加オブジェクトのオブジェクトＩＤとこれに対応する属性情報（オブジェクト名など）を取り出し、これらを管理テーブル部１００の属性情報管理テーブル１１０に追加する。
【００４６】
ステップＳ６３では、バックアップ情報の中の削除リンク情報（図８（ｃ））からリンクＩＤを取り出し、管理テーブル部１００の親子関係管理テーブル１２０からそのリンクＩＤに対応する行を削除する。
【００４７】
ステップＳ６４では、バックアップ情報の追加リンク情報（図８（ｄ））から、各行の情報（リンクＩＤ及び親オブジェクトＩＤ、子オブジェクトＩＤ）を取り出し、これらを管理テーブル部１００の親子関係管理テーブル１２０に追加する。
【００４８】
ステップＳ６５では、バックアップ情報の変更オブジェクト情報（図８（ｅ））から、各行の情報、すなわち変更されたオブジェクトのＩＤと、そのオブジェクトの変更後の各種属性情報、を取り出す。そして、取り出した情報を、管理テーブル部１００の属性情報管理テーブル１１０における同一オブジェクトＩＤの行に上書きすることにより、変更内容を反映させる。
【００４９】
ステップＳ６６では、バックアップ情報の中の削除画像情報（図８（ｆ））から保管先ＩＤを取り出し、管理テーブル部１００の画像データ保管先管理テーブル１３０からその保管先ＩＤに対応する行を削除する。更にこのとき、それら保管先ＩＤの行にある「データファイル名」に示される画像データのファイルをデータベース１００から削除する。
【００５０】
ステップＳ６７では、バックアップ情報の追加画像情報（図８（ｇ））から、各行の情報（リンクＩＤ及び親オブジェクトＩＤ、子オブジェクトＩＤ）を取り出し、これらを管理テーブル部１００の画像データ保管先管理テーブル１３０に追加する。更にこのとき、追加した保管先ＩＤに対応づけてバックアップしていた画像データを、その保管先ＩＤの行の「データファイル名」に示された格納場所に格納する。
【００５１】
以上のＳ６１〜Ｓ６７の処理により、バックアップ１回の間のデータベース１０の変化分が復旧される。なお、Ｓ６１〜Ｓ６７のステップはどのような順に実行してもよい。
【００５２】
次に、リストア処理部５０は、ステップＳ６８で、バックアップ情報保管部４０を調べ、未処理のバックアップ情報があるか否かを判定する。未処理のものがあれば、Ｓ６０に戻って次の未処理のバックアップ情報を取り出し、Ｓ６１以降の処理を行う。このような処理を繰り返し、Ｓ６８で未処理のバックアップ情報がなくなったと判定されると、一連のリストア処理が完了する。これにより、データベース１０は、障害発生直前のバックアップタイミングの状態まで復旧される。
【００５３】
なお、ここでは、障害発生直前の状態まで復旧する場合を例示したが、図９に示した処理の繰り返しを任意の時点でやめることにより、任意のバックアップタイミングの状態までの復旧も可能である。この場合、リストア処理部５０には、どのバックアップタイミングまでの復旧を行うか、ユーザから指示を受け付ける機構を設ければよい。
【００５４】
以上説明したように、本実施形態では、バックアップ処理は、各バックアップタイミングごとに間欠的に行われる。従来方式では、データベースに対して追加、削除などの操作が行われるごとにバックアップをしていたので、そのような追加等のデータベース操作自体のパフォーマンスが低下していた。これに対し、本実施形態では、バックアップ処理の頻度はデータベース操作の頻度よりもはるかに少なく設定できるので、バックアップ処理によるデータベース処理のパフォーマンス低下を極力抑えることができる。また、本実施形態では、バックアップのために個々のデータベース操作を記憶しておく必要がないので、バックアップのデータ量を従来より削減できる。また、リストアの際も、個々のデータベース操作を時系列順に反映させていくという煩雑な処理が要らないので、リストア処理が高速化できる。
【００５５】
なお、以上の実施形態では、所定の時間間隔ごとにバックアップ処理を行う場合を例示したが、本発明はこのような場合に限定されない。
【００５６】
例えば、データベース１０に対して行われる操作の頻度をバックアップ処理部３０等でモニタし、その操作頻度に応じてバックアップ処理の間隔を変えたり、バックアップタイミングを決定したりすることも好適である。
【００５７】
この方式の一つとして、データベース１０への操作の頻度が高くなるほど、バックアップ間隔を小さくするという方式が好適である。実施形態の方式では、最新のバックアップ以降の変化はバックアップしていないので、データベースが頻繁に更新されているときに障害が発生すると、失われてしまうデータベース操作内容が多くなる。そこで、操作頻度が高くなるほどバックアップ間隔を小さくすることにより、障害等により失われるデータを少なくすることができる。なお、この方式のバリエーションとして、所定のデータベース操作回数ごとに、前述のバックアップ処理を行う方式も考えられる。この方式でも、バックアップ間隔を操作頻度に追従させることができる。
【００５８】
また、別の方式として、比較的長時間（例えば数日から数ヶ月など）にわたる操作頻度の時系列的な推移のデータを採取し、そのデータに基づき、データベース１０に対する操作頻度が少ない時間帯を統計的に求め、その時間帯にバックアップタイミングを自動設定する方式も好適である。この方式によれば、バックアップ処理による通常データベース操作のパフォーマンス低下の影響を小さくすることができる。
【００５９】
また、以上の実施形態では、バックアップ処理は、前回のバックアップタイミングと今回のバックアップタイミングとの差分情報をバックアップ情報として、順次バックアップ情報保管部４０に蓄積するようにしているが、これ以外に、毎回、最初の時点（すなわち基準時点）との差分を取るという方式も可能である。すなわち、この方式では、基準時点の管理テーブル部１００のコピーをスナップショット情報記憶部２０に保持しておき、バックアップタイミングのたびに、管理テーブル部１００とその基準時点のスナップショット情報を比較して、その差分についての情報を前述の同様の形でバックアップ情報保管部４０に蓄積する。この方式では、バックアップ処理の際、バックアップ情報保管部４０にある前回の作成したバックアップ情報を破棄し、今回作成したバックアップ情報を上書きしても差し支えない。もちろん、記憶容量が許すなら、毎回のバックアップ情報を併存させておくことも可能である。復旧の際には、バックアップ情報を、基準時点のデータベース内容に反映させればよい。上記実施形態では、復旧処理の際、基準時点のデータベースに対して何回分かのバックアップ情報を順次適用していく必要があったが、この方式では、基準時点のデータベースに１つのバックアップ情報を適用するだけで所望の時点の状態までデータベースを復旧できる。なお、この方式にも、上述した操作頻度に基づくバックアップタイミングの制御を適用可能である。
【図面の簡単な説明】
【図１】 本発明に係るデータベースシステムのバックアップ処理に関する構成を示す図である。
【図２】 本発明に係るデータベースシステムのリストア（復旧）処理に関する構成を示す図である。
【図３】 管理テーブル部の各テーブルのデータ内容を示す図である。
【図４】 実施形態におけるバックアップ処理の手順を示す図である。
【図５】 データベースから削除されたオブジェクトについてのバックアップ処理手順を示す図である。
【図６】 データベースに追加されたオブジェクトについてのバックアップ処理手順を示す図である。
【図７】 変更されたオブジェクトについてのバックアップ処理手順を示す図である。
【図８】 バックアップ処理において作成される各種情報のデータ内容を示す図である。
【図９】 リストアの指示が入力された場合のリストア処理部５０の処理手順を示すフローチャートである。
【図１０】 削除されたオブジェクトに関するリストア処理手順を示す図である。
【符号の説明】
１０ データベース、２０ スナップショット情報記憶部、３０ バックアップ処理部、４０ バックアップ情報保管部、５０ リストア処理部、１００ 管理テーブル部、１１０ 属性情報管理テーブル、１２０ 親子関係管理テーブル、１３０ 画像データ保管先管理テーブル。
Claims (7)
- データベースに登録された各オブジェクトの実体データに関して、当該実体データの格納場所の情報を含む当該オブジェクトの管理情報を保持する管理テーブルと、
前記データベースに対して行われた操作に応じて前記管理テーブルを更新する手段と、
所定のバックアップタイミングごとに、その時点での前記管理テーブルの内容のコピーをスナップショット情報として保存するスナップショット手段と、
前記バックアップタイミングごとに、その時点での前記管理テーブルの内容と前回バックアップタイミングに作成された前記スナップショット情報との間で各オブジェクトの実体データの格納場所の情報を比較することにより、前回から今回までの間で前記データベースに追加されたオブジェクトの実体データの有無を判定し、前記データベースに追加されたオブジェクトの実体データがあると判定された場合は、前記管理テーブルにおける当該追加されたオブジェクトの実体データの格納場所の情報に基づき、当該追加されたオブジェクトの実体データをバックアップするバックアップ手段と、
を備えるデータベース管理装置。 - 前記データベースの障害復旧時に、基準時点のデータベース内容に対し、前記バックアップ情報を作成順に適用していくことにより、障害前の前記データベースの内容を復元するリストア手段を更に含む、請求項１記載のデータベース管理装置。
- 前記スナップショット手段は、前記バックアップ手段によるバックアップ情報の作成が完了した後、その時点での前記管理テーブルの内容を前回バックアップタイミングのスナップショット情報に上書きすることを特徴とする請求項１記載のデータベース管理装置。
- データベースに登録された各オブジェクトの実体データに関して、当該実体データの格納場所の情報を含む当該オブジェクトの管理情報を保持する管理テーブルと、
所定の基準時点での前記データベースの前記管理テーブルの内容を記憶する手段と、
前記データベースに対して行われた操作に応じて前記管理テーブルを更新する手段と、
所定のバックアップタイミングにおいて、前記管理テーブルの内容と前記基準時点での前記管理テーブルの内容との間で各オブジェクトの実体データの格納場所の情報を比較することにより、前記基準時点から現時点までの間で前記データベースに追加されたオブジェクトの実体データの有無を判定し、前記データベースに追加されたオブジェクトの実体データがあると判定された場合は、前記管理テーブルにおける当該追加されたオブジェクトの実体データの格納場所の情報に基づき、当該追加されたオブジェクトの実体データをバックアップするバックアップ手段と、
を備えるデータベース管理装置。 - 前記データベースに対して行われる操作の頻度をモニタする手段と、
前記バックアップ手段における前記バックアップタイミングを、前記操作の頻度に応じて自動設定するタイミング設定手段と、
を備える請求項１から請求項４までのいずれかに記載のデータベース管理装置。 - 前記タイミング設定手段は、前記操作の頻度が高くなるほど前記バックアップタイミングの間隔を小さくすることを特徴とする請求項５記載のデータベース管理装置。
- 前記タイミング設定手段は、前記操作の頻度が低い時間帯を統計的に求め、この時間帯にバックアップタイミングを設定することを特徴とする請求項５記載のデータベース管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000166758A JP3985430B2 (ja) | 2000-06-02 | 2000-06-02 | データベース管理装置及び方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000166758A JP3985430B2 (ja) | 2000-06-02 | 2000-06-02 | データベース管理装置及び方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2001344139A JP2001344139A (ja) | 2001-12-14 |
| JP2001344139A5 JP2001344139A5 (ja) | 2005-01-20 |
| JP3985430B2 true JP3985430B2 (ja) | 2007-10-03 |
Family
ID=18670030
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000166758A Expired - Fee Related JP3985430B2 (ja) | 2000-06-02 | 2000-06-02 | データベース管理装置及び方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3985430B2 (ja) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004005222A (ja) | 2002-05-31 | 2004-01-08 | Internatl Business Mach Corp <Ibm> | 格納形式が異なる記録装置のためのバックアップ技術 |
| US9489150B2 (en) | 2003-08-14 | 2016-11-08 | Dell International L.L.C. | System and method for transferring data between different raid data storage types for current data and replay data |
| EP1668486A2 (en) | 2003-08-14 | 2006-06-14 | Compellent Technologies | Virtual disk drive system and method |
| EP2357552A1 (en) | 2006-05-24 | 2011-08-17 | Compellent Technologies | System and method for RAID management, reallocation and restriping |
| JP2008033585A (ja) * | 2006-07-28 | 2008-02-14 | Nec Corp | 差分バックアップシステム、差分バックアップ方法、差分バックアップ装置及び差分バックアッププログラム |
| WO2008120340A1 (ja) * | 2007-03-29 | 2008-10-09 | Fujitsu Limited | ストレージ制御プログラム、ストレージ制御方法およびストレージ制御装置 |
| US8468292B2 (en) | 2009-07-13 | 2013-06-18 | Compellent Technologies | Solid state drive data storage system and method |
| JP5039891B2 (ja) | 2009-10-19 | 2012-10-03 | インターナショナル・ビジネス・マシーンズ・コーポレーション | データベースの複製を生成する装置及び方法 |
| US9146851B2 (en) | 2012-03-26 | 2015-09-29 | Compellent Technologies | Single-level cell and multi-level cell hybrid solid state drive |
| JP5681667B2 (ja) * | 2012-05-29 | 2015-03-11 | 株式会社野村総合研究所 | データベース移行システム |
| WO2024128347A1 (ko) * | 2022-12-14 | 2024-06-20 | 스트라토 주식회사 | 머신러닝 장애 복구 장치 및 그 제어방법 |
-
2000
- 2000-06-02 JP JP2000166758A patent/JP3985430B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001344139A (ja) | 2001-12-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10891067B2 (en) | Fast migration of metadata | |
| US7536424B2 (en) | System and methods for efficiently managing incremental data backup revisions | |
| US8380672B2 (en) | Backup control apparatus and method eliminating duplication of information resources | |
| JP4261800B2 (ja) | クライアントサーバー環境における差分バックアップシステムの管理方法 | |
| JP5021929B2 (ja) | 計算機システム及びストレージシステムと管理計算機並びにバックアップ管理方法 | |
| JPH11306058A (ja) | 異なるデ―タファイル蓄積サイトを調停する方法及びデ―タ蓄積サイト及びそれと関連した一組のジャ―ナルファイルを含むシステム | |
| JP3985430B2 (ja) | データベース管理装置及び方法 | |
| EP3785120A1 (en) | Fast and optimized restore using delta information | |
| CN109753381B (zh) | 一种基于对象存储的持续数据保护方法 | |
| US10061654B1 (en) | Depth first search of summary change log records for backup | |
| CN116401220A (zh) | 文件系统的数据恢复方法、装置、设备及介质 | |
| JP2004157958A (ja) | 計算機システムおよびファイル管理方法 | |
| JPH07152627A (ja) | ファイルリカバリシステム | |
| JP2005316715A (ja) | 文書管理システムおよび方法およびプログラム | |
| JP2002116938A (ja) | 世代管理機能を備えたファイルバックアップ方法 | |
| JPH0844609A (ja) | データバックアップ方法 | |
| JP2002132561A (ja) | 差分バックアップ方法および装置 | |
| JP2000207264A (ja) | バックアップ方法およびリストア方法 | |
| JPH09274581A (ja) | データバックアップ方法 | |
| JP2002351719A (ja) | メールサーバのバックアップ・リカバリシステムおよび同方法 | |
| JP4026278B2 (ja) | データ保管システム | |
| JPH10133934A (ja) | 分散型文書管理システムおよびそれを実現するプログラム記憶媒体 | |
| JPH01140353A (ja) | データベースのデータ保全方式 | |
| CN115328864A (zh) | 被删除文件的管理方法、装置、设备和存储介质 | |
| JPH07219827A (ja) | ジャーナルファイルの分割管理方式およびジャーナルフ ァイルの分割管理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040220 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040220 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040220 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061024 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061213 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070619 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070702 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100720 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110720 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110720 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120720 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130720 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |