JPWO2013098918A1 - データベースシステム及びデータベース管理方法 - Google Patents

Abstract

データベースシステムは、記憶デバイスに対するインタフェースと、インタフェースを通じて記憶デバイスにアクセスする制御デバイスとを有する。記憶デバイスは、複数の項目の値を有する行を複数管理する表と、１以上の項目の値により行を特定可能にするための複数のノードによる木構造で構成されたインデクスとを記憶する。制御デバイスは、検索クエリの検索条件に含まれる項目値条件を特定し、項目値条件に対応するインデクスのノードが参照不可であるか否かを判定し、ノードが参照不可である場合に、参照不可のノードが管理する項目値の範囲を特定し、特定した範囲に対して検索条件を満たす行を検索する。

Description

本発明は、表と、表の行（レコード）を検索するためのインデクスとを管理するデータベースシステム及びデータベース管理方法に関する。

データベースには、データベースに格納されている表のレコードを高速に検索できるようにするために、表のレコードについてのインデクスを管理しているものがある。このようなデータベースを管理するデータベースシステムでは、データベースの表を更新する場合には、インデクスも併せて更新するようにしている。

データベースシステムにおいて、インデクスの更新時に、ライトエラーが発生してしまうと、インデクスのデータが壊れてしまい、インデクスを用いて表のレコードの検索を実行することができなくなってしまう虞がある。ここで、インデクスのデータが壊れてしまっている状態を、「論理破壊」ということとする。

このような状況に対して、データベースのサービス提供を停止せずに、データベースを修復する技術が知られている（例えば、特許文献１参照）。

特開２００９−２５２１４８号公報

上記したように、データベースの修復が行われる場合においては、修復しているインデクスを用いた表の検索を実行することができず、表を直に検索することとなり、検索処理に長時間を要することとなる。また、検索処理の負荷が大きくなるので、同じデータベースを利用した他の検索処理の性能に対しても悪影響を及ぼすこととなる。

本発明は、上記課題に鑑みなされたものであり、その目的は、インデクスに論理破壊が発生した場合であっても、適切且つ迅速に検索を実行することのできる技術を提供することにある。

データベースシステムは、記憶デバイスに対するインタフェースと、インタフェースを通じて記憶デバイスにアクセスする制御デバイスとを有する。記憶デバイスは、複数の項目の値を有する行を複数管理する表と、１以上の項目の値により行を特定可能にするための複数のノードによる木構造で構成されたインデクスとを記憶する。制御デバイスは、検索クエリの検索条件に含まれる項目値条件を特定し、項目値条件に対応するインデクスのノードが参照不可であるか否かを判定し、ノードが参照不可である場合に、参照不可のノードが管理する項目値の範囲を特定し、特定した範囲に対して検索条件を満たす行を検索する。

データベースシステムが、前述の記憶デバイスを含んでいても良い。

図１は、実施形態に係るデータベースシステムの処理概要の一例を説明する図である。 図２は、実施形態に係るデータベースシステムを含む計算機システムの一例の構成図である。 図３は、実施形態に係る検索クエリの一例を説明する図である。 図４は、実施形態に係る表の構成の一例を示す図である。 図５は、実施形態に係るインデクスの構成の一例を示す図である。 図６は、実施形態に係るインデクスのノードの構成の一例を示す図である。 図７は、実施形態に係るインデクス段数管理表の一例を示す図である。 図８は、実施形態に係るインデクス管理表の一例を示す図である。 図９Ａは、実施形態に係る検索プログラム情報の構成の一例を示す図である。図９Ｂは、実施形態に係る検索プログラム情報の第１の例を示す図である。図９Ｃは、実施形態に係る検索プログラム情報の第２の例を示す図である。図９Ｄは、実施形態に係る検索プログラム情報の第３の例を示す図である。図９Ｅは、実施形態に係る検索プログラム情報の第４の例を示す図である。図９Ｆは、実施形態に係る検索プログラム情報管理キューの一例を示す図である。 図１０は、実施形態に係る参照不可ノード管理情報の構成の一例を示す図である。 図１１は、実施形態に係るインデクス検索処理の一例のフローチャートである。 図１２は、実施形態に係るノード参照検知処理の一例のフローチャートである。 図１３は、実施形態に係るエントリ参照検知処理の一例のフローチャートである。 図１４は、実施形態に係る参照不可箇所特定処理の一例のフローチャートである。 図１５は、実施形態に係る代替検索プログラム選定処理の一例のフローチャートである。 図１６Ａは、実施形態に係る検索プログラム情報の第１の具体例を示す図である。図１６Ｂは、実施形態に係る検索プログラム情報の第２の具体例を示す図である。図１６Ｃは、実施形態に係る検索プログラム情報の第３の具体例を示す図である。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

なお、以下の説明では、「ａａａ表」の表現にて各種情報を説明することがあるが、各種情報は、表以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ａａａ表」を「ａａａ情報」と呼ぶことができる。

また、以下の説明では、「プログラム」、又は、プログラムのモジュールを主語として処理を説明する場合があるが、プログラムやプログラムモジュールは、制御デバイス（例えばプロセッサ（例えばＣＰＵ（Central Processing Unit）））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インタフェースデバイス（例えばインタフェース）を用いながら行うため、処理の主語が制御デバイスとされてもよい。プログラム、プログラムモジュールを主語として説明された処理は、制御デバイス或いはその制御デバイスを有する装置やシステム（例えば、サーバ装置）が行う処理としても良い。また、制御デバイスは、処理の一部又は全部を行うハードウェア回路を含んでも良い。プログラムは、プログラムソースからインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。

まず、実施形態の処理概要について説明する。

図１は、実施形態に係るデータベースシステムの処理概要の一例を説明する図である。

例えば、外部記憶装置１００１と、サーバ装置２１００とで構成されるデータベースシステムにおいて、インデクス検索部２１２０が、検索クエリ３０１０に対応するインデクスのルートノードや、検索プログラム管理キュー８１００に登録された検索プログラム情報８１１０が示すノードを対象に検索を実行する。この際に、ノード参照検知部２１１３がノード９１００における参照不可を検知し、エントリ参照検知部２１１４がノード９１００のエントリ９１０４における参照不可を検知する。参照不可が検知されると、参照不可箇所特定部２１１５が、ノードの種別（ルートノード、中間ノード、リーフノード）に応じて、参照不可のノードによる検索範囲を特定して、参照不可ノード管理情報１１０００を生成する。

代替検索プログラム選定部２１１６は、参照不可ノード管理情報１１０００に基づいて、参照不可のノードによる検索範囲を検索するための検索プログラム情報を選定する。これにより、インデクス検索部２１２０により、参照不可ノードの検索範囲に対しても適切に検索され、検索結果が得られることとなる。

次に、本発明の一実施形態について、詳細に説明する。

図２は、本発明の一実施形態に係るデータベースシステムを含む計算機システムの構成図である。

計算機システムは、端末装置２１５０と、サーバ装置２１００と、外部記憶装置１００１とを有する。端末装置２１５０と、サーバ装置２１００とは、ネットワーク２１６０を介して接続されている。外部記憶装置１００１は、サーバ装置２１００の内部バス２１０４に接続されている。ここで、サーバ装置２１００と、外部記憶装置１００１とにより、データベースシステムが構成される。

端末装置２１５０は、例えば、データベースシステムを利用するアプリケーションを実行し、サーバ装置２１００に対して、データベース内の表６１００に対する検索要求（検索クエリ）を発行する。

図３は、実施形態に係る検索クエリの一例を説明する図である。

検索クエリ３０１０は、例えば、検索対象の表（６１００等）を指定する表指定記述３０１１と、検索条件を指定する検索条件記述３０１２とが含まれる。図３に示す検索クエリ３０１０は、ＳＱＬを用いた検索クエリの一例であり、表“Ｔ１”を対象として、キー“Ｃ１”の値が“５０”と“２００”との間にあるとの検索条件を満たす行を選択することを要求している。

図２の説明に戻り、外部記憶装置１００１は、表６１００と、インデクス管理表７１００と、インデクス段数管理表１００００と、インデクス４１００、７１１２、７１１３とを格納する。外部記憶装置１００１において、表は、複数備えてもよい。

図４は、実施形態に係る表の構成の一例を示す図である。

表６１００は、行ＩＤ６１０１と、行内容６１０２とを有する行（レコード）を複数格納する。行ＩＤ６１０１は、表６１００内で、行を一意に識別するＩＤを格納する。行内容６１０２は、複数の項目（６１０２、６１０３、６１０４、・・・）を含む。各項目は、項目に対応する値を格納する。図４に示す表名が“Ｔ１”の表６１００は、項目として、Ｃ１、Ｃ２、Ｃ３、・・・等を有する。Ｃ１、Ｃ２、Ｃ３は、例えば、一つで、又は組み合わせて検索用のキーとして用いることができる。

図５は、実施形態に係るインデクスの構成の一例を示す図である。図６は、実施形態に係るインデクスのノードの構成の一例を示す図である。

インデクス（４１００等）は、複数のノード（ページ）９１００により木構造に構成されている。従って、インデクス（４１００等）において、各ノード９１００は、最上位のノードであるルートノードと、最下位のノードであるリーフノードと、ルートノードとリーフノードとの間にある中間ノードとに分けられる。なお、図５では、インデクスのノードの階層は、３段であり、中間ノードについては１段となっているが、ノードの階層は、３段より多くてもよく、その場合には、２以上の段に中間ノードが存在することとなる。

ノード９１００は、図６に示すように、ヘッダ部整合性確認情報９１０１と、前ページ番号９１０２と、後ページ番号９１０３と、エントリ９１０４と、インデクス段数９１０５と、自ページ番号９１０６と、フッタ部整合性確認情報９１０７とを含む。

ヘッダ部整合性確認情報９１０１は、時刻データ等、当該ノードであるページの更新時に一意に決まる値を格納する。ヘッダ部整合性確認情報９１０１に格納される値は、ノードが正常に更新されていれば、フッタ部整合性確認情報９１０７に格納される値と同一となる。

前ページ番号９１０２は、同一の階層における、対応するノードの直前のノード（前ページ）のページ番号を格納する。なお、対応するノードが、階層における先頭である場合には、ナル値が格納される。後ページ番号９１０３は、同一の階層における、対応するノードの直後のノード（後ページ）のページ番号を格納する。なお、対応するノードが、階層における最後尾である場合には、ナル値が格納される。ここで、本実施形態では、インデクスが同一階層においては、キー値の小さいエントリを管理するノードから順に並んでおり、前ページは、当該ページよりもキー値が小さいエントリを管理し、後ページと、当該ページよりもキー値が大きいエントリを管理している。

エントリ９１０４は、当該ノードが、ルートノード又は中間ノードである場合には、当該エントリを示す番号（エントリ番号（エントリ＃））と、当該ノードに接続される直下の階層のノード（下位ノード）のページ番号と、対応する下位ノードで管理するキー値の最大値とを対応付けて格納する。また、エントリ９１０４は、当該ノードが、リーフノードである場合には、エントリ＃と、キー値と、対応するキー値を有する表６１００の行のＩＤ（行ＩＤ）とを対応付けて格納する。エントリ９１０４は、ノード９１００において、１以上備えることができる。本実施形態では、エントリ９１０４は、キー値の最大値に基づいて昇順となるように配置されている。

インデクス段数９１０５は、インデクス４１００における対応するノードの階層の段数を格納する。本実施形態では、リーフノードの段数が１であり、それより上位の階層のノードの段数は、２、３、・・・となる。自ページ番号９１０６は、当該ノードのページ番号を格納する。フッタ部整合性確認情報９１０７は、時刻データ等、当該ノードであるページの更新時に一意に決まる値を格納する。ノードが正常に更新されている場合であれば、ヘッダ部整合性確認情報９１０１に格納される値と同一となる。

図６に示すノード９１００は、図５に示すインデクスにおける２段目の最後（右端）のノードを示しており、当該ノード９１００において、前ページ番号９１０２には、前ページのページ番号である“＃８”が格納され、後ページ番号９１０３には、後ろページがないので、ナル値が設定され、エントリ９１０４としては、ページ番号“＃４”と、当該ページ番号のノードの最大のキー値である“１３０”とが対応付けられたエントリ＃が“０００６”のエントリと、ページ番号“＃３”と、当該ページ番号のノードの最大のキー値である“１６０”とが対応付けられたエントリ＃が“０００７”のエントリと、ページ番号“＃９”と、当該ページ番号のノードの最大のキー値である“２００”とが対応付けられたエントリ＃が“０００８”のエントリとがあり、インデクス段数には、“２”が格納され、自ページ番号には、“＃５”が格納されている。

ここで、例えば、図５に示すページ番号が”＃８”のノード９１００において、論理破壊が発生すると、当該ノード９１００の各エントリ９１０４として格納されている、”＃４”、”＃３”、及び”＃９”のノードに対しては、当該ノード９１００を用いて辿ることができなくなってしまう。

図７は、実施形態に係るインデクス段数管理表の一例を示す図である。

インデクス段数管理表１００００は、各インデクスに対応して設けられる。インデクス段数管理表１００００は、段数１０００１と、ページ番号（＃）１０００２とを含む。段数１０００１は、対応するインデクスに含まれる各段の段数を格納する。本実施形態では、リーフノードの段数を１としている。ページ＃１０００２は、対応する段のノードにおいて、管理しているキー値の最大値が最も小さいノード（ページ）のページ番号を格納する。このインデクス段数管理表１００００によると、各段における先頭のノードを特定することができる。

同図に示すインデクス段数管理表１００００は、図５に示す構成のインデクス“ＩＤＸ１”に対応するインデクス段数管理表１００００であり、３段目においては、ページ＃１が管理しているキー値の最大値が最も小さく、２段目においては、ページ＃８が管理しているキー値の最大値が最も小さく、１段目においては、ページ＃２が管理しているキー値の最大値が最も小さいことを示している。

図８は、実施形態に係るインデクス管理表の一例を示す図である。

インデクス管理表７１００は、表名７１０１と、インデクス名７１０２と、構成列７１０３とを有するレコードを管理する。表名７１０１は、インデクスが対象とする表６１００の名称（表名）を格納する。インデクス名７１０２は、対応するインデクスの名称（インデクス名）を格納する。構成列７１０３は、対応するインデクスを構成している、すなわち、インデクスの対象としている列（項目）を格納する。構成列７１０３は、複数の列を格納してもよい。例えば、インデクス管理表７１００の一番上のレコードは、“Ｔ１”の表６１００の“ＩＤＸ１”のインデクス４１００は、項目“Ｃ１”により構成していることを示しており、インデクス管理表７１００の３番目のレコードは、“Ｔ１”の表６１００の“ＩＤＸ３”のインデクス７１１３は、項目“Ｃ１”及び“Ｃ３”により構成していることを示している。

図２の説明に戻り、サーバ装置２１００は、インタフェース２１０１と、ＣＰＵ２１０２と、メモリ２１０３とを有する。インタフェース２１０１と、ＣＰＵ２１０２と、メモリ２１０３とは、内部バス２１０４を介して接続されている。

インタフェース２１０１は、端末装置２１５０との間の通信を制御する。ＣＰＵ２１０２は、メモリ２１０３に格納されたプログラムを実行することにより各種処理を実行する。

メモリ２１０３は、ＣＰＵ２１０２により実行されるプログラムや、ＣＰＵ２１０２により使用されるデータを記憶する。具体的には、メモリ２１０３は、データベース管理システム（ＤＢＭＳ）２１１０を記憶する。データベース管理システム２１１０は、プログラムモジュールとして、クエリ受付部２１１１と、インデクス検出部２１１２とを記憶する。

クエリ受付部２１１１は、端末装置２１５０から送信された検索クエリ３０１０を受け付ける。クエリ受付部２１１１は、受け付けた検索クエリ３０１０に含まれている検索を実行するための検索条件を含む実行手順を作成する。インデクス検索部２１１２は、ノード参照検知部２１１３と、エントリ参照検知部２１１４と、参照不可箇所特定部２１１５と、代替検索プログラム選定部２１１６とを含む。ノード参照検知部２１１３は、インデクスに対して、ノード単位での排他、又は論理破壊による参照不可を検知する。エントリ参照検知部２１１４は、インデクスに対して、ノード内のエントリ単位での排他、又は論理破壊による参照不可を検知する。参照不可箇所特定部２１１５は、インデクスの論理破壊による参照不可能な箇所のキー値の範囲を特定する。代替検索プログラム選定部２１１６は、インデクスの参照不可能なキー値範囲の検索を実行する代替検索プログラムを選定する。

また、データベース管理システム２１１０は、データとして、検索プログラム情報管理キュー８１００と、参照不可ノード管理情報１１０００とを記憶する。検索プログラム情報管理キュー８１００は、検索時に用いる検索プログラム情報を格納する。参照不可ノード管理情報１１０００は、参照不可ノードに関する情報を格納する。

図９Ａは、実施形態に係る検索プログラム情報の構成の一例を示す図である。図９Ｂは、実施形態に係る検索プログラム情報の第１の例を示す図である。図９Ｃは、実施形態に係る検索プログラム情報の第２の例を示す図である。図９Ｄは、実施形態に係る検索プログラム情報の第３の例を示す図である。図９Ｅは、実施形態に係る検索プログラム情報の第４の例を示す図である。図９Ｆは、実施形態に係る検索プログラム情報管理キューの一例を示す図である。

検索プログラム情報８１１０は、図９Ａに示すように、検索プログラムＩＤ８１１１と、第１領域８１１２と、第２領域８１１３とを含む。検索プログラムＩＤ８１１１は、検索プログラム、又は代替検索プログラムのＩＤを格納する。第１領域８１１２、第２領域８１１３は、検索プログラム情報８１１０の種類に応じて図９Ｂ乃至図９Ｅに示すよう各種情報を記憶する。

通常の検索を行うための検索プログラム情報８１１０は、図９Ｂに示すように、第１領域８１１２は、検索を開始するエントリ（元エントリ）の番号を格納する。第２領域８１１３は、元エントリの親となる親エントリの番号を格納する。

参照不可であるノードに対する検索を代替するための検索（代替検索）を行うための検索プログラム情報８１１０は、図９Ｃに示すように、検索プログラムＩＤ８１１１には、代替検索プログラムを示すＩＤを格納する。第１領域８１１２は、検索を開始するエントリ（元エントリ）の番号を格納する。第２領域８１１３は、元エントリの親となる親エントリの番号を格納する。なお、親エントリが参照不可である場合には、第２領域８１１３には、当該親エントリを参照するエントリの番号を格納する。例えば、元エントリが図５に示すエントリ＃００１８である場合において、ノード＃５が参照不可である場合には、第２領域８１１３には、参照不可であるノード＃５を参照するエントリ＃０００２が格納される。

代替インデクスを用いて代替検索を行うための検索プログラム情報８１１０は、図９Ｄに示すように、検索プログラムＩＤ８１１１には、代替検索プログラムを示すＩＤを格納する。第１領域８１１２は、検索に利用する代替インデクスのルートノード番号（＃）を格納する。第２領域８１１３は、代替インデクスを使用することを示すフラグ（代替インデクス使用フラグ）を格納する。

テーブルを用いて代替検索を行うための検索プログラム情報８１１０は、図９Ｅに示すように、検索プログラムＩＤ８１１１には、代替検索プログラムを示すＩＤを格納する。第１領域８１１２は、テーブル（表）の先頭データページ番号（＃）を格納する。第２領域８１１３は、テーブルスキャンを行うことを示すフラグ（テーブルスキャンフラグ）を格納する。

検索プログラム情報管理キュー８１００は、図９Ｆに示すように、１以上の検索プログラム情報８１１０を格納可能である。検索プログラム情報管理キュー８１００に格納されている検索プログラム情報８１１０は、インデクス検索部２１２０により一つずつ取り出されて実行されることとなる。

図１０は、実施形態に係る参照不可ノード管理情報の構成の一例を示す図である。

参照不可ノード管理情報１１０００は、参照不可ノード検索範囲１１００１と、参照不可ノードノード種別１１００２と、前エントリ番号（＃）１１００３とを格納する。

参照不可ノード検索範囲１１００１は、キー値最小値１１００１ａと、キー値最大値１１００１ｂとを含む。キー値最小値１１００１ａは、参照不可となったノード（参照不可ノード）による検索範囲であるキー値の最小値を格納する。キー値最大値１１００１ｂは、参照不可ノードによる検索範囲であるキー値の最大値を格納する。なお、参照不可ノードがルートノードである場合には、キー値最小値１１００１ａ、キー値最大値１１００１ｂには、ナル値が格納される。

参照不可ノードノード種別１１００２は、参照不可ノードのノード種別を格納する。ノード種別は、ルートノード、中間ノード、リーフノードのいずれかである。

前エントリ番号（＃）１１００３は、参照不可ノードをエントリとして含むノード（親ノード）における前のエントリ（前エントリ）の番号を格納する。ここで、前エントリとは、参照不可ノードの範囲とするキー値よりも小さいキー値を持っている直前のノードのエントリである。なお、前エントリがない場合には、ナル値が格納される。

例えば、図４に示すインデクスにおけるページ＃５のノードが参照不可ノードとなった場合には、参照不可ノード管理情報１１０００は、図１０に示すように、キー値最小値１１００１ａに、“１００”が格納され、キー値最大値１１００１ｂに、“２００”が格納され、参照不可ノードノード種別１１００２に、“中間ノード”が格納され、前エントリ＃１１００３に、“＃０００１”が格納される。

次に、本実施形態のサーバ装置２１００による処理動作について説明する。

図１１は、実施形態に係るインデクス検索処理のフローチャートである。

インデクス検索処理（ステップＳ１００）は、ＣＰＵ２１０２がインデクス検索部２１１２を実行することにより実現される。インデクス検索処理において、ＣＰＵ２１０２が、クエリ受付部２１１１から検索要求を受け取り（ステップＳ１０１）、検索要求に対する初回の検索であるか否か、すなわち、一度でも結果を返したか否かを判定する（ステップＳ１０２）。

この結果、最初の検索である場合（ステップＳ１０２でＹｅｓ）には、ＣＰＵ２１０２は、処理をステップＳ１０５に進める一方、最初の検索でない場合（ステップＳ１０２でＮｏ）には、検索プログラム情報管理キュー８１００から検索プログラム情報８１１０を取得することを試みる（ステップＳ１０３）。

ＣＰＵ２１０２は、検索プログラム情報管理キュー８１００で検索プログラム情報８１１０が枯渇しているか否かを判定する（ステップＳ１０４）。この結果、検索プログラム情報が枯渇している場合（ステップＳ１０４でＹｅｓ）には、検索要求に対応する検索処理を終えたことを意味するので、ＣＰＵ２１０２は、処理を終了する一方、検索プログラム情報８１１０が枯渇していない場合（ステップＳ１０４でＮｏ）には、処理をステップＳ１０５に進める。

ステップＳ１０５では、ＣＰＵ２１０２は、初回検索の場合（ステップＳ１０２でＹｅｓ）には、ルートノードに移動し、検索プログラム情報８１１０を取得した場合には、検索プログラム情報８１１０で指定されているノードに移動する。なお、検索プログラム情報８１１０に代替インデクス使用フラグが設定されている場合には、ＣＰＵ２１０２は、代替インデクスを用いて、検索条件のキーの値に着目して、検索を実行する。例えば、ＣＰＵ２１０２は、参照不可ノード管理情報１１０００の参照不可ノード検索範囲１１００１のキー値の範囲を検索範囲として、代替インデクスを用いて検索を実行する。

次いで、ＣＰＵ２１０２は、対象のノードに対する参照状態を検知するノード参照検知処理を実行する（ステップＳ２００）。

次いで、ＣＰＵ２１０２は、ノード参照検知処理の結果に基づいて、参照不可を検知したか否かを判定し（ステップＳ１０６）、参照不可を検知していない場合（ステップＳ１０６でＮｏ）には、ノード内の最初のエントリをカレントポジションとして記憶し（Ｓ１１５）、ノード内に他のエントリが存在する場合（Ｓ１１６：Ｙｅｓ）、検索条件を満たすエントリが存在する間、ステップＳ１０７〜ステップＳ１１１のループ処理を実行する。

ループ処理においては、ＣＰＵ２１０２は、対象のノードにおける検索条件を満たすエントリを１件取得し（ステップＳ１０８）、当該エントリに対する参照状態を検知するエントリ参照検知処理を実行する（ステップＳ４００）。次いで、ＣＰＵ２１０２は、参照不可を検知していない場合（ステップＳ１０９でＮｏ）には、検索ＩＤを決定し、当該検索ＩＤを含み、取得したエントリのエントリ＃を第１領域８１１２に格納し、現在の元エントリを第２領域８１１３に格納した検索プログラム情報８１１０を作成し、検索プログラム情報管理キュー８１００に登録し（ステップＳ１１０）、ステップＳ１１１に進む。

一方、ノードについて参照不可を検知した場合（ステップＳ１０６でＹｅｓ）又はエントリについて参照不可を検知した場合（ステップＳ１０９でＹｅｓ）には、ＣＰＵ２１０２は、参照不可箇所特定処理を実行し（ステップＳ６００）、代替検索プログラム選定処理を実行し（ステップＳ７００）、ステップＳ１０２に処理を進める。

検索条件を満たすすべてのエントリに対して、ステップＳ１０７〜ステップＳ１１１の処理を実行した場合には、ＣＰＵ２１０２は、対象のノードがリーフノードであるか否かを判定し（ステップＳ１１２）、リーフノードでない場合（ステップＳ１１２でＮｏ）には、他の検索処理を継続するために、ステップＳ１０２に処理を進める一方、リーフノードである場合（ステップＳ１１２でＹｅｓ）には、検索条件を満たす行ＩＤを取得して返却し（ステップＳ１１３）、ステップＳ１０２に処理を進める。

例えば、図１１に示す処理のステップＳ１０３において、図５に示すリーフノード＃４に対する検索をするための検索プログラム情報８１１０（第１領域８１１２にエントリ＃０００６を含み、第２領域８１１３にエントリ＃０００２を含む）を取得した場合には、検索条件が（５０≦キー（Ｃ１）≦２００）であるとすると、図１１に示すステップＳ１１０において、第１領域８１１２にエントリ＃００１９、＃００２０を含む２つの検索プログラム情報が作成されて検索プログラム情報管理キュー８１００に登録され、ステップＳ１１３でエントリ＃００１８に対応する行ＩＤを取得し、当該行ＩＤを検索結果の一部として返す処理が実行される。

図１２は、実施形態に係るノード参照検知処理のフローチャートである。

ノード参照検知処理（ステップＳ２００）は、ＣＰＵ２１０２がノード参照検知部２１１３を実行することにより実現される。ノード参照検知処理において、ＣＰＵ２１０２が、対象のノードに排他がかけられているか否かを確認し（ステップＳ２０１）、さらに、対象のノード９１００のヘッダ部整合性確認情報９１０１の値と、フッタ部整合性確認情報９１０７の値とが一致しているか否かにより、論理的な整合性が取れているか否か、言い換えれば、論理破壊が発生していないか否かを確認する（ステップＳ２０２）。

この確認の結果に基づいて、ＣＰＵ２１０２は、対象ノードが排他又は論理破壊が発生していることにより参照不可であるか否かを判定する（ステップＳ２０３）。判定の結果、参照不可である場合（ステップＳ２０３でＹｅｓ）には、参照不可検知をリターンコードとして設定し（ステップＳ２０４）、処理を終了する一方、参照不可でない場合（ステップＳ２０３でＮｏ）には、そのまま処理を終了する。

図１３は、実施形態に係るエントリ参照検知処理のフローチャートである。

エントリ参照検知処理（ステップＳ４００）は、ＣＰＵ２１０２がエントリ参照検知部２１１４を実行することにより実現される。エントリ参照検知処理において、ＣＰＵ２１０２が、対象のエントリに排他がかけられているか否かを確認し（ステップＳ４０１）、さらに、対象のエントリのキー値について、論理的な整合性が取れているか否か、言い換えれば、論理破壊が発生していないか否かを確認する（ステップＳ４０２）。本実施形態では、対象のエントリ９１０４のキー値が、当該ノード中の前のエントリのキー値より大きく、後ろのエントリのキー値より小さくなっているか否かを確認する。

次いで、ＣＰＵ２１０２は、対象のノードがリーフノードであるか否かを判定し（ステップＳ４０３）、リーフノードでない場合（ステップＳ４０３でＮｏ）には、エントリの下位ノードのページ番号についての整合性を確認する（ステップＳ４０４）。具体的には、ＣＰＵ２１０２は、エントリ９１０４中のページ番号と、エントリ９１０４とポインタで接続されている下位のノード９１００の自ページ番号９１０６のページ番号とが一致しているか否かを確認する。

一方、リーフノードである場合（ステップＳ４０３でＹｅｓ）には、エントリの行ＩＤについての整合性を確認する（ステップＳ４０５）。具体的には、ＣＰＵ２１０２は、エントリ９１０４中の行ＩＤと、エントリ９１０４とポインタで接続されている表６１００の行が持つ行ＩＤ６１０１とが一致しているか否かを確認する。

これらの確認の結果に基づいて、ＣＰＵ２１０２は、対象エントリが排他又は論理破壊が発生していることにより参照不可であるか否かを判定する（ステップＳ４０６）。判定の結果、参照不可である場合（ステップ４０６でＹｅｓ）には、参照不可検知をリターンコードとして設定し（ステップＳ４０７）、処理を終了する一方、参照不可でない場合（ステップＳ４０６でＮｏ）には、そのまま処理を終了する。

図１４は、実施形態に係る参照不可箇所特定処理のフローチャートである。

参照不可箇所特定処理（ステップＳ６００）は、ＣＰＵ２１０２が参照不可箇所特定部２１１５を実行することにより実現される。参照不可箇所特定処理において、ＣＰＵ２１０２が、ノード９１００のインデクス段数９１０５と、インデクス段数管理表１００００とに基づいて、対象のノードのノード種別を求めて、参照不可ノード管理情報１１０００に登録する（ステップＳ６０１）。

次いで、ＣＰＵ２１０２は、対象のノードに、検索プログラム情報８１１０の元エントリがその検索プログラム情報８１１０に存在するか否かを判定する（ステップＳ６０２）。この結果、元エントリが存在しない場合（ステップＳ６０２のＮｏ）には、当該ノードがルートノードであることを意味しているので、ＣＰＵ２１０２は、参照不可ノード管理情報１１０００のキー値最小値１１００１ａと、キー値最大値１１００１ｂにナル値を登録し（ステップＳ６１２）、処理を終了する。なお、元エントリは、検索プログラム情報作成時に、作成される検索プログラム情報に設定されて良い。

一方、元エントリが存在する場合（ステップＳ６０２のＹｅｓ）には、ＣＰＵ２１０２は、元エントリのキー値を、参照不可ノード管理情報１１０００のキー値最大値１１００１ｂに登録し（ステップＳ６０３）、元エントリに対する前エントリが存在するか否かを判定する（ステップＳ６０４）。

この結果、前エントリが存在する場合（ステップＳ６０４でＹｅｓ）には、ＣＰＵ２１０２は、前エントリのキー値を、参照不可ノード管理情報１１０００のキー値最小値１１００１ｂに登録し（ステップＳ６０５）、前エントリのエントリ番号を、参照不可ノード管理情報１１０００の前エントリ＃１１００３に登録し（ステップＳ６０６）、処理を終了する。

一方、前エントリが存在しない場合（ステップＳ６０４でＮｏ）には、ＣＰＵ２１０２は、さらに、元エントリに対する親エントリが検索プログラム情報に存在するか否かを判定し（ステップＳ６０７）、親エントリが存在しない場合（ステップＳ６０７でＮｏ）には、参照不可ノード管理情報１１０００のキー値最小値１１００１ａにナル値を登録し（ステップＳ６０８）、処理を終了する。なお、親エントリは、検索プログラム情報作成時に、作成される検索プログラム情報に設定されて良い。

一方、親エントリが存在する場合（ステップＳ６０７でＹｅｓ）には、ＣＰＵ２１０２は、親エントリに対する前エントリが存在するか否かを判定し（ステップＳ６０９）、親エントリに対する前エントリが存在しない場合（ステップＳ６０９でＮｏ）には、参照不可ノード管理情報１１０００のキー値最小値１１００１ａにナル値を登録し（ステップＳ６０８）、処理を終了する。

一方、親エントリに対する前エントリが存在する場合（ステップＳ６０９でＹｅｓ）には、参照不可ノード管理情報１１０００のキー値最小値１１００１ａに前エントリのキー値を登録し（ステップＳ６１０）、親エントリに対する前エントリのエントリ番号を、参照不可ノード管理情報１１０００の前エントリ＃１１００３に登録し（ステップＳ６１１）、処理を終了する。上記処理により、各ノードにおけるキー値の範囲を適切に参照不可ノード管理情報１１０００に格納することができる。

図１５は、実施形態に係る代替検索プログラム選定処理の一例のフローチャートである。ここで、当該フローチャートの説明において、図１６Ａ乃至図１６Ｃを適宜参照する。図１６Ａは、実施形態に係る検索プログラム情報の第１の具体例を示す図である。図１６Ｂは、実施形態に係る検索プログラム情報の第２の具体例を示す図である。図１６Ｃは、実施形態に係る検索プログラム情報の第３の具体例を示す図である。

代替検索プログラム選定処理（ステップＳ７００）は、ＣＰＵ２１０２が代替検索プログラム選定部２１１６を実行することにより実現される。代替検索プログラム選定処理において、ＣＰＵ２１０２が、参照不可ノード管理情報１１０００からノード種別、ノード検索範囲（キー値の範囲）を取得し（ステップＳ７０１）、対象のノードのノード種別がリーフノードであるか否かを判定する（ステップＳ７０２）。

この結果、対象のノードがリーフノードである場合（ステップＳ７０２でＹｅｓ）には、ＣＰＵ２１０２は、インデクス管理表７１００から当該インデクスと同じ構成列を含むインデクスを代替インデクスとして検索し（ステップＳ７０３）、代替インデクスがあるか否かを判定する（ステップＳ７０４）。

代替インデクスがある場合（ステップＳ７０４でＹｅｓ）には、代替インデクスから参照不可ノードと同様のキー値の範囲を検索するための検索プログラム情報８１１０を作成し（ステップＳ７０５）、ステップＳ７０７に処理を進める。ステップＳ７０５で作成される検索プログラム情報８１１０は、図１６Ａに示すように、
代替検索プログラムＩＤをプログラムＩＤ８１１１に含み、代替インデクスのルートノードのページ番号を第１領域８１１２に含み、代替インデクス使用を示すフラグを第２領域８１１３に含む。

このような検索プログラム情報８１１０をインデクス検索部２１２０が取得すると、既にある他のインデクスの一部を利用して検索する処理を実行することとなるので、迅速に検索を行うことができる

一方、代替インデクスがない場合（ステップＳ７０４でＮｏ）には、表６１００から参照不可ノードと同様のキー値の範囲を検索するための検索プログラム情報を作成し（ステップＳ７０６）、ステップＳ７０７に処理を進める。ステップＳ７０６で作成される検索プログラム情報８１１０は、図１６Ｂに示すように、代替検索プログラムＩＤをプログラムＩＤ８１１１に含み、表６１００の先頭があるページ番号を第１領域８１１２に含み、テーブルをスキャンすること示すフラグを第２領域８１１３に含む。

このような検索プログラム情報８１１０をインデクス検索部２１２０が取得すると、表６１００に対する検索を参照不可ノードと同様のキー値範囲に限って検索を行うので、すべての表６１００から直接検索する場合に比して、検索処理の時間及び負荷を低減することができる。なお、参照不可ノードのキー値範囲は、参照不可ノード管理情報１１０００から取得することができる。

ステップＳ７０７では、作成した検索プログラム情報８１１０を検索プログラム情報管理キュー８１００に登録し、処理を終了する。

一方、リーフノードではない場合（ステップＳ７０２でＮｏ）には、ＣＰＵ２１０２は、対象のノードがルートノードであるか否かを判定する（ステップＳ７０８）。対象のノードがルートノードである場合（ステップＳ７０８でＹｅｓ）には、ＣＰＵ２１０２は、インデクス段数管理表１００００に基づいて、下位ノードに移動し（ステップＳ７０９）、ノード参照検知処理を実行する（ステップＳ２００）。一方、対象のノードがルートノードでない場合（ステップＳ７０８でＮｏ）には、ＣＰＵ２１０２は、インデクス段数管理表１００００、又は前エントリに基づいて、下位ノードに移動し（ステップＳ７１０）、ノード参照検知処理を実行する（ステップＳ２００）。ここで、下位ノードとは、対象のノードが持つエントリが示すすべてのノードを意味している。

例えば、図５に示すインデクスにおいて、ノード＃５が参照不可である場合において、下位ノードに移動する方法としては、ノード＃５の元エントリ（エントリ＃０００２）の前エントリ（エントリ＃０００１）を特定し、当該エントリ＃０００１に基づいて、ノード＃８に移動し、ノード＃８の最後のエントリ（エントリ＃０００５）に基づいて、ノード＃６に移動し、ノード＃６が持つ後ページ＃に基づいて、ノード＃４、すなわち、ノード＃５の下位のノードの中の先頭のノード（直下ノード）に移動する。

ここで、直下ノードに辿る方法としては、以下に示す方法がある。例えば、対象のノードを参照するエントリ（元エントリ）がない場合には、インデクス段数管理表１００００に基づいて、直下ノードまで辿ることができる。また、元エントリが存在し、元エントリの前のエントリ（前エントリ）が存在する場合には、元エントリの前エントリを用いて、直下ノードまで辿ることができる。また、元エントリが存在するが、親エントリが存在しない場合には、インデクス段数管理表１００００に基づいて、直下ノードまで辿ることができる。また、元エントリが存在するが、元エントリの前エントリが存在しない場合であって、親エントリの前エントリが存在する場合には、親エントリの前エントリに基づいて、直下ノードまで辿ることができる。また、元エントリ、親エントリが存在するが、元エントリの前エントリ、及び、親エントリの前エントリが存在しない場合には、インデクス段数管理表１００００に基づいて、直下ノードまで辿ることができる。

次いで、ＣＰＵ２１０２は、ノード参照検知処理の結果に基づいて、参照不可を検知したか否かを判定し（ステップＳ７１１）、参照不可を検知していない場合（ステップＳ７１１でＮｏ）には、参照不可ノードのキー値の範囲内のエントリの数だけ、ステップＳ７１１〜ステップＳ７１６のループ処理を実行する。ここで、ステップＳ７１１〜ステップＳ７１６は、対象とするノードの下位ノードのエントリを対象にして実行される。例えば、図５に示すルートノードであるノード＃１が参照不可の場合には、ノード＃８、ノード＃５のエントリが対象となり、ノード＃５が参照不可の場合には、ノード＃４、ノード＃３、ノード＃９のエントリが対象になる。

ループ処理においては、ＣＰＵ２１０２は、対象のエントリを１件取得して、当該エントリに対する参照状態を検知するエントリ参照検知処理を実行する（ステップＳ４００）。
次いで、ＣＰＵ２１０２は、参照不可を検知していない場合（ステップＳ７１３でＮｏ）には、キー値が検索条件に合致しているか否かを判定し（ステップＳ７１４）、検索条件に合致している場合には、検索ＩＤを決定し、当該検索ＩＤを含み、当該エントリのエントリ＃を第１領域８１１２に格納した検索プログラム情報８１１０を作成し、検索プログラム情報管理キュー８１００に登録し（ステップＳ７１５）、ステップＳ７１６に進む。

ここで、例えば、ノード＃５が参照不可である場合においては、ステップＳ７１１〜ステップＳ７１６のループ処理によって、図１６Ｃに示すように、第１領域８１１２に、ノード＃４以降のノードのエントリであって、検索条件を満たすエントリの全てエントリ、すなわち、エントリ＃００１８からエントリ００２６＃のそれぞれのエントリに対する検索をするための検索プログラム情報８１１０が作成される。

一方、ノードについて参照不可を検知した場合（ステップＳ７１１でＹｅｓ）又はエントリについて参照不可を検知した場合（ステップＳ７１３でＹｅｓ）には、ＣＰＵ２１０２は、参照不可箇所特定処理を実行し（ステップＳ６００）、代替検索プログラム選定処理を実行し（ステップＳ７００）、処理を終了する。

参照不可ノードのキー値の範囲内のすべてのエントリに対して、ステップＳ７１２〜ステップＳ７１６の処理を実行した場合には、ＣＰＵ２１０２は、対象のノードがリーフノードであるか否かを判定し（ステップＳ１１１）、処理を終了する。この処理により、参照不可ノードによる検索範囲について、検索を適切に実行することができるようになる。

以上、実施形態を説明したが、本発明は、この実施形態に限定されるものでなく、その趣旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

例えば、上記実施形態では、インデクスをキー値の小さい方から検索する構成としていたが、例えば、キー値の大きい方から検索する構成としてもよい。この場合には、各ノードは、下位の各ノードのエントリとして、各ノードのキー値の最小値を管理するようにし、同一の段においては、大きいキー値を管理するノードが前のノードとなるようにし、インデクス段数管理表では、各段のキー値の最大値を管理するページ番号を管理するようにすればよい。このようにした場合には、参照不可ノードが中間ノードであれば、参照不可ノードよりも大きいキー値を管理する隣接するノードを辿って、参照不可ノードの下位ノードを特定するようにすればよい。

また、上記実施形態では、検索プログラム情報を一つずつ取り出して、逐次実行する例を示していたが、本発明はこれに限られず、例えば、検索プログラム情報を複数取り出して、それぞれに基づいた検索を並行して実行するようにしてもよい。

２１００：サーバ装置、１００１：外部記憶装置、２１５０：端末装置

Claims (15)

1. 記憶デバイスに対するインタフェースと、
   前記インタフェースを通じて前記記憶デバイスにアクセスする制御デバイスと
   を有し、
   前記記憶デバイスが、複数の項目の値を有する行を複数管理する表と、１以上の前記項目の値により前記行を特定可能にするための複数のノードを含む木構造で構成されたインデクスとを記憶し、
   前記制御デバイスは、
   前記表に対する検索クエリの検索条件に含まれる項目値条件を特定し、
   前記項目値条件に対応する前記インデクスの前記ノードが参照不可であるか否かを判定し、
   前記ノードが参照不可である場合に、前記参照不可のノードが管理する項目値の範囲を特定し、特定した前記範囲に対して前記検索条件を満たす行を検索する
   データベースシステム。
2. 前記制御デバイスは、
   前記参照不可のノードが、前記インデクスにおける中間ノードである場合に、前記ノードと同じ段における直前のノードが管理する項目値に基づいて、前記参照不可のノードが管理する項目値の範囲を特定する
   請求項１に記載のデータベースシステム。
3. 前記制御デバイスは、
   前記参照不可のノードが、前記インデクスにおける中間ノードである場合に、前記参照不可のノードの下位のノードを特定し、
   前記下位のノードを用いて、前記特定した前記範囲に対して前記検索条件を満たす行を検索する
   請求項２に記載のデータベースシステム。
4. 前記記憶デバイスは、前記インデクスの各段における先頭のノードのノード番号を含む段数管理情報を記憶し、
   前記制御デバイスは、
   前記参照不可のノードが、前記インデクスにおける中間ノードである場合に、前記参照不可のノードの上位のノードの、前記参照不可のノードの直前のノードのエントリがあれば、当該エントリに従って前記直前のノードを経由して下位のノードを特定し、
   前記参照不可のノードの直前のノードのエントリがなければ、前記段数管理情報に基づいて、下位の段のノードを特定し、特定したノードを経由して下位のノードを特定する
   請求項３に記載のデータベースシステム。
5. 前記制御デバイスは、
   前記参照不可のノードが、ルートノードである場合に、前記段数管理情報に基づいて、下位の最前のノードを特定し、特定したノード及び当該ノードから接続された各ノードを用いて、前記検索条件を満たす行を検索する
   請求項１に記載のデータベースシステム。
6. 前記記憶デバイスは、前記インデクスが対象とする１以上の前記項目を含む複数項目について対象とする他のインデクスを記憶し、
   前記制御デバイスは、
   前記参照不可のノードが、リーフノードである場合に、前記他のインデクスに基づいて、前記参照不可のノードと同じ項目値の範囲を検索する
   請求項１に記載のデータベースシステム。
7. 前記ノードは、ヘッダと、フッタとに、整合性確認用の情報を格納するように管理されており、
   前記制御デバイスは、
   前記ノードの前記ヘッダの整合性確認用の情報と、前記フッタの整合性確認用の情報とに基づいて、当該ノードが参照不可か否かを判定する
   請求項１に記載のデータベースシステム。
8. 前記ノードに排他がかけられているか否かに基づいて、当該ノードが参照不可か否かを判定する
   請求項１に記載のデータベースシステム。
9. 前記ノードは、当該ノードに接続される下位のノードのページ番号又は、当該ノードに接続される行を示す行ＩＤと、項目の値とを含む１以上のエントリを、前記エントリの前記項目の値に従って並べて格納し、
   前記制御デバイスは、
   前記ノードの前記エントリが前記項目の値に従って並んでいるか否かに基づいて、当該ノードが参照不可であるか否かを判定する
   請求項１に記載のデータベースシステム。
10. 前記ノードは、前記下位のノード又は前記接続されている行に対するポインタが設けられており、
    前記制御デバイスは、
    前記ポインタにより対応付けられているノードのページ番号又は行の行ＩＤと、前記ノードが格納しているページ番号又は行ＩＤとが一致しているか否かにより、前記ノードが参照不可であるか否かを判定する
    請求項１に記載のデータベースシステム。
11. 前記制御デバイスは、前記ポインタにより対応付けられている前記ノードに排他がかけられているか否かに基づいて、当該ノードが参照不可か否かを判定する
    請求項１に記載のデータベースシステム。
12. 検索対象とするノード又は行を示す１以上の検索プログラム情報を格納可能な検索プログラム情報キューを有し、
    前記制御デバイスは、前記検索プログラム情報キューから逐次前記検索プログラム情報を取得し、
    前記取得した検索プログラム情報が示す前記ノードが参照不可であるか否かを判定し、
    前記ノードから参照不可でなく、且つ検索条件に該当するエントリを検出した場合に、当該エントリを検索対象とするための検索プログラム情報を出力して、前記検索プログラム情報キューに登録する
    請求項１に記載のデータベースシステム。
13. 前記制御デバイスは、
    前記参照不可のノードの下位のノードから、参照不可でなく、且つ検索条件に該当するエントリを検出した場合に、当該エントリを検索対象とするための検索プログラム情報を出力して、前記検索プログラム情報キューに登録する
    請求項１２に記載のデータベースシステム。
14. 前記制御デバイスは、
    複数の前記検索プログラム情報に基づいた処理を並行して実行する
    請求項１２に記載のデータベースシステム。
15. 複数の項目の値を有する行を複数管理する表と、１以上の前記項目の値により前記行を特定可能にするための複数のノードを含む木構造で構成されたインデクスとを記憶する記憶デバイスにおけるインデクスを用いて前記表を検索するデータベース管理方法であって、
    前記表に対する検索クエリの検索条件に含まれる項目値条件を特定し、
    前記項目値条件に対応する前記インデクスの前記ノードが参照不可であるか否かを判定し、
    前記ノードが参照不可である場合に、前記参照不可のノードが管理する項目値の範囲を特定し、特定した前記範囲に対して前記検索条件を満たす行を検索する
    データベース管理方法。

Images