(57)【特許請求の範囲】
【請求項１】
複数のデータベースサーバとストレージを含むデータベース管理システムにおけるインデックス運用方法であって、
表データを前記ストレージの表領域に記憶するステップと、
前記表データに関連付けられた第１のインデックスを前記ストレージの第１のインデックス領域に記憶するステップと、
前記複数のデータベースサーバに対し、小領域に細分化された前記表データに対応する表データ小領域と、小領域に細分化された第１のインデックスに対応するインデックス小領域とを割り当てるステップと、
前記データベースサーバごとに、割り当てられた前記インデックス小領域に関連する第２のインデックスを作成するステップと、
前記第２のインデックスが作成されていない場合は、前記インデックス小領域を参照し前記第１のインデックスを利用して前記表データを検索するステップと、
前記第２のインデックスが作成され、前記第２のインデックスが前記データベースサーバに記憶されている場合は、前記第２のインデックスを利用して前記表データを検索するステップと、を有することを特徴とするインデックス運用方法。
【請求項２】
請求項１に記載のインデックス運用方法であって、
前記データベースサーバにおいて前記表データ小領域及び前記インデックス小領域の割り当てを変更する構成変更が生じた場合は、前記データベースサーバは前記第２のインデックスを無効にし、前記第１のインデックスを利用して前記表データを検索し、無効にした前記第２のインデックスの換わりに新しい第２のインデックスを作成するステップ、を更に有することを特徴とするインデックス運用方法。
【請求項３】
請求項２に記載のインデックス運用方法であって、
前記新しい第２のインデックスの作成を実行している間は、前記構成変更によって割り当てが変更された前記インデックス小領域を参照し前記第１のインデックスを利用して前記表データを検索するステップ、を更に有することを特徴とするインデックス運用方法。
【請求項４】
請求項３に記載のインデックス運用方法であって、
前記新しい第２のインデックスを前記データベースサーバに記憶し、前記新しい第２のインデックスを有効にするステップ、を更に有することを特徴とするインデックス運用方法。
【請求項５】
ユーザからのデータベーステーブルを構成するデータへの検索要求を受付けるフロントエンドモジュールに接続されるデータベースサーバで実行され、前記データを探索する複数のデータベース処理モジュールと、前記複数のデータベース処理モジュールによって共有され、各々が前記複数のデータベース処理モジュールのうちの一つに割り当てられる複数の細分化テーブルに分割された前記データベーステーブルを構成する前記データを記憶する第１のストレージと、前記複数のデータベース処理モジュールによって共有され、前記データベーステーブルのインデックスを記憶する第１のインデックス領域を有する第２のストレージと、各々が前記複数のデータベース処理モジュールのうち一のデータベース処理モジュールに接続され、第２のインデックス領域を有する複数の第３のストレージとを有し、
前記第１のインデックス領域は各々が各前記細分化テーブルと一対一に対応する複数の細分化インデックス領域に分割され、前記複数の細分化インデックス領域は各々、対応する前記細分化テーブルが割り当てられた前記データベース処理モジュールに割り当てられ、前記第２のインデックス領域は前記複数の細分化テーブルの全体に関連するインデックスを含む、データベース管理システムにおけるデータベース管理方法であって、
前記複数のデータベース処理モジュールは、
前記第２のインデックス領域のインデックスを無効にするステップと、
前記複数の細分化テーブルの各々、及び、前記複数の細分化インデックス領域の各々を前記複数のデータベース処理モジュールに対して再割り当てする構成変更処理を行うステップと、
前記第２のインデックス領域のインデックスを再作成するステップと、
前記第２のインデックス領域のインデックスを再作成している間、前記第１のインデックス領域のインデックスを利用して前記データベーステーブルを参照するステップと、
前記第２のインデックス領域のインデックスの再作成が完了した後、前記再作成された第２のインデックス領域のインデックスを有効にするステップと、を実行することを特徴とするデータベース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ領域を細分化したデータベース管理システム (DBMS) 運用向けのインデックス運用方法に関するものである。
【背景技術】
【０００２】
DBMSでは検索高速化のために、一般にインデックスを用いる。特にB-Tree構造およびその拡張構造は、ディスク装置に適したデータ構造であり、最も一般的なインデックス構造として広く用いられている。B-Tree構造のインデックスはテーブル内の特定の1つもしくは複数の列を予めソートし、また探索効率が上がるように配置しておくことで、その列をキーとした探索を高速化する。
【０００３】
また、近年のデータ量増大に伴い、複数のDBサーバを用いたクラスタDBMSに注目が集まっている。クラスタDBMSの運用方法のひとつに、DBサーバ間でテーブル内の同一行を共有しないよう、テーブル内の特定の1つもしくは複数の分割キー列を用いてハッシュ分割方式もしくは値域分割方式を用いて分割する方式がある。
【０００４】
上記方式で運用されるクラスタDBMSには、DBサーバの台数変更といった構成変更に時間がかかるという欠点があった。上記クラスタDBMSでは、全てのDBサーバの探索結果を集約する必要がある問合せ処理の場合、もっとも時間のかかるDBサーバに問合せ処理性能が支配される。DBサーバ間でデータ量の偏りが生じると一般に性能が劣化するため、構成変更の際にはデータ量を均一にそろえる処理が必須となる。しかし、この処理はディスク装置上のデータを物理的に異なる場所に移動させる必要があるため、長時間を要する。
【０００５】
特許文献１（米国特許第５５５１０２７号）には無共有型DBMSのクラスタ環境において、非分割キーによる絞りこみを行うための階層化インデクスについて記載される。それによると、非分割キーとその列を保持するサーバ番号の対からなるグローバルインデクスを用いて検索に用いるサーバを絞りことができる。しかしそのグローバルインデクスはそれだけでテーブル内の特定の行を指し示す能力はない。
【０００６】
【特許文献１】米国特許第５５５１０２７号
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の発明者らは先にネットワーク上で共有可能なストレージを予め細分化しておき、クラスタDBMSの構成変更時にその割り当てだけを変更することで、データの移動を伴わない高速な構成変更を可能にする発明を提案している（特願2004-003601号）。図2は、表領域 (204) が12個の小領域 (205) に細分化されている場合の例であり、図2の(a)に示す状態ではネットワーク (203) を介して接続された2台のバックエンドモジュール (201, 202) に対して6つずつ小領域 (206, 207) が割り当たっている。そこに新たに1台のバックエンドモジュール (208) を追加した状態が図2の(b)であり、この状態では小領域 (205) が3台のバックエンドモジュールに4つずつ (209, 210, 211) 割りあたっている。上記した先行出願ではストレージの細分化方法として、テーブルの分割キー列を用い、またテーブルと同じ分割方式を用いる方法を提案している。また、小領域 (205) のDBサーバへの割り当ては、割り当て管理表を用いて管理される。
【０００８】
なお、割り当て管理表を用いることなく、細分化されたストレージのみを用いて、上記の先行出願の方法の機能を模倣することも可能である。一例として、ネットワーク上の共有ストレージに、小領域に対応する多数の小さなLUを作成し、これらLUの割り当てを人手で管理することで、模倣が可能である。しかし、この場合には、トランザクションの一貫性制御といったDBMSが管理している事項を全て保障する必要があり、運用が煩雑になる。
【０００９】
しかし、インデックス探索機能を有するDBMSに対して特願2004-003601および上記の模倣した手法を適用する場合、インデックスは再作成が必要になるという問題が生じる。これは、DBMSがテーブルの分割キー列とは異なる列をキーとしてインデックスを張れる構造であることに起因する問題である。インデックスの再作成には一般にテーブル全体をスキャンする必要があり、多大な時間を要する。そのため、インデックスが存在する場合には、特願2004-003601および上記の模倣した手法による高速な構成変更のメリットが薄れてしまう。
【００１０】
従来手法で可能な解決法として、図3に示すようにインデックス領域 (301)を表領域 (204) と同じ分割方式で同じ数に予め細分化 (302) しインデックスにも上記特願2004-003601号で提案した手法、および上記の模倣した手法を適用し、バックエンドモジュール (201, 202, 208) に割り当てる (303, 304, 305, 306, 307) ことで、インデックスを含めて高速な構成変更を実現することが可能な場合もある。ここで、インデックス領域 (301) を細分化する際には、図4に示すように表領域 (204) 中の小領域とインデックス領域 (301) 中の小領域が一対一に対応する必要がある。ここでは、表領域 (204) 中の小領域 (401) とインデックス領域 (301) 中の小領域 (402)、表領域 (204) 中の小領域 (403) とインデックス領域 (301) 中の小領域 (404)といった対応関係がある。しかし、この方式をB-Treeインデックスに対して適用すると、表領域 (204) 全体に対する通常のインデックスと比べて探索コストがたいして変わらない小さなインデックスが大量に作成される。その結果、値域検索といった特定の問合せに対して探索コストが細分化の分割数倍かかるという問題が生じる。
【００１１】
そこで、本発明で解決しようとする課題は、複数のデータベースサーバから構成され、データ領域を小領域に細分化し、各小領域のデータベースサーバへの割り当てを変えることによってデータベースサーバ間でのデータの受け渡しが可能なデータベース管理システムの運用において、構成変更後にインデックスの再作成に伴う処理速度劣化が生じる点、および従来手法を用いてこの問題を解決する場合には定常運用時に特定の問合せに対して顕著な処理速度劣化が生じる点である。
【課題を解決するための手段】
【００１２】
複数のデータベースサーバから構成され、データ領域を小領域に細分化し、各小領域のデータベースサーバへの割り当てを変えることによってデータベースサーバ間でのデータの受け渡しが可能なデータベース管理システムの運用において、その小領域ごとに作成されたインデックスと、データベースサーバごとに割り当てられた小領域全体に対するインデックスを組み合わせて使う。
【発明の効果】
【００１３】
データ領域を細分化し、各小領域のデータベースサーバへの割り当てを変えることによってデータベースサーバ間でのデータの受け渡しが可能なデータベース管理システムの運用において、細分化したデータ領域の割り当て変更による構成変更後に、インデックスの再作成による顕著な処理速度劣化が生じなくなり、かつ定常運用時には特定の問合せに対して顕著な処理速度劣化が生じない。
【発明を実施するための最良の形態】
【００１４】
発明を実施するための最良の形態を図1に示す。ここではネットワーク (117) を介して複数のDBサーバ (101, 102) とネットワーク接続ストレージ上の表領域 (109) およびインデックス領域#1 (110) が接続され、表領域 (109) とインデックス領域 (110) は複数のDBサーバ (101, 102) から共有可能な状態である。また、DBサーバごとに専用のインデックス領域#2 (113, 115) が接続される。表領域 (109) とインデックス領域#1 (110) は内部が同一の手法を用いて同一数の小領域に細分化されている(111, 112)。その各小領域がDBサーバ (101, 102) に割り当てられる (103, 104, 106, 107)。一方のインデックス領域#2 (113, 115) には小領域を作らず、1つもしくは複数の領域を作成し (114, 116)、DBサーバから参照する (105, 108)。
【実施例１】
【００１５】
図５は、本発明の第1の実施例の模式図である。本実施例では表領域 (508) やインデックス領域へのデータ探索やデータ演算を行うバックエンドモジュール (501, 502) が図1のDBサーバ (101, 102) に該当し、かつユーザまたはプログラム (504) からの問合せ受付けや問い合わせプラン生成用のフロントエンドモジュール (503)、特願2004-003601に示した機能による構成変更やインデックス運用のスケジュールを管理するスケジューラモジュール (505)、細分化されたデータ領域の割り当て管理を行うマッピングモジュール (506)、および共有ストレージ上の表領域 (508)、共有ストレージ上のインデックス領域#1 (509)、非共有ストレージ上のインデックス領域#2 (510, 511) が連携して動作することでデータベース管理システム (512) を構成する。スケジューラモジュール (505) への構成変更命令投入は、管理者またはプログラム (507) によって行われる。
【００１６】
本実施例では、特願2004-003601に示した機能を、表領域 (508) とインデックス領域#1 (509) に適用し、スケジューラモジュール (505) によって構成変更のスケジュール管理を行い、またマッピングモジュール (506) によって共有ストレージ上の領域 (508, 509) の割り当て管理を行う。このような構成をとるためには、表領域 (508) とインデックス領域#1 (509) が一対一に対応することを保障する必要がある。ここでは、表の分割にハッシュ分割方式を用い、またインデックスはB-Treeインデックスとし、さらに図4に示す手法を用いて、表領域 (508) とインデックス領域#1 (509) の細分化に用いるハッシュ関数を等しくし、さらに表領域 (508) とインデックス領域#1 (509) を同じ分割数に細分化することで無矛盾を保障する。ここではインデックス領域#1 (509) に作成される細分化されたインデックスを小インデックスとよぶ。一方のインデックス領域#2 (510, 511) には、バックエンドモジュール (501, 502) に割り当てられた表領域全てにまたがるインデックスを作成する。ここではインデックス領域#2 (510, 511) に作成されるインデックスを大インデックスと呼ぶ。
【００１７】
ここで、構成変更を行うと、表領域としてバックエンドモジュール (501, 502) に割り当てられる小領域が変化するため、表領域 (508) とインデックス領域#2 (510, 511) の間で内容の不一致が生じる。そこで、構成変更の前後で大インデックスの管理を行う必要がある。この構成変更時の処理フローを図６に示す。ここでは、構成変更処理受理 (601) 後、大インデックスを無効化 (602) し、特願2004-003601に従い構成変更を行う (603)。構成変更 (603) 後に、先ほど無効化した (602) 大インデックスを再作成 (604) する。大インデックスの作成 (604) はバックグラウンドで行われるため、ユーザまたはプログラム (504) からの問合せ受付は継続して行われる。また、大インデックスの再作成中 (604) には、小インデックスを用いて検索処理を行うことで、検索処理速度の低下を最小限に食い止められる。大インデックス再作成 (604) の終了後、大インデックスを有効化 (605) し、問合せ処理で使用可能な状態とし、構成変更処理を完了 (606) する。
【００１８】
なお、従来手法による大インデックスの再作成には、該当する表の全件スキャンが必要となる。しかし、本発明を適用した環境では、大インデックスに対応する小インデックスが必ず存在し、小インデックスは既にソート済みであることが保証されている。そのため、大インデックスの再作成の際に表からではなく小インデックスから作成することで高速化が図れる。
【実施例２】
【００１９】
図７は、本発明の1実施例の模式図である。本実施例では表領域やインデックス領域へのデータ探索やデータ演算を行うバックエンドモジュール (701, 702) が図1のDBサーバ (101, 102) に該当し、かつユーザまたはプログラム (704) からの問合せ受付けや問い合わせプラン生成用のフロントエンドモジュール (703) 、および共有ストレージ上の表領域 (705) 、共有ストレージ上のインデックス領域#1 (706) 、非共有ストレージインデックス領域#2 (707, 708) が連携して動作することでデータベース管理システム (709) を構成する。
【００２０】
本実施例では、割り当て管理表を用いることなく特願2004-003601に示した機能を模倣する。ここでは共有ストレージ上の表領域およびインデックス領域#1をそれぞれ12個の仮想ボリュームに分割 (705, 706) し、これら仮想ボリューム (705, 706) のバックエンドサーバ (701, 702) への割り当てを手動で管理する事で、特願2004-003601に示した機能を模倣する。12分割された仮想ボリューム (705) への表の格納は、ハッシュ分割方式によって同じく12分割した表を作成する方式を取る。ここでもインデックス領域#1 (706) に作成される細分化されたインデックスを小インデックスとよぶ。一方のインデックス領域#2 (707, 708) には、バックエンドモジュール (701, 702) に割り当てられた仮想ボリューム全てにまたがるインデックスを作成し、インデックス領域#2 (707, 708) に作成されるインデックスを大インデックスと呼ぶ。
【００２１】
ここでも実施例１と同じく、構成変更を行うと、表領域とインデックス領域#2の間で内容の不一致が生じる。この構成変更時に必要な大インデックスの管理のための処理フローを図８に示す。ここでは、構成変更処理受理 (801) 後、大インデックスを無効化 (802) し、12分割された仮想ボリューム (705, 706) の割り当て変更に備えて表領域およびインデックス領域#1をデータベース管理システムからアンマウント (803) し、データベース管理システムを停止 (804)する。その後、OSおよび共有ストレージに命令を出して12分割された仮想ボリューム (705, 706) の割り当てを変更 (805) する。先にデータベース管理システムを停止 (804) してあるため、この割り当て変更によるデータ損失は発生しない。割り当て変更 (805) 後に、データベース管理システムを開始 (806) し、表領域およびインデックス領域#1をデータベース管理システムにマウント (807) しなおす。この時点で、ユーザまたはプログラム (704) からの問合せ受付が再開可能となる。続いて、先ほど無効化した (802) 大インデックスを再作成 (808) する。大インデックスの作成 (808) はバックグラウンドで行われるため、ユーザまたはプログラム (704) からの問合せ受付は継続して行われる。また、大インデックスの再作成中 (808) には、小インデックスを用いて検索処理を行うことで、検索処理速度の低下を最小限に食い止められる。大インデックス再作成 (808) の終了後、大インデックスを有効化 (809) し、問合せ処理で使用可能な状態とし、構成変更処理を完了 (810) する。
【図面の簡単な説明】
【００２２】
【図１】本発明に従うデータベース管理システムのシステム構成を示す概念図である。
【図２】データ領域を細分化したデータベース管理システムにおける高速な構成変更の方法を示した説明図である。
【図３】データ領域を細分化したデータベース管理システムにおける高速な構成変更の方法を示した説明図である。
【図４】データ領域を細分化したデータベース管理システムにおける高速な構成変更を実現可能なインデックスの構成方法を示した説明図である。
【図５】本発明の実施例の大インデックスおよび小インデックスを用いたデータベース管理システムの構成方法を示した説明図である。
【図６】上記実施例のデータベース管理システムにおける構成変更の処理フローを示すフローチャートである。
【図７】本発明の別の実施例のデータベース管理システムの構成方法を示した説明図である。
【図８】上記実施例のデータベース管理システムにおける構成変更の処理フローを示すフローチャートである（実施例２）。
【符号の説明】
【００２３】
101    データベースサーバ
102    データベースサーバ
103    表領域
104    小インデックス領域
105    大インデックス領域
106    表領域
107    小インデックス領域
108    大インデックス領域
109    共有ストレージ領域
110    共有ストレージ領域
111    細分化された小領域
112    細分化された小領域
113    非共有ストレージ領域
114    データ領域
115    非共有ストレージ領域
116    データ領域
117    ネットワーク
201    バックエンドモジュール
202    バックエンドモジュール
203    ネットワーク
204    共有ストレージ領域
205    細分化された小領域
206    表領域
207    表領域
208    バックエンドモジュール
209    表領域
210    表領域
211    表領域
301    共有ストレージ領域
302    細分化された小領域
303    小インデックス領域
304    小インデックス領域
305    小インデックス領域
306    小インデックス領域
307    小インデックス領域
401    細分化された小領域
402    細分化された小領域
403    細分化された小領域
404    細分化された小領域
501    バックエンドモジュール
502    バックエンドモジュール
503    フロントエンドモジュール
504    ユーザまたはプログラム
505    スケジューラモジュール
506    マッピングモジュール
507    管理者またはプログラム
508    共有ストレージ領域
509    共有ストレージ領域
510    非共有ストレージ領域
511    非共有ストレージ領域
512    データベース管理システム
601    フロー開始
602    処理
603    定義済み処理
604    処理
605    処理
606    フロー終了
701    バックエンドモジュール
702    バックエンドモジュール
703    フロントエンドモジュール
704    ユーザまたはプログラム
705    共有ストレージ
706    共有ストレージ
707    非共有ストレージ
708    非共有ストレージ
709    データベース管理システム
801    フロー開始
802    処理
803    処理
804    処理
805    処理
806    処理
807    処理
808    処理
809    処理
810    フロー終了。
【図１】
0004839706.tif 000002
【図２】
0004839706.tif 000003
【図３】
0004839706.tif 000004
【図４】
0004839706.tif 000005
【図５】
0004839706.tif 000006
【図６】
0004839706.tif 000007
【図７】
0004839706.tif 000008
【図８】
0004839706.tif 000009