(57)【要約】【課題】再配置中のアクセスプランのチューニングおよび性能の検証を事前に行うことができるデータベース管理方法および装置の提供。【解決手段】（ａ）において、検索用ＳＱＬを入力し（１０１）、データベース格納領域（以下、領域）を追加する表の表識別子を指定し（１０２）、追加するデータベース格納領域の個数を指定し（１０３）、検索実行する（１０４）。表定義情報テーブル、分割情報テーブルを生成して、領域追加前の検索処理を実行し、次いで前記各テーブルの内容の変更、設定をして、領域追加，再配置中の検索処理を実行し、次いで表定義情報テーブルの内容を変更して、領域追加，再配置後の検索処理を実行し、各実行の結果である実行時間（１０５、１０７、１０９）とアクセスプラン（１０６、１０８、１１０）を表示する。利用者がこの実行時間とアクセスプランを参照してアクセスプランをチューニングし、再度検索実行すると、（ｂ）に示すように改善される。【選択図】　　　　　　　　図１
2004021797.tif 000002
【特許請求の範囲】
【請求項１】
データベース格納領域の追加実行前に、設定されたデータ操作言語（ＤＭＬ）により仮想的な検索実行を行い、データベース格納領域の追加実行における最適なデータ定義言語（ＤＤＬ）を得るためのデータベース管理方法であって、
入力されたＤＭＬを解析し、
データベース格納領域（以下、領域）を追加する表について、領域追加前の表定義情報テーブルおよび分割情報テーブルを生成し、
該生成した表定義情報テーブルの分割数の変更と再配置種別の設定がされ、該生成した分割情報テーブルに対して領域の追加と実行時検索種別の設定がされて、領域追加・再配置中の表定義情報テーブルと分割情報テーブルが設定された後、実体のない領域を除き、前記解析したＤＭＬにより検索処理を実行し、領域追加・再配置中の実行時間及びアクセスプランを取得して表示し、
前記表示された実行時間及びアクセスプランを基に前記ＤＤＬに変更がされたとき、前記検索処理を該変更されたＤＤＬにより実行し、その実行時間及びアクセスプランを取得して表示することを特徴とするデータベース管理方法。
【請求項２】
データベース格納領域の追加実行前に、設定されたＤＭＬにより仮想的な検索実行を行い、データベース格納領域の追加実行における最適なＤＤＬを得るためのデータベース管理方法であって、
入力されたＤＭＬを解析し、
データベース格納領域（以下、領域）を追加する表について、領域追加前の表定義情報テーブルおよび分割情報テーブルを生成し、
該生成した表定義情報テーブルの分割数の変更がされ、再配置種別が設定されず、該生成した分割情報テーブルに対して領域の追加と実行時検索種別の設定がされて、領域追加・再配置後の表定義情報テーブルと分割情報テーブルが設定された後、実体のない領域を除き、前記解析したＤＭＬにより検索処理を実行し、領域追加・再配置後の実行時間及びアクセスプランを取得して表示し、
前記表示された実行時間及びアクセスプランを基に前記ＤＤＬに変更がされたとき、前記検索処理を該変更されたＤＤＬにより実行し、その実行時間及びアクセスプランを取得して表示することを特徴とするデータベース管理方法。
【請求項３】
データベース格納領域の追加実行前に、設定されたＤＭＬにより仮想的な検索実行を行い、データベース格納領域の追加実行における最適なＤＤＬを得るためのデータベース管理方法であって、
入力されたＤＭＬを解析し、
データベース格納領域（以下、領域）を追加する表について、領域追加前の表定義情報テーブルおよび分割情報テーブルを生成し、前記解析したＤＭＬにより第１の検索処理を実行し、領域追加前の実行時間及びアクセスプランを取得し、前記領域追加前の表定義情報テーブルの分割数の変更と再配置種別の設定がされ、前記領域追加前の分割情報テーブルに対して領域の追加と実行時検索種別の設定がされて領域追加・再配置中の表定義情報テーブルと分割情報テーブルが設定された後、実体のない領域を除き、前記解析したＤＭＬにより第２の検索処理を実行し、領域追加・再配置中の実行時間及びアクセスプランを取得し、
前記領域追加・再配置中の表定義情報テーブルの再配置種別の設定が変更された後、実体のない領域を除き、前記解析したＤＭＬにより第３の検索処理を実行し、領域追加・再配置中の実行時間及びアクセスプランを取得し、
前記取得した各実行時間及びアクセスプランを表示し、
前記表示された各実行時間及びアクセスプランを基に前記ＤＤＬに変更がされたとき、前記第１乃至第３の検索処理の内の少なくとも１つの検索処理を該変更されたＤＤＬにより実行し、その実行時間及びアクセスプランを取得して表示することを特徴とするデータベース管理方法。
【請求項４】
請求項１乃至請求項３記載のいずれかの請求項記載のデータベース管理方法において、
前記検索処理は、表が格納されているデータベース格納領域のみを検索し、定義情報だけで実際には追加されていないデータベース格納領域を検索対象から除外する中間コードを前記解析したＤＭＬを基に生成し、実行することを特徴とするデータベース管理方法。
【請求項５】
データベースシステムにおいて、データベース格納領域の追加実行前に、設定されたＤＭＬにより仮想的な検索実行を行い、データベース格納領域の追加実行における最適なＤＤＬを得るためのデータベース管理装置であって、
入力されたＤＭＬを解析する手段と、
データベース格納領域（以下、領域）を追加する表について、領域追加前の表定義情報テーブルおよび分割情報テーブルを生成する手段と、
該生成した表定義情報テーブルの分割数の変更と再配置種別の設定がされ、該生成した分割情報テーブルに対して領域の追加と実行時検索種別の設定がされて、領域追加・再配置中の表定義情報テーブルと分割情報テーブルが設定された後、実体のない領域を除き、前記解析したＤＭＬにより検索処理を実行し、領域追加・再配置中の実行時間及びアクセスプランを取得して表示する手段を有し、
前記表示された実行時間及びアクセスプランを基に前記ＤＤＬに変更がされたとき、前記検索処理手段が該変更されたＤＤＬにより検索処理を実行し、その実行時間及びアクセスプランを取得して表示することを特徴とするデータベース管理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
リレーショナルデータベースマネジメントシステムにおいて、データベース容量の増加によって新たにデータベース格納領域を追加して再配置を行う時に、データベース格納領域を追加する前の段階でアクセスプランをチューニング可能にするデータベース管理技術に関する。
【０００２】
【従来の技術】
データベース容量の増加によりデータベース格納領域を新たに追加すると、データ量を均等にするために再配置を行う必要が生じる。
再配置中はデータベース格納領域をまたがってデータが移動しているため、キー値が格納されているデータベース格納領域が特定できなくなり、全データベース格納領域を検索しなければならなくなる。
公知例として特開２００１−１４２７５２号公報がある。
その結果、表の検索単価の予測値が大幅に増加し、使用するインデックスが変わる場合や、インデックスを使用しなくなる場合がある。
また、結合検索では、表の検索単価の予測値が増加することで結合順序，結合方法が変わり、再配置前とはまったく異なるアクセスプランを生成し、再配置中の性能劣化の要因となることがある。
また、ＳＱＬ文の実行時間を表示する方法として特開２００１−２８２７９９号公報がある。
【０００３】
【発明が解決しようとする課題】
従来技術では、再配置を行う前には高速に検索可能なＳＱＬを、再配置中に実行すると、アクセスプランが変わることで検索性能が大幅に劣化し、メモリ不足等を引き起こすという課題があった。
つまり、再配置中のアクセスプランに対するチューニングや，実行性能，メモリが十分であるかを、再配置前に判断できないということである。
本発明の目的は、再配置中のアクセスプランのチューニングおよび性能の検証を事前に行うことができるようにすることにある。
【０００４】
【課題を解決するための手段】
上記目的を達成するため、本発明は、データベースシステムにおいて、データベース格納領域の追加実行前に、設定されたＤＭＬにより仮想的な検索実行を行い、データベース格納領域の追加実行における最適なＤＤＬを得るためのデータベース管理方法であり、
入力されたＤＭＬを解析し、データベース格納領域（以下、領域）を追加する表について、領域追加前の表定義情報テーブルおよび分割情報テーブルを生成し、該生成した表定義情報テーブルの分割数の変更と再配置種別の設定がされ、該生成した分割情報テーブルに対して領域の追加と実行時検索種別の設定がされて、領域追加・再配置中の表定義情報テーブルと分割情報テーブルが設定された後、実体のない領域を除き、前記解析したＤＭＬにより検索処理を実行し、領域追加・再配置中の実行時間及びアクセスプランを取得して表示し、前記表示された実行時間及びアクセスプランを基に前記ＤＤＬに変更がされたとき、前記検索処理を該変更されたＤＤＬにより実行し、その実行時間及びアクセスプランを取得して表示する。
【０００５】
【発明の実施の形態】
以下に本発明の一実施例を図面に従って説明する。
図２はデータベースマネジメントシステム（ＤＢＭＳ）全体を表す構成図である。
クライアント２０１でＳＱＬ文の入力を受け付け、ＳＱＬ文をフロントエンドサーバ２０２へ転送し、フロントエンドサーバでＳＱＬ文の構文解析，最適化，実行を行う。なお、クライアント２０１からＳＱＬ文を入力しているが、ＳＱＬ文に限られるものではなく、ＤＭＬによる文であればよく、また、言語以外による入力でもよい。
表の定義情報，分割情報は２０４に格納されており、ディクショナリサーバ２０３を介してフロントエンドサーバで取得する。
図ではフロントエンドサーバとディクショナリサーバを別ノードとして記述しているが、同一ノード上にまとめることも可能である。
表のデータは２０６に格納されており、データ取り出しサーバ２０５を介してフロントエンドサーバが取得する。
最後に検索結果、実行時間およびアクセスプランを２０１のクライアントに返却して検索を終了する。
データベース容量の増加に伴って、新たにデータベース格納領域２０８、および２０８を検索するためのデータ取り出しサーバ２０７を追加することができる。各サーバは２０９のネットワークで接続されている。
【０００６】
図３は本発明におけるフロントエンドサーバの構成図である。
まず、クライアント２０１からフロントエンドサーバ２０２がＳＱＬ文を受け付ける。
フロントエンドサーバは、解析部３０１にてＳＱＬ文を解析し、必要となる表の定義情報，分割情報はディクショナリサーバ２０３を介して表定義情報，分割情報取得部３０２で取得する。
表定義情報，分割情報取得部で取得した情報に対して、再配置情報生成部３０３は、実際にデータベース格納領域を追加する前の仮想的な再配置状態を生成し、最適化部３０４で最適化処理を行う。
実行時に検索するデータベース格納領域決定部３０５では、実際には存在せず定義情報だけのデータベース格納領域を除いて、中間コード生成部３０６で中間コードを生成する。
実行部３０７では、中間コードにしたがって実行する。
表に格納されているデータは、データ取り出しサーバ２０５を介して取得する。
実行部３０７は、検索結果、実行時間およびアクセスプランを２０１のクライアントに転送して検索を終了する。
アクセスプランは中間コードを基に実行部３０７で作成される。
【０００７】
図４は、本発明における検索処理のフローチャートを示す。
データベース格納領域追加前（４０３から４０７）、データベース格納領域追加，再配置中（４０８から４１４）、データベース格納領域追加，再配置後（４１５から４２０）の三段階に分けることができる。
まず、データベース格納領域追加前に関するフローを説明する。
ＳＱＬ文の解析処理を行う（４０１）。
表定義情報，分割情報を取得する（４０２）。
上記取得した表定義情報，分割情報に基づき、表定義情報テーブル，分割情報テーブルを生成する（４０３）。
ステップ４０３で生成するテーブルのデータ構造については図９で説明する。次いで最適化処理を行い（４０４）、中間コードを生成し（４０５）、実行する（４０６）。
実行時間およびステップ４０５で作成した中間コードを基に作成されたアクセスプランを４０７で画面に表示する。
【０００８】
次に、データベース格納領域追加，再配置中に関するフローについて説明する。
ステップ４０３で生成したテーブルをステップ４０８、４０９で更新する。
ステップ４０８では、表定義情報テーブルに対して、新たに追加する分割数を加え、再配置種別を設定する。
ステップ４０９では、分割情報テーブルに対して新規に追加するデータベース格納領域の行を追加し、新たに追加した行は実行時検索種別をＯＦＦに設定する。このＯＦＦの設定は、ステップ４１１および４１７で実体の存在しないデータベース格納領域を検索しないようにする中間コードを生成するためのものである。
以上の設定はユーザの検索要求によってＤＢＭＳが設定する。
ステップ４０８，４０９で設定するテーブルのデータ構造については図１０で説明する。
ステップ４１０で最適化処理を行う。
ステップ４１１では、実体の存在しないデータベース格納領域を取り除く。
ステップ４１２では、実際に存在するデータベース格納領域だけを対象として検索する中間コードを生成する。
ステップ４１３で実行をする。
ステップ４１４では、実行時間およびステップ４１２で作成した中間コードを基に作成されたアクセスプランを画面に表示する。
【０００９】
最後に、データベース格納領域追加，再配置後に関するフローについて説明する。
ステップ４１５では、ステップ４０８で設定したテーブルの再配置状態をクリアする。このクリアはユーザの検索要求によってＤＢＭＳが設定する。
ステップ４１５で設定するテーブルのデータ構造については図１１で説明する。
ステップ４１６で最適化処理を行う。
ステップ４１７では、ステップ４１１と同様に実体の存在しないデータベース格納領域を取り除く。
ステップ４１８では、実際に存在するデータベース格納領域だけを対象として検索する中間コードを生成する。
ステップ４１９で実行をする。
実行時間およびステップ４１８で作成した中間コードを基に作成されたアクセスプランを画面に表示する。
ステップ４０８、４０９、４１５で再配置状態を設定することにより、データベース格納領域追加後の状態を仮想的に作成して、この仮想的状態の下で検索処理を実行することにより、実行時間およびアクセスプランを即座に確認できるため、この実行時間およびアクセスプランを参考にして利用者がインデックス定義を変更し、利用者によるインデックス定義の変更と検索処理による実行時間およびアクセスプランの出力を交互に繰り返すことで容易にチューニングを実現することができる。
【００１０】
図５は本実施例で用いるＳＱＬによるデータ定義言語の例である。
５０１は表Ｔ１を定義するＳＱＬである。
Ｃ１とＣ２を列に持ち、Ｃ１は主キーであることを表す。
また、列Ｃ１でハッシングして４つのデータベース格納領域に分割格納されている。
５０２は表Ｔ２を定義するＳＱＬである。
Ｃ１とＣ２を列に持ち、表Ｔ１と同様に列Ｃ１でハッシングして４つのデータベース格納領域に分割格納されている。
５０３は表Ｔ１の列Ｃ２にインデクスＩＸ＿Ｔ１＿Ｃ２を定義するＳＱＬ文である。
５０４は表Ｔ２の列Ｃ１，Ｃ２にインデクスＩＸ＿Ｔ２＿Ｃ１Ｃ２を定義するＳＱＬ文である。
以上のＳＱＬの例は、利用者が最初の検索処理（図４）に先立って作成するものである。アクセスプランのチューニング処理時に利用者により作成されるＳＱＬは図５で省略している。
【００１１】
図１は本発明を実現するためのユーザインタフェースに用いる画面の表示例である。
ユーザは１０１にＳＱＬ文を入力する。
例にあるＳＱＬ文は表Ｔ１とＴ２を外結合することを表している。
外結合とは、表Ｔ１と表Ｔ２の直積のうち、ｏｎ句（例えば、図１（ａ）のＳＱＬ文入力における「ｏｎ　Ｔ１．Ｃ１＝Ｔ２．Ｃ１　ａｎｄ　Ｔ２．Ｃ２　ｂｅｔｗｅｅｎ　？　ａｎｄ　？」）に指定した条件が真となる行と、偽になる行はＴ２の結果にＮＵＬＬ値を埋めた行の和集合を求め、その結果に対してＷＨＥＲＥ句に指定した条件を満たす行を返却する検索である。
１０２にデータベース格納領域を追加する表の表識別子を指定し、１０３に追加するデータベース格納領域の個数を指定して１０４の検索実行ボタンを押す。ＤＢＭＳはユーザの検索要求によって、まず図４のステップ４０１から４０６を実行し、
ステップ４０７でデータベース格納領域追加前の実行時間を１０５に、アクセスプランを１０６に表示する。
次に、図４のステップ４０８から４１３を実行し、ステップ４１４でデータベース格納領域追加，再配置中の実行時間を１０７に、アクセスプランを１０８に表示する。
最後に、図４のステップ４１５から４１９を実行し、ステップ４２０でデータベース格納領域追加，再配置後の実行時間を１０９に、アクセスプランを１１０に表示する。
【００１２】
表示結果から再配置中の実行時間１０７は１０５と１０９に比べて大幅に劣化していることがわかる。
また、アクセスプランを確認すると、データベース格納領域追加前のアクセスプラン１０６と、データベース格納領域追加後，再配置後のアクセスプラン１１０がネストループジョインで結合し、表Ｔ２は結合列に指定したインデックスを使用して検索していることがわかる。
それに対して、データベース格納領域追加，再配置中のアクセスプラン１０８は、ソートマージジョインとなり表Ｔ２を検索した後で結合条件を評価するため、結合列に指定したインデックスは使われずに、フルスキャンとなっていることが確認できる。
再配置中はデータが格納されている箇所が特定できないためネストループジョインにはなりにくい。
特に、このＳＱＬ文では、外結合を行っているためにネストループジョインでは実行できない場合がある。
【００１３】
そこで、利用者は、ソートマージジョインの時に高速に検索できるようにチューニングを行う。
表Ｔ２には単表に閉じる条件が存在するので、条件に指定している列にインデックスを定義する。
表Ｔ２のＣ２にインデックスＩＸ＿Ｔ２＿Ｃ２を定義して再実行した結果が、図１（ｂ）のデータベース格納領域追加，再配置中の実行時間１１１およびアクセスプラン１１２になる。
図１（ａ）のアクセスプラン１０８のフルスキャンが図１（ｂ）のアクセスプラン１１２のＩＸ＿Ｔ２＿Ｃ２を使用した検索に変わり、図１（ａ）の実行時間１０７の１０００ｍｓｅｃが図１（ｂ）の実行時間１１１の５０ｍｓｅｃに向上していることがわかる。
このように、利用者は、再配置中の実行時間およびアクセスプランを事前に確認しながら、最適なアクセスプランとなるようにＳＱＬ文の変更やインデックスの追加，削除等のチューニングを行うことが出来る。
【００１４】
図６は、データベース格納領域の追加数が適切でない場合の例である。
追加数６０１に示すようにデータベース格納領域を１００個追加した場合である。
追加数が多いために、データベース格納領域追加，再配置中のアクセスプラン６０３だけでなく、データベース格納領域追加，再配置後のアクセスプラン６０５もソートマージジョインに変わり、実行時間６０２，６０４も１００ｍｓｅｃとなっていることがわかり、追加するデータベース格納領域の個数が適切ではないことがわかる。
このように、データベース格納領域をいくつ追加した場合に最適なパフォーマンスを得られるかを容易に確認することができる。
【００１５】
図７はデータベース格納領域追加，再配置中にエラーが発生する場合の例である。
再配置中に発生したメモリ不足エラーに関するメッセージが７０１に表示される。
実行時にエラーが発生したため、実行時間７０２は−で表す。
また、エラーが発生した時のアクセスプランを７０３に表示している。
このように再配置中のメモリ使用量，作業表用ファイルの使用量が十分かどうかを事前に確認できるため、再配置を実施する前にメモリの増設，ファイルの追加等を実施でき、あらかじめエラーとなる要因を取り除いておくことが出来る。
【００１６】
図８はデータベース格納領域追加，再配置中の注意事項に関する表示例である。
再配置中の実行時間１１１が５０ｍｓｅｃとなり、データベース格納領域追加前である実行時間１０５の１０ｍｓｅｃの５倍となっていることから、再配置中には同時実行可能なトランザクションの最大数を１／５程度にする運用が望ましいというメッセージを８０１で表示する。
このように、再配置中に実行した場合の実行時間が事前にわかるため、同時に実行可能なトランザクション数に制限を設ける等、再配置中の性能低下を考慮した運用方法を事前に検討することができる。
【００１７】
図９はデータベース格納領域追加前に関するデータ構造である。
表Ｔ２に対し９０１で示すように表定義情報テーブルに設定をする。
分割数は４で再配置種別はＯＦＦとなる。
表Ｔ２はハッシングにより複数のデータベース格納領域に分割して格納されている。また、９０２で示すように分割定義情報テーブルに設定をする。
データベース格納領域がＤＢＡＲＥＡ１１，ＤＢＡＲＥＡ１２，ＤＢＡＲＥＡ１３，ＤＢＡＲＥＡ１４となる分割情報を４行挿入し、全データベース格納領域を検索するようにするために実行時検索種別にＯＮを設定する。
図９のテーブルは図４のステップ４０３で設定され、ステップ４０４で参照される。
【００１８】
図１０はデータベース格納領域追加，再配置中に関するデータ構造である。
表Ｔ２に対し１００１で示すように表定義情報テーブルに設定をする。
分割数は６で再配置種別はＯＮとなる。
また、１００２で示すように分割定義情報テーブルに設定をする。
既に存在するデータベース格納領域は図９の９０２と同じで、新たに分割情報を２行挿入する。
この２行でのデータベース格納領域は特に設定する必要がないためＮＵＬＬ値としておく。＊＊＊＊＊＊＊＊はＮＵＬＬ値を表す。
また、実際に存在するデータベース格納領域の実行時検索種別はＯＮとなるが、新たに追加した２行のデータベース格納領域は定義情報のみなので、実行時には検索しないようＯＦＦとする。
図１０のテーブルは図４のステップ４０８および４０９で設定され、ステップ４１０および４１１で参照される。
【００１９】
図１１はデータベース格納領域追加，再配置後に関するデータ構造である。
表Ｔ２に対し１１０１で示すように表定義情報テーブルに設定をする。
分割数は６で再配置種別はＯＦＦとなる。
また、１１０２で示すように分割定義情報テーブルに設定をする。
分割定義情報テーブルは図１０の１００２と同じとなる。
図１１のテーブルは図４のステップ４１４および４１５で設定され、ステップ４１６および４１７で参照される。
【００２０】
【発明の効果】
本発明を用いることにより、ＳＱＬをデータベース格納領域追加，再配置中に実行した場合の実行時間およびアクセスプランが事前にわかるため、実行時間を減らし最適なアクセスプランとなるように、ＳＱＬ文の変更やインデックスの追加，削除等のチューニングを実際の検索処理の実行の前に行っておくことが出来る。
【図面の簡単な説明】
【図１】チューニング前後の実行時間およびアクセスプランの表示例を示す図である。
【図２】データベースマネジメントシステム（ＤＢＭＳ）全体を表す構成図である。
【図３】本発明におけるフロントエンドサーバの構成を示す図である。
【図４】本発明における検索処理のフローチャートを示す図である。
【図５】実施例で使用する定義系ＳＱＬの例を示す図である。
【図６】データベース格納領域の追加個数が適切でない場合の表示例を示す図である。
【図７】データベース格納領域の追加，再配置中にエラーが発生した場合の表示例を示す図である。
【図８】データベース格納領域の追加，再配置中の運用方法に関する注意事項の表示例を示す図である。
【図９】データベース格納領域追加前の状態のデータ構造を示す図である。
【図１０】データベース格納領域追加，再配置中の状態のデータ構造を示す図である。
【図１１】データベース格納領域追加，再配置後の状態のデータ構造を示す図である。
【符号の説明】
２０１　　クライアント
２０２　　フロントエンドサーバ
２０３　　ディクショナリサーバ
２０４　　表定義情報，分割情報
２０５、２０７　　データ取り出しサーバ
２０６、２０８　　データベース格納領域
２０９　　ネットワーク
【図１】
2004021797.tif 000003
【図２】
2004021797.tif 000004
【図３】
2004021797.tif 000005
【図４】
2004021797.tif 000006
【図５】
2004021797.tif 000007
【図６】
2004021797.tif 000008
【図７】
2004021797.tif 000009
【図８】
2004021797.tif 000010
【図９】
2004021797.tif 000011
【図１０】
2004021797.tif 000012
【図１１】
2004021797.tif 000013