特開 2024-144901 データベース管理方法、データベース管理プログラムおよび情報処理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024144901

(43)【公開日】2024-10-15

(54)【発明の名称】データベース管理方法、データベース管理プログラムおよび情報処理装置

(51)【国際特許分類】

   G06F 16/22 20190101AFI20241004BHJP

【ＦＩ】

G06F16/22

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2023057072

(22)【出願日】2023-03-31

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002918

【氏名又は名称】弁理士法人扶桑国際特許事務所

(72)【発明者】

【氏名】山地 亮

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175CA07

5B175KA11

(57)【要約】

【課題】インデックス再構築の処理負荷を低減する。
【解決手段】処理部３は、追記型でレコードが更新されるデータベース１０におけるツリー構造のインデックス１１を再構築してツリー構造のインデックス１２を作成するインデックス再構築処理を実行する。このインデックス再構築処理は、インデックス１１のリーフノードに含まれる複数の第１レコードのうち、複数の有効レコードに基づき、インデックス１２のリーフノードに含まれる、複数の有効レコードに応じた複数の第２レコードを作成し、複数の第２レコードの作成が完了した後、複数の第２レコードに基づいて、インデックス１２におけるリーフノードより上位のノードに含まれる複数の第３レコードを作成するインデックス作成処理を含む。
【選択図】図１

【特許請求の範囲】

【請求項1】

追記型でレコードが更新されるデータベースにおけるツリー構造の第１インデックスを再構築してツリー構造の第２インデックスを作成するインデックス再構築処理を、コンピュータが実行し、
前記インデックス再構築処理は、前記第１インデックスのリーフノードに含まれる複数の第１レコードのうち、複数の有効レコードに基づき、前記第２インデックスのリーフノードに含まれる、前記複数の有効レコードに応じた複数の第２レコードを作成し、前記複数の第２レコードの作成が完了した後、前記複数の第２レコードに基づいて、前記第２インデックスにおけるリーフノードより上位のノードに含まれる複数の第３レコードを作成するインデックス作成処理を含む、
データベース管理方法。

【請求項2】

前記インデックス作成処理の実行中において、前記第１インデックスの更新要求が発生すると、前記更新要求に基づいて前記第１インデックスを更新するとともに、更新内容を示す更新情報を記憶部に記録する、
処理を前記コンピュータが実行し、
前記インデックス再構築処理は、前記インデックス作成処理が完了した後、前記記憶部に記録された前記更新情報に基づいて前記第２インデックスを前記第１インデックスと整合させる処理を含む、
請求項１記載のデータベース管理方法。

【請求項3】

前記第２インデックスを整合させる処理では、前記更新情報に基づき、前記インデックス作成処理中に前記第１インデックスのリーフノードに追加されたレコードを、前記第２インデックスのリーフノードに追加する、
請求項２記載のデータベース管理方法。

【請求項4】

前記更新情報は揮発性記憶装置に記録され、
前記第２インデックスを整合させる処理では、前記更新情報が消失した場合、不揮発性記憶装置に記録された、トランザクションのログファイルに基づいて前記第２インデックスを前記第１インデックスと整合させる、
請求項２記載のデータベース管理方法。

【請求項5】

前記インデックス作成処理では、前記複数の第２レコードの作成が完了するまで、前記複数の第３レコードの作成を抑止する、
請求項１記載のデータベース管理方法。

【請求項6】

追記型でレコードが更新されるデータベースにおけるツリー構造の第１インデックスを再構築してツリー構造の第２インデックスを作成するインデックス再構築処理を、コンピュータに実行させ、
前記インデックス再構築処理は、前記第１インデックスのリーフノードに含まれる複数の第１レコードのうち、複数の有効レコードに基づき、前記第２インデックスのリーフノードに含まれる、前記複数の有効レコードに応じた複数の第２レコードを作成し、前記複数の第２レコードの作成が完了した後、前記複数の第２レコードに基づいて、前記第２インデックスにおけるリーフノードより上位のノードに含まれる複数の第３レコードを作成するインデックス作成処理を含む、
データベース管理プログラム。

【請求項7】

追記型でレコードが更新されるデータベースにおけるツリー構造の第１インデックスおよび第２インデックスを記憶する記憶部と、
前記第１インデックスを再構築して前記第２インデックスを作成するインデックス再構築処理を実行する処理部と、
を有し、
前記インデックス再構築処理は、前記第１インデックスのリーフノードに含まれる複数の第１レコードのうち、複数の有効レコードに基づき、前記第２インデックスのリーフノードに含まれる、前記複数の有効レコードに応じた複数の第２レコードを作成し、前記複数の第２レコードの作成が完了した後、前記複数の第２レコードに基づいて、前記第２インデックスにおけるリーフノードより上位のノードに含まれる複数の第３レコードを作成するインデックス作成処理を含む、
情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データベース管理方法、データベース管理プログラムおよび情報処理装置に関する。

【背景技術】

【0002】

データベース管理システムでは、膨大な量のデータを効率的に検索するためにインデックスが用いられる。インデックスとしては、例えば、Ｂ－ｔｒｅｅのような木構造のインデックスが広く用いられている。

【0003】

インデックスを用いたデータベース管理に関しては、次のような提案がある。例えば、最初の１回だけ全ファイルをクロールしてインデックスを作成し、２回目からはイベントの対象となったファイルのみインデックス更新の対象とした全文検索システムが提案されている。また、インデックスファイルの更新を遅延更新モードで行う際に、スタック領域に格納されているインデックス更新情報の中から不要なものを除去するようにしたインデックス更新方式が提案されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００８－３０５３５２号公報

【特許文献2】特開平８－３２８９２４号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、データベースの中には追記型アーキテクチャを用いてテーブルやインデックスが管理されるものがある。このようなデータベースでは、テーブルやインデックスの更新の際に、更新対象のレコードは削除されずに新たなレコードが追加される。このため、テーブルやインデックスのデータ量が増大しやすい。

【0006】

インデックスのデータ量を削減するための方法として、有効レコードだけを用いてインデックスを再構築する方法がある。しかし、インデックスの再構築は処理負荷が高いという問題がある。インデックス再構築の処理負荷が高い場合、例えば、クライアントアプリケーションからのデータベースに対するクエリの処理性能が低下してしまう。

【0007】

１つの側面では、本発明は、インデックス再構築の処理負荷を低減可能なデータベース管理方法、データベース管理プログラムおよび情報処理装置を提供することを目的とする。

【課題を解決するための手段】

【0008】

１つの案では、追記型でレコードが更新されるデータベースにおけるツリー構造の第１インデックスを再構築してツリー構造の第２インデックスを作成するインデックス再構築処理を、コンピュータが実行するデータベース管理方法が提供される。このデータベース管理方法において、インデックス再構築処理は、第１インデックスのリーフノードに含まれる複数の第１レコードのうち、複数の有効レコードに基づき、第２インデックスのリーフノードに含まれる、複数の有効レコードに応じた複数の第２レコードを作成し、複数の第２レコードの作成が完了した後、複数の第２レコードに基づいて、第２インデックスにおけるリーフノードより上位のノードに含まれる複数の第３レコードを作成するインデックス作成処理を含む。

【0009】

また、１つの案では、上記のデータベース管理方法と同様の処理をコンピュータに実行させるデータベース管理プログラムが提供される。
さらに、１つの案では、上記のデータベース管理方法と同様の処理を実行する情報処理装置が提供される。

【発明の効果】

【0010】

１つの側面では、インデックス再構築の処理負荷を低減できる。

【図面の簡単な説明】

【0011】

【図1】第１の実施の形態に係る情報処理装置の構成例および処理例を示す図である。

【図2】第２の実施の形態に係るデータベースシステムの構成例を示す図である。

【図3】ＤＢサーバのハードウェア構成例を示す図である。

【図4】ＤＢサーバおよび業務サーバが備える処理機能の構成例を示す図である。

【図5】インデックスファイルの構成例を示す図である。

【図6】インデックス再構築の全体の処理手順を示すフローチャートの例である。

【図7】インデックス作成処理の比較例を示すフローチャートである。

【図8】インデックス最新化処理の比較例を示す図である。

【図9】第２の実施の形態におけるインデックス作成処理例を示す図である。

【図10】第２の実施の形態におけるインデックス最新化処理を説明するための図である。

【図11】第２の実施の形態におけるインデックス作成処理手順を示すフローチャートの例である。

【図12】第２の実施の形態におけるインデックス更新処理手順を示すフローチャートの例である。

【図13】第２の実施の形態におけるインデックス最新化処理手順を示すフローチャートの例である。

【図14】更新管理情報が消失した場合のインデックス最新化処理例を示す図である。

【発明を実施するための形態】

【0012】

以下、本発明の実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態に係る情報処理装置の構成例および処理例を示す図である。図１に示す情報処理装置１は、記憶部２と処理部３を有する。

【0013】

記憶部２は、情報処理装置１が備える記憶装置に確保される記憶領域である。記憶部２は、情報処理装置１の外部に接続された記憶装置に確保された記憶領域であってもよい。記憶部２には、データベース１０とインデックス１１，１２が記憶される。データベース１０は、追記型でレコードが更新されるリレーショナルデータベースである。インデックス１１，１２は、データベース１０を検索するための情報であり、いずれもツリー構造を有する。データベース１０と同様に、インデックス１１，１２も追記型でレコードが更新される。また、インデックス１２は、処理部３によるインデックス１１の再構築によって作成され、記憶部２に記憶される。

【0014】

処理部３は、例えばプロセッサである。処理部３は、例えば、ＤＢＭＳ（DataBase Management System）用のソフトウェアを実行することでデータベース１０を管理する。処理部３は、インデックス１１を再構築してインデックス１２を作成するインデックス再構築処理を実行する。

【0015】

以下、インデックス再構築処理について説明する。まず、インデックス１１の構成例について説明する。
上記のように、インデックス１１はツリー構造を有する。図１の例では、インデックス１１は、リーフノードにページＰ１～Ｐ３を含み、中間ノードにページＰ４，Ｐ５を含み、ルートノードにページＰ６を含む。

【0016】

ページＰ１はレコードＲ１～Ｒ３を含み、ページＰ２はレコードＲ４，Ｒ５を含み、ページＰ３はレコードＲ６～Ｒ８を含む。レコードＲ１～Ｒ８には、例えばキーが記憶される。ページＰ４は、ページＰ１，Ｐ２に対する上位ノードであり、ページＰ１を管理するためのレコードＲ１１と、ページＰ２を管理するためのレコードＲ１２を含む。ページＰ５は、ページＰ３に対する上位ノードであり、ページＰ３を管理するためのレコードＲ１３を含む。ページＰ６は、ページＰ４，Ｐ５に対する上位ノードであり、ページＰ４を管理するためのレコードＲ２１と、ページＰ５を管理するためのレコードＲ２２を含む。

【0017】

インデックス１１には、追記型でレコードが更新される。例えば、処理部３は、インデックス１１内のあるレコードの更新が要求されると、そのレコードを削除せずに新たなレコードをインデックス１１に追加する。処理部３は、更新前のレコードに対して、無効化されたことを示す削除マークを付加する。

【0018】

このような追記型の処理のため、インデックス１１が更新されるたびにインデックス１１のデータサイズは大きくなり、インデックス１１には削除マークが付加された無効レコードが蓄積されていく。インデックス１１の肥大化を抑止するために、処理部３は、インデックス１１から削除マークが付加されていない有効レコードだけを抽出して新たなインデックス１２を作成するインデックス再構築処理を実行する。インデックス再構築処理では、処理部３は、新たなインデックス１２を作成し、作成されたインデックス１２をデータベース１０の検索のためのインデックスとして設定し直し、元のインデックス１１を削除してインデックス１１のレコードを再利用可能な状態にする。

【0019】

ここで、新たなインデックス１２の作成処理は、例えば次のような手順で実行可能である。処理部３は、インデックス１１のリーフノードから有効レコードを１つ選択し、そのレコードをインデックス１２のリーフノードにコピーする。処理部３は、インデックス１２において、コピーされたレコードに対応する上位ノードのレコードを作成する。処理部３は、このような処理をインデックス１１のリーフノードの有効レコードごとに繰り返す。しかし、このような手順では、記憶部２における離散的な領域に対するアクセス回数が多くなり、処理負荷が大きく、処理にかかる時間も長くなるという問題がある。このような処理負荷の増大は、例えば、クライアントアプリケーションからのデータベース１０に対するクエリの処理性能の低下を招く。

【0020】

このような問題に対して、本実施の形態において、処理部３は次のような手順でインデックス１２を作成する。処理部３はまず、インデックス１１のリーフノードに含まれる複数のレコードのうち、複数の有効レコードに基づき、インデックス１２のリーフノードに含まれる、複数の有効レコードに応じた複数のレコードを作成する。すなわち、作成された複数のレコードには、複数の有効レコードの内容がそれぞれコピーされる。これらのレコード作成が完了した後、処理部３は、作成されたレコードに基づいて、インデックス１２におけるリーフノードより上位のノードに含まれる複数のレコードを作成する。

【0021】

このような手順によれば、最初にリーフノードに含まれる複数のレコードだけが作成されるので、この作成処理中では記憶部２における連続的な記憶領域にアクセスが行われるようになる。その結果、インデックス１２の作成処理負荷を低減することができ、作成処理にかかる時間も短縮することができる。

【0022】

図１の例では、処理部３は、インデックス１１のページＰ１～Ｐ３のうち、有効レコードであるレコードＲ１，Ｒ３～Ｒ５，Ｒ７，Ｒ８に基づいて、インデックス１２のリーフノードのレコードを作成する（ステップＳ１）。インデックス１２では、ページＰ１からコピーされたレコードＲ１，Ｒ３を含むページＰ１１と、ページＰ２からコピーされたレコードＲ４，Ｒ５を含むページＰ１２と、ページＰ３からコピーされたレコードＲ７，Ｒ８を含むページＰ１３がリーフノードに作成される。これらのリーフノードのレコード作成が完了するまでの間、それより上位のノードにおけるレコードの作成は抑止される。

【0023】

そして、インデックス１１のリーフノードのレコード作成が完了した後、処理部３は、上位ノードのレコードを作成する。具体的には、処理部３は、ページＰ１１，Ｐ１２に対応する上位ノードとしてページＰ１４を定義する。処理部３は、ページＰ１１のレコードＲ１，Ｒ３に基づいてページＰ１４に含まれるレコードＲ３１を作成し、ページＰ１２のレコードＲ４，Ｒ５に基づいてページＰ１４に含まれるレコードＲ３２を作成する。また、処理部３は、ページＰ１３に対応する上位ノードとしてページＰ１５を定義し、ページＰ１３のレコードＲ７，Ｒ８に基づいてページＰ１５に含まれるレコードＲ３３を作成する。さらに、処理部３は、ページＰ１４，Ｐ１５に対応する上位ノードとしてページＰ１６を定義する。処理部３は、ページＰ１４のレコードＲ３１，Ｒ３２に基づいてページＰ１６に含まれるレコードＲ４１を作成し、ページＰ１５のレコードＲ３３に基づいてページＰ１６に含まれるレコードＲ４２を作成する。

【0024】

このような手順によれば、最初にリーフノードに含まれるレコードＲ１，Ｒ３～Ｒ５，Ｒ７，Ｒ８だけが作成されるので、この作成処理中では記憶部２における連続的なアクセスが行われるようになる。その結果、インデックス１２の作成処理負荷を低減することができ、作成処理にかかる時間も短縮することができる。

【0025】

なお、実際のインデックス再構築処理では、上記手順によるインデックス１２の作成処理に続いて、インデックス１２の最新化処理が実行される場合がある。例えば、上記手順によるインデックス１２の作成処理中に元のインデックス１１に対する更新を受け付けている場合には、インデックス１２の作成処理中に反映されなかったインデックス１１の更新内容が、インデックス１２に対して反映される。

【0026】

〔第２の実施の形態〕
次に、追記型アーキテクチャが採用されたＤＢＭＳとして、ＰｏｓｔｇｒｅＳＱＬ（Structured Query Language）を例示して説明する。

【0027】

図２は、第２の実施の形態に係るデータベースシステムの構成例を示す図である。図２に示すデータベースシステムは、ＤＢ（データベース）サーバ１００と業務サーバ２００を含む、ＤＢサーバ１００と業務サーバ２００とは、ネットワーク２１０を介して接続されている。

【0028】

ＤＢサーバ１００は、ＤＢＭＳが稼働するサーバコンピュータである。ＤＢサーバ１００は、データベースを管理し、データベースを操作するためのクエリをクライアントアプリケーションから受け付け、クエリに応じた処理を実行する。本実施の形態では、ＤＢサーバ１００は、ＰｏｓｔｇｒｅＳＱＬを用いてデータベースを管理する。

【0029】

業務サーバ２００は、業務アプリケーションを実行するサーバコンピュータである。業務アプリケーションは、ＤＢサーバ１００に対するクライアントアプリケーションの一例であり、ＤＢサーバ１００にクエリを送信してデータベースを操作する。

【0030】

図３は、ＤＢサーバのハードウェア構成例を示す図である。ＤＢサーバ１００は、例えば、図３に示すようなコンピュータとして実現される。図３に示すＤＢサーバ１００は、プロセッサ１０１、ＲＡＭ（Random Access Memory）１０２、ＨＤＤ（Hard Disk Drive）１０３、ＧＰＵ（Graphics Processing Unit）１０４、入力インタフェース（Ｉ／Ｆ）１０５、読み取り装置１０６およびネットワークインタフェース（Ｉ／Ｆ）１０７を備える。

【0031】

プロセッサ１０１は、ＤＢサーバ１００全体を統括的に制御する。プロセッサ１０１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）またはＰＬＤ（Programmable Logic Device）である。また、プロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。なお、プロセッサ１０１は、図１に示した処理部３の一例である。

【0032】

ＲＡＭ１０２は、ＤＢサーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。

【0033】

ＨＤＤ１０３は、ＤＢサーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳプログラム、アプリケーションプログラム、および各種データが格納される。なお、ＨＤＤ１０３は、図１に示した記憶部２の一例である。また、補助記憶装置としては、ＳＳＤ（Solid State Drive）などの他の種類の不揮発性記憶装置を使用することもできる。

【0034】

ＧＰＵ１０４には、表示装置１０４ａが接続されている。ＧＰＵ１０４は、プロセッサ１０１からの命令にしたがって、画像を表示装置１０４ａに表示させる。表示装置１０４ａは、例えば、液晶ディスプレイまたは有機ＥＬ（ElectroLuminescence）ディスプレイである。

【0035】

入力インタフェース１０５には、入力装置１０５ａが接続されている。入力インタフェース１０５は、入力装置１０５ａから出力される信号をプロセッサ１０１に送信する。入力装置１０５ａとしては、キーボードやポインティングデバイスなどを用いることができる。ポインティングデバイスとしては、マウス、タッチパネル、タブレット、タッチパッド、トラックボールなどを用いることができる。

【0036】

読み取り装置１０６には、可搬型記録媒体１０６ａが脱着される。読み取り装置１０６は、可搬型記録媒体１０６ａに記録されたデータを読み取ってプロセッサ１０１に送信する。可搬型記録媒体１０６ａとしては、光ディスク、半導体メモリなどがある。

【0037】

ネットワークインタフェース１０７は、ネットワーク２１０を介して業務サーバ２００などの他の装置との間でデータの送受信を行う。
以上のようなハードウェア構成によって、ＤＢサーバ１００の処理機能を実現することができる。なお、業務サーバ２００も、図３のようなハードウェア構成によって実現することが可能である。

【0038】

図４は、ＤＢサーバおよび業務サーバが備える処理機能の構成例を示す図である。
まず、業務サーバ２００は、業務処理を実行する業務アプリケーション２０１を備える。業務アプリケーション２０１の処理は、業務サーバ２００が備えるプロセッサが所定のアプリケーションプログラムを実行することで実現される。なお、業務アプリケーション２０１は、ＤＢサーバ１００に対応するクライアントアプリケーションの一例である。

【0039】

ＤＢサーバ１００は、共有メモリ部１１０、データ記憶部１２０、サーバ処理部１３１、インデックス再構築部１３２およびＷＡＬ（Write Ahead Logging）書き込み部１３３を備える。

【0040】

共有メモリ部１１０は、ＲＡＭ１０２など、ＤＢサーバ１００が備える揮発性記憶装置に確保される記憶領域であり、サーバ処理部１３１やインデックス再構築部１３２によって共有される。共有メモリ部１１０には、更新管理情報１１１が格納される。更新管理情報１１１には、インデックス再構築処理における新インデックス作成処理中に旧インデックスファイルに対して行われた更新の内容が示す情報が書き込まれる。

【0041】

データ記憶部１２０は、ＨＤＤ１０３など、ＤＢサーバ１００が備える不揮発性記憶装置に確保される記憶領域である。また、データ記憶部１２０は、ＤＢサーバ１００の外部に接続された不揮発性記憶装置に確保される記憶領域であってもよい。データ記憶部１２０には、テーブルファイル１２１ａ，１２１ｂ，・・・、インデックスファイル１２２ａ，１２２ｂ，・・・およびＷＡＬファイル１２３が格納される。

【0042】

テーブルファイル１２１ａ，１２１ｂ，・・・は、それぞれ個別のテーブルのデータを含む。インデックスファイル１２２ａ，１２２ｂ，・・・は、それぞれ個別のインデックスのデータを含む。ＷＡＬファイル１２３には、テーブルファイル１２１ａ，１２１ｂ，・・・およびインデックスファイル１２２ａ，１２２ｂ，・・・におけるトランザクションログが書き込まれる。

【0043】

サーバ処理部１３１、インデックス再構築部１３２およびＷＡＬ書き込み部１３３の処理は、例えば、プロセッサ１０１が所定のプログラムを実行することで実現される。
サーバ処理部１３１は、業務アプリケーション２０１からデータベースを操作するためのクエリを受信し、クエリに応じた処理を実行する。サーバ処理部１３１は、データベースに対するデータの挿入や更新が要求された場合、インデックスファイル１２２ａ，１２２ｂ，・・・を更新し得る。なお、サーバ処理部１３１は、Ｐｏｓｔｇｒｅインスタンスの「サーバプロセス」を実行する処理機能として実装される。

【0044】

インデックス再構築部１３２は、インデックスファイルの有効レコードを用いて新規のインデックスファイルを作成するインデックス再構築処理を実行する。
ＷＡＬ書き込み部１３３は、テーブルファイル１２１ａ，１２１ｂ，・・・やインデックスファイル１２２ａ，１２２ｂ，・・・の操作を含むトランザクションがコミットすると、トランザクションの内容を示すログをＷＡＬファイルに書き込む。

【0045】

なお、インデックス再構築部１３２およびＷＡＬ書き込み部１３３は、Ｐｏｓｔｇｒｅインスタンスの「ワーカプロセス」を実行する処理機能として実装される。
図５は、インデックスファイルの構成例を示す図である。ＰｏｓｔｇｒｅＳＱＬでは、インデックスごとに１つのファイル（インデックスファイル）が作成される。図５に示すインデックスファイル１２２は、上記のインデックスファイル１２２ａ，１２２ｂ，・・・の一例である。また、本実施の形態では、インデックスファイル１２２はＢ－ｔｒｅｅとして形成され、リーフノード、中間ノードおよびルートノードの３階層構造を有する。リーフノードのページ（リーフページ）、中間ノードのページ（中間ページ）およびルートノードのページ（ルートページ）には、１以上のレコードが格納される。

【0046】

図５の例では、インデックスファイル１２２は、リーフノードにリーフページ１４１ａ，１４１ｂを少なくとも含み、中間ノードに中間ページ１４２ａ，１４２ｂを含み、ルートノードにルートページ１４３を含む。リーフページ１４１ａは、キーとしてｋｅｙ１～ｋｅｙ３をそれぞれ含むレコードを含む。リーフページ１４１ｂは、キーとしてｋｅｙ１０１～ｋｅｙ１０３を含むレコードを含む。中間ページ１４２ａは、リーフページ１４１ａの上位ノードとなっており、リーフページ１４１ａに対するポインタが書き込まれたレコードを含む。中間ページ１４２ｂは、リーフページ１４１ｂの上位ノードとなっており、リーフページ１４１ｂに対するポインタが書き込まれたレコードを含む。ルートページ１４３は、中間ページ１４２ａに対するポインタが書き込まれたレコードと、中間ページ１４２ｂに対するポインタが書き込まれたレコードを含む。

【0047】

ところで、ＰｏｓｔｇｒｅＳＱＬでは追記型アーキテクチャが採用されている。インデックスファイルのレコードが更新される場合、更新対象のレコードは削除されずに新たなレコードがインデックスファイルに追加される。このとき、更新前のレコードには無効化されたことを示す削除マークが付加される。

【0048】

このような追記型の処理が行われるため、更新のたびにインデックスファイルには削除マークが付加された無効レコードが蓄積されていき、インデックスファイルのデータサイズは大きくなっていく。インデックスファイルの肥大化は、記憶容量を圧迫するという課題があり、ＳＱＬ性能を低下させる可能性がある。

【0049】

ＰｏｓｔｇｒｅＳＱＬでは、インデックスファイルの肥大化を抑止するために、ＨＯＴ（Heap－Only Tuples）やバキューム（VACUUM）といった機能が実装されている。ＨＯＴは、インデックスファイルのキーを更新しない場合には、参照先の変更のみ実施し、インデックスファイルを直接更新しないようにする機能である。バキュームは、無効レコードを回収し、無効レコードの記憶領域を再利用可能な状態にする機能である。さらに、無効レコードの発生状況などを示す統計情報を収集し、統計情報に基づいてバキューム処理を自動実行するオートバキューム（AUTOVACUUM）も実装されている。

【0050】

しかし、このような機能を用いてもインデックスファイルの肥大化を確実に防止できるとはいえない。インデックスファイルの肥大化を確実に防止するためには、データベースの管理者の操作によって、あるいはインデックスファイルの肥大化や断片化の発生状況の自動解析結果に応じて、インデックス再構築（REINDEX）が適宜実行されることが望ましい。

【0051】

図６は、インデックス再構築の全体の処理手順を示すフローチャートの例である。
［ステップＳ１１］インデックス再構築部１３２は、新規のインデックスファイル（以下、「新インデックスファイル」と記載する）を定義する。

【0052】

［ステップＳ１２］インデックス再構築部１３２は、再構築対象のインデックスファイル（以下、「旧インデックスファイル」と記載する）に含まれる有効レコードを用いて、新インデックスファイルの各レコードを作成する。

【0053】

［ステップＳ１３］このステップの処理は、ステップＳ１２のインデックス作成処理中に旧インデックスファイルの更新を許容する場合に実行される。インデックス再構築部１３２は、現時点での旧インデックスファイルと新インデックスファイルとの差分を検出し、差分を新インデックスファイルに反映させる。これにより、新インデックスファイルが最新化され、旧インデックスファイルとの間の整合がとられる。

【0054】

［ステップＳ１４］インデックス再構築部１３２は、新インデックスファイルを、対応するデータベース（テーブルファイル）を検索するための新規の参照先として登録する。また、インデックス再構築部１３２は、旧インデックスファイルを当該データベースを検索するための参照先から除外する。

【0055】

［ステップＳ１５］インデックス再構築部１３２は、旧インデックスファイルを削除し、旧インデックスファイルに含まれるレコードを再利用可能な状態にする。
ここで、ＰｏｓｔｇｒｅＳＱＬでは、クライアントアプリケーションからのデータベースの操作をインデックス再構築処理中にも可能とする「REINDEX CONCURRENTLY」という機能がある。REINDEX CONCURRENTLYでは、ステップＳ１２のインデックス作成処理中に旧インデックスファイルの更新が要求されると、旧インデックスファイルと新インデックスファイルの両方の更新が行われる。

【0056】

以下、図７、図８を用いて、REINDEX CONCURRENTLYを用いた場合のインデックス作成処理およびインデックス最新化処理の比較例について説明する。
図７は、インデックス作成処理の比較例を示すフローチャートである。図７の処理は、図６のステップＳ１２の処理に対応する。

【0057】

［ステップＳ２１］インデックス再構築部１３２は、旧インデックスファイルのリーフページに含まれる有効レコードを１つ選択し、選択した有効レコードのコピーを新インデックスファイルのリーフページに対して挿入する。

【0058】

［ステップＳ２２］インデックス再構築部１３２は、ステップＳ２１での挿入先ページに対応する上位ノード（中間ノードおよびルートノード）に、レコードを作成する。実際には例えば、ステップＳ２１において新インデックスファイルに新規に作成されたリーフページにレコードが挿入された場合に、当該リーフページに対応する中間ページに当該リーフページを指し示すレコードが作成されてもよい。また、このレコードの作成先が新規に作成された中間ページである場合に、当該中間ページを指し示すレコードがルートページに作成されてもよい。

【0059】

［ステップＳ２３］インデックス再構築部１３２は、旧インデックスファイルのリーフページに含まれる有効レコードのコピーをすべて新インデックスファイルに挿入済みかを判定する。コピーを挿入済みでない有効レコードがある場合、処理がステップＳ２１に進められ、挿入済みでない有効レコードが１つ選択される。一方、すべての有効レコードのコピーが挿入済みの場合、インデックス作成処理が終了される。

【0060】

以上の処理により、無効レコードを含まない、旧インデックスファイルよりデータサイズが縮小された新インデックスファイルが作成される。また、上記の処理手順によれば、新インデックスファイルの木構造を常に保持した状態（リーフノードに追加されたレコードをルートノードから探索可能な状態）で新インデックスファイルの作成処理が実行される。このため、クライアントアプリケーションから旧インデックスファイルの更新が要求された場合に、旧インデックスファイルと新インデックスファイルの両方を更新することが可能となる。

【0061】

ただし、次のケースでは旧インデックスファイルのみ更新可能で、新インデックスファイルを更新できない。１つは、レコードのコピー処理（ステップＳ２１）が実行中のページに対して更新が発生したケースである。他の１つは、新インデックスファイルに対するレコードのコピーが完了していないページに対して更新が発生したケースである。このようなケースでは更新内容が新インデックスファイルに反映されないので、インデックス作成処理が完了した後に新インデックスファイルを最新化する処理が必要となる。

【0062】

図８は、インデックス最新化処理の比較例を示す図である。図８の処理は、図６のステップＳ１３の処理に対応する。
図８は、旧インデックスファイル１２２－１を再構築して新インデックスファイル１２２－２を作成する例を示している。旧インデックスファイル１２２－１は、図５と同様のデータ構造を有しているものとする。また、図７の手順により、新インデックスファイル１２２－２では、リーフページ１５１ａにリーフページ１４１ａの有効レコードがコピーされ、リーフページ１５１ｂにリーフページ１４１ｂの有効レコードがコピーされたとする。ただし、リーフページ１４１ｂのレコード１４１ｂ１は、インデックス再構築処理において新インデックスファイル１２２－２に反映されなかったとする。

【0063】

なお、新インデックスファイル１２２－２には、中間ページ１５２ａ，１５２ｂとルートページ１５３が作成される。中間ページ１５２ａには、リーフページ１５１ａを指し示すレコードが少なくとも書き込まれ、中間ページ１５２ｂには、リーフページ１５１ｂを指し示すレコードが少なくとも書き込まれる。ルートページ１５３には、中間ページ１５２ａを指し示すレコードと、中間ページ１５２ｂを指し示すレコードが書き込まれる。

【0064】

図７の手順で新インデックスファイル１２２－２が作成されると、インデックス再構築部１３２は次のような手順で新インデックスファイル１２２－２を最新化する。インデックス再構築部１３２は、旧インデックスファイル１２２－１のリーフノードをフルスキャンして有効レコードを読み出す。また、インデックス再構築部１３２は、新インデックスファイル１２２－２のリーフノードをフルスキャンしてレコードを読み出す。

【0065】

インデックス再構築部１３２は、旧インデックスファイル１２２－１および新インデックスファイル１２２－２のそれぞれから読み出したレコード同士を突き合わせて、差分レコードを抽出する。この突き合わせでは、例えば、レコードに記録された、テーブルファイル内のデータレコードに対するポインタを示すＴＩＤ（Tuple ID）が比較される。図８の例では、レコード１４１ｂ１が新インデックスファイル１２２－２に存在しないことが検出されるので、インデックス再構築部１３２は、レコード１４１ｂ１を新インデックスファイル１２２－２のリーフページ１５１ｂにコピーする。

【0066】

以上の比較例では、次のような問題がある。
図７に示したインデックス作成処理では、ステップＳ２１～Ｓ２３のループ処理が、旧インデックスファイル１２２－１のリーフノードの有効レコードごとに繰り返される。この処理では、リーフノードのレコードに対するアクセスとそれより上位のノードのレコードに対するアクセスとが繰り返されることになり、記憶装置の離散的な領域に対するアクセス回数が多くなる。このため、処理負荷が大きく、処理にかかる時間も長くなるという問題がある。このような処理負荷の増大は、例えば、クライアントアプリケーションからのクエリの処理性能の低下を招く。

【0067】

また、図８に示したインデックス最新化処理では、差分レコードの抽出のために、新旧両方のインデックスファイルにおいてリーフノードがフルスキャンされる。このため、差分レコードの抽出のために読み出されるデータ量が多くなり、その分だけ処理負荷が大きく、処理にかかる時間も長くなるという問題がある。

【0068】

さらに、上記の比較例では、クライアントアプリケーションからインデックス更新が要求された場合に、旧インデックスファイルと新インデックスファイルの両方が更新される。このため、旧インデックスファイルのみ更新される場合と比較して、クエリに対する応答時間が長くなる。その結果、クライアントアプリケーションの処理（本実施の形態では業務処理）の速度が低下する可能性がある。例えば、ミッションクリティカルな業務処理では、クエリに対する応答性能の低下を許容できない場合がある。

【0069】

一方、クライアントアプリケーションからのインデックス更新要求に対して旧インデックスファイルのみ更新するようにした場合には、インデックス作成処理中に旧インデックスファイルと新インデックスファイルとの間で差分レコードが発生しやすくなる。このため、インデックス作成処理の完了後のインデックス最新化処理において、新インデックスファイルに反映すべきレコード数が増大し、インデックス最新化処理にかかる時間が一層長くなり得るという問題がある。

【0070】

このような問題点に対し、本実施の形態では、クライアントアプリケーションからインデックス更新が要求された場合に旧インデックスファイルのみ更新するようにした上で、以下のような方法でインデックス作成処理およびインデックス最新化処理の負荷を低減する。

【0071】

図９は、第２の実施の形態におけるインデックス作成処理例を示す図である。図９の処理は、図６のステップＳ１２の処理に対応する。また、以下の説明では、旧インデックスファイル１２２－１を再構築して新インデックスファイル１２２－３が作成されるものとする。

【0072】

インデックス再構築部１３２はまず、旧インデックスファイル１２２－１のリーフノードに含まれるすべての有効レコードを、新インデックスファイル１２２－３のリーフノードにコピーする。これにより、新インデックスファイル１２２－３のすべてのリーフノードを作成する。図９の例では、旧インデックスファイル１２２－１のリーフページ１４１ａに含まれる有効レコードが、新インデックスファイル１２２－３のリーフページ１６１ａにコピーされる。また、旧インデックスファイル１２２－１のリーフページ１４１ｂに含まれる有効レコードが、新インデックスファイル１２２－３のリーフページ１６１ｂにコピーされる。ただし、リーフページ１４１ｂのレコード１４１ｂ１（図８参照）は、インデックス作成処理中に旧インデックスファイル１２２－１に追加されたために、新インデックスファイル１２２－３にはコピーされなかったとする。

【0073】

以上のようにリーフノードの作成が完了すると、インデックス再構築部１３２は次に、作成されたリーフノードの各レコードに基づいて新インデックスファイル１２２－３の中間ノードのデータを作成する。図９では例えば、リーフページ１６１ａの上位ノードに中間ページ１６２ａが作成され、リーフページ１６１ａを指し示すレコードが中間ページ１６２ａに書き込まれる。また、リーフページ１６１ｂの上位ノードに中間ページ１６２ｂが作成され、リーフページ１６１ｂを指し示すレコードが中間ページ１６２ｂに書き込まれる。

【0074】

以上のように中間ノードの作成が完了すると、インデックス再構築部１３２は次に、作成された中間ノードの各レコードに基づいて新インデックスファイル１２２－３のルートノードのデータを作成する。図９では、ルートノードにルートページ１６３が作成され、中間ページ１６２ａを指し示すレコードと、中間ページ１６２ｂを指し示すレコードがルートページ１６３に書き込まれる。

【0075】

このような手順によれば、最初に、新インデックスファイル１２２－３のリーフノードに含まれるレコードだけが作成され、その作成中には上位ノードの作成が抑止される。このようなリーフノードのレコード作成では、記憶装置の連続的な記憶領域にアクセスが行われるようになる。その結果、図７に示した比較例より、インデックス作成の処理負荷を低減でき、その処理時間も短縮できる。

【0076】

ここで、前述のように本実施の形態では、上記のインデックス作成処理中にクライアントアプリケーションからインデックス更新が要求された場合には、旧インデックスファイル１２２－１のみ更新され、新インデックスファイル１２２－３は更新されない。このため、インデックス作成処理が完了した時点で、旧インデックスファイル１２２－１と新インデックスファイル１２２－３との間で差分レコードが発生し得る。図９の手順によるインデックス作成処理時間の短縮は、このような差分レコードの発生数を抑制する効果も生み出す。

【0077】

しかし、クライアントアプリケーションからの更新要求に応じて新旧の両方のインデックスファイルを更新する上記比較例に比べると、差分レコードの発生数は増加する可能性が高く、差分レコード発生数の抑制効果は十分とはいえない。そこで、本実施の形態のＤＢサーバ１００は、次の図１０に示すような処理により、インデックス最新化処理にかかる時間を図８に示した比較例より短縮させる。これにより、差分レコードの発生数が増加した場合でも、インデックス再構築処理の全体にかかる時間が長期化することを抑制する。

【0078】

図１０は、第２の実施の形態におけるインデックス最新化処理を説明するための図である。
図１０の初期状態では、旧インデックスファイル１２２－１を基に新インデックスファイル１２２－３を作成する処理が実行中であるとする。この状態から、状態１では、旧インデックスファイル１２２－１に含まれるｋｅｙ１を更新する要求がクライアントアプリケーションから発生したとする。この場合、サーバ処理部１３１は、旧インデックスファイル１２２－１に含まれるｋｅｙ１を更新し、新インデックスファイル１２２－３の更新を抑止する。これとともに、サーバ処理部１３１は、共有メモリ部１１０に格納されている更新管理情報１１１に対して、ｋｅｙ１を更新したことを示す更新情報１１１ａを登録する。

【0079】

また、状態２では、旧インデックスファイル１２２－１に含まれるｋｅｙ２を更新する要求がクライアントアプリケーションから発生したとする。この場合、サーバ処理部１３１は、旧インデックスファイル１２２－１に含まれるｋｅｙ２を更新し、新インデックスファイル１２２－３の更新を抑止する。これとともに、サーバ処理部１３１は、共有メモリ部１１０に格納されている更新管理情報１１１に対して、ｋｅｙ２を更新したことを示す更新情報１１１ｂを登録する。

【0080】

そして、状態３では、インデックス作成処理が完了したとする。すると、インデックス再構築部１３２は、更新管理情報１１１を参照して新インデックスファイル１２２－３の最新化処理を実行する。状態３では、更新管理情報１１１に更新情報１１１ａ，１１１ｂが登録されている。インデックス再構築部１３２は、更新情報１１１ａに基づいてｋｅｙ１の更新を新インデックスファイル１２２－３に反映させる。また、インデックス再構築部１３２は、更新情報１１１ｂに基づいてｋｅｙ２の更新を新インデックスファイル１２２－３に反映させる。

【0081】

例えば、インデックス作成処理中に旧インデックスファイル１２２－１のリーフノードにレコード１４１ｂ１（図８参照）が追加されたとする。この場合、レコード１４１ｂ１が追加されたことを示す更新情報（例として更新情報１１１ａとする）が更新管理情報１１１に登録される。そして、インデックス最新化処理では、更新情報１１１ａに基づいて、新インデックスファイル１２２－３のリーフノードにレコード１４１ｂ１が追加される。

【0082】

このように、インデックス再構築部１３２は、インデックス作成処理が完了したとき、この作成処理の間に更新管理情報１１１に登録された更新情報を読み取るだけで、差分レコードを認識し、インデックス最新化処理を実行可能になる。更新情報は旧インデックスファイル１２２－１の更新が要求された場合にのみ登録されるので、旧インデックスファイル１２２－１および新インデックスファイル１２２－３のそれぞれのリーフノードに含まれるレコード数より明らかに少ない。このため、新旧両方のインデックスファイルのリーフノードをフルスキャンする図８の処理と比較して、差分レコードを認識するために読み出すデータ量を大幅に縮小できる。その結果として、インデックス作成処理にかかる時間を短縮できる。

【0083】

したがって、クライアントアプリケーションからの更新要求に対して旧インデックスファイル１２２－１のみ更新することで差分レコード数が増加した場合でも、インデックス作成処理時間の短縮により、インデックス再構築処理の全体にかかる時間の長期化を抑制できる。

【0084】

次に、本実施の形態におけるインデックス作成処理およびインデックス最新化処理について、フローチャートを用いて説明する。
図１１は、第２の実施の形態におけるインデックス作成処理手順を示すフローチャートの例である。図１１の処理は、図６のステップＳ１２の処理に対応する。

【0085】

［ステップＳ３１］インデックス再構築部１３２は、旧インデックスファイルのリーフページから有効レコードを１つ選択する。インデックス再構築部１３２は、選択した有効レコードのコピーを、新インデックスファイルのリーフページに挿入する。

【0086】

［ステップＳ３２］インデックス再構築部１３２は、旧インデックスファイルのリーフページに含まれる有効レコードのコピーをすべて挿入済みかを判定する。コピーを挿入済みでない有効レコードがある場合、処理がステップＳ３１に進められ、挿入済みでない有効レコードが選択される。一方、該当するすべての有効レコードのコピーを挿入済みである場合、処理がステップＳ３３に進められる。

【0087】

［ステップＳ３３］インデックス再構築部１３２は、新インデックスファイルのリーフページを１つ選択する。インデックス再構築部１３２は、選択したリーフページを管理する中間ページのレコードを作成する。このレコードには少なくとも、選択したリーフページを指し示すポインタが登録される。

【0088】

［ステップＳ３４］インデックス再構築部１３２は、新インデックスファイルの中間ページに含まれる、リーフページを管理するためのレコードをすべて作成済みかを判定する。未作成のレコードがある場合、処理がステップＳ３３に進められ、未作成のレコードの下位ノードに対応するリーフページが１つ選択される。一方、該当するすべてのレコードを作成済みの場合、処理がステップＳ３５に進められる。

【0089】

［ステップＳ３５］インデックス再構築部１３２は、新インデックスファイルの中間ページを１つ選択する。インデックス再構築部１３２は、選択した中間ページを管理するルートページのレコードを作成する。このレコードには少なくとも、選択した中間ページを指し示すポインタが登録される。

【0090】

［ステップＳ３６］インデックス再構築部１３２は、新インデックスファイルのルートページに含まれる、中間ページを管理するためのレコードをすべて作成済みかを判定する。未作成のレコードがある場合、処理がステップＳ３５に進められ、未作成のレコードの下位ノードに対応する中間ページが１つ選択される。一方、該当するすべてのレコードを作成済みの場合、インデックス作成が終了する。

【0091】

図１２は、第２の実施の形態におけるインデックス更新処理手順を示すフローチャートの例である。
［ステップＳ４１］サーバ処理部１３１は、クライアントアプリケーションからのデータベースの操作要求に伴ってインデックスの更新要求が発生すると、インデックスファイルの定義情報に基づいて、更新対象のインデックスファイルを特定する。

【0092】

［ステップＳ４２］サーバ処理部１３１は、特定されたインデックスファイルを更新する。
［ステップＳ４３］サーバ処理部１３１は、特定されたインデックスファイルについてのインデックス作成処理が実行中であるかを判定する。インデックス作成処理が実行中である場合、処理がステップＳ４４に進められ、インデックス作成処理が実行されていない場合、インデックス更新処理が終了する。

【0093】

［ステップＳ４４］サーバ処理部１３１は、ステップＳ４２でのインデックスファイル（旧インデックスファイル）の更新内容を示す更新情報を、共有メモリ部１１０に格納された更新管理情報１１１に書き込む。

【0094】

図１３は、第２の実施の形態におけるインデックス最新化処理手順を示すフローチャートの例である。図１３の処理は、図６のステップＳ１３の処理に対応する。すなわち、ステップＳ１２のインデックス作成処理（図１１の処理）が完了すると、図１３の処理が開始される。

【0095】

［ステップＳ５１］インデックス再構築部１３２は、更新管理情報１１１を参照し、旧インデックスファイルに対応する更新情報があるかを判定する。該当する更新情報がある場合、処理がステップＳ５２に進められ、該当する更新情報がない場合、インデックス最新化処理が終了する。

【0096】

［ステップＳ５２］インデックス再構築部１３２は、旧インデックスファイルに対応する更新情報の中から１つを選択する。インデックス再構築部１３２は、選択した更新情報に基づいて、新インデックスファイルにレコードを作成する。インデックス再構築部１３２は、レコード作成が完了すると、選択した更新情報を更新管理情報１１１から削除する。その後、処理がステップＳ５１に進められる。

【0097】

なお、クライアントアプリケーションからの要求に応じた旧インデックスファイルの更新速度が、インデックス最新化処理における新インデックスファイルに対する更新内容の反映速度より高速になる可能性がある。この場合、インデックス再構築部１３２は、例えば、インデックス最新化のプロセスを多重実行して、新インデックスファイルに対する更新内容の反映速度を高速化してもよい。

【0098】

例えば、インデックス再構築部１３２は、更新管理情報１１１に登録された、旧インデックスファイルに対応する更新情報のサイズ（更新情報の数）を算出する。これとともに、インデックス再構築部１３２は、更新情報を基に更新内容を新インデックスファイルに反映するのにかかる時間を算出する。そして、インデックス再構築部１３２は、算出されたサイズと時間とを基に、新インデックスファイルに対する更新内容の反映速度Ｖ１を算出する。また、インデックス再構築部１３２は、更新管理情報１１１に対する旧インデックスファイルに対応する更新情報の書き込み発生の時間間隔を基に、クライアントアプリケーションからの要求による旧インデックスファイルの更新速度Ｖ２を算出する。そして、インデックス再構築部１３２は、Ｖ２＞Ｖ１の場合に、｛（Ｖ２／Ｖ１）×所定の係数｝で算出される数だけのインデックス最新化のプロセスを生成し、これらのプロセスを並列実行する。

【0099】

ところで、上記の更新管理情報１１１は、揮発性記憶装置に確保される共有メモリ部１１０に格納される。このため、ＤＢサーバ１００の障害発生や停電発生によって、更新管理情報１１１が消失してしまう可能性がある。このような事態が発生した場合、インデックス再構築部１３２は、ＷＡＬファイル１２３を参照して旧インデックスファイルと新インデックスファイルとの間の差分レコードを特定し、新インデックスファイルを最新化する。

【0100】

図１４は、更新管理情報が消失した場合のインデックス最新化処理例を示す図である。
ＷＡＬ書き込み部１３３は、データベースの操作を含むトランザクションがコミットすると、トランザクションの内容を示すログをＷＡＬファイル１２３に書き込む。図１４に示すように、このようなログは、クライアントアプリケーションからの要求に応じて旧インデックスファイル１２２－１が更新される場合にも、インデックス再構築処理によって新インデックスファイル１２２－３が更新される場合にも、ＷＡＬファイル１２３に書き込まれる。

【0101】

図１４では、インデックス作成処理が完了した時点でＤＢサーバ１００に障害が発生し、その後に更新管理情報１１１の更新情報が消失した状態でＤＢサーバ１００が復旧したとする。インデックス再構築部１３２は、ＷＡＬファイル１２３から旧インデックスファイル１２２－１および新インデックスファイル１２２－３に関するログを読み出す。インデックス再構築部１３２は、旧インデックスファイル１２２－１に関するログと新インデックスファイル１２２－３に関するログとを比較することで、差分レコードを判別し、差分レコードの内容を示す更新情報を更新管理情報１１１に登録する。図１４の例では、ログの比較によって旧インデックスファイル１２２－１におけるｋｅｙ１の更新が反映されていないと判定され、その旨を示す更新情報１１１ｃが更新管理情報１１１に登録される。

【0102】

この状態から、インデックス再構築部１３２は図１３に示したインデックス最新化処理を実行する。これにより、更新情報１１１ｃに基づいてｋｅｙ３の更新が新インデックスファイル１２２－３に反映される。このような処理により、更新管理情報１１１の更新情報が消失した場合でも新インデックスファイル１２２－３を最新化し、旧インデックスファイル１２２－１との間でレコードの整合をとることが可能となる。

【0103】

なお、ＰｏｓｔｇｒｅＳＱＬのオートバキュームには、無効レコードの発生状況などを示す統計情報を収集する機能が実装されている。そこで、インデックス再構築部１３２は、この機能によって収集された統計情報を参照して、再構築処理が必要なインデックスファイルを特定し、特定されたインデックスファイルを旧インデックスファイルとしてインデックス再構築を実行することが可能である。これにより、データベースの管理者が再構築処理が必要なインデックスファイルを特定することなく、必要なインデックスファイルを処理対象としたインデックス再構築処理を自動的に実行することが可能となる。

【0104】

また、上記の各実施の形態に示した装置（例えば、情報処理装置１、ＤＢサーバ１００、業務サーバ２００）の処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク（Blu-ray Disc：ＢＤ、登録商標）などがある。

【0105】

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

【0106】

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。

【符号の説明】

【0107】

１ 情報処理装置
２ 記憶部
３ 処理部
１０ データベース
１１，１２ インデックス
Ｐ１～Ｐ６，Ｐ１１～Ｐ１６ ページ
Ｒ１～Ｒ８，Ｒ１１～Ｒ１３，Ｒ２１，Ｒ２２，Ｒ３１～Ｒ３３，Ｒ４１，Ｒ４２ レコード
Ｓ１，Ｓ２ ステップ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】