JP3027782B2 - データベース回復方式 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、例えば、データベース
の領域設定及び回復方式に係り、データベースの領域情
報に関してレコードが追加される前後にシステム障害は
発生してもデータベースの領域情報及びデータを論理的
に矛盾のない状態に回復できる方式に関する。

【０００２】

【従来の技術】複数のプログラムがデータベースの資源
を共通に利用して処理を実行する従来からのデータベー
ス処理システムは、コンピュータシステムが故障しシス
テムが停止したときデータベースに対してそれまでに行
われた更新操作が中断されるためにデータベースが不整
合（一貫性のない）な状態に陥る。このような状態から
一貫性のある状態に回復する場合、図４に示すような回
復管理システムによる回復方式があった。

【０００３】図４において、１はデータ処理の要求を行
う応用プログラム、２はデータ処理を行うデータベース
処理部、３はデータベースが格納されるディスク装置と
入出力するために使用するデータベースバッファ、４は
データベースから効率よくデータをアクセスするために
使用する索引、６はキー値とデータが１対１で対応する
ユニークなキー（データが一意に決まるキー）から構成
される主索引、７は主索引以外の索引でキー値の重複が
許される副索引、８はデータファイル、９はデータベー
スの更新履歴を採るジャーナルである。

【０００４】次に、図５は動作について説明したもので
ある。応用プログラム１がトランザクション開始を宣言
すると、データベース処理部２はＢｅｇｉｎ Ｔｒａｎ
ｓａｃｔｉｏｎ（Ｂ．Ｔ）をジャーナル９に採り、さら
に応用プログラム１がレコード追加命令（ＷＲＩＴＥ命
令）を発行すると、データベース処理部２は、データフ
ァイル８にレコードを追加するための位置（レコード番
号）と領域情報を得、追加位置には削除マークを書き、
また領域情報には領域情報の更新（ＥＯＦ１→ＥＯＦ
２）を行い、追加操作コードと追加データイメージ（更
新イメージ）をジャーナル９に採取し、さらに応用プロ
グラム１がトランザクション終了（コミット）を要求す
ると、データベース処理部２は追加データをデータベー
ス４に追加するために、主索引６に追加レコードの主キ
ーに相当するキー値及びレコード番号（追加レコード番
号）を登録し、次に追加レコードをデータファイル８の
追加レコード位置に書き込み、次に副索引７に該当キー
を登録し、最後にＥｎｄ Ｔｒａｎｓａｃｔｉｏｎ
（Ｅ．Ｔ）をジャーナル９に採ることにより、応用プロ
グラム１からの１つのトランザクションの要求が完結す
ることになる。

【０００５】ここで、追加レコード位置に削除マークを
書く理由は、トランザクション完結前、かつデータファ
イル８の領域情報が更新された後にコンピュータシステ
ムがダウンしても、ダウン後の再開で追加レコード位置
にデータが書かれていなくとも削除レコード扱いとする
ことができるので、論理的な矛盾を起こさないようにす
るためのものである。以上のように、従来のデータベー
ス回復方式は、データベースの更新履歴（ジャーナル）
を採り、各トランザクションで行われるべき更新操作が
完結していないトランザクションに関してそのトランザ
クションの更新を全て無効にする。

【０００６】

【発明が解決しようとする課題】従来のデータベース回
復方式は、データベースの整合性を保証するために、ジ
ャーナルを採ることは勿論であるが、万一のコンピュー
タシステムの故障時に発生し得る不整合な状態（例えば
索引とデータファイル（レコード）の関係に矛盾を引き
起こさないこと、及び領域情報に矛盾な状態を作り込ま
ないこと等）を回避するために、応用プログラムからの
データ更新操作に対して以下のような方式を採用してい
る。 （１）回復操作のために使用する主キーは、データレコ
ードがデータファイルに書かれるよりも前に主索引に登
録する。主キーのディスク装置への書き込みが完了する
のを待ってから、データレコードの書き込みを行う。こ
れはもし、データレコードを先に書き込んでから、主キ
ーを主索引に登録するようにすると、データレコードを
先に書き込んでから、主キーを主索引に登録する前にシ
ステムダウンが起きると、データはデータ部にあるのに
主索引からはそれがわからないため、回復作業により、
再び同一データを登録してしまうということを防ぐため
である。 （２）追加操作の場合、領域情報に変更が生じるため
に、追加レコード位置には削除マークを出力した後に領
域情報を更新する。このような従来の方式は、主キーと
データの登録順に制限があったり、ディスク装置への入
出力回数が通常のファイルアクセスに比べて多くなり、
実行時性能が悪くなるという問題を抱えている。

【０００７】この発明は、上記のような問題点を解消す
るためになされたもので、データベースへのデータ更新
操作に伴う上記問題を排除し、高速なデータベースアク
セスを提供するデータベース回復方式及びデータベース
設定方式を得ることを目的とする。

【０００８】

【課題を解決するための手段】この発明に係るデータベ
ース回復方式は、以下の要素を有するものである。 （ａ）索引部とデータ部を有するデータベースのデータ
部の各データ領域に対応してその領域にデータがないこ
とを示す識別子を設定する設定手段、 （ｂ）上記データベースを更新するアクセス手段、 （ｃ）上記アクセス手段によるデータベースの更新履歴
をジャーナルに記憶するジャーナル手段、 （ｄ）以下の要素を有しデータベースの回復処理をする
回復処理手段、（ｄ１）データベースの索引を再生成す
る索引生成手段、（ｄ２）上記ジャーナル手段により記
憶した更新履歴を用いて、データベースへの処理が終了
しているトランザクションに対しては、更新後の状態ま
で回復し、処理が終了していないトランザクションに対
しては、更新前の状態に回復する回復手段。

【０００９】また、この発明に係るデータベース設定方
式は、データ部の各データ領域に対応して、その領域に
データがないことを示す識別子をあらかじめ設定するも
のである。

【００１０】

【作用】この発明は、データベースのベースとなるファ
イルの定義時に割り当てられた領域の未使用部分を有効
データがその領域にないことを示す識別子（削除マー
ク）で初期化することにより、データベースに対する更
新操作において、領域情報の更新を出力完了待ちするこ
とや追加レコード位置に削除マークを書き込みすること
を不要とするので、高速アクセスすることを可能とした
ものである。

【００１１】

【実施例】

実施例１．この発明の一実施例を図について説明する。
図１において、２１はデータベースに対する各種データ
操作を行う応用プログラム、２２は一定時間ごとにデー
タベースバッファの更新データをディスクに書き込むチ
ェックポイントプログラム、２３は応用プログラムのデ
ータ操作を時系列に表現したもの、２４は各データ操作
に対するデータ処理を行うデータベース処理部、２５は
データベースバッファ、２６はデータベースの主索引
部、２７は副索引部、２８はデータベースのベースとな
るデータ部、２９はデータベース定義プログラム、ま
た、図２において、３０はジャーナルファイル、図３に
おいて、システムダウン後の回復処理を示すものであ
る。なお、ここで図１に示したＲｕａ、Ｒｗａ、Ｒｗｂ
はレコード（あるいはレコードナンバー）を意味し、応
用プログラムＡは、Ｒｕａを更新する命令とし、Ｒｗａ
を書き込む命令として実行するものとする。また応用プ
ログラムＢは、Ｒｗｂを書き込む命令を実行するものと
する。

【００１２】データベースを使用する前にデータベース
定義プログラム２９により使用するデータベースの未使
用領域に対して削除マークにより初期化を行う。このよ
うに定義した後に、応用プログラムＡと応用プログラム
Ｂが後述するデータ操作２３をデータベースに対して行
い、システムダウンし、そのあとデータベースの回復処
理を行う場合について説明する。まず、時刻ｔ１で、チ
ェックポイントプログラム２２がデータベースバッファ
中にある更新データをすべてディスク上に書き込む。そ
して、更新データをジャーナルファイルにも書き込んだ
ことを示すＳＹＮＣポイントを記録する。次に時刻ｔ２
においてはプログラムＡがＢＴ（ａ）を発行し、データ
ベース処理部２４はこのＢＴ（ａ）を記録する。次に応
用プログラムＡはＲｕａを更新する命令を時刻ｔ３にお
いて発行する。データベース処理部２４はレコードＲｕ
ａの更新前後のイメージをデータベースバッファに作成
する。続いて時刻ｔ４においては同じく応用プログラム
ＡがレコードＲｗａの書き込みイメージをデータベース
バッファに作成する。次に時刻ｔ５において応用プログ
ラムＢがその処理を開始するためにＢＴ（ｂ）を発行
し、データベース処理部２４はこのＢＴ（ｂ）を記録す
る。

【００１３】次に、時刻ｔ６のＥＴ（ａ）の発行により
トランザクションＡが完結したことを記録し、時刻ｔ６
でそれまでの更新操作に関するジャーナルも、データベ
ースが更新される前に採取しておく。また、この時刻ｔ
６においてはデータベースバッファ２５に記録されてい
た情報がデータ部２８に登録されることになる。例え
ば、この例ではレコードＲｕａが更新され新たなレコー
ドとなる。またレコードＲｗａは追加のレコードとして
それまで削除マークを付されていた領域の一番最初の部
分に追加レコードとして新たに登録されることになる。
なお、ここで、ジャーナルのみ書かれていれば必ずしも
この時点でデータベースが更新されている必要はない。

【００１４】時刻ｔ７で応用プログラムからのレコード
Ｒｗｂ書き込みイメージをデータベースバッファに作成
した後、システムダウンが発生した場合、コンピュータ
システムを復旧した後、データベースの回復処理を次の
手順で行う。データベースの回復処理を行うにあたりこ
こでは、ＳＹＮＣポイントまでの処理はすべて索引部２
６、２７、データ部２８に記録されており、最終のＳＹ
ＮＣポイント以前のデータはすべて索引部２６、２７、
データ部２８に正しく記録されていることが保証されて
いるものとする。また、この実施例においてはトランザ
クションＢが追加しようとしたレコードＲｗｂは揮発性
メモリであるデータベースバッファ２５は記録されてい
たが、データ部２８にはまだ記録されていない時点でシ
ステムダウンが起こったものと仮定する。

【００１５】まず、ジャーナルファイル３０を探索し、
最終チェックポイント（ＳＹＮＣポイント）を求める。
次に、ＳＹＮＣポイントよりジャーナルデータエンド
（図中ＪＥ）までの間をチェックして最終レコード番号
（Ｒｗｂ）を得る。次に、データベースの最終レコード
番号（Ｒｗｂ）＋１の位置を未使用領域の始まり位置と
して当該データベースの領域情報に記録する。

【００１６】次に上記データベースの索引部を再生成
し、データベース内とレコードとキーの対応関係を正当
化する。このように最終レコード番号（Ｒｗｂ）＋１を
未使用領域の始まりとする事により索引部を再生成する
場合には、この最終レコード番号（Ｒｗｂ）までの領域
を対象にして索引部を再生成することが可能となる。こ
の実施例では前述したようにトランザクションＢによる
レコードＲｗｂはデータベースバッファ２５には記録さ
れていたがデータ部２８にはまだ記録されていない状態
でシステムダウンが起こっているので最終レコード番号
（Ｒｗｂ）の位置には実際には削除マークが記録されて
いるのみであり、トランザクションＢが書き込もうとし
たデータは存在していない。索引部を再生成する場合に
はこの削除マークが記入されている最終レコードＲｗｂ
の索引生成の対象とするが削除マークが記入されている
ために実際にはこのレコードに対しての索引部は生成さ
れないことになる。

【００１７】次に、最終ＳＹＮＣポイントからジャーナ
ルデータエンドまでの完結トランザクションに対する更
新後イメージをすべて対象のデータベースに適用する。
適用後、未完了のトランザクションＢに関して今度はジ
ャーナルデータエンドＪＥから反対方向に向かってトラ
ンザクションＢに関する更新前イメージを適用する。こ
の例においてトランザクションＢに関しては更新前イメ
ージがないので、更新前イメージを適用する必要はな
い。すなわちこの例においてはトランザクションＢはＲ
ｗｂの書き込み処理を行おうとしていたため、更新前イ
メージは存在せず、最終レコード番号（Ｒｗｂ）の位置
は削除マークがついたまま放置されることになる。

【００１８】以上の操作により、データ部２８及びその
索引２６，２７に応用プログラムＡの行った処理は適用
され、未完了となった応用プログラムＢの行った処理は
トランザクションＢが実行される直前の状態に戻ったこ
とになる。

【００１９】前述した動作においてはトランザクション
Ｂによるレコードはデータ部２８に登録される前にシス
テムダウンが起こったものと仮定して説明したが、次に
トランザクションプログラムＢによるレコードの追加処
理がデータ部２８に対して記録された後にシステムダウ
ンが起こった場合について説明する。前述した動作と異
なるところは索引部を再生成する際に最終レコード番号
（Ｒｗｂ）の位置には削除マークの代わりに実際にトラ
ンザクションＢが追加しようとしたデータが存在してお
り、このデータから索引部が再生成される点である。し
たがって未完処理であるトランザクションＢに対してジ
ャーナルデータエンドＪＥから反対方向に向かってトラ
ンザクションＢに関する更新前イメージを適用しようと
した場合にはこのデータを削除する処理を行う。したが
って、最終レコード番号（Ｒｗｂ）の位置は回復処理に
より削除マークが記入されることになる。

【００２０】以上のように、この実施例では、固定長レ
コード形式のデータファイルを基本構造とし、データフ
ァイル内のレコードとレコード内の任意の項目をキーと
して、キー値とレコード番号の対応表（索引）を複数個
有することの可能なデータベースと、当該データベース
に対する更新履歴を記録するジャーナルファイルを備え
るデータ処理装置のデータベースシステムにおいて、デ
ータベースの定義時において、当該データベースが使用
する領域の中で有効レコードを除く未使用領域部分につ
いて各レコード領域ごとに削除マークを記すことによ
り、当該データベースに対してトランザクションが新し
いレコードを追加した場合、その追加レコードを登録す
るためのレコード領域を当該データベースの未使用領域
から得て、追加レコードを登録する直前にジャーナルフ
ァイルに更新履歴を採取するが、このときシステム障害
が発生してコンピュータシステムが停止しても、コンピ
ュータシステムの復旧後に、ジャーナルファイルを読
み、当該レコードの更新履歴が採取されておらず、追加
レコードも登録されていなくとも未使用領域から得たレ
コードは削除マークにより論理的にレコードなしの状態
を示し、また、ジャーナルファイルに更新履歴がある場
合はその履歴情報により未完了トランザクションの戻し
回復が行われ、この場合も論理的にレコードなしの状態
となり、データベースを常に整合性のある状態に回復を
行うことを特徴とするデータベースの回復方式を説明し
た。この発明におけるデータベース回復方式は、データ
ベースの定義時にファイル内の未使用な領域（データが
まだ格納されていない領域）をあらかじめ削除マークで
初期化しておくことによりデータベース更新時のファイ
ル整合性保証のために行っていたディスクアクセスを減
らすことにより、高速なデータ操作を行うことができ
る。

【００２１】さらに、データベースバッファに残る更新
データは、バッファフルや一定時間毎（ＳＹＮＣ ＰＯ
ＩＮＴ）にディスクに書かれる直前に更新前後のイメー
ジをジャーナルバッファに書き込み、万一、コンピュー
タシステムがダウンした場合には、ジャーナルを探索
し、最新のＳＹＮＣ ＰＯＩＮＴを見いだし、それ以降
に記録されている更新操作に関連するデータファイルの
索引を再生成し、領域情報を最新の状態に修復した後に
最新ＳＹＮＣ ＰＯＩＮＴからのロールフォワード（最
新状態まで回復）を行い、不完全トランザクションのロ
ールバック（戻し回復）を行うことによりデータベース
を回復するものである。

【００２２】またこの実施例においては、従来のように
主キーを主索引に登録した後にデータをデータベースに
記録するという順番を経なくてもよくなる。すなわち従
来とは逆にデータを先にデータ部に書き込んでから主キ
ーを主索引に登録するようにしてもかまわない。なぜな
らば、回復作業においてデータ部から索引部を再生成す
るようにしたのでデータ部にデータが存在するのに索引
部にその索引が存在しないというような不都合がなくな
るためである。このように回復処理において索引部を再
生成することにより従来必要とされていた書き込みの順
番を自由に変えることが可能となり、操作に柔軟性が加
わることになる。

【００２３】実施例２． 上記実施例１においては、データベースが主索引及び副
索引というような複数の索引を持つ場合を例にして説明
したが、一つのデータ部からなるデータベース、あるい
は一つの索引部と一つのデータ部からなるデータベース
であってもかまわない。

【００２４】実施例３．上記実施例１においては、削除
マークをデータ部の未使用領域に設定する場合を示した
が、削除マークはデータ部の未使用領域に記入される場
合ばかりでなく、各データの未使用領域に対応して設定
されていればよく、例えばテーブル等によりまとめて一
個所に削除マークが記憶されているような場合であって
もかまわない。

【００２５】実施例４．上記実施例１においては、未使
用領域にデータがないことを示す識別子として削除マー
クを用いる場合を示したが、削除マークでない場合でも
よい。すなわちその領域に有効なデータがないことを示
す識別子を設定するものであれば削除マークと呼ばれる
ものでなくてもかまわない。

【００２６】

【発明の効果】以上のように、この発明によれば、デー
タベースの領域を削除マーク等の識別子にて初期化し、
かつ、データベース更新履歴をジャーナルに採取するこ
とにより、システム故障後のデータベースリカバリでは
必要最小限のデータ回復操作で速やかに回復することが
でき、また通常のデータ操作においてもジャーナルのみ
採取されれば、データベース中の更新結果は長時間デー
タベースバッファに残すことも可能となり、データベー
スバッファの大きさを大きくすればより高性能なデータ
ベースアクセスが可能となるという効果がある。

【図面の簡単な説明】

【図１】本発明の実施例を示す図。

【図２】本発明の実施例であるジャーナルファイルの一
例を示す図。

【図３】本発明の実施例であるダウン後の回復処理を示
す図。

【図４】従来のデータベース処理システムの構成図。

【図５】従来のデータベース処理システムの動作概要
図。

【符号の説明】

１ 応用プログラム ２ データベース処理部 ３ データベースバッファ ４ データベース ５ 索引部 ６ 主索引 ７ 副索引 ８ データファイル ９ ジャーナル ２１Ａ 応用プログラムＡ ２１Ｂ 応用プログラムＢ ２２ チェックポイントプログラム ２３ データ操作の時系列 ２４ データベース処理部 ２５ データベースバッファ ２６ 主索引 ２７ 副索引 ２８ データ部 ２９ データベース定義プログラム ３０ ジャーナルファイル ３１ ダウン後の回復処理

フロントページの続き (56)参考文献 特開 昭62−245348（ＪＰ，Ａ) 特開 昭62−297948（ＪＰ，Ａ) 特開 昭63−16348（ＪＰ，Ａ) 特開 平１−166231（ＪＰ，Ａ) 特開 平２−37440（ＪＰ，Ａ) 特開 平２−216557（ＪＰ，Ａ) 特開 平３−48939（ＪＰ，Ａ) 特開 平３−59733（ＪＰ，Ａ) 特開 平３−63737（ＪＰ，Ａ) 特開 平３−73037（ＪＰ，Ａ) 特開 平３−192438（ＪＰ，Ａ) 特開 平４−15734（ＪＰ，Ａ) 特開 平４−149649（ＪＰ，Ａ) 特開 平４−160441（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00

Claims (2)

(57)【特許請求の範囲】
1. 【請求項１】 索引部とデータ部とを有する不揮発性メ
   モリよりなるデータベースと、上記データベースを更新
   するための情報を一時保管する揮発性メモリよりなるデ
   ータベースバッファとを備え、障害が発生した場合にデ
   ータベースの回復処理をするデータベース回復方式にお
   いて、以下の要素を備えることを特徴とするデータベー
   ス回復方式 （ａ）上記データベースのデータ部の各データ領域に対
   応してその領域にデータがないことを示す識別子を設定
   する設定手段、 （ｂ）上記データベースバッファに上記データベースを
   更新するための情報を一時保管するとともに、保管した
   情報を用いて所定のタイミングで上記データベースを更
   新し、上記データベースの更新が上記識別子が設定され
   ているデータ領域に対する更新である場合は上記識別子
   を無効にするアクセス手段、 （ｃ）上記データベースバッファに上記データベースを
   更新するための情報を一時保管した後で、上記アクセス
   手段によるデータベースの更新を行うよりも前に、少な
   くとも更新するデータ領域の更新前イメージと更新後イ
   メージとを上記データベースの更新履歴としてジャーナ
   ルに記憶するジャーナル手段、 （ｄ）以下の要素を有し、障害が発生した場合にデータ
   ベースの回復処理をする回復処理手段、 （ｄ１）上記ジャーナル手段により記憶された更新履歴
   と上記更新履歴により示される上記データベースのデー
   タ部のデータ領域とを参照して、上記データ部のデータ
   領域に対応して上記識別子が設定されていない場合に、
   データベースの索引を再生成する索引生成手段、 （ｄ２）上記ジャーナル手段により記憶された更新履歴
   を用いて、データベースへの処理が終了しているトラン
   ザクションに対しては、上記データベースのデータ部の
   上記トランザクションに対応するデータ領域を上記更新
   後イメージを用いて更新後の状態に回復し、処理が終了
   していないトランザクションに対しては、上記データベ
   ースのデータ部の上記トランザクションに対応するデー
   タ領域に対応して上記識別子が設定されていない場合に
   は、上記データ領域を上記更新前イメージを用いて更新
   前の状態に回復する回復手段。
2. 【請求項２】 上記設定手段は、上記索引部とデータ部
   とを有するデータベースを定義する場合、データ部のデ
   ータ領域に対応して、その領域に上記識別子をあらかじ
   め設定することを特徴とする請求項１記載のデータベー
   ス回復方式。