(57)【要約】【課題】  コンピュータ・リソースを動的に調整するための方法、システム、およびコンピュータ・プログラムを提供することにある。【解決手段】  コンピュータ・リソースの動的調整は、実際に使用されたコンピュータ・リソースのコストを提示するためにも、照会ランタイムの予測に応答して、適宜、行われ、そのコストは消費者の要求と一致する。【選択図】  図２
2007524951.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのプロセッサと、前記プロセッサに結合されたメモリと、前記メモリ内に常駐し、少なくとも１つの事前定義された照会時間境界に関して照会のランタイムを評価し、前記照会時間境界内に照会ランタイムを完了するためにコンピュータ・リソースの適切な量を動的に予測するためにプロセッサによって実行可能なマネージャと、を有するシステム。
【請求項２】
前記動的予測が、前記照会が前記照会時間境界内にランタイム実行を完了できるようにするために、前記マネージャにより前記照会および割り振るべき使用可能コンピュータ・リソースを評価することを含む、請求項１に記載のシステム。
【請求項３】
前記マネージャが、前記照会時間境界内に前記照会ランタイムの完了を可能にするために前記動的予測に基づいて前記適切な量のコンピュータ・リソースの割振り／割振り解除を行う、請求項１に記載のシステム。
【請求項４】
照会が実行される前に、前記マネージャが前記適切な量のコンピュータ・リソースの割振り／割振り解除をさらに行う、請求項３に記載のシステム。
【請求項５】
前記照会時間境界が事前定義された最大照会時間境界を含み、前記照会ランタイムが前記最大照会時間境界を超えた場合に前記照会マネージャが前記照会の実行を停止する、請求項１に記載のシステム。
【請求項６】
前記マネージャが、前記照会時間境界内に照会ランタイムを完了させる際に実際に使用されたコンピュータ・リソースに関するコストを提示する、請求項１に記載のシステム。
【請求項７】
前記マネージャが、前記プロセッサの１つまたは複数のプロセッサ・パーティションによって提供されるコンピュータ・リソースの割振り／割振り解除をさらに行う、請求項１に記載のシステム。
【請求項８】
前記マネージャが、ネットワーク・コンピューティング・グリッドによって提供されるリソースの割振り／割振り解除をさらに行う、請求項１に記載のシステム。
【請求項９】
前記マネージャが、ネットワーク・コンピューティング・グリッドまたは前記プロセッサの１つまたは複数のプロセッサ・パーティションあるいはその両方によって提供されるリソースの割振り／割振り解除をさらに行う、請求項１に記載のシステム。
【請求項１０】
前記コンピュータ・リソースの予測割振りに関するパラメータ値をユーザが確立できるようにするユーザ・インターフェースをさらに有する、請求項１に記載のシステム。
【請求項１１】
前記マネージャが、ユーザ・ポリシーにより事前定義されたレベルの増加分だけ前記割振りリソースを増加する、請求項３に記載のシステム。
【請求項１２】
少なくとも１つのプロセッサと、前記プロセッサに結合されたメモリと、前記メモリ内に常駐するマネージャと、を有するシステム内のコンピュータによって実行される方法であって、
少なくとも１つの事前定義された照会時間境界に関して照会のランタイムを評価するステップと、
前記照会時間境界内に照会ランタイムを完了するためにコンピュータ・リソースの適切な量を動的に予測するステップとを含む、方法。
【請求項１３】
プロセッサを含むコンピュータ・システム内で照会最適化を実現するために、コンピュータによって実行されるプログラムであって、
実行されたときに、少なくとも１つの事前定義された照会時間境界に関して照会のランタイムを評価するステップと、
前記照会時間境界内に照会ランタイムを完了するためにコンピュータ・リソースの適切な量を動的に予測するステップとをコンピュータに実行させるためのプログラム。
【請求項１４】
複数のコンピューティング・リソースからなるグリッドと、前記グリッドのコンピューティング・リソースの使用状況に関して１人または複数の顧客の要求を受信するための前記グリッドの要求マネージャと、前記要求マネージャに結合された顧客の１つまたは複数のコンピュータ・システムであって、１つまたは複数のプロセッサを有するコンピュータ・システムと、前記コンピュータ・システムの少なくとも１つの前記プロセッサに結合されたメモリと、前記メモリ内に常駐し、事前定義された時間照会ランタイム境界に関するデータに関して照会のランタイムを評価し、前記前記照会の実行を完了するために割り振るべきコンピュータ・リソースの適切な量を動的に予測するために前記プロセッサによって実行可能なスケジューリング・マネージャと、を有するネットワーク・システムであって、
前記マネージャが、前記動的予測に基づいて、前記グリッド・コンピューティング・リソースのコンピューティング・リソースについて動的に割振り／割振り解除を行う、ネットワーク・システム。
【請求項１５】
複数のコンピューティング・リソースからなるグリッドと、前記グリッドのコンピューティング・リソースの使用状況に関して１人または複数の顧客の要求を受信するための前記グリッドの要求マネージャとを含むネットワーク・システムで実行される方法であって、
顧客の１つまたは複数のコンピュータ・システムが、前記要求マネージャに結合され、さらに、１つまたは複数のプロセッサと、前記１つまたは複数のプロセッサのうちの少なくとも１つに結合されたメモリと、前記メモリ内に常駐し、前記少なくとも１つのプロセッサによって実行可能なスケジューリング・マネージャとを含み、
少なくとも１つの事前定義された照会時間境界に関するデータに関して照会のランタイムを評価するステップと、
前記照会時間境界内に前記照会の実行を完了するために割り振るべきコンピュータ・リソースの適切な量を動的に予測するステップとを含み、
前記要求マネージャが、前記動的予測に基づいて、前記グリッド・コンピューティング・リソースのコンピューティング・リソースについて動的に割振り／割振り解除を行う、方法。
【請求項１６】
プロセッサ・システム内の照会ジョブに関する料金ベースの処理を実行する方法であって、
料金が、照会プロセスの事前定義されたサービス期間でまたはそれにきわめて接近して照会ジョブの処理を完了するためのユーザ構成パラメータによるコンピュータ・リソースの実際の使用状況に基づくものであり、
前記プロセッサ・システムが、少なくとも１つのプロセッサと、前記少なくとも１つのプロセッサに結合されたメモリと、前記メモリ内の常駐する照会スケジューリング・マネージャとを含み、
前記スケジューリング・マネージャが、一般に前記照会ジョブの前記事前定義されたサービス期間内にモニターすべき複数の時間セグメントのそれぞれ１つで前記照会ジョブの実行の進行状況のモニターを可能にし、一般に前記事前定義されたサービス期間でまたはそれにきわめて接近して前記照会ジョブを完了するために必要なコンピュータ・リソースの量を動的に予測し、必要なコンピュータ・リソースの前記予測量に基づいて前記照会ジョブを処理するためにコンピュータ・リソースを動的に割り振り、さらに前記照会ジョブを処理するための料金を提示するために前記必要なコンピュータ・リソースの実際の使用状況を計量することを実行する、方法。
【請求項１７】
事前定義されたサービス期間中に照会を実行するためにコンピュータ・リソースの料金ベースの動的割振りを行うための方法であって、
１人または複数のユーザのために処理システムを提供し、前記システムが可変コンピュータ・リソースを提供する少なくとも１つのリソースを含むステップと、
一般に前記照会の実行のために割り振られた前記事前定義されたサービス期間内にモニターすべき複数の時間セグメントを確立し、前記時間セグメントのそれぞれで照会部分の実行の進行状況のモニターを可能にするステップと、
前記時間セグメントのそれぞれですでに実行された前記照会の部分の進行状況のモニターに基づいて前記照会が一般に前記事前定義されたサービス期間内に実行されるかどうか、及び前記事前定義されたサービス期間内に前記照会を完了するために必要な前記処理システムのコンピュータ・リソースの量を予測するステップと、
前記照会を処理するための料金を提示するために前記必要なコンピュータ・リソースの実際の使用状況を計量するステップと、を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、コンピュータにおけるデータ処理方法、システム、およびコンピュータ・プログラム（computer program product）に関する。詳細には、本発明は、照会ランタイム（query runtime）が照会管理時間境界内に完了するように、適宜、データベース照会を動的に最適化することに関する。
【０００２】
本発明は、本出願とともに出願され、参照により本明細書に組み込まれ、本明細書の一部になる、以下の同時係属かつ本出願人に譲渡された米国特許出願第１０／７８７７２２号（代理人参照番号ＲＯＣ９２００３００４４ＵＳ１）に関連する。
【背景技術】
【０００３】
ＳＱＬを使用する典型的なデータベース照会では、照会ガバナ（query governor）は、いくつかの機能を実行するメカニズムである。典型的には、照会ガバナは、事前定義された最長時間で、たとえば、すべての接続に関するすべての照会について、または特定の接続に関するすべての照会について、数秒間で、すべての照会を実行できるように構成することができる。特定の照会ガバナ機能の１つは、長期実行照会が始動する前にその照会の実行を阻止（pre-empt）または防止（prevent）することである。この阻止は、照会オプティマイザ（query optimizer）によって行われた照会ランタイムの見積もりが照会ガバナによって設定された事前定義された照会時間境界を超えることになるかどうかの判断に基づくものである。しきい値を超える可能性があるという判断が行われた場合、警告が発せられる可能性があり、照会は実行されない。これは、システム・リソースが不必要に消費されるのを防止するので、有益である。
【０００４】
照会ガバナは上記のように照会を管理するが、さもなければ長期実行の照会が実行を阻止されないように、その照会を事前定義された照会時間境界内に収めるために必要なコンピュータ・リソースの適切な量を動的に予測するための既知の手法はまったく存在しない。さらに、さもなければ長期実行の照会を事前定義された照会時間境界内に収めるために適切な量のコンピュータ・リソースを動的に割り振るための手法であって、その割振りが動的予測に基づいて行われるような手法はまったく知られていない。加えて、割り振られたリソースが、上記のタスクを達成するためにロジカル・パーティション環境またはグリッド環境あるいはその両方から使用可能になるようなシステム内で使用するための手法はまったく知られていない。その上、顧客の構成可能なコストおよびパフォーマンス要求を満足することは言うまでもなく、上記を達成するために実際に使用されたコンピュータ・リソースに基づいてコストまたは料金を顧客に配分するための手法はまったく知られていない。
【特許文献１】米国特許出願第１０／７８７７２２号
【特許文献２】米国特許出願第１０／６５９９７６号
【特許文献３】米国特許出願第１０／６１６６７６号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
したがって、長期実行照会の実行を防止することによりデータを管理し、事前定義された時間境界内に完了するように照会実行を収めるために必要なコンピュータ・リソースの適切な量を動的に予測し、このような動的予測に基づいて事前定義された照会時間境界内に照会実行を完了させるために適切な量のコンピュータ・リソースを動的に割り振り、リソースを配分するためにロジカル・パーティション環境またはグリッド環境あるいはその両方で適用可能であり、実際に使用されたコンピュータ・リソースに基づいてコストを顧客に配分し、それにより、顧客の構成可能な要求が満足される、照会ガバナを提供するための方法、システム、およびコンピュータ・プログラムが必要である。
【０００６】
したがって、このような必要性が満足されない場合、照会ガバナによって照会を実行することの真の可能性は容易に達成されないであろう。
【課題を解決するための手段】
【０００７】
本発明は、さもなければ事前定義された照会時間境界内に完了しないと思われる照会をこのような境界内に完了させるために割り振らなければならないコンピュータ・リソースの適切な量を動的に予測するための方法、システム、およびコンピュータ・プログラムの改良策を提供する。否定的な影響なしにこれらの動的予測により適切なコンピュータ・リソースを動的に割り振るための改良策であって、従来技術の処理装置の欠点の多くを克服する改良策が含まれる。
【０００８】
本発明の諸態様としては、動的に割り振られたコンピュータ・リソースがロジカル・パーティション環境またはグリッド環境あるいはその両方から得られるという利点を備えた方法、システム、およびコンピュータ・プログラムの改良策を含む。
【０００９】
本発明の諸態様としては、実際に使用されたコンピュータ・リソースに基づいてコストを顧客に配分し、それにより、コストおよびパフォーマンスに関する顧客の構成可能な要求が満足されるという利点を備えた方法、システム、およびコンピュータ・プログラムの改良策を含む。
【００１０】
本発明のさらに他の態様は、照会最適化のための信頼でき効率の良い方法を提供することである。
【００１１】
本発明の上記その他の特徴および諸態様は、添付図面に照らし合わせて読まなければならない例示的な諸実施形態に関する以下の詳細な説明から、より完全に理解されるであろう。上記の一般化した説明および以下の詳細な説明はいずれも例示的なものであり、本発明を制限するものではないことを理解されたい。
【発明を実施するための最良の形態】
【００１２】
本発明は、一般に、事前定義された照会時間境界外で完了するものと予測されていたので実行を阻止されていたと思われる照会を事前定義された照会時間境界内に完了するために、適宜、コンピュータ・リソースを動的に予測し割り振るためのシステム、方法、およびコンピュータ・プログラムを対象とする。最適化は、スタンドアロン・コンピュータ・システム、またはグリッド・コンピューティング、またはロジカル・パーティション・プロセッサ環境、あるいはこれらの組み合わせからのコンピュータ・リソースの動的割振りを必要とする可能性がある。このため、システム・ユーザは、不必要なリソースではなく、実際に使用されたコンピュータ・リソースについて公正に課金されることになるであろう。
【００１３】
図１〜図３は、本発明による照会最適化方法を実現するためのデータ処理システム１００の例示的な一実施形態を図示している。図示されている実施形態は、使用可能な多種多様なシステムの一例にすぎない。次に図１を参照すると、本発明が実施されるデータ処理環境１００が示されている。一般に、データ処理環境１００は、プロバイダ・コンピュータ・システム１０２と、１つまたは複数のコンピュータ・システム１１６ｉ〜１１６ｎ（ひとまとめにして１１６）とを含む。プロバイダ・コンピュータ・システム１０２は、システム・ユーザ（クライアント）コンピュータ・システム１１６に対するサーバ・コンピュータとして例示的に実施される。すべてのコンピュータは単一エンティティとして図示されているが、実際には、プロバイダ・コンピュータ・システム１０２およびクライアント・コンピュータ・システム１１６はいずれも、本明細書に記載されたものを含む様々な機能を実行するように構成された複数コンピュータ・システムのネットワークになる可能性がある。さらに、「クライアント」および「サーバ」という用語は本明細書では、制限としてではなく、単に便宜上、使用されているものである。このため、クライアント・コンピュータ・システム１１６は、いくつかの点ではプロバイダ・コンピュータ・システム１０２に対するクライアントになる可能性があるが、１つまたは複数の他のクライアント（図示せず）に対するサーバそのものになる可能性もある。
【００１４】
プロバイダ・コンピュータ・システム１０２およびクライアント・コンピュータ・システム１１６はネットワーク１０６により通信する。プロバイダ・コンピュータ・システム１０２はグリッド・コンピューティング環境１０４へのアクセスを可能にする。グリッド・コンピューティング環境１０４内の様々なリソースへのアクセスは、種々のサービス・プロバイダによって提供される場合もある。グリッド環境１０４は、複数の異なるコンピューティング・リソース１２０ｉ〜１２０ｎ（ひとまとめにして１２０）を含む可能性もある。グリッド・コンピューティング環境１０４は、それぞれの可用性、能力、パフォーマンス、コスト、またはユーザのサービス品質要件、あるいはこれらの組み合わせに応じて、ランタイムに地理的に分散されたリソースの共用、選択、および集約を可能にする並列および分散コンピューティング・システムを含むことができる。グリッド・コンピューティング環境１０４は、多様なハードウェアまたはソフトウェアあるいはその両方のコンピューティング・リソースを含むネットワークにすることができる。これらのリソースは、インターネットなどのネットワーク媒体１０６により多種多様なユーザにとって使用可能かつアクセス可能なものにすることができ、ユーザ間で共用することができる。
【００１５】
例示的な実施形態では、ネットワーク１０６は、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）など、それにより情報を転送することできるいくつかの適当なもののうちのいずれか１つにすることができる。プロバイダ・コンピュータ・システム１０２は、クライアント・コンピュータ・システム１１６上に常駐するブラウザ・プログラムからの要求を処理するためにハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバ１２２とともに構成することができる。ＨＴＴＰサーバ１２２およびブラウザ・プログラムは、ネットワーク１０６を介してネットワーク接続（たとえば、ＴＣＰ／ＩＰ接続）を確立するための便利で周知のソフトウェア・コンポーネントを提供する。
【００１６】
プロバイダ・コンピュータ・システム１０２に戻って参照すると、これは、クライアント・コンピュータ・システム１１６用のグリッド・リソースを要求するマネージャ１０８とともに構成することができる。例示的な一実施形態では、マネージャ１０８は、クライアント・コンピュータ・システム１１６からグリッド環境１０４の適切なリソースへの経路指定要求を管理する。このようなグリッド・コンピューティング・システムは、２００３年９月１１日に出願され、本明細書に組み込まれ、本明細書の一部になる、同時係属かつ本出願人に譲渡された米国特許出願第１０／６５９９７６号（代理人参照番号ＲＯＣ９２００３０２０７ＵＳ１）に記載されている。本発明を実現するために必要と見なされる詳細のみ、本明細書に提示される。
【００１７】
グリッド・リソースに関する要求のいくつかは、固定料金ベースまたはパラメータ値に依存する料金ベースで履行される。たとえば、照会を処理するために必要な時間に依存して料金が課金される。マネージャ１０８は、特定の要求に費やされた時間を追跡し、それに関連するコストを計算することにより、これらの要求の進行状況もモニターする。マネージャ１０８は単一エンティティとして示されているが、プロバイダ・コンピュータ・システム１０２内の種々のソフトウェアまたはハードウェアあるいはその両方のコンポーネントによって実現される種々の機能を表すことができることに留意されたい。価格設定は、たとえば、時間ベースの基準、要求タイプまたはクラス基準、優先順位基準、履歴情報、システム・ユーザ識別基準、およびこれらの組み合わせを含む、任意の種類の価格設定基準に関して決定される。これらの価格設定基準は、ある要求に関するコストを計算するためにマネージャ１０８がアクセス可能な価格設定スケジュールまたはポリシーを定義するために適用される。一実施形態では、価格設定基準は、データベース１１０に保管されたサービス契約１１２に定義される。データベース１１０はリレーショナル・データベースである。データベース１１０は、データ・ファイル１１１とともに使用するために、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ社から市販されているＤＢ２などのデータベース管理システム（ＤＢＭＳ）を使用することができる。データベース１１０は、照会の様々な態様を処理するために使用した対応する量のリソースおよび要した時間とともに、過去に受信され処理された要求のログを含む履歴データ１２４も含むことができる。プロバイダ・コンピュータ・システム１０２の契約上のシステム・ユーザごとにサービス契約が存在する可能性がある。他の実施形態では、サービス・プロバイダとの契約上の取り決めを行っていないシステム・ユーザに関する汎用価格設定スケジュール１１４に価格設定基準を指定することができる。前述のもの（たとえば、要求時間基準、要求タイプまたはクラス基準、優先順位基準、履歴情報、システム・ユーザ識別基準、およびこれらの組み合わせ）を含む、様々な異なる価格設定基準について、異なる汎用価格設定スケジュール１１４が存在する可能性がある。また、履歴情報は、価格設定スケジュールを決定するための基準としても機能することができる。１つまたは複数の価格設定基準の組み合わせを考慮に入れる価格設定スケジュールが存在する可能性がある。履歴情報は、過去にある要求を処理するために要したリソースおよび時間の量に関する情報を含む履歴データ１２４によって提供することができる。履歴データ１２４をサーチして、受信した要求と同様の要求または同じ要求が過去に処理されているかどうかを判断することができる。同様の要求が履歴データ内で見つけられた場合、その要求を処理するために使用したリソースおよび要した時間に関する情報を使用して、異なる価格設定スケジュールを選択することができる。当然のことながら、前述の基準のそれぞれは任意選択のものであり、種々の諸実施形態において価格設定スケジュールを決定する際に使用する場合もあれば使用しない場合もある。
【００１８】
ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ社から市販されているｅＳｅｒｖｅｒ  ｉＳｅｒｉｅｓコンピュータ・システムなどのコンピュータ・システム１１６を例証するために図２を参照する。本発明を実現する際に使用するために他のコンピュータ・システムが構想されており、図示されている実施形態は１つのみを例示するものであることが分かるであろう。コンピュータ・システム１１６は、メイン・メモリ１４０と、大容量ストレージ・インターフェース１５０と、ディスプレイ・インターフェース１６０と、ネットワーク・インターフェース１７０と、複数の入出力スロット１８０とに接続された１つまたは複数のプロセッサ１３０ａ〜１３０ｎ（ひとまとめにして１３０）を含む。システム・バス１２５は、これらのコンポーネントを相互接続する。単一のバスのみが使用されているが、当業者であれば、本発明は複数のバスを使用できることが分かるであろう。それぞれのプロセッサは、１つまたは複数のマイクロプロセッサまたは集積回路あるいはその両方から構築することができる。プロセッサはメイン・メモリ内のプログラム命令を実行する。大容量ストレージ・インターフェース１５０は、直接アクセス・ストレージ・デバイス（ＤＡＳＤ）１５５などの大容量ストレージ・デバイス、たとえば、適切なＣＤ−ＲＷドライブをコンピュータ・システムに接続するために使用される。ディスプレイ・インターフェース１６０は、１つまたは複数のディスプレイ１６５をコンピュータ・システムに直接接続するために使用される。ディスプレイ１６５は、非インテリジェント端末または完全プログラマブル・ワークステーションにすることができる。ネットワーク・インターフェース１７０は、ネットワークを越えて他のコンピュータ・システムまたはワークステーション１７５あるいはその両方をコンピュータ・システム１１６に接続するために使用される。使用されるネットワーク接続技術にかかわらず、他のコンピュータ・システムまたはワークステーションあるいはその両方にいくつのコンピュータ・システムまたはワークステーションあるいはその両方を接続できる場合でも、本発明が適用されることが指摘されている。
【００１９】
メイン・メモリ１４０は、メイン・メモリにアクセスできる任意のプロセッサ１３０または任意のその他のデバイスによって読取りまたは書込みを行うことができるデータを収容している。メイン・メモリ１４０は、オペレーティング・システム１４１を含むことができる。メイン・メモリ１４０は、プロセッサがアクセスし実行できるプログラムおよびデータを保管する。オペレーティング・システム１４１は、ＯＳ／４００（商標）、ＡＩＸ（商標）、またはＬｉｎｕｘ（商標）などのマルチタスキング・オペレーティング・システムである。当業者であれば、本発明の精神および範囲が任意の１つのオペレーティング・システムに限定されないことが分かるであろう。オペレーティング・システム１４１は、プロセッサ１３０、メイン・メモリ１４０、大容量ストレージ・インターフェース１５０、ディスプレイ・インターフェース１６０、ネットワーク・インターフェース１７０、および入出力スロット１８０を含むコンピュータ・システムのリソースを管理する。任意の適切なオペレーティング・システムを使用することができる。オペレーティング・システム１４１は、システムを操作するためのアプリケーションを含む。メイン・メモリ１４０には、データベース管理システム（ＤＢＭＳ）１４２が含まれている。データベース管理システム１４２は、構造化照会言語（ＳＱＬ）などの高水準の照会言語を使用して、データベース１１０にデータを保管し、そこからデータを検索し、そこに保管されたデータを変更するためのアプリケーションである。システム・ユーザは、対話式ＳＱＬプログラム１４３内のＳＱＬコマンドを伴う照会を使用することができる。照会は、データを検索し、それを表示するように動作する。また、データベース管理システム１４２には、照会オプティマイザ１４４と、照会ガバナ１４５と、照会スケジューリング・マネージャ１４６も含まれている。照会スケジューリング・マネージャ１４６は、事前定義された時間内に照会を実行させるために必要なコンピュータ・リソースの動的予測を実施するために、後述する方法で照会ガバナ１４５の動作を管理する。照会スケジューリング・マネージャ１４６は、後述する通り、コンピュータ・リソース・アロケータ・アプリケーションまたはモジュール１４７と、実コンピュータ・リソース・メータ・アプリケーションまたはモジュール１４８と、照会履歴メカニズムまたはモジュール１４９も含む。リソース・アロケータ・モジュール１４７は、照会ガバナによって設定された事前定義された照会時間境界内に照会ランタイムを完了するための予測に基づくスタンドアロン環境、ロジカル・パーティション環境、およびグリッド環境からのコンピュータ・リソースを、適宜、配分する。実使用メータ・モジュール１４８は、コンピュータ・リソースの実際の使用状況に基づいてコストを決定する際に使用するために設けられている。新しいジョブに関する履歴テーブルを作成し、既知の照会に関する履歴テーブルを更新する照会履歴モジュール１４９が設けられている。データベース管理システム、ＳＱＬアプリケーション、照会オプティマイザ、照会スケジューリング・マネージャ、照会ガバナ、リソース・アロケータ、実使用メータ、および照会履歴モジュールは、メイン・メモリ内に常駐することができるが、既知の通り、他の場所に常駐することもできる。
【００２０】
照会オプティマイザ１４４は、データベースに適用されたＳＱＬ照会を実行するために効率の良い実行可能照会プランを選択するように動作するアプリケーションである。照会プランは、照会を実行する方法である。照会は、データベースからデータを検索するための１組のコマンドである。たとえば、照会プランは、最短期間で照会が実行されるという要求された結果を生み出すことができる。また、照会オプティマイザ１４４は、照会が実行される実行期間の予測を可能にするとともに、タスクを達成するために使用すべきハードウェア・リソースを示す。照会ガバナ１４５は、完了するために照会が実行されることが予想される時間の長さに関する予測値を照会オプティマイザ１４４から受信するアプリケーションである。照会ガバナ１４５は、照会ガバナの設定時間フレームまたは事前定義された照会時間境界値を超える予測実行長を照会が有する場合、その照会の実行を却下するように動作する。照会ガバナの事前定義された照会時間境界は、最小しきい値および最大時間制限値に設定することができる。最小しきい値時間値（たとえば、秒数）は、照会がそれを超えた場合に照会ガバナによりその照会の実行を防止させるような値になるように決定される。最大時間制限値は、予測照会ランタイムがそれを超えた場合に照会ガバナによりその照会の実行を防止させるような最大時間値（たとえば、秒数）である。照会ガバナ１４５の事前定義された照会時間境界の境界値または時間設定は、システム・ユーザまたはシステム構成によって確立することができる。
【００２１】
本発明により、照会スケジューリング・マネージャ１４６は、照会オプティマイザ１４４からの予測照会実行時間に基づいて照会ガバナによって設定された事前定義された照会時間境界内に予測照会ランタイムを収めるかまたは完了するためにコンピュータ・リソースの適切な量を動的に予測する。この動的予測では、スタンドアロン環境、ロジカル・パーティション環境、またはグリッド・コンピューティング環境、あるいはこれらの組み合わせからの使用可能リソースを考慮に入れる。その後、照会スケジューリング・マネージャ１４６は、照会ガバナによって設定された事前定義された照会時間境界内に照会ランタイムを収めるかまたは完了させるための適切なリソースについて、コンピュータ・リソース・アロケータ・モジュール１４７により、動的に割振り／割振り解除を行う。結果として、その予測実行時間が照会ガバナの事前定義された照会時間境界を超えていると思われるので、さもなければ実行を阻止されると思われる照会が実行できるようになる。また、コストは、タスクを達成するために、顧客の構成可能な要求を満足したことを含め、実際に使用されたコンピュータ・リソースに基づいて顧客に配分することができる。
【００２２】
この時点で、完全機能のコンピュータ・システムに関連して本発明をこれまで説明し、今後も説明し続けるが、当業者であれば、本発明が様々な形のプログラムとして配布可能であり、その配布を実際に実行するために使用されるコンピュータ可読信号伝送媒体の特定のタイプまたはクラスにかかわらず、本発明が等しく適用されることが分かるであろうことは留意すべき重要なことである。また、例示的な諸実施形態は、ロジカル・パーティション・コンピュータ・システムまたはグリッド環境あるいはその両方にも及ぶものである。
【００２３】
これに関して、２００３年７月１０日に出願され、本出願人に譲渡され、同時係属の米国特許出願公報第２００５００１０５０２号、米国特許出願第１０／６１６６７６号（代理人参照番号ＲＯＣ９２００３０１４７ＵＳ１）を参照する。しかし、その諸態様のうち、本発明の理解に関連するもののみを示すことになる。ロジカル・パーティションは、同じ物理コンピュータ・システム上に完全に異なるコンピューティング環境を提供することができる。
【００２４】
図３を参照すると、ロジカル・パーティション・コンピュータ・システム２００の具体的な実現例の１つはＮ個のロジカル・パーティションを含み、各ロジカル・パーティションはそれ自体のそれぞれのオペレーティング・システムを実行する。図３では、ロジカル・パーティション２２５ａ〜２２５ｎ（ひとまとめにして２２５）は、それぞれのオペレーティング・システム２２６ａ〜２２６ｎ（ひとまとめにして２２６）を実行しているものとして示されている。各ロジカル・パーティション内のオペレーティング・システム２２６は、他のパーティションのオペレーティング・システムと同じものである場合もあれば、完全に異なるオペレーティング・システムである場合もある。したがって、あるパーティションがＯＳ／４００オペレーティング・システムを実行し、異なるパーティションがＯＳ／４００の他のインスタンス、おそらく、異なるリリースを実行する場合もある。ハードウェアと互換性のあるものであれば、ロジカル・パーティション内のオペレーティング・システムはＯＳ／４００とは異なるものである可能性もある。ロジカル・パーティション２２５はパーティション・マネージャ２４０によって管理される。適切なパーティション・マネージャ２４０の一例は、インターナショナル・ビジネス・マシーンズ社から市販されている「ハイパーバイザ」として知られている。パーティション・マネージャ２４０は、リソース２５０として図３に示されているリソース２５０を管理する。本出願に使用されている通り、「リソース」は、パーティション・マネージャ２４０によって制御可能な任意のハードウェアまたはソフトウェアあるいはその組み合わせにすることができる。ハードウェア・リソースの例としては、プロセッサ、メモリ、およびハード・ディスク・ドライブを含む。ソフトウェア・リソースの例としては、データベース、内部通信（ロジカルＬＡＮなど）、またはアプリケーション（ワード・プロセッサ、電子メールなど）を含む。パーティション・マネージャ２４０は、ロジカル・パーティション２２５によってどのリソース２５０を割り振ることができるかを制御する。リソースは、パーティション・マネージャ２４０にとって使用可能なものになると、ロジカル・パーティションにまだ割り当てられていない場合に使用可能リソース２６０としてカテゴリ化され、複数のロジカル・パーティションがそのリソースにアクセスできる場合に共用リソース２７０としてカテゴリ化され、あるロジカル・パーティションに排他的に割り当てられている場合に専用リソース２８０ａ〜２８０ｎ（ひとまとめにして２８０）としてカテゴリ化される。
【００２５】
次に図４を参照すると、照会スケジューリング・マネージャ１４６を含むデータ処理システム１００によって実現される本発明の照会管理方法４００の例示的な諸ステップが図示されている。基本的に、照会管理方法４００は、照会ガバナによって決定された通り、それぞれのランタイムが長すぎるものであると予測されるために、さもなければ実行を阻止された照会が実行されるように、適切に、コンピュータ・リソースについて動的に割振り／割振り解除を行う。照会ガバナは、照会のランタイムがそれを超えた場合に照会が実行できなくなるようなしきい値または限界を有するように構成することができる。加えて、照会管理方法４００は、タスクを達成する際に実際に使用されるコンピュータ・リソースに関するコストを配分するように動作する。照会管理方法４００はステップ４０２から開始される。イベントを取得するステップ４０４では、照会は、照会オプティマイザから照会ガバナに転送されたイベントであり、その照会に関する照会ランタイム（たとえば、秒数）を予測する時間値を含む。イベントを取得するステップ４０４から、照会ガバナ判断ステップ４０６があとに続く。
【００２６】
照会ガバナ判断ステップ４０６では、照会オプティマイザによって得られた照会の予測ランタイムが事前定義された照会時間境界内に収まるかどうかという判断が照会ガバナによって行われる。このような事前定義された境界は、たとえば、後で説明するグラフィカル・ユーザ・インターフェース（ＧＵＩ）画面８００（図８）によりユーザによって設定することができる。ステップ４０６の判断がＮｏである場合、すなわち、照会が事前定義された時間境界を超えることになっていない場合、照会管理方法４００はイベントを取得するステップ４０４に戻る。この復帰に次いで、照会管理方法４００は評価すべき他の照会を待つ。代わって、ステップ４０６の判断がＹｅｓである場合、すなわち、照会の予測ランタイムが事前定義された時間境界を超えたことによる照会ガバナ阻止を示す場合、完了するための時間を計算するステップ４０８があとに続く。具体的には、完了するための時間を計算するステップ４０８では、照会をより速く実行させるためにリソースの割振りに基づいて新しい照会実行時間を計算するアルゴリズムが適用される。新しい照会実行時間は、新しい照会実行時間の見積もりが事前定義された時間境界を超えないように選択することができる。したがって、照会は照会ガバナによって阻止されなくなるであろう。
【００２７】
とりわけ、ステップ４０８で実行される新しい見積もり照会実行時間ルーチンまたは方法５００を計算するというタスクを達成するための例示的な諸ステップを例証するために図５を参照する。照会実行時間ルーチン５００は、スケジューリング・モジュール１４６によって実行することができる。このような照会実行時間（たとえば、秒数）の新しい見積もりは、好ましくは、照会実行時間がより高速になり、事前定義された時間境界を超える前に完了することを示すものである。たとえば、事前定義された時間境界は、ユーザがフィールド８１０（図８）に１０秒を入力することによって確立されたように１０秒にすることができる。結果として、照会ガバナは、後者が１０秒またはそれ以下で終了すると見積もられた場合のみ、照会の実行を可能にすることができる。後で説明するように、照会を１０秒未満で終了させるのを支援するために、適切な量のコンピュータ・リソースが他のソース（複数も可）から動的に割り振られる。
【００２８】
照会実行時間ルーチン５００はステップ５０２から開始され、そこで照会のランタイム見積もりがステップ５０４から得られる。ステップ５０６はステップ５０４のあとに続くものである。ステップ５０６では、ヘルプ照会しきい値（Help Query Threshold）フィールド８０２（図８）にシステム・ユーザによって入力された時間値がある場合に、ある照会の見積もり期間がその時間値より大きいかどうかに関する判断が照会ガバナによって行われる。このように実行することにより、ユーザは、照会のために使用可能リソースが探索される事前定義された時間境界を設定することができる。ヘルプ照会しきい値フィールド８０２に入力された事前定義された時間境界値は、フィールド８１０（図８）に入力された照会ガバナ限界時間境界値と一致する必要はない。ユーザがヘルプ照会しきい値フィールド８０２に値を入力すると、そのユーザはヘルプ照会％（Help Query %）フィールド８０４（図８）に非ゼロのパーセンテージ値を入力できることが分かるであろう。
【００２９】
ヘルプ照会％フィールド８０４に入力された値は、照会をより速く実行させるためにユーザが適用することを望むと思われる使用可能リソースのパーセンテージに関するシステム・ユーザによる判断に基づくものである。たとえば、照会がヘルプ照会しきい値フィールド８０２に入力された値（たとえば、５秒）より長くかかると見積もられた場合、ユーザは、照会をより速く実行させるために適切な量で他のパーティションなどからの追加リソース（ＣＰＵ）を提供することを希望する可能性がある。追加される追加ＣＰＵの量は、ヘルプ照会％フィールド８０４に入力されたパーセンテージ値に基づくものになるであろう。たとえば、システム・ユーザは、２０％の追加の使用可能リソースの増加を提供することにより、照会ランタイムを助力することを望む場合もある。さらに、本発明は、フィールド８０９（図８）にユーザによって追加されたように、５０％の改良などの照会実行時間の有意差に到達できる場合のみ、照会ガバナに使用可能リソースからリソースを取得させることを構想するものである。たとえば、ある照会が５秒で実行すると見積もられた場合、システム・ユーザは、５０％の改良を定義するように追加リソースを必要とする可能性がある。その他のパーセンテージ値を入力することもできる。本発明は、パーセンテージ値が実行されているアプリケーション、システム、またはジョブなどの料金またはタイプあるいはその両方に基づくものになる可能性があることを企図している。追加リソースは、照会ガバナによって発生すると予測された追加のボトルネックの予測に基づいて追加することができる。したがって、処理時間の遅延は、ガバナによって見積もられたランタイムの長さを見積もる際の要因になる。
【００３０】
ステップ５０６に戻って参照すると、照会の見積もりランタイムがヘルプ照会しきい値フィールド８０２の値を超えるというＹｅｓの判断が行われた場合、ヘルプ％を設定するステップ５０８があとに続く。ステップ５０８では、パーセンテージ値がユーザによってヘルプ照会％フィールド８０４に入力される。この値は、照会をより速く実行させるための追加リソースを決定するために使用される。具体的には、アルゴリズムでは、好ましくは事前定義された時間境界内に照会ランタイムを取得するために追加すべきリソースの追加の量を定義するためにこの値を使用する。追加すべきリソースは、上記のタスクを達成するために事前定義された量になる。システム自体もこのような値を構成することができる。ステップ５０８に次いで、その照会に関する新しい見積もりランタイムが使用される照会再計算ステップ５１０が実行される。ステップ５１０では、その照会に関する新しい予測ランタイムは、割り振るべきリソースの増加量に基づいて再計算される。その後、照会実行時間ルーチン５００はステップ５１４の終了に移行し、その後、再計算された照会ランタイムは、後述するようにステップ４１０で使用される。
【００３１】
代わって、ステップ５０６でＮｏと判断された場合、ステップ５１２があとに続く。ステップ５１２では、好ましくはＧＵＩ画面８００のフィールド８１０にユーザによって設定された事前定義されたガバナ時間制限より照会ランタイムが大きいかどうかに関する判断が行われる。ステップ５１２でＮｏの判断が行われた場合、ルーチンはステップ５１４で終了し、次にステップ４１０に移行する。代わって、ステップ５１２でＹｅｓである場合、ステップ５１６があとに続く。ステップ５１６では、ガバナ・ヘルプ・フラグが設定されているかどうかに関する判断が行われる。ヘルプ・フラグは、システム・ユーザが予測長期実行照会に関するヘルプの取得に関心がある場合に使用される。Ｎｏである場合、システム・ユーザはガバナ・ヘルプ・フラグを設定しておらず、ルーチン５００はステップ５１４で終了する。Ｙｅｓである場合、システム・ユーザは、図８のＧＵＩ８００のフィールド８０４に適切な値を設定することにより、ガバナ・ヘルプ・フラグを設定しており、コンピュータ・リソースが追加される。ステップ５１８では、アルゴリズムは、事前構成されたユーザ選択パラメータにより、追加すべきリソースの量を確立する。これは、照会ガバナにより照会の実行を防止させるのを回避するように行われる。事前構成された追加すべき量により、照会ランタイムが事前定義された時間境界内に完了することになる。ステップ５２０では、新しい照会ランタイムが再計算される。その後、ルーチン５００はステップ５１４で終了し、その後、再構成されたランタイム見積もりはステップ４１０で使用されることになる。
【００３２】
図４に戻ると、ステップ４１０では、同時係属かつ本出願人に譲渡された米国特許出願第１０／７８７７２２号（代理人参照番号ＲＯＣ９２００３００４４ＵＳ１）に示されているように、新しい見積もり照会ランタイムが適切な量のセグメントに分割されることになる。たとえば、新しい照会時間はいくつかの時間セグメントおよび間隔（たとえば、４セグメント）に分割される。それぞれの間隔は、使用可能コンピュータ・リソースが照会を処理するために十分であるかどうかを判断するために処理される。その後、ステップ４１２で遅れているかという判断が行われる。使用可能リソースの結果、照会実行がスケジュールより遅れることになるかどうかに関する判断が行われる。この判断では、照会の処理中にコンピュータ・システムについて行われる任意のその他の要求（ボトルネックなど）を含む、追加された照会ランタイムを考慮に入れる。ステップ４１２の判断がＹｅｓである場合、プロセスは遅れることになり、ステップ４１４で適切に追加リソースが追加される。代わって、ステップ４１２の判断がＮｏである場合、進みすぎているかという判断ステップ４１６があとに続く。
【００３３】
ステップ４１４で発生する可能性のある適切なリソースを割り振るためのリソース割振り方法６００を例証するために図６を参照する。リソース割振り方法６００の実施中に、事前定義された照会時間境界内に照会を収めるために、適切なリソースが現行プロセスに追加される。ステップ６０２では、リソース追加プロセスが開始される。ステップ６０４では、処理がスタンドアロンまたはパーティション化されていないコンピュータ・システム上で実行されるかどうかに関する判断が行われる。Ｙｅｓである場合、ステップ６０６があとに続く。ステップ６０６では、照会実行時間を削減するために割り振らなければならないリソースの量（たとえば、余分のＣＰＵ、メモリ）を決定するためのアルゴリズムが適用される。好ましくは、照会が実行される前に、その量のリソースが動的に割り振られることが照会ランタイムを加速するために適切である。このため、照会は事前定義された時間境界内に収まることができる。ステップ６０６のこのような割振り指示に次いで、ルーチン６００はステップ６０７で終了し、その後、照会管理方法４００が続行される。代わって、Ｎｏである場合、ステップ６０８が実行される。
【００３４】
ステップ６０８では、システムがＬＰＡＲシステムであるかどうかに関する判断が行われる。ステップ６０８でＹｅｓの判断が行われた場合、リソースを取得できるかという判断ステップ６１２があとに続く。リソースを取得できるかというステップ６１２では、照会を時間境界内に収めさせるために適用しなければならないリソースを供給するために、パーティション（複数も可）のリソースを要求側パーティションにスイッチ可能であるかどうかに関する判断が行われる。リソースを取得できるかというステップ６１２でＹｅｓの判断が行われた場合、要求側パーティションにリソースをスイッチするステップ６１４で適切な量だけリソースをスイッチすることができる。ステップ６１４に次いで、プロセス６００は終了ステップ６０７に移行し、その後、方法４００が再開する。代わって、リソースを取得できるかというステップ６１２でＮｏまたは否定の判断が行われた場合、待機しなければならないかというステップ６１６が実行される。待機しなければならないかというステップ６１６では、他のパーティション（複数も可）からリソースを要求する前に事前定義された期間の間、プロセスが待機しなければならないかどうかに関する判断を行うことができる。待機しなければならないかというステップ６１６で判断がＮｏである場合、終了ステップ６０７があとに続く。その後、照会管理方法４００が再開する。代わって、待機しなければならないかというステップ６１６で判断がＹｅｓである場合、待機ステップ６１８が実行される。待機ステップ６１８では、リソースを取得できるかというステップ６１２に照会リソース要求を送信する前に、所定の長さの時間を経過することができる。待機の期間および待機サイクル数はシステムによって構成することができる。代わって、Ｎｏの判断が決定された場合、ステップ６１０でグリッド計算判断が行われる。グリッド計算判断ステップ６１０では、システムがグリッド・コンピューティング環境にあるかどうかに関する判断が行われる。ステップ６１０の判断がＹｅｓである場合、リソースが使用可能であるかという判断ステップ６２０が実行される。ステップ６２０で判断がＹｅｓである場合、追加リソースを追加するステップ６２２が実行され、ステップ６０７で終了する。リソースが使用可能であるかという判断ステップ６２０の判断がＮｏである場合、待機しなければならないかというステップ６２４が実行される。待機しなければならないかというステップ６２４の判断がＮｏである場合、プロセスはステップ６０７で終了する。待機しなければならないかというステップ６２４の判断がＹｅｓである場合、待機ステップ６２５が実行され、それにより、プロセスは、事前定義された時間の後、リソースが使用可能であるかというステップ６２０に戻る。所定の時間の後、いかなるリソースも使用不能である場合、ステップ６０７があとに続き、照会管理方法４００がステップ４２０で再開する。
【００３５】
留意されている通り、ステップ４１２の判断が否定である場合、進みすぎているかというステップ４１６が実行される。ステップ４１６の判断がＮｏである場合、ステップ４２０があとに続く。ステップ４１６の判断がＹｅｓである場合、リソースを減らすステップ４１８があとに続く。
【００３６】
ステップ４１８で行われる適切なリソースを割り振るためのリソース除去方法７００を例証するために図７を参照する。方法７００の実施中に、事前定義された照会ウィンドウでまたはそれにきわめて接近して照会が終了するために、適切なリソースが現行プロセスに追加される。リソース除去プロセス７００はステップ７０２から開始される。ステップ７０４では、実行中の処理がスタンドアロンまたはパーティション化されていないコンピュータ・システム上で実行されるかどうかに関する判断が行われる。Ｙｅｓである場合、ステップ７０６では、事前定義された照会ウィンドウでまたはそれにきわめて接近してそのランタイムを終了する照会に対して否定的な影響を与えずに割振り解除または除去が可能なコンピュータ・リソースの量を決定するためのアルゴリズムが適用される。具体的には、ステップ７０６では、ＣＰＵなどの適切な量のコンピュータ・リソースを割振り解除できるかどうかが判断される。ステップ７０６からのデータはステップ４２２に転送される。
【００３７】
代わって、ステップ７０４でＮｏと判断された場合、実行中のマシンがロジカル・パーティション・コンピュータ・システムであるかどうかが判断されるステップ７０８を実行することができる。ステップ７０８でＮｏと判断された場合、ステップ７１２を実行することができる。ステップ７０８では、使用されているコンピュータ・システムがロジカル・パーティションであるかどうかの判断が行われる。Ｎｏである場合、ステップ７１２が実行される。代わって、ステップ７０８でＹｅｓと判断された場合、ステップ７１０が実行される。ステップ７１０では、現行照会プロセスを実行しているパーティションから他のパーティションにどの適切なリソースをシフトできるかがパーティション・マネージャ２４０に通知される。このようなシフトは適切な入力に基づくものである。ステップ７０８でＮｏと判断された場合、ステップ７１２が実行される。ステップ７１２では、グリッド・コンピューティング環境１０４がコンピュータ・システム１００に結合されているかどうかに関する判断が行われる。ステップ７１２で判断がＮｏである場合、プロセス７００はステップ７１６に移行する。代わって、判断がＹｅｓである場合、適切な量のリソースに関するデータがグリッド・コントロールに転送されるステップ７１４が実行される。グリッド・コントロールは、コンピュータ・システム１００からグリッド環境１０４にこのようなリソースをシフトバックするために機能する。
【００３８】
方法の継続のために図４に戻って参照する。終了できるかというステップ４２０では、その瞬間に存在する使用可能リソースの場合に、再計算された照会ランタイムが事前定義された期間内に終了できるかどうかに関する判断が行われる。ステップ４２０の判断がＮｏである場合、以前に動的に割り振られることになっていたリソースは、リソースを減らすステップ４２２から回収されるかまたは減らされるはずである。その後、照会は照会ガバナによりステップ４２４で打ち切られる。代わって、特定の時間セグメントまたは間隔に関する終了できるかというステップ４２０の判断がＹｅｓである場合、事前定義された期間の間、待機ステップ４２６が実行される。この待機は、セグメントに分割するステップ４１０で作成されたすべてのセグメントが完了するためのものである。待機ステップ４２６の後、終了したかという判断ステップ４２８が実行される。終了したかという判断ステップ４２８は、新しい照会見積もりが事前定義された照会時間境界またはランタイム内に終了するかどうかに関する判断が行われる。Ｎｏである場合、プロセスの反復のために、プロセスはステップ４１２にループバックする。代わって、終了したかという判断ステップ４２８の判断がＹｅｓである場合、必要ではない追加リソースはリソースを減らすステップ４３０で除去されるかまたは減らされる。リソースを減らすステップ４３０に次いで、照会管理方法４００はステップ４３２で終了する。
【００３９】
図８は、本発明の諸ステップの実行の際に使用されるパラメータをシステム・ユーザが構成できるようにするためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）構成画面８００を図示している。これに関して、ヘルプ照会しきい値を制御するパラメータに関する値が入力されるフィールド８０２が設けられている。ヘルプ照会しきい値は、照会実行によってそれを超えた場合に照会ガバナにより照会の実行を阻止させると思われるしきい値を定義する時間の値（たとえば、秒数）を含むことができる。フィールド８０４は、事前定義された時間境界内に照会を収めるように、照会時間パフォーマンスを改善することになるコンピュータ・リソースの照会実行の際にシステム・ユーザに選択の機会を増加させることに関して有効である。たとえば、これらの値は、コンピュータ・リソースのパーセンテージの増加（１０％、２０％など）に関連する可能性がある。フィールド８０６は、ユーザにガバナ・ヘルパ・フラグを設定させることに関して有用である。フラグがフィールド８０６に設定された場合、照会スケジューリング・マネージャ１４６により、照会ガバナは、事前定義された時間境界内に照会を実行させることに関してリソースを割り振るように動作できるようになる。これは、照会の実行が照会ガバナ時間制限を超えるものと予測された場合に発生することになる。後者に関して、ユーザは、時間単位（たとえば、秒数）の点でフィールド８１０内の照会実行に関する最大ガバナ時間制限を識別することができる。フィールド８０８は、照会のタイムアウトを防止する追加されたコンピュータ・リソースのユーザ入力を可能にする。追加コンピュータ・リソースの量は、事前選択されたパーセンテージの増加（たとえば、１０％、２０％など）など、コンピュータ・リソースの既知のパーセンテージの増加に基づく可能性がある。コンピュータ・リソースを増加することに関してその他のアルゴリズムを使用することもできる。
【００４０】
この時点で、完全機能のコンピュータ・システムに関連して本発明を説明してきたが、当業者であれば、本発明がプログラムとして配布可能であることが分かるであろう。その配布を実際に実行するために使用されるコンピュータ可読信号伝送媒体の特定のタイプにかかわらず、本発明は等しく適用される。
【００４１】
本発明の一態様は、コンピュータ・システムまたは環境とともに使用するためのプログラムとして実現される。そのプログラムのプログラム（複数も可）は、諸実施形態（本明細書に記載した方法を含む）の諸機能を定義し、様々な信号伝送媒体上に収容することができる。例示的な信号伝送媒体としては、（ｉ）書込み不能記憶媒体（たとえば、ＣＤ−ＲＯＭドライブによって読取り可能なＣＤ−ＲＯＭディスクなど、一般にコンピュータ内にある読取り専用メモリ・デバイス）上に永続的に保管された情報、（ｉｉ）書込み可能記憶媒体（たとえば、一般にディスケット・ドライブまたはハード・ディスク・ドライブ内にあるフレキシブル・ディスク）上に保管された変更可能な情報、および（ｉｉｉ）ワイヤレス通信を含み、コンピュータ・ネットワークまたは電話網などを介して通信媒体によってコンピュータに伝達される情報を含むが、これらに限定されない。後者の実施形態は、具体的には、インターネットおよびその他のネットワークからダウンロードされた情報を含む。このような信号伝送媒体は、本発明の諸機能を指図するコンピュータ可読命令を伝えるときに、本発明の諸実施形態を表すものである。
【００４２】
一般に、本発明の諸実施形態を実現するために実行されるルーチンは、オペレーティング・システムの一部であるか、または特定のアプリケーション、コンポーネント、プログラム、モジュール、オブジェクト、または命令シーケンスにすることができる。
【００４３】
一般に、本発明の諸実施形態を実現するために実行されるルーチンは、オペレーティング・システムの一部であるか、または特定のアプリケーション、コンポーネント、プログラム、モジュール、オブジェクト、または命令シーケンスにすることができる。本発明のコンピュータ・プログラムは、典型的には、ネイティブ・コンピュータによって機械可読フォーマットに変換される多数の命令、つまり、実行可能命令からなるものである。また、プログラムは、プログラムにとってローカルに存在するかあるいはメモリ内または記憶装置上で見つかる変数およびデータ構造からなるものである。加えて、以下に記載される様々なプログラムは、それらが本発明の特定の一実施形態で実現される場合の適用例に基づいて識別することができる。しかし、使用される任意の特定のプログラム名称は単に便宜上のものにすぎないことが分かるはずである。したがって、本発明は、このような名称によって識別または暗示あるいはその両方が行われる任意の特定の適用例での使用のみに限定されてはならない。
【００４４】
本明細書に示されている諸実施形態および例は、本発明およびその実用的な適用例を最も良く説明するために提示されたものであり、それにより、当業者が本発明を作成し使用できるようにするものである。しかし、当業者であれば、上記の説明および例が図示および例証のみのために提示されたものであることを認識するであろう。示されている説明は、網羅的になるようにまたは開示された正確な形式に本発明を限定するように意図されているわけではない。図面内に図示されている上記の例示的な諸実施形態を説明する際に、明瞭にするために特定の用語が使用されている。しかし、本発明では、選択された特定の用語に限定されるように意図されているわけではない。それぞれの特定の用語は、同様の目的を達成するために同様に機能するすべての技術的同等物を含むことを理解されたい。特許請求の範囲の精神および範囲から逸脱せずに上記の教示を考慮して多くの変更および変形が可能である。
【図面の簡単な説明】
【００４５】
【図１】本発明により、グリッド環境によるコンピューティング・サービスのプロバイダを有する環境のブロック図である。
【図２】例示的な諸実施形態の１つによるコンピュータ・システムのブロック図である。
【図３】ロジカル・パーティション・コンピュータ・システム内の論理コンポーネントを示すブロック図である。
【図４】本発明の一実施形態により、照会に適用すべきコンピュータ・リソースの動的予測を示す例示的な流れ図である。
【図５】本発明の一実施形態に対するリソースの割振りおよび割振り解除を示す例示的な流れ図である。
【図６】本発明により実行されるプロセスの他の態様を示す例示的な流れ図である。
【図７】本発明により実行されるプロセスの他の態様を示す例示的な流れ図である。
【図８】顧客の要求を満たすためにシステム動作を構成するためのパラメータをユーザが指定できるようにするために使用されるグラフィカル・ユーザ・インターフェースの例証となる図である。
【図１】
2007524951.tif 000003
【図２】
2007524951.tif 000004
【図３】
2007524951.tif 000005
【図４】
2007524951.tif 000006
【図５】
2007524951.tif 000007
【図６】
2007524951.tif 000008
【図７】
2007524951.tif 000009
【図８】
2007524951.tif 000010
【国際調査報告】
2007524951.tif 000011
2007524951.tif 000012
2007524951.tif 000013
2007524951.tif 000014