JP2001142898A

JP2001142898A - 問合せ処理の実行可否判定方法

Info

Publication number: JP2001142898A
Application number: JP32500499A
Authority: JP
Inventors: Akira Shimizu; 清水　　晃; Shigekazu Inohara; 茂和猪原; Itaru Nishizawa; 格西澤; Nobutoshi Sagawa; 暢俊佐川
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1999-11-16
Filing date: 1999-11-16
Publication date: 2001-05-25

Abstract

(57)【要約】【課題】ユーザが予測する以上に長く実行する問合せで
ある長時間実行問合せの実行を抑止する。【解決手段】問合せ処理の実行時間を予測する実行時間
予測（１２３）と、実行時間予測により問合せ実行の可
否を判定する実行可否判定（１２４）と、問合せ処理中
に予測した実行時間を修正する実行時間予測修正部（１
２６）とを導入する。【効果】長時間実行問合せの実行を抑止可能となる結
果、データシステムハブまたはＤＢＭＳのスループット
が向上する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はコンピュータシステ
ムに関し、特に１つ以上のデータベースを用いてユーザ
の問合せを処理するデータ処理システムによる問合せ実
行の可否判定方法に関する。

【０００２】

【従来の技術】現在、企業の計算機システムには、数多
くのデータベース管理システム（ＤＢＭＳ）が存在して
いる。これらのＤＢＭＳは、歴史的に企業の発展ととも
に目的別に追加されてきたものである。現在、業種間の
規制緩和が急速に進展しており、これに伴い各企業は新
規事業を追加していく傾向が強い。この際、新規事業の
導入に伴って、さらに新しいＤＢＭＳが導入される場面
が多くなっている。

【０００３】一方、規制緩和に伴い、各企業は他企業に
ない新たなサービスなどにより顧客によりよいサービス
を提供し、その結果優良な顧客をより多く獲得しようと
試みている。この際、ＤＢＭＳ群に蓄積された過去の企
業活動、顧客動向などを分析する必要性が高まり、デー
タウェアハウスやデータマートの構築を行う企業が非常
に多くなっている。

【０００４】データウェアハウスやデータマートの構築
には、先に述べた多数のＤＢＭＳに蓄積されたデータ
を、ひとつの論理的に統合されたデータベースとするこ
とが必要となる。また、データウェアハウスやデータマ
ートのような分析処理のベースとなるデータベースを構
築する以外にも、新規業務を迅速に立ち上げる目的で、
従来のＤＢＭＳ群を論理的に統合することが、企業の競
争力を高める目的で行われている。論理的に統合したデ
ータベースをベースとすることにより、新規業務のため
の応用プログラム（アプリケーション）構築の高速化を
図ることが可能となるためである。

【０００５】ＤＢＭＳ群を論理的に統合する方法とし
て、ＤＢＭＳ群とアプリケーション群の間に、ＤＢＭＳ
群への統一的なアクセスを提供する「データベースハ
ブ」のシステムを置く方法がある。データベースハブ
は、アプリケーションからの問合せ（典型的には、Ｓｔ
ｒｕｃｔｕｒｅｄＱｕｅｒｙＬａｎｇｕａｇｅ（Ｓ
ＱＬ）言語で記述された問合せ）を受けつけ、その問合
せをＤＢＭＳ群への問合せへ分解・変換する。そしてデ
ータベースハブは、分解・変換した問合せをＤＢＭＳ群
に発行し、ＤＢＭＳ群から問合せ結果を作成するための
データを収集し、アプリケーションの問合せに対する最
終的な結果を得て、アプリケーションにその結果を返
す。

【０００６】このようなデータベースハブには、多種多
様なアプリケーションの問合せが発行される。このよう
な問合せ群は、分析系業務で発行する実行時間の長い複
雑な問合せから定型業務で発行する実行時間の短い単純
な問合せまで、多種多様である。

【０００７】分析系業務で発行される問合せは複雑なた
め、ユーザが予測する以上に実行時間が長い問合せ（長
時間実行問合せ）が発行されてしまう場合がある。ま
た、タイプミス等で意図せず長時間実行問合せを発行し
てしまうこともある。

【０００８】このような長時間実行問合せは、データベ
ースハブまたはＤＢＭＳなどのデータ処理システムのス
ループットの低下を招く。なぜなら、長時間実行問合せ
はＣＰＵやメモリなどの計算機資源を長く使用するた
め、他の問合せ実行を妨げてしまう。また、ユーザが問
合せ結果を必要とする時までに処理が終了しないため、
業務に支障をきたす可能性がある。このため、データ処
理システムを効率よく運営するために、長時間実行問合
せを抑止する機能が必要となる。

【０００９】長時間実行問合せの実行を抑止するため
に、従来技術では問合せ処理を実行するために必要とさ
れるＣＰＵ時間や二次記憶装置へのＩ／Ｏ回数などのコ
ストを予測し、該コストを問合せ実行の可否判定の基準
としている。文献「ＤＢ２ＵｎｉｖｅｒｓａｌＤａｔ
ａｂａｓｅｆｏｒＯＳ／３９０ＲｅｌｅａｓｅＰｌ
ａｎｎｉｎｇＧｕｉｄｅＶｅｒｓｉｏｎ６」（ｐｐ．
６７−ｐｐ．７９、ＩＢＭ社１９９９年６月；以下文献
１と称す）に記載されているシステム（以下公知例１と
称す）がこれにあたる。

【００１０】

【発明が解決しようとする課題】問合せ処理コストは実
行時間を反映しているが、実行時間そのものではない。
同じ処理コストでも、使用できる計算機資源や実行時の
計算機負荷によって実行時間は異なる。そのため、コス
トを基準とした実行可否判定では、実際に長時間実行問
合せでない問合せの実行を抑止してしまうこともある。
逆に、長時間実行問合せであるにもかかわらず該問合せ
の実行を抑止できないこともある。このため、実行時間
を基準として実行可否判定を行う必要がある。

【００１１】即ち、本発明が解決しようとする第１の課
題は、実行時間を基準とした実行可否判定を行い長時間
実行問合せの実行を抑止することである。

【００１２】また、実行前の問合せ処理の実行時間予測
には誤差が含まれる場合があるため、誤って長時間実行
問合せが実行される可能性もある。このため、実行中の
問合せに関しても長時間実行を行っている問合せを停止
する必要が出てくる。

【００１３】即ち、本発明が解決しようとする第２の課
題は、実行中の長時間実行問合せの実行を抑止すること
である。

【００１４】データベースハブの場合、アプリケーショ
ンから発行される問合せ（第１の問合せ）を処理する際
に、ＤＢＭＳに問合せ（第２の問合せ）を発行する。該
ＤＢＭＳはデータベースハブ以外から発行される問合せ
も処理しているため、第２の問合せがデータベースハブ
以外から発行される問合せ処理の妨げにならないほうが
望ましい。該ＤＢＭＳはデータベースハブとは独立に管
理されるのが普通なので、該ＤＢＭＳで他の問合せ処理
の妨げになる第２の問合せを抑止することは困難であ
る。このため、データベースハブで該ＤＢＭＳの問合せ
処理の妨げになる第２の問合せの発行を抑止する必要が
ある。

【００１５】即ち、本発明が解決しようとする第３の課
題は、ＤＢＭＳの問合せ処理を妨げる問合せの発行をデ
ータベースハブで抑止することである。

【００１６】問合せ実行の実行時間を予測する際、正確
な実行プランを生成する必要がある。データベースハブ
の場合には、ＤＢＭＳでの実行プランを指定できない。
このため、データベースハブはＤＢＭＳでの実行プラン
の予測を行う。

【００１７】即ち、本発明が解決しようとする第４の課
題は、データベースハブでＤＢＭＳで処理される正確な
実行プランを取得することである。

【００１８】以上４つの課題を解決することにより、分
析系業務におけるデータベースハブおよびＤＢＭＳの効
率のよい運営を可能とすることが本発明の目的である。

【００１９】

【課題を解決するための手段】第１の課題に対する解決
手段として、本発明では、データベースハブ（またはＤ
ＢＭＳ）に、実行時間予測を導入する。実行時間予測
は、アプリケーションから発行された問合せより実行時
間を予測する方法である。初めに、問合せの実行プラン
から問合せ処理に必要なコストを計算する。該コストか
ら問合せ処理を実行する計算機性能と計算機負荷を用い
て、該コストより実行時間を予測する。予測した実行時
間（予測実行時間）を基準に実行可否判定を行う。これ
により、実行時間を基準とした実行可否判定を行い長時
間実行問合せの実行を抑止する第１の課題が解決され
た。

【００２０】第２の課題に対する解決手段として、本発
明では、データベースハブ（またはＤＢＭＳ）に、実行
時間予測修正を導入する。実行時間予測修正は、実行中
の問合せ処理の経過情報を用いて実行前に予測実行時間
を修正する方法である。例えば、ある処理までの実行時
間が該処理までの予測実行時間の１．５倍であった場
合、問合せ処理全体の予測実行時間を１．５倍にすると
いった修正である。修正された予測実行時間を基準に実
行中の問合せの実行可否判定を行う。これにより、実行
中の長時間実行問合せの実行を抑止する第２の課題が解
決された。

【００２１】第３の課題に対する解決手段として、本発
明では、データベースハブがＤＢＭＳに発行する問合せ
に対する実行可否判定基準を設定できることを可能に
し、データベースハブの実行可否判定においてＤＢＭＳ
に発行される問合せでも実行可否判定を行う。これによ
り、ＤＢＭＳの問合せ処理を妨げる問合せの発行をデー
タベースハブで抑止する第３の課題が解決された。

【００２２】第４の課題に対する解決手段として、本発
明では、データベースハブにおいて、ＤＢＭＳから得ら
れる実行プランを用いて実行プランを修正する実行プラ
ン修正を導入する。問合せから実行プラン生成後、ＤＢ
ＭＳでの実行プランを取得し、データベースハブでの実
行プランに修正を加える。またＤＢＭＳでの実行プラン
取得時にコストも取得できる場合、該コストを利用す
る。これにより、データベースハブでＤＢＭＳで処理さ
れる正確な実行プランを取得する第４の課題が解決され
た。

【００２３】

【発明の実施の形態】本発明の実施の一形態を、図面を
参照しながら説明する。

【００２４】全体構成図１を用いて、本発明の実施の一形態（第１の実施例）
の全体構成を説明する。

【００２５】図１は第１の実施例が好適に用いられるコ
ンピュータシステムである。第１の実施例の全体は、１
つ以上のコンピュータ（データ処理システム１００、１
つ以上のクライアントコンピュータ１０１、１０１’、
…、管理用コンピュータ１０２、１つ以上のＤＢサーバ
１０５、１０５’、…）がクライアント側ネットワーク
１０３およびサーバ側ネットワーク１０４で相互に接続
されたコンピュータシステムである。

【００２６】クライアント側ネットワーク１０３および
サーバ側ネットワーク１０４のいずれも、ある団体（企
業や学校や類似の団体）の全体や一部門でよく使用され
るＬＡＮでもよく、また地理的に分散した複数の地点を
結合するＷＡＮの一部または全部でもよい。またこれら
のネットワークは、計算機間結合網や並列計算機内部の
プロセッサ要素間の結合網でもよい。また、クライアン
ト側ネットワーク１０３とサーバ側ネットワーク１０４
が同一のネットワークであっても差し支えない。

【００２７】データ処理システム１００、クライアント
コンピュータ１０１、１０１’、…、管理用コンピュー
タ１０２、ＤＢサーバ１０５、１０５’、…はいずれ
も、パーソナルコンピュータ、ワークステーション、並
列計算機、大型計算機、小型携帯型コンピュータ等、任
意のコンピュータでよい。また、図１ではデータ処理シ
ステム１００、クライアントコンピュータ１０１、１０
１’、…、管理用コンピュータ１０２、ＤＢサーバ１０
５、１０５’、…をそれぞれ独立したコンピュータとし
て図示しているが、これらのうち任意の組み合わせが、
１つのコンピュータであっても差し支えない。また、図
１に示したデータ処理システム１００、クライアントコ
ンピュータ１０１、１０１’、…、管理用コンピュータ
１０２、ＤＢサーバ１０５、１０５’、…の数と構成は
例として示したもので、本発明の範囲を限定するもので
はない。

【００２８】クライアントコンピュータ１０１、１０
１’、…では、ユーザの処理を行うプログラムであるア
プリケーション１１０、１１０’、…が動作する。アプ
リケーション１１０、１１０’、…は、データベースに
対する参照または更新を行うために問合せ（例えばＳｔ
ｒｕｃｔｕｒｅｄＱｕｅｒｙＬａｎｇｕａｇｅ（ＳＱ
Ｌ）言語のような問合せ言語で記述された問合せ）を発
行する。

【００２９】ＤＢサーバ１０５、１０５’、…では、１
つ以上のデータベースを管理しているＤＢＭＳ１１２、
１１２’、…が動作している。ＤＢＭＳ１１２、１１
２’、…は、管理しているデータベースを二次記憶装置
１０６、１０６’、…上に保持しており、他のプログラ
ムの問合せに応じてデータベースに対する参照または更
新を行う。データベースは、データを１つ上のカラムか
ら成る１つ以上のレコードから成る１つ以上の表から構
成されるリレーショナルデータベースで差し支えない
し、他の形式のデータベース（ネットワーク型データベ
ースや階層型データベース、オブジェクト指向データベ
ース、オブジェクトストレージ）やファイルシステムで
も差し支えない。

【００３０】管理用コンピュータ１０２では、管理用ア
プリケーション１１１が動作している。管理用アプリケ
ーション１１１はデータ処理システム１００の管理を行
うプログラムであり、データ処理システム１００または
図１のシステム全体の管理者が利用する。

【００３１】データ処理システム１００はクライアント
コンピュータ１０１、１０１’、…の発行する第１の問
合せを受け付け、必要に応じＤＢサーバ１０５、１０
５’、…への１つ以上の第２の問合せを作成し発行し、
第１の問合せが指定した参照または更新を行い、結果の
データを第１の問合せの発行元に返す。即ち、データ処
理システム１００は、ＤＢサーバ１０５、１０５’、…
の保持するデータベース群への統一的なアクセスを実現
し、クライアントコンピュータ１０１、１０１’、…へ
統合されたデータベースを提供するデータベースハブで
ある。

【００３２】入出力処理部１２０、問合せ解析・最適化
部１２１、実行プラン修正部１２２、実行時間予測部１
２３、実行可否判定部１２４、１２７、実行制御部１２
５、実行時間予測修正部１２６、ＤＢＭＳ情報取得部１
２８、実行可否判定管理部１２９は、データ処理システ
ム１００を構成する構成要素である。各構成要素の詳細
な説明は後で述べることにし、ここでは概略を説明する
のに留める。

【００３３】入出力処理部１２０は、クライアントコン
ピュータ１０１、１０１’、…から問合せ要求を受け付
け、管理用コンピュータ１０２から管理要求を受けつ
け、これらの問合せの返答を行う。

【００３４】問合せ解析・最適化部１２１は、入力処理
部１２０では受け付けた問合せに対し問合せ解析と問合
せ最適化を行い、実行プランを作成する。

【００３５】実行プラン修正部１２２は、問合せ解析・
最適化部１２１で生成された実行プランに対し、ＤＢＭ
Ｓから得られた実行プランを用い修正を加える。

【００３６】実行時間予測部１２３は、実行プラン修正
部１２２で作成された実行プランを用い実行時間を予測
する。

【００３７】実行可否判定部１２４、１２７は、実行時
間予測部１２３及び実行時間予測修正部１２６で予測さ
れた実行時間と実行可否判定基準制御部１２９から得ら
れた実行可否判定基準とを比較し、問合せ実行の可否を
判定する。

【００３８】実行制御部１２５は、実行プランに基づき
問合せを処理をし、問合せへの結果を作成する。

【００３９】実行時間予測修正部１２６は、実行制御部
１２５から実行中の問合せの経過情報を用いて予測実行
時間を修正する。

【００４０】ＤＢＭＳ情報取得部１２８は、ＤＢＭＳの
各種情報を管理しており、実行プラン修正部１２２及び
実行時間予測部１２３の要求に対しＤＢＭＳの種類に応
じた情報取得問合せを発行する。

【００４１】実行可否判定管理部１２９は、実行可否判
定部１２４、１２７で用いる実行可否判定基準を管理す
る。

【００４２】以上が第１の実施例の全体構成である。

【００４３】ＤＢＭＳ１１２、１１２’、…の役割を兼
ねたデータ処理システムの実施例は、実行プラン修正部
１２２とＤＢＭＳ情報取得部１２８を取り除いた構成で
ある。また、以降説明するデータ処理システムで行う処
理も第１の実施例と本質的に同じなため、ＤＢＭＳ１１
２、１１２’、…の役割を兼ねたデータ処理システムの
実施例の詳しい説明は省略する。

【００４４】データ処理システムで行う処理データ処理システム１００で行う処理は、問合せ処理、
実行可否判定基準設定処理がある。

【００４５】問合せ処理の流れ図１を用いてデータ処理システムの問合せ処理の流れを
説明する。

【００４６】アプリケーション１１０が発行した第１の
問合せは、クライアント側ネットワークを経由して入出
力処理部１２０に到達する（１３０）。

【００４７】入出力処理部１２０では、アプリケーショ
ン１１０の要求が問合せであることを認識すると、第１
問合せを問合せ解析・最適化部１２１に渡す（１３
１）。

【００４８】問合せ解析・最適化部１２１では、第１の
問合せに対し問合せ解析と問合せ最適化を行い第１の実
行プランを作成し、実行プラン修正部１２２に第１の実
行プランを渡す（１３２）。問合せ解析では、第１の問
合せに対し字句解析、構文解析、意味解析を行い、第１
の問合せの第１の解析木を生成する。問合せ最適化で
は、問合せ解析で生成された第１の解析木から第１の実
行プランを作成する。問合せ最適化にはルールベース最
適化とコストベース最適化があるが、データ処理システ
ム１００ではどちらを用いても差し支えない。問合せ解
析と問合せ最適化で行われる動作は、コンパイラ、デー
タベース管理システムで用いられている技術なので、こ
こではこれ以上詳細には述べない。

【００４９】図３で示したデータ構造が生成される実行
プランの一例である。実行プランは木構造になってお
り、各ノード３１１、３１２、３１３、３１４、３１
５、３１６、３１７はノード内データ構造３００と同じ
構成をしている。ノードＩＤ３０１は、実行プラン内で
一意な識別子である。例えば、実行プランのノードごと
に連続した整数を用いてもよいし、ノードのデータがあ
るアドレスを用いてもよい。操作内容３０２は、ノード
で行われる操作内容を示している。例えば、「ｊｏｉｎ
−ａｔ−ＤＢＭＳ１」は「ＤＢＭＳ１でジョインを行う」
ことを示しており、「ａｃｃｅｓｓ−ＤＢＭＳ１．Ｔ３」
は「ＤＢＭＳ１の表Ｔ３を参照する」ことを示しており、
「ｄａｔａｂａｓｅ−ｈｕｂ−ｊｏｉｎ」は「データ処理
システム１００でジョインする」ことを示している。予
測結果行数３０３は、操作内容３０２の結果行数の予測
値である。予測結果行数３０３が−１の場合、予測結果
行数３０３が計算されていないことを示す。予測コスト
３０４は、ノード以下の部分木を処理するのに必要なコ
ストを示す。コストにはＣＰＵ時間、ＣＰＵステップ
数、Ｉ／Ｏ回数などが用いられる。予測コスト３０４の
値が−１の場合、予測コスト３０４が計算されていない
ことを示す。予測実行時間３０５は、ノード以下の部分
木を処理するのに必要な実行時間を示す。予測実行時間
３０５が−１の場合、予測実行時間３０５が計算されて
いないことを示す。

【００５０】実行プラン修正部１２２では、ＤＢＭＳか
ら得られる実行プランの情報を用いて第１の実行プラン
に修正を加え、第２の実行プランを生成し、実行時間予
測部１２３に第２の実行プランを渡す（１３３）。実行
プランを修正する動作は、実行プラン修正処理の流れで
詳しく説明する。

【００５１】実行時間予測部１２３は、実行プラン修正
部１２２から受け取った第２の実行プランを用い実行時
間を予測し、予測された実行時間（第１の予測実行時
間）を第２の実行プランのノードの予測時間３０５に設
定し、第２の実行プランを実行可否判定部１２４に渡す
（１３４）。実行プランから実行時間を計算する動作は
実行時間予測処理の流れで詳しく説明する。

【００５２】実行可否判定部１２４は、実行時間予測部
１２３で予測された第１の予測実行時間を基準にして第
１の問合せの実行可否を判定し、実行可であれば実行制
御部１２５に第２の実行プランを渡し（１３５）、実行
不可であれば第１の問合せの結果としてエラーを入出力
処理部１２０に返す（１６０）。実行可否判定の詳細に
ついては実行可否判定処理の流れで説明する。

【００５３】実行制御部１２５は、第２の問合せ処理動
作に基づき第１の問合せを処理し、その結果を入出力処
理部１２０に返す。第２の問合せ処理動作に従いＤＢＭ
Ｓ１１２、１１２’、…に第２の問合せをサーバ側ネッ
トワーク１０４を介して発行し（１３６）、第２の問合
せの結果を取得する（１３７）。加工が必要であれば第
２の問合せの結果を加工し、第１の問合せの結果を作成
する。作成された第１の問合せの結果を入出力処理部１
２０に返す（１３８）。第１の問合せ処理実行時に実行
時間予測修正及び実行可否判定処理を行い、実行不可と
判定された場合処理を中止し、第１の問合せの結果とし
てエラーを入出力処理部１２０に返す（１７４）。実行
時間予測修正及び実行可否判定処理の動作については、
実行時間予測修正及び実行可否判定処理の流れで詳しく
述べる。実行時間予測修正及び実行可否判定処理を行う
タイミングはいつでもよい。例えば、「３０分毎に実行
しているすべての問合せに対して行う」のようにデータ
処理システム１００全体への指定でもよいし、問合せ処
理動作の中に「ＤＢＭＳ１１２への問合せの後に実行時
間予測修正及び実行可否判定処理を行う」のように問合
せ毎に指定を行ってもよい。

【００５４】入出力処理部１２０は、第１の問合せの結
果を実行可否判定部１２４または実行制御部１２５から
うけとり、第１の問合せを発行したアプリケーション１
１０に第１の問合せの結果をクライアント側ネットワー
ク１０３を介して返す（１３８）。

【００５５】以上が問合せ処理の流れである。

【００５６】実行プラン修正処理の流れ実行プラン修正処理の流れを図２と図１を用いて説明す
る。

【００５７】ステップ２００では、問合せ解析・最適化
部１２１から受け取った第１の実行プラン（予測実行プ
ラン）から各ＤＢＭＳに発行する第２の問合せ群を生成
する。

【００５８】ステップ２０１では、ＤＢＭＳ情報取得部
１２８を介して、第２の問合せ群からＤＢＭＳの実行プ
ラン（取得実行プラン）を受け取る。

【００５９】ＤＢＭＳ情報取得部１２８では、実行プラ
ン修正部１２２から問合せ群を受け取り（１４０）、実
行プランを取得する問合せをＤＢＭＳに応じ発行する
（１４１）。実行プランを取得する問合せには、例えば
ＤＢ２／ＯＳ３９０の場合ＥＸＰＬＡＩＮ文を用いるこ
とができる。各ＤＢＭＳから結果を受け取ると（１４
２）、データ処理システム１００で用いている実行プラ
ンのデータ構造にし、実行プラン修正部１２２に返す
（１４３）。

【００６０】ステップ２０３では、取得実行プランを受
け取ると、修正する対象となる予測実行プランの中の各
ＤＢＭＳで処理される部分木を列挙する。

【００６１】ステップ２０４では、ステップ２０３で列
挙された全ての部分木が対応する取得実行プランと比較
されているか判定する。全ての部分木が比較されていな
い場合（Ｎ）、ステップ２０５に進む。全ての部分木が
比較されている場合（Ｙ）、実行プラン修正処理を終了
する。

【００６２】ステップ２０５では、取得実行プラン中に
コストまたは結果行数が設定されている場合、予測実行
プランの対応するノードの予測結果行数３０３または予
測コスト３０４を設定する。

【００６３】ステップ２０６では、取得実行プランと予
測実行プランの部分木を比較し、同じ実行プランかどう
かを判定する。同じ実行プランの場合（Ｙ）、ステップ
２０４に戻る。実行プランが異なる場合（Ｎ）、ステッ
プ２０７に進む。

【００６４】ステップ２０７では、取得実行プランと同
じ実行プランになるように予測実行プランの部分木を修
正する。

【００６５】実行プラン修正処理の一例を図３、図４、
図５に示す。図３の実行プランが修正前の予測実行プラ
ンで、図４がＤＢＭＳ１から取得した取得実行プラン
で、図５が修正された予測実行プランである。ノード３
１２以下の部分木が図４の取得実行プランに対応してい
るが、実行プランが異なるため図５では図４の実行プラ
ンと同じになるように修正されている。またＤＢＭＳ１
の取得実行プランではコストも取得できているため、ノ
ード５０２の予測コストの値が設定されている。

【００６６】ＤＢＭＳでの実行プランが修正された実行
プランは実行時間予測部１２３に渡される（１３３）。

【００６７】以上が問合せ処理動作修正処理の流れであ
る。

【００６８】実行時間予測処理の流れ実行時間予測処理の流れを図６と図１を用いて説明す
る。

【００６９】ステップ６０１では、実行時間予測部１２
３はＤＢＭＳ情報取得部１２８からＤＢＭＳ統計情報お
よびＤＢＭＳ性能情報７００を取得する（１４４）。

【００７０】ＤＢＭＳ統計情報には、ＤＢＭＳで処理さ
れる実行プランの部分木のコストを計算するのに必要な
情報である。例えば、表の大きさ（表中のレコード
数）、カラム中の値の最大値、最小値、平均値、カラム
中の異なる値の数、カラム中の値の分布などがある。

【００７１】ＤＢＭＳ性能情報７００は図７の構成をし
ている。ＤＢＭＳ名７０１はＤＢＭＳを識別するデータ
処理システム１００で一意な名前である。ＣＰＵ数７０
２は、ＤＢＭＳが動作している計算機のＣＰＵの数であ
る。ＭＩＰＳ値７０３は、ＤＢＭＳが動作している計算
機のＣＰＵ１個が１秒間に処理できる命令数である。ｌ
ｏａｄａｖｅｒａｇｅ７０４は、ＤＢＭＳが動作して
いる計算機の単位時間当りの実行プロセス数である。

【００７２】ステップ６０２では、各ＤＢＭＳで処理さ
れる実行プランの部分木を列挙する。

【００７３】ステップ６０３では、ステップ６０２で列
挙された全ての部分木の予測実行時間３０５が計算され
ているかを判定する。全ての部分木で予測実行時間３０
５が計算されていなければ（Ｎ）、ステップ６０４に進
む。全ての部分木の予測実行時間３０５が計算されてい
れば（Ｙ）、ステップ６０７に進む。

【００７４】ステップ６０４では、対象としている部分
木の予測コスト３０４が計算されているかを判定する。
予測コスト３０４が計算されていれば（Ｙ）ステップ６
０６に進み、計算されていなければ（Ｎ）ステップ６０
５に進む。

【００７５】ステップ６０５では、ステップ６０１で取
得したＤＢＭＳ統計情報を用いて部分木の予測コスト３
０４を求める。部分木の予測コスト３０４の計算方法
は、データベースの分野で古くから研究されており、こ
こでは詳しくは述べない。

【００７６】ステップ６０６では、部分木の予測コスト
３０４からＤＢＭＳ性能情報７００を用いて予測実行時
間３０５を計算する。予測実行時間３０５は、関数Ｆを
用いて予測コスト３０４とＤＢＭＳ性能情報７００から
計算する。例えば、予測コスト３０４がＣＰＵステップ
数で計算されている場合、予測実行時間３０５＝Ｆ（予
測コスト３０４、ＤＢＭＳ性能情報７００）＝予測コス
ト３０４／｛ＣＰＵ数７０２＊ＭＩＰＳ値７０３／ｌｏ
ａｄａｖｅｒａｇｅ７０４｝と計算する。

【００７７】ステップ６０７では、部分木の予測実行時
間３０５から実行プランの実行時間３０５を求める。ま
ず、データ処理システム１００で処理されるノードで構
成されている部分木のコストを求め、コストから実行時
間を計算する。データ処理システム１００で処理される
ノードで構成されている部分木のコスト及び実行時間の
計算方法は、前述のＤＢＭＳで処理される部分木の予測
コスト３０４と予測実行時間３０５の計算方法と同じな
ので省略する。実行プランの予測実行時間３０５は、Ｄ
ＢＭＳで処理される部分木の予測実行時間３０５とデー
タ処理システム１００で処理されるノードで構成される
部分木の計算された実行時間から計算する。例えば、Ｄ
ＢＭＳで処理される部分木の予測実行時間とデータ処理
システム１００で処理されるノードで構成される部分木
の計算された実行時間の総和を実行プランの予測実行時
間３０５とする方法がある。また別の計算方法として、
ＤＢＭＳで処理される部分木の予測実行時間の最大値と
データ処理システム１００で処理されるノードで構成さ
れた部分木の計算された実行時間の和を実行プランの予
測実行時間とするものもある。

【００７８】予測実行時間３０５が計算された実行プラ
ンは実行可否判定部１２４に渡される（１３４）。

【００７９】以上が実行時間予測処理の流れである。

【００８０】実行可否判定処理の流れ実行可否判定処理の流れを図８と図１を用いて説明す
る。

【００８１】ステップ８０１では、実行可否判定部１２
４が実行可否判定管理部１２９から実行可否判定基準９
００を受け取る（１８２）。

【００８２】実行可否判定基準９００は図９の構成をし
ている。ＤＢＭＳ名９０１は、実行可否を判定する問合
せで問合せが発行されるＤＢＭＳを示す。例えば、ＤＢ
ＭＳを識別するデータ処理システム１００で一意な名前
や、データ処理システム１００と全ＤＢＭＳを示す
「＊」である。ユーザ名９０２は、実行可否を判定する
問合せを発行するユーザを示す。例えば、データ処理シ
ステム１００を利用するユーザアカウントや、全てのユ
ーザを示す「＊」である。実行時間９０３は、ＤＢＭＳ
名９０１で指定されるＤＢＭＳに発行されるユーザ名９
０２で指定されるユーザの問合せの実行可能な予測実行
時間３０５の最大値である。ＣＰＵステップ数９０４
は、ＤＢＭＳ名９０１で指定されるＤＢＭＳに発行され
るユーザ名９０２で指定されるユーザの問合せの実行可
能なＣＰＵステップ数の最大値である。図９の実行可否
判定基準９００の各行は上から順に、「データ処理シス
テム１００に発行される全てのユーザの問合せは、実行
時間の基準では７、２００秒以下、ＣＰＵステップ数の
基準では７２０、０００Ｍステップ以下であること」、
「ＤＢＭＳ１に発行されるＵＳＥＲ１の問合せは、実行
時間の基準では１、２００秒以下、ＣＰＵステップ数の
基準では４８０、０００Ｍステップ以下であること」、
「ＤＢＭＳ１に発行される全ユーザの問合せは、実行時
間の基準では６００秒以下、ＣＰＵステップ数の基準で
は２４０、０００Ｍステップ以下であること」、「ＤＢ
ＭＳ２に発行される全ユーザの問合せは、実行時間の基
準では３、６００秒以下、ＣＰＵステップ数の基準では
３６０、０００Ｍステップ以下であること」を示してい
る。

【００８３】ステップ８０２では、対象となる全ての実
行可否判定基準９００で実行プランの実行可否を判定し
てるかを判定する。対象となる実行可否判定基準９００
とは、ユーザ名９０２が問合せを発行したユーザ名と等
しい行か、もしくはユーザ名９０２が「＊」である行の
ＤＢＭＳ名９０１がユーザ名９０２が問合せを発行した
ユーザ名と等しい行のＤＢＭＳ名９０１と等しくない行
である。対象となる全ての実行可否判定基準９００で実
行可否を判定していなければ（Ｎ）ステップ８０３に進
み、対象となる全ての実行可否判定基準９００で実行可
否を判定していれば（Ｙ）ステップ８０５に進む。

【００８４】ステップ８０３では、一つの実行可否判定
基準に基づき実行プランの実行可否を判定する。実行プ
ランの実行可否を判定する基準は複数あるので、全ての
条件を満たした場合だけ実行可と判定してもよい。他に
も、複数ある基準のうち特定数の基準の条件を満たして
いる場合を実行可と判断してもよいし、特定の基準を満
たしている場合を実行可と判断してもよい。実行可と判
定された場合（Ｙ）ステップ８０２に戻り、実行可と判
定されなかった場合（Ｎ）ステップ８０４に進む。

【００８５】ステップ８０４では、実行プランを実行不
可と判定し、入出力処理部１２０に問合せの結果として
エラーを返す（１６０）。

【００８６】ステップ８０５では、実行プランを実行可
と判定し、実行プランを実行制御部１２５に渡す（１３
５）。

【００８７】以上が実行可否判定処理の流れである。

【００８８】実行時間予測修正及び実行可否判定処理の
流れ実行時間予測修正及び実行可否判定処理の流れを図
１０と図１を用いて説明する。

【００８９】ステップ１００１では、実行制御部１２５
から問合せ実行の経過情報１１００を受け取る（１７
０）。

【００９０】経過情報１１００は図１１の構成をしてい
る。ノードＩＤ１１０１は、実行プランを構成している
ノードのノードＩＤ３０１である。実行時間１１０２
は、ノードＩＤ１１０１で指定されたノードより下の部
分木の実行時間である。

【００９１】ステップ１００２では、ステップ１００１
で受け取った経過情報１１００を用いて実行プランの予
測実行時間３０５を修正する。予測実行時間の修正方法
の一例として、ノードＩＤ１１０１で特定されるノード
の予測実行時間３０５を実行時間１１０２に設定し、再
びステップ６０７と同じ方法で実行プランの予測実行時
間３０５を計算する方法がある。他にも、実行時間１１
０２がノードＩＤ１１０１の予測実行時間３０５の１．
５倍だった場合実行プランの予測実行時間３０５を１．
５倍する方法も考えられる。予測実行時間を修正された
実行プランは実行可否判定部１２７へ渡される（１７
１）。

【００９２】ステップ１００３では、修正された予測実
行時間３０５を持つ実行プランの実行可否判定を実行可
否判定部１２７が行う。実行可否判定の動作については
前述の実行可否判定処理の流れと同じなので、ここでは
省略する。

【００９３】ステップ１００４では、ステップ１００３
の実行可否判定の結果を判定する。実行プランが実行可
と判定されていれば（Ｙ）ステップ１００５へ進み、実
行プランが実行不可と判定されていれば（Ｎ）、ステッ
プ１００６に進む。

【００９４】ステップ１００５では、問合せ処理の実行
を継続する。

【００９５】ステップ１００６では、実行不可を実行制
御部１２５に通知する（１７２）。

【００９６】ステップ１００７では、実行不可となった
問合せ処理の後処理を行い問合せ処理を中止させ、入出
力処理部１２０へ問合せの結果としてエラーを返す（１
７３）。

【００９７】以上が実行時間予測修正及び実行可否判定
処理の流れである。

【００９８】実行可否判定基準設定の流れ実行可否判定基準設定処理の流れを図１を用いて説明す
る。

【００９９】実行可否判定基準設定要求は管理アプリケ
ーション１１１からデータ処理システム１００に発行さ
れる（１８０）。

【０１００】入出力処理部１２０は、要求が実行可否判
定基準設定要求と識別すると、該実行可否判定基準設定
要求を実行可否判定管理部１２９に送る（１８１）。

【０１０１】実行可否判定管理部１２９では実行可否判
定基準設定要求に応じ、実行可否判定基準９００を管理
方法に応じ変更する。実行可否判定基準がＤＢＭＳで管
理されている場合、実行可否判定基準は要求に応じた問
合せに変換され、実行可否判定基準を管理しているＤＢ
ＭＳに発行される。またメモリ上で管理されている場合
には、実行可否判定管理部１２９が直接実行可否判定基
準９００を書きかえる。

【０１０２】以上が実行可否判定基準設定の流れであ
る。

【０１０３】

【発明の効果】本発明によれば、以下の効果がある。

【０１０４】（１）実行時間予測部１２３とＤＢＭＳ性
能情報７００と実行可否判定部１２４とにより、問合せ
実行時間を予測して実行可否を判定でき、長時間実行問
合せの実行を抑止できる。

【０１０５】（２）実行時間予測修正部１２６と経過情
報１１００と実行可否判定部１２７によって、実行時間
予測の誤差で実行されてしまっている長時間実行問合せ
の実行を抑止できる。

【０１０６】（３）実行可否判定基準９００をＤＢＭＳ
ごとに設定可能とすることにより、ＤＢＭＳの問合せ処
理を妨げるデータベースハブから発行される問合せをデ
ータベースハブで抑止できる。

【０１０７】（４）実行プラン修正部１２２によって、
データベースハブで正確な実行プランを取得できるよう
になる。

【０１０８】以上の効果により、分析系業務におけるデ
ータベースハブおよびＤＢＭＳのスループットを向上で
き、効率よい運営が可能となる。

【図面の簡単な説明】

【図１】第１の実施例の全体構成を示すブロック図。

【図２】実行プラン修正処理の流れ図。

【図３】予測実行プランの一例を示す図。

【図４】取得実行プランの一例を示す図。

【図５】修正後の予測実行プランを示す図。

【図６】実行時間予測処理の流れ図。

【図７】ＤＢＭＳ性能情報の構成図。

【図８】実行可否判定処理の流れ図。

【図９】実行可否判定基準の構成図。

【図１０】実行時間予測修正及び実行可否判定処理の流
れ図。

【図１１】経過情報の構成図。

【符号の説明】

１００：データ処理システム１０１、１０１’、…：クライアントコンピュータ１０２：管理用コンピュータ１０３：クライアント側ネットワーク、１０４：サーバ側ネットワーク１０５、１０５’…：ＤＢサーバ１０６、１０６、１０６’…：二次記憶装置１１０、１１０’…：クライアントアプリケーション１１１：管理用アプリケーション１１２、１１２’…：ＤＢＭＳ、１２０：入出力処理部１２１：問合せ解析・最適化部、１２２：実行プラン修
正部１２３：実行時間予測部、１２４：実行可否判定部１２５：実行制御部、１２６：実行時間予測修正部１２７：実行可否判定部、１２８：ＤＢＭＳ情報取得部１２９：実行可否判定管理部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者西澤格東京都国分寺市東恋ケ窪一丁目280番地株式会社日立製作所中央研究所内 (72)発明者佐川暢俊東京都国分寺市東恋ケ窪一丁目280番地株式会社日立製作所中央研究所内Ｆターム(参考） 5B075 KK07 ND34 QR00 QS20 5B082 GA08 GC04

Claims

【特許請求の範囲】

【請求項１】データ処理を行う第１のプログラムと、ア
プリケーションプログラムに相当する１つ以上の第２の
プログラムと、データベース管理を行う１つ以上の第３
のプログラムとが、１つのコンピュータ上、またはネッ
トワークで結合された複数のコンピュータ上で動作し、
第３のプログラムが、１つ以上のカラムを持つ１つ以上
のレコードからなる１つ以上の表からなる１つ以上のデ
ータベースを保持し、第１のプログラムが、第２のプロ
グラムから第１の問合せを受けつけ、第１のプログラム
が、第１の問合せから第３のプログラムに発行する問合
せ群と該問合せ群の実行プランを生成し、第１のプログ
ラムが、該実行プランに従い該問合せ群を第３のプログ
ラムに発行し、第１のプログラムが、第３のプログラム
から得た該データベース中のデータを用いて第１の問合
せに対する結果を得る問合せ処理方法であって、実行プ
ランより第１の問合せの実行時間を予測する処理と、予
測された実行時間を用いて第１の問合せの実行可否を判
定する処理とを有することを特徴とする問合せ処理の実
行可否判定方法。
【請求項２】前記予測する処理は、第３のプログラムが
動作している計算機の負荷を用いて実行プランより実行
時間を予測する処理を有する請求項１記載の問合せ処理
の実行可否判定方法。
【請求項３】データ処理を行う第１のプログラムと、ア
プリケーションプログラムに相当する１つ以上の第２の
プログラムと、データベース管理を行う１つ以上の第３
のプログラムとが、１つのコンピュータ上、またはネッ
トワークで結合された複数のコンピュータ上で動作し、
第３のプログラムが、１つ以上のコードを持つ１つ以上
の表を備えた１つ以上のデータベースを保持し、第１の
プログラムが、第２のプログラムから第１の問合せを受
けつけ、第１のプログラムが、第１の問合せから第３の
プログラムに発行する問合せ群と該問合せ群の実行プラ
ンを生成し、第１のプログラムが、該実行プランに従い
該問合せ群を第３のプログラムに発行し、第１のプログ
ラムが、第３のプログラムから得た該データベース中の
データを用いて第１の問合せに対する結果を得る問合せ
処理方法であって、第３のプログラムに発行される問合
せ群中の１つの問合せの実行時間を予測する処理と、予
測された実行時間を用いて第１の問合せの実行可否を判
定する処理とを有することを特徴とする問合せ処理の実
行可否判定方法。
【請求項４】前記判定する処理は、第３のプログラムか
ら問合せ実行に関する情報を得る処理を有する請求項１
又は３記載の問合せ処理の実行可否判定方法。
【請求項５】前記問合せ実行に関する情報を得る処理
は、実行プランを第３のプログラムから得られる問合せ
実行に関する情報を用いて修正する実行プラン修正処理
を有する請求項４記載の問合せ処理の実行可否判定方
法。
【請求項６】データ処理を行う第１のプログラムと、ア
プリケーションプログラムに相当する１つ以上の第２の
プログラムと、データベース管理を行う１つ以上の第３
のプログラムとが、１つのコンピュータ上、またはネッ
トワークで結合された複数のコンピュータ上で動作し、
第３のプログラムが、１つ以上のカラムを持つ１つ以上
のレコードからなる１つ以上の表からなる１つ以上のデ
ータベースを保持し、第１のプログラムが、第２のプロ
グラムから第１の問合せを受けつけ、第１のプログラム
が、第１の問合せから第３のプログラムに発行する問合
せ群と該問合せ群の実行プランを生成し、第１のプログ
ラムが、該実行プランに従い該問合せ群を第３のプログ
ラムに発行し、第１のプログラムが、第３のプログラム
から得た該データベース中のデータを用いて第１の問合
せに対する結果を得る問合せ処理方法であって、問合せ
処理を実行中に経過情報を用い予測された実行時間を修
正する処理と、修正された実行時間を用い問合せ実行継
続の可否を判定する処理とを有することを特徴とする問
合せ処理の実行可否判定方法。
【請求項７】前記第１のプログラムが第３のプログラム
の役割を兼ね、前記コンピュータが、１つ以上の第３の
プログラムの代わりに、１つ以上の第１のデータベース
を備え、前記第１のプログラムが、該問合せに必要なデ
ータを第３のプログラムに代わって、前記第１のデータ
ベースから得る請求項１記載の問合せ処理の実行可否判
定方法。
【請求項８】データ処理を行う第１のプログラムと、ア
プリケーションプログラムに相当する１つ以上の第２の
プログラムと、データベース管理を行う１つ以上の第３
のプログラムとが、１つのコンピュータ上、またはネッ
トワークで結合された複数のコンピュータ上で動作し、
第３のプログラムが、１つ以上のカラムを持つ１つ以上
のレコードからなる１つ以上の表からなる１つ以上のデ
ータベースを保持し、第１のプログラムが、第２のプロ
グラムから第１の問合せを受けつけ、第１のプログラム
が、第１の問合せから第３のプログラムに発行する問合
せ群と該問合せ群の実行プランを生成し、第１のプログ
ラムが、該実行プランに従い該問合せ群を第３のプログ
ラムに発行し、第１のプログラムが、第３のプログラム
から得た該データベース中のデータを用いて第１の問合
せに対する結果を得るコンピュータシステムのデータ処
理システムであって、データ転送量を実行プランより予
測する処理と、予測された該データ転送量を用い問合せ
実行の可否を判定する処理とを有することを特徴とする
問合せ処理の実行可否判定方法。