(57)【特許請求の範囲】
【請求項１】
インデックス部とデータ部とで構成され、該インデックス部はインデックスキーとデータレコードの格納アドレスとの対応を格納し、該データ部は該データレコードを格納するデータベースと、
該格納アドレスに対応して、該インデックスキー及び該データレコードの情報が更新中か否かの状態を示す更新中フラグと、該インデックスキーと該データレコードが存在するか否かのチェック結果を示すチェック結果フラグとを記憶装置上に格納する対応関係チェックテーブルと、
該インデックス部及び該データ部の情報を更新するとき、該対応関係チェックテーブルの関連する格納アドレスに対応する該更新中フラグを更新中でない状態から更新中の状態に設定するデータベース管理のための処理手段と、
該対応関係チェックテーブルを参照して該更新中フラグが更新中でない状態を示す該格納アドレスについて、該格納アドレスに対応するインデックスキーとデータレコードを参照して当該インデックスとデータレコードが存在するか否かをチェックし、そのチェック結果によって該チェック結果フラグを設定するチェック処理手段とを有することを特徴とするデータベースのチェックを行う情報処理装置。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、データベースのチェックを行う情報処理装置に係わり、特に業務によってデータベースを更新する処理と並行してデータベースのチェックを行う情報処理装置に関するものである。
【０００２】
【従来の技術】
データファイル又はデータベースは、一般にインデックス部とデータ部とで構成され、インデックス部はインデツクスキーとデータレコードの格納アドレスとの対応関係を格納し、データ部はこの格納アドレスによってリンクされる格納場所にこのインデックスキーによってアクセスされるデータレコードを格納する。データファイル又はデータベースを管理するプログラムは、業務プログラムの要求に応じてインデックス部を検索して指定されたインデックスキーに対応するレコード格納アドレスを読み出し、このレコード格納アドレスを基にしてデータ部中の目的のデータレコードにアクセスする。データ部に新しいデータレコードを追加するときには、データベース管理プログラムはインデックス部の空き領域を検索し、データ部を検索して未使用のレコード格納アドレスを求め、インデックス部にインデツクスレコードを格納した後にデータ部に追加のデータレコードを格納する。
【０００３】
データベースは一般に上記のように構成され、アクセスされ、更新されるが、インデックスキーとデータレコードが常に正しく対応して格納されるとは限らない。例えばデータベースに物理的な破壊が生じたり、データベース管理プログラムのバグによつてデータベースに誤った情報が格納された場合、インデックスキーに対応するレコード格納アドレスが存在しなかったり、逆にインデックスレコードが存在しないのにデータレコードが単独で存在する不都合な状態となることがある。このためデータベース中のすべてのインデックスキーとデータレコードとの対応関係をチェックするプログラムを作成し、チェックを行っている。
【０００４】
従来は業務プログラムを停止させ、他からデータベースへのアクセスがない状態で上記の対応関係チェックプログラムを走行させ、データベースのチェックを行っていた。しかしデータベースにアクセスする業務プログラムを２４時間稼働させたいという要望が強くなっており、データベースをアクセスするすべての業務プログラムを停止させ、この対応関係チェックプログラムを走行させるのが困難な状況になっている。
【０００５】
なお、この種の技術として関連するものには、例えば特開平１−２１７６５２号公報「ファイルの同時更新回避方式」、特開平２−４８７４６号公報「ファイルの排他制御方法」、特開平５−２１６７８号公報「デ−タベ−ス管理システム」等がある。
【０００６】
【発明が解決しようとする課題】
データベース管理プログラムが行うデータレコードの追加の場合をみると、インデックス部にインデックスレコードを格納した後にデータ部に追加のデータレコードを格納する。従ってこの期間インデックスキーとデータレコードとの対応関係が一時的に不整合となる。従来の対応関係チェックプログラムはデータベース管理プログラムと並行処理することを考慮していないために、両者を並行して走行させると対応関係チェックプログラムがこの一時的に不整合な状態を捉えて対応関係が異常と判定する恐れがある。そうであるからと言って上記のように業務プログラムを停止させた上で対応関係プログラムを走行させることは許されない状況になっている。
【０００７】
本発明は、デ−タベースの追加・更新処理を停止させることなく、デ−タベースのチェックを行うことを目的とする。
【０００８】
【課題を解決するための手段】
本発明は、データベース管理プログラムがインデックス部及びデータ部の情報を更新する期間、各レコード格納アドレス対応に更新中の表示をし、この更新中の表示がされている期間、対応関係チェックプログラムが該当するレコード格納アドレスについての対応関係チェックを回避し、その他のレコード格納アドレスについて対応関係チェックを行うような情報処理装置を特徴とする。
【０００９】
【作用】
対応関係チェックプログラムは更新中の表示がされているレコード格納アドレスについて対応関係チェックを回避するので、上記のような一時的不整合の期間のチェックを避けることができる。すでにチェック済みのレコード格納アドレスをチェック対象から除外して行き、このようなチェックを何回か試行すれば一度対応関係チェックを回避したレコード格納アドレスについても次の機会にチェックされる。
【００１０】
【実施例】
以下、本発明の一実施例について図面を用いて説明する。
【００１１】
図１は、本実施例のデ−タベ−スのチェックを行う装置の構成図である。データベース４は、インデックスキ−とデータ格納アドレスとの対応表が格納されるインデックス部５とデータレコードが格納されるデ−タ部６とから構成される。データベース管理プログラム３は、データベース４に対するデータレコードの参照、更新、追加、削除などの操作を制御するプログラムである。業務プログラム２は、データベース管理プログラム３に対してデータレコードの操作をする要求を発行するプログラムである。対応関係チェックプログラム１は、インデックスキーとデータレコードとの対応関係が正常か否かをチェックするプログラムであり、データベース４上のインデックスレコード及びデータレコードを参照する。対応関係チェックテーブル７は、データレコードの格納アドレスごとにデータベース４中の情報の更新状態、インデックスレコードとデータレコードの参照結果、チェック結果等を格納し、対応関係チェックプログラム１及びデータベース管理プログラム３によって参照され、更新される。本実施例の装置は、情報処理装置によって実現され得る。対応関係チェックプログラム１、業務プログラム２及びデータベース管理プログラム３はこの情報処理装置の記憶装置に格納され、情報処理装置によって実行されるプログラムである。データベース４及び対応関係チェックテーブル７は、この情報処理装置の記憶装置（主記憶装置又は外部記憶装置）に格納されるデータである。
【００１２】
業務プログラム２からデータベース４についてデータレコードの参照、更新、追加、削除などの要求があったとき、データベース管理プログラム３はインデックス部５及びデ−タ部６を参照して要求された操作を行う。この操作がデータベース４中の情報を更新するものである場合、データベース管理プログラム３は対応関係チェックテーブル７上の関連するデータレコードの格納アドレスを初期状態から更新状態に変更し、操作を終えるときその更新状態を初期状態に戻す。対応関係チェックプログラム１は、対応関係チェックテーブル７上の各格納アドレスについて、インデックスレコードとデータレコードの状態を参照し、その結果を対応関係チェックテーブル７中の参照結果に反映する。対応関係チェックプログラム１は、インデックスレコードとデータレコードの参照結果が格納された格納アドレスについて、その格納アドレスの更新状態が初期状態であるときインデックスキーとデータレコードとの対応関係が正常か否かをチェックし、その結果を対応関係チェックテーブル７上のチェック結果の欄に格納する。
【００１３】
図２（ａ）は、インデックス部５のデータ構成を示す図である。インデックスキー１７は、データレコードを検索するためのインデックスキーである。レコード格納アドレス１８は、各インデックスキー１７に対応するデータレコードのデータ部６上の格納アドレスを示すものであり、アドレスは磁気ディスク装置のシリンダ番号、トラック番号、セクタ番号など物理アドレスで指定してもよいし、ページ番号、相対バイトアドレスなど論理アドレスで指定してもよい。図２（ｂ）は、データ部６についてレコード格納アドレス２１、使用状態２２及びデータレコード２３の対応を示す図である。レコード格納アドレス２１はレコード格納アドレス１８に対応するデータ部６上のすべてのアドレスである。使用状態２２はデータレコードの領域に実際のデータが格納されている（使用中）か格納されていない（未使用）かを示すフラグである。使用状態２２は制御情報としてデータレコードに前置してもよいし、データレコードの先頭文字が削除コード（未使用）か削除コードでない（使用中）かによって識別されてもよい。あるいはデータレコードとは別にレコード格納アドレス２１と対応するビツトマツプの形式で設定してもよい。データレコード２３はセクタ番号、ページ番号等により指定される物理レコードでもよいし、相対バイトアドレス等により指定される論理レコードでもよい。いずれにしてもインデックスキーを基にしてインデックス部５を検索し、求めたレコード格納アドレスを基にしてデータ部６を検索して目的の物理レコード又は論理レコードを含むデータレコードにアクセスすることができる。
【００１４】
図３は、対応関係チェックテーブル７のデータ構成を示す図である。レコード格納アドレス１０は、レコード格納アドレス１８及びレコード格納アドレス２１と同じである。更新状態１１は、データベース４中の情報が更新中か更新中でない（初期）かを示すフラグであり、初期状態は「初期」に設定される。インデックス有無１２は、レコード格納アドレスに対応するインデックスキーが存在する（有り）か存在しない（無し）かを示すフラグであり、初期状態は「無し」である。インデツクスキー１３はインデックスキーが存在する場合にインデックスキーの内容を格納する領域である。データ部使用状態１４は、レコード格納アドレスに対応する使用状態２２が「使用中」か「未使用」かを示すフラグであり、初期状態は「未使用」である。チェック対象１５は、インデックスキーとデータレコードとの対応関係が正常か否かのチェックが済んでいない（対象）か済んでいる（対象外）かを示すフラグであり、初期状態は「対象」である。チェック結果１６は、レコード格納アドレスに対応するインデックス有無１２とデータ部使用状態１４との対応関係チェックの結果を設定するフラグである。更新状態１１はデータベース管理プログラム３によって更新され、対応関係チェックプログラム１によって参照される。インデックス有無１２からチェック結果１６までは対応関係チェックプログラム１によって更新され、参照される。
【００１５】
図４は、データレコードの追加操作を行うデータベース管理プログラム３の処理の手順を示すフローチャートである。業務プログラム２からデータベース４へのデータレコードの追加要求があったとき、データベース管理プログラム３はインデックス部５の空き領域（エントリ）を求めてサーチする（インデックス部の読み込み：ステップ４１）。次にデータ部６の使用状態２２が「未使用」に対応するレコード格納アドレスを求めてサーチする（データ部の読み込み：ステップ４２）。次にこのアドレスに対応する対応関係チェックテーブル７上の更新状態１１を「更新中」に変更する（ステップ４３）。次にインデックス部５上の求めた空き領域にインデックスキー１７と求めたレコード格納アドレス１８の対を格納する（インデックス部の書き込み：ステップ４４）。次に求めたレコード格納アドレスの使用状態を「使用中」に変更してデータレコードを格納する（データ部の書き込み：ステップ４５）。最後にこのアドレスに対応する対応関係チェックテーブル７上の更新状態１１を「初期」に変更する（ステップ４６）。例えばインデックスキーが「００３」のデータレコードを追加するとき、インデックス部５にはインデックスキー「００３」とアドレス「＃４」の対応を示すインデックスレコードが追加され、データ部６のアドレス「＃４」に対応する使用状態２２が「使用中」に変更され、対応するデータレコード２３が格納される。
【００１６】
業務プログラム２からデータベース４上のデータレコードの削除要求があったとき、データベース管理プログラム３は指定されたインデックスキーに基づいてインデックス部５を検索し、このインデックスキーに対応するレコード格納アドレスを求め、このアドレスに対応する対応関係チェックテーブル７上の更新状態１１を「更新中」に変更する。次にインデックス部５上の指定されたインデックスキーと対応するレコード格納アドレスを削除し、求めたレコード格納アドレスに対応するデータ部６の使用状態２２を「未使用」に変更する。最後にこのアドレスに対応する対応関係チェックテーブル７上の更新状態１１を「初期」に変更する。データレコードの更新の場合で更新前と更新後でデータレコードのサイズが変わる場合には、更新前のレコードの削除をしてから更新後のレコードの追加を行うことになり、上記レコード削除の操作を行ってからレコード追加の操作を行うことになる。
【００１７】
図５は、対応関係チェックプログラム１の処理の概略の手順を示す図である。まずインデックス部５を参照して対応関係チェックテーブル７上のインデツクス有無１２及びインデックスキー１３を設定する（ステップ５１）。その詳細は図６に示される。次にデータ部６を参照して対応関係チェックテーブル７上のデータ部使用状態１４を設定する（ステップ５２）。その詳細は図７に示される。次に設定されたインデツクス有無１２、インデックスキー１３及びデータ部使用状態１４に基づいてインデックスキーとデータレコードとの対応関係をチェックする（ステップ５３）。その詳細は図８ａ，図８ｂ及び図８ｃに示される。最後にチェック結果を編集して図示しないプリンタ等の出力装置に出力する（ステップ５４）。
【００１８】
図６は、対応関係チェックテーブル７上のインデツクス有無１２及びインデックスキー１３を設定する対応関係チェックプログラム１の処理の流れを示すフローチャートである。インデックス部５のインデックスレコードをその配置順に読み込み、インデックスキーに対応するレコード格納アドレスを求める（ステップ６１）。次にこのレコード格納アドレスに対応する対応関係チェックテーブル７上のインデツクス有無１２を「有り」に設定する（ステップ６２）。次に読み込んだインデックスキーをレコード格納アドレスに対応するインデックスキー１３に格納する（ステップ６３）。インデツクス部５の終端に達していなければ（ステップ６４ＮＯ）、ステップ６１に戻って上記処理を繰り返す。インデツクス部５の終端に達していれば（ステップ６４ＹＥＳ）、処理を終了する。処理を終了したとき、対応関係チェックテーブル７上のレコード格納アドレスに対応するインデックスキーが存在すればインデツクス有無１２が「有り」に設定され、インデックスキーが存在しなければそのレコード格納アドレスに対応するインデツクス有無１２は初期値の「無し」のままである。図６に示す処理は、データベース４中のインデツクス部５のみを参照する処理であり、たとえデータベース管理プログラム３がインデックスレコードを更新していたとしてもデータレコードとの一時的な不整合は対応関係チェックプログラム１に影響しない。
【００１９】
図７は、対応関係チェックテーブル７上のデータ部使用状態１４を設定する対応関係チェックプログラム１の処理の流れを示すフローチャートである。対応関係チェックテーブル７に登録されたレコード格納アドレス１０を順に参照し、各レコード格納アドレスについてデータ部６の使用状態２２を読み出す（ステップ７１）。次にこの結果に従ってそのレコード格納アドレスについて対応関係チェックテーブル７上のデータ部使用状態１４を「使用中」又は「未使用」に設定する（ステップ７２）。データ部６の終端、すなわち対応関係チェックテーブル７の終端に達していなければ（ステップ７３ＮＯ）、ステップ７１に戻って上記処理を繰り返す。データ部６の終端に達していれば（ステップ７３ＹＥＳ）、処理を終了する。図７に示す処理はデータベース４中のデータ部６のみを参照する処理であり、たとえデータベース管理プログラム３がデータレコードを更新していたとしてもインデックスレコードとの一時的な不整合は対応関係チェックプログラム１に影響しない。
【００２０】
図８ａは、インデックスキーとデータレコードとの対応関係をチェックする対応関係チェックプログラム１の処理の流れを示すフローチャートである。対応関係チェックテーブル７上の各レコード格納アドレス１０について、チェック対象１５が「対象」であれば（ステップ８１ＹＥＳ）、インデツクス有無１２が「有り」であって（ステップ８２有り）、データ部使用状態１４が「使用中」であれば（ステップ８３使用中）、チェック結果１６を「正常」に設定する（ステップ８４）。またインデツクス有無１２が「無し」であって（ステップ８２無し）、データ部使用状態１４が「未使用」であれば（ステップ８５未使用）、チェック結果１６を「正常」に設定する（ステップ８６）。またインデツクス有無１２が「有り」であって（ステップ８２有り）、データ部使用状態１４が「未使用」であれば（ステップ８３未使用）、図８ｂに示す処理を行う（ステップ８７）。またインデツクス有無１２が「無し」であって（ステップ８２無し）、データ部使用状態１４が「使用中」であれば（ステップ８５使用中）、図８ｃに示す処理を行う（ステップ８８）。チェック結果１６に値を設定した後、チェック対象１５を「対象外」に設定し（ステップ８９）、対応関係チェックテーブル７の終端に達していなければ（ステップ９０ＮＯ）、ステップ８１に戻り次のレコード格納アドレスについて上記処理を繰り返す。チェック対象１５が「対象外」であれば（ステップ８１ＮＯ）、そのレコード格納アドレスについてはすでにステップ８２からステップ８９に至る処理が済んだのであるから、この処理をスキップしてステップ９０へ行く。対応関係チェックテーブル７の終端に達していて（ステップ９０ＹＥＳ）、あらかじめ規定した回数だけ対応関係チェックテーブル７をスキャンしていなければ（ステツプ９１ＮＯ）、ステップ８１に戻り対応関係チェックテーブル７の最初のレコード格納アドレスから上記処理を繰り返す。規定した回数だけ対応関係チェックテーブル７をスキャンしたら（ステップ９１ＹＥＳ）、処理を終了する。すなわち所定回数繰り返してもまだ「更新中」の状態のレコード格納アドレスが残るのであれば、例外的なケースとし処理を打ち切る。
【００２１】
図８ｂは、ステップ８７の処理を展開して示すフローチャートである。まずインデツクスキー１３を使ってインデックス部５を検索する（ステップ９３）。インデックスが存在しなければ（ステップ９４ＮＯ）、チェック結果１６を「正常」に設定し（ステップ９５）、ステップ８９へ行く。インデックスが存在し（ステップ９４ＹＥＳ）、インデツクスキー１３に対応するレコード格納アドレスが現在チェック中のレコード格納アドレスに一致すれば（ステップ９６ＹＥＳ）、チェック結果１６を「異常」に設定し（ステップ９７）、ステップ８９へ行く。インデックスが存在し（ステップ９４ＹＥＳ）、インデツクスキー１３に対応するレコード格納アドレスに一致しなければ（ステップ９６ＮＯ）、チェック結果１６を「正常」に設定し（ステップ９８）、ステップ８９へ行く。
【００２２】
図８ｃは、ステップ８８の処理を展開して示すフローチャートである。更新状態１１が「更新中」であれば（ステップ１０１ＹＥＳ）、現在のレコード格納アドレスについてのチェックを保留してステップ９０へ行く。更新状態１１が「初期」であれば（ステップ１０１ＮＯ）、現在のレコード格納アドレスを基にしてデータ部６からデータレコードを読み出し、そのインデックスキーを抽出し（ステップ１０２）、抽出したインデックスキーを基にしてインデックス部５を検索する（ステップ１０３）。インデックスが存在しなければ（ステップ１０４ＮＯ）、チェック結果１６を「異常」に設定し（ステップ１０５）、ステップ８９へ行く。インデックスが存在し（ステップ１０４ＹＥＳ）、インデツクスキーに対応するレコード格納アドレスが現在チェック中のレコード格納アドレスに一致すれば（ステップ１０６ＹＥＳ）、チェック結果１６を「正常」に設定し（ステップ１０７）、ステップ８９へ行く。インデックスが存在し（ステップ１０４ＹＥＳ）、インデツクスキーに対応するレコード格納アドレスが現在チェック中のレコード格納アドレスに一致しなければ（ステップ１０６ＮＯ）、チェック結果１６を「異常」に設定し（ステップ１０８）、ステップ８９へ行く。
【００２３】
ステップ８４及びステップ８６の処理は、特定のレコード格納アドレスについてインデックス有無の設定の処理（ステップ５１，図６）とデータ部使用状態の設定の処理（ステップ５２，図７）との間に当該データレコードについて追加や削除が発生しなかったケースであり、データレコードの追加・削除が少ないアプリケーションでは多くはこのケースとなる。ステップ９５の処理は、特定のレコード格納アドレスについてステップ５１とステップ５２との間で当該データレコードの削除があったケースであり、データ部使用状態が「未使用」であり、対応するインデックスキーが削除されているからチェック結果は「正常」である。ステップ９８の処理は、特定のレコード格納アドレスについてステップ５１とステップ５２との間で当該データレコードの削除があった後当該データレコードの追加があり、しかもレコード格納アドレスが移動しているケースであり、一旦削除されたインデックスキーは再び追加されてインデックス部５に残っているが、対応するレコード格納アドレスが変更されているのでインデツクスキー１３に対応するレコード格納アドレスが現在チェック中のレコード格納アドレスに一致しないケースであり、「正常」とした。ただし非常に例外的なケースであって、当該データレコードの削除があった後当該データレコードの追加があり、しかもレコード格納アドレスが移動しないケース（ステップ９６ＹＥＳ）の可能性もあるならば、ステップ９８の結果をステップ９７と同様に「異常」に設定し、後は運用的に処置する方法をとってよい。ステップ１０７の処理は、特定のレコード格納アドレスについてステップ５１とステップ５２との間で新しいデータレコードの追加があったケースであり、データ部使用状態が「使用中」であり、データレコードの追加によりインデックス有無「有り」が証明されたのであるから、チェック結果は「正常」である。それ以外のケースのチェック結果はすべて「異常」となる。なおステップ１０２でデータ部からインデックスキーを抽出できなければ、一旦追加されたデータレコードがさらに削除された可能性があり、チェック結果を「異常」としてよい。
【００２４】
本実施例によれば、インデックス有無１２を設定するためにインデックス部５を１回だけシーケンシャルに参照し、データ部使用状態１４を設定するためにデータ部６を１回だけシーケンシャルに参照し、多くのケースは対応関係チェックテーブル７上のインデックス有無１２とデータ部使用状態１４を参照するだけでチェック結果「正常」の結果を出せるので、対応関係チェックプログラム１の処理を非常に高速に行うことができる。しかも例外的なケースについては、対応関係チェック（ステップ５３）の段階で再度インデックス部５及びデータ部６をアクセスしているが、このときデータベース管理プログラム３がデータベース４の情報を更新している期間を避け、この期間のインデツクス部５とデータ部６との間の一時的な不整合を回避している。
【００２５】
【発明の効果】
本発明によれば、デ−タベースを更新する業務プログラムを停止させることなく対応関係チェックプログラムを走行させることができるため、サービス性を向上させることができる。
【図面の簡単な説明】
【図１】本発明の一実施例の情報処理装置の構成図である。
【図２】インデックス部及びデータ部の構成例を示す図である。
【図３】対応関係チェックテーブル７のデータ構成例を示す図である。
【図４】データレコードの追加を行うデ−タベ−ス管理プログラムの処理手順を示す図である。
【図５】実施例の対応関係チェックプログラムの処理の手順を示す図である。
【図６】実施例のインデックス有無を設定する処理の流れを示す図である。
【図７】実施例のデ−タ部使用状態を設定する処理の流れを示す図である。
【図８ａ】実施例の対応関係チェックの処理の流れを示す図である。
【図８ｂ】図８ａのステップ８７を展開して示す図である。
【図８ｃ】図８ａのステップ８８を展開して示す図である。
【符号の説明】
１・・・対応関係チェックプログラム、２・・・業務プログラム、３…データベース管理プログラム、４・・・データベース、７・・・対応関係チェツクテーブル、１０・・・レコード格納アドレス、１１・・・更新状態、１２・・・インデックス有無、１３・・・インデックスキー、１４・・・データ部使用状態、１５・・・チェック対象、１６・・・チェック結果、１７・・・インデックスキ−、１８・・・レコード格納先アドレス、２２・・・使用状態、２３・・・デ−タレコード
【図１】
0003636773.tif 000002
【図２】
0003636773.tif 000003
【図３】
0003636773.tif 000004
【図４】
0003636773.tif 000005
【図５】
0003636773.tif 000006
【図６】
0003636773.tif 000007
【図７】
0003636773.tif 000008
【図８ａ】
0003636773.tif 000009
【図８ｂ】
0003636773.tif 000010
【図８ｃ】
0003636773.tif 000011