JP2016162016A - 管理情報取得プログラム、管理情報取得方法及び管理情報取得装置 - Google Patents

Abstract

【課題】ウエブサービスのデータベースの構成情報がなくても、データベースから必要なデータを抽出する管理情報取得プログラムを提供する。
【解決手段】管理対象サービスシステムのデータベースに対するクエリを取得し、取得したクエリに含まれる対象テーブルとクエリの内容に基づいてデータベースに含まれる参照対象テーブルを特定し、参照対象テーブルのデータに基づいて報告対象テーブルを特定し、報告対象テーブルに対する取得クエリを前記データベースに実行させ報告対象テーブルから所望の管理情報を取得し出力する、処理を実行させるコンピュータ読み取り可能な管理情報取得プログラム。
【選択図】図４

Description

本発明は，管理情報取得プログラム、管理情報取得方法及び管理情報取得装置に関する。

サービスシステムは、インターネットやイントラネットのウエブサイトで多数のユーザに対して所定のサービスを提供する。このようなサービスシステムでは、情報処理装置（以下単にサーバと称する。）が、サービスのアプリケーションプログラム（以下サービスアプリケーションと称する。）と、ユーザ端末とサーバとの間のアクセス処理等を行うウエブサービスのアプリケーションプログラム（以下ウエブアプリケーションと称する。）を実行する。

ウエブアプリケーションの性能は、サービスシステムのサービス品質を高める一つの要因である。したがって、様々な性能を調べて改善することが、サービスシステムのサービス品質の向上につながる。

ウエブアプリケーションの様々な性能には、例えば、アクセスに対するレスポンス速度や、アクセスの集中に対してハングアップしないアクセス集中に対するサーバの耐性（サーバがダウンしない程度）などがある。レスポンス速度が遅いことや、アクセスの集中に対してサーバの耐性が低いことが、サービス品質の低下を招く。

一方で、クラウドコンピューティングサービス（以下単にクラウドサービス）の普及により、コンピュータのインフラが安価で容易に利用可能になってきた。それに伴い、クラウドサービスのインフラを利用して、サービスシステムを構築することが行われる。そして、サービスシステムは、クラウドサービスで提供されるウエブアプリケーションを利用する場合がある。そのため、サービスシステムの運用管理者とは異なるクラウドサービスの運用管理者が、ウエブアプリケーションの性能分析を行い、分析結果に基づいてウエブアプリケーションの性能改善を行うことがある。

ウエブアプリケーションの性能分析には、例えば、ウエブアプリケーションのデータベースのデータを参照する必要がある。例えば、ウエブアプリケーションの性能の一つであるレスポンス速度が遅い場合、レスポンス速度が遅い国や企業または接続地域の顧客数に基づいて、レスポンス速度改善の優先順位を定める。その場合、データベースから国や企業または接続地域毎の顧客数を取得することが必要になる。

そこで、データベースから必要なデータを抽出するためのクエリを作成し、データベースにそのクエリを実行させて必要なデータを抽出する。かかる技術については、以下の特許文献に記載されている。

特開平１１−００３２５７号公報 特開平０８−１３７８１０号公報 特開２０１１−２２１８６１号公報 特開２０１２−０１４２６７号公報

しかしながら、ウエブアプリケーションの性能を収集し管理するクラウドサービスの運用管理サーバは、サービスシステムを提供するサーバとは異なる。そして、クラウドサービスの運用管理者は、必ずしも、サービスシステムのデータベースの構成を入手できるとは限らないし、一般にデータベースの生データを取得することは許可されない。

そこで，実施の形態の第１の側面の目的は，ウエブサービスのデータベースの構成情報がなくても、データベースから必要なデータを抽出する管理情報取得プログラム、管理情報取得方法及び管理情報取得装置を提供することにある。

実施の形態の第１の側面は，
管理対象サービスシステムのデータベースに対するクエリを取得し、
前記取得したクエリに含まれる対象テーブルと前記クエリの内容に基づいて、前記データベースに含まれる参照対象テーブルを特定し、
前記参照対象テーブルのデータに基づいて、報告対象テーブルを特定し、
前記報告対象テーブルに対する取得クエリを前記データベースに実行させ、前記報告対象テーブルから所望の管理情報を取得し、出力する
処理を実行させるコンピュータ読み取り可能な管理情報取得プログラムである。

実施の形態の第１の側面によれば，データベースから必要なデータを抽出することができる。

サービスシステムのレスポンス性能について説明する図である。 レスポンス性能が収集されたレスポンス性能テーブルの一例を示す図である。 管理サーバとサービスシステムとの関係例を示す図である。 第１の実施の形態における管理サーバとサービスシステムの構成例を示す図である。 第１の実施の形態におけるサービスシステムと管理サーバの別の構成例を示す図である。 図５の各物理マシン１、２、３と管理サーバ３４の構成を示す図である。 第１の実施の形態における管理情報取得プログラムの処理を示すフローチャート図である。 第２の実施の形態における管理サーバとサービスシステムの構成例を示す図である。 第２の実施の形態における優先度情報取得エージェント３７の概略処理を示すフローチャート図である。 管理サーバの性能改善分析情報生成部３４２による処理のフローチャート図である。 クエリ情報の収集工程S20の詳細フローチャート図である。 マスターデータテーブルの特定処理S22の詳細なフローチャート図である。 テーブル分析部によるユーザテーブルの特定処理S23の詳細なフローチャート図である。 テーブル分析部による国データテーブルの特定処理S24の詳細なフローチャート図である。 取得クエリ作成部による国別ユーザ数取得クエリの作成S26の詳細フローチャート図である。 結合情報探索関数のフローチャート図である。 ユーザテーブルと国コードテーブルとが他のテーブルを介した関係を有する例を示す図である。 優先度情報取得部３７４による優先度情報である国別ユーザ数取得処理S28の詳細フローチャート図である。 性能改善分析情報データベースの生成処理S29の詳細なフローチャート図である。 業務データベースに含まれるユーザテーブルuserとアカウントテーブルaccountの一例を示す図である。 業務データベースに含まれる国データテーブルcountryと役割テーブルroleの一例を示す図である。 業務データベースに含まれる売上データテーブルsalesとオーダテーブルorderと製品テーブルproductの一例を示す図である。 管理サーバ３４が保持する性能情報データベース３４３内のレスポンス性能テーブルの一例を示す図である。 クエリ情報テーブル３７５＿１の一例を示す図である。 テーブル分析情報テーブルの一例を示す図である。 第２の実施の形態における国別ユーザ数情報取得クエリの例を示す図である。 取得クエリにより取得した国別ユーザ数を有する国別ユーザ数情報テーブルの一例を示す図である。 図２４の４行目のクエリの演算処理を示す図である。 性能改善分析情報テーブルの一例を示す図である。

本実施の形態では、管理対象のサービスシステムとして、ウエブサイトにウエブサービスを提供するサーバ（ウエブサーバ）を設け、インターネットやイントラネットを介して世界中の複数のユーザからアクセスされ所定のサービスを提供するサービスシステムを例にして説明する。このウエブサーバのウエブアプリケーションの性能は、例えばユーザ端末がウエブサーバにアクセスしてから応答を受信するまでのレスポンス速度であり、このレスポンス速度を改善するために収集したい管理情報は、例えば国毎、企業毎または接続地域毎のユーザ数である。

図１は、サービスシステムのレスポンス性能について説明する図である。ウエブサーバ３０は、ウエブアプリケーション３１を実行して、複数の国の複数のユーザ端末４０＿Ａ〜４０＿Ｃに所定のウエブサービスを提供する。また、ウエブサーバ３０は、業務データベース３３を利用してユーザにウエブサービスを提供する。業務データベース３３は、例えば、ユーザテーブルや商品データテーブルなどのマスターデータテーブルと、購入データテーブルや入出金データテーブルなどのトランザクションデータテーブルなどを有する。

一方、管理サーバ３４は、ウエブアプリケーション３１のレスポンス性能（レスポンス速度）を収集する。そのために、レスポンス性能収集用エージェント（プログラム）３２が、ウエブサーバ３０にインストールされる。また、管理サーバ３４にレスポンス性能収集用マネージャ（プログラム）がインストールされる。

図１に示されるとおり、Ａ国のユーザ端末４０＿Ａ、Ｂ国のユーザ端末４０＿Ｂ、Ｃ国のユーザ端末４０＿Ｃが、ウエブサーバ３０にアクセスして所定のリクエストを送信し（Ｓ１）、ウエブサーバ３０はウエブアプリケーション３１を実行して、リクエストに対するレスポンスを返信する（Ｓ２）。このレスポンスは通常ＨＴＭＬ言語で記述されたファイルであり、ユーザ端末４０のブラウザはそのＨＴＭＬファイルを実行してレスポンス画面を生成する。

レスポンス性能であるレスポンス速度を計測するために、ウエブサーバ３０のレスポンス性能収集用エージェント３２は、レスポンスのＨＴＭＬファイルにレスポンス速度を計測するスクリプトを埋め込む。そして、ユーザ端末４０のブラウザがレスポンスのＨＴＭＬファイルに埋め込まれたスクリプトを起動し、起動したスクリプトがブラウザからレスポンス性能の情報を収集し、管理サーバ３４に送信する。

管理サーバ３４は、クラウドサービスの運用者によって管理されている。管理サーバ３４のレスポンス性能収集用マネージャ３５は、受信したレスポンス性能情報を収集する。これにより、クラウドサービスの運用者は、管理サーバ３４のレスポンス性能収集マネージャ３５により、ウエブサーバ３０に対して世界中のユーザが体感しているレスポンス性能（レスポンス速度）の情報を収集し、監視する。

クラウドサービスの運用者は、複数の国においてレスポンス速度が遅くなった場合、レスポンス速度を改善する必要がある。しかし、ウエブアプリケーションのレスポンス速度の低下の要因は、例えば、ネットワーク経路、連携しているウエブサービスの遅延など様々であるので、原因調査や改善には多大な工数を要する。したがって、一度に複数全ての国のレスポンス速度の改善に取り組むことは困難である。その場合、複数の国のレスポンス速度が同程度に遅い場合、性能改善のための優先度情報に基づいて、性能改善の優先度を判断する。

性能改善の優先度の候補としては、第１にリクエスト数がある。リクエスト数が多い国はレスポンス速度の遅延の影響が大きいので、リクエスト数が多い国ほど性能改善の優先度が高いと判断することができる。その場合、ウエブサーバにおける国別のリクエスト数を集計することで優先度情報を取得できる。

しかし、同じユーザが多数のリクエストを発行する場合、レスポンス速度の改善効果は一部のユーザに偏ってしまう。したがって、国別のリクエスト数は性能改善の優先度としてはあまり適切ではない。また、リクエストからユーザを識別することができる情報（例えばユーザID）は、アプリケーション毎に異なっているので、各リクエストのユーザを識別することは困難であり、同じユーザにリクエストが偏っていることを検出することは困難である。

性能改善の優先度の候補として、第２に国毎のユーザ数がある。ユーザ数が多い国はレスポンス速度の遅延の影響は大きいので、ユーザ数が多い国ほど性能改善の優先度が高いと判断できる。クラウドサービスの運用者は、この判断基準で優先度が高い国のレスポンス速度を優先的に改善することで、多くのユーザに対してサービス品質を向上できる。

しかし、図１に破線で示されるとおり、管理サーバ３４は、業務データベース３３に直接アクセスすることは許されない場合がある。また、管理サーバ３４を管理するクラウドサービスの運用者は、業務データベース３３の構造情報を知ることはできないので、業務データベース３３にアクセスして国毎のユーザ数を取得することは容易ではない。

図２は、レスポンス性能が収集されたレスポンス性能テーブルの一例を示す図である。図１で説明した方法で、管理サーバ３４は、図２に示すように国別のレスポンス性能（レスポンス速度）を収集する。しかし、図２の例では、「アメリカ」「ドイツ」「日本」のレスポンス速度が同程度に遅いことは判明したが、その性能改善の優先度である国毎のユーザ数は取得できていない。したがって、「アメリカ」「ドイツ」「日本」のいずれの国から性能改善に取り組むべきかの判断ができない。

図３は、管理サーバとサービスシステムとの関係例を示す図である。図３の例では、Ａ社システム２２が、商品購入サービスを提供するサービスシステム２０＿１と、Ａ社情報サービスを提供するサービスシステム２０＿２とを有する。それぞれのサービスシステム２０＿１，２０＿２は、ウエブサーバ３０＿１，３０＿２とアプリケーションサーバ３６＿１，３６＿２とを有する。そして、各ウエブサーバ３０＿１，３０＿２は、複数のユーザ端末４０からアクセスされ、所定のリクエストを受信し、リクエストに応答するレスポンスを返信する。また、ウエブサーバ３０＿１，３０＿２は、それぞれのアプリケーションサーバ３６＿１，３６＿２を介して、業務データベース３３にクエリを発行して所望の情報を取得または登録する。取得した情報は、例えばレスポンスに反映される。

一方、管理サーバ３４は、Ａ社システムのネットワークの外のネットワークに設置されるため、図３中破線で示されるように、管理サーバ３４が業務データベース３３に直接クエリを発行して所望の情報を直接取得することは許可されない場合がある。さらに、管理サーバ３４が、業務データベース３３の構造情報を事前に取得することもできない場合がある。したがって、管理サーバ３４が、業務データベース３３から所望の情報を取得することは容易ではない。

そのため、管理サーバ３４が、管理サービスとしてウエブサーバ３０のレスポンス性能を監視する場合、図１で説明した仕組みで国毎のレスポンス速度を集計することはできるが、前述の優先度情報として国毎のユーザ数を業務データベース３３から取得することは困難である。

仮に、優先度情報を収集するエージェント（プログラム）をＡ社システム２２内にインストールすることが許されたとしても、業務データベースの構造情報を入手できない状況下では、エージェントに所望の優先度情報を業務データベース３３から取得することは困難である。さらに、エージェントが業務データベース３３の生データをそのまま管理サーバ３４に渡すことは許可されない。

［第１の実施の形態］
図４は、第１の実施の形態における管理サーバとサービスシステムの構成例を示す図である。図３と異なる構成は、管理サーバ３４と連携する管理情報取得エージェント（プログラム）３７がＡ社システム２２にインストールされていることである。管理情報取得エージェント３７は、業務データベース３３に対する複数のクエリを分析して、業務データベース３３が有するテーブル類を特定し、特定したテーブル情報に基づいて所望の管理情報を取得する取得クエリを生成し、その取得クエリにより所望の管理情報を業務データベース３３から取得する。そして、管理情報取得エージェント３７は、取得した管理情報を管理サーバ３４に提供する。

これにより、管理サーバ３４は、レスポンス性能を収集すると共に、管理情報取得エージェント３７が業務データベース３３から収集した管理情報を収集することができる。管理情報は、例えば、図１の例で示した国毎のユーザ数である性能改善優先度情報である。

図５は、第１の実施の形態におけるサービスシステムと管理サーバの別の構成例を示す図である。図５は、サーバファシリティ（またはデータセンタ）を示す。サーバファシリティは、複数の仮想マシンVMをハイパーバイザHV上で実行する複数の物理マシン（またはVMホスト、ホストマシン）１、２、３と、物理マシン及び仮想マシンを管理する管理サーバ３４と、ストレージ９とを有する。サービスシステムは、多数の物理マシンが配備されたサーバファシリティ内に構築される。サーバファシリティは、物理マシンなどのハードウエアリソースを利用者に提供することで、クラウドコンピューティングサービスを提供する。

各物理マシン１、２、３は、ハイパーバイザHVを実行して、複数の仮想マシンVMを起動し実行する。つまり、ハイパーバイザHVが仮想マシンVMを起動し実行する。ストレージ９は、仮想マシンVMのゲストOS(Operating System)やアプリケーションプログラムなどを有するイメージファイルを記憶する。仮想マシンVMは、ストレージ９内に格納されたイメージファイルのゲストOSとアプリケーションプログラムを、物理マシン１，２，３のメモリに展開し、メモリに展開したゲストOSとアプリケーションプログラムを実行し、所望のサービスシステムを構築する。

管理サーバ３４の管理プログラム３４＿１は、ハイパーバイザHVにコンフィグレーション情報に基づく仮想マシンを起動させ、必要に応じて仮想マシンを一時停止（ポーズ）及び再開（リジューム）させ、遮断させる。コンフィグレーション情報は、仮想マシンVMに割り当てるCPUコア数とメモリ容量の情報などを有する。

サービスシステムを構成するウエブサーバとアプリケーションサーバ（図示せず）は、仮想マシンVMと仮想マシンのネットワークVM_NWとストレージ９とにより構成される。仮想マシンVMで構成されるウエブサーバは、ネットワークVM_NWを介してユーザ端末４０と接続可能になる。また、ストレージ９は、例えば業務データベースの情報を格納する。そして、仮想マシンVMで構成されるデータベースサーバ（図示せず）は、ストレージ９内の業務データベースの情報と連携して業務データベースを構築する。

本実施の形態では、管理プログラム３４＿１は、さらに、仮想マシンVMで構成されたサービスシステムのウエブサーバのレスポンス性能を収集するレスポンス性能収集用マネージャを有する。また、管理プログラム３４＿１は、管理情報取得エージェント（プログラム）をサービスシステムにインストールするインストールプログラムと、そのサービスシステムにインストールした管理情報取得エージェント（プログラム）に所望の管理情報を取得させ、その管理情報を受信して所定の分析情報を生成する分析情報生成プログラムなどを有する。上記の管理情報取得プログラムは、例えば、図５のストレージ９に格納され、仮想マシンVMで構成されたサービスシステム内のデータベースサーバにより実行される。

また、管理サーバ３４の管理プログラム３４＿１は、仮想マシンで構築されたサービスシステムを運用するクラウドユーザ端末６にポータルサイト３４＿２を提供する。クラウドユーザ端末６は外部のネットワークEX_NWを介してポータルサイト３４＿２にアクセスし、サービスシステムの維持管理を行う。

各物理マシン１、２、３と管理装置３４とストレージ９は、管理ネットワークM_NWを介して通信可能にされる。サーバファシリティの運用管理者端末７は、例えば管理ネットワークM_NWを介して管理サーバ３４にアクセス可能である。また、クラウドユーザ端末６は、ポータルサイト３４＿２を介して管理サーバ３４にアクセスし、仮想マシンの新たな起動や遮断などを要求する。

図６は、図５の各物理マシン１、２、３と管理サーバ３４の構成を示す図である。物理マシン１、２、３と管理サーバ３４は、演算処理装置であるCPU１０と、メモリであるRAM１２と、ROM１３と、物理ネットワークインターフェース１４と、入出力部１５と、ハードディスクなどの大容量記憶装置１６とを有する。そして、それらはバス１８を介して接続される。

物理マシン１、２、３の場合、大容量記憶装置１６は、例えばOSやハイパーバイザHVなどを格納する。管理サーバ３４の場合、大容量記憶装置１６は、例えばOSと管理プログラム３４＿１などを記憶する。そして、大容量記憶装置１６に格納されているOSやソフトウエアはメモリであるRAM１２内に展開され、各CPUコアにより実行される。

図７は、第１の実施の形態における管理情報取得プログラムの処理を示すフローチャート図である。管理情報取得プログラムは、図４に示した管理情報取得エージェントであり、データベースサーバ（図示せず）にインストールされ、実行され、次のような処理を実行する。

管理情報取得プログラムは、データベースに対するクエリを収集する（S10）。データベースに対するクエリの例については後で詳述する。データベースに対するクエリは、例えばSQL文（SQL：Structured Query Language）である。クエリの一例は、データベース内の所定のテーブルのデータを取得するセレクト（SELECT）、所定のテーブルにデータを登録するインサート（INSERT）、所定のテーブルの所定のデータを更新するアップデート（UPDATE）などである。

また、データベースのテーブルの例は、マスターデータを格納するテーブルであり、セレクトにより参照されることが多い参照対象テーブルと、トランザクションデータを格納するテーブルであり、インサートやアップデートによりデータが登録、更新される非参照対象テーブルなどである。マスターデータは、業務アプリケーションで共通して使用されるデータであり、あまり更新されず固定的なデータである。したがって、マスターデータのテーブルは、参照回数が登録や更新回数より多いテーブルである。トランザクションデータは、業務に伴って発生し記録されるデータであり、業務処理に伴い増加するデータである。トランザクションデータのテーブルは、登録や更新回数が参照回数と同程度または参照回数より多いテーブルである。

次に、管理情報取得プログラムは、クエリの対象テーブルとクエリ内容に基づいて、データベース内の参照対象テーブルを特定する（S11）。前述のクエリの例で説明すると、管理情報取得プログラムは、セレクトの対象テーブルになる回数（参照回数）が、インサートやアップデートの対象テーブルになる回数（登録回数、更新回数）よりも多いテーブルを、参照対象テーブルと判断する。管理情報取得プログラムは、インサートやアップデートの対象テーブルになる回数（登録回数、更新回数）が、セレクトの対象テーブルになる回数（参照回数）と同程度またはより多いテーブルを、非参照対象テーブルと判断する。

次に、管理情報取得プログラムは、特定された参照対象テーブルから管理情報を有する報告対象テーブルを特定する（S12）。この報告対象テーブルの特定は、例えば、データベース３３内の参照対象テーブルのデータをセレクトで抽出し、そのテーブルが有するデータが管理情報や報告対象テーブルに固有のデータに該当するか否かで行うことができる。

そして、管理情報取得プログラムは、報告対象テーブルから所望の管理情報を取得する取得クエリを作成する。この取得クエリは、例えば報告対象テーブルを対象とするセレクトである。管理情報プログラムは、工程S10で収集した複数のクエリを分析して、報告対象テーブルの構造を認識し、その認識した構造に基づいて取得クエリを生成する。所望の管理情報を取得するために、複数の報告対象テーブルを参照対象テーブルとするセレクトの取得クエリが必要な場合がある。その場合は、工程S10で収集した複数のクエリに含まれる結合情報（インナージョイン句（INNER JOIN））を分析し、取得クエリであるセレクト文を生成する。具体例は後述する。

最後に、管理情報取得プログラムは、取得クエリをデータベースに実行させて、所望の管理情報を取得する（S14）。そして、管理情報取得プログラムは、取得した管理情報を、管理サーバに提供する。

第１の実施の形態によれば、サービスシステムのデータベースサーバに管理情報取得エージェント（管理情報取得プログラム）をインストールし、管理情報取得エージェントがデータベースに対するクエリを収集し分析する。管理情報取得エージェントは、クエリを分析することで、データベース内の参照対象テーブルを特定し、さらに報告対象テーブルを特定し、報告対象テーブルからデータを取得する取得クエリを生成する。そして、管理情報取得エージェントは、その取得クエリをデータベースに実行させて所望の管理情報を取得する。

したがって、管理サーバがサービスシステム内のデータベースに直接アクセスせず、データベースの構造を事前に取得することなく、サービスシステムのデータベースから所望の管理情報を取得することができる。管理情報取得エージェントは、データベースの生データをそのまま管理サーバに供給するのではなく、管理サーバが必要とする所望の管理情報だけを取得して管理サーバに提供する。

［第２の実施の形態］
第２の実施の形態では、第１の実施の形態における所望の管理情報と管理情報取得エージェントは、それぞれ、図１，２で説明したウエブサーバのレスポンス性能を改善するための優先度情報と優先度情報取得エージェント（優先度情報取得プログラム）である。第２の実施の形態では、優先度情報取得プログラムが性能改善の優先情報を業務データベースから取得することを例にして、より具体的に説明する。そして、第２の実施の形態では、参照対象テーブルはマスターデータテーブルであり、報告対象テーブルはユーザテーブルと国データテーブルであり、優先度情報は国毎のユーザ数である。

図８は、第２の実施の形態における管理サーバとサービスシステムの構成例を示す図である。図４に示した第１の実施の形態と同様に、ユーザシステム２２は、ウエブサーバ３０と、データベースサーバ３３とを有する。そして、管理サーバ３４は、ウエブサーバのレスポンス性能を収集し、性能改善の優先度情報を収集して性能改善分析情報を生成する。管理サーバ３４は、データベースサーバ３３に優先度情報取得エージェント（プログラム）３７をインストールする。

ウエブサーバ３０は、ユーザ端末４０からのアクセスを制御するウエブアプリケーション３１を実行し、さらに、ユーザ端末４０からのリクエストに応答するＨＴＭＬファイルにレスポンス性能情報収集のためのスクリプトを埋め込むレスポンス性能収集プラグイン３２を実行する。

ユーザ端末４０は、ブラウザ４１をインストールし、インターネットやイントラネットなどのネットワークを介してウエブサーバ３０にアクセスする。

管理サーバ３４では、レスポンス性能情報収集部３４０がユーザ端末４０からスクリプトが収集したレスポンス性能情報を受信し、性能情報データベース３４３に格納する。性能情報データベース３４３は、ウエブサーバ３０のＣＰＵやメモリなどのシステム性能の情報も格納される。

レスポンス性能分析部３４１は、性能情報データベース３４３に格納されたデータを分析して、性能改善分析情報データベース３４４を生成し、それに基づいてレスポンス性能を分析する。そして、性能改善分析情報生成部３４２は、優先度情報取得エージェント３７から送信される性能改善の優先度情報を性能改善優先度データベース３４５に格納する。さらに、レスポンス性能分析部３４１は、性能改善優先度情報を性能改善分析情報データベース３４４に登録する。

データベースサーバ３３では、データベース管理プログラム３３１が、ウエブアプリケーション３１から送信される種々のクエリを実行して、業務データベース３３２に反映しまたは参照データを返信する。また、データベースサーバ３３は、優先度情報取得エージェント３７を実行して、取得した優先度情報を管理サーバに送信する。優先度情報取得エージェント３７は、クエリを収集するクエリ情報収集部３７１と、収集したクエリに基づいて業務データベース３３８のテーブルを分析するテーブル分析部３７２を有する。さらに、優先度情報取得エージェント３７は、優先度情報を取得するクエリを生成する取得クエリ生成部３７３と、取得クエリにより業務データを検索して所望の優先度情報を取得する業務データ検索処理部３７４とを有する。これらの処理については、後で具体的に説明する。そして、優先度情報取得エージェント３７は、分析情報データベース３７５を有する。

以下、優先度情報取得エージェント（プログラム）３７による優先度情報の取得処理と、管理サーバ３４による性能改善分析情報の生成処理について、具体例を示して説明する。

まず、前提として、業務データベース３３２が有する各種のテーブル例について説明する。

図２０は、業務データベースに含まれるユーザテーブルuserとアカウントテーブルaccountの一例を示す図である。ユーザテーブルuserは、キー番号key、名前name、アドレスaddress、郵便番号postalcode、電話番号tel_num、メールアドレスemail、国コードcountryのデータを有する。アカウントテーブルaccountは、キー番号key、ユーザIDuser_id、パスワードpassword、ユーザ番号userなどの認証情報を有する。

図２１は、業務データベースに含まれる国データテーブルcountryと役割テーブルroleの一例を示す図である。国データテーブルcountryは、キー番号keyと国コードcountry_codeのデータを有する。役割テーブルroleは、キー番号keyと役割roleのデータを有する。

図２２は、業務データベースに含まれる売上データテーブルsalesとオーダテーブルorderと製品テーブルproductの一例を示す図である。売上データテーブルsalesは、キー番号keyとオーダ番号orderと支払い額paymentのデータを有する。オーダテーブルorderは、キー番号key、ユーザuser、メールアドレスemail、製品product、個数number、日付dateのデータを有する。そして、製品テーブルproductは、キー番号key、製品コードproduct_code、製品名product_name、国番号countryのデータを有する。

上記のテーブルのうち、ユーザテーブルuser、アカウントテーブルaccount、国データテーブルcountry、役割テーブルrole、製品テーブルproductは、セレクト（SELECT）により参照される回数が多い参照対象テーブルに属する。また、売上データテーブルsalesとオーダテーブルorderは、業務実行とともに発生するトランザクションデータを有するテーブルであり、非参照対象テーブルに属する。

図２３は、管理サーバ３４が保持する性能情報データベース３４３内のレスポンス性能テーブルの一例を示す図である。レスポンス性能テーブルは、国番号countryと、URLurlと、レスポンス時間response_timeと、タイムスタンプtimestampのデータを有する。URLは、ユーザ端末から送信されてきたリクエスト先の情報である。管理サーバ３４は、レスポンスのＨＴＭＬファイルに埋め込んだスクリプトが収集したレスポンス性能情報を受信し、性能情報データベース３４３内のレスポンス性能テーブルに格納する。

図９は、第２の実施の形態における優先度情報取得エージェント３７の概略処理を示すフローチャート図である。

［クエリ情報の収集S20］
優先度情報取得エージェント３７（以下単にエージェント３７）のクエリ情報収集部３７１は、業務データベース３３２に対するクエリ情報を収集し、分析情報データベース３７５内のクエリ情報テーブル３７５＿１に格納する(S20)。データベースサーバ３３のDB管理プログラム３３１は、クエリを受信し実行するとともに、受信したクエリのログを業務データベース３３２の記憶装置に格納している。したがって、クエリ情報収集部３７１は、業務データベース３３２内のクエリのログから一定時間（例えば１日）分のクエリを収集する（S21）。

図２４は、クエリ情報テーブル３７５＿１の一例を示す図である。クエリ情報テーブル３７５＿１は、クエリと、クエリ種別と、対象のテーブルと、作成日時のデータを有する。図２４の例では、５つのクエリが格納されている。各クエリは次のとおりである。

１行目のクエリは、ユーザテーブルuser内の全てのデータを出力するセレクト文である。セレクト文の次の「*」は全てのデータを意味する。クエリ種別はSELECTで、対象テーブルはuserである。

２行目のクエリは、ユーザテーブルuserの名前、メールアドレス、電話番号のコラムに、値「Suzuki Ichiro, Suzuki@sample.com,012-345-6789」をそれぞれ登録するインサート文である。つまり、ユーザテーブルにユーザ登録するクエリである。クエリ種別はINSERTで、対象テーブルはuserである。

３行目のクエリは、出荷テーブルshippingに、キー番号keyが47189の行のステータスstatusを「processed」に更新するアップデート文である。クエリ種別はUPDATEで、対象テーブルはshippingである。

４行目のクエリは、アカウントテーブルaccountと、ユーザテーブルuserと、国データテーブルcountryを結合し、アカウントテーブルのユーザID account.user_idが「mike」で、アカウントテーブルのユーザ番号account.userとユーザテーブルのキー番号user.keyとが等しく、ユーザテーブルの国番号user.countryと国データテーブルのキー番号country.keyとが等しいレコードの、国テーブルの国名country.country_codeの情報を出力するセレクト文である。クエリ種別はSELECTで、対象テーブルはアカウントテーブルaccountと、ユーザテーブルuserと、国データテーブルcountryの３つである。

図２８は、図２４の４行目のクエリの演算処理を示す図である。図２８に示されるとおり、４行目のクエリは、アカウントテーブルのユーザID account.user_idが「mike」の行に対して、account.user＝user.keyと、user.country＝country.keyの結合句(JOIN句)を介して、国データテーブルの国名country.country_codeの「DEU」を抽出することができる。

図２４の５行目のクエリは、オーダテーブルorderの製品キー番号product_keyと数numに、値「1287321」、「2」を登録するインサート文である。クエリ種別はINSERTで、対象テーブルはオーダテーブルである。

図１１は、クエリ情報の収集工程S20の詳細フローチャート図である。クエリ情報収集部３７１は、クエリ収集用プログラムを起動し、国別ユーザ数取得クエリが格納されるまでバックグランドでクエリ情報を収集してクエリ情報テーブル３７５＿１を生成する（S200）。まず、クエリ情報収集部３７１は、ウエブサーバ３０とデータベースサーバ３３間のネットワーク機器を通過する通信データまたは業務データベースで生成されたクエリログからクエリを抽出する（S201）。そして、クエリをSELECT、UPDATE、INSERTに分類し（S202）、各クエリの対象のテーブルを抽出し（S203）、クエリ情報テーブルに格納する(S204)。その結果、図２４に示したクエリ情報テーブル３７５＿１が生成される。

［マスターデータテーブルの特定S22、ユーザテーブルの特定S23、国データテーブルの特定S24］
図９に戻り、優先度情報取得プログラム３７のテーブル分析部３７２は、クエリ情報テーブル３７５＿１に収集されたクエリの対象テーブルとクエリの内容（クエリ種別）とから、もっぱらデータの参照の対象となっている参照対象テーブル、つまりマスターデータを格納するテーブル（マスターデータテーブル）を特定する（S22）。さらに、テーブル分析部３７２は、特定した複数のマスターデータテーブルの中から各テーブルのデータを参照して、ユーザテーブルを特定し（S23）、さらに、国データテーブルを特定する（S24）。

図１２は、マスターデータテーブルの特定処理S22の詳細なフローチャート図である。参照対象テーブルであるマスターデータテーブルは次のような特徴を有する。業務データベースでは、マスターデータとトランザクションデータが様々なテーブルに格納される。マスターデータは、業務アプリケーションで共通して使用されるデータであり、あまり更新されず固定的である。例えば、ユーザデータや商品データなどである。したがって、マスターデータを格納するテーブル（マスターデータテーブル、参照対象テーブル）は、セレクト文などのクエリにより参照される回数が多く、登録及び更新の回数は参照回数より少ない。

一方、トランザクションデータは、業務に伴って発生した出来事を記録したデータであり、業務処理と共に増加する。例えば、購入データや入出金データなどである。したがって、トランザクションデータを格納するテーブル（トランザクションテーブル、非参照対象テーブル）は、クエリにより参照される回数が少なく、インサート文やアップデート文などによる登録及び更新の回数が参照回数と同等かより多い。

そこで、図１２のマスターデータテーブルの特定処理S22では、上記のマスターデータテーブルとトランザクションテーブルの違いに基づいて、クエリの内容（参照か、更新及び登録か）とそのクエリが対象とするテーブルから、マスターデータテーブルを特定する。

テーブル分析部３７２は、クエリ情報から対象のテーブルの一覧を取得する（S220）。図２４の「対象のテーブル」のコラムにテーブルの一覧が格納されている。次に、テーブル分析部３７２は、一覧からテーブルを取り出し以下の処理を全てのテーブルについて行う（S221）。すなわち、テーブル分析部３７２は、取り出したテーブルについてクエリ種別別（SELECT、INSERT、UPDATE）に数を集計し（S222）、SELECTの回数（参照回数）がINSERTの回数（登録回数）より多く、または若しくは且つ、SELECTの回数がUPDATEの回数（更新回数）より多いか否か判定し（S223）、判定がYESであればマスターデータテーブル（参照対象テーブル）に指定し（S224）、判定がNOであればトランザクションデータテーブル（非参照対象テーブル）に指定する（S225）。各テーブルの判定結果が、分析情報データベース３７５内のテーブル分析情報テーブル３７５＿２に格納される。

図２５は、テーブル分析情報テーブルの一例を示す図である。図２５の左側のテーブル分析情報テーブル３７５＿２Ａでは、テーブル種別のコラムに、各テーブルについてマスターデータテーブルかトランザクションデータテーブルかの特定が行われている。

図９に戻り、テーブル分析部３７２は、マスターデータテーブルに指定されたテーブルからユーザテーブルを特定する(S23)。

図１３は、テーブル分析部によるユーザテーブルの特定処理S23の詳細なフローチャート図である。テーブル分析部３７２は、マスターデータテーブルの一覧をテーブル分析情報テーブル３７５＿２から取得する（S230）。そして、一覧からテーブルを一つ取り出し、以下の処理を全てのテーブルについて行う(S231)。すなわち、テーブル分析部３７２は、取り出したマスターデータテーブルのデータを取得し、電子メールアドレスが含まれているか確認する（S232）。そして、電子メールアドレスが含まれるテーブルが見つかれば（S233のYES）、電子メールアドレスが含まれているテーブルのうち、レコード数が最も多いテーブルをユーザテーブルと特定する（S234）。

ユーザテーブル以外のマスターデータテーブルにも電子メールアドレスが含まれるテーブルが存在するのが一般的である。例えば、組織データテーブル、配送データテーブル、請求書データテーブルなどである。

組織データは、ユーザが所属する会社や部門のデータであり、データ内容として、会社名（部門名）、本社住所、代表電話番号、代表電子メールアドレスなどが含まれる。ユーザが組織単位で登録されている場合は、この組織データがユーザデータとして扱われる。但し、ユーザデータと組織データが併存する場合は、一般にユーザデータのほうが組織データよりもデータ数が多いので、複数の電子メールアドレスを有するテーブルが見つかったら、データ数が多いテーブルをユーザテーブルと特定するのが適切である。また、ユーザデータが存在せず組織データがユーザデータとして使用されている場合は、組織データをユーザデータと見なして特定するのが好ましい。

また、配送データテーブル、請求書データテーブルにも、ユーザや組織の電子メールアドレスが含まれることがある。しかし、配送データテーブルや請求書データテーブルは、トランザクションデータテーブルと判定されているので、ユーザテーブルの特定処理S23では、判定対象のテーブルにはならない。

図９に戻り、テーブル分析部３７２は、マスターデータテーブルに指定されたテーブルから国データテーブルを特定する(S24)。そして、ユーザテーブルと国データテーブルが特定できるまで（S25）、処理S23,S24を繰り返す。

図１４は、テーブル分析部による国データテーブルの特定処理S24の詳細なフローチャート図である。テーブル分析部３７２は、マスターデータテーブルの一覧をテーブル分析情報テーブル３７５＿２から取得する（S240）。そして、一覧からテーブルを一つずつ取り出し、以下の処理を全てのテーブルについて行う(S241)。すなわち、テーブル分析部３７２は、取り出したマスターデータテーブルのデータを取得し、国名コードと一致するデータが含まれているか確認する（S242）。そして、国名コードと一致するデータが含まれるテーブルが見つかれば（S243のYES）、そのテーブルを国データテーブルと特定する（S244）。

代表的な国名コードは、以下のとおりである。

テーブル分析部３７２は、上記のいずれかの国コードと一致するデータが含まれているテーブルを国データテーブルと判定する。

図２５の右側のテーブル分析テーブル３７５＿２Ｂには、テーブルuserとcountryが、それぞれテーブル種別がユーザ、国データとが登録されている。

［国別ユーザ数取得クエリの作成S26、国別ユーザ数取得S28］
図９に戻り、性能改善優先度情報取得クエリ作成部３７３は、工程S20で収集したクエリを分析して、国別ユーザ数情報取得クエリを作成する（S26,S27）。第２の実施の形態では、国別ユーザ数情報が、第１の実施の形態の性能改善優先度情報に対応する。したがって、国別ユーザ数情報取得クエリは、性能改善優先度情報取得クエリに対応する。

図１５は、取得クエリ作成部による国別ユーザ数取得クエリの作成S26の詳細フローチャート図である。図１６は、結合情報探索関数のフローチャート図である。図１５に示すとおり、取得クエリ作成部３７３は、ユーザテーブルを関数の入力とし、結合情報探索関数を呼び出す（S260）。そして、結合情報探索関数がユーザテーブルと国データテーブルの間の結合情報を検出したら（S261のYES）、取得クエリ作成部３７３は、ユーザテーブルと国データテーブルを結合し、国別ユーザ数を取得する取得クエリを作成する（S262）。取得クエリは、分析情報データベース３７５内の国別ユーザ数取得クエリテーブル３７５＿３に格納される。

ここで、結合情報とは、クエリ内のJOIN句と対象テーブル名に対応し、クエリにJOIN句が含まれている場合、そのJOIN句からクエリの対象テーブル間の結合情報を検出することができる。また、特定のテーブル間の結合情報は、複数のクエリのJOIN句と対象テーブルから検出できる場合もある。

図２４のクエリ情報テーブルの５つのクエリを例にしてJOIN句について説明する。１，２，３，５行目のクエリはいずれも対象テーブルが、user, user, shipping, orderと１つのテーブルであるので、JOIN句は含まれない。一方、４行目のクエリは、対象テーブルがaccount, user, countryと複数のテーブルであり、複数のテーブルを参照しているのでJOIN句が含まれ、さらに、where句内のaccount.user=user.key、user.country=country.keyが、テーブルaccountとuserとの結合関係、テーブルuserとcountryとの結合関係をそれぞれ示している。この点に関し、４行目のクエリを説明した図２８を参照すれば、３つの対象テーブル間の結合情報が理解できる。

図１６の結合情報探索関数は、収集したクエリ情報テーブル３７５＿１のテーブルの一覧から一つずつテーブルを取り出して、以下の処理を実行する(S260_1)。取り出すテーブルは、ユーザテーブルから、または国コードテーブルから開始することが望ましい。まず、結合情報探索関数は、取り出したテーブルを対象とするクエリからそのテーブルと結合している他のテーブル及びその結合情報を取得する(S260_2)。最初は、ユーザテーブルを取り出し、ユーザテーブルを対象とするクエリからユーザテーブルと結合しているテーブル及び結合条件を取得することが望ましい。または、国コードテーブルから取り出して行っても良い。

そして、結合情報探索関数は、ユーザテーブルを対象テーブルとする全てのクエリをチェックして、ユーザテーブルと国データテーブルとの結合情報が見つかれば（S260_3のYES）、リターンとなり、見つからなければ（S260_3のNO）、ユーザテーブルと結合対象のテーブルを関数入力として再度結合情報探索関数を読み出す（S260_4）。このように結合情報探索関数が再帰的に呼び出される理由について以下説明する。

図２８の例では、ユーザテーブルuserと国コードテーブルcountryとは、ユーザテーブルの国コードuser.countyと国コードテーブルのキー番号country.keyとで結合可能である。したがって、例えば、あるクエリの対象テーブルにユーザテーブルと国コードテーブルとが含まれ、JOIN句やwhere句により両テーブルの結合関係が含まれていれば、結合情報探索関数は１回でユーザテーブルと国コードテーブルの関係情報を取得できる。例えば、図２４のクエリ情報テーブル内の４行目のクエリは、単独でユーザテーブルと国コードテーブルの結合関係を示している。しかしながら、ユーザテーブルと国コードテーブルとの関係が他のテーブルを介して判明する場合がある。

図１７は、ユーザテーブルと国コードテーブルとが他のテーブルを介した関係を有する例を示す図である。図１７の例では、ユーザテーブルは、Ａテーブル、Ｂテーブル、Ｃテーブル、Ｄテーブルと結合関係を有し、ＡテーブルはＡ１、Ａ２テーブルと結合関係を有し、ＢテーブルはＢ１テーブルと、ＣテーブルはＣ１，Ｃ２テーブルと、そして、Ｄテーブルは国データテーブルとそれぞれ結合関係を有する。

このような例の場合、あるクエリがユーザテーブルとＤテーブルとを対象テーブルとするJOIN句を有し、それらの間の結合情報を含んでいた場合、結合情報探索関数は、ユーザテーブルとDテーブルとの間の結合情報を検出する。そこで、ユーザテーブルと結合関係を有するDテーブルを関数入力として結合情報探索関数を再帰的に呼び出すことで、呼び出された結合情報探索関数は、Dテーブルと国データテーブルとの間の結合情報を検出する。その結果、ユーザテーブルと国データテーブルとはDテーブルを介して結合関係を有することが検出される。

図２６は、第２の実施の形態における国別ユーザ数情報取得クエリの例を示す図である。図２８のユーザテーブルと国コードテーブルとの関係を参照して説明すると、この取得クエリは、ユーザテーブルuserと国コードテーブルcountryで、ユーザテーブルの国番号user.countryと国コードテーブルのキー番号country.keyが等しい条件（user.country=country.key）を満たすレコードを、国コードテーブルの国コードcountry.country_codeでグループ化した数（count(*)）を全て抽出するセレクト文selectである。

つまり、図２６の取得クエリは、図２４の４行目のクエリから図２８に示すユーザテーブルと国コードテーブルとの結合情報に基づいて作成される。

図９に戻り、性能改善優先度情報取得部３７４は、取得クエリを使用して業務データベースから国別ユーザ数を取得する（S28）。

図１８は、優先度情報取得部３７４による優先度情報である国別ユーザ数取得処理S28の詳細フローチャート図である。優先度情報取得部３７４は、分析情報データベース３７５内の国別ユーザ数取得クエリ３７５＿３を読み込み（S280）、管理情報取得エージェント３７のサービスが動作中は、以下の処理を実行する（S281）。すなわち、優先度情報取得部３７４は、業務データベース３３２から国別ユーザ数取得クエリにより国別ユーザ数を取得し（S282）、取得した国別ユーザ数を優先度情報データベース３４５内の国別ユーザ数情報テーブル３４５＿１に登録する（S283）。そして、優先度情報取得部３７４は、上記の国別ユーザ数の取得処理を、収集間隔（例えば５分）毎に繰り返す（S284）。

図２７は、上記の取得クエリにより取得した国別ユーザ数を有する国別ユーザ数情報テーブルの一例を示す図である。国別ユーザ数情報テーブル３４５＿１は、監視サーバ３４が有する性能改善優先度情報データベース３４５内に生成されるテーブルである。図２７に示すとおり、国毎のユーザ数と、取得日時が格納されている。取得日時は５分間隔になっている。

［監視サーバによる性能改善分析情報DBの生成S29］
図１０は、管理サーバの性能改善分析情報生成部３４２による処理のフローチャート図である。性能改善分析情報生成部３４２は、性能情報データベース３４３内のレスポンス性能情報と、優先度情報データベース３４５の優先度情報とを関連付けて、性能改善分析情報データベース３４４を生成する。第２の実施の形態では、レスポンス性能はレスポンス速度、性能改善優先度情報は国別ユーザ数、性能改善分析情報データベースは国別ユーザ数テーブルである。

図１９は、性能改善分析情報データベースの生成処理S29の詳細なフローチャート図である。性能改善分析情報生成部３４２は、性能情報データベースから国別のレスポンス性能情報の一覧を取得し（S290）、優先度情報データベース３４５から国別ユーザ数情報の一覧を取得し(S291)、全てのレスポンス性能情報と国別ユーザ数情報とを組み合わせて、性能改善分析情報データベースに登録する（S292,S293）。そして、処理結果をレスポンス性能分析部３４１に渡す（S294）。

図２９は、性能改善分析情報テーブルの一例を示す図である。性能改善分析情報テーブル２４４は、国と、レスポンス性能と、ユーザ数とが関連付けられている。そして、レスポンス性能が同程度に遅いアメリカ、ドイツ、日本のユーザ数が多い順に改善優先度が決定している。

上記の第２の実施の形態では、性能情報の例としてレスポンス速度を、性能改善優先度の例として国別ユーザ数をそれぞれ挙げて説明した。しかしながら、これらの例に限定されない。

例えば、性能改善優先度の例として、国別ユーザ数に代えて、企業別ユーザ数、接続拠点別ユーザ数でもよい。また、性能の例として、レスポンス速度に代えて、アクセス集中時のサーバの耐性（単位時間当たりに処理可能なアクセス数など）でもよい。

以上の通り、本実施の形態によれば、ウエブサービスを伴うサービスシステムにおけるウエブサービスの性能の改善の優先度に対応する管理情報を、サービスシステムの業務データベースの構成情報を事前に取得しなくても、また、業務データベースに直接アクセスできなくても、クエリを分析して報告対象テーブルを特定し、優先度情報を取得するクエリを作成し、その取得クエリを実行することで、所望の管理情報を取得することができる。

以上の実施の形態をまとめると，次の付記のとおりである。

（付記１）
管理対象サービスシステムのデータベースに対するクエリを取得し、
前記取得したクエリに含まれる対象テーブルと前記クエリの内容に基づいて、前記データベースに含まれる参照対象テーブルを特定し、
前記参照対象テーブルのデータに基づいて、報告対象テーブルを特定し、
前記報告対象テーブルに対する取得クエリを前記データベースに実行させ、前記報告対象テーブルから所望の管理情報を取得し、出力する
処理を実行させるコンピュータ読み取り可能な管理情報取得プログラム。

（付記２）
前記報告対象テーブルを特定する処理は、複数の報告対象テーブルを特定し、
さらに、
前記取得したクエリに含まれる前記複数の報告対象テーブルの結合情報に基づいて、前記取得クエリを作成する
処理を実行させる付記１に記載の管理情報取得プログラム。

（付記３）
前記取得クエリを作成する処理では、クエリに第１のテーブルと第２のテーブルとの結合情報が含まれているか否かを判定し当該含まれていた結合情報を出力する結合情報探索関数を、最初は前記報告対象テーブルを関数入力として実行し、前記複数の報告対象テーブルの結合情報が得られるまで、前記結合情報探索関数を再帰的に実行する
付記２に記載の管理情報取得プログラム。

（付記４）
前記参照対象テーブルを特定する処理では、前記対象テーブル毎に、対応するクエリの内容が参照である回数と、登録である回数と、更新である回数を求め、前記参照の回数が前記登録の回数より多い、及び前記参照の回数が前記更新の回数が多い、のいずれか一方または両方が満たされる場合に、前記対象テーブルを参照対象テーブルと特定する
付記１に記載の管理情報取得プログラム。

（付記５）
前記報告対象テーブルの特定処理では、前記参照対象テーブルのデータが前記報告対象テーブルのデータを有する場合に、前記参照対象テーブルを前記報告対象テーブルと特定する
付記１または３に記載の管理情報取得プログラム。

（付記６）
管理対象サービスシステムのデータベースに対するクエリを取得し、
前記取得したクエリに含まれる対象テーブルと前記クエリの内容に基づいて、前記データベースに含まれる参照対象テーブルを特定し、
前記参照対象テーブルのデータに基づいて、報告対象テーブルを特定し、
前記報告対象テーブルに対する取得クエリを前記データベースに実行させ、前記報告対象テーブルから所望の管理情報を取得し、出力する
処理を有する管理情報取得方法。

（付記７）
前記報告対象テーブルを特定する処理は、複数の報告対象テーブルを特定し、
さらに、
前記取得したクエリに含まれる前記複数の報告対象テーブルの結合情報に基づいて、前記取得クエリを作成する
処理を有する付記６に記載の管理情報取得方法。

（付記８）
管理対象サービスシステムのデータベースに対するクエリを取得し、前記取得したクエリに含まれる対象テーブルと前記クエリの内容に基づいて、前記データベースに含まれる参照対象テーブルを特定し、前記参照対象テーブルのデータに基づいて、報告対象テーブルを特定し、前記報告対象テーブルに対する取得クエリを前記データベースに実行させ、前記報告対象テーブルから所望の管理情報を取得し、出力する処理を実行させるコンピュータ読み取り可能な管理情報取得プログラムを、前記管理対象サービスシステムにインストールするインストール部と、
前記管理情報取得プログラムが出力する前記所望の管理情報を受信する受信部と
を有する管理情報取得装置。

（付記９）
前記報告対象テーブルを特定する処理は、複数の報告対象テーブルを特定し、
さらに、前記処理は、
前記取得したクエリに含まれる前記複数の報告対象テーブルの結合情報に基づいて、前記取得クエリを作成する処理を有する
付記８に記載の管理情報取得装置。

（付記１０）
前記データベースに対して直接クエリを実行させることなく、前記管理情報取得プログラムから、前記所望の管理情報を取得する付記８に記載の管理情報取得装置。

２０＿１，２０＿２：管理対象サービスシステム
３３：データベース
３３２：参照対象テーブル（マスターデータテーブル）
３３２：非参照対象テーブル（トランザクションテーブル）
３３２：報告対象テーブル（顧客データテーブル、国データテーブル）
３７３：取得クエリ作成部
３４５：所望の管理情報（性能改善優先度）情報データベース
３０：ウエブサーバ
４０：ユーザ端末
３４：管理サーバ、レスポンス性能管理サーバ

Claims (8)

1. 管理対象サービスシステムのデータベースに対するクエリを取得し、
   前記取得したクエリに含まれる対象テーブルと前記クエリの内容に基づいて、前記データベースに含まれる参照対象テーブルを特定し、
   前記参照対象テーブルのデータに基づいて、報告対象テーブルを特定し、
   前記報告対象テーブルに対する取得クエリを前記データベースに実行させ、前記報告対象テーブルから所望の管理情報を取得し、出力する
   処理を実行させるコンピュータ読み取り可能な管理情報取得プログラム。
2. 前記報告対象テーブルを特定する処理は、複数の報告対象テーブルを特定し、
   さらに、
   前記取得したクエリに含まれる前記複数の報告対象テーブルの結合情報に基づいて、前記取得クエリを作成する
   処理を実行させる請求項１に記載の管理情報取得プログラム。
3. 前記取得クエリを作成する処理では、クエリに第１のテーブルと第２のテーブルとの結合情報が含まれているか否かを判定し当該含まれていた結合情報を出力する結合情報探索関数を、最初は前記報告対象テーブルを関数入力として実行し、前記複数の報告対象テーブルの結合情報が得られるまで、前記結合情報探索関数を再帰的に実行する
   請求項２に記載の管理情報取得プログラム。
4. 前記参照対象テーブルを特定する処理では、前記対象テーブル毎に、対応するクエリの内容が参照である回数と、登録である回数と、更新である回数を求め、前記参照の回数が前記登録の回数より多い、及び前記参照の回数が前記更新の回数が多い、のいずれか一方または両方が満たされる場合に、前記対象テーブルを参照対象テーブルと特定する
   請求項１に記載の管理情報取得プログラム。
5. 前記報告対象テーブルの特定処理では、前記参照対象テーブルのデータが前記報告対象テーブルのデータを有する場合に、前記参照対象テーブルを前記報告対象テーブルと特定する
   請求項１または３に記載の管理情報取得プログラム。
6. 管理対象サービスシステムのデータベースに対するクエリを取得し、
   前記取得したクエリに含まれる対象テーブルと前記クエリの内容に基づいて、前記データベースに含まれる参照対象テーブルを特定し、
   前記参照対象テーブルのデータに基づいて、報告対象テーブルを特定し、
   前記報告対象テーブルに対する取得クエリを前記データベースに実行させ、前記報告対象テーブルから所望の管理情報を取得し、出力する
   処理を有する管理情報取得方法。
7. 管理対象サービスシステムのデータベースに対するクエリを取得し、前記取得したクエリに含まれる対象テーブルと前記クエリの内容に基づいて、前記データベースに含まれる参照対象テーブルを特定し、前記参照対象テーブルのデータに基づいて、報告対象テーブルを特定し、前記報告対象テーブルに対する取得クエリを前記データベースに実行させ、前記報告対象テーブルから所望の管理情報を取得し、出力する処理を実行させるコンピュータ読み取り可能な管理情報取得プログラムを、前記管理対象サービスシステムにインストールするインストール部と、
   前記管理情報取得プログラムが出力する前記所望の管理情報を受信する受信部と
   を有する管理情報取得装置。
8. 前記データベースに対して直接クエリを実行させることなく、前記管理情報取得プログラムから、前記所望の管理情報を取得する請求項７に記載の管理情報取得装置。

Images