JP2005267194A - データベース診断レポート管理システム - Google Patents

Abstract

【課題】 様々な種類のデータベースから得られた診断レポートを一元管理し、時系列的な解析を可能にする。
【解決手段】 データベースＤにＳＱＬ文からなる診断用スクリプトＳを実行させ、テキストデータからなる診断レポートＲを、受信手段２１０により受信する。記憶手段２２０には、種々のデータベースに用いられているＤＢＭＳの種類を特定するための種類特定情報を用意しておき、種類特定手段２３０により、受信した診断レポートＲからデータベースＤに用いられているＤＢＭＳの種類を特定する。選択手段２５０は、記憶手段２４０から、特定されたＤＢＭＳの種類に適した変換ルールを選択する。フォーマット変換手段２６０は、選択された変換ルールに基づき、診断レポートＲをＸＭＬデータに変換し、格納手段２７０に格納する。検索表示手段２８０は、ＸＭＬデータのタグ情報を利用して、診断レポートの検索および表示処理を行う。
【選択図】 図４

Description

本発明は、データベース診断レポート管理システムに関し、特に、様々な種類のデータベース装置に所定の診断用スクリプトを実行させることにより得られる診断レポートを管理するシステムに関する。

コンピュータを利用して様々なビジネスデータを処理する装置として、データベースシステムが広く普及している。データベースシステムは、通常、ネットワーク上にデータベース装置となるサーバを設置し、多数のクライアントコンピュータから、このデータベース装置をアクセスする形態によって構築される。したがって、データベースとして取り扱うべきデータ量が増えれば増えるほど、また、ネットワークを介して接続するクライアントコンピュータの台数が増えれば増えるほど、データベース装置の負担も大きくなる。

近年では、インターネットが、社会的な基幹システムとして機能するようになってきており、インターネット経由で多数のクライアントコンピュータからのアクセスを同時に受け付ける必要があるデータベース装置も少なくない。このような装置が、万一、高負荷によってダウンするような事態が生じると、社会的な影響も無視できなくなる。このような背景事情から、データベース装置の性能を客観的に計測することは重要であり、データベース診断システムを用いて、定期的にデータベース装置の性能を計測して診断することが行われている。

データベース装置となるサーバ性能を計測する一般的な手法は、サーバに対して種々の処理要求を与え、その処理に対するサーバの応答速度やスループットを計測する方法によって行われる。たとえば、下記特許文献１には、サーバに処理要求を送信した時刻と、この処理要求に対する応答データの受信時刻との差から、応答時間を算出し、サーバの性能を計測する手法が開示されている。また、下記特許文献２には、待ち時間を発生させない状況下での同時処理数とスループットと応答時間との関係をエミュレーション評価することにより、サーバの性能を計測する手法が開示されている。

一般的なデータベースに対しては、通常、ＳＱＬ（Structured Query Language）文として記述された所定の診断用スクリプトを与え、その実行結果として得られる診断レポートを解析することにより診断が行われる。ＳＱＬは、ＩＳＯにより標準規格となっているデータベース照会言語であり、現在市販されている多くのデータベースが対応している。
特開平１０−１４３４０１号公報 特許第２９２３８７４号公報

上述したように、データベース装置に対する診断は、通常、ＳＱＬで記述された診断用スクリプトを実行させ、その結果として得られる診断レポートを解析することによりなされる。しかしながら、ＳＱＬには各社独自の拡張規格による方言が存在するため、個々のデータベースが採用しているＤＢＭＳ（DataBase Management System：データベース管理システム）の種類によって、得られる診断レポートの書式は様々である。したがって、従来は、様々な種類のデータベース装置から得られた診断レポートを一元管理することができず、異なるデータベース装置についての診断結果を比較検討するような作業を行うことが困難であった。また、診断レポートは、通常、テキストデータの形式で出力されるので、同一のデータベース装置について過去に実施された診断の結果を、時系列的に解析するような作業も困難であった。

そこで本発明は、様々な種類のデータベース装置から得られた診断レポートを一元管理するとともに、時系列的な解析も容易に行うことができるデータベース診断レポート管理システムを提供することを目的とする。

(1) 本発明の第１の態様は、データベース装置に所定の診断用スクリプトを実行させることにより得られる診断レポートを管理するデータベース診断レポート管理システムにおいて、
診断対象となったデータベース装置からテキストデータとして出力される診断レポートを受信する診断レポート受信手段と、
種々のデータベース装置に用いられているＤＢＭＳの種類を特定するための種類特定情報を記憶する種類特定情報記憶手段と、
この種類特定情報を参照して、診断レポート受信手段が受信した診断レポートから、診断対象となったデータベース装置に用いられているＤＢＭＳの種類を特定する種類特定手段と、
種々のデータベース装置からテキストデータとして出力される診断レポートを、所定の共通フォーマットで記述された診断レポートに変換するための変換ルールを、ＤＢＭＳの種類ごとにそれぞれ用意した変換ルール記憶手段と、
この変換ルール記憶手段から、種類特定手段によって特定された種類に対応する変換ルールを選択する変換ルール選択手段と、
この変換ルール選択手段が選択した変換ルールに基づいて、診断レポート受信手段が受信した診断レポートのフォーマットを、共通フォーマットに変換するフォーマット変換手段と、
このフォーマット変換手段による変換後の診断レポートを格納する診断レポート格納手段と、
この診断レポート格納手段に格納されている診断レポートを検索して表示する診断レポート検索表示手段と、
を設けるようにしたものである。

(2) 本発明の第２の態様は、上述の第１の態様に係るデータベース診断レポート管理システムにおいて、
種類特定情報記憶手段が、種々のデータベース装置に用いられているＤＢＭＳ名のリストと、診断レポート内に記載されるＤＢＭＳ名の見出しを構成する見出し文字列と、を種類特定情報として記憶しており、
種類特定手段が、診断レポートを構成するテキストデータの先頭から、種類特定情報内の見出し文字列を検索し、この見出し文字列を検索開始位置として、種類特定情報内のリストに掲載されているＤＢＭＳ名のいずれかと一致する文字列を検索し、当該一致する文字列をＤＢＭＳ名として認識し、これに後続する数字をそのバージョンと認識することにより、診断対象となったデータベース装置に用いられているＤＢＭＳの種類を特定するようにしたものである。

(3) 本発明の第３の態様は、上述の第１または第２の態様に係るデータベース診断レポート管理システムにおいて、
診断レポートの共通フォーマットとして、ＸＭＬ形式のフォーマットを用い、テキストデータとして出力される診断レポート内の各項目を、それぞれタグ情報に変換するようにしたものである。

(4) 本発明の第４の態様は、上述の第３の態様に係るデータベース診断レポート管理システムにおいて、
フォーマット変換手段が、テキストデータ形式の診断レポートに含まれているＤＢＭＳ名およびそのバージョンを示す情報を、それぞれＤＢＭＳ名であることを示すタグ情報およびバージョンであることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すようにしたものである。

(5) 本発明の第５の態様は、上述の第３または第４の態様に係るデータベース診断レポート管理システムにおいて、
フォーマット変換手段が、テキストデータ形式の診断レポートに含まれているデータベース識別情報を、データベース識別情報であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すようにしたものである。

(6) 本発明の第６の態様は、上述の第５の態様に係るデータベース診断レポート管理システムにおいて、
データベース識別情報として、データベースサーバのＩＰアドレス、データベース名およびインスタンス名を用いるようにしたものである。

(7) 本発明の第７の態様は、上述の第３〜第６の態様に係るデータベース診断レポート管理システムにおいて、
フォーマット変換手段が、テキストデータ形式の診断レポートに含まれているスクリプト実行時間を、スクリプト実行時間であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すようにしたものである。

(8) 本発明の第８の態様は、上述の第３〜第７の態様に係るデータベース診断レポート管理システムにおいて、
フォーマット変換手段が、変換対象となった診断レポートごとに、それぞれ当該診断レポートのシリアル番号を示すカウンタ値を発行し、この発行したカウンタ値を、カウンタ値であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すようにしたものである。

(9) 本発明の第９の態様は、上述の第３〜第８の態様に係るデータベース診断レポート管理システムにおいて、
フォーマット変換手段が、変換対象となった診断レポートについて、ＤＢＭＳの種類およびデータベース識別情報の組み合わせを認識し、
認識した組み合わせと同一の組み合わせをもった診断レポートが、既に診断レポート格納手段に格納されている場合には、当該既存の診断レポートに含まれているデータベースＩＤと同一のデータベースＩＤを発行し、
認識した組み合わせと同一の組み合わせをもった診断レポートが、まだ診断レポート格納手段に格納されていない場合には、新たなデータベースＩＤを発行し、
この発行したデータベースＩＤを、データベースＩＤであることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すようにしたものである。

(10) 本発明の第１０の態様は、上述の第３〜第９の態様に係るデータベース診断レポート管理システムにおいて、
診断レポート検索表示手段が、タグ情報を利用した検索機能を有するようにしたものである。

(11) 本発明の第１１の態様は、上述の第１〜第１０の態様に係るデータベース診断レポート管理システムにおいて、
診断レポート検索表示手段が、所定の表示書式を示すスタイルシートに基づいて、表示対象となる診断レポートをＨＴＭＬ形式に変換し、Ｗｅｂページ上で表示を行う機能を有するようにしたものである。

(12) 本発明の第１２の態様は、上述の第１〜第１１の態様に係るデータベース診断レポート管理システムとしてコンピュータを機能させるためのプログラムを用意し、当該プログラムをコンピュータ読み取り可能な記録媒体に記録して配付できるようにしたものである。

以上のとおり、本発明に係るデータベース診断レポート管理システムによれば、個々の
データベース装置から得られた診断レポートは、共通フォーマットに変換された上で格納されることになるので、様々な種類のデータベース装置から得られた診断レポートを一元管理することができ、時系列的な解析も容易に行うことができる。

以下、本発明を図示する実施形態に基づいて説明する。図１は、４つの異なるデータベース装置Ｄ１〜Ｄ４に対する診断を行う際の処理手順を示すブロック図である。データベース装置（データベースサーバ）は、所定のＯＳの管理下で動作するサーバに、ＤＢＭＳ（DataBase Management System：データベース管理システム）を組み込むことにより構築される。現在、主なＤＢＭＳとしては、日本オラクル社のOracle（登録商標）、マイクロソフト社のSQL Server（登録商標）、サイベース社のAdaptive Server（登録商標）などが利用されており、これらＤＢＭＳを動作させるサーバ用ＯＳとしては、ＵＮＩＸ（登録商標）、Windows（登録商標）NT/2000、NetWare（登録商標）などが利用されている。ただ、ここでは、説明の便宜上、「ＸＸＸ」，「ＹＹＹ」，「ＺＺＺ」なる３通りのＤＢＭＳが利用されているケースについて、以下の説明を行うことにする。

図示の例の場合、データベース装置Ｄ１には、ＤＢＭＳ「ＸＸＸのバージョン１．０」が、データベース装置Ｄ２には、ＤＢＭＳ「ＸＸＸのバージョン２．０」が、データベース装置Ｄ３には、ＤＢＭＳ「ＹＹＹのバージョン１．０．１」が、データベース装置Ｄ４には、ＤＢＭＳ「ＺＺＺのバージョン６．４」が、それぞれ組み込まれている。各データベース装置に対する診断は、それぞれＳＱＬ（Structured Query Language）で記述された診断用スクリプトを与えることにより実行される。図示の例では、データベース装置Ｄ１〜Ｄ４に対して、それぞれ診断用スクリプトＳ１〜Ｓ４を与えた例が示されている。診断用スクリプトは、データベース装置に直接読み込ませるようにしてもよいし、ネットワーク経由で、別のコンピュータからデータベース装置へと送信するようにしてもかまわない。

図２は、一般的な診断用スクリプトの構成例を示すブロック図である。図示のとおり、この診断用スクリプトは、第１のＳＱＬ文〜第ＮのＳＱＬ文まで、合計Ｎ個のＳＱＬ文を羅列したファイルになっている。このような診断用スクリプトが与えられたデータベース装置は、このスクリプトを構成するＳＱＬ文を順次実行し、その実行結果を診断レポートとして出力する。ＳＱＬ文の実体は、データベースに対する種々の問い合わせ命令であり、データベース装置は、この問い合わせ命令に応じて、データの検索処理などを実行し、その結果を診断レポートの形式で出力することになる。データベース装置の性能評価に関する情報が得られるようなＳＱＬ文によって診断用スクリプトを構成しておけば、性能評価の材料となる数値（たとえば、バッファキャッシュのヒット率、ログバッファの待ち時間など）が診断レポートとして返されることになる。

診断レポートは、通常、テキストデータの形式で返される。図３に示す診断レポート１は、所定の診断用スクリプトに応じてデータベース装置から返された診断レポートの一例を模式的に示すものである。この例では、個々のＳＱＬ文に対する応答結果は、いずれも「□」で囲われた見出し文から始まるテキストデータとして与えられる。たとえば、第１のＳＱＬ文に対する応答結果は、「□開始日時□」なる見出しから始まっており、第２のＳＱＬ文に対する応答結果は、「□データベース種類情報□」なる見出しから始まっており、第３のＳＱＬ文に対する応答結果は、「□データベース識別情報□」なる見出しから始まっている。

この例における第１〜第３のＳＱＬ文は、いわばデータベースに対する診断を実施する上での書誌情報を応答結果として求める命令であり、具体的には、図示のとおり、開始日時、データベース種類情報、データベース識別情報を求める命令である。ここで、開始日時は、文字どおり、データベースに対する診断を開始した日時を示す情報であり、図示の例の場合、「２００３年１２月４日１２時３３分１８秒」に診断が開始されたことが示されている。また、データベース種類情報は、診断対象となったデータベース装置に組み込まれているＤＢＭＳの種類（ＤＢＭＳ名およびそのバージョン）を示す情報であり、図示の例の場合、「ＸＸＸ １．０」なる種類のＤＢＭＳが用いられていることが示されている。一方、データベース識別情報は、診断対象となったデータベースを特定するための情報であり、具体的には、データベースサーバのＩＰアドレス、診断対象データベースについてのデータベース名およびインスタンス名を示す情報となっている。図示の例の場合、ＩＰアドレス「192.168.20.13」、データベース名「ADDRESS BOOK」、インスタンス名「AAA」というデータベース識別情報が示されている。

一方、この例における第４のＳＱＬ文以降は、本来の診断のための命令であり、図示のとおり、各ＳＱＬ文に対する応答結果は、それぞれ「□表１□」，「□表２□」，「□表３□」，…という形式のテキストデータとして得られている。各ＳＱＬ文の実体は、データベースに対する問い合わせ命令であるため、第４のＳＱＬ文以降に対する応答結果は、「特定の項目に対する値」という形式で与えられる。たとえば、図示の例の場合、第４のＳＱＬ文に対する応答結果は、項目１、項目２、項目３という３つの項目のそれぞれについて、３つずつの値（値１１〜値１３，値２１〜値２３，値３１〜値３３）が返されており、第５のＳＱＬ文に対する応答結果は、単一の項目１について、４つの値（値１１〜値１４）が返されている。

ここで、この診断レポート１における見出し文（個々のＳＱＬ文に対する応答結果の開始行を示す「□」で囲まれた文字列）の書式は、診断スクリプト内のＳＱＬ文に依存して定まるので、この診断スクリプト内のＳＱＬ文の書式を統一しておけば、異なる種類のデータベース装置からの診断レポートであっても、共通の書式にすることが可能である。しかしながら、この見出し文に続く応答結果を示すデータ本体部分の書式は、各データベースが利用するＤＢＭＳの種類（ＤＢＭＳ名およびそのバージョン）に依存して定まることになるので、データベース装置の種類が異なれば、書式も異なったものとなる。

図１に示す例では、データベース装置Ｄ１〜Ｄ４は、それぞれ診断用スクリプトＳ１〜Ｓ４（ＳＱＬ文）の実行結果として、診断レポートＲ１〜Ｒ４（テキストデータ）を出力している。このように複数のデータベース装置に対して診断を行う場合、ＳＱＬには各社独自の拡張規格による方言が存在するため、実際には、個々のデータベース装置が採用しているＤＢＭＳの種類や、サーバの基幹となるＯＳの種類によって、それぞれ異なるＳＱＬ文を用意しなければならない。また、各データベース装置から返される診断レポートの書式も、上述したとおり、ＤＢＭＳの種類によって異なったものになる。

たとえば、データベース装置Ｄ１（使用するＤＢＭＳは、ＸＸＸのバージョン１．０）から出力された診断レポートＲ１が、図３の診断レポート１のような書式であったとしても、データベース装置Ｄ２（使用するＤＢＭＳは、ＸＸＸのバージョン２．０）から出力される診断レポートＲ２は、バージョンの違いから、通常、完全には同一の書式にはならない。まして、使用するＤＢＭＳが異なるデータベース装置Ｄ３，Ｄ４から出力される診断レポートＲ３，Ｒ４の書式は、診断レポートＲ１の書式とはかなり異なったものになる。このため、従来は、様々な種類のデータベース装置から得られた診断レポートを一元管理することができず、異なるデータベース装置についての診断結果を比較検討することが困難であった。また、診断レポートがテキストデータの形式であったため、過去に実施された診断の結果を時系列的に解析することも困難であった。

本発明の主眼は、様々な種類のデータベース装置から得られた診断レポートを、検索に適した共通フォーマットに変換して一元管理することにより、異なるデータベース装置についての診断結果を比較検討したり、過去に実施された診断の結果を時系列的に解析したりすることを容易にすることにある。

図４は、本発明の一実施形態に係るデータベース診断レポート管理システムの基本構成を示すブロック図である。診断対象データベースに対する診断処理は、診断実行システム１００によって実行される。診断実行システム１００は、ＳＱＬ文により構成された診断用スクリプトＳを、診断対象データベースＤに与えて実行させる機能を有する。診断対象データベースＤは、与えられた診断用スクリプトＳを構成するＳＱＬ文を逐次実行し、その結果をテキストデータからなる診断レポートＲとして返すことになる。図示の例では、診断対象データベースは、「ＤＢＭＳ名：ＸＸＸ、バージョン１．０」という種類のＤＢＭＳを用いており、ＩＰアドレス「192.168.20.13」でアクセス可能なサーバ装置上に、「ADDRESS BOOK」なるデータベース名、「AAA」なるインスタンス名で格納されている。このようなデータベースから返される診断レポートは、たとえば、図３に示す診断レポート１のようなものになる。

本発明に係るデータベース診断レポート管理システム２００は、このような診断レポートを一元管理する機能をもったシステムであり、図４に示すとおり、診断レポート受信手段２１０、種類特定情報記憶手段２２０、種類特定手段２３０、変換ルール記憶手段２４０、変換ルール選択手段２５０、フォーマット変換手段２６０、診断レポート格納手段２７０、診断レポート検索表示手段２８０の各手段によって構成される。もっとも、これらの各手段は、コンピュータに所定のプログラムを組み込むことにより実現されるものであり、実用上、本発明に係るデータベース診断レポート管理システム２００は、コンピュータハードウエアと、これに組み込まれたソフトウエアとによって実現される。また、当該ソフトウエアプログラムは、コンピュータ読み取り可能な記録媒体に記録して配付したり、電子通信回線を介して配付したりすることが可能である。

診断レポート受信手段２１０は、診断対象となったデータベースＤから出力される診断レポートＲを受信する機能をもった構成要素である。診断レポートＤは、テキストデータのファイルとして出力されるので、診断レポート受信手段２１０は、このテキストデータファイルを受信する機能をもった構成要素であれば、どのような要素で構成してもかまわない。たとえば、ネットワークを介して診断レポートＲを受信するのであれば、診断レポート受信手段２１０は、ネットワーク用インタフェイスにより構成されることになる。あるいは、フロッピディスクなどの記録媒体を仲介させて診断レポートＲを受信するのであれば、磁気ディスクドライブ装置などにより、診断レポート受信手段２１０を構成することができる。

種類特定情報記憶手段２２０は、種々のデータベースに用いられているＤＢＭＳの種類を特定するための種類特定情報を記憶する構成要素であり、種類特定手段２３０は、この種類特定情報を参照して、診断レポート受信手段２１０が受信した診断レポートＲから、診断対象となったデータベースＤに用いられているＤＢＭＳの種類を特定する処理を行う構成要素である。ここに示す実施形態の場合、種類特定情報記憶手段２２０には、図５に示すように、診断レポートＲ内に記載されるＤＢＭＳ名の見出しを構成する見出し文字列と、種々のデータベースに用いられているＤＢＭＳ名のリストとが、種類特定情報として記憶されており、種類特定手段２３０は、これらの情報に基づいて、ＤＢＭＳの種類を特定する処理を行うことになる。

この場合、種類特定手段２３０は、次のような手順により、ＤＢＭＳの種類を特定することができる。まず、診断レポートＲを構成するテキストデータの先頭から、図５に示されている見出し文字列「□データベース種類情報□」を検索する。そして、この見出し文字列を検索開始位置として、図５に示されているＤＢＭＳ名のリストに掲載されているＤＢＭＳ名「ＸＸＸ」，「ＹＹＹ」，「ＺＺＺ」のいずれかと一致する文字列を検索し、当該一致する文字列をＤＢＭＳ名として認識し、これに後続する数字をそのバージョンと認識することにより、診断対象となったデータベースＤに用いられているＤＢＭＳの種類を特定する。

たとえば、図３に示す診断レポート１に対して、上述の手順を実施すると、第４行目に見出し文字列「□データベース種類情報□」が検索されることになる。そこで、この見出し文字列を検索開始位置として、リストに掲載されているＤＢＭＳ名「ＸＸＸ」，「ＹＹＹ」，「ＺＺＺ」のいずれかと一致する文字列を検索すると、第６行目に「ＸＸＸ」なるＤＢＭＳ名が検索される。そこで、これに後続する数字「１．０」をバージョンと認識することにより、診断対象となったデータベースＤに用いられているＤＢＭＳの種類が「ＸＸＸのバージョン１．０」であることを特定できる。

前述したとおり、診断レポート中の見出し文は、個々のＳＱＬ文に対する応答結果の開始行を示すものであり、その書式は、診断スクリプト内のＳＱＬ文に依存して定まる。したがって、診断実行システム１００から各データベースに与える診断用スクリプト内の「データベース種類情報を要求するＳＱＬ文」において、「□データベース種類情報□」なる共通した見出し文字列を指定しておくようにすれば、データベースの種類にかかわらず、診断レポート内のデータベース種類情報を示す見出しは、必ず「□データベース種類情報□」なる共通した見出し文字列になる。したがって、図５に示す見出し文字列は、結局、ＳＱＬ文で指定した共通の見出し文字列ということになる。

このように、図３に示す診断レポート１において、「□」で囲まれた見出しは、データベースの種類にかかわらず共通した文字列になる。しかしながら、この見出しに続く応答結果を示すデータ本体部分のフォーマットは、各データベースが利用するＤＢＭＳの種類（ＤＢＭＳ名およびそのバージョン）に応じて様々なものになる。フォーマット変換手段２６０は、この様々なフォーマットを共通フォーマットに変換する処理を行うことになる。

このようなフォーマット変換を行うためには、ＤＢＭＳの種類ごとに変換ルールを用意しておく必要がある。変換ルール記憶手段２４０は、このような変換ルールを用意するための手段であり、種々のデータベースからテキストデータとして出力される診断レポートを、所定の共通フォーマットで記述された診断レポートに変換するための変換ルールを、ＤＢＭＳの種類ごとにそれぞれ記憶している。図６は、変換ルール記憶手段２４０の記憶内容の一例を示すブロック図である。この例では、合計７種類の変換ルールが記憶されている。各変換ルールは、それぞれ特定のＤＢＭＳの種類に対応している。図示の例では、ＤＢＭＳの名称としては、「ＸＸＸ」，「ＹＹＹ」，「ＺＺＺ」なる３種類しか示されていないが、一般に、同一名称のＤＢＭＳでも、バージョンが異なれば診断レポートのフォーマットも異なることが多いため、この実施形態では、同一名称のＤＢＭＳでも各バージョンごとに、それぞれ別個の変換ルールを用意している。

変換ルール選択手段２５０は、変換ルール記憶手段２４０から、種類特定手段２３０によって特定された種類に対応する変換ルールを選択する機能を有し、フォーマット変換手段２６０は、この変換ルール選択手段２５０が選択した変換ルールに基づいて、診断レポート受信手段２１０が受信した診断レポートＲのフォーマットを、共通フォーマットに変換する機能を有する。こうして、共通フォーマットに変換された診断レポートは、診断レポート格納手段２７０に格納され、必要に応じて、診断レポート検索表示手段２８０により検索され、ディスプレイ画面上に表示される。

ここに示す実施形態では、診断レポートの共通フォーマットとして、ＸＭＬ形式のフォーマットを用い、テキストデータとして出力される診断レポート内の各項目を、それぞれタグ情報に変換する処理を行っている。したがって、変換ルール記憶手段２４０に用意すべき各変換ルールは、特定バージョンの特定ＤＢＭＳが、テキストデータとして出力する診断レポートの書式を踏まえて、当該診断レポートの内容を、ＸＭＬデータに変換するためのルールということになる。

図７は、図３に示すテキストデータからなる診断レポート１を、ＸＭＬデータに変換した一例を示す図である。ＸＭＬデータの特徴は、一対のタグ情報に挟まれた部分が、当該タグ情報で示された内容を示すデータになっている点である。たとえば、図７の第１行目に示されているタグ情報＜診断レポート＞と、最終行に示されているタグ情報＜／診断レポート＞との間に挟まれた部分（すなわち、図７に示す診断レポートの全体部分）は、この一対のタグ情報により、「診断レポート」を示すデータであることが示されている。

また、図７の第４行目に示されているタグ情報＜メタデータ＞と、第１３行目に示されているタグ情報＜／メタデータ＞との間に挟まれた部分（すなわち、第５行目〜第１２行目）は、「メタデータ」を示すデータである。この実施形態における「メタデータ」は、診断レポート上の書誌情報を示すデータとしての役割を有しており、図３の診断レポート１に示されている第１〜第３のＳＱＬ文に対する応答結果を示すデータに対応する。以下、この「メタデータ」の具体的な構成を順に説明する。

まず、図７の第５行目には、＜ＤＢＭＳ名＞および＜／ＤＢＭＳ名＞なるタグ情報に挟まれて、「ＸＸＸ」なるデータが記述されており、第６行目には、＜バージョン＞および＜／バージョン＞なるタグ情報に挟まれて、「１．０」なるデータが記述されている。これらのデータは、図３に示す診断レポート１の第６行目に記載されている「ＸＸＸ １．０」なるデータに対応するものである。フォーマット変換手段２６０は、その変換プロセスにおいて、図３に示す診断レポート１の第６行目に記載されている「ＸＸＸ １．０」なるデータを、図７に示す診断レポート１の第５行目に記載されている「＜ＤＢＭＳ名＞ＸＸＸ＜／ＤＢＭＳ名＞」なるデータ、および第６行目に記載されている「＜バージョン＞１．０＜／バージョン＞」なるデータに変換する処理を実行することになる。

このような変換処理は、図６に示されている８組の変換ルールのうち、「ＸＸＸ １．０の変換ルール」に基づいて行われる。当該変換ルールは、「ＸＸＸのバージョン１．０」では、図３に示すようなフォーマットで診断レポートが出力されることを踏まえて、予め作成しておけばよい。具体的には、たとえば、テキストデータとして与えられた診断レポート上に、「□データベース種類情報□」に続いて「BANNER」なる単語があった場合には、その次の単語「ＸＸＸ」を、タグ情報＜ＤＢＭＳ名＞とタグ情報＜／ＤＢＭＳ名＞との間に挟んだＸＭＬデータを生成し、更にその次の数値「１．０」を、タグ情報＜バージョン＞とタグ情報＜／バージョン＞との間に挟んだＸＭＬデータを生成せよ、という変換ルールを定めておけば、図３の第４〜６行目のテキストデータ（第２のＳＱＬ文に対する応答結果として得られるデータベース種類情報）を、図７の第５〜６行目のＸＭＬデータに変換することができる。

同様の変換処理により、図３の第７〜１０行目のテキストデータ（第３のＳＱＬ文に対する応答結果として得られるデータベース識別情報）を、図７の第７〜１１行目のＸＭＬデータに変換することができ、図３の第１〜３行目のテキストデータ（第１のＳＱＬ文に対する応答結果として得られる開始日時）を、図７の第１２行目のＸＭＬデータに変換することができる。

結局、ここに示す実施形態では、フォーマット変換手段２６０は、テキストデータ形式の診断レポートに含まれているＤＢＭＳ名およびそのバージョンを示す情報を、それぞれＤＢＭＳ名であることを示すタグ情報およびバージョンであることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出す機能と、テキストデータ形式の診断レポートに含まれているデータベース識別情報（具体的には、データベースサーバのＩＰアドレス、データベース名およびインスタンス名）を、データベース識別情報であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出す機能と、テキストデータ形式の診断レポートに含まれているスクリプト実行時間を、スクリプト実行時間であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出す機能と、を有していることになる。

一方、図３の第１１行目以下は、診断レポート本体部というべき部分であり、診断対象となったデータベースの具体的な性能を示す個々の項目について、それぞれ得られた値を記述した部分である。この診断レポート本体部は、やはりＸＭＬ形式のデータに変換され、図７の第１４行目以降（矩形で囲って示した部分）に配置される。図８は、このＸＭＬ形式のデータに変換された診断レポート本体部を示す図である。図示のとおり、各ＳＱＬ文に対する応答結果を示すデータは、それぞれ＜表ｎ＞および＜／表ｎ＞なるタグ情報で囲われたデータとして記述されている（ｎ＝１，２，３…）。また、個々の項目についての値は、それぞれ＜項目ｎ＞および＜／項目ｎ＞なるタグ情報で囲われたデータとして記述されている。このように、テキストデータとして出力された診断レポート内の各項目を、それぞれタグ情報に変換してＸＭＬ形式のデータを作成するようにすれば、これらタグ情報に囲まれて表示された値が、意味のある特定の項目についての値であることを示すことができ、後の検索処理の便宜を向上させることができる。

図９は、別な種類のデータベースからテキストデータの形式で出力された診断レポート２を示す図であり、図１０は、この図９に示す診断レポート２を、ＸＭＬデータに変換した例を示す図であり、図１１は、図１０内の診断レポート本体部の具体的内容を示す図である。図９に示す診断レポート２を、図３に示す診断レポート１と比較すると、いずれもほぼ同じ診断内容をもったＳＱＬ文の実行結果を示すテキストデータであるが、細かな書式が若干異なっていることがわかる。その理由は、図３に示す診断レポート１が、「ＸＸＸのバージョン１．０」という種類のＤＢＭＳを利用しているデータベース装置についての診断結果であるのに対し、図９に示す診断レポート２が、「ＺＺＺのバージョン６．４」という種類のＤＢＭＳを利用しているデータベース装置についての診断結果であるためである。

いずれも、「□」で囲まれた見出し部分の書式は共通するものの（前述したとおり、この見出し部分の書式は、ＳＱＬ文によって指定することができるので、ＤＢＭＳが異なっても共通化することが可能である）、その他の部分の書式が若干異なっている。たとえば、図３の第２行目の「FROMDATETIME」および第５行目の「BANNER」なる文字列は、図９では、「START TIME」および「DATA BASE」なる文字列となっているし、図３の第８〜１０行目の「IP」，「DBNAME」，「INSTANCE」なる文字列は、図９では、「IP:」，「NAME:」，「INST:」なる文字列になっている。また、第４のＳＱＬ文に対する応答結果を両者で比較すると、図３に示す診断レポート１では、「項目１ 値１１ 値１２ 値１３ 項目２ 値２１ 値２２ 値２３ 項目３ 値３１ 値３２ 値３３」のような順に並んでいるのに対して、図９に示す診断レポート２では、「項目１ 項目２ 項目３」なる行に続いて、「値１１ 値２１ 値３１」なる行、「値１２ 値２２ 値３２」なる行、「値１３ 値２３ 値３３」なる行、という順に並んでいる。

しかしながら、フォーマット変換手段２６０によって、図９に示す診断レポート２に対する変換プロセスを実施する際には、変換ルール選択手段２５０によって、「ＺＺＺ ６．４の変換ルール」が選択されることになり、当該ルールに基づく変換処理が実行されることになるので、結局、図１０に示すようなＸＭＬデータへの変換が支障なく行われることになる。ここで、図７に示すＸＭＬ形式の診断レポート１と、図１０に示すＸＭＬ形式の診断レポート２とを比較すると、第１〜１３行目までの書誌情報の部分の書式は完全に一致していることがわかる。また、図８に示すＸＭＬ形式の診断レポート１の本体部と、図１１に示すＸＭＬ形式の診断レポート２の本体部とを比較すると、項目や値の並び順は相違するものの、一対のタグ情報とこれに囲まれた値との関係という点では、実質的な相違はない。

結局、図７および図８に示す診断レポート１と図１０および図１１に示す診断レポート２とは、一元管理の下で取り扱うことができる共通フォーマットのデータになっている。このように、本発明に係る管理システム２００では、診断レポート格納手段２７０には、一元管理可能な共通フォーマットの形式で、診断レポートが逐次格納されてゆくことになる。

なお、ここに示す実施形態では、フォーマット変換手段２６０が、変換対象となった診断レポートごとに、それぞれ当該診断レポートのシリアル番号を示すカウンタ値を発行し、この発行したカウンタ値を、カウンタ値であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出す機能を有している。図７の第２行目に示されている「＜カウンタ＞365＜／カウンタ＞」なる記述における一対のタグ情報＜カウンタ＞，＜／カウンタ＞に挟まれた「３６５」は、このカウンタ値を示している。すなわち、この図７に示す診断レポート１は、診断レポート格納手段２７０に格納される第３６５番目の診断レポートということになる。

フォーマット変換手段２６０は、診断レポート格納手段２７０に格納されている診断レポートの総数を常に認識し、新たな診断レポートについてのフォーマット変換を行う際には、「当該総数＋１」という新たなカウンタ値を発生し、これをタグ情報＜カウンタ＞，＜／カウンタ＞の間に挟んだ形で追加する処理を実行することになる。図１０の第２行目に示されている「＜カウンタ＞366＜／カウンタ＞」も、同様の方法で診断レポート格納手段２７０により追加されたデータであり、当該診断レポート２が、診断レポート格納手段２７０に格納される第３６６番目の診断レポートであることを示している。

フォーマット変換手段２６０は、上述したカウンタ値の他に、データベースＩＤをタグ情報とともに付加する機能も有している。本願における「データベースＩＤ」とは、いわば個々のデータベースを識別するためのＩＤであり、「ＤＢＭＳの種類」および「データベース識別情報」の組み合わせごとにユニークとなるように発行されるＩＤということになる。既に述べたとおり、「ＤＢＭＳの種類」とは、ＤＢＭＳ名およびそのバージョンによって特定される事項であり、「データベース識別情報」とは、データベースサーバのＩＰアドレス、データベース名、インスタンス名によって特定される事項である。したがって、データベースＩＤが一致した場合、別言すれば、「ＤＢＭＳの種類」および「データベース識別情報」の組み合わせが完全に一致した場合、それは同一のデータベースサーバ上に構築された、同一のＤＢＭＳを利用した、同一のデータベース、であることを意味する。

たとえば、図７の第３行目に示されている「＜データベースＩＤ＞15＜／データベースＩＤ＞」なる記述における一対のタグ情報＜データベースＩＤ＞，＜／データベースＩＤ＞に挟まれた「１５」は、このデータベースＩＤを示している。すなわち、この図７に示す診断レポート１は、診断レポート格納手段２７０に格納される第１５番目のデータベースについての診断レポートということになる。前述したカウンタ値が、個々の診断レポート単位で発行されるシリアル番号であるのに対して、このデータベースＩＤは、個々のデータベース単位で発行されるシリアル番号ということになる。別言すれば、データベースＩＤ＝１５で示されるデータベースは、ＩＰアドレスが「192.168.20.13」であるサーバ内のデータベース名「ADDRESS BOOK」およびインスタンス名「AAA」で特定される「ＸＸＸバージョン１．０」なるＤＢＭＳを利用したデータベース、ということになる。

同様に、図１０の第３行目には「＜データベースＩＤ＞8＜／データベースＩＤ＞」と記述されており、この診断レポート２についてのデータベースＩＤが「８」であることが示されているが、このデータベースＩＤ＝８で示されるデータベースは、ＩＰアドレスが「192.168.30.55」であるサーバ内のデータベース名「CONSUMER DATA」およびインスタンス名「EFG」で特定される「ＺＺＺバージョン６．４」なるＤＢＭＳを利用したデータベース、ということになる。

フォーマット変換手段２６０により、このようなデータベースＩＤを発行する処理を行うには、次のような手順を実行すればよい。まず、変換対象となった診断レポートについて、ＤＢＭＳの種類およびデータベース識別情報の組み合わせを認識する。たとえば、図３に示すような診断レポート１が変換対象である場合、ＤＢＭＳの種類は「ＸＸＸバージョン１．０」ということになり、データベース識別情報は「ＩＰアドレス：192.168.20.13、データベース名：ADDRESS BOOK、インスタンス名：AAA」ということになる。続いて、この認識したＤＢＭＳの種類およびデータベース識別情報の組み合わせと同一の組み合わせをもった診断レポートが、既に診断レポート格納手段２７０に格納されているか否かを調べる。そして、もし既に格納されていた場合には、当該既存の診断レポートに含まれているデータベースＩＤと同一のデータベースＩＤを発行すればよい。もし、まだ診断レポート格納手段２７０に格納されていない場合には、新たなデータベースＩＤを発行すればよい。フォーマット変換手段２６０は、こうして発行したデータベースＩＤを、データベースＩＤであることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出す処理を行うことになる。

このように、診断レポート格納手段２７０内に、共通のフォーマットをもったデータとして診断レポートを格納してゆくようにすれば、必要に応じて、診断レポート検索表示手段２８０を用いて、所望の診断レポートを検索し、これを表示させることが可能になる。特に、診断レポートをＸＭＬ形式のデータとして格納すれば、タグ情報を利用した検索を行うことができるので便利である。

たとえば、「ＸＸＸ」なるＤＢＭＳを利用したデータベースの性能を相互に比較してみたいような場合であれば、＜ＤＢＭＳ名＞なるタグ情報で示される値が「ＸＸＸ」である診断レポートを検索すればよいし、「ＸＸＸのバージョン１．０」なるＤＢＭＳを利用したデータベースの性能を相互に比較してみたいような場合であれば、＜ＤＢＭＳ名＞なるタグ情報で示される値が「ＸＸＸ」であり、かつ、＜バージョン＞なるタグ情報で示される値が「１．０」である診断レポートを検索すればよい。あるいは、特定の性能を示す「項目１」の値が特定の範囲の値をとる事例を見つけたい場合であれば、＜項目１＞なるタグ情報で示される値が特定の範囲をとる診断レポートを検索すればよい。

また、ここに示す実施形態では、上述したように、各診断レポートにデータベースＩＤを付与しているので、このデータベースＩＤに基づいて検索することも可能である。たとえば、ある特定のデータベースの管理者は、自分の管理するデータベースについて付されているデータベースＩＤを認識しておくだけで、当該データベースについて過去に行われた診断結果を容易に検索することができる。

たとえば、データベースＩＤ＝１５が付されたデータベースについて、これまでに実施された診断結果を解析してみたい場合であれば、＜データベースＩＤ＞なるタグ情報で示される値が「１５」であるような診断レポートを検索すればよい。図１２は、このような検索結果として得られた診断レポートのうち、＜表１＞なるタグ情報で抽出されたデータのみを表示させた例である。このように、データベースＩＤを用いて検索された診断レポートの情報に対しては、＜表ｎ＞なるタグ情報や＜項目ｎ＞なるタグ情報を用いることにより、更なる絞り込みを行うことができるので、必要な情報のみを選択的に表示させることが可能になる。図１３は、データベースＩＤ＝８を用いて検索された診断レポートの情報のうち、＜表２＞なるタグ情報で抽出されたデータのみを表示させた例である。

なお、実用上は、診断レポート検索表示手段２８０には、所定の表示書式を示すスタイルシートを用意しておくようにし、このスタイルシートを利用して、表示対象となる診断レポートをＨＴＭＬ形式に変換し、Ｗｅｂページ上で表示を行うことができるようにしておくのが好ましい。そうすれば、検索結果を、Ｗｅｂブラウザ機能を有するパソコンなどの一般的な端末装置の画面上に表示させることが可能になる。

４つの異なるデータベースＤ１〜Ｄ４に対する診断を行う際の処理手順を示すブロック図である。 一般的な診断用スクリプトの構成例を示すブロック図である。 所定の診断用スクリプトに応じてデータベース装置から返される診断レポートの一例を示す模式図である。 本発明の一実施形態に係るデータベース診断レポート管理システムの基本構成を示すブロック図である。 図４に示す種類特定情報記憶手段２２０に記憶されている種類特定情報の一例を示す図である。 図４に示す変換ルール記憶手段２４０の記憶内容の一例を示すブロック図である。 図３に示すテキストデータからなる診断レポート１を、ＸＭＬデータに変換した一例を示す図である。 図３に示すテキストデータにおける診断レポート本体部を、ＸＭＬ形式のデータに変換した一例を示す図である。 所定の診断用スクリプトに応じてデータベース装置から返される診断レポートの別な一例を示す模式図である。 図９に示すテキストデータからなる診断レポート２を、ＸＭＬデータに変換した一例を示す図である。 図９に示すテキストデータにおける診断レポート本体部を、ＸＭＬ形式のデータに変換した一例を示す図である。 データベースＩＤ＝１５を用いて検索された診断レポートの情報のうち、＜表１＞なるタグ情報で抽出されたデータのみを表示させた例を示す図である。 データベースＩＤ＝８を用いて検索された診断レポートの情報のうち、＜表２＞なるタグ情報で抽出されたデータのみを表示させた例を示す図である。

符号の説明

１００…診断実行システム
２００…データベース診断レポート管理システム
２１０…診断レポート受信手段
２２０…種類判定情報記憶手段
２３０…種類判定手段
２４０…変換ルール記憶手段
２５０…変換ルール選択手段
２６０…フォーマット変換手段
２７０…診断レポート格納手段
２８０…診断レポート検索手段
Ｄ，Ｄ１〜Ｄ４…データベース装置（データベースサーバ）
Ｒ，Ｒ１〜Ｒ４…診断レポート
Ｓ，Ｓ１〜Ｓ４…診断用スクリプト

Claims (12)

1. データベース装置に所定の診断用スクリプトを実行させることにより得られる診断レポートを管理するシステムであって、
   診断対象となったデータベース装置からテキストデータとして出力される診断レポートを受信する診断レポート受信手段と、
   種々のデータベース装置に用いられているＤＢＭＳの種類を特定するための種類特定情報を記憶する種類特定情報記憶手段と、
   前記種類特定情報を参照して、前記診断レポート受信手段が受信した診断レポートから、診断対象となったデータベース装置に用いられているＤＢＭＳの種類を特定する種類特定手段と、
   種々のデータベース装置からテキストデータとして出力される診断レポートを、所定の共通フォーマットで記述された診断レポートに変換するための変換ルールを、ＤＢＭＳの種類ごとにそれぞれ用意した変換ルール記憶手段と、
   前記変換ルール記憶手段から、前記種類特定手段によって特定された種類に対応する変換ルールを選択する変換ルール選択手段と、
   前記変換ルール選択手段が選択した変換ルールに基づいて、前記診断レポート受信手段が受信した診断レポートのフォーマットを、前記共通フォーマットに変換するフォーマット変換手段と、
   前記フォーマット変換手段による変換後の診断レポートを格納する診断レポート格納手段と、
   前記診断レポート格納手段に格納されている診断レポートを検索して表示する診断レポート検索表示手段と、
   を備えることを特徴とするデータベース診断レポート管理システム。
2. 請求項１に記載の管理システムにおいて、
   種類特定情報記憶手段が、種々のデータベース装置に用いられているＤＢＭＳ名のリストと、診断レポート内に記載されるＤＢＭＳ名の見出しを構成する見出し文字列と、を種類特定情報として記憶しており、
   種類特定手段が、診断レポートを構成するテキストデータの先頭から、前記見出し文字列を検索し、この見出し文字列を検索開始位置として、前記リストに掲載されているＤＢＭＳ名のいずれかと一致する文字列を検索し、当該一致する文字列をＤＢＭＳ名として認識し、これに後続する数字をそのバージョンと認識することにより、診断対象となったデータベース装置に用いられているＤＢＭＳの種類を特定することを特徴とするデータベース診断レポート管理システム。
3. 請求項１または２に記載の管理システムにおいて、
   診断レポートの共通フォーマットとして、ＸＭＬ形式のフォーマットを用い、テキストデータとして出力される診断レポート内の各項目を、それぞれタグ情報に変換することを特徴とするデータベース診断レポート管理システム。
4. 請求項３に記載の管理システムにおいて、
   フォーマット変換手段が、テキストデータ形式の診断レポートに含まれているＤＢＭＳ名およびそのバージョンを示す情報を、それぞれＤＢＭＳ名であることを示すタグ情報およびバージョンであることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すことを特徴とするデータベース診断レポート管理システム。
5. 請求項３または４に記載の管理システムにおいて、
   フォーマット変換手段が、テキストデータ形式の診断レポートに含まれているデータベース識別情報を、データベース識別情報であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すことを特徴とするデータベース診断レポート管理システム。
6. 請求項５に記載の管理システムにおいて、
   データベース識別情報として、データベースサーバのＩＰアドレス、データベース名およびインスタンス名を用いることを特徴とするデータベース診断レポート管理システム。
7. 請求項３〜６のいずれかに記載の管理システムにおいて、
   フォーマット変換手段が、テキストデータ形式の診断レポートに含まれているスクリプト実行時間を、スクリプト実行時間であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すことを特徴とするデータベース診断レポート管理システム。
8. 請求項３〜７のいずれかに記載の管理システムにおいて、
   フォーマット変換手段が、変換対象となった診断レポートごとに、それぞれ当該診断レポートのシリアル番号を示すカウンタ値を発行し、この発行したカウンタ値を、カウンタ値であることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すことを特徴とするデータベース診断レポート管理システム。
9. 請求項３〜８のいずれかに記載の管理システムにおいて、
   フォーマット変換手段が、変換対象となった診断レポートについて、ＤＢＭＳの種類およびデータベース識別情報の組み合わせを認識し、
   認識した組み合わせと同一の組み合わせをもった診断レポートが、既に診断レポート格納手段に格納されている場合には、当該既存の診断レポートに含まれているデータベースＩＤと同一のデータベースＩＤを発行し、
   認識した組み合わせと同一の組み合わせをもった診断レポートが、まだ診断レポート格納手段に格納されていない場合には、新たなデータベースＩＤを発行し、
   この発行したデータベースＩＤを、データベースＩＤであることを示すタグ情報とともに、ＸＭＬ形式のデータとして書き出すことを特徴とするデータベース診断レポート管理システム。
10. 請求項３〜９のいずれかに記載の管理システムにおいて、
    診断レポート検索表示手段が、タグ情報を利用した検索機能を有することを特徴とするデータベース診断レポート管理システム。
11. 請求項１〜１０のいずれかに記載の管理システムにおいて、
    診断レポート検索表示手段が、所定の表示書式を示すスタイルシートに基づいて、表示対象となる診断レポートをＨＴＭＬ形式に変換し、Ｗｅｂページ上で表示を行う機能を有することを特徴とするデータベース診断レポート管理システム。
12. 請求項１〜１１のいずれかに記載のデータベース診断レポート管理システムとしてコンピュータを機能させるためのプログラムおよび当該プログラムを記録したコンピュータ読み取り可能な記録媒体。