JP4148529B2 - データベースにおける索引の整合性をチェックするためのシステム、方法およびプログラム - Google Patents

Description

本発明は、データベースの整合性をチェックするためのシステム、方法およびプログラムに関するものであり、特に、複数のデータ・セグメントが記録された主データベースおよび複数の索引セグメントが記録された索引データベースを含むデータベースにおいて索引の整合性をオンラインでチェックするためのシステム、方法およびプログラムに関する。

従来、データベースの整合性のチェックは、データベースに含まれる各セグメントの保存先アドレスと、データベースに含まれる各ポインタとを比較することによって行われていた。このような整合性チェックは、例えば、本出願人によって開発されたデータベース管理システムに実装されて用いられている（非特許文献１を参照。）。

上述のような整合性チェックでは、全てのポインタの読み出しを完了するまでの間にデータベースが更新されると、更新前後のポインタが混ざった状態でアドレスと比較されてしまうことになり、正確なチェックができない場合がある。このため、従来、整合性チェックの処理中には、データベースの更新を停止するか、または、データベースの少なくとも一部に対するアクセスの排他制御を行うことが一般的である（例えば特許文献１を参照。）。

しかしながら、データベースのデータサイズが大きい場合には、更新が停止される時間が膨大となり、または、更新が大幅に遅延し、利用者の利便性を低下させてしまう場合があったため、更新を停止させることなく整合性をチェックする技術も提案されている（特許文献２および３を参照。）。

ところで、データベースが大きくなると、上述の更新の問題の他に、検索時間が長くなるという問題も生じるが、これは索引付けによって解決することができる。例えば、階層型データベースであるＩＢＭ社のＩＭＳでは、データ・セグメントを記録した主データベースの他に、データ・セグメントへの索引を記録した索引データベースを設けることによって索引付けを実現している。

索引は、主データベースにおける対応するデータ・セグメントの保存先アドレスを示すポインタと、検索用のキー値を含んでおり、データベースの整合性の観点からは、これらの索引に含まれるポインタとキー値も定期的に整合性をチェックする必要がある。当然、このような索引の整合性チェックも、オンラインで、すなわちデータベースの更新を停止させることなく実行できるのが望ましい。

特開平８−２４９２２２号公報 特開２００１−１４２７６５号公報 特開２００６−１３９６１９号公報 IMS High Performance Pointer Checker User's Guide http://publibfi.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/fabp1b10/CCONTENTS

従って本発明の目的は、複数のデータ・セグメントが記録された主データベースおよび複数の索引セグメントが記録された索引データベースを含むデータベースにおいて索引の整合性をオンラインでチェックするためのシステム、方法およびプログラムを提供することにある。

本発明の第１の態様によれば、複数のデータ・セグメントが記録された主データベースおよび複数の索引セグメントが記録された索引データベースを含むデータベースにおいて索引の整合性をチェックするためのシステムであって、前記索引データベースから索引セグメントを順次読み出して、ポインタ値およびキー値を含むポインタ・レコードを生成し、前記主データベースからデータ・セグメントを順次読み出して、そのうちの前記索引セグメントのポインタ値により示される索引対象セグメントの保存先アドレスおよび検索フィールド値を含むセグメント・レコードを生成するレコード生成部と、前記ポインタ・レコードおよび前記セグメント・レコードの生成がどこまで進んだかを示すスキャン・ポイントを設定するスキャン・ポイント設定部と、前記索引データベースで索引セグメントが更新されたこと、または前記主データベースで索引対象セグメントが更新されたことに応じ、更新されたセグメントが前記スキャン・ポイント設定部により設定されたスキャン・ポイントよりも前であることを条件に、前記更新セグメントの更新ログを書き出す更新ログ書き出し部と、前記更新ログに基づいて前記ポインタ・レコードおよび前記セグメント・レコードを修正するレコード修正部と、修正後のポインタ・レコードをポインタ値でソートし、修正後のポインタ・レコードおよび修正後のセグメント・レコードにおいて対応するレコード・エントリ同士を比較することにより索引の整合性を検証する整合性検証部と、を含むシステムが提供される。

本発明の第２の態様によれば、複数のデータ・セグメントが記録された主データベースおよび複数の索引セグメントが記録された索引データベースを含むデータベースにおいて索引の整合性をチェックするための方法であって、前記索引データベースから索引セグメントを順次読み出して、ポインタ値およびキー値を含むポインタ・レコードを生成するステップと、前記主データベースからデータ・セグメントを順次読み出して、そのうちの前記索引セグメントのポインタ値により示される索引対象セグメントの保存先アドレスおよび検索フィールド値を含むセグメント・レコードを生成するステップと、前記ポインタ・レコードおよび前記セグメント・レコードの生成がどこまで進んだかを示すスキャン・ポイントを設定するステップと、前記索引データベースで索引セグメントが更新されたこと、または前記主データベースで索引対象セグメントが更新されたことに応じ、更新されたセグメントが前記スキャン・ポイント設定部により設定されたスキャン・ポイントよりも前であることを条件に、前記更新されたセグメントの更新ログを書き出すステップと、前記更新ログに基づいて前記ポインタ・レコードおよび前記セグメント・レコードを修正するステップと、修正後のポインタ・レコードおよび修正後のセグメント・レコードにおいて対応するレコード・エントリ同士を比較することにより索引の整合性を検証するステップと、を含む方法が提供される。

本発明の第３の態様によれば、複数のデータ・セグメントが記録された主データベースおよび複数の索引セグメントが記録された索引データベースを含むデータベースにおいて索引の整合性をチェックするためのプログラムであって、第２の態様による方法の各ステップをコンピュータに実行させるためのプログラムが提供される。

何れの態様においても、主データベースおよび索引データベースが同じであってもよい。すなわち、データ・セグメントおよび索引セグメントを単一のデータベースに記録するようにしてもよい。

以下、図面を参照しながら、本発明を実施するための最良の形態について説明するが、以下の説明は単なる例示であって、特許請求の範囲に記載された本発明を制限するものではない。例えば、実施形態では、データベースの例としてＩＢＭ社のＩＭＳを取り上げるが、もちろん本発明は他のデータベースにも適用可能である。

図１は、本発明が対象とするデータベース・システム１０の概略を示す。データベース・システム１０は、データベース２０と、データベース管理システム３０とを備える。データベース２０は、本実施形態では階層型データベースであって、図２に示すように、ツリー形式に構成された複数のデータ・セグメント２００を記録する主データベース２２と、それぞれが対応するデータ・セグメントに対するキー値（索引）を含む複数の索引セグメント３００を記録する索引データベース２４から成っている。図２において、例えばキー値Ａを有する索引セグメント３００は、検索フィールドに値Ａを有するデータ・セグメント２００に対応している。他の索引セグメントについても同様である。

主データベース２２および索引データベース２４は同じデータベースであってもよい。すなわち、データ・セグメント２００および索引セグメント３００を単一のデータベースに記録するようにしてもよい。

主データベース２２の具体的な構成例を図３に示す。主データベース２２は、データ・セグメント２００−１〜４に代表される複数のデータ・セグメントを記録している。図示の例では、データ・セグメント２００−１がルート・セグメントになっており、ルート・アンカー・ポイント（ＲＡＰ）によって指定することができる。データ・セグメント２００−１は、接頭部２１０−１と、データ部２２０−１とを含む。また、データ・セグメント２００−１の保存先アドレスは１０００である。ここで、保存先アドレスとは、例えば、主データベース２２の所定の基準アドレスと比較したデータ・セグメント２００−１の先頭アドレスの位置（相対バイトアドレス：ＲＢＡ）をいう。接頭部２１０−１は、データ・セグメント２００−２の保存先アドレスである１１００を指示するポインタ２３０−１と、その他のデータ・セグメントの保存先アドレスを指示するポインタ２４０−１と、セグメント・コード（ＳＣ）２５０−１とを含む。セグメント・コード２５０−１は、ルート・セグメントから順にセグメント・タイプを特定するために降られた番号である。図示の例では、データ・セグメント２００−１はルート・セグメントであるから、セグメント・コード２５０−１は、例えば“０１”に設定される。

データ・セグメント２００−２は、データ・セグメント２００−１と同じく、接頭部２１０−２と、データ部２２０−２とを含む。接頭部２１０−２は、データ・セグメント２００−３の保存先アドレスである１２００を指示するポインタ２３０−２と、更に他のデータ・セグメントの保存先アドレスを指示するポインタ２４０−２と、セグメント・コード２５０−２とを含む。データ・セグメント２００−２は、ルート・セグメントの次のセグメントであるから、セグメント・コード２５０−２は、例えば“０２”に設定される。

データ・セグメント２００−３も、接頭部２１０−３と、データ部２２０−３とを含む。データ・セグメント２００−３は、データ・セグメント２００−１から始まる一連の階層構造の終端部分に位置する。このため、接頭部２１０−３は、下位のセグメントを指すポインタは持たず、同じ親の兄弟を指すポインタのみを持っている。実際には、接頭部２１０−３は、何れのアドレスをも示さない所定のデータ（例えば、Ｎｕｌｌ）を、ポインタ２４０−３として含んでもよい。また、接頭部２１０−３のセグメント・コード２５０−３は、例えば“０３”に設定される。

このように、主データベース２２は、各データ・セグメントの接頭部に記録されたポインタを辿る事により順次他のデータ・セグメントをアクセスできる階層構造を有している。なお、図には示していないが、各データ・セグメント２００のデータ部２２０は、複数のフィールドを含み、ＩＭＳではそのうちの１つまたは複数を索引用の検索フィールドとして指定できるようになっている。

索引データベース２４は、図４に示すような形式の索引セグメント３００が単に記録されているだけで、階層構造にはなっていない。図示の索引セグメント３００は、対応するデータ・セグメントの保存先アドレスを示すポインタ値（例えばＲＢＡ）３１０と、対応するデータ・セグメントを検索するためのキー値３２０と、セグメント・コード（ＳＣ）３３０とを含んでいる。キー値３２０としては、対応するデータ・セグメント中の所定の検索フィールドの値が使用される。例えば、データ・セグメント中に人名フィールドがあって、そこに「佐藤」という名前が記入されていた場合、これを検索キーとして使用したければ、「佐藤」をキー値３２０にすればよい。ただし、実際にキー値３２０として記録されるのは「佐藤」の１６進コード化値である。例えば、メインフレームで使用されているＥＢＣＤＩＣコードの場合、「佐藤」は「x'0E457645680F'」で表される。セグメント・コード３３０は、便宜上ルート・セグメントに対して割り振られるコード値、例えば“０１”を含む。索引セグメント３００においては、ポインタ値３１０およびセグメント・コード３３０が接頭部を構成し、キー値３２０がデータ部を構成している。

次に、本発明に従うデータベース管理システム３０の機能構成例を図５に示す。図示のデータベース管理システム３０は、レコード生成部５０、スキャン・ポイント設定部５２、更新ログ書き出し部５４、レコード修正部５６、および整合性検証部５８を有する。レコード生成部５０は、索引データベース２４から索引セグメント３００を順次に読み出して、ポインタ値およびキー値を含むポインタ・レコードを生成し、更に主データベース２２からデータ・セグメントを順次に読み出して、そのうちの索引の対象となっているデータ・セグメント（索引対象セグメント）の保存先アドレスおよび検索フィールド値を含むセグメント・レコードを生成する。本実施形態では、データ・セグメントの索引付けは、セグメント・コードを指定することによって行われる。従って、主データベース２２から読み出したデータ・セグメントの接頭部２１０にあるセグメント・コード２５０を調べれば、そのデータ・セグメントが索引対象セグメントであるかどうかを判断することができる。

スキャン・ポイント設定部５２は、レコード生成部５０によるポインタ・レコードおよびセグメント・レコードの生成がどこまで進んだかを示すスキャン・ポイントを設定する。これは、例えば、レコード生成部５０が読み出したセグメントのアドレスを保管して、それを読み出しに伴って昇順で順次に更新していくことによって実現できる。ただし、索引セグメントについては、索引データベース２４内で一定の位置（ＲＢＡ）に配置されているとは限らないので、アドレスの代わりにキー値をスキャン・ポイントとして設定するのが好ましい。勿論、索引セグメントの位置が一定であれば、アドレスをスキャン・ポイントとして設定できる。

更新ログ書き出し部５４は、索引データベース２４で索引セグメントが更新されたこと、または主データベース２２で索引対象セグメントが更新されたことに応じ、更新されたセグメントがスキャン・ポイント設定部により設定されたスキャン・ポイントよりも前であることを条件に、更新されたセグメントの更新ログを書き出す。すなわち、更新ログ書き出し部５４は、レコード生成部５０が整合性チェックのために既に読み出したセグメントが更新された場合に、その更新セグメントの更新ログを書き出す。

レコード修正部５６は、更新ログ書き出し部５４が書き出した更新ログに基づいて、レコード生成部５０が生成したポインタ・レコードおよびセグメント・レコードを修正する。整合性検証部５８は、修正後のポインタ・レコードおよび修正後のセグメント・レコードにおいて対応するレコード・エントリ同士を比較することにより索引の整合性を検証して、検証結果を出力する。

次に、図６の流れ図を参照して、図５に示すデータベース管理システム３０の動作について説明する。最初のステップＳ１で、データベース管理システム３０のレコード生成部５０は、主データベース２２および索引データベース２４からそれぞれデータ・セグメントおよび索引セグメントを、ロックをかけて読み出し、セグメント・レコードおよびポインタ・レコードのエントリをそれぞれ作成する。ロックは、データベース全体ではなく、これから読み出そうとする特定のアドレスにのみかけられる。

ポインタ・レコードの構成例を図７に示す。図示のように、ポインタ・レコード７０は、ポインタ値７４およびキー値７６を保管する２つのフィールドを有する。ポインタ値７４およびキー値７６は、読み出した索引セグメントに含まれていたものである。

セグメント・レコードの構成例を図８に示す。図示のように、セグメント・レコード８０は、保存先アドレス８４および検索フィールド値８６を保管する２つのフィールドを有する。保存先アドレス８４は、読み出したデータ・セグメントが保存されていた開始アドレスであり、本実施形態ではＲＢＡが使用されている。検索フィールド値８６は、前述のように、データ・セグメントのデータ部２２０において、検索フィールドとして指定されたフィールドの値である。

なお、図７および図８では、説明の便宜上、各レコード・エントリの記号を同じにしているが、実際には、例えば保存先アドレスＲＢＡ１とポインタ値ＲＢＡ１が同じであるとは限らず、また検索フィールド値Ａとキー値Ａが同じであるとは限らない。他の値についても同様である。

図６に戻って、次のステップＳ２で、データベース管理システム３０のスキャン・ポイント設定部５２は、レコード生成部５０が読み出したデータ・セグメントの保存先アドレスおよび索引セグメントのキー値をデータベース別にそれぞれスキャン・ポイントとして設定する。これらのスキャン・ポイントは、データ・セグメントおよび索引セグメントの読み出しの度に順次更新されていく。

次のステップＳ３で、データベース管理システム３０の更新ログ書き出し部５４は、データベース２０においてデータ・セグメントまたは索引セグメントが更新されたかどうかをチェックし、もし更新されていると、ステップＳ４で、更新されたセグメントのアドレス（またはキー値）が現在のスキャン・ポイントよりも前かどうか、すなわちステップＳ１で読み出しが終わったセグメントが更新されたかどうかを調べる。もし読み出し済みのセグメントが更新されていると、ステップＳ５に進み、さもなければステップＳ６に進む。

ステップＳ５で、更新ログ書き出し部５４は、更新されたセグメントの更新ログを書き出す。図９および図１０に、索引セグメント用の更新ログおよび索引対象セグメント用の更新ログの構成例をそれぞれ示す。図９において、索引セグメント用の更新ログ９０は、ログ番号９２、セグメントＩＤ９４、更新前接頭部９６、および更新後接頭部９８を含む。ログ番号は昇順の連続番号でよい。セグメントＩＤ９４は、更新されたセグメントを特定できるものであればどのような値でもよい。本実施形態のＩＭＳでは、索引セグメントは索引データベース２４内で一定の位置（ＲＢＡ）に配置されているとは限らないため、ＲＢＡ値では索引セグメントを特定することができない。その代わり、キー値は索引データベース２４内で重複なしに割り当てられるので、この値で索引セグメントを特定することが可能である。更新前接頭部９６および更新後接頭部９８は、索引セグメントの更新前および更新後の接頭部の内容、すなわちポインタ値およびセグメント・コードをそれぞれ含む。

図１０において、索引対象セグメント用の更新ログ１００は、ログ番号１０２、セグメントＩＤ１０４、ログタイプ１０６、更新前接頭部１０８、更新後接頭部１１０、および検索フィールド値１１２を含む。ログ番号１０２は、昇順の連続番号でよい。セグメントＩＤ１０４は、更新された索引対象セグメントを特定できるものであればどのようなものでもよい。本実施形態では、索引対象セグメントは主データベース２２内で一定の位置（ＲＢＡ）をしめるので、セグメントＩＤとしてＲＢＡを使用することができる。ログタイプ１０６は、ログがどのような変更データを保持するかを示す。本実施形態では、ログタイプとして、「接頭部および検索フィールド部」（タイプ１）、「接頭部のみ」（タイプ２）、および「検索フィールド部のみ」（タイプ３）の３種類が想定されており、それぞれのタイプによって更新ログの保管情報が異なる。更新前接頭部１０８および更新後接頭部１１０は、索引対象セグメントの更新前後の接頭部の内容をそれぞれ含む。検索フィールド値１１２は、更新された索引対象セグメントの検索フィールドの値である。検索フィールドが更新された場合には、検索フィールドの更新部分または全体が記録される。例えば、検索フィールド値「ＡＢＣ」が「ＡＤＥ」に更新された場合には、検索フィールド値１１２には更新部分の「ＤＥ」のみが、更新部分の開始位置と更新部分の長さとともに記録される、としてもよい。検索フィールド全体を記録することも可能である。

上述のように、更新ログの保管情報はログタイプによって異なる。例えば、セグメント追加に伴う更新ログ・エントリ（タイプ１）は、更新前接頭部１０８、更新後接頭部１１０および検索フィールド値１１２を含むが、セグメント削除に伴う更新ログ・エントリ（タイプ２）は、削除されたセグメントに含まれているポインタ値がわかればよいので、検索フィールド値１１２を含まず（「Ｎ／Ａ」によって示す）、更新前接頭部１０８および更新後接頭部１１０のみが記録され、セグメントの検索フィールドのみの更新に伴う更新ログ・エントリ（タイプ３）は、更新された検索フィールドの値がわかればよいので、更新前接頭部１０８および更新後接頭部１１０を含まない。

更新ログ書き出し部５４は、スキャン・ポイントよりも前の更新がある度に、更新ログを書き足していく。

図６に戻って、ステップＳ５が終了するか、ステップＳ４の判断結果がＮＯの場合は、ステップＳ６に進んで、読み出すべきセグメントが主データベース２２および索引データベース２４に残っているかどうかを調べる。もし残っていればステップＳ１に戻り、さもなければステップＳ７に進む。

ステップＳ７において、データベース管理システム３０のレコード修正部５６は、更新ログ書き出し部５４が書き出した更新ログ９０および１００に基づいて、レコード生成部５０が生成したポインタ・レコード７０およびセグメント・レコード８０をそれぞれ修正する。具体的には、レコード修正部５６は、更新ログ９０および１００の更新内容を１つずつポインタ・レコード７０およびセグメント・レコード８０に反映させていく。例えば、ポインタ・レコード７０に、「ポインタ値＝１０００、キー値＝Ａ」というエントリがあり、セグメント・レコード８０に、「保存先アドレス＝１０００、検索フィールド値＝Ａ」というエントリがあって、更新ログ９０および１００が図１１のようになっていた場合を考えてみる。

図１１の更新ログ９０および１００は、最初に１０００番地のデータ・セグメントおよび対応する索引セグメントが主データベース２２および索引データベース２４からそれぞれ削除され、次に検索フィールド値Ｂを持ったデータ・セグメントが主データベース２２の７０００番地に追加されると共に、キー値Ｂを持った対応する索引セグメントが索引データベース２４に追加され、最後に７０００番地の追加データ・セグメントにおいて検索フィールド値がＢ’に更新されて、そのため索引データベース２４において、キー値がＢの索引セグメントが削除され、代わりにキー値がＢ’の索引セグメントが追加されたことを示している。従って、ポインタ・レコード７０においては、まず「ポインタ値＝１０００、キー値＝Ａ」というエントリが削除され、次に「ポインタ値＝７０００、キー値＝Ｂ」というエントリが追加され、次にこの追加されたエントリが削除され、最後に「ポインタ値＝７０００、キー値＝Ｂ’」というエントリが追加される。セグメント・レコード８０においては、「保存先アドレス＝１０００、検索フィールド値＝Ａ」というエントリが削除され、次に「保存先アドレス＝７０００、検索フィールド値＝Ｂ」というエントリが追加され、最後にこのエントリが「保存先アドレス＝７０００、検索フィールド値＝Ｂ’」に更新される。新たなエントリの追加は、削除されたエントリへの上書きでも構わない。

なお、図１１の例では、主データベース２２の７０００番地にあるデータ・セグメントの検索フィールド値は１回しか更新されていないが、これが複数回更新された場合には、ログ番号を使用してセグメント・レコード８０に対し、古いものから順に更新を適用していく。その際、対応する索引セグメントは、検索フィールド値が更新される度に、古い索引セグメントの削除と新しい索引セグメントの追加が繰り返される。

上述のように、レコード修正部５６は、主データベース２２および索引データベース２４からのセグメントの読み出しが完了した後で、更新ログ９０および１００の内容をポインタ・レコード７０およびセグメント・レコード８０に反映させるものである。当業者であれば、上述の説明から、図１１の更新例以外の更新についても、各レコードの修正を容易に実施できるであろう。なお、データ・セグメントにおける検索フィールド値以外の更新は、索引付けとは関係がなく、また従来の整合性チェック技術で対処できるので、その詳細については省略する。

図６に戻って、レコードの修正が完了すると、ステップＳ８で、データベース管理システム３０の整合性検証部５８は、修正後のポインタ・レコード７０および修正後のセグメント・レコード８０において対応するレコード・エントリ同士を比較することにより索引の整合性を検証する。具体的には、整合性検証部５８は、修正後のポインタ・レコード７０をポインタ値（ＲＢＡ）でソートし、修正後のセグメント・レコード８０を保存先アドレス（ＲＢＡ）でソートする。そして同じＲＢＡを持った、ポインタ・レコード７０のエントリのキー値およびセグメント・レコード８０のエントリの検索フィールド値が同じであれば整合していると判断し、さもなければ整合エラーと判断する。

図１２は、データベース管理システム３０として機能する情報処理装置５００のハードウェア構成の一例を示す。本図においては、情報処理装置５００が、メインフレームと呼ばれる大型汎用計算機である場合を例に、そのハードウェア構成を説明する。情報処理装置５００は、主記憶装置５０２と、少なくとも１つの中央処理装置５０４と、記憶制御部５０６と、チャネル・サブシステム５０８と、少なくとも１つの制御装置５１０と、少なくとも１つの入出力デバイス５１２ａ〜ｄとを備える。

主記憶装置５０２は、入出力デバイス５１２ａ〜ｄから入力したデータ及びプログラムを格納する。そして、主記憶装置５０２は、中央処理装置５０４及びチャネル・サブシステム５０８からアドレスの指定を受けると、そのアドレスに格納しているデータを中央処理装置５０４及びチャネル・サブシステム５０８に送る。主記憶装置５０２は、格納しているデータを高速に読み書き可能であり、この高速な読み書きにより、中央処理装置５０４による高速演算処理が可能となる。

中央処理装置５０４は、情報処理装置５００の全体を制御する中心的な役割を果たし、例えば、少なくとも１つのオペレーティングシステム５０５を実行する。オペレーティングシステム５０５は、情報処理装置５００におけるプログラムの実行及び入出力処理を制御する。例えば、オペレーティングシステム５０５は、中央処理装置５０４上で動作する他のプログラムの実行を制御してもよいし、入出力デバイス５１２ａ〜ｄまでの各々におけるデータ転送を制御してもよい。

記憶制御部５０６は、双方向又は片方向に通信可能なバス５１４を経由して中央処理装置５０４に接続される。記憶制御部５０６は、更に、バス５１６を経由して主記憶装置５０２に接続され、バス５１８を経由してチャネル・サブシステム５０８に接続される。記憶制御部５０６は、例えば、中央処理装置５０４又はチャネル・サブシステム５０８から受けたアクセスリクエストを一時的に格納し（キューイング処理）、所定のタイミングでそのアクセスリクエストを主記憶装置５０２に送信してもよい。

チャネル・サブシステム５０８は、各々の制御装置５１０に対して、データ転送路５２０を経由して接続される。そして、チャネル・サブシステム５０８は、入出力デバイス５１２ａ〜ｄ及び主記憶装置５０２間でのデータ転送を制御する。これにより、中央処理装置５０４が入出力デバイス５１２ａ〜ｄとの間で通信する処理負荷が軽減されるので、中央処理装置５０４による演算処理と、入出力デバイス５１２ａ〜ｄによる入出力処理とを並列に実行させることができ、結果として情報処理装置５００を効率的に動作させることができる。

また、チャネル・サブシステム５０８は、少なくとも１つのチャネルパス５２２により、入出力デバイス５１２ａ〜ｄとデータ転送する。各々のチャネルパス５２２は、チャネル・サブシステム５０８内に設けられたチャネル５２４を有する。また、各々のチャネルパス５２２は、少なくとも１つの制御装置５１０と、データ転送路５２０を有する。ここで、データ転送路５２０は、例えば、ＥＳＣＯＮ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍｓ Ｃｏｎｎｅｃｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ）に基づくシリアルリンクであってもよい。これに代えて、データ転送路５２０は、パラレルＯＥＭＩであってもよいし、ファイバチャネルであってもよい。

制御装置５１０は、入出力デバイス５１２ａ〜ｄの少なくとも１つを制御する。例えば、制御装置５１０は、入出力デバイス５１２ａ〜ｄの各々におけるデータ転送のタイミングを制御してもよい。制御装置５１０は、バス５２６を経由して、入出力デバイス５１２ａ〜ｄの少なくとも１つに接続する。一例として、制御装置５１０は、最大２５６個の入出力デバイスに接続可能である。

入出力デバイス５１２ａ〜ｄの各々は、制御装置５１０、チャネル・サブシステム５０８、及び記憶制御部５０６を順次経由して主記憶装置５０２との間でデータ転送を行う。ここで、入出力デバイス５１２ａは、具体的には、磁気テープドライブであり、入出力デバイス５１２ｄは、ハードディスクドライブである。これに代えて、又はこれに加えて、入出力デバイス５１２ａ〜ｄの各々は、パンチカードリーダ、ディスプレイ、キーボード、プリンタ、通信デバイス、各種センサー、又はその他の記憶装置であってもよい。一例として、入出力デバイス５１２ａ〜ｄの少なくとも何れか１つは、データベース２０と接続され、データベース２０に対するアクセスを行ってもよい。

情報処理装置５００に提供されるプログラムは、テープ記録媒体５３５等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力デバイス５１２ａによって読み出され、チャネル・サブシステム５０８を経由して主記憶装置５０２に格納される。そして、主記憶装置５０２に格納されたプログラムは、再度チャネル・サブシステム５０８を経由して入出力デバイス５１２ｄ（ハードディスクドライブ）にインストールされる。プログラムが情報処理装置５００等に働きかけて行わせる動作は、図１から図１１において説明したデータベース管理システム３０における動作と同一であるから、説明を省略する。

以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク、ＣＤ−ＲＯＭの他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムを情報処理装置５００に提供してもよい。

以上、本発明を実施形態を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明が対象とするデータベース・システムの概略を示す図。 主データベースおよび索引データベースから成るデータベースを示す図。 主データベースの具体的な構成例を示すブロック図。 索引データベースに記録される索引セグメントの形式を示す図。 本発明に従うデータベース管理システムの機能構成例を示すブロック図。 本発明に従うデータベース管理システムの動作を示すフローチャート。 本発明に従うデータベース管理システムのレコード生成部により生成されるポインタ・レコードの一例を示す図。 本発明に従うデータベース管理システムのレコード生成部により生成されるセグメント・レコードの一例を示す図。 本発明に従うデータベース管理システムの更新ログ書き出し部により書き出される索引セグメント用更新ログの一例を示す図。 本発明に従うデータベース管理システムの更新ログ書き出し部により書き出される索引対象セグメント用更新ログの一例を示す図。 本発明に従うデータベース管理システムの更新ログ書き出し部により書き出される索引セグメント用更新ログおよび索引対象セグメント用更新ログの具体例を示す図。 本発明に従うデータベース管理システムとして機能する情報処理装置のハードウェア構成の一例を示すブロック図。

Claims (9)

1. 複数のデータ・セグメントが記録された主データベースおよび複数の索引セグメントが記録された索引データベースを含むデータベースにおいて索引の整合性をチェックするためのシステムであって、
   前記索引データベースから索引セグメントを順次読み出して、ポインタ値およびキー値を含むポインタ・レコードを生成し、前記主データベースからデータ・セグメントを順次読み出して、そのうちの索引の対象となっている索引対象セグメントの保存先アドレスおよび検索フィールド値を含むセグメント・レコードを生成するレコード生成部と、
   前記ポインタ・レコードおよび前記セグメント・レコードの生成がどこまで進んだかを示すスキャン・ポイントを設定するスキャン・ポイント設定部と、
   前記レコード生成部が、前記ポインタ・レコード若しくはセグメント・レコードを生成中に、前記索引データベースで索引セグメントが更新されたこと、または前記主データベースで索引対象セグメントが更新されたことに応じ、更新されたセグメントが前記スキャン・ポイント設定部により設定されたスキャン・ポイントよりも前であることを条件に、前記更新されたセグメントの更新ログを書き出す更新ログ書き出し部と、
   前記レコード生成部が、前記ポインタ・レコード若しくはセグメント・レコードを生成後に、前記更新ログに基づいて前記ポインタ・レコードおよび前記セグメント・レコードを修正するレコード修正部と、
   修正後のポインタ・レコードおよび修正後のセグメント・レコードにおいて対応するレコード・エントリ同士を比較することにより索引の整合性を検証する整合性検証部と、
   を含むシステム。
2. 前記索引対象セグメントは、セグメント・コードおよび検索フィールドを有し、前記索引セグメントは、セグメント・コード、対応する索引対象セグメントのポインタ値および索引付けのためのキー値を有する、請求項１に記載のシステム
3. 前記レコード生成部は、読み出したデータ・セグメントのセグメント・コードから、当該データ・セグメントが索引対象セグメントかどうかを判断する、請求項２に記載のシステム。
4. 前記スキャン・ポイント設定部は、前記レコード生成部が読み出した索引対象セグメントの保存先アドレスおよび前記レコード生成部が読み出した索引セグメントに含まれるキー値をそれぞれスキャン・ポイントとして設定する、請求項１〜３のいずれかに記載のシステム。
5. 前記更新ログ書き出し部は、索引対象セグメントの検索フィールドが更新された場合には、更新された部分および更新の順序を示す情報を前記更新ログに記録する、請求項１〜４のいずれかに記載の方法。
6. 前記レコード修正部は、索引対象セグメントの検索フィールドが更新された場合には、前記セグメント・レコードに対し、前記更新の順序を示す情報に従って更新を順次に適用する、請求項５に記載のシステム。
7. 前記整合性検証部は、修正後のポインタ・レコードをポインタ値でソートし、修正後のセグメント・レコードを保存先アドレスでソートして、それらの値が同じである、ポインタ・レコードのエントリのキー値およびセグメント・レコードのエントリの検索フィールド値が同じであれば整合していると判断し、さもなければ整合エラーと判断する、請求項１〜６のいずれかに記載のシステム。
8. 複数のデータ・セグメントが記録された主データベースおよび複数の索引セグメントが記録された索引データベースを含むデータベースにおいて索引の整合性をチェックするための方法であって、
   コンピュータの有するレコード生成部が、前記索引データベースから索引セグメントを順次読み出して、ポインタ値およびキー値を含むポインタ・レコードを生成するステップと、
   前記レコード生成部が、前記主データベースからデータ・セグメントを順次読み出して、そのうちの前記索引セグメントのポインタ値により示される索引対象セグメントの保存先アドレスおよび検索フィールド値を含むセグメント・レコードを生成するステップと、
   前記コンピュータの有するスキャン・ポイント設定部が、前記ポインタ・レコードおよび前記セグメント・レコードの生成がどこまで進んだかを示すスキャン・ポイントを設定するステップと、
   前記レコード生成部が前記ポインタ・レコード若しくはセグメント・レコードを生成中に、前記コンピュータの有する更新ログ書き出し部が、前記索引データベースで索引セグメントが更新されたこと、または前記主データベースで索引対象セグメントが更新されたことに応じ、更新されたセグメントが前記スキャン・ポイント設定部により設定されたスキャン・ポイントよりも前であることを条件に、前記更新されたセグメントの更新ログを書き出すステップと、
   前記レコード生成部が前記ポインタ・レコード若しくはセグメント・レコードを生成後に、前記コンピュータの有するレコード修正部が、前記更新ログに基づいて前記ポインタ・レコードおよび前記セグメント・レコードを修正するステップと、
   前記コンピュータの有する整合性検証部が、修正後のポインタ・レコードおよび修正後のセグメント・レコードにおいて対応するレコード・エントリ同士を比較することにより索引の整合性を検証するステップと、
   を含む方法。
9. 複数のデータ・セグメントが記録された主データベースおよび複数の索引セグメントが記録された索引データベースを含むデータベースにおいて索引の整合性をチェックするためのプログラムであって、
   請求項８に記載の方法のステップをコンピュータに実行させるためのプログラム。

Images