JP2006338415A - データベースシステムに接続せずにデータベースシステムをモニタリングする方法 - Google Patents

Abstract

【課題】 データベースシステムに接続せずデータベースシステムをモニタリングする。
【解決手段】 データベースシステムを含む複数の運営サーバと複数のクライアントアプリケーションプロセス間の複数のデータパケットがＳＱＬネットプロトコル（ＳＱＬ Ｎｅｔ Ｐｒｏｔｏｃｏｌ）或いはＢＥＱプロトコルで送受信されるときに，モニタリングプロセスによるスニフィング（Ｓｎｉｆｆｉｎｇ）又は別のパイプゲートウェイプロセスを通してデータパケットらを収集し運営サーバとクライアントアプリケーションプロセス間で伝送される全てのＳＱＬ情報を残しここで測定されるモニタリング項目からデータベースの性能情報を抽出する。データベース，運営サーバ及びネットワークシステムに負荷を全く与えなかったり最小限の負荷で全てのＳＱＬ情報及びデータベース性能情報を効率的にモニタリングすることができる。
【選択図】 図１

Description

本発明はデータベースシステムに接続せずデータベースシステムをモニタリングする方法に関し，特にデータベースを含む複数の運営サーバと複数のクライアントアプリケーションプロセス間のネットワーク，ループバックデバイス及びＩＰＣパイプ上に存在する全てのＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：構造化問合せ言語，以下“ＳＱＬ”と呼ぶ）を抽出して分析及び記録することにより，データベース及びネットワークシステムに負荷を全く与えなかったり負荷を最小限にしたりして，全てのＳＱＬ情報及びデータベース性能情報をモニタリング（Ｍｏｎｉｔｏｒｉｎｇ）するためのデータベースシステムに接続せずデータベースシステムをモニタリングする方法に関する。

一般に，一つの情報処理システムはデータベースを含む複数の運営サーバと，ＳＱＬネットプロトコルを通して運営サーバのデータベースと連結される複数のクライアント端末機と，情報処理システム内の情報保護のためのファイヤウォールなどからなる。この情報処理システムは，イーサネット（Ｅｔｈｅｒｎｅｔ）（登録商標）などで連結されたブロードキャスティング（Ｂｒｏａｄｃａｓｔｉｎｇ）ネットワークを使用する。なお，通常上記データベースは，データベース管理システム（ＤＢＭＳ）を含み，ＳＱＬはオラクルのようなリレーショナルデータベース管理システム（ＲＤＢＭＳ）の標準化した使用者プログラム言語及びインターフェースを含む意味である。以下，データベースシステムとはオラクルデータベース及びデータベース管理システム（ＤＢＭＳ或いはＲＤＢＭＳ）を意味する。

通常，上述の情報処理システムでクライアント端末機のアプリケーションプログラム（Ａｐｐｌｉｃａｔｉｏｎ）がデータベースシステムに接続すると，ＤＢＭＳはデータベースの性能に関連する複数のデータを動的生成しメモリーの特定領域に格納する。特に，オラクルＤＢＭＳ（或いはＲＤＢＭＳ）により生成されるデータベースの性能データはデータベースレベル，セッション（Ｓｅｓｓｉｏｎ）レベル及びＳＱＬレベルに分類されメモリー空間に割り当てられたデータディクショナリー（Ｄａｔａ ｄｉｃｔｉｏｎａｒｙ）にそれぞれ一定時間格納される。

従って，従来のデータベースモニタリング方法（或いはＴｏｏｌ）は上述のデータベース又はＤＢＭＳ（ＲＤＢＭＳ）のメモリーに直接接続し，データベースの性能データをモニタリングする。しかし，このような方式は性能データをモニタリングする間，データベースシステム及び情報処理システム内のネットワーク或いは運営サーバに負荷（ｌｏａｄ）を与える問題点がある。なお，従来のデータベースモニタリング方法では１秒当たり数千，数万件のトランザクション（Ｔｒａｎｓａｃｔｉｏｎ）を処理する情報処理システム内の全てのＳＱＬ情報をモニタリングすることは事実上不可能だという問題点がある。

そこで，本発明はこのような問題に鑑みてなされたもので，その目的とするところは，データベースシステムに接続せずにデータベースシステムを含む複数の運営サーバと複数のクライアントアプリケーションプロセス間のネットワーク，ループバックデバイス及びＩＰＣパイプ上に存在するデータパケットらを収集し，全てのＳＱＬ情報及びデータベース性能情報を抽出することにより，データベース，運営サーバ及びネットワークシステムに負荷を全く与えなかったり負荷を最小限にしたりして，全てのＳＱＬ情報及びデータベース性能情報を効率的にモニタリングするためのデータベースシステムに接続せずにデータベースシステムをモニタリングする方法を提供することにある。

上記課題を解決するために，本発明のある観点によれば，データベースシステムを含む複数の運営サーバと複数のクライアントアプリケーションプロセス間の複数のデータパケットがＳＱＬネットプロトコル（ＳＱＬ＊Ｎｅｔ Ｐｒｏｔｏｃｏｌ）で送受信される時，モニタリングプロセスによるスニフィング（Ｓｎｉｆｆｉｎｇ）を通して複数のデータパケットを収集し，運営サーバとクライアントアプリケーションプロセス間で伝送される全てのＳＱＬ情報及びデータベース性能情報を抽出することを特徴とする，データベースシステムに接続せずデータベースシステムをモニタリングする方法が提供される。

上記スニフィングは，ＳＱＬネットプロトコルを利用する複数のデータパケットを収集し，データベースシステムとクライアントアプリケーションプロセス間のイーサネット（登録商標）ネットワーク上で行われるようにしてもよい。なお，上記スニフィングは，データベースシステムとクライアントアプリケーションプロセス間のループバックデバイス（Ｌｏｏｐｂａｃｋ Ｄｅｖｉｃｅ）上で行われるようにしてもよい。

上記モニタリングプロセスは，モニタリングするネットワークアダプタがループバックデバイスであるか否かを判断する段階と，ネットワークアダプタがループバックデバイスである場合スニフィングモードを実行する段階と，ネットワークアダプタがループバックデバイスでない場合に，“ｐｒｏｍｉｓｃｕｏｕｓ＝ＴＲＵＥ”を設定しスニフィングモードを実行する段階と，プログラムを終了するかを判断する段階と，プログラムを終了しなかった場合にデータパケットの方向がクライアントアプリケーションプロセスから運営サーバへなのか否かを判断する段階と，パケットの方向がクライアントアプリケーションプロセスから運営サーバへだった場合にＳＱＬ情報を抽出する段階と，パケットの方向がクライアントアプリケーションプロセスから運営サーバへでなかった場合にデータベース性能情報を抽出する段階と，を含むようにしてもよい。上記モニタリングプロセスは別のモニタリングシステム又は運営サーバ内で実現されるようにしてもよい。

上記ＳＱＬ情報はデータ定義言語（ＤＤＬ），データ操作言語（ＤＭＬ），データ制御言語（ＤＣＬ），ＰＬＳＱＬ及び問合せ言語（Ｑｕｅｒｙ）からなるＳＱＬログ情報を含むようにしてもよい。

上記ＳＱＬ情報は，データベースシステムに接続したクライアントアプリケーションプロセスの使用者ＩＰ，使用者名，使用者アプリケーションプログラム名，使用時間，運営サーバのホスト名などのセッション情報と各セッション情報及び各インスタンス（Ｉｎｓｔａｎｃｅ）別ＳＱＬログ情報を含むようにしてもよい。

上記データベース性能情報は，運営サーバのデータベースシステムとクライアントアプリケーションプロセス間の平均応答時間及び処理時間，インスタンス別データベース性能統計データを含むようにしてもよい。

上記データベースシステムはオラクルデータベース及びオラクルデータベース管理システム（ＤＢＭＳ，ＲＤＢＭＳ）であってもよい。

上記課題を解決するために本発明の別の観点によれば，データベースシステムを含む複数の運営サーバと複数のクライアントアプリケーションプロセス間のデータパケットらがＢＥＱプロトコルで送受信されるときに，別のパイプゲートウェイプロセスによりデータパケットらを収集し運営サーバとクライアントアプリケーションプロセス間で伝送される全てのＳＱＬ情報及びデータベース性能情報を抽出することを特徴とする，データベースシステムに接続せずデータベースシステムをモニタリングする方法が提供される。

上記パイプゲートウェイプロセスは，ＢＥＱプロトコルを利用するデータパケットらを収集し，データベースシステムとクライアントアプリケーションプロセス間のＩＰＣパイプ上で行われるようにしてもよい。

上記モニタリング方法は，クライアントアプリケーションプロセスがパイプゲートウェイプロセスを実行する段階と，クライアントアプリケーションプロセスとパイプゲートウェイプロセス間の通信パイプを開く段階と，パイプゲートウェイプロセスがオラクルシャドープロセスを実行する段階と，パイプゲートウェイプロセスとオラクルシャドープロセス間の通信パイプを開く段階と，パイプが切れているものがあるか否かを判断する段階と，パイプが切れていなかった場合に，データパケットの方向がクライアントアプリケーションプロセスからオラクルシャドープロセスへなのか否かを判断する段階と，パケットの方向が，クライアントアプリケーションプロセスからオラクルシャドープロセスへだった場合にＳＱＬ情報を抽出する段階と，パケットの方向がクライアントアプリケーションプロセスからオラクルシャドープロセスへではない場合にデータベース性能情報を抽出する段階と，パイプが切れていたら全てのパイプを閉じ終了する段階と，を含むようにしてもよい。

上記パイプゲートウェイプロセスは運営サーバ内で実現するようにしてもよい。上記ＳＱＬ情報は，データ定義言語（ＤＤＬ），データ操作言語（ＤＭＬ），データ制御言語（ＤＣＬ），ＰＬＳＱＬ及び問合せ言語（Ｑｕｅｒｙ）からなるＳＱＬログ情報を含むようにしてもよい。

上記ＳＱＬ情報は，データベースシステムに接続したクライアントアプリケーションプロセスの使用者ＩＰ，使用者名，使用者アプリケーションプログラム，使用時間，運営サーバのホスト名などのセッション情報と各セッション情報及び各インスタンス別のＳＱＬログ情報を含むようにしてもよい。

上記データベース性能情報は，運営サーバのデータベースシステムとクライアントアプリケーションプロセス間の平均応答時間及び処理時間，インスタンス別データベース性能統計データを含むようにしてもよい。上記データベースシステムは，オラクルデータベース及びオラクルデータベース管理システムであってもよい。

以上説明したように本発明によれば，データベースシステムを含む複数の運営サーバと複数のクライアントアプリケーションプロセス間に存在する複数のデータパケットのスニフィングを通して収集し，内部監査及びデータベース性能測定のための全てのＳＱＬ情報及びデータベース性能情報を抽出することにより，データベースシステムに接続せずにデータベース，運営サーバ及びネットワークシステムに負荷を全く与えなかったり，負荷を最小限にしたりしてＳＱＬ情報及びデータベース性能情報を効率的にモニタリングすることができ，モニタリングのためデータベースシステムに連結される別の連結装置を必要としない，データベースシステムをモニタリングする方法を提供することができる。

以下に添付図面を参照しながら，本発明の好適な実施の形態について詳細に説明する。なお，本明細書及び図面において，実質的に同一の機能構成を有する構成要素については，同一の符号を付することにより重複説明を省略する。

図１は本発明の実施形態に係るデータベースモニタリング方法が適用される情報処理システムを概略的に示す構成図である。即ち，本発明に係るデータベースモニタリング方法が適用される情報処理システム１は，イーサネット（登録商標）ネットワーク，ループバックデバイス又はＩＰＣパイプを介して連結される複数の運営サーバ１０及び複数のクライアント端末機３０から構成され，運営サーバ１０はデータベースシステム２０を含む。本発明が適用されるデータベースシステム２０は，オラクルデータベース及びデータベース管理システム（ＤＢＭＳ或いはＲＤＢＭＳ）であり，オラクルデータベース及びＤＢＭＳ（ＲＤＢＭＳ）が運営されるための全ての構成要素（オラクルデータファイル（Ｏｒａｃｌｅ Ｄａｔａ ｆｉｌｅ），インスタンス（Ｉｎｓｔａｎｃｅ），オラクルシャドープロセス（Ｏｒａｃｌｅ Ｓｈａｄｏｗ Ｐｒｏｃｅｓｓ），リスナ（Ｌｉｓｔｅｎｅｒ）など）を含む意味である。

データベースシステム２０とクライアント端末機３０との間の通信は，ＳＱＬネットプロトコル（ＳＱＬ＊Ｎｅｔ Ｐｒｏｔｏｃｏｌ）或いはＢＥＱプロトコルを用いて実現するようにしてもよい。従って，本発明のデータベースモニタリング方法に係るモニタリングプロセスは別のモニタリングシステム４０又は運営サーバ１０内で実現されＳＱＬネットプロトコル又はＢＥＱプロトコルを通して送受信される複数のデータパケット（Ｐａｃｋｅｔ）を収集し，全てのＳＱＬ情報及びデータベース性能情報を抽出する。クライアント端末機３０は，物理的意味のクライアント端末機及びクライアント端末機３０内で実行される全てのクライアントアプリケーションプログラム又はアプリケーションプロセスを含む。

図２〜図５は本発明に係るデータベースモニタリング方法を説明するためのブロック図である。図２はイーサネット（登録商標）ネットワーク上でデータベースシステムをモニタリングする方法を説明するためのブロック図である。図面に示したように，クライアントアプリケーションプロセス３０らがイーサネット（登録商標）上でネットワーク装置を経由し運営サーバ１０内のオラクルデータベースシステム２０と接続する場合，本発明に係るデータベースモニタリング方法はオラクルデータベースシステム２０に接続せずに，イーサネット（登録商標）ネットワーク上でブロードキャスティングされるＳＱＬネットパケット（ＳＱＬ＊Ｎｅｔ Ｐａｃｋｅｔ）をネットワークスニフィングを通して抽出及び分析する。そして，全てのクライアントアプリケーションプロセス３０とオラクルデータベースシステム２０間の全てのＳＱＬを残して，ここで測定されるモニタリング項目から性能情報を抽出する。

即ち，本発明で提案するネットワークスニフィング技法は，イーサネット（登録商標）上の全てのパケットがブロードキャスティングされる特性を利用する。オラクルデータベースシステム２０と全てのクライアント３０間のＳＱＬネットプロトコルでパケットを送受信する時，そのパケットは同一なネットワークにブロードキャスティングされる。本発明のモニタリングシステム４０は，オラクルデータベースシステム２０が位置する同一のネットワークでネットワークアクセスモード（ｎｅｔｗｏｒｋ ａｃｃｅｓｓ ｍｏｄｅ）を“Ｐｒｏｍｉｓｃｕｏｕｓ＝ＴＲＵＥ”のように設定するとブロードキャスティングされた全てのパケットを収集することができる。こうして収集されたパケットを分析し，各クライアント３０とオラクルデータベースシステム２０との送受信内容を一つ一つ適切に分離してモニタリング段階（図６ａ参照）を経ることになる。

図３は，ループバックデバイスでデータベースシステムをモニタリングする方法を説明するためのブロック図である。ループバックデバイス１２でモニタリングする場合，オラクルデータベースシステム２０が存在する運営サーバ１０内のループバックデバイス（Ｉｎｔｅｒｎａｌ Ｎｅｔｗｏｒｋ Ｄｅｖｉｃｅ， １２７．０．０．１： １２）で発生するＳＱＬネットプロトコル（ＳＱＬ＊Ｎｅｔ Ｐｒｏｔｏｃｏｌ）情報を，スニフィングを通して抽出及び分析し，クライアントアプリケーションプロセス３０とオラクルデータベースシステム２０間の全てのＳＱＬを残してここで測定されるモニタリング項目からデータベース性能情報を抽出する。

即ち，本発明で提案するループバックスニフィング技法は，ループバックデバイス１２にループバックアクセスモードをスニフィングモードに設定することにより，運営サーバ１０内で実行されるクライアント間のＳＱＬネットプロトコルで送受信されるパケットを抽出することからなる。こうして収集されたパケットを分析し，各クライアントアプリケーションプロセス３０と運営サーバ１０内のオラクルデータベースシステム２０の送受信内容を一つ一つ適切に分離しモニタリング段階を経ることになる（図６ａ参照）。

本発明に係るスニフィングは，スニフィングモード設定によりＳＱＬネットプロトコル（ＳＱＬ＊Ｎｅｔ Ｐｒｏｔｏｃｏｌ）を通してなる通信のフィルタリング（ｆｉｌｔｅｒｉｎｇ）過程を省略して，全てのデータパケットを収集することである。上記のように収集されたデータパケットから情報処理システム１内の内部監査（Ａｕｄｉｔｉｎｇ）とデータベースシステム２０の性能（Ｐｅｒｆｏｒｍａｎｃｅ）測定のための全てのＳＱＬ情報及びデータベース性能情報を抽出する。なお，本発明に係るイーサネット（登録商標）ネットワーク又はループバックデバイス１２上でのデータベースモニタリング方法は，別のモニタリングシステム４０を通して実現でき，運営サーバ１０内で実行されることもできる。

図４及び図５は本発明に係るＩＰＣパイプ上でデータベースシステムをモニタリングする方法を説明するための構成図である。

クライアントアプリケーションプロセス３０らがＩＰＣパイプ１３を通してオラクルデータベースシステム２０と接続した場合には，ＩＰＣ（Ｉｎｔｅｒ Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ−Ｐｉｐｅ）デバイスで発生するＢＥＱプロトコル情報を抽出及び分析し，オラクルデータベースシステム２０とオラクルデータベースシステム２０が位置する同一の運営サーバ１０で行われるオラクルデータベースシステム２０とクライアントアプリケーションプロセス３０間の全てのＳＱＬを残してここで測定されるモニタリング項目から性能情報を抽出する。

即ち，オラクルデータベースシステム２０が位置する同一の運営サーバ１０でクライアントアプリケーションプロセス３０がループバックデバイスを経由せず接続する場合，オラクルデータベースシステム２０はクライアントアプリケーションプロセス３０と通信するオラクルシャドープロセス（Ｏｒａｃｌｅ Ｓｈａｄｏｗ Ｐｒｏｃｅｓｓ）を生成するが，オラクルが使用するデフォルトシャドーの代わりに別のパイプゲートウェイプロセス（Ｐｉｐｅ Ｇａｔｅｗａｙ Ｐｒｏｃｅｓｓ）１５を生成するように誘導する。パイプゲートウェイプロセス１５が行われることでクライアントアプリケーションプロセス３０と通信するパイプ通路を開く。

パイプゲートウェイプロセス１５とクライアントアプリケーションプロセス３０間のパイプ通路が正常的に開けば，パイプゲートウェイプロセス１５はオラクルシャドープロセスを実行させパイプ通路を開く。結果的に，元のクライアントアプリケーションプロセス３０とオラクルシャドープロセス間の通信時と同一な機能をするようになる。上記の過程が正常的に行われると，オラクルシャドープロセスとクライアントアプリケーションプロセス３０間に通信通路がなされ，二つのプロセス間の通信がパイプゲートウェイを経るので，オラクルシャドープロセスとクライアントアプリケーションプロセス３０同士相互交換されるＢＥＱプロトコルデータを監視することができる。パイプゲートウェイプロセス１５は図６ｂのモニタリング段階を経る。

上記のように収集されたデータパケットらから情報処理システム１内の内部監査（Ａｕｄｉｔｉｎｇ）とデータベースシステム２０の性能（Ｐｅｒｆｏｒｍａｎｃｅ）測定のための全てのＳＱＬ情報及びデータベース性能情報を抽出する。本発明に係るＩＰＣパイプ１３上でのデータベースモニタリング方法は運営サーバ１０内で実行される。

以下，本発明の一実施形態に係るモニタリングプロセスを添付の図面を参照して詳細に説明する。図６ａは本発明に係るイーサネット（登録商標）ネットワーク又はループバックデバイス１２でモニタリングするプロセスを示すフローチャートである。

まず，本発明に係るモニタリングプロセスはモニタリングするネットワークアダプタがループバックデバイス１２であるかを判断する（Ｓ１００）。ネットワークアダプタがループバックデバイス１２である場合，スニフィングモードを実行し（Ｓ１０２），もしネットワークアダプタがループバックデバイス１２でない場合にはイーサネット（登録商標）ネットワークであるので“ｐｒｏｍｉｓｃｕｏｕｓ＝ＴＲＵＥ”を設定し（Ｓ１０１）スニフィングモードを実行する（Ｓ１０２）。

そして，プログラムを終了するかを確認し（Ｓ１０３），プログラムを終了しなかったらデータパケットの方向がクライアントアプリケーションプロセス３０から運営サーバ１０へなのか判断する（Ｓ１０４）。パケットの方向がクライアントアプリケーションプロセス３０から運営サーバ１０へだった場合，全てのＳＱＬ情報を抽出し（Ｓ１０５），パケットの方向がクライアントアプリケーションプロセス３０から運営サーバ１０でなかった場合（即ち，運営サーバ→クライアントアプリケーションプロセスである場合），運営サーバ１０内のオラクルデータベースシステム２０の性能情報を抽出する（Ｓ１０６）。

上記の段階１０５又は段階１０６で全てのＳＱＬ情報及びデータベース性能情報を抽出した後には，プログラムを終了するかを判断する段階（Ｓ１０３）に戻る。

図６ｂは本発明に係るＩＰＣパイプ１３上でモニタリングする方法を示すフローチャートである。モニタリング位置がＩＰＣパイプ１３である場合には，クライアントアプリケーションプロセス３０が，本発明に係るパイプゲートウェイプロセス１５を実行し（Ｓ２００），クライアントアプリケーションプロセス３０とパイプゲートウェイプロセス１５間の通信パイプ１３を開く（Ｓ２０１）。そして，パイプゲートウェイプロセス１５がオラクルシャドープロセスを実行し（Ｓ２０２），パイプゲートウェイプロセス１５とオラクルシャドープロセス間の通信パイプ１３を開く（Ｓ２０３）。パイプ１３の中で切れたものがあるか確認し（Ｓ２０４），パイプ１３が切れていなければＢＥＱプロトコルを利用するデータパケットの方向がクライアントアプリケーションプロセス３０からオラクルシャドープロセスへなのか判断する（Ｓ２０５）。

もし，データパケットの方向がクライアントアプリケーションプロセス３０からオラクルシャドープロセスへだった場合，全てのＳＱＬ情報（ＳＱＬ Ｒｅｑｕｅｓｔ ＆ Ｒｅｓｐｏｎｓｅ）を抽出し（Ｓ２０６），パケットの方向がクライアントアプリケーションプロセスからオラクルシャドープロセスへでない場合には，オラクルデータベースシステム２０の性能情報を抽出する（Ｓ２０７）。

段階２０４でパイプ１３が切れていたら全てのパイプ１３を閉じ（Ｓ２０８），プログラムを終了する。なお，段階２０６及び２０７で全てのＳＱＬ情報及びデータベース性能情報を抽出した後には段階２０４に戻る。

本発明に係る情報処理システム１内の内部監査（Ａｕｄｉｔｉｎｇ）のため抽出されるＳＱＬ情報はデータベースのデータとその構造を定義するデータ定義言語（ＤＤＬ），データベースのデータ検索と修正などを処理するデータ操作言語（ＤＭＬ），データベース使用者の権限を定義するデータ制御言語（ＤＣＬ），ＰＬＳＱＬ，データベーステーブル内の情報に対する問合せ言語（Ｑｕｅｒｙ）などのＳＱＬログ情報を含む。

なお，抽出されるＳＱＬ情報は，データベースシステム２０に接続したクライアント端末機３０の使用者ＩＰ，使用者名，使用者アプリケーションプログラム（クライアントアプリケーションプロセス）名，使用時間，運営サーバ１０のホスト名などのセッション情報を含み，各セッション情報及び各インスタンス別ＳＱＬログ情報を含む。そして，本発明に係るモニタリングプロセスは各ＳＱＬ別（ＤＤＬ，ＤＭＬ，ＤＣＬなど）詳細情報（リターンされたｒｏｗｓ，ｂｙｔｅｓ，応答時間，サーバ処理時間など）と各ＳＱＬ別使用量（個数）変化などを表示できる。

本発明に係るモニタリングプロセスは，運営サーバ１０のデータベースシステム２０とクライアントアプリケーションプロセス３０間の平均応答時間（ｒｅｓｐｏｎｓｅ ｔｉｍｅ）及び処理時間（ｐｒｏｃｅｓｓｉｎｇ ｔｉｍｅ），インスタンス別各種状態情報などを含むデータベース性能情報を表示する。ここで，各種状態情報はオラクルデータベースがデータベースの性能を追跡して測定するため提供する指標で，Ｉ／Ｏ，ＣＰＵ，メモリーなどのリソースと関連する性能情報を示すデータベース性能統計（Ｐｅｒｆｏｒｍａｎｃｅ Ｓｔａｔｉｓｔｉｃｓ）データである。

そして，本発明に係るモニタリングプロセスは，データベース性能測定のため送受信されるデータパケットらの推移分析（Ｉｎ／Ｏｕｔ ｐａｃｋｅｔ ｃｏｕｎｔ， ｂｙｔｅｓ），各インスタンス別使用者接続数，インスタンス別データパケットらの推移分析，インスタンス別応答時間／サーバ処理時間推移分析，使用されたＳＱＬ別詳細情報分析（ｐｅａｋ ｔｉｍｅ ａｎａｌｙｓｉｓ）などを示すことができる。他にも，本発明に係るモニタリングプロセスは各オブジェクト（ｏｂｊｅｃｔ）別接続使用者を探索したり，各インスタンス別現在の使用者，セッション及びＳＱＬを表示したりすることもでき，別の各種データベースチューニング（ｔｕｎｉｎｇ）ツールとも連動することができる。

上述したように本発明によると，複数の運営サーバ１０内のオラクルデータベースシステム２０とクライアントアプリケーションプロセス３０間の通信がイーサネット（登録商標）ネットワーク，ループバックデバイス１２又はＩＰＣパイプ１３上で行われる時，オラクルデータベースシステム２０に直接接続せずに，ＳＱＬネットプロトコル或いはＢＥＱプロトコルを通して送受信されるデータパケットらをスニフィング又は別のパイプゲートウェイプロセスを通して収集する。これにより，運営サーバ１０と，データベースシステム２０及びネットワークに対する負荷を全く与えなかったり，最小限の負荷で情報処理システム１内の内部監査及びデータベース性能測定のための全てのＳＱＬ情報及びデータベース性能情報を抽出したりすることができる。したがって，データベースシステム２０へのモニタリングのための別の連結装置を必要としない。また，１秒当たり数千，数万件のトランザクションが処理されるデータベースシステム２０に対するＳＱＬ情報抽出とデータベース性能測定などのモニタリング作業をシステムの負荷なしで行うことができる。

以上，添付図面を参照しながら本発明の好適な実施形態について説明したが，本発明は係る例に限定されないことは言うまでもない。当業者であれば，特許請求の範囲に記載された範疇内において，各種の変更例または修正例に想到し得ることは明らかであり，それらについても当然に本発明の技術的範囲に属するものと了解される。

本発明の実施形態にかかるデータベースモニタリング方法が適用される情報処理システムを概略的に示す構成図である。 同実施の形態におけるイーサネット（登録商標）ネットワーク上でデータベースシステムをモニタリングする方法を説明するためのブロック図である。 同実施の形態におけるループバックデバイスでデータベースシステムをモニタリングする方法を説明するためのブロック図である。 同実施の形態におけるＩＰＣパイプ上でデータベースシステムをモニタリングする方法を説明するための構成図である。 同実施の形態におけるＩＰＣパイプ上でデータベースシステムをモニタリングする方法を説明するための構成図である。 同実施の形態におけるイーサネット（登録商標）ネットワーク又はループバックデバイスでモニタリングするプロセスを示すフローチャートである。 同実施の形態におけるＩＰＣパイプでモニタリングする方法を示すフローチャートである。

符号の説明

１ 情報処理システム
１０ 運営サーバ
１２ ループバックデバイス
１３ ＩＰＣパイプ
２０ データベースシステム
３０ クライアント端末機

Claims (17)

1. モニタリングプロセスによるスニフィングにより，
   データベースシステムを含む複数の運営サーバと複数のクライアントアプリケーションプロセス間のデータパケットとをＳＱＬネットプロトコルで送受信するときに，
   前記複数のデータパケットを収集し，前記運営サーバと前記クライアントアプリケーションプロセス間で伝送される全てのＳＱＬ情報及びデータベース性能情報を抽出することを特徴とする，データベースシステムに接続せずにデータベースシステムをモニタリングする方法。
2. 前記スニフィングは，
   前記ＳＱＬネットプロトコルを利用する前記複数のデータパケットを収集し，
   前記データベースシステムとクライアントアプリケーションプロセス間のイーサネット（登録商標）ネットワーク上で行われることを特徴とする，請求項１に記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
3. 前記スニフィングは，
   前記ＳＱＬネットプロトコルを利用する前記複数のデータパケットを収集し，
   前記データベースシステムとクライアントアプリケーションプロセス間のループバックデバイスにより行われることを特徴とする，請求項１に記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
4. 前記モニタリングプロセスは，
   モニタリングするネットワークアダプタがループバックデバイスであるか否かを判断する段階と，
   前記ネットワークアダプタがループバックデバイスである場合に，スニフィングモードを実行する段階と，
   前記ネットワークアダプタがループバックデバイスでない場合に，“ｐｒｏｍｉｓｃｕｏｕｓ＝ＴＲＵＥ”を設定しスニフィングモードを実行する段階と，
   プログラムを終了するか否かを判断する段階と，
   前記プログラムを終了しなかった場合に，データパケットの方向が前記クライアントアプリケーションプロセスから運営サーバへなのか否かを判断する段階と，
   前記パケットの方向がクライアントアプリケーションプロセスから運営サーバへだった場合に，前記ＳＱＬ情報を抽出する段階と，
   前記パケットの方向がクライアントアプリケーションプロセスから運営サーバでなかったら前記データベース性能情報を抽出する段階と，
   を含んでなることを特徴とする，請求項１に記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
5. 前記モニタリングプロセスは，
   別のモニタリングシステムまたは前記運営サーバ内で実行されることを特徴とする，請求項１または請求項４のいずれかに記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
6. 前記ＳＱＬ情報は，
   データ定義言語（ＤＤＬ），データ操作言語（ＤＭＬ），データ制御言語（ＤＣＬ），ＰＬＳＱＬ及び問合せ言語（Ｑｕｅｒｙ）からなるＳＱＬログ情報を含むことを特徴とする，請求項１または請求項４のいずれかに記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
7. 前記ＳＱＬ情報は，
   前記データベースシステムに接続した前記クライアントアプリケーションプロセスの使用者ＩＰ，使用者名，使用者アプリケーションプログラム，使用時間，前記運営サーバのホスト名などのセッション情報と，前記各セッション情報及び各インスタンス別の前記ＳＱＬログ情報を含むことを特徴とする，請求項６に記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
8. 前記データベース性能情報は，
   前記運営サーバのデータベースシステムと前記クライアントアプリケーションプロセス間の平均応答時間及び処理時間，インスタンス別データベース性能統計データを含むことを特徴とする，請求項１または請求項４のいずれかに記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
9. 前記データベースシステムは，
   オラクルデータベース及びオラクルデータベース管理システムであることを特徴とする，請求項１または請求項４のいずれかに記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
10. データベースシステムを含む複数の運営サーバと，複数のクライアントアプリケーションプロセス間のデータパケットとがＢＥＱプロトコルで送受信されるときに，
    別のパイプゲートウェイプロセスにより前記複数のデータパケットを収集し，前記運営サーバと前記クライアントアプリケーションプロセス間で伝送される全てのＳＱＬ情報及びデータベース性能情報を抽出することを特徴とする，データベースシステムに接続せずにデータベースシステムをモニタリングする方法。
11. 前記パイプゲートウェイプロセスは，
    前記ＢＥＱプロトコルを利用する前記データパケットらを収集し，
    前記データベースシステムとクライアントアプリケーションプロセス間のＩＰＣパイプ上で行われることを特徴とする，請求項１０に記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
12. 前記モニタリング方法は，
    前記クライアントアプリケーションプロセスが前記パイプゲートウェイプロセスを実行する段階と，
    前記クライアントアプリケーションプロセスと前記パイプゲートウェイプロセス間の通信パイプを開く段階と，
    前記パイプゲートウェイプロセスがオラクルシャドープロセスを実行する段階と，
    前記パイプゲートウェイプロセスとオラクルシャドープロセス間の通信パイプを開く段階と，
    前記パイプが切れているものがあるか否かを判断する段階と，
    前記パイプが切れていなかった場合に，前記データパケットの方向が前記クライアントアプリケーションプロセスから前記オラクルシャドープロセスへなのか否かを判断する段階と，
    前記パケットの方向が，前記クライアントアプリケーションプロセスからオラクルシャドープロセスへだった場合に前記ＳＱＬ情報を抽出する段階と，
    前記パケットの方向が前記クライアントアプリケーションプロセスからオラクルシャドープロセスへではない場合に前記データベース性能情報を抽出する段階と，
    前記パイプが切れていたら全てのパイプを閉じ終了する段階と，
    を含んでなることを特徴とする請求項１０又は請求項１１に記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
13. 前記パイプゲートウェイプロセスは前記運営サーバ内で実現されることを特徴とする，請求項１０または請求項１２のいずれかに記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
14. 前記ＳＱＬ情報は，
    データ定義言語（ＤＤＬ），データ操作言語（ＤＭＬ），データ制御言語（ＤＣＬ），ＰＬＳＱＬ及び問合せ言語（Ｑｕｅｒｙ）からなるＳＱＬログ情報を含むことを特徴とする，請求項１０または請求項１２のいずれかに記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
15. 前記ＳＱＬ情報は，
    前記データベースシステムに接続した前記クライアントアプリケーションプロセスの使用者ＩＰ，使用者名，使用者アプリケーションプログラム，使用時間，前記運営サーバのホスト名などのセッション情報と前記各セッション情報及び各インスタンス別の前記ＳＱＬログ情報を含むことを特徴とする，請求項１４に記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
16. 前記データベース性能情報は，
    前記運営サーバのデータベースシステムと前記クライアントアプリケーションプロセス間の平均応答時間及び処理時間，インスタンス別データベース性能統計データを含むことを特徴とする，請求項１０または請求項１２のいずれかに記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
17. 前記データベースシステムは，
    オラクルデータベース及びオラクルデータベース管理システムであることを特徴とする，請求項１０に記載のデータベースシステムに接続せずにデータベースシステムをモニタリングする方法。
    

Images