JP2531776B2

JP2531776B2 - デ―タベ―スを回復する方法

Info

Publication number: JP2531776B2
Application number: JP1025962A
Authority: JP
Inventors: リンダ・キヤロライン・エリオツト; ゲリイ・ランダル・ホーン; ロイド・ジユーゼン・ジヨーダン・セカンド; フランク・エリオツト・レビン; チエング―フオング・シイ; ウイリアム・ウオルター・マイエ、ジユニア
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1988-04-08
Filing date: 1989-02-06
Publication date: 1996-09-04
Anticipated expiration: 2011-09-04
Also published as: US4945474A; BR8901635A; EP0336546B1; EP0336546A3; DE68926693D1; JPH01261746A; EP0336546A2; DE68926693T2

Description

【発明の詳細な説明】 A.産業上の利用分野情報処理システムの発展で、関係データベース管理プ
ログラムが進歩し、多数の異なるデータベース・テーブ
ルのすべてに共通な特定のフィールドを使って、それら
のテーブルに含まれるデータをユーザが探索、アクセス
及び変更することが可能になった。

B.従来技術これらのデータベース・システムが改善されるに従っ
て、データベース内のレコードに対するアクセスの速度
及び効率が増大し、能力がさらに追加された。たとえ
ば、最近のデータ処理システムは、各ユーザがサブペー
ジ・レベルで同時にデータに均等なアクセスを行なうこ
とができる。多数の同時ユーザのためのサポートを提供
し始めた。

そのような改善にもかかわらず、大きな問題として残
された１つの領域は、入出力または電源の故障後、すな
わち、システム・クラッシュ後などにデータの回復を行
なうことであった。その理由は、データベースにあるデ
ータの編集に伴って大量の時間と経費がかかるようにな
ったこと、ならびに、ユーザが、ますます需要になって
きている彼等のデータベース資源に大きく依存するよう
になったことであった。したがって、そのようなデータ
損失に関連する問題を解決する試みに多大な開発努力が
費やされてきた。

多分、この問題に対する最も明白な一般的解決法は、
冗長構成を設けて、そのような不完全なログの書込み、
または検出されたログ書込みの障害のためにデータベー
スまたはその一部分を復元する必要がある場合に、デー
タのバックアップ・コピーを入手できるようにすること
であった。したがって、そのような冗長構成をもたらす
ための幾つかの方法が当技術で開発されてきた。その最
も初期の方法の１つはシャドー・ページングと呼ばれ、
基本的に、データ・ページ全体のコピーを保持し、第２
のコピーに更新を行なうというものであった。変更を含
む新しいコピーを永久的媒体に安全に書き込んだ後、保
存用コピーを書き直すことができる。この方法は、たと
えば、SQL/DSとして市販されているIBM社のデータベー
ス・プロダクトで使用されていた。このシャドー・コピ
ー法を用いた種々のシステムについての概説が、リバ・
スボボドバ（Liba Svobodova）の論文「ネットワークに
基づいた分散システムのためのファイル・サーバ（File
Servers for Network Based Distribution System
s）」、ACM Computing Surveys、Vol.16、No.4（1984年
12月）、pp.353−399に記載されている。

シャドー・ページングは幾つかの環境で実現可能な解
決法であると思われるが、そのようなシャドー・コピー
を維持する際に費用と空間が必要なことを含めて、それ
なりの欠点を伴っていた。したがって、データベース・
システムは、データベース・レコードに対する変更を変
更レコード及びデータベース回復ログの両方に書き込む
ことによってのみ、トランザクション回復機能を実施し
始めた。データベース回復ログに記録された情報は、コ
ミットされたトランザクションの変更がシステム故障の
後に続くシステム再始動の間にデータベース状態に組み
込まれるようにするものであった（かつ、コミットされ
ていないトランザクションに対するトランザクション・
ロールバックをサポートして、データベース・レコード
に対する変更を逆転または取消しできるようにするもの
であった）。

先行書込みロギングと呼ばれるこの方法の１形態が開
発されたが、そのプロトコルは、実際のデータベース・
レコード自体に変更を書き込む前に永続ファイル内の回
復ログに変更を書き込むことを必要とした。そのような
ロギングの１つの問題点は、多数のユーザが、望ましく
は、サブページ・レベルでデータベースに同時にアクセ
スすることができるという、上記の同時性が望まれるこ
とに関係するものであり、そのような同時性が必要だと
いうことは、言い換えればたとえば、レコードに対する
迅速で効率的なアクセスを行なうためにデータベース・
プログラムが共通に使用するインデックス・ファイルに
対する同時アクセスが必要だということになる。

これらのインデックス・ファイルのインデックス・ノ
ードに含まれる情報は、データベース・テーブルに対し
てレコードが削除または挿入されるとき頻繁に削除また
は挿入される、重要なレコード情報を提供する点で非常
に重要であり、したがって、そのようなサブページ・レ
ベルでの同時アクセス可能性が強く求められていた。そ
のようなインデックス・ファイルの特に重要な１つの態
様は、データベース内のレコードの個々のフィールド
が、それ自体に関するレコードには保持されていず、
（ポインタまたは記述子により）別のファイルに保持さ
れているデータを論理的に含むことがしばしばあるとい
うことであった。そのようなファイルの例は長フィール
ド・ファイルと呼ばれ、非常に重要である可能性がある
音声データやイメージ・データ等の大きなデータ・セッ
ト型式の項目に関連するイメージを含むことがあり、し
たがって、そのようなインデックスの重要性を示す長い
フィールドがそれに含まれる。

上記のことを念頭に置いて、それにもかかわらず上記
サブページ・レベルの同時性をもたらす先行書込みロギ
ング型のデータベース回復システムを実現することが望
まれていたことを理解されたい。したがって、特願昭63
−94715号に記載されたようなシステムが開発された。
当技術で周知のＢツリー構造として通常構成されるもの
などこれらのインデックス・ファイルについて考察して
いるその他の参考文献は、レーマン（Lehman）及びヤオ
（Yao）の論文「Ｂツリー上の同時動作のための効率的
ロッキング（Efficient Locking for Concurrent Opera
tion on a B−Tree）」、ACM Transactions on Databas
e Systems、Vol.6、No.4、1981年12月、pp.650−670で
ある。この参考文献を引用により本書に組み込む。

上記の進歩にもかかわらず、有効なデータベース回復
を行なう点で問題が残っていた。まず、そのようなシス
テムの再始動時に、入出力エラーを含むファイルは容易
に検出できず、したがって、再始動動作がファイルにア
クセスしてデータ損失をもたらすのを防止し防護するこ
とができなかった。さらに、不完全なログ書込みまたは
検出されたログ書込み障害を容易に検出して、それ以後
のトランザクションの書込みを中断するための手段がな
かった。さらに、再始動中にそのようなエラー・ファイ
ルを容易に識別するための有効な手段がなかった。さら
に、エラー・ファイル・インデックスの復元は決して自
動的ではなく、明確なユーザ活動を必要とし、障害イン
デックスに関連するアクセス計画を無効にした。

C.発明が解決しようとする問題点したがって、先行書込みロギング・プロトコルを使用
したトランザクション管理システムで、ディスクへの非
原子的書込み中における入出力エラー及び電源障害によ
るデータ消失を減少させるための手法が求められてい
た。システム・テーブルを含めて、インデックス・ファ
イル上の入出力エラーがデータ消失を引き起こさないよ
うなシステム及び方法が強く求められていた。また、影
響を受けたインデックスを復元するための明確なユーザ
活動を必要とせずに、エラーからの自動回復を行なうた
めの方法が求められていた。２重書込み、シャドー・ペ
ージング等を使用しなくても、ログ・ファイル書込み中
の電源障害でデータ消失が起こらないような手段が求め
られていた。ユーザ・テーブル上の入出力エラーがエラ
ー状態のテーブルに対して僅かなデータ消失効果しか持
たないようにする効果的な手段を設けることが強く望ま
れていた。さらに、インデックスと関連するアクセス計
画を無効にしない。インデックス・ファイルの復元方法
を提供することが望まれていた。従来技術によって満た
されることがなかった上記及びその他の機能が、以下に
詳細に説明する本発明によって提供される。

D.問題点を解決するための手段先行書込みロギング・プロトコルを有するトランザク
ション管理システムを使用した、非原子的メモリ書込み
中のデータベース・システム・クラッシュに対するデー
タ回復のための手法が提供される。好ましい実施例で
は、通常処理中にログ・レコードが書かれる。再実行
（REDO）中に回復ログを走査して、記録された処理の完
了が確認される。検出された不完全なまたは失敗したロ
グ書込みからの回復が行なわれ、コミットされていない
トランザクションは取り消される。入出力エラーを有す
るファイルが検出され、フラッグが付けられて、後続の
再始動（RESTART）動作がファイルにアクセスしないよ
うにする。このシステムはさらに、障害インデックスに
関連するアクセス計画を無効にするために明確なユーザ
活動を必要とすることなく、再始動手順の一部としてエ
ラー・インデックス・ファイルの自動的復元を行なう。

通常動作中、フラッグを付けられたデータ・ファイル
・エラーは、そのデータ・ファイルにアクセスしようと
しているアプリケーションに報告される。しかし、フラ
ッグを付けられた長フィールド・ファイル・エラーは、
アプリケーションがその長フィールド・ファイルを使用
しようとしたときだけ、そのアプリケーションに報告さ
れる。フラッグを付けられたインデックス・ファイル・
エラーは、システムが下側のデータ・ファイルにアクセ
スするとき、または、アプリケーションが相関データ・
レコードにアクセスするためインデックス・ファイルに
アクセスするとき、アプリケーションに対するエラー状
況なしにその復元を行なう。インデックス・ファイル上
で検出された入出力エラー及びログ書込み障害またはロ
グ書込み中の電源障害の結果として前にコミットされた
データが消失することが回避される。

E.実施例本発明を一層良く理解するため、最初に第１図ないし
第４図を参照にしながら、代表的データ及び、そのデー
タがデータベース・システムに記憶される方法について
のさらに詳細な説明を、第１図の従業員表の例を使って
行なう。第３図に関して、データベース・インデックス
の概念について一例を示す。次に、第４図に関して、第
４図に示した特に重要な形態のファイル、すなわち、長
フィールド・ファイルにアクセスする際の第３図のイン
デックス情報の使用について説明する。後でさらに明ら
かになるように、これらのインデックスは実際には、対
応するデータ・レコードを参照し、それらのデータ・レ
コードは相関する長フィールドを参照する。

次に、システム再始動モードにおける本発明の動作全
体、再実行再始動及び取消し再始動段階について第５図
を参照して概説する。次に、第７図及び第８図に関して
再実行中の各動作のより詳しい考察を行ない、第11図に
関して、第５図に示すシステム再始動後のシステム動作
のより詳しい説明を行なう。

第１図は、ユーザがデータベースに入力した実際のデ
ータの一例を概念的に示す。この例では、このデータは
実質的には、従業員名10等のヘッダ、ある形式の従業員
番号12、及び当該の従業員の肖像画等のある型式のイメ
ージ・データ14を含むリストである。したがって、この
テーブルの最初のレコードはアンドリュー（Andrew）、
従業員番号１、及びアンドリューの肖像画からなるデー
タである。データベースに入力された他の従業員につい
ても同様のレコードがある。

第２図は、コンピュータ・ディスクに記憶されるとき
の第１図のテーブル・データの一部を示すファイルの説
明図である。このファイルは、それぞれ第１図のレコー
ドの幾つかを含むページ０−２（それぞれ、参照番号1
6、18及び20）等のデータ・ページを順に示す。各デー
タ・ページはヘッダ及びトレーラを有する。たとえば、
ページ０はヘッダとして22及びトレーラとして30を有
し、ページ１は36及び44を、ページ２は50及び58をそれ
ぞれヘッダ及びトレーラとして有する。ヘッダ及びトレ
ーラはそれぞれログ・シーケンス番号（LSN）を含む。
このLSNは、ページの書出しに先立ってヘッダからトレ
ーラに複写される。ページの読み戻し後、前の書込みが
完了したことを確認するため、ヘッダとトレーラが比較
されて、それらが等しいことが確かめられる。

さらに具体的にページ０（参照番号16）を参照する
と、第１のスロット０のポインタ32を含むレコード・ポ
インタ・ディレクトリ24がある。ポインタ32はレコード
26を指し、レコード26自体は、名前「エドワーズ（Edwa
rds）」、通し番号24、及びエドワーズのイメージのビ
デオ・データを含む長フィールド・ファイル（LF）を指
すポインタを含む。レコード・ポインタ・ディレクトリ
24の次のスロットはこの例では使用されない。すなわ
ち、このスロットは、ビデオ・データを有する別の長フ
ィールド・ファイルを指すポインタを含まない。スロッ
ト２は、レコード28を指すポインタ34を有し、レコード
28は、アンドリューのイメージのビデオ・データを含む
長フィールドを指すポインタを含む。要約すると、イン
デックスは、レコードを指すポインタを含むデータ・レ
コード・ディレクトリを指す。これらのレコードは名
前、通し番号、及び実際の長フィールド・イメージ・デ
ータを指す長フィールド記述子またはポインタを含む。

同様に、ページ１（18）はレコード・ポインタ・ディ
レクトリ38を有する。この事例では、スロット０のポイ
ンタ48は、ハウェル（Howell）のデータを含むレコード
42を指し、レコード42には、イメージ・データを指す長
フィールド・ポインタが存在する。スロット１のポイン
タ46は、レコード40を指し、レコード40は、ベーカー
（Baker）のイメージ・データを含む長フィールドを指
す長フィールド・ポインタを含む。同様に、ページ２に
ついては、レコード・ポインタ・ディレクトリ52は、レ
コード56を指すポインタ62を有するスロット０を含む。
このレコード56は、対応する長フィールド・ファイル中
でチェスター（Chester）のイメージ・データを指す長
フィールド・ポインタを含む。スロット１は同様に、レ
コード54を指すポインタ60を有し、レコード54は、エド
ガー（Edgar）のイメージ・データが存在する長フィー
ルドを指すポインタを含む。

長フィールドとは、当技術で周知のように、イメージ
のディジタル化された実際のビデオ・データが、好まし
くは圧縮された様式で記憶される場所である。したがっ
て、レコードに対するポインタは32、34、46、48、60及
び62、及びレコードは、イメージ・データが存在するそ
れぞれの長フィールド・ファイルの始めに対する指示さ
れた実際の変位を含む。第２図で一例を挙げると、ポイ
ンタ62はレコード56を指し、レコード56は、チェスター
82の圧縮イメージ・データが存在する長フィールドに対
するセグメント・ディレクトリの始めである1098（第４
図の最上部に示す）に対応する数を含むことになる。

関係データベースでは、第１図のテーブル１のデータ
等のデータに効率的にアクセスすることが必要である。
このことは通常インデックス・ファイルを使って行なわ
れており、その一例を、当技術で周知の形で（テーブル
１のデータについて）第３図に概略的に示す。第３図
は、インデックスが２段ツリーの形を取っている、テー
ブル１用のインデックスを示す。データベース・ファイ
ルのページ３（64）のルート・レベルは、３つのノード
66、68及び70を指すポインタを有する。これらのノード
は、それぞれインデックス・ファイルのページ５、４及
び６に記憶されたインデックス・データを有する。イン
デックス・ファイルのページ３（64）のＤ、Ｆ及び「NU
LL」はそれぞれ、それらが指す指定のノード66、68、70
における最も可能性の高い「キー」を示す。この事例で
は、キーは従業員名の頭文字であるが、数字データが記
憶される他のアプリケーションでは、キーは数字でよ
い。アンドリュー、ベーカー及びチェスターはＤよりも
前の頭文字を有するので、彼等に関係するインデックス
・データはノード66に記憶される。ルート64内のＦはノ
ード68を指し、ノード68は、頭文字がＦよりも前でＤよ
りも後のエドガー及びエドワーズのインデックス・デー
タを含む。ルート64のNULLポインタは許容される最高の
キーであるので、最後のノード70を指す。ノード70はハ
ウェルを含む。なぜならば、その頭文字ＨがＦ（先行ノ
ード68中の最高キー）よりも後だからである。

第３図の名前の後に続く番号の意味は、それらの番号
がレコード識別、すなわち、それぞれの名前のIDを表わ
すことである。たとえば、ノード66の場合、アンドリュ
ー０、２は、まずページ０のレコード・ポインタ・ディ
レクトリ24、スロット２からの長フィールド・ポインタ
を含むレコード28の位置34を検索し、次に、レコード28
に含まれる長フィールド・ポインタが指す92（第４図）
にある実際の長フィールド・データを検索することによ
り、アンドリューに対するイメージ・データを探し出す
ことができることを示す。

第４図はコンピュータ・ディスクにある長フィールド
・ファイルの記憶についての説明図である。参照番号72
は、最初のイメージ・データを82に有する長フィールド
・ファイルの始めを示す。各イメージに対する内部セグ
メント・ディレクトリが、それぞれのイメージ・データ
についての詳細を提供する。したがって、チェスターの
イメージ・データ82に対するディレクトリ80は、長さが
10,500バイトで開始変位が1106である１つの項目を示
す。同様に、第２図のページ１、参照番号18では、ハウ
ェルのイメージ・データを指すレコード42中の長フィー
ルド・ポインタは、ハウェルの実際のイメージ・データ
88に対する内部セグメント・ディレクトリ86の始めであ
る11,800（第４図）を指すことになる。

他の長フィールド・データの始め74及び76に関して
は、第２図に示す適当な相関長フィールド・ファイル・
ポインタが、対応する内部セグメント・ディレクトリ9
0、94、98及び102を指すことになる。これらのディレク
トリは、アンドリュー、エドワーズ、ベーカー及びエド
ガーに関する当該の実圧縮イメージ・データ92、96、10
0及び104についての詳細を含む。本明細書に示す実施例
では、セグメント・ディレクトリは長フィールド領域に
あるが、希望するなら、これらの領域にはイメージ・デ
ータのみを含めることができ、その場合は、セグメント
・ディレクトリを望むなら第２図に示すレコード中に含
めることもできることに留意されたい。

これで、たとえば今述べたようにインデックスから見
つかったポインタを用い、重要なタイプのデータベース
・ファイルにアクセスして更新する際の、データベース
・システムにおけるインデックスの役割について一層明
確な理解が得られたので、第５図に関連して本発明の回
復システムの全体的動作について説明する。

260でシステム再始動が開始すると、262でログ・レコ
ードが読み込まれる。各ログ・レコードは、ログ・レコ
ード、及びそれに含まれるデータベース活動が関係する
特定のページの表識を含む。基本的に、プログラムは、
ステップ260−270では、これらのログ・レコードまたは
それらと関連するLSNによって参照されるデータ・ペー
ジを読み込んで、ログ・レコードのデータベース動作ま
たは活動が行なわれたことを確認する（この段階はシス
テム再始動−再実行段階と呼ばれる）。266で、特定の
ログ・レコードについて、データ、インデックス、長フ
ィールド・ファイル等の関連ページ・ファイル・タイプ
が識別される。次に、268でそのページが読み取られ、2
70で、読み込まれたばかりのページ上のLSNが関連ログ
・レコードのLSNに等しいまたはそれよりも大きいかど
うかについて、検査が行なわれる。イエスの場合は、ロ
グ・レコードで識別された動作が完了したことが分か
り、処理は、262で次のログ・レコードを読むためにル
ープして戻る。しかし、検査の結果がノーの場合は、読
み込まれたばかりのログ・レコードに関連する元のデー
タベース活動または動作を272で再実行しなければなら
ないことを示す。したがって、その基本概念は、上記特
願昭63−94715号によれば、294で検査して、残ったログ
・レコードがなくなるまで、ログ・ファイル全体が読み
取られ、264でイエスの場合は、すべての活動が繰り返
され、再始動−再実行段階が完了したことを示す。した
がって、判断ブロック264でイエスの結果が出ること
は、このとき、コミットしていない、記録されたすべて
のトランザクションをロール・バックしなければならな
いことを意味し、したがって、274でシステム再始動−
取消し段階に入る。

一般に、この取消し段階中に、コミットされていない
トランザクションを表わす各ログ・レコードは時間順に
取り消される。すなわち、全ログ・レコードを逆方向に
検査して、それらがコミットされていないトランザクシ
ョンの一部であるかどうか調べる。そうである場合は、
そのログ・レコードに対して打切りが行なわれる。この
取消し段階は、第５図のステップ274−282で表わされ
る。

具体的には、276で前のログ・レコードが読み取ら
れ、278で、ログ・レコードが見つかったかどうか検査
が行なわれる。見つからなかった場合は、279で、シス
テム・プロファイルまたはシステム構成中に、エラー・
インデックスを自動的に再作成するようにとの要求をユ
ーザが指定したかどうか検査が行なわれる。ノーの場合
は、281で通常動作が再開する。すなわち、システム再
始動が完了する。イエスの場合は、プログラムはステッ
プ284を実行する。これは、第５図のシステム再始動動
作の直後に起こることに対応する。そこで、処理はルー
チンを出て、第11図に関してさらに詳しく示すエラー・
インデックス・ファイルの再作成を完了する。

始動−取消し段階の目的に関して前述したように、ロ
グ・レコードが見つかったときは、280で検査を行なっ
て、このログ・レコードがコミットされていないトラン
ザクションと関連しているかどうか判定する。イエスの
場合、システムは282で、ログ・レコード中で識別され
たデータベース活動の取消しを実行し、そこで処理は、
276で次の前ログ・レコードを読み取るためにループし
て戻る。もちろん、280で、問題のログ・レコードがコ
ミットされていないトランザクションに含まれていない
場合は、処理は、ステップ282の動作のような取消し動
作を実行せずに、次の前ログ・レコードを読むために27
6にループして戻る。

第５図の上段に示したステップ262及び266に関連し
て、第７図のステップ136に示すように、ログ・レコー
ドを得るにはページを読み取らなければならないことは
もちろん明らかである。第７図に示すログ・ページの読
取り動作のさらに詳細な説明に加えて、第７図のステッ
プは、ページを読み取る際にエラーに出会ったときの本
発明のシステムの動作をも示す。たとえば、ある事例で
ページがログ・エラーを有することが分かった場合、処
理はステップ268に進む。一方、たとえば、第７図の180
に示すように、両方のページで入出力エラーが発生した
場合は、戻りエラー・ログ・ファイル状況を起こす致命
的エラーが発生したことになる。第７図に関連するもう
１つの事例は、170のようにログ・ファイル終了状況が
返されるときであり、これは、やはり第５図に関連し
て、処理ステップ264に達し、すべての活動が繰り返さ
れた、すなわち、再始動−再実行段階が完了したことを
示す。

第７図と同様に、以下にさらに詳しく説明する第８図
のステップ262及び266に関してさらに詳細を提供するこ
とは、第５図のステップ268で示すように、データ・フ
ァイル、長フィールド・ファイル及びインデックス・フ
ァイルからページを読み取る際に実際に必要なステップ
についてさらに詳細を提供する。第８図の184及び186で
ファイルからページを読み取る際にエラーに出会ったと
きに実行されるステップが特に示されている。その際19
4でファイルが命名し直され、次いで処理は、ステップ2
62に従って次のログ・レコードを読み取るためにブロッ
ク270から出るイエスの経路にループして戻る。

したがって、第７図、第８図及び第11図はシステム再
始動中の本発明の動作に関することに留意されたい。具
体的には、第７図はログ・ページの処理と、再始動中に
検出されるエラーの処理を詳細に示す。第８図は、再始
動中の実際のデータ・ファイル、インデックス・ファイ
ル及び長フィールド・ファイルに関係するエラーの検出
及び処理を詳細に示し、第11図は、再始動−取消しの完
了後にエラー・インデックス・ファイルを再作成する際
のステップを詳細に示す。対照的に、第６図、第９図及
び第10図はデータベース・システムの通常の順方向処理
動作に関係する。具体的には、第６図はそのような通常
処理中のログ・ページの書込みを詳細に示し、第９図
は、通常のデータベース動作で普通出会う読取りエラー
の処理を詳細に示し、第10図は、データベース・システ
ムの通常動作中のそのような通常のすなわち非再始動の
インデックス処理中に行なわれるエラー・インデックス
・ファイルの処理について記述する。

第６図は、ログ・ページをハード・ファイル等のコン
ピュータ媒体に書き込む方法を示す流れ図である。一般
に、システムは「付加」モードにあり、ログ・レコード
が回復ログに連続的に追加、すなわち、書き込まれる。
次に、ログ・ページが周期的にディスクに書き出され
る。106は、コミットを出した要求側機能に応答してロ
グ・ページをディスクへ書き込み始めることを示す。最
終的に、要求側機能から要求されたログ・レコードは、
要求側機能がコミットを出した後で、ページに書き出さ
れるが、第６図に示した処理は、ページが実際に書き出
される前に行なわれることを認識されたい。コミット時
に、その時点までに作成されたすべてのログ・レコード
のデータを含むログ・ページを書き出すことが望まし
い。

108で、処理は、書き込むべきログ・レコードが満た
されているか否かについて照会する。ログ・ページが満
たされていない（すなわち、ログ・ページがページ・サ
イズよりも小さい）場合は、不完全ページであると指示
され、処理は114に進み、そのページがすでに書き込ま
れたかどうか判定される。書かれていない場合は、処理
は116に進み、そのページが位置ｎ＋１に書き込まれ
る。次いで118でページ書込みカウンタが１にセットさ
れ、106で開始したルーチンの呼出しプログラムに120で
戻り、ページを書き出すアルゴリズムが実際に完了す
る。

ブロック114で、ページがすでに書き込まれていた場
合は、122へのイエス分岐をたどり、122で、ページ・カ
ウンタが増分される。ページ・カウンタが偶数であると
124で判定された場合は、処理は128に進み、ｎ番目のロ
グ・ページが位置ｎ＋２に書き込まれる。124でページ
書込みカウンタが奇数の場合は、手順は126に進み、そ
こでｎ番目のログ・ページが位置ｎ＋１に書き込まれ
る。いずれの場合にも、130または132で、このルーチン
の呼出しプログラムへの戻りが実行される。108に戻っ
て、ログ・ページ・サイズがページ・サイズよりも小さ
くない（すなわち、完全なページが満たされた）場合
は、処理はステップ110に進み、そこで、ｎ番目のログ
・ページが位置ｎに書き込まれ、次いで、処理は112で
呼出しプログラムに戻る。このように、ｎ番目のログ・
ページが位置ｎに書き込まれるのは、当該ログ・ページ
にログ・レコードがたまって、そのサイズが所定のペー
ジ・サイズ以上になったときである。それまでは、位置
ｎ＋１及びｎ＋２に交互に書き込まれる。従って、ｎ番
目のログ・ページの書き込みが停電等のため途中で中断
しても、前回書き込まれたログ・ページが位置ｎ＋１及
びｎ＋２のいずれかに残っているから、それを第７図に
従って読み出すことによりデータベースを回復すること
ができる。

第７図は、ログ・ページの処理、及びデータベース再
始動処理中に検出されたエラーの処理を示す流れ図であ
る。134はこの処理の始めであり、136で、ｎ番目のログ
・ページが読み込まれる。ログ・ページの読込み後、13
8で、入出力エラーまたはヘッダとトレーラのLSNの不一
致があった場合は、172で次のログ・ページｎ＋１が読
み込まれる。174で、入出力エラーまたは不一致のLSNが
あると判定された場合は、180でエラー状況が返され
る。この特定の事例では、180でデータベースを回復す
ることができず、したがって、バックアップ・コピーか
ら復元しなければならない。174で、入出力エラーまた
はヘッドLSNとトレーラLSNの不一致がなかった場合は、
判断ブロック176に達する。ページｎ＋１のLSNがログの
開始LSNよりも小さい場合は、このページが前に書き出
されていないことが分かり、処理は178に進む。178で、
ログ・ファイル終了状況が返され、全ページの処理が完
了したことを示す。

第７図で176のノー分岐から先に進むと、ページｎ＋
１のLSNがログの開始LSNよりも大きいかまたは等しい場
合は、処理は148に進み、ページｎ＋１のLSNを検査し
て、ログの開始LSNよりも小さいかどうか調べる。小さ
い場合は、第７図のこの処理は完了し、154でログ・フ
ァイル終了状況が返される。148で、ページｎ＋１のLSN
がログの開始LSNよりも小さくない場合は、152で次のロ
グ・ページｎ＋２が読み取られる。そのページの読取り
後、156で、入出力エラーまたはヘッダとトレーラのLSN
の不一致が発生したかどうか判定される。発生した場合
は、ページｎ＋１からのログ・レコードが使用され、処
理は162で呼出しプログラムに戻る。156に戻って、入出
力エラーや不一致がなかった場合は、158で、ページｎ
＋２のLSNがページｎ＋１のLSNよりも小さいかどうか判
定される。そうである場合は、162で再び処理はページ
ｎ＋１に戻る。そうでない場合は、160で、処理はペー
ジｎ＋２に戻る。この段階では、処理は単に、最高のLS
Nを有するページを判定して、そのページを返す。有効
なLSN、すなわちログの始めよりも大きなLSNがある限
り、入出力エラーまたは不一致に出会わない場合に書き
出すことが可能な隣接する２ページのうちの大きい方の
ページが返される。ページを返すことに関連して、実際
に特定のページ番号が返され、次いで、番号を指定され
たページから適当なレコードが返されることに留意され
たい。

判断ブロック138に戻って、136でｎ番目のログ・ペー
ジを読み込んだ後、検査を行なって、入出力エラーまた
はヘッダとトレーラのLSNの不一致が発生したかどうか
判定する。発生しなかった場合は、140でページｎのLSN
がログの開始LSNよりも小さいかどうか検査が行なわれ
る。そうである場合は、ページｎ＋１またはｎ＋２での
み作業が行なわれたことを示し、次に流れは144に進
み、次のログ・ページｎ＋１が読み取られる。しかし、
ページｎのLSNがログの開始LSNよりも大きいかまたは等
しい場合は、そのページが正しく読み取られ、使用すべ
き適正なページであることを示し、したがって、142に
従って読取り成功状況が返される。

144に戻って、次のログ・ページｎ＋１を読み込んだ
後、146で入出力エラーまたはヘッダとトレーラのLSNの
不一致が発生したかどうか検査が行なわれる。不一致ま
たはエラーが検出された場合は、150に従って次のログ
・ページｎ＋２が読み込まれる。次に、164でこのペー
ジの入出力エラーまたは不一致が検査される。164で不
一致またはエラーが検出された場合は、イエスの分岐出
口に従って165でエラー・ログ・ファイル状況が返され
る。一方、164でエラーや不一致が検出されなかった場
合は、168で、このログ・ページｎ＋２のLSNがログの開
始LSNよりも小さいかどうかが検査される。もし小さけ
れば、170でログ・ファイル終了が返される。一方、ペ
ージｎ＋２のLSNがログの開始LSNに等しいか又はそれよ
りも大きい場合は、168でページｎ＋２が返される。こ
のように、第７図のオペレーションは、第６図に従って
書き込まれたログ・ページが適正かどうかを判断し、そ
して適正なページｎ、ｎ＋１又はｎ＋２を返す。

第６図との関連で説明すると、ｎ番目のログ・ページ
について、110で位置ｎへの書き込みが成功裏に完了し
ていると、第７図のオペレーションは、136から138及び
140を経て、ｎ番目のログ・ページの読み取りがうまく
いったことを示す。また、第６図において126での位置
ｎ＋１への書き込みが完了し、次回の書き込みを128で
実行している途中でエラーが生じた場合は、ｎ番目のロ
グ・ページについてはまだ位置ｎへの書き込み（110）
が実行されていないので、第７図のオペレーションは、
136から138及び140を経て144の方へ進み、そこから14
6、148、152及び156を経て、162で適正なページｎ＋１
を返す。このページは、第６図の126で位置ｎ＋１に書
き込まれていたものである。第６図で126に続いて110が
実行され、その途中でエラーが生じていた場合には、第
７図の138でエラーが検出されるので、172から174及び1
76を経て、最終的に162で適正なページｎ＋１を返す。
第６図で位置ｎ＋２への書き込み（128）が完了して、
それに続く書き込み（110又は126）の途中でエラーが生
じた場合も同様である。その場合は、中断したのが110
か126かに応じて、第７図の160又は168で適正なページ
ｎ＋２が返される。このページｎ＋２は、第６図の128
で位置ｎ＋２に書き込まれていたものである。

第８図は、データベース再始動処理中の任意のデータ
・ファイル、インデックス・ファイルまたは長フィール
ド・ファイルでのエラーの検出及び処理を示す流れ図で
ある。処理は182で開始し、ログ・レコードの処理が開
始される。ログ・レコードは、特定の所望データ、イン
デックスまたは長フィールド・ファイル・データを読み
取るべきページ及びファイルを識別することを想起され
たい。184で、ログ・レコードから指定されたページが
読み取られる。186で、読取りエラーが発生したかどう
か検出が行なわれる。読取りエラーが検出されたとき
は、190で検査が行なわれて、読取りが試みられている
ファイルが存在するかどうか調べられる。存在しないと
きは、エラーの標識を付する対象がないので、これで第
８図の処理は終了する。そこで、第８図の処理が終了し
たという意味でステップ196で動作成功が返される。一
方、そのようなファイルが存在するときは、そのファイ
ルが命名し直され、エラーの標識が付されることにな
る。こうして、ステップ196で動作成功が返される。186
に戻って、読取りエラーが発生しなかった場合は、188
で検査が行なわれて、ヘッダとトレーラのLSNの不一致
が存在するかどうかが判定される。存在する場合は、や
はり194で、ファイルが命名し直され、196で動作成功が
返される。一方、188でヘッダとトレーラのLSNの不一致
が検出されなかった場合は、192で、通常行なわれるは
ずの動作が実行される。これらの動作は、この時点でロ
グ・レコードがその実行を要求するどのような動作でも
よい。たとえば、特定の動作の再実行等でも、そのとき
必要ならば、キーを追加することでもよい。最後に、第
８図に関連して、回復後に、エラー・ファイルを識別す
る情報を捕捉してテーブル中またはディスク上に載せる
ことができる。しかし、好ましい方法は、そのような情
報をビット・マップに記憶することである。

第９図は、通常処理中、すなわち、非データベース再
始動中のエラー・ファイル処理を示す流れ図である。処
理は198で開始し、その後200で、ページまたはファイル
の読取り要求が実行される。202で読取りエラーがある
かどうか検査され、エラーがあった場合は、206で検査
が行なわれて、そのファイルが存在するかどうかが判定
される。そうである場合は、214で、エラーに相当する
状況が設定され、要求は処理されず、次いで215でその
状況が返される。

206のファイルが存在するかどうかのテストに戻っ
て、ファイルが存在しない場合は210で、ファイル・タ
イプがインデックス・ファイルであるかどうかについて
検査が行なわれる。インデックス・ファイルでない場合
は、処理は214に進み、やはり要求は処理されず、215で
エラーに相当する状況が返される。一方、210で検査さ
れたファイル・タイプがインデックス・ファイルであっ
た場合は、処理は、第10図に示すように212から先に進
む。202に戻って、読取りエラーが検出されなかった場
合は、204でヘッダとトレーラのLSNの不一致があるかど
うか検査が行なわれる。不一致が検出された場合は、や
はり214及び215で処理要求が拒絶される。一方、ヘッダ
とトレーラのLSNが一致した場合は、208で要求が処理さ
れ、成功に相当する状況が設定され、215でその状況が
返される。

次に第10図に戻ると、これは、通常の非データベース
再始動中のエラー・インデックス・ファイル処理を示す
流れ図である。218で、テーブルをオープンするように
との要求が行なわれたかどうか検査が行なわれる。要求
が行なわれていない場合は、220でエラー・メッセージ
が返される。テーブル・オープン要求は、新しいテーブ
ルの処理を開始するようにとの要求である。そのような
要求を処理が受け取った場合、222で、インデックス・
ファイルを再作成するための手順が開始される。222に
おけるそのような手順の始めはエラー・インデックス・
ファイルを削除することである。それが行なわれると、
224で、システム・インデックス・テーブルを使って最
初のインデックス定義が探し出される。226で、この最
初の定義を使って、処理は、224で定義されたインデッ
クスを作成または再作成し始める。228で、すべてのイ
ンデックスがすでに作成されたかどうか検査が行なわれ
る。まだの場合は、230で次のインデックス定義が検索
され、226にループして戻って、取り出されたインデッ
クスが再作成される。再び228の検査を続行し、すべて
のインデックスが作成された場合は、232で「テーブル
・オープン」要求が完了され、234から戻る。

第11図は、システム再始動の完了後の全エラー・イン
デックス・ファイルの再作成を示す流れ図である。236
で、システム再始動が実際に完了し、インデックス・フ
ァイルのすべてを作成する動作が開始される。238です
べてのエラー・インデックス・ファイルのリストが取り
出される。これは、前のエラーが発生した時点及びイン
デックス・ファイル再作成を試みていた際のシステム・
クラッシュの後であり、その場合は、238でリストが存
在する。しかし、前のエラー及びクラッシュが起きなか
った場合は、このリストは明らかに空である。240で、
取り出されたこのリストが任意の新しいエラー・インデ
ックス・ファイルに追加される。これは、第８図で付さ
れたエラー標識によりそのディレクトリを検査すること
によってエラー・インデックス・ファイルがあるかどう
か調べることによって行なわれ、エラー・インデックス
・ファイルがある場合は、それらをエラー・インデック
ス・ファイルのリストに加える。242で、検査が行なわ
れて、リスト上の最初のファイルが取り出される。以下
のステップ244以下で、このリストに挙げられたすべて
のファイルについて実際にそのファイルをオープンして
みることにより、オープンが成功すれば、それは再始動
によりエラーが回復していることを意味するので、それ
をリストから削除し、オープンが成功しなければ、それ
は再始動によってもエラーが回復しなかったことを意味
するので、それをリストに残すという処理を行う。244
で、リスト上のすべての項目が処理されたかどうか調べ
られる。処理されていない場合は、246でファイルが更
新のためオープンされる。252で検査が行なわれ、オー
プンが成功したかどうかが判定され、そうである場合
は、リスト254からその項目が取り除かれる。取り除か
れた後で、256で次の項目が指示され、244にループして
戻り、そこで再び検査が行なわれて、リスト上のすべて
の項目が処理されたかどうかが判定される。252で、オ
ープンが成功しなかった場合は、256で次の項目が指示
される。244に戻って、リスト上の全項目が処理された
場合は、248でディスク上のリストが更新され、250で処
理が終了する。

第12図に、前述のアルゴリズムの機能を提供するコン
ピュータ・プログラムを実行して、本発明のシステムを
実現するために使用することができる処理装置のブロッ
ク・ダイヤグラムを示す。このシステムは、IBMパーソ
ナル・システム/2に組み込まれたパーソナル・コンピュ
ータ等の通常のパーソナル・コンピュータ・アーキテク
チャーの形を取ることが好ましい。このシステム290に
は、インテル80286または80386等のマイクロプロセッサ
308が設けられている。マイクロプロセッサ308はバス31
0によって入出力装置300、ROM302、メモリ304及び媒体3
06のうちの選択された所望のものに結合される。通常の
ように、バス310は当技術では周知の目的用のアドレス
線、コマンド線及びデータ線からなることを了解された
い。本発明のシステム290に含めることができる入出力
装置300には、IBMパーソナル・システム・カラー表示装
置8510等の表示装置、ユーザ入力用のキーボード、マウ
ス等、さらに、所望ならば印刷装置がある。簡単のた
め、第12図ではアダプタが省略されているが、それぞれ
の装置300−306用のそのようなアダプタをIBMパーソナ
ル・システム/2の一部として含めることができ、あるい
はIBM社からのプラグ・イン・オプションとして入手で
きることを了解されたい。

読取り専用メモリ（ROM）302内には、プロセッサ308
による実行のために基本入出力オペレーティング・シス
テム（BIOS）が格納される。BIOSは周知のように、コン
ピュータ・システム290の基本動作を制御する。さら
に、OS/2等のオペレーティング・システム298が設けら
れ、メモリ304にロードされ、ROM302内のBIOSと共に実
行される。

本発明のシステム及び方法を実現するための好ましい
実施例で使用することができるパーソナル・システム/2
及びオペレーティング・システムOS/2についてのその他
の情報は、引用により本書に組み込んだ下記の参考文献
に記載されている。IBM Operating System/2 Version
1.0 Standard Edition Technical Reference、IBM社部
品番号6280201、発注番号5871−AA;Technical Referenc
e Manual、Personal System/2（Model 80）、IBM社部品
番号68X2256、発注番号S68X−2256;及びOS/2 Programme
r′s Guide、ヤコブッチ（Iacobucci）編、マグローヒ
ル社、1988年。

本発明によれば、さらに、メモリ304にロードできる
か、あるいは媒体306に記憶させることができるアプリ
ケーション・プログラム292が設けられる。この媒体306
は、ハード・ファイル、ディスク駆動機構に結合された
ディスケット等の通常の形のものなら何でもよい。OS/2
によれば、データベース・アプリケーション・プログラ
ム292はオペレーティング・システム298の拡張と見なす
ことができ、システム290が上記の関係データベース機
能をできるようにするため、通常、プロセッサ308に命
令を与えるデータベース・プログラムと関連する多数の
機能を含む。オペレータは種々の入出力装置300を介し
てデータベース・プログラムとインターフェースするこ
とができ、そのようなインターフェース処理にはデータ
の入力、アクセス、変更またはデータベースからの削除
及びその他のそのようなタスクが含まれる。たとえば、
ユーザは、当技術で周知のSQLコマンド等のある形のデ
ータ操作言語コマンドを入力することにより、データベ
ース・プログラム292と対話することができ、それによ
り、システム290は、データベースに存在するデータを
照会し、検査のためユーザが設定した所望の応答をビデ
オ端末、印刷装置等に出力する。

データベース・プログラム292に含まれるソフトウェ
ア機能は、回復ログ機能294及びシステム再始動機能296
を含むことに留意されたい。第12図にデータベース・プ
ログラム292の一部として図式的かつ概念的に示したこ
れらの機能は、本発明の方法による回復ログの生成及び
システム再始動の実行に関して、上記の本発明の機能を
実行することが認められる。

【図面の簡単な説明】

第１図はデータベース・テーブルの説明図である。第２図は、媒体に概念的に記憶されたときの第１図のデ
ータベース・テーブルのデータ・ページの説明図であ
る。第３図は、媒体に概念的に記憶されたときの第１図のデ
ータベース・テーブル用のインデックスＢツリーの説明
図である。第４図は、第１図のテーブル中の従業員に対応する長フ
ィールド・ファイル・データの説明図である。第５図は、本発明の種々の構成要素の動作全体を示す流
れ図である。第６図は、ログ・ページを媒体に書き込む方法を示す流
れ図である。第７図は、第５図の方法に従って書かれたログ・ページ
の処理と、データベース再始動処理の間に検出されたエ
ラーの処理を示す流れ図である。第８図は、データベース再始動処理中におけるデータ、
インデックスまたは長フィールド・ファイルに関するエ
ラーの検出及び処理を示す流れ図である。第９図は、通常の非データベース再始動処理中における
エラー・ファイル処理を示す流れ図である。第10図は、通常の非データベース再始動インデックス処
理中におけるエラー・インデックス・ファイル処理を示
す流れ図である。第11図は、システム再始動の完了後のエラー・インデッ
クスの再作成を示す流れ図である。第12図は、第５図ないし第11図に関連して説明するルー
チンを実行するための本発明によるコンピュータ化され
たシステムを示す全般的機能ブロック・ダイヤグラムで
ある。 290……データ回復システム、292……データベース・プ
ログラム、298……オペレーティング・システム、300…
…入出力装置、302……読取り専用メモリ、304……メモ
リ、306……媒体、308……プロセッサ。

フロントページの続き (72)発明者ロイド・ジユーゼン・ジヨーダン・セカンドアメリカ合衆国テキサス州オースチン、ベイスウオーター・ガーデン13505番地 (72)発明者フランク・エリオツト・レビンアメリカ合衆国テキサス州オースチン、チヤペル・ダウン・ストリート9406番地 (72)発明者チエング―フオング・シイアメリカ合衆国テキサス州オースチン、カバナ、レイン12225番地 (72)発明者ウイリアム・ウオルター・マイエ、ジユニアアメリカ合衆国テキサス州オースチン、マークリイ・レイン・12405番地

Claims

(57)【特許請求の範囲】

【請求項１】データ・ファイル、インデックス・ファイ
ル、及び回復ログを記憶するための記憶媒体と、該記憶
媒体に対して入出力を行うCPUとを有するデータベース
・システムにおいて、入出力エラーの後でデータベース
を回復する方法であって、（ａ）通常の処理中にログ・レコードを上記記憶媒体上
の上記回復ログに書き込むステップと、（ｂ）上記回復ログを走査することにより上記システム
を再始動するステップと、（ｃ）上記回復ログの走査でコミットされないトランザ
クションが検出された場合に該トランザクションで取り
消すステップと、（ｄ）上記記憶媒体において入出力エラーの生じたファ
イルを命名し直し、エラー・ファイルとして識別するス
テップと、（ｅ）上記エラー・ファイルがインデックス・ファイル
の場合に該インデックス・ファイルを再構成するステッ
プと、を具備するデータベースを回復する方法。
【請求項２】データ・ファイル及びインデックス・ファ
イルを有するデータベースを回復するための回復ログを
ログ・ページとして保持するデータベース・システムに
おいて、（ａ）ログ・ページを記憶媒体に書き出すときに、該ロ
グ・ページが所定のサイズより小さいかどうかを判断す
るステップと、（ｂ）上記ログ・ページが上記所定のサイズ以上であれ
ば、上記ログ・ページを上記記憶媒体の所定の位置に書
き出すステップと、（ｃ）上記ログ・ページが上記所定のサイズより小さけ
れば、上記ログ・ページを上記記憶媒体の上記所定の位
置とは異なる２つの位置に交互に書き出すステップと、（ｄ）エラー後の再始動で上記所定の位置及び上記２つ
の位置のいずれかから正しいログ・ページを読み取るス
テップと、（ｅ）読み取ったログ・ページに基づいて上記システム
を再始動するステップと、を具備するデータベースを回復する方法。