JP2022105456A - 情報処理プログラム、情報処理方法及び情報処理装置 - Google Patents

Abstract

【課題】ＤＢＭＳの管理コストを低減すること。【解決手段】情報収集部が、フィードリストカタログに基づいてＤＢＭＳ１の情報を収集してフィードカタログに登録し、クエリの処理時間を収集してクエリカタログに登録する。そして、判定部が、クエリカタログの情報に基づいて、ＤＢＭＳ１に性能劣化が発生しているか否かを判定する。そして、判定部によりＤＢＭＳ１に性能劣化が発生していると判定された場合に、対策実行部が、収集情報に基づいた対策を実行する。【選択図】図１

Description

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

データベースマネジメントシステム（以下、ＤＢＭＳ：Data Base Management System）を継続的に適切に運用するために、データベース管理者によりＤＢＭＳの管理が行われる。データベース管理者は、ＤＢＭＳの動作を定期的に監視し、ＤＢＭＳの性能劣化を検知すると、ＤＢＭＳの情報を収集して劣化の原因を特定する。そして、データベース管理者は、最も適切な対策を適切なタイミングで実施し、対策の効果を測定する。

図１４は、データベース管理者によるＤＢＭＳの管理を説明するための図である。図１４に示すように、ＤＢＭＳ９１は、テーブル形式でデータを記憶し、クエリを受け付け、テーブルの検索及び操作を行い、応答を返す。データベース管理者は、ＤＢＭＳ９１の動作を監視し、劣化を検知すると、試行錯誤を行いながら対策を実施する。

なお、ＤＢＭＳに関する従来技術として、統計分析を通じてＳＱＬ（Structured Query Language）の改善案を提案するチューニング自動化システムがある。このチューニング自動化システムは、データベースを運営する運営サーバーとモニタリングサーバーで構成される。モニタリングサーバーは、クライアントと運営サーバー上のデータベース間に送受信されるネットワークストリームからＳＱＬを含むトランザクション情報及び応答時間、処理結果を抽出して性能をモニタリングしつつ、性能低下の原因を分析して改善案を提供する。

また、従来技術として、クラウド・システムの性能低下を抑制して、適切な計算機リソースを提供する計算機システムがある。この計算機システムは、物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、１以上の仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機とを備える。管理計算機は、サービスを提供する仮想計算機群の性能を取得して、取得した仮想計算機群の性能と、予め設定されたサービスの性能条件とを比較し、比較結果に応じて、仮想計算機群で変更する計算機リソースを決定する。そして、管理計算機は、変更の対象となる計算機リソースに応じた仮想計算機でサービスを試行して、当該仮想計算機の性能を測定し、測定した性能がサービスの性能条件を満たす場合には変更を適用する。

また、従来技術として、トランザクション処理のロギングを行うためのシステムがある。このシステムは、ロギング・ポリシー・テーブルと、トランザクション処理の応答時間を自動的に監視するトランザクション処理監視部と、トランザクション処理のログを記録する記憶デバイスを備える。ロギング・ポリシー・テーブルは、サービス・レベル・アグリーメントに規定される要求応答時間に基づいてトランザクション処理のログのデータ量が変化するロギングを実行するように定義されたロギング・ポリシーを記録する。このシステムは、ロギング・ポリシー・テーブルに記憶されたロギング・ポリシーを選択し、選択されたロギング・ポリシーに従って、当該トランザクション処理のログを記録デバイスに記録させるロギング制御部をさらに備える。ロギング制御部は、トランザクション処理監視部によって監視されたトランザクション処理の応答時間に基づいて、ロギング・ポリシーを選択する。

特開２０１９－１１４２４１号公報 特開２０１６－１０３１７９号公報 国際公開第２００７／０７４６８０号

ＤＢＭＳの管理にはコストがかかるという問題がある。例えば、ＤＢＭＳが受け付けたクエリごとに処理時間を監視すると、監視にコストがかかる。また、緩やかに性能が劣化した場合など、性能劣化の検知が困難な場合があり、検知にコストがかかる。また、性能劣化の原因を特定するためには、様々な種類の情報を取得する必要があり、取得した情報の管理にコストがかかる。また、対策の効果の測定にもコストがかかる。

本発明は、１つの側面では、ＤＢＭＳの管理コストを低減することを目的とする。

１つの態様では、情報処理プログラムは、データベース管理システムの管理を行う。前記情報処理プログラムは、前記データベース管理システムが受け付けたクエリの情報と前記クエリの処理時間を含む前記データベース管理システムの情報とを収集情報として収集し、収集した前記クエリの処理時間に基づいて前記データベース管理システムの処理性能が低下しているか否かを判定し、低下していると判定した場合に、前記収集情報に基づいた対策を実行する処理をコンピュータに実行させる。

１つの側面では、本発明は、ＤＢＭＳの管理コストを低減することができる。

図１は、実施例に係るＤＢＭＳ管理を説明するための図である。 図２は、ＤＢＭＳの機能構成を示す図である。 図３は、フィードリストカタログの一例を示す図である。 図４は、フィードカタログの一例を示す図である。 図５は、ＬＲＵによる情報管理を説明するための図である。 図６は、ペットカタログの一例を示す図である。 図７は、クエリ処理時間の収集例を示す図である。 図８は、クエリ処理時間の平均及び標準偏差の計算を説明するための図である。 図９は、クエリ処理時間の分布を示す図である。 図１０Ａは、モジュールの呼び出し例を示す第１の図である。 図１０Ｂは、モジュールの呼び出し例を示す第２の図である。 図１０Ｃは、モジュールの呼び出し例を示す第３の図である。 図１１は、情報収集処理のフローを示すフローチャートである。 図１２は、性能劣化に対する処理のフローを示すフローチャートである。 図１３は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。 図１４は、データベース管理者によるＤＢＭＳの管理を説明するための図である。

以下に、本願の開示する情報処理プログラム、情報処理方法及び情報処理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

まず、実施例に係るＤＢＭＳ管理について説明する。図１は、実施例に係るＤＢＭＳ管理を説明するための図である。図１に示すように、実施例に係るＤＢＭＳ１は、複数のテーブル２０ａにデータを記憶し、複数のテーブル２０ａを用いてクエリを処理する。また、ＤＢＭＳ１は、管理部１０を有する。なお、実施例に係るＤＢＭＳ１は、情報処理を行う情報処理装置の一例である。

管理部１０は、管理用テーブル１０ａを用いてＤＢＭＳ１を管理する。具体的には、管理部１０は、ＤＢＭＳ１の性能を監視し、性能劣化を検知すると、複数のモジュール２に必要な各種情報を提供し、各モジュール２から対策を受け取る。そして、管理部１０は、対策を実行し、対策の有効性を検証する。

モジュール２は、管理部１０から必要な情報を受け取って、性能劣化に対する対策を管理部１０に応答する。モジュール２には、例えば、統計情報ずれ解決モジュール２、テーブル肥大化解決モジュール２、インデックス肥大化解決モジュール２、インデックス付与・削除モジュール２がある。

統計情報ずれ解決モジュール２は、テーブル２０ａの行数、テーブル２０ａのサイズなどの統計情報のずれを修正することで性能を向上させる対策を作成する。ＤＢＭＳ１は、統計情報に基づいてクエリの処理を行う。例えば、ＤＢＭＳ１は、統計情報に基づいてどのようにテーブル２０ａにアクセスするかを決める。したがって、統計情報がずれるとクエリの処理が遅くなる。また、統計情報は、データベースの利用にともなって変化する。そこで、統計情報ずれ解決モジュール２は、例えば「pg_class_per_hour」を受け取って、統計情報のずれを修正する対策を応答する。

テーブル肥大化解決モジュール２は、不要になったデータによりテーブル２０ａが肥大化した場合に、ガベージコレクションを行うことで性能を向上させる対策を作成する。ＤＢＭＳ１では、データの削除、更新が行われるごとに不要になるデータが発生するが、不要となったデータは削除されることなく、不要のマークが付与される。そこで、テーブル２０ａの肥大化を解決するモジュール２は、不要となったデータをガベージコレクションにより回収する対策を応答する。

インデックス肥大化解決モジュール２は、テーブル２０ａの検索に用いられるインデックスの情報に基づいてインデックスの肥大化具合が閾値以上である場合に、対策を応答する。インデックス肥大化解決モジュール２が必要とする情報の取得には、例えば、pgstattupleが用いられる。pgstattupleモジュールは、タプルレベルの統計情報を入手するための各種関数を提供する。対策は、通常はＲＥＩＮＤＥＸであり、特にひどい場合はＣＬＵＳＴＥＲである。ここで、ＲＥＩＮＤＥＸはインデックスの再構築であり、ＣＬＵＳＴＥＲはテーブル２０ａのクラスタ化である。

インデックス付与・削除モジュール２は、適切なインデックスを付与（例えば、create index）し、不適切なインデックスを削除する（例えば、drop index）ことを対策として応答する。

次に、ＤＢＭＳ１の機能構成について説明する。図２は、ＤＢＭＳ１の機能構成を示す図である。図２に示すように、ＤＢＭＳ１は、管理部１０と、データ記憶部２０と、クエリ処理部３０とを有する。データ記憶部２０は、複数のテーブル２０ａを記憶する。クエリ処理部３０は、ユーザからクエリを受け付け、データ記憶部２０を用いてクエリを処理し、ユーザに応答を返す。管理部１０は、カタログ記憶部１１と、収集情報登録部１２と、情報収集部１３と、判定部１４と、協調部１５と、対策実行部１６と、検証部１７とを有する。

カタログ記憶部１１は、管理用テーブル１０ａをカタログとして記憶する。カタログには、フィードリストカタログ４１、フィードカタログ４２、ペットカタログ４３及びクエリカタログ４４がある。

フィードリストカタログ４１は、モジュール２がどのような情報を個別収集情報として必要とし、必要な情報をどのようなときにどうやって収集すべきかを示す情報を保持する。フィードリストカタログ４１は、モジュール２の追加及び削除時にデータベース管理者により更新される。管理部１０は、ＤＢＭＳ１が起動されたときに、フィードリストカタログ４１を読み込み、フィードリストカタログ４１に基づいて情報を取集する。

図３は、フィードリストカタログ４１の一例を示す図である。図３に示すように、フィードリストカタログ４１は、モジュール名と情報名とＷｈｅｎとＨｏｗとを対応付けた情報を保持する。モジュール名は、モジュール２を識別する名前である。情報名は、収集する情報を識別する名前である。Ｗｈｅｎは、いつ情報を収集するかを示す。Ｈｏｗは、どのように情報を収集するかを示す。

例えば、「モジュール＃１」で識別されるモジュール２は、「Query_execution_start_time」で識別される情報を必要とする。この情報は、関数「ExecutorStart()」が起動されたときに、関数「gettimeofday()」を呼び出すことで収集される。また、「モジュール＃ｎ」で識別されるモジュール２は、「Daily_snapshot」で識別される情報を必要とする。この情報は、２４時間ごとにコマンド「pg_dump」を呼び出すことで収集される。また、「モジュール＃ｎ」で識別されるモジュール２は、「pg_class_per_hour」で識別される情報を必要とする。この情報は１時間ごとにコマンド「psql -c “select reltuples, relpages from pg_class;”」により収集されるデータベースの統計情報である。

フィードカタログ４２は、フィードリストカタログ４１に基づいて収集された情報を保持する。管理部１０は、フィードカタログ４２に含まれる情報をモジュール２に渡す。図４は、フィードカタログ４２の一例を示す図である。図４に示すように、フィードカタログ４２は、クエリ識別子と情報名と値とを対応付けた情報を保持する。クエリ識別子は、情報が収集されたクエリを識別する識別子である。情報名は、収集された情報を識別する名前である。値は、収集された情報である。例えば、「クエリ＃１」で識別されるクエリについて「Query_execution_start_time」で識別される情報が収集され、収集された情報は「yyyy_mm_dd_hh_...」である。

フィードカタログ４２の情報は、ＬＲＵ（Least Recently Used）により管理される。図５は、ＬＲＵによる情報管理を説明するための図である。図５に示すように、クエリ＃１について情報が収集され、フィードカタログ４２への登録が行われる際、フィードカタログ４２に空がない（ｏｖｅｒ）と、クエリ＃１の情報のうち最古の情報が破棄される。そして、収集された情報がフィードカタログ４２に登録される。

ペットカタログ４３は、モジュール２が対策の作成に必要とする情報を保持する。モジュール２は、ペットカタログ４３に基づいて呼び出される。図６は、ペットカタログ４３の一例を示す図である。図６に示すように、ペットカタログ４３は、モジュール名に複数のフィードを対応付けた情報を保持する。モジュール名は、モジュール２を識別する名前である。フィードは、モジュール２が必要とする情報の名前である。例えば、「統計情報ずれ解決モジュール」で識別されるモジュール２は、対策の作成に「pg_class_per_hour」で識別される情報を必要とする。ペットカタログ４３は、フィードリストカタログ４１から作成される。

クエリカタログ４４は、クエリ処理時間を保持する。ここで、クエリ処理時間は、クエリを受信してから応答するまでの時間である。定数部分だけが異なるクエリは同じクエリとして扱われる。クエリカタログ４４に基づいて、ＤＢＭＳ１の性能劣化が判定される。図７は、クエリ処理時間の収集例を示す図である。図７に示すように、クエリカタログ４４は、クエリ識別子と一般化クエリとｔｉｍｅを対応付けた情報を保持する。

クエリ識別子は、一般化クエリを識別する識別子である。一般化クエリは、定数部分が「＄１」で置き換えられたクエリである。ｔｉｍｅは、クエリ処理時間である。例えば、「select name from tbl where id = 5432;」と「select name from tbl where id = 2785;」は、「id＝定数」の定数部分だけが異なるので、一般化されると、識別子が「１２３」の同じ「select name from tbl where id = $1;」になる。

図２に戻って、収集情報登録部１２は、データベース管理者の指示に基づいてフィードリストカタログ４１に情報を登録する。データベース管理者は、モジュール２を追加した場合及び削除した場合に、収集情報登録部１２を用いてフィードリストカタログ４１を更新する。

情報収集部１３は、フィードリストカタログ４１に基づいてＤＢＭＳ１の情報を収集し、フィードカタログ４２に登録する。情報収集部１３は、フィードカタログ４２の情報を、ＬＲＵにより管理する。また、情報収集部１３は、クエリ処理時間を収集し、クエリカタログ４４に登録する。

判定部１４は、クエリカタログ４４の情報に基づいて、ＤＢＭＳ１に性能劣化が発生しているか否かを判定する。判定部１４は、例えば、一般化クエリごとに直近ｋ（ｋは正の整数）件のクエリ処理時間の平均及び標準偏差を計算する。図８は、クエリ処理時間の平均及び標準偏差の計算を説明するための図である。図８では、クエリ識別子が「１２３」であるクエリについてｔｉｍｅの値が取り出され、平均及び標準偏差が計算される。

判定部１４は、計算した平均及び標準偏差から、次のクエリの偏差値を計算し、クエリ処理時間の分布を作成する。図９は、クエリ処理時間の分布を示す図である。図９の横軸はクエリ処理時間の偏差値であり、縦軸はクエリ数である。

判定部１４は、例えば、図９に示すように、クエリの偏差値がデータベース管理者により設定された閾値αを超えているか否かに基づいてＤＢＭＳ１に性能劣化が発生しているか否かを判定する。あるいは、判定部１４は、ｋ件ごとの平均値の増加量が大きくなったか否かに基づいてＤＢＭＳ１に性能劣化が発生しているか否かを判定する。

協調部１５は、判定部１４がＤＢＭＳ１に性能劣化が発生していると判定した場合に、モジュール２と協調して性能劣化に対する対策を特定する。協調部１５は、ペットカタログ４３に基づいて、各モジュール２に渡す情報名を特定し、各モジュール２に、特定した情報名の情報をフィードカタログ４２から取り出して渡す。そして、協調部１５は、モジュール２から対策を受け取る。なお、モジュール２は、対策がない場合には、対策なしを応答する。

図１０Ａ～図１０Ｃは、モジュール２の呼び出し例を示す図である。図１０Ａに示すように、協調部１５は、ペットカタログ４３に基づいて、統計情報ずれ解決モジュール２が「pg_class_per_hour」で識別される情報を必要とすると判断する（ｔ１）。そして、協調部１５は、図１０Ｂに示すように、フィードカタログ４２で情報名が「pg_class_per_hour」に対応する値を必要な情報として選択する（ｔ２）。そして、協調部１５は、図１０Ｃに示すように、統計情報ずれ解決モジュール２を呼び出して、選択した情報を渡す（ｔ３）。

対策実行部１６は、協調部１５から対策を受け取って実行する。協調部１５が複数の対策を受け取った場合には、対策実行部１６は、複数の対策を実行する。あるいは、対策実行部１６は、複数の対策から１つ対策を選択して実行してもよい。データベースの管理者により対策の通知が指定されている場合には、対策実行部１６は、データベースの管理者に対策を通知し、データベースの管理者から実行指示を受け取ると、対策を実行する。

検証部１７は、対策の実行結果を検証する。検証部１７は、例えば、フィードリストカタログ４１に基づいて、対策の実行前後のクエリ処理時間の平均及び標準偏差を計算し、対策の実行前後のクエリ処理時間の平均及び標準偏差に有意性があるか否かを検定することで対策の実行結果を検証する。検証部１７は、対策の効果が確認できなかった場合には、データベースの管理者にアラートを通知する。あるいは、検証部１７は、対策の効果が確認できなかった場合には、ＤＢＭＳ１の動作を継続監視した後に対策の実行結果の検証を再度行ってもよい。

次に、管理部１０による処理のフローについて図１１及び図１２を用いて説明する。図１１は、情報収集処理のフローを示すフローチャートである。図１１に示すように、管理部１０は、ＤＢＭＳ１の起動時に、フィードリストカタログ４１を読み込む（ステップＳ１）。例えば、管理部１０は、フィードリストカタログ４１を磁気ディスクからメモリに読み込む。

そして、管理部１０は、フィードリストカタログ４１に基づいて情報収集を行い（ステップＳ２）、フィードカタログ４２の情報が満杯であるか否かを判定する（ステップＳ３）。そして、満杯である場合には、管理部１０は、フィードカタログ４２に、ＬＲＵにより空領域を作成する（ステップＳ４）。

そして、管理部１０は、フィードカタログ４２に収集した情報を登録する（ステップＳ５）。そして、管理部１０は、ＤＢＭＳ１が停止するか否かを判定し（ステップＳ６）、停止しない場合には、ステップＳ２に戻り、停止する場合には、情報収集処理を終了する。なお、ＤＢＭＳ１の停止判定は、ＤＢＭＳ１のパフォーマンスの低下、所定のクエリ処理のパフォーマンスの低下、リードライトエラーまたは各種障害などの様々な停止要因を判定することができる。

このように、管理部１０は、フィードリストカタログ４１に基づいて情報を収集するので、モジュール２が必要とする情報を提供することができる。

図１２は、性能劣化に対する処理のフローを示すフローチャートである。図１２に示すように、管理部１０は、クエリ処理が遅延しているか否かを判定し（ステップＳ１１）、遅延していない場合には、ステップＳ１１に戻る。一方、クエリ処理が遅延している場合には、管理部１０は、ペットカタログ４３に基づいて、各モジュール２が必要とする情報を各モジュール２に提供し（ステップＳ１２）、各モジュール２から対策を取得する（ステップＳ１３）。

そして、管理部１０は、対策通知の指定があるか否かを判定し（ステップＳ１４）、対策通知の指定がない場合には、対策を実行し（ステップＳ１５）、実行した対策を検証する（ステップＳ１６）。一方、対策通知の指定がある場合には、管理部１０は、データベース管理者に対策を通知し（ステップＳ１７）、データベース管理者からの実行指示があるか否かを判定する（ステップＳ１８）。そして、データベース管理者からの実行指示がある場合には、管理部１０は、対策を実行し（ステップＳ１５）、実行した対策を検証する（ステップＳ１６）。一方、データベース管理者からの実行指示がない場合には、管理部１０は、性能劣化に対する処理を終了する。

このように、管理部１０は、各モジュール２が必要とする情報を各モジュール２に提供し、各モジュール２から対策を取得するので、ＤＢＭＳ１の性能劣化に対応することができる。

上述してきたように、実施例では、情報収集部１３が、フィードリストカタログ４１に基づいてＤＢＭＳ１の情報を収集してフィードカタログ４２に登録し、クエリの処理時間を収集してクエリカタログ４４に登録する。そして、判定部１４が、クエリカタログ４４の情報に基づいて、ＤＢＭＳ１に性能劣化が発生しているか否かを判定する。そして、判定部１４によりＤＢＭＳ１に性能劣化が発生していると判定された場合に、協調部１５が、モジュール２に必要な情報を提供してモジュール２から性能劣化に対する対策を取得する。そして、対策実行部１６が、協調部１５が取得した対策を実行し、検証部７が、対策の実行前後の処理性能に基づいて対策の効果を検証する。したがって、管理部１０は、ＤＢＭＳ１の管理コストを低減することができる。

また、実施例では、ペットカタログ４３が、モジュール２とモジュール２が対策の作成に必要とする情報とを対応付けて保持する。そして、協調部１５は、ペットカタログ４３に基づいて、モジュール２に情報を提供する。したがって、モジュール２は、対策を作成することができる。

また、実施例では、フィードリストカタログ４１は、モジュール２が対策の作成に必要とする情報をいつどのように収集するかを示す情報（取得するタイミング及び取得する方法）を保持し、情報収集部１３は、フィードリストカタログ４１に基づいて情報を収集する。したがって、管理部１０は、モジュール２が対策の作成に必要とする情報を収集することができる。

また、実施例では、統計情報ずれ解決モジュール２が、ＤＢＭＳ１の統計情報のずれを修正する対策を作成して協調部１５に応答する。したがって、管理部１０は、統計情報のずれを修正してＤＢＭＳ１の性能を向上することができる。

また、実施例では、テーブル肥大化解決モジュール２が、不要になったデータによりテーブル２０ａが肥大化した場合に、ガベージコレクションを行うことで性能を向上させる対策を作成する。したがって、管理部１０は、ガベージコレクションを行うことでＤＢＭＳ１の性能を向上することができる。

また、実施例では、インデックス肥大化解決モジュール２が、テーブル２０ａの検索に用いられるインデックスの情報に基づいてインデックスの肥大化具合が閾値以上である場合に、ＲＥＩＮＤＥＸ又はＣＬＵＳＴＥＲを対策として応答する。したがって、管理部１０は、ＲＥＩＮＤＥＸ又はＣＬＵＳＴＥＲを行うことでＤＢＭＳ１の性能を向上することができる。

また、実施例では、インデックス付与・削除モジュール２が、適切なインデックスを付与し、不適切なインデックスを削除することを対策として応答する。したがって、管理部１０は、インデックス付与及び削除を行うことでＤＢＭＳ１の性能を向上することができる。

なお、実施例では、管理部１０について説明したが、管理部１０が有する構成をソフトウェアによって実現することで、同様の機能を有する管理プログラムを得ることができる。そこで、管理プログラムを実行するコンピュータについて説明する。なお、管理プログラムは、情報処理を行う情報処理プログラムの一例である。

図１３は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。図１３に示すように、コンピュータ５０は、メインメモリ５１と、ＣＰＵ（Central Processing Unit）５２と、ＬＡＮ（Local Area Network）インタフェース５３と、ＨＤＤ（Hard Disk Drive）５４とを有する。また、コンピュータ５０は、スーパーＩＯ（Input Output）５５と、ＤＶＩ（Digital Visual Interface）５６と、ＯＤＤ（Optical Disk Drive）５７とを有する。

メインメモリ５１は、プログラムやプログラムの実行途中結果等を記憶するメモリである。ＣＰＵ５２は、メインメモリ５１からプログラムを読み出して実行する中央処理装置である。ＣＰＵ５２は、メモリコントローラを有するチップセットを含む。

ＬＡＮインタフェース５３は、コンピュータ５０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ５４は、プログラムやデータを格納するディスク装置であり、スーパーＩＯ５５は、マウスやキーボード等の入力装置を接続するためのインタフェースである。ＤＶＩ５６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ５７は、ＤＶＤの読み書きを行う装置である。

ＬＡＮインタフェース５３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ５２に接続され、ＨＤＤ５４及びＯＤＤ５７は、ＳＡＴＡ（Serial Advanced Technology Attachment）によりＣＰＵ５２に接続される。スーパーＩＯ５５は、ＬＰＣ（Low Pin Count）によりＣＰＵ５２に接続される。

そして、コンピュータ５０において実行される管理プログラムは、コンピュータ５０により読み出し可能な記録媒体の一例であるＤＶＤに記憶され、ＯＤＤ５７によってＤＶＤから読み出されてコンピュータ５０にインストールされる。あるいは、管理プログラムは、ＬＡＮインタフェース５３を介して接続された他のコンピュータシステムのデータベース等に記憶され、これらのデータベースから読み出されてコンピュータ５０にインストールされる。そして、インストールされた管理プログラムは、ＨＤＤ５４に記憶され、メインメモリ５１に読み出されてＣＰＵ５２によって実行される。

１，９１ ＤＢＭＳ
２ モジュール
１０ 管理部
１０ａ 管理用テーブル
１１ カタログ記憶部
１２ 収集情報登録部
１３ 情報収集部
１４ 判定部
１５ 協調部
１６ 対策実行部
１７ 検証部
２０ データ記憶部
２０ａ テーブル
３０ クエリ処理部
４１ フィードリストカタログ
４２ フィードカタログ
４３ ペットカタログ
４４ クエリカタログ
５０ コンピュータ
５１ メインメモリ
５２ ＣＰＵ
５３ ＬＡＮインタフェース
５４ ＨＤＤ
５５ スーパーＩＯ
５６ ＤＶＩ
５７ ＯＤＤ

Claims (11)

1. データベース管理システムの管理を行う情報処理プログラムであって、
   前記データベース管理システムが受け付けたクエリの情報と前記クエリの処理時間を含む前記データベース管理システムの情報とを収集情報として収集し、
   収集した前記クエリの処理時間に基づいて前記データベース管理システムの処理性能が低下しているか否かを判定し、
   低下していると判定した場合に、前記収集情報に基づいた対策を実行する
   処理をコンピュータに実行させることを特徴とする情報処理プログラム。
2. 前記収集情報に基づいて実行する対策は、前記収集情報に基づいて前記処理性能の低下の対策を作成するモジュールに前記収集情報を送信し、送信した前記収集情報に応じて前記モジュールから受信する対策であることを特徴とする請求項１に記載の情報処理プログラム。
3. 前記対策の実行前後の処理性能の比較結果に基づいて前記対策の効果を検証する処理をコンピュータに実行させることを特徴とする請求項１または２に記載の情報処理プログラム。
4. 前記対策を実行する処理は、
   モジュールと前記収集情報のうち該モジュールが用いる個別収集情報とを対応付けてモジュールごとに記憶する記憶部を参照して、各モジュールに個別収集情報を提供して対策を取得し、
   各モジュールから取得した対策を実行することを特徴とする請求項１から３のいずれか一つに記載の情報処理プログラム。
5. 前記記憶部は、前記個別収集情報を取得するタイミング及び取得する方法を示す取得実行情報を前記個別収集情報に対応付けて記憶し、
   前記収集する処理は、前記取得実行情報に基づいて前記データベース管理システムにおいて情報を収集することを特徴とする請求項４に記載の情報処理プログラム。
6. 前記対策を実行する処理は、
   前記データベース管理システムの統計情報のずれを修正する対策を作成するモジュールから該対策を取得し、
   前記統計情報のずれを修正することを特徴とする請求項１から５のいずれか一つに記載の情報処理プログラム。
7. 前記対策を実行する処理は、
   前記データベース管理システムが使用するテーブルに含まれる不要なデータを削除する対策を作成するモジュールから該対策を取得し、
   前記不要なデータを削除することを特徴とする請求項１～６のいずれか１つに記載の情報処理プログラム。
8. 前記対策を実行取得する処理は、
   前記データベース管理システムが検索に使用するインデックスの肥大化に対してインデックスの再構築又は前記データベース管理システムが使用するテーブルのクラスタ化を行う対策を作成するモジュールから対策を取得し、
   前記インデックスの再構築又は前記テーブルのクラスタ化を行うことを特徴とする請求項１～７のいずれか１つに記載の情報処理プログラム。
9. 前記対策を実行する処理は、
   前記データベース管理システムが検索に使用するインデックスを付与又は削除する対策を作成するモジュールから該対策を取得し、
   前記インデックスの付与又は削除を行うことを特徴とする請求項１～８のいずれか１つに記載の情報処理プログラム。
10. データベース管理システムの管理を行う情報処理方法であって、
    前記データベース管理システムが受け付けたクエリの情報と前記クエリの処理時間を含む前記データベース管理システムの情報とを収集情報として収集し、
    収集した前記クエリの処理時間に基づいて前記データベース管理システムの処理性能が低下しているか否かを判定し、
    低下していると判定した場合に、前記収集情報に基づいた対策を実行する
    処理をコンピュータが実行することを特徴とする情報処理方法。
11. データベース管理システムとして動作する情報処理装置であって、
    前記データベース管理システムが受け付けたクエリの情報と前記クエリの処理時間を含む前記データベース管理システムの情報とを収集情報として収集する情報収集部と、
    前記情報収集部により収集された前記クエリの処理時間に基づいて前記データベース管理システムの処理性能が低下しているか否かを判定する判定部と、
    前記判定部により前記処理性能が低下していると判定された場合に、前記収集情報に基づいた対策を実行する対策実行部と、
    を有することを特徴とする情報処理装置。

Images