JP4522170B2

JP4522170B2 - リレーショナルデータベースのインデックス追加プログラム，インデックス追加装置及びインデックス追加方法

Info

Publication number: JP4522170B2
Application number: JP2004196488A
Authority: JP
Inventors: 寿昭千田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2004-07-02
Filing date: 2004-07-02
Publication date: 2010-08-11
Anticipated expiration: 2024-07-02
Also published as: US20060004840A1; JP2006018632A

Description

本発明は、インデックスを用いてアクセスを高速化したリレーショナルデータベース（以下「データベース」という）において、アプリケーションに対するサービスを停止させずに、新たなインデックスを動的かつ効率良く追加可能にする技術に関する。

ＳＱＬ（Structured Query Language）文によりデータベースのアクセスを高速化する一般的な手法として、BTREE（二分木）型のインデックスを利用する技術が公知である。データベースを使用したシステム設計においては、アプリケーションから発行されるＳＱＬ文に応じたインデックスの設計が行われる。そして、システム運用開始前に、データベース上で実際にインデックスの定義及び創成が行われる。一方、システム運用開始後においては、サービス拡張などによるＳＱＬ文の追加に伴って、新たなインデックスの追加が必要となる場合がある。しかも、データベースを使用したシステムでは、２４時間連続運用が一般的であることから、アプリケーションによる表（テーブル）の更新中に、その表に対して新たなインデックスを追加可能であることが要求される。

更新中の表にインデックスを追加する手法として、“Oracle9i DatabaseとIBM DB2 UDBの技術比較：高可用性”（非特許文献１）に記載されるように、インデックス創成中の表の更新ログを蓄積し、インデックス創成後に表の更新ログを反映させる技術が実用化されている。
Jenny Tsai，"Oracle9i DatabaseとIBM DB2 UDBの技術比較：高可用性"，［online］，2002年2月，Oracle Corporation，［平成16年6月14日検索］，インターネット＜URL:http://otndnld.oracle.co.jp/products/iserver/oracle9i/pdf/cwp_9ivsdb2_ha_j.pdf＞

しかしながら、かかる実用化技術であっても、表の更新ログをインデックスに反映させるときに、アプリケーションに対するサービスを一時的に停止させなければならず、システムの２４時間連続運用は極めて困難であった。また、インデックス創成に長時間要すると、表の更新ログの容量も多くなり、これをインデックスに反映させるための時間、即ち、サービス停止時間が長くなるおそれもあった。さらに、アプリケーションに対するサービス停止を回避すべく、表の更新ログをインデックスに反映させているときに、表の更新ログをさらに蓄積することが考えられるが、更新ログの蓄積及びその反映がいつまでたっても完了しないおそれもあった。

そこで、本発明は以上のような従来の問題点に鑑み、インデックスに対する更新ログの反映方法を工夫することで、アプリケーションに対するサービスを停止させずに、新たなインデックスを動的かつ効率良く追加可能にする技術を提供することを目的とする。

このため、本発明に係るインデックス追加技術では、リレーショナルデータベースのインデックス初期創成中には、リレーショナルデータベースに対する更新ログを蓄積する。一方、インデックス初期創成後には、リレーショナルデータベースに対する更新依頼に対応するデータがインデックスに存在していれば、その更新依頼をインデックスに反映させる一方、更新依頼に対応するデータがインデックスに存在していなければ、その更新依頼を作業領域に格納する。また、更新ログをインデックスに順次反映させるときに、更新ログに対応するデータが作業領域に格納されていれば、その更新ログを無視する一方、更新ログに対応するデータが作業領域に格納されていなければ、その更新ログをインデックスに反映させる。

本発明によれば、インデックス初期創成後には、リレーショナルデータベースに対する更新依頼は、インデックスに対応データがあれば直接反映される一方、インデックスに対応データがなければ作業領域に格納される。また、インデックス初期創成中に蓄積された更新ログは、対応データが作業領域に格納されていれば、インデックスに対する更新順序が逆転したと判断し、挿入及び削除がこの順番で行われたために何ら影響を及ぼさないことに鑑み、これを無視する。一方、更新ログが作業領域に格納されていなければ、インデックスに対する更新順序が保証されたと判断し、その更新ログをインデックスに反映させる。

このため、更新ログをインデックスに反映させるときに、作業領域を参照することで、インデックスに対する処理順序が保証されることから、アプリケーションに対するサービスを停止させずに、新たなインデックスを動的かつ効率良く追加することができる。

以下、添付された図面を参照して本発明を詳述する。
図１は、少なくとも中央処理装置（ＣＰＵ）とメモリとを備えたコンピュータシステムに対して本発明を適用し、データベースのインデックス追加装置（以下「インデックス追加装置」という）を構築した全体構成を示す。インデックス追加装置は、メモリにロードされたインデックス追加プログラムにより実現される各種機能、即ち、アプリケーション１０，インデックス創成処理部２０及びインデックス創成デーモン（daemon）３０を含んで構成される。そして、インデックス追加装置では、後述するように、「インデックス初期創成処理」及び「ログ反映処理」という２つの処理を順次実行することで、アプリケーション１０に対するサービスを停止させずに、新たなインデックスが動的かつ効率良く追加される。

アプリケーション１０は、ＳＱＬ文を用いて、データベース（ＤＢ）４０を構成する２次元の表に対して、削除，追加又は更新などの表更新を行う。このとき、ディスク障害などによるＤＢ４０の破壊に備えたバックアップデータとして、ある時点の表データを退避したダンプファイル５０Ａと、表に対する更新内容を記録したアーカイブログファイル５０Ｂと、が適宜取得される。ここで、ダンプファイル５０Ａ及びアーカイブログファイル５０Ｂからバックアップデータを構成することで、極力少ない記憶容量で任意時点におけるＤＢ４０を再現することができる。

インデックス創成処理部２０は、インデックス初期創成処理において、図２に示すように、ダンプファイル５０Ａ及びアーカイブログファイル５０Ｂを読み込んで表６０を作成した後、キーレコードを抽出して第２の作業領域としての作業ファイル７０に格納すると共に、作業ファイル７０に格納されたキーレコードから新たに追加するインデックス８０を初期創成する。また、インデックス創成処理部２０は、ログ反映処理において、図３に示すように、インデックス初期創成処理中における表更新内容が格納されたログファイル９０をインデックス８０に反映させる。

ここで、キーレコードは、図４に示すように、インデックスを構成するカラムデータを示す「キー値」と、対象データの格納位置を特定すべく一意な値をとる「ＴＩＤ」と、インデックスの挿入又は削除を示す「操作種別」と、を含んで構成される。なお、ダンプファイル５０Ａ及びアーカイブログファイル５０Ｂから作成されたキーレコードは、操作種別が常に「挿入」となる。また、キーレコードの更新は、「削除」及び「挿入」で表現する。

インデックス創成デーモン３０は、インデックス初期創成処理において作業ファイル７０に対するキーレコードの格納が完了するまでの間、図２に示すように、アプリケーション１０からの依頼に対応したキーレコードを作業ファイル７０にマージしつつ、キー値に基づいてキーレコードをソートする。また、インデックス創成デーモン３０は、インデックス初期創成処理においてキーレコードの格納が完了した後には、アプリケーション１０からの依頼に対応したキーレコードをログファイル９０に格納する。一方、インデックス創成デーモン３０は、ログ反映処理において、図３に示すように、アプリケーション１０からの依頼に応じて、表の更新内容をインデックス８０に直接反映するか、第１の作業領域又は作業領域としての作業インデックス１００に格納する。

次に、かかる構成からなるインデックス追加装置の動作について説明する。
図５は、インデックス創成処理部２０において、ユーザ指示又は所定スケジュールに応じて実行される処理内容のメインルーチンを示す。
ステップ１（図では「Ｓ１」と略記する。以下同様）では、動作環境を作成する。
ステップ２では、アプリケーション１０に対して創成処理開始を通知する。

ステップ３では、アプリケーション１０との同期をとるべく、アプリケーション１０からの認識通知を受信する。
ステップ４では、インデックス初期創成処理を行うサブルーチン（図６参照）をコールする。
ステップ５では、ログ反映処理を行うサブルーチン（図７参照）をコールする。

ステップ６では、アプリケーション１０に対して創成処理完了を通知する。
ステップ７では、アプリケーション１０との同期をとるべく、アプリケーション１０からの認識通知を受信する。
ステップ８では、動作環境を回収する。
図６は、インデックス初期創成処理のサブルーチンを示す。

ステップ１１では、インデックス創成デーモン３０に対して初期創成開始を通知する。
ステップ１２では、ダンプファイル５０Ａ及びアーカイブログファイル５０Ｂを夫々読み込む。
ステップ１３では、読み込んだダンプファイル５０Ａ及びアーカイブログファイル５０Ｂから、インデックス初期創成処理開始時点におけるＤＢ４０の内容を再現した表６０を作成する。

ステップ１４では、作成された表６０からキーレコードを抽出し、キーレコードを作業ファイル７０に格納する。
ステップ１５では、インデックス創成デーモン３０における処理を切り替えるべく、インデックス創成デーモン３０に対して読込完了を通知する。
ステップ１６では、インデックス創成デーモン３０との同期をとるべく、インデックス創成デーモン３０からの切替完了通知を受信する。

ステップ１７では、ソートされた状態で作業ファイル７０に格納されたキーレコードから、新たに追加するインデックス８０を初期創成する。このとき、キー値及びTIDが同一のキーレコードについて挿入及び削除が行われたときには、インデックス８０に何ら影響を与えないことに鑑み、これらを無視することで、インデックス初期創成効率を向上させることができる。なお、ステップ１２，１３，１４及び１７の一連の処理が、初期創成手段に該当する。

ステップ１８では、アプリケーション１０及びインデックス創成デーモン３０における処理を切り替えるべく、両者に対して初期創成完了を夫々通知する。
ステップ１９では、インデックス創成デーモン３０との同期をとるべく、インデックス創成デーモン３０からの切替完了通知を受信する。
図７は、ログ反映処理のサブルーチンを示す。

ステップ２１では、ログファイル９０から、時系列的に最も古い時点におけるキーレコードを１つ取り出す。
ステップ２２では、キーレコードに基づいてトランザクションを組み立てる。
ステップ２３では、作業インデックス１００を参照する。
ステップ２４では、取り出したキーレコードに対応するデータ、即ち、キー値及びTIDが同一のキーレコードが作業インデックス１００に格納されているか否かを判定する。そして、対応するデータが格納されていなければステップ２５へと進む一方（Ｙｅｓ）、対応するデータが格納されていればステップ２１へと戻る（Ｎｏ）。ここで、作業インデックス１００は、インデックス８０に対して、ログファイル９０に格納されているキーレコードを反映してよいか否かを判定するために利用される。

ステップ２５では、取り出したレコードに基づいてインデックス８０を更新する。
ステップ２６では、ログ反映処理が完了したか否か、即ち、ログファイル９０に格納されているすべてのキーレコードの処理が完了したか否かを判定する。そして、ログ反映処理が完了したならばステップ２７へと進み（Ｙｅｓ）、インデックス創成デーモン３０に対してログ反映完了を通知する。一方、ログ反映処理が完了していなければ、次のキーレコードを処理すべくステップ２１へと戻る（Ｎｏ）。なお、ステップ２１〜２６の一連の処理が、ログ反映手段に該当する。

図８及び図９は、インデックス創成デーモン３０において、所定時間ごとに繰り返し実行される処理内容を示す。
ステップ３１では、インデックス創成処理を開始すべきか否かを判定すべく、インデックス創成処理部２０から初期創成開始通知があったか否かを判定する。そして、初期創成開始通知があればステップ３２へと進む一方（Ｙｅｓ）、初期創成開始通知がなければ待機する（Ｎｏ）。

ステップ３２では、アプリケーション１０からの依頼を受信する。
ステップ３３では、受信した依頼が表更新依頼であるか否かを判定する。そして、表更新依頼であればステップ３４へと進む一方（Ｙｅｓ）、表更新依頼でなければステップ３６へと進む（Ｎｏ）。
ステップ３４では、受信した依頼から、表更新に係るキーレコードを抽出する。

ステップ３５では、抽出したキーレコードを作業ファイル７０にマージしつつ、作業ファイル７０に格納されているキーレコードからキー値を取り出し、これが昇順となるようにキーレコードをソートする。
ステップ３６では、インデックス創成処理部２０から読込完了通知があったか否かを判定する。そして、読込完了通知があればステップ３７へと進む一方（Ｙｅｓ）、読込完了通知がなければステップ３２へと戻る（Ｎｏ）。

ステップ３７では、インデックス創成処理部２０に対して切替完了を通知する。
ステップ３８では、アプリケーション１０からの依頼を受信する。
ステップ３９では、受信した依頼が表更新依頼であるか否かを判定する。そして、表更新依頼であればステップ４０へと進む一方（Ｙｅｓ）、表更新依頼でなければステップ４２へと進む（Ｎｏ）。

ステップ４０では、受信した依頼から、表更新に係るキーレコードを抽出する。
ステップ４１では、抽出したキーレコードをログファイル９０に格納する。このとき、キーレコードは、その発生順序が保証されるように、所定規則に則ってログファイル９０に格納されるようにする。
ステップ４２では、インデックス創成処理部２０から初期創成完了通知があったか否かを判定する。そして、初期創成完了通知があればステップ４３へと進む一方（Ｙｅｓ）、初期創成完了通知がなければステップ３８へと戻る（Ｎｏ）。なお、ステップ３８〜４２の一連の処理が、ログ蓄積手段に該当する。

ステップ４３では、インデックス創成処理部２０に対して切替完了を通知する。
ステップ４４では、アプリケーション１０からの依頼を受信する。
ステップ４５では、受信した依頼が表更新依頼であるか否かを判定する。そして、表更新依頼であればステップ４６へと進む一方（Ｙｅｓ）、表更新依頼でなければステップ５１へと進む（Ｎｏ）。

ステップ４６では、受信した依頼から、表更新に係るキーレコードを抽出する。
ステップ４７では、インデックス８０を参照する。
ステップ４８では、抽出したキーレコードに対応するデータ、即ち、キー値が同一のキーレコードがインデックス８０に格納されているか否かを判定する。そして、対応するデータが格納されていればステップ４９へと進み（Ｙｅｓ）、そのキーレコードに基づいてインデックス８０を更新する。一方、対応するデータが格納されていなければステップ５０へと進み（Ｎｏ）、そのキーレコードを作業インデックス１００に格納する。

ステップ５１では、インデックス創成処理部２０からログ反映完了通知があったか否かを判定する。そして、ログ反映完了通知があれば処理を終了する一方（Ｙｅｓ）、ログ反映完了通知がなければステップ４４へと戻る（Ｎｏ）。なお、ステップ４４〜５１の一連の処理が、更新依頼処理手段に該当する。
図１０は、アプリケーション１０における表更新を契機として、実行される処理内容を示す。なお、アプリケーション１０では、インデックス創成処理部２０との同期をとるべく、インデックス創成処理部２０からの創成処理開始通知及び創成処理完了通知に応答して、認識通知を夫々返信する。

ステップ６１では、ＤＢ４０を構成する表を更新する。
ステップ６２では、インデックス創成処理中であるか否か、即ち、創成処理開始通知があり、かつ、創成処理完了通知がない状態であるか否かを判定する。そして、インデックス創成処理中であればステップ６３へと進む一方（Ｙｅｓ）、インデックス創成処理中でなければ処理を終了する（Ｎｏ）。

ステップ６３では、インデックス初期創成処理が完了したか否か、即ち、初期創成完了通知があったか否かを判定する。そして、インデックス初期創成処理が完了したならばステップ６４へと進み（Ｙｅｓ）、表更新に係る依頼に基づいてインデックス８０を直接更新する。一方、インデックス処理創成処理が完了していなければステップ６５へと進み（Ｎｏ）、インデックス創成デーモン３０に対して表更新に係る依頼を送信する。

以上説明した処理によれば、インデックス初期創成処理では、図１１に示すように、バックアップデータとしてのダンプファイル５０Ａ及びアーカイブログファイル５０Ｂから、インデックス初期創成処理開始時点におけるＤＢ４０の内容を再現した表６０が作成される。このため、ＤＢ４０を構成する表をアクセスする必要がなく、アプリケーション１０との間でディスクＩ／Ｏの競合が回避されることから、インデックス創成処理中であっても、アプリケーションに対するサービスレスポンスの低下を抑制することができる。その後、表６０からキーレコードが抽出され、これが作業ファイル７０に格納される。

また、ダンプファイル５０Ａ及びアーカイブログファイル５０Ｂの読込開始から作業ファイル７０へのキーレコード格納完了までの間には、アプリケーション１０からの表更新依頼に係るキーレコードは、作業ファイル７０へとマージされつつキー値に基づいてソートされる。このため、インデックス初期創成処理中におけるログ量が削減し、これをインデックス８０に反映させるためのログ反映処理時間、要するに、インデックス創成時間を短縮することができる。

そして、作業ファイル７０に格納されたキーレコードからインデックス８０を初期創成するときには、表更新依頼に係るキーレコードが作業ファイル７０にマージできないことから、図１２に示すように、そのキーレコードの発生順序を保証しつつログファイル９０に格納される。
ログ反映処理では、図１３に示すように、アプリケーション１０からの表更新依頼は、インデックス８０に対応データがあれば直接反映される一方、インデックス８０に対応データがなければキーレコードが抽出され作業インデックス１００に格納される。また、図１４（Ａ）に示すように、ログファイル９０から取り出されたキーレコードに対応するデータが作業インデックス１００に格納されていれば、インデックス８０に対する更新順序が逆転したと判断し、挿入及び削除がこの順番で行われたために何ら影響を及ぼさないことに鑑み、そのキーレコードを無視して何もしない。一方、同図（Ｂ）に示すように、取り出されたキーレコードに対応するデータが作業インデックス１００に格納されていなければ、インデックス８０に対する更新順序が保証されたと判断し、そのキーレコードに基づいてインデックス８０を更新する。

このため、ログファイル９０に蓄積されたキーレコード、即ち、ログを反映するときに、作業ファイル１００を参照することで、インデックス８０に対する更新順序が保証されることから、アプリケーション１０に対するサービスを停止させずに、新たなインデックスを動的かつ効率良く追加することができる。また、ログ反映処理中における表更新は、その更新順序が保証される限り、直接インデックス８０に反映されるため、ログ適用効率を大幅に向上させることができる。

本発明に係るインデックス追加装置の全体構成図インデックス初期創成処理の概要説明図ログ反映処理の概要説明図キーレコードの説明図インデックス創成処理部において実行されるメインルーチンを示すフローチャートインデックス初期創成処理のサブルーチンを示すフローチャートログ反映処理のサブルーチンを示すフローチャートインデックス創成デーモンにおいて実行される処理内容のフローチャートインデックス創成デーモンにおいて実行される処理内容のフローチャートアプリケーションにおける表更新を契機として、実行される処理内容のフローチャートインデックス初期創成処理における前半処理説明図インデックス初期創成処理における後半処理説明図ログ反映処理中における表更新依頼の処理説明図ログ反映処理における処理詳細を示し、（Ａ）はログに対応するデータがあるときの説明図、（Ｂ）はログに対応するデータがないときの説明図

符号の説明

１０アプリケーション
２０インデックス創成処理部
３０インデックス創成デーモン
４０データベース（ＤＢ）
５０Ａダンプファイル
５０Ｂアーカイブログファイル
６０表
７０作業ファイル
８０インデックス
９０ログファイル
１００作業インデックス

Claims

リレーショナルデータベースのインデックスを初期創成するステップと、
インデックス初期創成中におけるリレーショナルデータベースに対する更新ログを蓄積するステップと、
インデックス初期創成後に、前記リレーショナルデータベースに対する更新依頼に対応するデータがインデックスに存在すれば、前記更新依頼をインデックスに反映させる一方、前記更新依頼に対応するデータがインデックスに存在しなければ、前記更新依頼を第１の作業領域に格納するステップと、
蓄積された更新ログを初期創成されたインデックスに順次反映させるときに、前記更新ログに対応するデータが第１の作業領域に格納されていれば、その更新ログを無視する一方、前記更新ログに対応するデータが第１の作業領域に格納されていなければ、その更新ログをインデックスに反映させるステップと、
をコンピュータに実現させるためのリレーショナルデータベースのインデックス追加プログラム。
前記リレーショナルデータベースのインデックスを初期創成するステップは、前記リレーショナルデータベースの破壊に備えて適宜取得されたバックアップデータから、インデックスを初期創成することを特徴とする請求項１記載のリレーショナルデータベースのインデックス追加プログラム。
前記バックアップデータは、ある時点におけるリレーショナルデータベースを退避したダンプファイルと、前記リレーショナルデータベースの更新内容を記録したアーカイブログファイルと、から構成されることを特徴とする請求項２記載のリレーショナルデータベースのインデックス追加プログラム。
前記リレーショナルデータベースのインデックスを初期創成するステップは、前記リレーショナルデータベースからキーレコードを抽出して第２の作業領域に格納するステップと、前記第２の作業領域に格納されたキーレコードを所定規則に沿ってソートしつつ、前記リレーショナルデータベースに対する更新依頼から抽出されたキーレコードを該当箇所にマージするステップと、ソート及びマージされたキーレコードからインデックスを創成するステップと、を含んで構成されることを特徴とする請求項１〜請求項３のいずれか１つに記載のリレーショナルデータベースのインデックス追加プログラム。
前記ソート及びマージされたキーレコードからインデックスを創成した後、蓄積された更新ログをインデックスに反映させ終るまでの間、前記リレーショナルデータベースに対する更新依頼に対応するデータがインデックスに存在すれば、その更新依頼に応じてインデックスを更新する一方、前記更新依頼に対応するデータがインデックスに存在していなければ、その更新依頼を第１の作業領域に格納するステップを備えたことを特徴とする請求項４記載のリレーショナルデータベースのインデックス追加プログラム。
前記ソート及びマージされたキーレコードからインデックスを創成するステップは、同一インデックスに対する挿入及び削除の組み合わせを無視して、インデックスを創成することを特徴とする請求項４又は請求項５に記載のリレーショナルデータベースのインデックス追加プログラム。
リレーショナルデータベースのインデックスを初期創成する初期創成手段と、
前記初期創成手段によるインデックス初期創成中に、前記リレーショナルデータベースに対する更新ログを蓄積するログ蓄積手段と、
前記初期創成手段によるインデックス初期創成後に、前記リレーショナルデータベースに対する更新依頼に対応するデータがインデックスに存在すれば、前記更新依頼をインデックスに反映させる一方、前記更新依頼に対応するデータがインデックスに存在しなければ、前記更新依頼を作業領域に格納する更新依頼処理手段と、
蓄積された更新ログを初期創成されたインデックスに順次反映させるときに、前記更新ログに対応するデータが作業領域に格納されていれば、その更新ログを無視する一方、前記更新ログに対応するデータが作業領域に格納されていなければ、その更新ログをインデックスに反映させるログ反映手段と、
を含んで構成されたことを特徴とするリレーショナルデータベースのインデックス追加装置。
リレーショナルデータベースのインデックスを初期創成するステップと、
インデックス初期創成中におけるリレーショナルデータベースに対する更新ログを蓄積するステップと、
インデックス初期創成後に、前記リレーショナルデータベースに対する更新依頼に対応するデータがインデックスに存在すれば、前記更新依頼をインデックスに反映させる一方、前記更新依頼に対応するデータがインデックスに存在しなければ、前記更新依頼を作業領域に格納するステップと、
蓄積された更新ログを初期創成されたインデックスに順次反映させるときに、前記更新ログに対応するデータが作業領域に格納されていれば、その更新ログを無視する一方、前記更新ログに対応するデータが作業領域に格納されていなければ、その更新ログをインデックスに反映させるステップと、
をコンピュータに実行させることを特徴とするリレーショナルデータベースのインデックス追加方法。