JP5858371B2 - 解析システム、計算機システム及び解析方法 - Google Patents

Description

本発明は、データベース（ＤＢ）に関わる挙動や性能等の解析を行う技術に関する。

現在、ＤＢを基盤とする多くのアプリケーションが存在しており、ＤＢに関する一連の処理・管理を行うＤＢＭＳは極めて重要なものとなっている。ＤＢＭＳの特徴の一つは、多大な量のデータを扱うことである。そのため、ＤＢＭＳが稼動する計算機システムの多くにおいては、ＤＢＭＳが動作する計算機に大容量のディスクを持つ記憶装置を接続し、記憶装置上にＤＢのデータを記憶するシステム形態が一般的である。

このシステム形態をとっている場合においては、記憶装置のディスク上にデータが記憶されるので、ＤＢに関する処理（ＤＢ処理）を行う際にはディスクに対してアクセスが必然的に発生する。特に、ペタバイトクラスの超大規模ＤＢにおいて、そのＤＢのデータから、ある特定のデータを探し出す処理には膨大な時間を要することになる。そこで、大量のデータの中から特定のデータを探し出す検索処理を高速化する技術として、特許文献１に開示されている技術が知られている。

特許文献１に開示されている技術は、データの読み出しを行う都度、タスクを動的に作成し、タスクを並列に実行することでデータの読み出しを多重化する技術である。当該技術を用いたＤＢＭＳによると、タスクを発生順に実行する従来のＤＢＭＳと比較して、検索性能を飛躍的に向上することができる。

上記ＤＢＭＳは、ＤＢ処理をタスクと呼ばれる処理単位に細分化し、高並列でタスクを実行してＩ／Ｏ（非同期Ｉ／Ｏ）を高多重で発行し、ストレージの性能を最大限に引き出すことで性能を向上する。従って、Ｉ／Ｏを含む処理（タスク）の並列度が性能を出す上で非常に重要となる。例えば、記憶装置の各ＨＤＤにどれだけのＩ／Ｏを同時に発行できるか、すなわち、各ＨＤＤにどれだけのタグ（計算機から記憶装置に発行したＳＣＳＩコマンド）を積めるかということが重要である。

特開２００７−３４４１４号公報

処理（タスク）を高並列に実行し、高多重でＩ／Ｏを発行するＤＢＭＳにおいて、その処理挙動は大変複雑なものとなり、開発時の動作デバッグや、システム運用時の性能デバッグ等のための挙動・性能解析には膨大な時間を要する。

本発明は、上記課題に鑑みなされたものであり、その目的は、タスクを並列に実行するＤＢＭＳの挙動、性能等の解析を容易且つ適切に行うことのできる技術を提供することにある。

タスクを並列に実行するＤＢＭＳにおいては、並列に実行するタスク数である処理並列度が性能を出す上で非常に重要であり、この処理並列度は実行するクエリの内容やハードウェア資源等によって決まるものである。本発明は、上記目的を達成するため、この処理並列度に着目し、上記ＤＢＭＳの挙動や性能解析を容易化するものである。

本発明の一観点に係る解析システムは、ＤＢＭＳのＤＢ処理における計算機システムの挙動を解析する。計算機システムは、記憶装置と計算機とを有する。記憶装置は、ＤＢのデータを記憶する複数の記憶媒体を有する。ＤＢＭＳは、プロセッサコアを有する計算機上で動作し、ＤＢに対するクエリを実行するための複数のデータ読み出し要求を前記記憶装置に送信することが可能である。ＤＢＭＳは、クエリの処理において、オペレーションを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行して良い。具体的には、例えば、ＤＢＭＳは、クエリの処理において、（ａ）オペレーションを実行するためのタスクを生成すること、（ｂ）生成されたタスクを実行すること、（ｃ）前記（ｂ）で実行されたタスクに対応したＮ番目のオペレーションの実行結果に基づき（Ｎ＋１）番目のオペレーションを実行する場合には、当該実行結果に基づくタスクを新たに生成すること（Ｎは１以上の整数）、及び、（ｄ）その新たに生成したタスクについて前記（ｂ）及び前記（ｃ）を行うこと、を行って良い。前記（ｂ）及び（ｄ）において、ＤＢＭＳは、２以上の実行可能なタスクが存在する場合には、それら２以上のタスクのうちの少なくとも２つのタスクを並列に実行するようになっていて良い。タスクの実行には、ＯＳが管理するスレッド（プロセス）を用いて良く、プロセッサコアによって実行される複数のスレッドがタスクを実行し、それぞれのスレッドは複数のタスクを実行して良い。このＤＢＭＳの動作は、前述した特許文献１に開示の技術に従う動作であって良い。

前記解析システムは、情報を記憶可能な記憶資源と、処理を実行するプロセッサとを含む。

前記記憶資源は、前記ＤＢＭＳにおける前記クエリに対する最大のスレッド数を特定可能なスレッド数特定情報と、前記計算機の前記記憶装置とのインタフェースにおける並列実行可能な第１入出力処理数を特定可能な第１処理数特定情報と、前記記憶装置における前記記憶媒体に対する並列実行可能な第２入出力処理数を特定可能な第２処理数特定情報と、各前記記憶媒体が並列実行可能な第３入出力処理数を特定可能な第３処理数特定情報とを記憶する。

前記プロセッサは、前記ＤＢＭＳからクエリに関する索引キーのキー値に対応する選択行数を取得し、前記選択行数と、前記スレッド数特定情報により特定される最大のスレッド数と、前記第１処理数特定情報により特定される第１入出力処理数と、前記第２処理数特定情報により特定される第２入出力処理数と、前記第３処理数特定情報により特定される第３入出力処理数とに基づいて、前記クエリに対応する処理におけるモデルに基き予測した処理並列度である処理並列度モデル予測値を算出する。前記プロセッサは、前記クエリに対応する処理を実際に実行した際の前記記憶媒体に対する入出力イベントに関するイベント情報を前記記憶装置から取得し、前記イベント情報に基づいて、前記クエリに対応する処理を実際に実行した際の処理並列度である処理並列度実測値を算出し、前記処理並列度モデル予測値と、前記処理並列度実測値とに基づいた情報を表示させる制御を行う。

本発明に係る解析システムによると、タスクを並列に実行するＤＢＭＳの挙動、性能等の解析を容易且つ適切に行うことができる。

図１は、実施例１に係る計算機システムの一例の構成図である。 図２Ａは、実施例１に係るスキーマ情報の一例の構成図である。 図２Ｂは、実施例１に係るＤＢファイル情報の一例の構成図である。 図２Ｃは、実施例１に係るＤＢ統計情報の一例の構成図である。 図２Ｄは、実施例１に係るクエリプラン情報の一例の構成図である。 図２Ｅは、実施例１に係るＤＢ処理情報の一例の構成図である。 図３Ａは、実施例１に係るＯＳマッピング情報の一例の構成図である。 図３Ｂは、実施例１に係るＯＳ処理情報の一例の構成図である。 図４Ａは、実施例１に係るＳＴマッピング情報の一例の構成図である。 図４Ｂは、実施例１に係るＳＴ処理情報の一例の構成図である。 図５Ａは、実施例１に係るシステム情報の一例の構成図である。 図５Ｂは、実施例１に係るクエリ（ＳＱＬ）例を示す図である。 図５Ｃは、実施例１に係るクエリプランの一例を示す図である。 図６は、実施例１に係る解析・可視化処理のフローチャートである。 図７は、実施例１に係る処理並列度モデル予測値算出処理の第１のフローチャートである。 図８は、実施例１に係る処理並列度モデル予測値算出処理の第２のフローチャートである。 図９は、実施例１に係る処理並列度実測値算出処理のフローチャートである。 図１０Ａは、実施例１に係る処理並列度モデル予測値グラフの例を示す図である。 図１０Ｂは、実施例１に係る処理並列度モデル予測値及び処理並列度実測値のグラフの第１の例を示す図である。 図１０Ｃは、実施例１に係る処理並列度モデル予測値及び処理並列度実測値のグラフの第２の例を示す図である。 図１１Ａは、実施例１に係る処理並列度モデル予測値のグラフを含む画面表示例を示す図である。 図１１Ｂは、実施例１に係る処理並列度モデル予測値及び処理並列度実測値のグラフを含む画面表示例を示す図である。 図１１Ｃは、実施例１に係る滞留数についてのグラフを含む画面表示例を示す図である。 図１２Ａは、実施例１に係るＨＤＤにおける処理並列度のモデル予測値と実測値との適合・不適合を示すグラフを含む画面表示例を示す図である。 図１２Ｂは、実施例１に係る各ＨＤＤについての処理並列度のモデル予測値と実測値との適合・不適合を示す画面表示例を示す図である。 図１２Ｃは、実施例１に係る処理並列度のモデル予測値と実測値との不適合率が高いＨＤＤを順番に示す画面表示例を示す図である。 図１３Ａは、実施例１に係るＤＢＭＳがアクセスしている表や索引毎のタスク数の統計値のグラフを含む画面表示例を示す図である。 図１３Ｂは、実施例１に係るタスクの状態毎の統計値のグラフを含む第１の画面表示例を示す図である。 図１３Ｃは、実施例１に係る各タスクの状態のグラフを含む第２の画面表示例を示す図である。 図１４は、実施例１に係る処理並列度モデル予測値及び処理並列度実測値のグラフの第３の例を示す図である。 図１５Ａは、実施例１に係る論理ボリューム情報の一例の構成図である。 図１５Ｂは、実施例１に係るボリュームグループ情報の一例の構成図である。 図１６は、実施例２に係るスキーマ群の一例を示す。 図１７Ａは、実施例２に係るクエリの一例を示す。 図１７Ｂは、実施例２に係るクエリプランの一例を示す。 図１７Ｃは、実施例２に係るクエリ結果の一例を示す。 図１８は、実施例２に係る索引ＩＡ及び関係表Ａのデータ構造を示す。 図１９は、実施例２に係る索引ＩＢ及び関係表Ｂのデータ構造を示す。 図２０は、実施例２に係るデータ構造サマリテーブルの一例を示す。 図２１は、従来のＤＢＭＳが逐次的にタスクを実行することを示す 図２２は、従来のＤＢＭＳのＤＢ処理情報の一例を示す。 図２３は、実施例２に係るＤＢＭＳが並列にタスクを実行することを示す。 図２４は、実施例２に係るＤＢＭＳのＤＢ処理情報の一例を示す。 図２５は、実施例２に係る可視化ウィンドウを示す。 図２６は、実施例２に係るタスク挙動可視化ツリーの一例を示す。 図２７は、実施例２に係るデータ構造挙動可視化ツリーの一例を示す。 図２８は、指定時刻が変更された後のタスク挙動可視化ツリーの一例を示す。 図２９は、指定時刻が変更された後のデータ構造可視化ツリーの一例を示す。 図３０は、実施例２に係るタスク挙動可視化ツリーの一変形例としてのラディカルツリーの一例を示す。 図３１は、指定時刻が変更された後のラディカルツリーの一例を示す。

本発明の幾つかの実施例について、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、計算機、ストレージ装置等に含まれるプロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサ或いはそのプロセッサを有する装置（計算機、ストレージ装置等）が行う処理としても良い。また、コントローラは、プロセッサそれ自体であっても良いし、コントローラが行う処理の一部又は全部を行うハードウエア回路を含んでも良い。プログラムは、プログラムソースから各コントローラにインストールされても良い。プログラムソースは、例えば、プログラム配布計算機又は記憶メディアであっても良い。

また、計算機における入出力装置の代替としてシリアルインタフェースやイーサーネットインタフェース（イーサーネットは登録商標）を入出力装置とし、当該インタフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用装置を接続し、表示用情報を表示用装置に送信したり、入力用情報を表示用装置から受信することで、表示用装置で表示を行ったり、入力を受け付けることで入出力装置での入力及び表示を代替してもよい。

以後、計算機システムにおける各種情報を解析する一つ以上の計算機の集合を解析システムと呼ぶことがある。計算機が前記表示用情報を表示する場合は、当該計算機が解析システムである。また、計算機と表示用装置の組み合わせも解析システムである。また、解析処理の高速化や高信頼化のために複数の計算機で解析及び表示の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用装置が行う場合は表示用装置も含め）が解析システムである。

図１は、実施例１に係る計算機システムの一例の構成図である。

計算機システムは、計算機１００と、記憶装置の一例としてのストレージ装置１５０と、解析システムの一例としての計算機１８０とを有する。図１において、計算機１００、及びストレージ装置１５０はそれぞれ１台のみ記載しているが、どちらとも複数台でも良い。計算機１００と、ストレージ装置１５０とは、通信ネットワーク１４０を介して接続される。ストレージ装置１５０は、ＤＢのデータを格納する。計算機１００は、ストレージ装置１５０に格納されているＤＢのデータを管理する。以下、計算機１００を操作する人間のことを、便宜上「システム管理者」と言うが、計算機１００は、システム管理者以外の者によって操作されても良い。

計算機１００、ストレージ装置１５０、及び計算機１８０は、通信ネットワーク１４２を介して接続される。計算機１８０は、計算機１００、ストレージ装置１５０から各種モニタ情報を取得して解析・可視化処理を行う。通信ネットワーク１４０、１４２は、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）等のネットワークであっても良く、また、ファイバチャネル等で構成されるネットワーク（ストレージエリアネットワーク：ＳＡＮ）でも良い。

計算機１００は、例えば一般的な計算機により実現することができる。例えば、計算機１００は、ＣＰＵ（制御プロセッサ）１０４、入出力装置１０６、記憶装置１０８、メモリ１１０、Ｉ／Ｆ（１）１３６、Ｉ／Ｆ（２）１３８を有する。ＣＰＵ１０４、入出力装置１０６、記憶装置１０８、メモリ１１０、Ｉ／Ｆ（１）１３６、及びＩ／Ｆ（２）１３８は、内部バス１０２を介して接続されている。

Ｉ／Ｆ（１）１３６は、通信ネットワーク１４０とのインタフェースであり、Ｉ／Ｆ（２）１３８は、通信ネットワーク１４２とのインタフェースである。Ｉ／Ｆ（１）１３６は、例えば、ＨＢＡ（Host Bus Adapter）である。ＨＢＡは、１以上のポートを有する。入出力装置１０６は、例えば、マウス、キーボード等の入力装置や、液晶ディスプレイの出力装置を含む。記憶装置１０８は、ＣＰＵ１０４によって実行されるプログラム及びＣＰＵ１０４によって必要とされる情報等を記憶する。

メモリ１１０は、ＣＰＵ１０４によって実行されるプログラム及びＣＰＵ１０４によって必要とされる情報等を記憶する。例えば、メモリ１１０は、オペレーティングシステム（以下、ＯＳ）１１２、ＤＢＭＳ１２０を記憶する。ＯＳ１１２は、ＯＳ１１２が管理するデバイスとストレージ装置１５０上の論理的な記憶領域とを対応付けるＯＳマッピング情報１１４と、ＤＢＭＳ１２０がクエリを実行した際のＯＳ内の処理（処理のイベント）に関するＯＳ処理情報１１６とを保持する。また、ＯＳ１１２には、ＯＳマッピング情報１１４、及びＯＳ処理情報１１６を外部に出力するＯＳモニタ情報出力部１１８を構成するためのプログラムが含まれる。ＯＳモニタ情報出力部１１８は、ＣＰＵ１０４が当該プログラムを実行することにより構成される。ＯＳモニタ情報出力部１１８は、モニタ情報を計算機１８０に出力する際に、一旦ファイルに書き出して、その後に計算機１８０に転送しても良いし、計算機１８０に直接転送しても良い。

ＤＢＭＳ１２０は、ＤＢの表や索引等のスキーマ（以下、オブジェクトとも記載する）に関するスキーマ情報１２２、ＤＢのデータが格納されるファイルに関するＤＢファイル情報１２４、ＤＢＭＳ１２０内部の統計に関するＤＢ統計情報１２６、ＤＢＭＳ１２０が実行するクエリに関するクエリプラン情報１２８、ＤＢＭＳ１２０がクエリを実行した際の処理に関するＤＢ処理情報１３０を格納する。また、ＤＢＭＳ１２０には、上記各情報を外部に出力するＤＢモニタ情報出力部１３２を構成するためのプログラムが含まれる。ＤＢモニタ情報出力部１３２は、ＣＰＵ１０４が当該プログラムを実行することにより構成される。ＤＢモニタ情報出力部１３２は、モニタ情報を計算機１８０に出力する際に、一旦ファイルに書き出して、その後に計算機１８０に転送しても良いし、計算機１８０に直接転送しても良い。

ＣＰＵ１０４は、メモリ１１０に格納されたプログラムを実行することにより、各種処理を実行する。例えば、ＣＰＵ１０４は、ＤＢＭＳ１２０を実行することにより、アプリケーション（図示せず）からクエリを受付け、受付けたクエリのクエリプランを作成し、そのクエリプランに従って処理を実行する。また、ＣＰＵ１０４は、この処理の中で、ストレージ装置１５０に格納しているＤＢのデータにアクセスする必要がある場合は、該当データのアクセス要求（Ｉ／Ｏ要求）を、ＯＳ１１２を介してストレージ装置１５０に発行する。

なお、図１においては、ＯＳ１１２及びＤＢＭＳ１２０の両方がメモリ１１０に格納されている例を示しているが、ＯＳ１１２及びＤＢＭＳ１２０の少なくとも一部が記憶装置１０８に格納されていても良い。

ストレージ装置１５０は、コントローラ１５４と、記憶媒体としての複数のディスク（ＨＤＤ）１７８を有する。コントローラ１５４と、複数のディスク１７８とは、内部バス１５２によって接続される。ディスク１７８は、例えばハードディスクドライブ（ＨＤＤ、磁気記憶装置）である。ストレージ装置１５０において、複数のディスク１７８をＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）構成にしても良い。また、ストレージ装置１５０においては、ディスク１７８に加えて、又は、ディスク１７８に代えて、他種の記憶メディアを有する記憶デバイス（例えばフラッシュメモリドライブ）を備えても良い。

コントローラ１５４は、Ｉ／Ｆ（１）１５８、Ｉ／Ｆ（２）１６０、ＣＰＵ（制御プロセッサ）１６２、キャッシュメモリ１６４、及びメモリ１６８を有する。Ｉ／Ｆ（１）１５８、Ｉ／Ｆ（２）１６０、ＣＰＵ１６２、キャッシュメモリ１６４、及びメモリ１６８は、例えば内部バス１５６によって接続される。Ｉ／Ｆ（１）１５８は、通信ネットワーク１４０とのインタフェースであり、Ｉ／Ｆ（２）１６０は、通信ネットワーク１４２とのインタフェースである。キャッシュメモリ１６４は、必要なデータを記憶する。

メモリ１６８は、ＣＰＵ１６２によって実行されるプログラム及びＣＰＵ１６２によって必要とされる情報等を記憶する。メモリ１６８は、ストレージ装置１５０を制御する制御プログラム１７０を記憶する。制御プログラム１７０は、ストレージ装置１５０の論理的な記憶領域（ＬＵ：Logical Unit）と、ディスク１７８が有する物理的な記憶領域とを対応付けるＳＴマッピング情報１７２と、ＤＢＭＳ１２０がクエリを実行した際のストレージ装置１５０内の処理（処理のイベント）に関するＳＴ処理情報１７４を保持する。制御プログラム１７０には、上記各情報を外部に出力するＳＴモニタ情報出力部１７６を構成するためのプログラムが含まれる。ＳＴモニタ情報出力部１７６は、ＣＰＵ１６２が当該プログラムを実行することにより構成される。ＳＴモニタ情報出力部１７６は、ＳＴ処理情報１７４を計算機１８０に送信する際、一旦ファイルに書き出してクエリ終了後にまとめて計算機１８０に送信しても良いし、ＳＴ処理情報１７４にエントリが追加される度に直接計算機１８０に送信しても良い。ＣＰＵ１６２は、メモリ１６８に格納されたプログラムを実行することにより、各種処理を実行する。

計算機１８０は、例えば一般的な計算機により実現することができる。例えば、計算機１８０は、Ｉ／Ｆ１８４、ＣＰＵ（制御プロセッサ）１８６、入出力装置１８８、記憶装置１９０、メモリ１９２を有する。Ｉ／Ｆ１８４、ＣＰＵ１８６、入出力装置１８８、記憶装置１９０、及びメモリ１９２は、内部バス１８２により接続される。ここで、記憶装置１９０及びメモリ１９２が記憶資源の一例である。

Ｉ／Ｆ１８４は、通信ネットワーク１４２とのインタフェースである。入出力装置１８８は、例えば、マウス、キーボード等の入力装置や、ディスプレイ１４４が接続される。ディスプレイ１４４には、各種情報、例えば、解析・可視化プログラム１９５による実行結果が表示される。記憶装置１９０は、ＣＰＵ１８６によって実行されるプログラム及びＣＰＵ１８６によって必要とされる情報等を記憶する。

メモリ１９２は、ＣＰＵ１８６によって実行されるプログラム及びＣＰＵ１８６によって必要とされる情報等を記憶する。メモリ１９２は、当該計算機システムに関する情報であるシステム情報１９６、ＤＢモニタ情報出力部１３２が出力した一連の情報であるＤＢモニタ情報１９７、ＯＳモニタ情報出力部１１８が出力した一連の情報であるＯＳモニタ情報１９８、ＳＴモニタ情報出力部１７６が出力した一連の情報であるＳＴモニタ情報１９９、解析・可視化プログラム１９５を記憶する。システム情報１９６は、パラメータとしてシステム管理者が与えておいても良く、また、ＤＢモニタ情報出力部１３２、ＯＳモニタ情報出力部１１８、ＳＴモニタ情報出力部１７６から自動的に取得するようにしても良い。ＣＰＵ１８６は、メモリ１９２に格納されたプログラムを実行することにより、各種処理を実行する。例えば、ＣＰＵ１８６は、解析・可視化プログラム１９５を実行することにより、メモリ１９２に格納されたシステム情報１９６、各種モニタ情報等を用いて処理を実行する。

なお、図１においては、ＯＳ１９４及び解析・可視化プログラム１９５の両方がメモリ１９２に格納されている例を示しているが、ＯＳ１９４及び解析・可視化プログラム１９５の少なくとも一部が記憶装置１９０に格納されていても良い。

続いて、前述した各種情報について詳細について説明する。

図２Ａは、実施例１に係るＤＢＭＳに格納されるスキーマ情報の一例の構成図である。

スキーマ情報１２２は、ＤＢを構成する表や索引等のオブジェクトに関する情報であり、オブジェクト毎にエントリを有する。各エントリは、オブジェクトを識別するための識別子（Object ID）を登録するフィールド２００、オブジェクトの名前を登録するフィールド２０２、オブジェクトの種別（表、索引）を登録するフィールド２０４、オブジェクトのデータ量を登録するフィールド２０６、オブジェクトの行数（オブジェクトの種別が表の場合のみ）を登録するフィールド２０８、オブジェクトのデータが格納されるＤＢファイルの識別子（File-ID）を登録するフィールド２０９を有する。スキーマ情報１２２は、ＤＢ構築時に作成され、オブジェクトの追加・削除時に更新される。

図２Ｂは、実施例１に係るＤＢＭＳに格納されるＤＢファイル情報の一例の構成図である。

ＤＢファイル情報１２４は、ＤＢのデータが格納されるＤＢファイルに関する情報であり、ＤＢファイル毎にエントリを有する。各エントリは、ＤＢファイルを識別するための識別子（File-ID）を登録するフィールド２１０、ＤＢファイルが作られたＯＳ１１２上のデバイス名を登録するフィールド２１２を有する。ＤＢファイル情報１２４は、ＤＢ構築時に作成され、ＤＢファイルの追加・削除・変更時に更新される。

図２Ｃは、実施例１に係るＤＢＭＳに格納されるＤＢ統計情報の一例の構成図である。

ＤＢ統計情報１２６は、ＤＢＭＳ１２０内部の統計に関する情報であり、シーケンシャルＩ／Ｏ性能を登録するフィールド２２０、ランダム入出力に係る時間を示す入出力時間情報の一例としてのランダムＩ／Ｏ性能を登録するフィールド２２２、索引のキー値に対する選択行数を登録するフィールド２２４、２２６を有する。索引のキー値に対する選択行数２２４は、索引のキー値毎にエントリを有する。ＤＢ統計情報１２６は、ＤＢＭＳ１２０がＤＢ処理を実行した際に適宜更新される。尚、索引のキー値に対する選択行数に関する情報は、ヒストグラム等の情報を基に算出された情報でも良いし、外部から直接与えられたパラメータでも良い。また、シーケンシャルＩ／Ｏ性能２２０、及びランダムＩ／Ｏ性能２２２に登録する値は、ある一定期間の直近の過去のＩ／Ｏ応答時間平均値としても良い。

図２Ｄは、実施例１に係るＤＢＭＳに格納されるクエリプラン情報の一例の構成図である。

クエリプラン情報１２８は、ＤＢＭＳ１２０が実行するクエリに関する情報であり、クエリ内のスキャン毎にエントリを有する。各エントリは、クエリを識別するための識別子（QID）を登録するフィールド２３０、クエリ内の処理ブロック（部分クエリ）を識別するための識別子（SubQID）を登録するフィールド２３２、クエリ内のスキャンを識別するための識別子（ScanID）を登録するフィールド２３４、クエリ内のスキャンの種別を登録するフィールド２３６、当該スキャンでアクセスするオブジェクトを識別する識別子を登録するフィールド２３８、当該スキャンが索引スキャン（Index Scan）の場合に検索条件となる索引キーを格納するフィールド２４０、検索条件となる索引キー値を登録するフィールド２４２を有する。クエリプラン情報１２８は、ＤＢＭＳ１２０がクエリを受付けた後に作成され、当該情報により対象のクエリがどの表・索引を、どのような検索条件（索引キー、キー値）で、どの順番でアクセスするかを特定することができる。

図２Ｅは、実施例１に係るＤＢＭＳに格納されるＤＢ処理情報の一例の構成図である。

ＤＢ処理情報１３０は、ＤＢＭＳ１２０がクエリを実行した際の処理に関する情報であり、処理において特定のイベント（例えば、非同期Ｉ／Ｏ発行イベント、非同期Ｉ／Ｏ刈取りイベント）を実行した際にエントリ（イベント情報）が作られる。各エントリは、エントリ番号を登録するフィールド２５０、イベントを実行した時間のタイムスタンプを登録するフィールド２５２、イベントを実行したスレッドを識別するための識別子（Thread ID）を登録するフィールド２５４、イベント種別を登録するフィールド２５６、イベントを実行したタスク（スレッドにおけるタスク）を識別するための識別子（Task ID）を登録するフィールド２５８、フィールド２５８に登録されている識別子から識別されるタスクの生成元タスク（親タスク）を識別するための識別子（Present Task ID）を登録するフィールド２６０、イベントの実行元となるクエリを識別するための識別子（QID）を登録するフィールド２６２、イベントの実行元となるクエリ内の処理ブロックを識別するための識別子（SubQID）を登録するフィールド２６４、アクセス先のオブジェクトを識別するための識別子（Object ID）を登録するフィールド２６６、アクセス先のＤＢファイルを識別するための識別子（File-ID）を登録するフィールド２６８、アクセスするデータのオフセットを登録するフィールド２７０、アクセスするデータのサイズを登録するフィールド２７２、当該イベントで発行したＩ／Ｏを識別するための識別子（IO-ID）を登録するフィールド２７４を有する。

図３Ａは、実施例１に係るＯＳマッピング情報の一例の構成図である。

ＯＳマッピング情報１１４は、ＯＳ１１２で管理されるデバイスとストレージ装置１５０上の論理的な記憶領域（ＬＵ）とを対応付ける情報であり、デバイス毎にエントリを有する。各エントリは、デバイスを識別するためのデバイス名を登録するフィールド３００、当該デバイスに対応する記憶領域（ＬＵ）を持つストレージ装置１５０を識別するための識別子（ST-ID）を登録するフィールド３０２、当該デバイスに対応する記憶領域（ＬＵ）を識別するための番号（LUN）を登録するフィールド３０４を有する。ＯＳマッピング情報１１４は、システム構築時に作成され、システム構成に変更があった場合に更新される。

図３Ｂは、実施例１に係るＯＳ処理情報の一例の構成図である。

ＯＳ処理情報１１６は、ＤＢＭＳ１２０がクエリを実行した際のＯＳ内の処理に関する情報であり、特定のイベント（例えば、非同期Ｉ／Ｏ受付け、Ｉ／Ｏ要求発行、Ｉ／Ｏ完了受付け等）を実行した際にエントリ（イベント情報）が作られる。各エントリは、エントリ番号を登録するフィールド３１０、イベントを実行した時間のタイムスタンプを登録するフィールド３１２、イベント種別を登録するフィールド３１４、当該イベントに対応するＩ／Ｏを識別するための識別子（IO-ID）を登録するフィールド３１６、アクセス先のストレージ装置１５０を識別するための識別子（ST-ID）を登録するフィールド３１８、アクセス先の論理的な記憶領域（ＬＵ）を識別するための番号（LUN）を登録するフィールド３２０、アクセスするデータの論理的なアドレス（LBA）を登録するフィールド３２２、アクセスするデータのサイズを登録するフィールド３２４を有する。

図４Ａは、実施例１に係るＳＴマッピング情報の一例の構成図である。

ＳＴマッピング情報１７２は、ストレージ装置１５０で管理される論理的な記憶領域（ＬＵ）と、ディスク１７８が有する物理的な記憶領域とを対応付ける情報であり、ＬＵ毎にエントリを有する。各エントリは、当該ＬＵを持つストレージ装置１５０を識別するための識別子（ST-ID）を登録するフィールド４００、当該ＬＵを識別するための番号（LUN）を登録するフィールド４０２、当該ＬＵを構成するディスク１７８の台数を登録するフィールド４０４、当該ＬＵを構成するディスク１７８を識別するための識別子（HDD-ID）を登録するフィールド４０６を有する。ＳＴマッピング情報１７２は、システム構築時に作成され、システム構成に変更があった場合に更新される。尚、一つのＬＵを複数のディスク１７８で構成する場合、フィールド４０６が同一エントリに複数作られる。

図４Ｂは、実施例１に係るＳＴ処理情報の一例の構成図である。

ＳＴ処理情報１７４は、ＤＢＭＳ１２０がクエリを実行した際のストレージ装置１５０内の処理に関する情報であり、特定のイベント（例えば、Ｉ／Ｏ要求受付け、ディスクＩ／Ｏ開始、ディスクＩ／Ｏ終了、Ｉ／Ｏ応答発行等）を実行した際にエントリ（イベント情報）が作られる。各エントリは、エントリ番号を登録するフィールド４１０、イベントを実行した時間のタイムスタンプを登録するフィールド４１２、イベント種別を登録するフィールド４１４、当該イベントに対応するＩ／Ｏを識別するための識別子（IO-ID）を登録するフィールド４１６、Ｉ／Ｏ要求のサイズを登録するフィールド４１８、アクセス先の論理的な記憶領域（ＬＵ）を識別するための番号（LUN）を登録するフィールド４２０、アクセスするデータの論理的なアドレス（LBA）を登録するフィールド４２２、アクセスするデータが格納されているディスク１７８を識別するための識別子（HDD-ID）を登録するフィールド４２４、アクセスするデータの物理的なアドレス（PBA）を登録するフィールド４２６を有する。

図５Ａは、実施例１に係るシステム情報の一例の構成図である。

システム情報１９６は、当該計算機システムに関する情報であり、ＤＢ処理を実行するカーネルスレッド数を登録するフィールド５００、ＤＢ処理を実行する１カーネルスレッド当りのタスク数を登録するフィールド５０２、ＨＢＡ（Host Bus Adapter）のポート数を登録するフィールド５０４、ＨＢＡ１ポート当りの同時Ｉ／Ｏ処理数を登録するフィールド５０６、通信ネットワーク１４０の帯域を登録するフィールド５０８、ストレージ装置１５０のコントローラ１５４の数を登録するフィールド５１０、１ストレージコントローラ当りの同時Ｉ／Ｏ処理数を登録するフィールド５１２、ディスク台数を登録するフィールド５１４、１ディスク当りの同時Ｉ／Ｏ処理数（タグ数）を登録するフィールド５１６を有する。ここで、カーネルスレッド数及び１カーネルスレッド当りのタスク数が、スレッド数特定情報に該当し、ＨＢＡのポート数及びＨＢＡ１ポート当りの同時Ｉ／Ｏ処理数が、第１処理数特定情報に該当し、コントローラ１５４の数及び１ストレージコントローラ当りの同時Ｉ／Ｏ処理数が、第２処理数特定情報に該当し１ディスク当りの同時Ｉ／Ｏ処理数（タグ数）が、第３処理数特定情報に該当する。

次に、解析・可視化プログラム１９５が実行する処理について説明するにあたって、ＤＢＭＳ１２０に対してのクエリ（ＳＱＬ）の一例及びそのクエリについてのクエリプランについて説明する。

図５Ｂは、実施例１に係るクエリ（ＳＱＬ）例を示す図である。図５Ｃは、実施例１に係るクエリプランの一例を示す図である。

図５Ｂに示すクエリ５２０は、図５Ｃに示すように、“Select MAX(C2) From T2 Where C3=10”の部分がまず副クエリ５３４（処理ブロックＢ：部分クエリ）として実行され、その後、副クエリ５３４の実行結果を用いて、“Select C1 FromT1 Where C2=（副クエリ結果）”の部分の主クエリ５３２（処理ブロックＡ：部分クエリ）が索引を用いた結合処理方法によって実行されることになる。

クエリ５２０に対応する処理は、副クエリ５３４に対応する処理ブロックＢと、主クエリ５３２に対応する処理ブロックＡとの２つの処理ブロックで構成されることがわかる。なお、ＤＢＭＳ１２０を実行するＣＰＵ１０４は、クエリに基づいて、クエリプランを特定し、当該クエリプランをクエリプラン情報１２８に登録する。

次に、解析・可視化プログラム１９５を実行する計算機１８０による処理を説明する。なお、当該処理の実行前においては、計算機システム構築、及びＤＢ構築が済んでおり、且つ計算機１００のＤＢＭＳ１２０がクエリ５２０を受付け、各種処理を実行したものとする。したがって、スキーマ情報１２２、ＤＢファイル情報１２４、ＤＢ統計情報１２６、ＤＢ処理情報１２８、ＯＳマッピング情報１１４、ＯＳ処理情報１１６、ＳＴマッピング情報１７２、ＳＴ処理情報１７４、システム情報１９６は、作成されており、その際の情報が反映されている。

図６は、実施例１に係る解析・可視化処理のフローチャートである。なお、解析・可視化処理は、ＣＰＵ１８６が解析・可視化プログラム１９５を実行することにより実現される処理である。また、並列に実行するタスク数である処理並列度は実行するクエリの内容やハードウェア資源等によって決まるものであり、実施例１では、最終的な処理並列度として、ストレージ装置１５０のディスク１７８のタグ数（以下、ＨＤＤタグ数）を想定している。

システム管理者により、解析・可視化プログラム１９５の起動指示がされると、計算機１８０が、解析・可視化処理を開始する（ステップ６００）。尚、以下のステップの処理は、解析・可視化プログラム１９５が起動されると自動的に開始されるようにしても良いし、システム管理者の指示によって開始されるようにしても良い。

解析・可視化プログラム１９５は、ＤＢモニタ情報出力部１３２が出力したモニタ情報（スキーマ情報１２２、ＤＢファイル情報１２４、ＤＢ統計情報１２６、クエリプラン情報１２８、及びＤＢ処理情報１３０）をＤＢモニタ情報１９７として取得し、メモリ１９２上に読込む（ステップ６０２）。次に、ＯＳモニタ情報出力部１１８が出力したモニタ情報（ＯＳマッピング情報１１４、ＯＳ処理情報１１６）をＯＳモニタ情報１９８として取得し、メモリ１９２上に読込む（ステップ６０４）。次に、ＳＴモニタ情報出力部１７６が出力したモニタ情報（ＳＴマッピング情報１７２、ＳＴ処理情報１７４）をＳＴモニタ情報１９９として取得し、メモリ１９２上に読込む（ステップ６０６）。次に、システム情報１９６を記憶装置１９０からメモリ１９２上に読込む（ステップ６０８）。

続いて、解析・可視化プログラム１９５は、処理並列度モデル予測値算出処理７００を実行し、当該計算機システムでクエリ５２０を実行した場合に、モデルに基づいて予測された処理挙動を示す数値として、処理並列度（ＨＤＤタグ数）モデル予測値を算出する（ステップ６１０）。次に、処理並列度実測値算出処理８００を実行し、当該計算機システムでクエリ５２０を実行した場合の実際の処理挙動を示す値として、処理並列度（ＨＤＤタグ数）実測値を算出する（ステップ６１２）。

続いて、解析・可視化プログラム１９５は、ステップ６１０で算出した処理並列度モデル予測値と、ステップ６１２で算出した処理並列度実測値とに基づいたグラフをディスプレイ１４４上に表示させ（ステップ６１４）、システム管理者の指示により処理を終了する（ステップ６１６）。実施例１では、ディスプレイ１４４上に、縦軸に処理並列度モデル予測値及び処理並列度実測値を取り、横軸に時間を取ったグラフを表示する。このグラフによると、処理並列度モデル予測値と、処理並列度実測値とを容易に比較することができる。詳細なグラフについては、後述する。

図７は、実施例１に係る処理並列度モデル予測値算出処理の第１のフローチャートである。図８は、実施例１に係る処理並列度モデル予測値算出処理の第２のフローチャートである。

解析・可視プログラム１９５は、ＤＢモニタ情報１９７内のクエリプラン情報１２８を参照し、対象とするクエリの処理ブロック数を特定する（ステップ７０２）。例えば、クエリ５２０の場合は、処理ブロック数は２となる。次に、特定した各処理ブロックに関して、ステップ７０８からステップ７４２を実行する。全ての処理ブロックに対して処理並列度モデル予測値の算出を行ったか判定し（ステップ７０４）、全ての処理ブロックの処理並列度モデル予測値の算出を行った場合（ステップ７０４でＹｅｓ）は、処理並列度モデル予測値算出処理を終了する（ステップ７０６）。

解析・可視化プログラム１９５は、ＤＢモニタ情報１９７内のクエリプラン情報１２８を参照して、当該処理ブロックのスキャンタイプを特定し（ステップ７０８）、スキャンタイプが表スキャン（Table Scan）か索引スキャン（Index Scan）かを判定する（ステップ７１０）。尚、表スキャンは、表だけを参照して条件に合致するレコードを取得するスキャンであり、索引スキャンは、索引を使って条件に合致する表のレコードを取得するスキャンである。判定の結果、当該処理ブロックのスキャンタイプが表スキャンの場合（ステップ７１０でＮｏ）は、処理並列度に１を設定する（ステップ７１２）。表スキャンも並列に処理することは可能であるが、その並列度は本発明が想定している処理並列度よりも遥かに小さいためここでは１としている。一方、当該処理ブロックのスキャンタイプが索引スキャンの場合（ステップ７１０でＹｅｓ）は、ＤＢモニタ情報１９７内のＤＢ統計情報１２６を参照して、当該処理ブロックのスキャンの索引キーとキー値に対応するキー値選択行数を取得し、取得した値を処理並列度に設定する（ステップ７１４）。

例えば、クエリ５２０の処理ブロックＢを対象にしている場合には、処理ブロックＢのスキャンタイプは索引スキャン、索引キーはＩ２．Ｃ３、キー値はＣ３＝１０であることがクエリプラン情報１２８から特定でき、Ｉ２．Ｃ３＝１０のキー値選択行数が１００，０００であることがＤＢ統計情報１２６から特定することができる。従って、ステップ７１４終了時点の処理ブロックＢの処理並列度は、１００，０００と設定される。また、クエリ５２０の処理ブロックＡを対象にしている場合には、処理ブロックＡのスキャンタイプは索引スキャン、索引キーはＩ１．Ｃ２、キー値はＣ２＝Ｍａｘ(Ｃ２)であることがクエリプラン情報１２８から特定でき、Ｉ１．Ｃ２＝Ｍａｘ（Ｃ２）のキー値選択行数が１００であることがＤＢ統計情報１２６から特定することができる。従って、ステップ７１４終了時点の処理ブロックＡの処理並列度は、１００と設定される。尚、今回の例では、１処理ブロック＝１スキャンとなっているが、処理並列度が変わらないのであれば、１処理ブロックに複数のスキャンが入っていても良い。

続いて、解析・可視化プログラム１９５は、システム情報１９６を参照し、カーネルスレッド数と、１カーネルスレッド当りのタスク数とを乗じて、ＤＢＭＳ１２０の最大並列度を算出する（ステップ７１６）。図５Ａに示すシステム情報１９６の場合には、カーネルスレッド数が６４であり、１カーネルスレッド当りのタスク数が１，０００であるので、ＤＢＭＳ１２０の最大並列度は６４，０００となる。尚、ここで算出している最大並列度は、１タスク当りに同時に発行できるＩ／Ｏが１であることを前提としている。１タスク当り複数のＩ／Ｏを同時に発行する場合では、カーネルスレッド数と１カーネルスレッド数当りのタスク数と１タスク当りに発行する同時Ｉ／Ｏ数を乗じた結果が最大並列度となる。

次に、解析・可視化プログラム１９５は、この時点の処理並列度と、ステップ７１６で算出したＤＢＭＳ１２０の最大並列度を比較し（ステップ７１８）、ＤＢＭＳ１２０の最大並列度の方が低い場合（ステップ７１８でＹｅｓ）は、処理並列度にＤＢＭＳ１２０の最大並列度を設定する（ステップ７２０）。例えば、クエリ５２０の処理ブロックＢが対象の場合には、この時点の処理並列度（ステップ７１４で設定した処理ブロックＢの処理並列度）は１００，０００であり、ステップ７１６で算出したＤＢＭＳ１２０の最大並列度は６４，０００であり、ＤＢＭＳ１２０の最大並列度の方が小さいため、処理ブロックＢの処理並列度に６４，０００を設定する。また、クエリ５２０の処理ブロックＡが対象の場合には、この時点の処理並列度（ステップ７１４で設定した処理並列度）は１００であり、ＤＢＭＳ１２０の最大並列度６４，０００の方が大きいため、処理ブロックＡの処理並列度は１００のままとなる。尚、この時点の処理ブロック毎の処理並列度は、ＤＢＭＳ１２０の最大スレッド数（カーネルスレッド数と１カーネルスレッド当りのタスク数を乗じた値）に、外部から与えられた定数を乗じた結果としても良い。

続いて、解析・可視化プログラム１９５は、システム情報１９６を参照し、ＨＢＡポート数とＨＢＡ１ポート数当りの同時Ｉ／Ｏ処理数とを乗じて、ＨＢＡ同時Ｉ／Ｏ処理数（第１入出力処理数）を算出する（ステップ７２２）。図５Ａに示すシステム情報１９６の場合には、ＨＢＡポート数が６であり、ＨＢＡ１ポート当りの同時Ｉ／Ｏ処理数が２５６であるので、ＨＢＡ同時Ｉ／Ｏ処理数は１，５３６となる。

次に、この時点の処理並列度と、ステップ７２２で算出したＨＢＡ同時Ｉ／Ｏ処理数とを比較し（ステップ７２４）、ＨＢＡ同時Ｉ／Ｏ処理数の方が低い場合（ステップ７２４でＹｅｓ）は、処理並列度にＨＢＡ同時Ｉ／Ｏ処理数を設定する（ステップ７２６）。クエリ５２０の処理ブロックＢを対象としている場合には、この時点の処理ブロックＢの処理並列度は６４，０００であり、ステップ７２２で算出したＨＢＡ同時Ｉ／Ｏ処理数は１，５３６であり、ＨＢＡ同時Ｉ／Ｏ処理数の方が小さいため、処理ブロックＢの処理並列度に１，５３６を設定する。また、クエリ５２０の処理ブロックＡを対象としている場合には、この時点の処理並列度は１００であり、ＨＢＡ同時Ｉ／Ｏ処理数１，５３６の方が大きいため、処理ブロックＡの処理並列度は１００のままとなる。

続いて、解析・可視化プログラム１９５は、システム情報１９６を参照し、ストレージ装置１５０のコントローラ数と１コントローラ当りの同時Ｉ／Ｏ処理数とを乗じて、コントローラ同時Ｉ／Ｏ処理数（第２入出力処理数）を算出する（ステップ７２８）。図５Ａに示すシステム情報１９６の場合には、ストレージ装置１５０のコントローラ数が２であり、１コントローラ当りの同時Ｉ／Ｏ処理数が１，０００であるので、コントローラ同時Ｉ／Ｏ処理数は２，０００となる。

次に、解析・可視化プログラム１９５は、この時点の処理並列度と、ステップ７２８で算出したコントローラ同時Ｉ／Ｏ処理数とを比較し（ステップ７３０）、コントローラ同時Ｉ／Ｏ処理数の方が低い場合（ステップ７３０でＹｅｓ）は、処理並列度にコントローラ同時Ｉ／Ｏ処理数を設定する（ステップ７３２）。一方、コントローラ同時Ｉ／Ｏ処理数が同じか又は高い場合（ステップ７３０でＮｏ）は、処理並列度は、そのままとなる。

例えば、クエリ５２０の処理ブロックＢが対象の場合には、この時点の処理ブロックＢの処理並列度は１，５３６であり、ステップ７２８で算出したコントローラ同時Ｉ／Ｏ処理数は２，０００であり、コントローラ同時Ｉ／Ｏ処理数の方が大きいため、処理ブロックＢの処理並列度は１，５３６のままとなる。また、クエリ５２０の処理ブロックＡが対象の場合には、この時点の処理並列度は１００であり、コントローラ同時Ｉ／Ｏ処理数２，０００の方が大きいため、処理ブロックＡの並列度は１００のままとなる。

続いて、解析・可視化プログラム１９５は、ＤＢモニタ情報１９７のスキーマ情報１２２及びＤＢファイル情報１２４、ＯＳモニタ情報１９８のＯＳマッピング情報１１４、ＳＴモニタ情報１９９のＳＴマッピング情報１７２を参照して、当該処理ブロックがアクセスするオブジェクトのデータを格納しているディスク１７８のＨＤＤ台数を割出し（ステップ７３４）、この時点の処理並列度を、割り出したＨＤＤ台数で割って、１ＨＤＤ当たりの処理並列度を算出する（ステップ７３６）。クエリ５２０の処理ブロックＢを対象としている場合には、処理ブロックＢでアクセスするオブジェクトは“Ｔ２”（クエリプラン情報１２８のアクセス先Object ID２３８）であり、“Ｔ２”が格納されているＤＢファイルは“ＦＩＬＥ２”（スキーマ情報１２２のＦｉｌｅ−ＩＤ２０９）であり、“ＦＩＬＥ２”に対応するデバイスは“Ｓｄｅ２”（ＤＢファイル情報１２４のデバイス名２１２）であり、“Ｓｄｅ２”のデバイスに対応する論理的な記憶領域は“ＳＴ１”の“Ｌｕｎ２”（ＯＳマッピング情報１１４のＳＴ−ＩＤ３０２及びＬＵＮ３０４）であり、“ＳＴ１”の“Ｌｕｎ２”を構成するＨＤＤ台数は１０台（ＳＴマッピング情報１７２のＨＤＤ台数４０４）であり、この時点の処理ブロックＢの処理並列度は１，５３６であり、処理ブロックＢの１ＨＤＤ当たりの処理並列度は１，５３６／１０≒１５３となる。

また、クエリ５２０の処理ブロックＡを対象としている場合には、アクセスするオブジェクトは“Ｔ１”（クエリプラン情報１２８のアクセス先Object ID２３８）であり、“Ｔ１”が格納されているＤＢファイルは“ＦＩＬＥ１”（スキーマ情報１２２のＦｉｌｅ−ＩＤ２０９）であり、“ＦＩＬＥ１”に対応するデバイスは“Ｓｄｄ１”（ＤＢファイル情報１２４のデバイス名２１２）であり、“Ｓｄｄ１”のデバイスに対応する論理的な記憶領域は“ＳＴ１”の“Ｌｕｎ１”（ＯＳマッピング情報１１４のＳＴ−ＩＤ３０２及びＬＵＮ３０４）であり、“Ｌｕｎ１”を構成するＨＤＤ台数は１０（ＳＴマッピング情報１７２のＨＤＤ台数４０４）であり、この時点の処理ブロックＡの処理並列度は１００であり、処理ブロックＡの１ＨＤＤ当たりの処理並列度は１０となる。

次に、解析・可視化プログラム１９５は、システム情報１９６を参照して１ＨＤＤ当りの同時Ｉ／Ｏ処理数（第３入出力処理数）を取得し（図５Ａでは、３０）、ステップ７３６で算出した１ＨＤＤ当りの処理並列度と比較し（ステップ７３８）、１ＨＤＤ当りの同時Ｉ／Ｏ処理数の方が低い場合には（ステップ７３８でＹｅｓ）、１ＨＤＤ当りの処理並列度に１ＨＤＤ当りの同時Ｉ／Ｏ処理数を設定する（ステップ７４０）。一方、１ＨＤＤ当りの同時Ｉ／Ｏ処理数の方が高い場合（ステップ７３８でＮｏ）は、１ＨＤＤ当りの処理並列度はそのままとなる。続いて、解析・可視化プログラム１９５は、求めた１ＨＤＤ当りの処理並列度に、ステップ７３４で求めたＨＤＤ台数を乗じて、システム全体の処理並列度モデル予測値を算出する（ステップ７４２）。以降、図面も含め処理並列度モデル予測値と記載した箇所は、このシステム全体の処理並列度モデル予測値のことを意味する。

例えば、クエリ５２０の処理ブロックＢが対象の場合には、ステップ７３６で算出した１ＨＤＤ当りの処理並列度は１５３であり、１ＨＤＤ当りの同時Ｉ／Ｏ処理数は３０であり、１ＨＤＤ当りの同時Ｉ／Ｏ処理数の方が小さいため、処理ブロックＢの１ＨＤＤ当りの処理並列度は３０となり、それに該当ＨＤＤ台数の１０を乗じた結果の３００が処理ブロックＢの処理並列度モデル予測値となる。また、クエリ５２０の処理ブロックＡが対象の場合には、ステップ７３６で算出した１ＨＤＤ当りの処理並列度は１０であり、１ＨＤＤ当りの同時Ｉ／Ｏ処理数の方が大きいため、処理ブロックＡの１ＨＤＤ当りの処理並列度は１０となり、それに該当ＨＤＤ台数の１０を乗じた結果の１００が処理ブロックＡの処理並列度モデル予測値となる。

続いて、解析・可視化プログラム１９５は、ＤＢモニタ情報１９７のＤＢ統計情報１２６のシーケンシャルＩ／Ｏ性能２２０、もしくはランダムＩ／Ｏ性能２２２を参照し、当該処理ブロックがアクセスするオブジェクトの行数を処理並列度モデル予測値で実行した場合に要する処理時間を算出する（ステップ７４２）。クエリ５２０の処理ブロックＢが対象の場合には、処理ブロックＢのスキャン種別は索引スキャン（Index Scan）、アクセスするオブジェクト“Ｔ２”の選択行数は１００，０００、処理並列度モデル予測値は３００、ランダムアクセス性能１０ｍｓであるから、処理ブロックＢの処理時間は、選択行数／処理並列度モデル予測値×アクセス性能＝１００，０００／３００×１０ｍｓ≒３．３ｓとなる。また、クエリ５２０の処理ブロックＡが対象の場合には、処理ブロックＡのスキャン種別は索引スキャン（Index Scan）、アクセスするオブジェクト“Ｔ１”の選択行数は１００、処理並列度モデル予測値は１００、ランダムアクセス性能１０ｍｓから、処理ブロックＡの処理時間は、選択行数／処理並列度モデル予測値×アクセス性能＝１００／１００×１０ｍｓ≒１０ｍｓとなる。

上記処理により、クエリ５２０を実行した際に予測される処理挙動は、処理ブロックＢの処理を処理並列度３０で３．３ｓ実行し、その後、処理ブロックＡの処理を処理並列度１０で１０ｍｓ実行するということになる。

図９は、実施例１に係る処理並列度実測値算出処理のフローチャートである。尚、実施例１では、処理並列度実測値としてＨＤＤ毎のタグ数が算出される。具体的には、解析・可視化プログラム１９５は、イベントベースであるＳＴ処理情報を１件ずつ読込み、そのイベントに応じて該当ＨＤＤのタグ数をインクリメント或いはデクリメントする（ディスクＩ／Ｏ開始イベントの場合にインクリメントし、ディスクＩ／Ｏ終了イベントの場合にデクリメントする）。そして、解析・可視化プログラム１９５は、所定のサンプリング間隔毎に、その時点における全ＨＤＤの処理ブロック毎のタグ数を処理並列度実測値として取得する。

解析・可視化プログラム１９５は、まず全ＨＤＤのタグ数を０クリアして初期化し（ステップ８０１）、ＳＴモニタ情報１９９内のＳＴ処理情報１７４を１エントリ読込み（ステップ８０２）、全てのエントリの読込みが終わったかどうかを判定し（ステップ８０４）、全てのエントリの読込みを終了していない場合（ステップ８０４でＮｏ）には、ステップ８０８からの処理を実行する一方、全てのエントリの読込みを終了した場合（ステップ８０４でＹｅｓ）には、処理並列度実測値算出処理を終了する（ステップ８０６）。

解析・可視化プログラム１９５は、ステップ８０２で読込んだＳＴ処理情報１７４の１エントリのタイムスタンプが実測値算出の所定のサンプリング間隔を越えたかどうかを判定し（ステップ８０８）、実測値算出のサンプリング間隔を越えた場合（ステップ８０８でＹｅｓ）には、その時点における全ＨＤＤの処理ブロック毎のタグ数（処理に用いる変数）を、当該時点におけるタグ数として取得する（ステップ８１０）。一方、実測値算出のサンプリング間隔を超えていない場合（ステップ８０８でＮｏ）には、何もしない。ここで、実測値算出のサンプリング間隔は、解析・可視化プログラム１９５が起動時にパラメータとして与えても良いし、解析を開始する前にシステム管理者が設定しても良い。

続いて、ステップ８０２で読込んだＳＴ処理情報１７４の１エントリのイベントが“ディスクＩ／Ｏ開始”（Disk IO-Start）イベントの場合、解析・可視化プログラム１９５は、ＯＳモニタ情報１９８のＯＳ処理情報１１６及びＤＢモニタ情報１９７のＤＢ処理情報１３０を参照し、当該イベントのＩ／Ｏを発行したクエリ、及びクエリ内の処理ブロックを特定し、アクセス先となるディスク１７８の処理ブロック毎のタグ数をインクリメントする（ステップ８１２）。例えば、ＳＴ処理情報１７４のエントリ番号３の“ディスクＩ／Ｏ開始”イベントの場合、Ｉ／Ｏの識別子（IO-ID）は“ＩＯ１”である。同じ識別子“ＩＯ１”を有するＯＳ処理情報１１６のエントリ、ＤＢ処理情報１３０のエントリをそれぞれ検索して見つけ出し、当該Ｉ／Ｏを発行したクエリ“Ｑ１”とクエリ内の処理ブロック“Ａ”を特定する。

続いて、ステップ８０２で読込んだＳＴ処理情報１７４の１エントリのイベントが“ディスクＩ／Ｏ終了”（Disk IO-End）イベントの場合、解析・可視化プログラム１９５は、ＯＳモニタ情報１９８のＯＳ処理情報１１６、及びＤＢモニタ情報１９７のＤＢ処理情報１３０を参照し、当該イベントのＩ／Ｏを発行したクエリ、及びクエリ内の処理ブロックを特定し（特定手順はステップ８１２と同様）、アクセス先となるディスク１７８の処理ブロック毎のタグ数をデクリメントする（ステップ８１４）。そして、解析・可視化プログラム１９５は、ステップ８０２に戻り、ＳＴ処理情報１７４の次の１エントリの読み込みを行う。

上記、処理並列度実測値算出処理によると、実測値サンプリング間隔で、ディスク１７８毎の処理ブロック毎のタグ数を算出することができ、実際にクエリを実行した場合のＤＢＭＳ１２０の実処理挙動を特定することができる。

続いて、解析・可視化プログラム１９５が、算出した処理並列度モデル予測値と処理並列度実測値とに基づいて表示されるグラフに関して説明する。

図１０Ａは、実施例１に係る処理並列度モデル予測値グラフの例を示す図である。図１０Ａに示すグラフ９００は、縦軸を処理並列度モデル予測値とし、横軸を時間としたグラフであり、処理並列度モデル予測値算出処理で算出した処理並列度モデル予測値を時系列で描画したものである。グラフ９００では、グラフ線９０２が処理並列度モデル予測値を示し、時間０からｔ１までが処理ブロックＢの処理並列度モデル予測値であり、時間ｔ１からｔ２までが処理ブロックＡの処理並列度モデル予測値である。

図１０Ｂは、実施例１に係る処理並列度モデル予測値及び処理並列度実測値のグラフの第１の例を示す図である。図１０Ｂに示すグラフ９１０は、縦軸を処理並列度（処理並列度モデル予測値及び処理並列度実測値）とし、横軸を時間としたグラフであり、処理並列度モデル予測値算出処理で算出した処理並列度モデル予測値と、処理並列度実測値算出処理で算出した処理並列度実測値を時系列で描画したものである。グラフ９１０では、処理並列度モデル予測値がグラフ線９０２で示され、処理並列度実測値が色を付けて重ね合わせて描画している。グラフ９１０で示した例によれば、処理並列度モデル予測値と処理並列度実測値とが、処理ブロックＡ、処理ブロックＢとも時間ｔ０〜ｔ２の範囲で適合していることがわかり、ＤＢＭＳ１２０は、モデルに基づいて予測した処理挙動通りに動作しているという判定ができる。

図１０Ｃは、実施例１に係る処理並列度モデル予測値及び処理並列度実測値のグラフの第２の例を示す図である。図１０Ｃに示すグラフ９２０は、グラフ９１０と同様のグラフである。グラフ９２０で示した例によれば、処理並列度モデル予測値と処理並列度実測値とが、処理ブロックＢの一部の時間ｔ０〜ｔ３の範囲で不適合であり、処理ブロックＢの時間０〜ｔ０の範囲は適合であり、処理ブロックＡの範囲は適合していることがわかる。このグラフ９２０によると、ＤＢＭＳ１２０は、モデルに基づいて予測した処理挙動通りに動作していないという判定ができ、この場合問題が発生していると捉えその問題の発生時間はｔ０の可能性が高いということを容易に判定することができる。

グラフ９１０、９２０で示した様に、処理ブロック毎に処理並列度モデル予測値と処理並列度実測値のグラフを重ね合わせて表示することで、処理並列度モデル予測値と処理並列度実測値との比較を容易に行うことができる。尚、グラフ９１０、グラフ９２０における処理並列度実測値のグラフにおいて、ＤＢＭＳ１２０以外のシステム、プログラムから発生したＩ／Ｏに関しては、表示形態（例えば、グラフ色をグレーにする等）を変えて表示するとしても良い。この場合、ＤＢＭＳ１２０以外のシステム、プログラムからのＩ／Ｏは、前述した処理並列度実測値算出処理８００内で、ＤＢ処理情報１３０、ＯＳ処理情報１１６、ＳＴ処理情報１７４に含まれる「IO-ID」によって紐付かないＩ／Ｏがそうであると特定できる。これにより、ＤＢＭＳ１２０からのＩ／Ｏか、それ以外のシステム、プログラムからのＩ／Ｏかを切り分けることができ、ＤＢＭＳ１２０だけの処理挙動の解析を行うことができる。

続いて、解析・可視化プログラム１９５により表示される画面の例に関して説明する。

図１１Ａは、実施例１に係る処理並列度モデル予測値のグラフを含む画面表示例を示す図である。解析・可視化プログラム１９５が実行されると、図１１Ａに示すようにウインドウ１０００がディスプレイ１４４に表示される。ウインドウ１０００には、メニューバー１００１、表示対象ＨＤＤ選択ボックス１００２、モデル予測値表示選択ボタン１００４、実測値表示選択ボタン１００６、グラフ描画アリア１００８、ウインドウを閉じるボタン１０１２が配置され、マウス等の入力装置により各ボタンに対する指示操作等を行うことが可能である。

メニューバー１００１には、解析開始や画面切替え、プログラム終了等の指示を与えるメニューが用意される。表示対象ＨＤＤ選択ボックス１００２では、グラフ描画エリア１００８に描画するグラフの対象となるＨＤＤを選択することができる。ここで表示対象ＨＤＤ選択ボックス１００２において、“ＡＬＬ”が選択されると、解析・可視化プログラム１９５は、システム全体の処理並列度のグラフをグラフ描画エリア１００８に描画する。モデル予測値表示ボタン１００４が選択指示されると、解析・可視化プログラム１９５は、モデル予測値表示ボタン１００４を選択状態（図においては、太枠表示が選択状態を示す）にし、処理並列度モデル予測値算出処理で算出した処理並列度モデル予測値のグラフをグラフ描画エリア１００８に描画する。また、実測値表示ボタン１００６が選択指示されると、解析・可視化プログラム１９５は、実測値表示ボタン１００６を選択状態（図においては、太枠表示が選択状態を示す）にし、処理並列度実測値算出処理で算出した処理並列度実測値のグラフをグラフ描画エリア１００８に描画する。図１１Ａの例では、処理並列度モデル予測値だけを表示した状態である。

図１１Ｂは、実施例１に係る処理並列度モデル予測値及び処理並列度実測値のグラフを含む画面表示例を示す図である。図１１Ｂの例では、モデル予測値表示ボタン１００４及び実測値表示ボタン１００６が選択されている状態であり、グラフ描画エリア１００８には、処理並列度モデル予測値及び処理並列度実測値が重ねあわされたグラフが表示される。また、グラフ描画エリア１００８に描画されたグラフに対して、マウスカーソルが合わせられると、解析・可視化プログラム１９５は、その箇所の情報（タイムスタンプ、クエリの識別子、処理ブロックの識別子、処理並列数等）をツールチップ１０１０で表示する。閉じるボタン１０１２がマウスクリックされると、解析・可視化プログラム１９５は、ウインドウ１０００を閉じて、処理を終了する。

システム管理者は、解析・可視化プログラム１９５により表示された画面を操作することで、処理並列度モデル予測値及び処理並列度実測値のグラフを表示させることができ、ＤＢＭＳ１２０のモデルに基づいて予測した処理挙動に対し、実際にどう動作したか、問題が発生していないか等を容易且つ適切に判定することができる。

次に、問題が発生している原因についての調査に利用する表示画面について説明する。

図１１Ｃは、実施例１に係る滞留数についてのグラフを含む画面表示例を示す図である。

図１１Ｃは、計算機システムにおける処理滞留が考えられる箇所（要素：処理滞留箇所）毎の滞留状況を表示したグラフを含む画面である。処理滞留箇所としては、例えば、計算機１００のＤＢＭＳ１２０内部（ＤＢＭＳ１２０による処理要素）、ＯＳ１１２内部（ＯＳ１１２による処理要素）、Ｉ／Ｆ（１）１３６の一例であるＨＢＡ、通信ネットワーク１４０、ストレージ装置１５０のコントローラ１５４、ＨＤＤ１７８の構成要素等がある。

ここで、まず、解析・可視化プログラム１９５による各滞留箇所の滞留状況を取得する処理を説明する。解析・可視化プログラム１９５は、ＤＢモニタ情報１９７のＤＢ処理情報１３０、ＯＳモニタ情報１９８のＯＳ処理情報１１６、ＳＴモニタ情報１９９のＳＴ処理情報１７４を参照し、それぞれの滞留箇所に対応するイベント（例えば、ＤＢＭＳ１２０での滞留については、ＤＢ処理情報１３０内の“IO-Submit”イベント〜“IO-GetEvent”イベントで特定できる）に基づいて、滞留数のインクリメント又はデクリメントを行い、処理並列度実測値算出処理と同様に、実測サンプリング時間で各滞留箇所の滞留数を確定して取得することにより、実測サンプリング時間毎の滞留数を取得することができる。解析・可視化プログラム１９５は、各滞留箇所についての実測サンプリング時間毎の滞留数を用いて、滞留数の時系列のグラフとして表示する。

図１１Ｃに表示された画面は、ウインドウ１０００のメニューバー１００１の画面切り替えメニューが選択された場合に切り替えて表示させても良いし、問題発生時に自動的にその箇所を特定して表示するようにしても良い。図１１Ｃに示す画面においては、ウインドウ１０００には、メニューバー１００１、閉じるボタン１０１２、グラフ描画エリア１０１０が含まれる。グラフ描画エリア１０１０において、解析・可視化プログラム１９５は、縦軸を滞留数とし、横軸を時間とした各滞留箇所における滞留数の時系列のグラフを描画する。図１１Ｃにおいては、滞留箇所１の滞留状況をグラフ１０１２で表し、滞留箇所２の滞留状況をグラフ１０１４で表し、滞留箇所３の滞留状況をグラフ１０１６で表している。例えば、時間ｔ０に問題が発生していることが処理並列度モデル予測値と処理並列度実測値とのグラフで分かった場合、時間ｔ０の各滞留箇所の状況を図１１Ｃの画面により把握して原因を容易に特定することができる。例えば、図１１Ｃの画面例においては、時間ｔ０に滞留箇所２の滞留状況が大きく変化していることが分かるので、滞留箇所２に問題の原因があるということを容易に特定することができる。

次に、解析・可視化プログラム１９５により表示される別の画面例について説明する。

図１２Ａは、実施例１に係るＨＤＤにおける処理並列度のモデル予測値と実測値との適合・不適合を示すグラフを含む画面表示例を示す図である。図１２Ｂは、実施例１に係る各ＨＤＤについての処理並列度のモデル予測値と実測値との適合・不適合を示す画面表示例を示す図である。

図１１Ａ、図１１Ｂに示した画面では、ＨＤＤ毎の処理並列度理論値と処理並列度実測値とを表示することができる。ＨＤＤ数が少数であれば、システム管理者がそれぞれのＨＤＤ毎に処理並列度モデル予測値と処理並列度実測値のグラフを表示し、各ＨＤＤが適正に動作したか否かを判定することができる。しかし、数百〜数千オーダーのＨＤＤを有する計算機システムの場合、同様のことを各々のＨＤＤについて行うには膨大な時間を要することになる。

そこで、解析・可視化プログラム１９５が、ＨＤＤ毎に処理並列度（ＨＤＤタグ数）の不適合率を自動的に割り出してその結果を表示することにより、システム管理者の解析工数を削減し、挙動・性能解析を容易化する。ここで、処理並列度の不適合率は、クエリの全体の処理時間に対する不適合の時間の割合としている。例えば、あるＨＤＤの処理並列度モデル予測値及び処理並列度実測値の関係が、図１０Ｃのグラフに示すような関係であるとすると、全体の処理時間がｔ４であり、不適合の時間がｔ３−ｔ０となり、不適合率は、ｔ４／（ｔ３−ｔ０）として表すことができる。ここで、解析・可視化プログラム１９５は、例えば、実測値サンプリング間隔毎に、処理並列度モデル予測値と処理並列度実測値とを比較し、両者が一致していれば適合と判定し、一致していなければ不適合と判定する。尚、システム管理者が解析・可視化プログラム１９５に対して適合・不適合判定の閾値を設定するようにし、処理並列度モデル予測値に対して処理並列度実測値が、その閾値の範囲内に収まれば適合として判定するようにしても良い。

図１２Ａは、時間経過に伴う、当該計算機システムの全ＨＤＤにおける処理並列度モデル予測値と処理並列度実測値との適合・不適合ＨＤＤ数を表示した画面の一例である。ウインドウ１０００には、メニューバー１００１、閉じるボタン１０１２、グラフ描画エリア１０１０が含まれる。グラフ描画エリア１０１０に、適合・不適合ＨＤＤ数のグラフが縦軸をＨＤＤ数とし、横軸を経過時間として描画される。図１２Ａに示す画面においては、ライン１１０２が全ＨＤＤを示し、グラフ１１０４が適合するＨＤＤの数、グラフ１１０６が不適合のＨＤＤの数を示している。尚、処理全体の中で各々のＨＤＤが適合か不適合かの判定は、不適合率が０％のＨＤＤを適合として判定しても良いし、システム管理者が解析・可視化プログラム１９５に与えたパラメータ（例えば不適合率２０％）以下を適合として判定しても良い。図１２Ａに示す画面により、ＤＢＭＳ１２０による処理全体の中で、どの程度のＨＤＤがモデルに基づいて予測した処理挙動で動作しているか、動作していないかを容易に特定することができる。

図１２Ｂは、計算機システムの全ＨＤＤにおける処理並列度モデル予測値と処理並列度実測値との適合・不適合の状態をグラフ描画エリア１０１０にマトリックス表示した画面である。

同図において、マトリックスにおけるそれぞれの矩形部分が一つのＨＤＤに対応している。この矩形部分は、処理並列度数モデル予測値と処理並列度実測値とが適合しているＨＤＤと、処理並列度数モデル予測値と処理並列度実測値とが不適合であるＨＤＤと、クエリにおける未アクセスのＨＤＤとで異なる表示態様（例えば、異なる色）で表示される。ここで、矩形１１１０は、適合しているＨＤＤを示し、矩形１１１２は、不適合であるＨＤＤを示し、矩形１１１４は、未アクセスのＨＤＤを示している。解析・可視化プログラム１９５による、各々のＨＤＤが適合か不適合かの判定方法については、上記と同様に、不適合率が０％のＨＤＤを適合として判定するように良いし、システム管理者が解析・可視化プログラム１９５に与えたパラメータ（例えば不適合率２０％）以下を適合として判定するようにしても良い。

尚、図１２Ｂにおいては、全ＨＤＤを一つのマトリックスで示しているが、ストレージ装置１５０毎やＲａｉｄグループ毎といった様に、これらのグループを１つのマトリックスで表示するようにしても良い。また、マトリックス中の一つの矩形部分をマウスクリック等の操作によって選択されたときに、解析・可視化プログラム１９５が、選択された矩形部分に対応するＨＤＤについて、図１１Ｂに示すような処理並列度モデル予測値・処理並列度実測値のグラフを表示するようにしても良い。これにより、処理並列度モデル予測値と処理並列度実測値との適合・不適合の状態を容易且つ詳細に解析することができる。

図１２Ｃは、実施例１に係る処理並列度のモデル予測値と実測値との不適合率が高いＨＤＤを順番に示す画面表示例を示す図である。

図１２Ｃに示すウインドウ１０００においては、解析・可視化プログラム１９５により、グラフ表示エリア１０１０に、処理並列度モデル予測値と処理並列度実測値との不適合率が高いＨＤＤが順番にランキング表示される。グラフ表示エリア１０１０において、エリア１１２０にはランキング番号が表示され、エリア１１２２にはストレージ装置１５０を識別する識別子（ST-ID）とＨＤＤ１７８を識別する識別子（HDD-ID）が表示され、エリア１１２４には不適合率が表示される。

図１２Ｃにおいては、ストレージ装置“ＳＴ1”のＨＤＤ“ＨＤＤ４５”が不適合率３２．５％で１位であることが表示され、ストレージ装置“ＳＴ１”のＨＤＤ“ＨＤＤ６”が不適合率３１．８％で２位であることが表示され、ストレージ装置“ＳＴ１”のＨＤＤ“ＨＤＤ７４”が不適合率３１．４％で３位であることが表示されている。

また、グラフ表示エリア１０１０においては、ランキングの各々のエントリに対応する位置に詳細表示ボタン１１２６が表示される。詳細表示ボタン１１２６に対して、マウスクリック等の操作が行われると、対応するＨＤＤについての処理並列度モデル予測値及び並列処理度実測値のグラフが表示される。これにより、不適合率が高いとして表示されている各ＨＤＤについての処理並列度モデル予測値と処理並列度実測値との適合・不適合の状態を詳細に解析することができる。

更に、解析・可視化プログラム１９５により表示される別の画面例について説明する。

図１１Ａ、図１１Ｂに示した画面によると、計算機システムにおける処理並列度モデル予測値・処理並列度実測値を表示し、ＤＢＭＳ１２０がモデルに基づいて予測した処理挙動通りに動作しているか、問題が発生していないかを容易に判定することができ、図１１Ｃに示した画面により、問題が発生している箇所を容易に特定することができる。しかし、これらの画面のみでは、ＤＢＭＳ１２０の実際の挙動がどうなっているかをより詳細に調査・解析することはできない。

そこで、解析・可視化プログラム１９５は、システム情報１９６、ＤＢモニタ情報１９７、ＯＳモニタ情報１９８、ＳＴモニタ情報１９９を解析し、ＤＢＭＳ１２０における各スレッドの処理状況を画面に表示することにより、ＤＢＭＳ１２０の実挙動の調査・解析を容易化する。

図１３Ａは、実施例１に係るＤＢＭＳがアクセスしている表や索引毎のタスク数の統計値のグラフを含む画面表示例を示す図である。図１３Ａに示すグラフ１２００は、ウインドウ１０００のグラフ描画エリア１０１０に、縦軸をアクセスしているオブジェクト毎のタスク数、横軸を時間として、アクセスしているオブジェクト毎のタスク数を時系列でオブジェクト毎に表示態様（例えば、グラフの色）を変えて描画したものである。このグラフ１２００により、各時間帯でどのオブジェクトに、どれだけのタスクがアクセスしているかを容易に特定することできる。

図１３Ｂは、実施例１に係るタスクの状態毎の統計値のグラフを含む第１の画面表示例を示す図である。図１３Ｂに示すグラフ１２１０は、ウインドウ１０００のグラフ描画エリア１０１０に、縦軸をタスク状態毎のタスク数、横軸を時間として、タスク状態毎のタスク数を時系列でタスク状態毎に表示形態（例えば、グラフの色）を変えて描画したものである。タスクの状態としては、例えば、ＤＢ処理実行中、Ｉ／Ｏ発行中の状態、ＣＰＵ割当て待ちの状態、ＤＢバッファのＩ／Ｏ完了待ち状態、ロック保持状態、ロック取得待ち状態を取る。グラフ１２１０で示した例では、グラフ１２１２は、ＤＢバッファのＩ／Ｏ完了待ち状態のタスク数を示し、グラフ１２１４は、ロック取得待ち状態のタスク数を示し、グラフ１２１６は、ＣＰＵ割当待ちの状態のタスク数を示し、グラフ１２１８は、Ｉ／Ｏ発行中の状態のタスク数を示している。グラフ１２１０によると、各時間帯でタスクが実行可能な上限で動作しているか、またどの様なタスク状態となっているか等を容易に特定することができる。

図１３Ｃは、実施例１に係る各タスクの状態を示すグラフを含む第２の画面表示例を示す図である。図１３Ｃに示すグラフ１２２０は、ウインドウ１０００のグラフ描画エリア１０１０に、縦軸をタスク（横方向の１ラインが１タスクの状態を示す）、横軸を時間として、タスクの状態毎に表示形態（例えば、グラフの色）を変えて描画したものである。尚、タスクの状態のうち、ロック保持状態以外はいずれかの一つの状態だけを取るが、ロック保持状態はそれ以外の状態と重なる場合（例えば、ロックを保持しながらＩ／Ｏを発行している場合等）があるため、ロック保持状態のグラフはそれ以外のグラフの下に描画するようにしている。グラフ１２２０によると、各時間帯で各タスクがどの様な状態にあるかを容易に特定することができる。

実施例１においては、処理並列度モデル予測値は、参照する索引のキー値に対応する選択行数、カーネルスレッド数、タスク数、ＨＢＡ同時Ｉ／Ｏ処理数、ストレージコントローラの同時Ｉ／Ｏ処理数、１ＨＤＤ当りの同時Ｉ／Ｏ処理数を基にして算出している。しかし、実施例１には記載していないが、ＯＳが多段化されているＶＭ（Virtual Machine）やＯＳ内のファイルシステムやスケジューラ、デバイスドライバ等におけるＩ／Ｏパス上のキュー長やネットワーク上のＱＯＳ制御によるスロットリング等、その他にも処理並列度の律速要因が考えられる。実施例１において、それらの律速要因となる部位に関する情報を取得する手段を設け、処理並列度を算出する際にそれらを含めて算出するとしても良い。

実施例１においては、ＤＢＭＳ１２０が１つのクエリを実行した場合について説明しているが、ＤＢＭＳ１２０が複数のクエリが同時に実行した場合についても同様に処理並列度モデル予測値と処理並列度実測値を算出し、その結果を画面表示することで複数クエリ実行時の処理挙動についても解析が可能である。この場合、クエリプラン情報１２８、ＤＢ処理情報１３０に含まれる「QID」で複数のクエリの識別が可能となる。処理並列度モデル予測値の算出に関しては、クエリ毎に処理並列度モデル予測値算出処理６１０を実行してそれらを合算することでシステム全体の処理モデル予測値を算出することができる。処理並列度実測値の算出に関しては、前述の「QID」でクエリ毎にカウントすることで算出できる。また、複数クエリ実行時の処理並列度実測値を画面にグラフ表示する際は、それぞれのクエリ毎に表示形態（例えば、グラフ色）を変えて表示することで、各クエリがどう実行されたかを解析することが可能となる。

図１４は、複数クエリ（本例ではクエリＸとクエリＹ）を実行した際の処理並列度モデル予測値と処理並列度実測値のグラフの例を示した図である。図１４に示すグラフ１４００では、クエリＸとクエリＹのそれぞれの処理並列度モデル予測値を合算した値を処理並列度モデル予測値のグラフ線９０２として表示し、クエリＸの処理並列度実測値１４０２とクエリＹの処理並列度実測値１４０４の色を変えて表示している。

実施例１においては、例えばＬＶＭ（Logical Volume Manager）のようなＩ／Ｏパスの抽象化層に関して説明していないが、Ｉ／Ｏパスの抽象化層を考慮した処理並列度モデル予測値と処理並列度実測値の算出し、その結果の表示により、ＤＢＭＳ１２０の処理挙動の解析を行うものとして良い。図１５Ａ、図１５ＢはＬＶＭを用いた場合の論理ボリューム情報、ボリュームグループ情報の一例の構成図である。論理ボリューム情報１５００は、論理的な記憶領域である論理ボリュームと、当該論理ボリュームが作られるボリュームグループのマッピングに関する情報であり、論理ボリューム毎にエントリを有する。各エントリは、論理ボリュームを識別するための論理ボリューム名を登録するフィールド１５０２、当該論理ボリュームが作られるボリュームグループを識別するためのボリュームグループ名を登録するフィールド１５０４を有する。ボリュームグループ情報１５１０は、ボリュームグループと当該ボリュームグループを構成する物理ボリューム（デバイス）のマッピングに関する情報であり、ボリュームグループ毎にエントリを有する。各エントリは、ボリュームグループを識別するためのボリュームグループ名を登録するフィールド１５１２、当該ボリュームグループを構成する物理ボリューム（デバイス）を登録するフィールド１５１４を有する。また、この場合、ＤＢファイルは論理ボリューム上に作成することになり、図２ＢのＤＢファイル情報１２４のデバイス名を登録するフィールド２１２には作成した論理ボリューム名を登録する。処理並列度モデル予測値、及び処理並列度実測値を算出する処理では、論理ボリューム情報１５００、及びボリュームグループ１５１０を参照して、ＤＢＭＳ１２０がＤＢ処理を実行する際にアクセスするＨＤＤを特定する。

実施例１においては、処理並列度モデル予測値値（例えば、ＨＤＤタグ数のモデル予測値）と、処理並列度実測値（例えば、ＨＤＤタグ数の実測値）とに着目して、ＤＢＭＳ１２０の挙動・性能を解析する方法を説明しているが、例えば、性能を消費電力と置き換え、計算機システムで問合わせを実行した場合の消費電力モデル予測値と、実際にクエリを実行した際の消費電力実測値とを算出し、消費電力のモニタリングとして活用することも可能である。特に、大規模なシステム環境においては膨大な電力を消費するため、予め消費電力モデル予測値を算出してシステム管理者に提示するだけでも有用である。また、消費電力モデル予測値と、消費電力実測値とを比較可能に表示することにより、消費電力の解析を容易に行うこともできる。

以上説明したように、実施例１によると、システム管理者は、ＤＢＭＳ１２０がモデルに基づいて予測した処理挙動通りに動作しているか、動作していないかを容易に判定することが可能となり、また動作していない場合には問題が発生していると捉え、その問題の原因箇所を容易に特定することが可能となる。更に、ＤＢＭＳ１２０の実際の挙動を容易に調査・解析することが可能となり、ＤＢＭＳ１２０の挙動・性能解析に要する時間を大幅に短縮することができる。

以下、実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。

実施例１では、解析・可視化プログラム１９５は、モデル予測値を算出し、モデル予測値と実測値とをディスプレイ１４４に表示するが、実施例２では、解析・可視化プログラム１９５は、モデル予測値を必ずしも算出及び表示しないで良い。実施例２では、ＤＢモニタ情報出力部１３２が、クエリ実行の進行に伴い、タスクの実行に係るイベントドリブンの情報を後述のＤＢ処理情報２２００、２４００として出力し、解析・可視化プログラム１９５はその情報を取得してタスクの実行状況を示すグラフを画面に表示する。

勿論、実施例１と実施例２を組み合わせることもできる。実施例１と実施例２の組み合わせでは、例えば、下記の流れが考えられる。
（Ａ）解析・可視化プログラム１９５が、取得した各種モニタ情報を基に、ＤＢＭＳ１２０の処理挙動のモデル予測値と実測値とを算出し、それらのグラフ（図１１Ａ〜図１１Ｃ、必要に応じて（例えば、システム管理者からの要求に応答して）図１２Ａ〜図１２Ｃ）をディスプレイ１４４に表示する。
（Ｂ）システム管理者は、それらのグラフを見て、ＤＢＭＳ１２０の処理に問題が発生しているか否かを判定する。

上記（Ｂ）で、問題が発生していると判定された場合、システム管理者は、次のような操作を行うことで、発生している問題を特定することができる。なお、特定される問題としては、例えば、ＤＢＭＳ１２０２はタスクを並列に実行可能であるにも関わらず逐次的にタスクが実行されている等がある。

例えば、システム管理者は、ディスプレイ１４４に表示された画面のメニューを操作することにより、解析・可視化プログラム１９５に、ＤＢＭＳ１２０の挙動に関するグラフ（例えば図１３Ａ〜図１３Ｃ）を表示させる。これにより、システム管理者は、スレッドの実行状態やオブジェクトアクセス状態等の解析を行うことができる。

また、例えば、システム管理者は、ディスプレイ１４４に表示された画面のメニューを操作することにより、解析・可視化プログラム１９５に、可視化ウィンドウ２５００（図２５）を表示させ、且つ、解析・可視化プログラム１９５に、タスク挙動可視化ツリー（例えば図２６又は図３０）、及び／又は、データ構造可視化ツリー（例えば図２７）を可視化ウィンドウ２５００上に描画させる。タスク挙動可視化ツリー及びデータ構造可視化ツリーにおける各ノードの表示態様は、クエリの実行の進捗に応じて（図２２、及び図２４に示すＤＢ処理情報内のイベントタイプに応じて）変化する。これにより、システム管理者は、クエリの実行の際に生じた問題を特定することができる。

以下、実施例２を詳細に説明する。

実施例２では、スキーマとして、例えば、図１６に示すように、索引ＩＡ、表Ａ、索引ＩＢ及び表Ｂがある。索引ＩＡは、表ＡのカラムＡ２に張られているおり、索引ＩＢは、表ＢのカラムＢ１に張られている。

ＤＢＭＳ１２０は、図１６に示したスキーマ群について、図１７Ａに示すクエリを受信した場合、図１７Ｂに示すクエリプランを生成し、その実行結果として、例えば、図１７Ｃに示すクエリ結果を取得する。

図１６に示したスキーマ群のうち、索引ＩＡ及び表Ａについては、データ構造が、図１８に示す通りの構造であって、索引ＩＢ及び表Ｂについては、データ構造が、図１９に示す通りの構造であるとする。図１８及び図１９において、「Ｐ」は、ＤＢページを表している。以下、「Ｐｘｘｘ」を（ｘｘｘは３桁の整数）、ＤＢページ＃ｘｘｘと表記する。例えば、図１８によれば、カラムＡ２の値として「ＡＢＢ」以上の値を含んだレコード内の値は、ＤＢページ＃１０１からページ参照に従いＤＢページ＃１０３を参照し、かつ、ＤＢページ＃１０３からレコード参照に従いＤＢページ＃１０５及び１０６を参照することで、ＤＢページ＃１０５及び１０６から取得可能である。

なお、索引は、ここでは木構造としているが、ハッシュ等の別の構造であってもよい。

また、レコード参照は、ここでは物理参照（例えば、ページＩＤとページ内の格納位置）としているが、論理参照（一意性のある主キー）であってもよい。その場合、二次索引から索引エントリを得て、主索引を検索して、レコードを得ることができる。

また、表のデータ構造は、フラットファイルとしているが、索引構成表のように、索引同様に木構造等であってもよい。

上記のデータ構造を表す情報は、通常、計算機１００のメモリ１１０に記憶させるには困難な程に膨大である。そのため、ＤＢＭＳ１２０は、その情報のサマリであるデータ構造サマリテーブルを作成し、データ構造サマリテーブルをメモリ１１０に記憶させる。

図２０は、データ構造サマリテーブル２０００の一例を示す。このテーブル２０００は、ＤＢページ毎に、ページＩＤと、オブジェクトＩＤ（ＤＢページに格納されている値を有するスキーマのＩＤ）と、親ＤＢページＩＤ（ＤＢページの親ＤＢページ（参照元のＤＢページ）のＩＤ）と、キー範囲（使用可能なキー値の上限と下限）とを含む。

２５個のタスク＃１〜＃２５があるとする。

従来型のＤＢＭＳであれば、図２１に示すように、２５個のタスクを逐次的に実行する。その実行履歴が記述されたレコードの集合を表すＤＢ処理情報は、例えば、図２２に示すＤＢ処理情報２２００となる。ＤＢ処理情報２２００は、１以上のレコードを有する。１つのレコードは、１つのタスク実行履歴に対応しており、エントリ番号（履歴の番号）と、タイムスタンプ（タスク実行の時刻又は番号）と、スレッドＩＤ（実行されたタスクを有するスレッドのＩＤ）と、イベントタイプ（タスク実行により行われたイベントのタイプ）と、タスクＩＤ（実行されたタスクのＩＤ）と、親タスクＩＤ（実行されたタスクの親タスクのＩＤ）とを有する。ＤＢ処理情報２２００は、図２Ｅに示すＤＢ処理情報１３０の変形例である。

しかし、前述したＤＢＭＳ１２０は、タスクを並列に実行するようになっており、例えば、タスク＃１〜＃２５を、図２３に示す通りに実行する。より具体的には、ＤＢＭＳ１２０は、タスク＃１を生成して実行し、実行されたタスク＃１に対応したＤＢオペレーションの実行結果に基づき次のＤＢオペレーションを実行する場合には、当該実行結果に基づくタスク＃２及び＃１６を新たに生成し、新たに生成したタスク＃２及び＃１６を並列に実行する。これにより、図２１と図２３を比較してわかるように、クエリの実行に要する時間を短くすることができる。なお、図２３に示した通りにタスク＃１〜＃２５を実行した場合のＤＢ処理情報は、例えば、図２４に示すＤＢ処理情報２４００の通りとなる。ＤＢ処理情報２４００は計算機１００のメモリ１１０に記憶される。

図２２のエントリ番号６及び７のレコードと、図２４のエントリ番号６及び７のレコードを比べるとわかるように、従来型のＤＢＭＳは、タスク＃２に対応したオペレーションを逐次的に実行しているが、実施例２に係るＤＢＭＳ１２０は、タスク＃２に対応したオペレーションとタスク＃１６に対応したオペレーションを並列に実行する。

従来型のＤＢＭＳの挙動において何らかの問題が生じても、タスクは発生順に逐次に行われるので、問題を特定することは困難ではないと考えられる。

しかし、実施例２（及び実施例１）のような、タスクを並列に実行するＤＢＭＳの挙動において何らかの問題が生じた場合は、タスクがどのような順番で実行されるかが決まっていないので、問題を特定することは困難である。

この問題を解決する方法として、ＤＢＭＳの挙動を可視化することが考えられる。

しかし、ＤＢＭＳの挙動（ＤＢＭＳが計算機でどのように動いているか）が単純に可視化されても、システム管理者が問題を特定できるとは限らない。例えば、解析・可視化プログラムは、図２４に示したＤＢ処理情報２４００をテキストで表示することで、ＤＢＭＳの挙動を可視化することはできる。しかし、システム管理者は、問題を特定するために、表示されたＤＢ処理情報におけるレコードを時系列順に追う必要があり、問題を特定するための負担が大きい。

そこで、実施例２では、解析・可視化プログラム１９５が、ＤＢ処理情報２４００を計算機１００から取得し、取得したＤＢ処理情報２４００をメモリ１９２に格納する。解析・可視化プログラム１９５が、ＤＢＭＳ１２０の挙動を、メモリ１９２内のＤＢ処理情報２４００を基に、下記のルール、
（ａ）実行されたタスクを表すオブジェクトであるタスクオブジェクトを描画する、
（ｂ）タスクオブジェクトの表示態様を、そのタスクオブジェクトが表すタスクの状態（タスク実行により行われたイベントのタイプ）の変化に応じて変える、
に従い可視化する。例えば、タスクオブジェクトは、ツリーにおけるノードであっても良いし、実行されたタスクの数で所定の領域（例えば円）を等分することにより得られた断片領域（例えば扇形領域）であっても良い。また、タスク状態によって変わる表示態様としては、色、模様、明るさ、タスクオブジェクト（例えばノード）の大きさ、線の太さ、或いは、非表示から表示への変更、など、種々の態様を採用することができる。また、解析・可視化プログラム１９５は、タスクオブジェクトの表示態様を、アニメーションで変化させても良い。また、解析・可視化プログラム１９５は、ＤＢ処理情報２４００を基に、タスクの親子関係を表すオブジェクト（例えば、タスクオブジェクト間を結ぶエッジ（リンク））を描画しても良い。

ＤＢの規模が大きくなると、上記のタスクオブジェクトの数も多くなり、解析・可視化プログラム１９５が上記の描画を行った場合、描画の内容が過密となってユーザ（解析者）がその挙動をどう解釈して良いか分からなくなる可能性がある。そこで、解析・可視化プログラム１９５は、ユーザの指示によって、上記タスクオブジェクトの全てを表示する表示形態と、指定されたタスクオブジェクトの一部を表示する表示形態を切り替えることができるようにしても良い。また、表示する一部のタスクオブジェクトの選択には、例えばマウスポインタを選択したいタスクオブジェクトに合わせ、そこを基点にズームイン、ズームアウトによって、表示する上記タスクオブジェクトの範囲を選択できるようにしても良い。

以下、幾つかの具体例を説明する。

解析・可視化プログラム１９５は、可視化ウィンドウの表示のための操作を表す情報を入出力装置１８８から受けた場合に、図２５に示すような可視化ウィンドウ２５００をディスプレイ１４４に表示する。

可視化ウィンドウ２５００は、タスク挙動可視化ツリーが表示されるタスク表示エリア２５０１と、オブジェクトのデータ構造可視化ツリーが表示されるオブジェクト表示エリアとを有する。オブジェクト表示エリアとしては、例えば、１以上の索引にそれぞれ対応した１以上のデータ構造可視化ツリーが表示される１以上の索引の表示エリア２５０２Ａ、２５０２Ｂと、１以上の表にそれぞれ対応した１以上のデータ構造可視化ツリーが表示される１以上の表の表示エリア２５０３Ａ、２５０３Ｂとがある。索引の表示エリアとその索引から参照される表の表示エリアは、所定方向(例えば鉛直方向）に沿って並んでいる。

また、可視化ウィンドウ２５００は、タイムスタンプスライダ２５０４と、ズームインボタン２５０５と、ズームアウトボタン２５０６とを有する。タイムスタンプスライダ２５０４は、タイムスタンプ調整ツールの一例であり、スライダ２５０４が走るバー２５０５の一端が、ルートタスク（最初のタスク）の実行開始時刻（ＤＢ処理情報２４００の先頭レコードにおけるタイムスタンプが表す時刻）であり、バー２５０５の他端が、エンドタスク（最後のタスク）に対応するＤＢオペレーションが終了した時刻（ＤＢ処理情報２４００の末尾レコードにおけるタイムスタンプが表す時刻）である。

図２６は、タスク表示エリア２５０１に描画されるタスク挙動可視化ツリーの一例である。

タスク挙動可視化ツリーは、タスクをノード、タスクの親子関係をエッジ（リンク）とするグラフである。

所定方向（例えば鉛直方向）に沿って、例えば、タイムスタンプの古い方から新しい方へと、２５個のタスク＃１〜＃２５に対応する２５個のノードが並んでいる。図２６では、例えば、ルートタスク（タイムスタンプの最も古いタスク）が最も上にあり、エンドタスク（タイムスタンプの最も古いタスク）が最も下にある。解析・可視化プログラム１９５は、タスク挙動可視化ツリーの表示範囲における鉛直座標範囲を、鉛直方向に並ぶノードの数で等分し、等分された各座標位置に、ノードを描画する。この除算において、解析・可視化プログラム１９５は、イベントタイプ「タスク開始」のタイムスタンプが実質的に同じ２以上のノードを１個のノードとみなす。従って、このツリーから、鉛直座標が同じ２以上のノードにそれぞれ対応した２以上のタスクは、実質的に同じタイミングでタスク開始となっていることがわかる。

また、タスク挙動可視化ツリーにおいて、ルートタスクに相当するノードから等距離のノードが、水平方向に沿って等間隔で配置される。

タスク挙動可視化ツリーにおけるノード及びエッジの表示態様に対応した状態種類として、例えば、未開始タスク、ＩＯ中タスク（イベントタイプが「Task Start」又は「IO-Submit」であるタスク））、ＯＰ中タスク（イベントタイプが「IO-GetEvent」又は「OP Start」であるタスク）、及びＯＰ完了タスク（イベントタイプが「OP End」であるタスク）の４種類がある。解析・可視化プログラム１９５は、初期状態では、全てのノード及びエッジを未開始タスクに対応する表示態様で描画し、その後、ノード及びエッジの表示態様を、指定時刻でのタスクの状態に対応した表示態様に変える。図２６に示すツリーは、タイムスタンプ「１０３．００」でのタスク実行状態を表す。図２４のＤＢ処理情報２４００によれば、タイムスタンプ「１０３．００」で、タスク＃１のイベントタイプは「OP End」となっており、タスク＃２及び１６のイベントタイプは「IO-Submit」となっており、且つ、それ以外のタスクは未開始である。このため、解析・可視化プログラム１９５は、タスク＃１に対応するノード及びエッジの表示態様を、ＯＰ完了タスクに対応した表示態様に変更し（例えば、アニメーションで、途中の表示態様（ＩＯ中タスク、ＯＰ中タスク）も表示した上で変更し）、タスク＃２及び１６に対応するノード及びエッジの表示態様を、ＩＯ中タスクに対応した表示態様に変更し、それ以外のタスクに対応するノード及びエッジの表示態様を、未開始タスクに対応した表示態様のままとする。

図２７は、スキーマ表示エリア２５０２Ａ、２５０２Ｂ、２５０３Ａ及び２５０３Ｂに描画されるデータ構造可視化ツリーの一例である。

データ構造可視化ツリーは、ＤＢページをノード、データ構造上のページ間の依存関係をエッジ（リンク）とするグラフである。

解析・可視化プログラム１９５は、データ構造サマリテーブル２０００を計算機１００から取得し、取得したデータ構造サマリテーブル２０００をメモリ１９２に格納する。解析・可視化プログラム１９５は、メモリ１９２内のＤＢ処理情報２４００とデータ構造サマリテーブル２０００に基づいて、データ構造可視化ツリーを描画する。

データ構造上のＤＢページ間の親子関係は、リンクアレイの場合、リンク等であってよい。データ構造がフラットファイルである場合は、解析・可視化プログラム１９５は、ＤＢページに対応するノードを、グラフ構造として描画せず、ページのアドレス順で配置して描画してもよい。また、解析・可視化プログラム１９５は、データ構造ではなくデータベース全体を、ＤＢページのアドレス順にノードを配置することで描画してもよい。

データ構造のルートページに相当するノードから等距離のノードが、水平方向に等間隔で配置される。

データ構造可視化ツリーにおけるノード及びエッジの表示態様に対応した状態種類として、例えば、未ＩＯページ（対応するタスクが未開始タスクであるＤＢページ）、ＩＯ済ページ（対応するタスクがＩＯ中タスクであるＤＢページ）、ＯＰ中ページ（対応するタスクがＯＰ中タスクであるＤＢページ）、及びＯＰ済ページ（対応するタスクがＯＰ完了タスクであるＤＢページ）の４種類がある。解析・可視化プログラム１９５は、初期状態では、全てのノード及びエッジを未ＩＯページに対応する表示態様で描画し、その後、ノード及びエッジの表示態様を、指定時刻でのタスクの状態に依存するＤＢページ状態に対応した表示態様に変える。図２７に示すツリーは、タイムスタンプ「１０３．００」での状態を表す。図２４に示すＤＢ処理情報２４００によれば、タイムスタンプ「１０３．００」で、ＤＢページ＃１０１は、ＯＰ完了タスクであるタスク＃１から参照されるＤＢページであり、ＤＢページ＃１０２及び１０３は、ＩＯ中タスクであるタスク＃２及び１６から参照されるＤＢページであり、それ以外のＤＢページは、未開始タスクであるタスクから参照されるＤＢページである。このため、解析・可視化プログラム１９５は、ＤＢページ＃１０１に対応するノード及びエッジの表示態様を、ＯＰ済ページに対応した表示態様に変更し（例えば、アニメーションで、途中の表示態様（ＩＯ済ページ、ＯＰ中ページ）も表示した上で変更し）、ＤＢページ＃１０２及び１０３に対応するノード及びエッジの表示態様を、ＩＯ済ページに対応した表示態様に変更し、それ以外のＤＢページに対応するノード及びエッジの表示態様を、未ＩＯページの表示態様のままとする。

解析・可視化プログラム１９５は、指定時刻が変わるにつれ（スライダ２５０４が移動するにつれ）、各種ツリーのノード及びエッジの表示態様を、遷移後の指定時刻のイベントタイプ（又はそれ以前で最も指定時刻に近いイベントタイプ）に応じた表示態様に変更する。例えば、指定時刻が第１の時刻「１０３．００」から第２の時刻（例えば第１の時刻よりも将来の或る時刻）に変わった場合、解析・可視化プログラム１９５は、ＤＢ処理情報２４００を基に、タスク実行可視化ツリーの表示を、図２６に示した表示から図２８に示す表示に変更し（例えばアニメーションで変更し）、且つ、各データ構造可視化ツリーの表示を、図２７に示した表示から図２９に示す表示に変更する（例えばアニメーションで変更する）。具体的には、解析・可視化プログラム１９５は、ＤＢ処理情報２４００におけるレコードの参照先を、指定時刻の変化に伴い切り替えていき、レコード参照先を切り替えに伴い参照したレコード内の値（特にイベントタイプ）に基づいて、当該レコードに対応するタスクについてのノード及びエッジの表示態様を変更する。解析・可視化プログラム１９５は、タスク挙動可視化ツリーとデータ構造可視化ツリーの両方の表示態様を、指定時刻の変化に伴い変更する。すなわち、例えば、解析・可視化プログラム１９５は、指定時刻の変更の結果、タスク＃１の状態が未開始タスクからＯＰ完了タスクに変わった場合には、タスク＃１に対応するノード及びエッジの表示態様を、未開始タスクの表示態様からＯＰ完了タスクの表示態様に変更する（例えば、途中の表示態様も経てアニメーションで変更する）と共に、それに伴って、タスク＃１から参照されるＤＢページ＃１０１の表示態様を、未ＩＯページの表示態様からＯＰ済ページの表示態様に変更する（例えば、途中の表示態様も経てアニメーションで変更する）。解析・可視化プログラム１９５は、指定時刻が順方向（過去から未来）で変更されても逆方向（未来から過去）で変更されても、ＤＢ処理情報２４００におけるレコードの参照先をその変更に伴い切り替え、各種ツリーの表示を変更することができる。

実施例２によれば、可視化ウィンドウ２５００上に描画された各種ツリーにおけるノード及びエッジの表示態様の変化が、ＤＢ処理情報２４００を基に、指定時刻の変化に伴い変化する。システム管理者は、各種ツリーにおけるノード及びエッジの表示態様の変化を見ることで、発生した問題を特定することができる。例えば、システム管理者は、タスク挙動可視化ツリーにおいて、ノード及びエッジの表示態様が、タスクのＩＤの順番で遷移していれば、ＤＢＭＳ１２０がタスクを実行可能であるにも関わらず逐次的にタスクを実行したという問題があったことを特定することができる。また、例えば、システム管理者は、データ構造可視化ツリーにおいて、いつまでの表示態様が変わらないＤＢページがある場合には、そのＤＢページにアクセスすべきタスクが実行されなかったという問題があったことを特定することができる。

なお、実施例２において、解析・可視化プログラム１９５は、ズームインボタン２５０５を押すといったようなズームインのための操作がされた場合、ズームインの対象、例えば、タスク挙動可視化ツリー及びデータ構造可視化ツリーのうちの少なくとも１つを拡大表示することができる。また、解析・可視化プログラム１９５は、ズームアウトボタン２５０６を押すといったようなズームアウトのための操作がされた場合、ズームアウトの対象、例えば、タスク挙動可視化ツリー及びデータ構造可視化ツリーのうちの少なくとも１つを縮小表示することができる。なお、このような伸縮の態様としては、種々の態様を採用することができる。例えば、垂直方向・水平方向の両方に伸縮を行うモードと、その一方についてのみ伸縮を行うモードとが設けられていて、解析・可視化プログラム１９５は、それらのモードのうちシステム管理者から選択されたモードでツリーの伸縮を行っても良い。また、モードとして、ルートノードを常に表示するように伸縮率を調整するモードがあっても良い。解析・可視化プログラム１９５は、再描画時には、描画座標上で表示される領域に含まれるノートのその隣接エッジについてのみ、描画処理を行ってもよい。

また、タスク表示エリア２５０１に表示されるタスク挙動可視化ツリーとしては、図３０に示すようなラディカルツリーが採用されても良い。解析・可視化プログラム１９５は、或るタスクのノード（例えば、ルートタスクのノード）を中心とする同心円状に、同じレベルのタスクのノードを配置することで、図３０に示すようなラディカルツリーを描画することができる。「同じレベルのタスク」とは、或るタスクからの世代数を同じくするタスクであってもよいし、或るデータ構造においてルートページから同じ距離のページをアクセスするタスクであってもよい。このようなラディカルツリーについても、例えば、指定時刻が第１の時刻「１０３．００」から第２の時刻（例えば第１の時刻よりも将来の或る時刻）に変わった場合、解析・可視化プログラム１９５は、ＤＢ処理情報２４００を基に、ラディカルツリーの表示を、図３０に示した表示から図３１に示す表示に変更することができる。

また、データ構造可視化ツリーの一変形例として、ラディカルツリーが採用されても良い。

また、前述した鉛直方向は、第１方向の一例で良く、前述した水平方向は、第２方向（例えば第１方向と直行する方向）の一例で良い。

また、タスク挙動及びデータ構造（或いはデータベース）の可視化の少なくとも一方について、上述したようなツリー以外の種類の表示、例えば、A Tree Visualization Reference IEEE Computer Graphics and
Applications, Vol. 31, No. 6. (November 2011), pp. 11-15.で述べられているような各種の可視化が採用されても良い。

以上、幾つかの実施例を説明したが、本発明は、上述した実施例に限らず、種々の態様で実施することが可能である。例えば、上述の説明を基に、下記のような解析システムを導き出すことができる。
複数の記憶媒体を有する記憶装置に記憶されているデータベースに対するクエリの処理においてオペレーションを実行するためのタスクを動的に生成し動的に生成されたタスクを並列に実行するデータベース管理システム（ＤＢＭＳ）の挙動を解析する解析システムであって、
記憶資源と、
前記記憶資源に接続されたプロセッサと
を有し、
前記ＤＢＭＳは、タスクの変化後の状態とそのときの時刻とを含んだレコードの集合であるイベント情報を生成し、
前記プロセッサは、
前記イベント情報を、前記ＤＢＭＳを実行する計算機から取得し、前記イベント情報を前記記憶資源に格納し、
前記イベント情報を基に、タスクを表すオブジェクトであるタスクオブジェクトを描画し、且つ、前記タスクオブジェクトの表示態様を、前記タスクオブジェクトのタスクの状態に応じた表示態様にする、
解析システム。

解析システムは、前記イベント情報の全部又は一部の２以上のレコードを時系列に参照し、前記タスクオブジェクトの表示態様を、前記タスクオブジェクトのタスクの変化後の状態に応じた表示態様に変更することができる。ここで言う「時系列」は、レコードにおける時刻が旧い順（順方向）であってもレコードにおける時刻が新しい順（逆方向）であっても良い。

前記イベント情報は、どのタスクがどのタスクにより生成されたかを表す情報を含んでいて良い。解析システムは、前記イベント情報を基に、タスクオブジェクトとタスクオブジェクトとを結ぶ、タスクの生成関係を表すエッジを描画しても良い。

１００、１８０…計算機、１４０、１４２…ネットワーク、１４４…ディスプレイ、１５０…ストレージ装置、１１２…ＯＳ、１２０…ＤＢＭＳ、１５４…コントローラ、１７０…制御プログラム、１９５…解析・可視化プログラム、１３２…ＤＢモニタ情報出力部、１１８…ＯＳモニタ情報出力部、１７４…ＳＴモニタ情報出力部。

Claims (25)

1. 複数の記憶媒体を有する記憶装置に記憶されているデータベースに対するクエリの処理においてオペレーションを実行するためのタスクを動的に生成し動的に生成されたタスクを並列に実行するデータベース管理システム（ＤＢＭＳ）の挙動を解析する解析システムであって、
   記憶資源と、
   前記記憶資源に接続されたプロセッサと
   を有し、
   前記記憶資源は、
   前記ＤＢＭＳにおける前記クエリに対する最大のスレッド数を特定可能なスレッド数特定情報と、前記ＤＢＭＳの前記記憶装置とのインタフェースにおける並列実行可能な第１入出力処理数を特定可能な第１処理数特定情報と、前記記憶装置における前記記憶媒体に対する並列実行可能な第２入出力処理数を特定可能な第２処理数特定情報と、各前記記憶媒体が並列実行可能な第３入出力処理数を特定可能な第３処理数特定情報とを記憶し、
   前記プロセッサは、
   前記ＤＢＭＳからクエリに関する索引キーのキー値に対応する選択行数を取得し、
   前記選択行数と、前記スレッド数特定情報により特定される最大のスレッド数と、前記第１処理数特定情報により特定される第１入出力処理数と、前記第２処理数特定情報により特定される第２入出力処理数と、前記第３処理数特定情報により特定される第３入出力処理数とに基づいて、前記クエリに対応する処理におけるモデルに基づき予測した処理並列度である処理並列度モデル予測値を算出し、
   前記クエリに対応する処理を実際に実行した際の前記記憶媒体に対する入出力イベントに関するイベント情報を前記記憶装置から取得し、
   前記イベント情報に基づいて、前記クエリに対応する処理を実際に実行した際の処理並列度である処理並列度実測値を算出し、
   前記処理並列度モデル予測値と、前記処理並列度実測値とに基づいた情報を表示させる制御を行う
   解析システム。
2. 前記プロセッサは、
   前記処理並列度モデル予測値と、前記処理並列度実測値とを比較可能なグラフを表示させる制御を行う
   請求項１に記載の解析システム。
3. 前記ＤＢＭＳを実行する計算機は、データ読み出しする際のランダム入出力に係る時間を特定可能な入出力時間情報を記憶しており、
   前記プロセッサは、
   前記計算機から、前記入出力時間情報を取得し、
   前記入出力時間情報に基づいて、前記処理並列度モデル予測値の前記クエリにおける時間変化を決定し、
   前記イベント情報に基づいて、前記処理並列度実測値の時間変化を特定し、
   前記処理並列度モデル予測値と、前記処理並列度実測値とを時間変化のグラフとして表示させる
   請求項２に記載の解析システム。
4. 前記プロセッサは、
   前記クエリに対応するデータを格納する記憶媒体数を特定し、
   前記最大のスレッド数と、前記第１入出力処理数と、前記第２入出力処理数との中で、値が最も低いものを特定し、当該特定したものを前記記憶媒体数で除算して、処理並列度モデル予測値候補として決定し、
   前記処理並列度モデル予測値候補と、前記第３入出力処理数とで値が低い方を前記処理並列度モデル予測値に決定する
   請求項１に記載の解析システム。
5. 前記ＤＢＭＳは、
   前記クエリが複数の部分クエリから構成される場合に、前記クエリを、複数の部分クエリに分割して、各部分クエリを実行するようになっており、
   前記プロセッサは、
   前記各部分クエリ毎に、前記処理並列度モデル予測値及び前記処理並列度実測値を算出する
   請求項１に記載の解析システム。
6. 前記処理並列度モデル予測値及び前記処理並列度実測値は、前記記憶媒体のタグ数を示す値である
   請求項１に記載の解析システム。
7. 前記プロセッサは、
   前記処理並列度モデル予測値に関するグラフ上のいずれかの位置に対する指定を受け付けた場合に、指定された前記位置に対応する時間におけるクエリ及び部分クエリを特定可能な情報を表示させる
   請求項１に記載の解析システム。
8. 前記記憶媒体は、ディスク装置であり、
   前記スレッド数特定情報は、前記クエリ処理を実行するＤＢＭＳにおけるカーネルスレッド数と、１カーネルスレッド当りのタスク数とを含み、
   前記第１処理数特定情報は、前記ＤＢＭＳが稼動する計算機のＩ／Ｏパス上のキュー長と、前記インタフェースのポート数及び１ポートあたりの同時入出力処理数と、ネットワークの帯域に関する情報とを含み、
   前記第２処理数特定情報は、前記記憶装置のストレージコントローラの数と、１ストレージコントローラあたりの同時入出力処理数を含み、
   前記第３処理数特定情報は、１ディスク装置の同時入出力処理数を含む
   請求項１に記載の解析システム。
9. 前記プロセッサは、
   前記計算機システムにおける前記クエリに対応する処理に関与する複数の要素におけるイベント情報を取得し、
   前記各要素における前記イベント情報に基づいて、前記各要素における前記クエリに対応する処理実行時における入出力処理の滞留数を検出する
   前記要素における滞留数を表示させる
   請求項１に記載の解析システム。
10. 前記プロセッサは、
    前記要素の前記滞留数を時系列のグラフとして表示させる
    請求項９に記載の解析システム。
11. 前記プロセッサは、
    各前記記憶媒体についての前記処理並列度モデル予測値及び前記処理並列度実測値を求め、前記各記憶媒体について、前記処理並列度実測値が前記処理並列度モデル予測値に適合する範囲であるか否かを特定し、
    前記処理並列度実測値が前記処理並列度モデル予測値に適合する範囲から外れている記憶媒体の数を特定可能なグラフを表示させる
    請求項１に記載の解析システム。
12. 前記プロセッサは、
    各前記記憶媒体についての前記処理並列度モデル予測値及び前記処理並列度実測値を求め、前記各記憶媒体について、前記処理並列度実測値が前記処理並列度モデル予測値に適合する範囲であるか否かを特定し、
    前記各記憶媒体について、前記処理並列度実測値が前記処理並列度モデル予測値に適合する範囲であるか否かを特定可能な形態の図を表示させる
    請求項１に記載の解析システム。
13. 前記プロセッサは、
    前記各記憶媒体について、前記クエリに対応する処理の実行時間に占める前記処理並列度実測値が前記処理並列度モデル予測値に適合する範囲から外れた時間の割合である不適合率を算出し、
    前記不適合率の高い順に複数の記憶媒体の情報を表示させる
    請求項１に記載の解析システム。
14. 前記ＤＢＭＳは、タスクの変化後の状態とそのときの時刻とを含んだレコードの集合であるイベント情報を生成し、
    前記プロセッサは、
    （Ａ）前記イベント情報を、前記ＤＢＭＳを実行する計算機から取得し、前記イベント情報を前記記憶資源に格納し、
    （Ｂ）前記イベント情報を基に、タスクを表すオブジェクトであるタスクオブジェクトを描画し、且つ、前記タスクオブジェクトの表示態様を、前記タスクオブジェクトのタスクの状態に応じた表示態様にする、
    請求項１に記載の解析システム。
15. 前記イベント情報は、各タスクがどのタスクの実行によって生成されたかを表す情報と、あるタスクの実行によって生成された一つ、または複数のタスクの生成順序を表す情報とを含み、
    前記タスクオブジェクトは、ノードであり、
    前記（Ｂ）では、前記プロセッサは、各タスクの生成関係と生成順序とを表すエッジをノード間に有するグラフを描画する、
    請求項１４に記載の解析システム。
16. 前記（Ｂ）では、前記プロセッサは、前記タスクオブジェクトを、タスクの状態に応じて異なった表示様態で描画し、
    ユーザが指定したタスクに関して、タスクがアクセスしているＤＢのオブジェクトに関する情報等の詳細な情報を表示する、
    請求項１４に記載の解析システム。
17. 前記（Ｂ）では、前記プロセッサは、前記イベント情報の全部又は一部の２以上のレコードを時系列に参照することに伴うタスク状態の変化に従い、前記タスクオブジェクトの表示態様を経時的に変化させる、
    請求項１４に記載の解析システム。
18. 前記（Ｂ）では、前記プロセッサは、ユーザの指示によって、前記タスクオブジェクトの全てを表示する表示形態と、
    前記タスクオブジェクトの一部を拡大して表示する表示形態とを切り替えることができる
    請求項１４に記載の解析システム。
19. 前記ＤＢＭＳを実行する計算機は、前記データベースのデータ構造のサマリを表すデータ構造サマリ情報を記憶し、
    前記イベント情報のレコードが、当該レコードに対応するタスクのアクセス先のページのＩＤを含んでおり、
    前記プロセッサは、
    （Ｃ）前記データ構造サマリ情報を、前記計算機から取得し、前記データ構造サマリ情報を前記記憶資源に格納し、
    （Ｄ）前記データ構造サマリ情報に基づき、データが格納されている領域であるページを表すオブジェクトであるページオブジェクトを描画し、且つ、前記ページオブジェクトの表示態様を、前記ページにアクセスするタスクの状態に応じた表示態様にする、
    請求項１４に記載の解析システム。
20. 前記ページオブジェクトはノードであり、
    前記（Ｄ）で、前記プロセッサは、前記データベースのデータ構造毎に、ページ間の依存関係を表すエッジをノード間に有するグラフを描画する、
    請求項１９に記載の解析システム。
21. 前記（Ｄ）で、前記プロセッサは、前記ページオブジェクトを、ページへのアクセスの状態に応じて異なった表示様態で描画し、
    ユーザが指定したページに関して、ページの論理・物理アドレス等の詳細な情報を表示する、
    請求項１９に記載の解析システム。
22. 前記（Ｄ）では、前記プロセッサは、前記イベント情報の全部又は一部の２以上のレコードを時系列に参照することに伴うタスク状態の変化に従い、前記ページオブジェクトの表示態様を経時的に変化させる、
    請求項１９に記載の解析システム。
23. 前記（Ｄ）では、前記プロセッサは、ユーザの指示によって、前記ページオブジェクトの全てを表示する表示形態と、
    前記ページオブジェクトの一部を拡大して表示する表示形態とを切り替えることができる
    請求項１９に記載の解析システム。
24. 複数の記憶媒体を有する記憶装置に記憶されているデータベースに対するクエリの処理においてオペレーションを実行するためのタスクを動的に生成し動的に生成されたタスクを並列に実行するデータベース管理システム（ＤＢＭＳ）を実行する計算機と、
    前記ＤＢＭＳの挙動を解析する解析システムと
    を有し、
    前記解析システムは、記憶資源と、前記記憶資源に接続されたプロセッサとを含み、
    前記記憶資源は、
    前記ＤＢＭＳにおける前記クエリに対する最大のスレッド数を特定可能なスレッド数特定情報と、前記ＤＢＭＳの前記記憶装置とのインタフェースにおける並列実行可能な第１入出力処理数を特定可能な第１処理数特定情報と、前記記憶装置における前記記憶媒体に対する並列実行可能な第２入出力処理数を特定可能な第２処理数特定情報と、各前記記憶媒体が並列実行可能な第３入出力処理数を特定可能な第３処理数特定情報とを記憶し、
    前記プロセッサは、
    前記ＤＢＭＳからクエリに関する索引キーのキー値に対応する選択行数を取得し、
    前記選択行数と、前記スレッド数特定情報により特定される最大のスレッド数と、前記第１処理数特定情報により特定される第１入出力処理数と、前記第２処理数特定情報により特定される第２入出力処理数と、前記第３処理数特定情報により特定される第３入出力処理数とに基づいて、前記クエリに対応する処理におけるモデルに基づき予測した処理並列度である処理並列度モデル予測値を算出し、
    前記クエリに対応する処理を実際に実行した際の前記記憶媒体に対する入出力イベントに関するイベント情報を前記記憶装置から取得し、
    前記イベント情報に基づいて、前記クエリに対応する処理を実際に実行した際の処理並列度である処理並列度実測値を算出し、
    前記処理並列度モデル予測値と、前記処理並列度実測値とに基づいた情報を表示させる制御を行う
    計算機システム。
25. 複数の記憶媒体を有する記憶装置に記憶されているデータベースに対するクエリの処理においてオペレーションを実行するためのタスクを動的に生成し動的に生成されたタスクを並列に実行するデータベース管理システム（ＤＢＭＳ）の挙動を解析する解析方法であって、
    前記ＤＢＭＳからクエリに関する索引キーのキー値に対応する選択行数を取得し、
    前記選択行数と、前記スレッド数特定情報により特定される最大のスレッド数と、前記ＤＢＭＳの前記記憶装置とのインタフェースにおける並列実行可能な第１入出力処理数と、前記記憶装置における前記記憶媒体に対する並列実行可能な第２入出力処理数と、前記記憶媒体が並列実行可能な第３入出力処理数とに基づいて、前記クエリに対応する処理におけるモデルに基づき予測した処理並列度である処理並列度モデル予測値を算出し、
    前記クエリに対応する処理を実際に実行した際の前記記憶媒体に対する入出力イベントに関するイベント情報を取得し、
    前記イベント情報に基づいて、前記クエリに対応する処理を実際に実行した際の処理並列度である処理並列度実測値を算出し、
    前記処理並列度モデル予測値と、前記処理並列度実測値とに基づいた情報を表示させる制御を行う解析方法。