(57)【特許請求の範囲】
【請求項１】
コンピュータをアプリケーションサーバとして動作させるプログラムであって、
前記プログラムは、コンピュータに、
データベースサーバへの問合せを発行する問合せステップと、
前記問合せステップにおいて発行された前記問合せを前記データベースサーバに対して実行する実行ステップと、
前記問合せステップにおいて発行された前記問合せを監視対象として、前記問合せが予め定められた期間に前記実行ステップにおいて実行されない状態であるタイムアウトを監視し、前記問合せステップにおいて発行された前記問合せを監視する時間を定める時間である全体監視時間内に、予め定められた数の前記問合せがタイムアウトした場合に、前記データベースサーバを再起動する監視ステップとを実行させる
ことを特徴とするプログラム。
【請求項２】
前記監視ステップにおいて、前記問合せステップにおいて発行された前記問合せが最初にタイムアウトした場合に、前記全体監視時間のカウントを開始させる
ことを特徴とする請求項１に記載のプログラム。
【請求項３】
前記監視ステップにおいて、前記問合せステップにおいて発行された前記問合せの発行の時間間隔が、前記問合せステップにおいて発行される前記問合せの発行の時間間隔を定める下限問合せ発行間隔よりも長い場合には、その時点までに発行された前記問合せを前記監視対象から除外し、その時点における前記全体監視時間のカウントをリセットしてその時点から再スタートさせる
ことを特徴とする請求項２に記載のプログラム。
【請求項４】
前記監視ステップにおいて、前記全体監視時間内に前記予め定められた数の前記問合せがタイムアウトした場合において、タイムアウトした前記問合せの件数が、前記問合せステップにおいて発行された前記問合せの発行件数を定める下限問合せ発行件数より少ない場合には、前記全体監視時間内に前記予め定められた数の前記問合せがタイムアウトした場合を、前記データベースサーバを再起動する場合から除外する
ことを特徴とする請求項１に記載のプログラム。
【請求項５】
前記監視ステップにおいて、前記問合せステップにおいて発行された前記問合せがキャンセルされた場合であっても、キャンセルされた前記問合せを前記監視対象とする
ことを特徴とする請求項１に記載のプログラム。
【請求項６】
前記問合せステップにおいて、前記アプリケーションサーバに接続された複数のクライアントの各々に応じて生成されたスレッドが、対応する前記クライアントから受信した前記データベースサーバへの問合せ要求に応じて、前記問合せを発行する
ことを特徴とする請求項１に記載のプログラム。
【請求項７】
データベースサーバへの問合せを発行するステップと、
発行された前記問合せを前記データベースサーバに対して実行するステップと、
発行された前記問合せを監視対象として、前記問合せが予め定められた期間に実行されない状態であるタイムアウトを監視するステップと、
発行された前記問合せを監視する時間を定める時間である全体監視時間内に、予め定められた数の前記問合せがタイムアウトした場合に、前記データベースサーバを再起動するステップとを含む
ことを特徴とするアプリケーションサーバ装置の制御方法。
【請求項８】
データベースサーバへの問合せを発行する複数のアプリケーション処理部と、
前記複数のアプリケーション処理部により発行された前記問合せを前記データベースサーバに対して実行する実行処理部と、
前記複数のアプリケーション処理部により発行された前記問合せを監視対象として、前記問合せが予め定められた期間に前記実行処理部で実行されない状態であるタイムアウトを監視し、発行された前記問合せを監視する時間を定める時間である全体監視時間内に、予め定められた数の前記問合せがタイムアウトした場合に、前記データベースサーバを再起動する監視処理部とを含む
ことを特徴とするアプリケーションサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム、アプリケーションサーバ装置の制御方法、アプリケーションサーバ装置に関する。
【背景技術】
【０００２】
クライアントがアプリケーションサーバを介してデータベースサーバに問合せ、例えばＳＱＬコマンドを発行した場合において、ＳＱＬコマンドが所定の時間内に完了しない場合がある。ＳＱＬコマンドが所定の時間内に完了しないと、クライアントにおいてアプリケーションプログラムの実行に障害となる。そこで、アプリケーションサーバは、ＳＱＬコマンドが所定の時間内に完了しない場合、クライアントにエラー通知処理を行う等、種々の障害処理を実行する。
【０００３】
例えば、サーバ処理装置において、サービススレッドが、クライアントからのリクエストを受信すると、要求された処理のタイムアウト時間と自分のスレッドＩＤをタイムアウト表に書込み、リクエストの処理を終了すると、タイムアウト表内のタイムアウト時間及びスレッドＩＤを消去し、監視スレッドが、定期的にタイムアウト表からタイムアウト時間を読み出して、現在の時刻と比較することにより、設定されたタイムアウト時間までに処理を終了していないサービススレッドを検出し、タイムアウトしたサービススレッドを発見した場合には、該サービススレッドを強制的に終了させて、クライアントにエラーを通知することが提案されている。
【０００４】
また、商品販売データ処理システムにおいて、定期的にデータベースサーバーに関与して各アプリケーションプロセスが当該データベースサーバーに接続要求した回数を取得可能かつ取得した接続要求回数と設定回数とを比較して取得接続要求回数が設定回数以上になったことを条件にデータベースサーバーに障害が発生する蓋然性が強いと判別可能に形成し、障害が発生する蓋然性が強いと判別された場合にシステムの一部または全部を再起動可能に形成することが提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平８−２６３３２５号公報
【特許文献２】特開２０００−１２２９７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
データベースサーバへの問合せ、例えばＳＱＬコマンドが所定の時間内に完了しない場合、アプリケーションサーバは、例えばデータベースサーバに対してＳＱＬコマンドのキャンセルを発行する。ＳＱＬコマンドのキャンセルが成功した場合には、ＳＱＬコマンドを強制的に終了させることができる。
【０００７】
しかし、アプリケーションサーバにおいて何らかの異常がある場合には、ＳＱＬコマンドのキャンセルが失敗する場合がある。ＳＱＬコマンドのキャンセルが失敗した場合には、ＳＱＬコマンドを強制的に終了させることができず、また、その後に発行されるＳＱＬコマンドが実行されない可能性がある。
【０００８】
本発明は、データベースサーバへの問合せが実行されない場合にデータベースサーバを再起動するアプリケーションサーバのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
開示されるプログラムは、コンピュータをアプリケーションサーバとして動作させるプログラムである。前記プログラムは、コンピュータに、データベースサーバへの問合せを発行する問合せステップと、問合せステップにおいて発行された問合せをデータベースサーバに対して実行する実行ステップと、問合せステップにおいて発行された問合せを監視対象として、問合せが予め定められた期間に実行ステップにおいて実行されない状態であるタイムアウトを監視し、問合せステップにおいて発行された問合せを監視する時間を定める時間である全体監視時間内に、予め定められた数の問合せがタイムアウトした場合に、データベースサーバを再起動する監視ステップとを実行させる。
【発明の効果】
【００１０】
開示されるプログラムによれば、アプリケーションサーバ等における何らかの異常に起因して、ＳＱＬコマンドのようなデータベースサーバへの問合せが実行されない場合に、データベースサーバを再起動することができる。
【図面の簡単な説明】
【００１１】
【図１】アプリケーションサーバシステムの構成の一例を示す図である。
【図２】監視テーブルの一例を示す図である。
【図３】監視情報の一例を示す図である。
【図４】アプリケーションサーバ装置の構成の一例を示す図である。
【図５】ＳＱＬ監視処理の説明図である。
【図６】ＳＱＬ監視処理の説明図である。
【図７】ＳＱＬ監視処理の説明図である。
【図８】ＳＱＬ監視処理の説明図である。
【図９】ＳＱＬ処理フローチャートである。
【図１０】ＳＱＬ登録処理フローチャートである。
【図１１】ＳＱＬ登録解除処理フローチャートである。
【図１２】ＳＱＬ監視処理フローチャートである。
【図１３】データベース監視処理フローチャートである。
【図１４】タイムアウト監視処理フローチャートである。
【図１５】本発明者が検討したＳＱＬ監視処理の説明図である。
【発明を実施するための形態】
【００１２】
図１５は、本発明者が検討したＳＱＬ監視処理の説明図であり、アプリケーションサーバがＳＱＬコマンドのキャンセルに失敗する場合についての説明図である。
【００１３】
アプリケーション処理スレッド２０１が、監視処理への登録をアプリケーションタイムアウトスレッド２０３に依頼し（Ｐ＃１０１）、その後、ＳＱＬコマンドの実行をＳＱＬコマンド実行部２０４に依頼する（Ｐ＃１０２）。ＳＱＬコマンド実行部２０４は、依頼されたＳＱＬコマンドの実行をデータベースサーバ２０５へ依頼する。
【００１４】
この後、アプリケーション処理スレッド２０２が、ＳＱＬコマンドの実行をＳＱＬコマンド実行部２０４に依頼する（Ｐ＃１０２’）。ＳＱＬコマンド実行部２０４は、実行を依頼されたＳＱＬコマンドをデータベースサーバ２０５に対して実行する。なお、Ｐ＃１０２’における依頼に先立って、アプリケーション処理スレッド２０２は、監視処理への登録をアプリケーションタイムアウトスレッド２０３に依頼している。
【００１５】
この時、ＳＱＬコマンドの実行が終了しないので、アプリケーション処理スレッド２０１は、終了しないＳＱＬコマンドのキャンセルを、アプリケーションタイムアウトスレッド２０３へ依頼する。これに応じて、アプリケーションタイムアウトスレッド２０３は、キャンセル処理を実行するサブルーチンであるキャンセル処理実行部を呼び出し、呼び出されたキャンセル処理実行部は、ＳＱＬコマンド実行部２０４に対してＳＱＬコマンドのキャンセルを実行しようとする（Ｐ＃１０３）。
【００１６】
しかし、ＳＱＬコマンド実行部２０４は、Ｐ＃１０２’における依頼に応じて他のアプリケーション処理スレッド２０２からのＳＱＬコマンドを実行中であるので、Ｐ＃１０３におけるＳＱＬコマンドのキャンセルを実行することができない。
【００１７】
また、データベースサーバ２０５が正常でない場合には、ＳＱＬコマンド実行部２０４は、データベースサーバ２０５へ実行を依頼したＳＱＬコマンドをキャンセルすることができない。
【００１８】
このように、ＳＱＬコマンドのキャンセルが失敗した場合には、ＳＱＬコマンドを強制的に終了させることができない。また、その後にＳＱＬコマンドを再度実行しようとしても、実行されない可能性がある。従って、ＳＱＬコマンドの実行のリトライが無駄になる可能性がある。
【００１９】
開示のプログラム、アプリケーションサーバ装置の制御方法、アプリケーションサーバ装置は、データベースサーバへの問合せ、例えばＳＱＬコマンドのタイムアウトを監視し、タイムアウトが予め定められた状態となった場合に、データベースサーバを再起動する。
【００２０】
図１は、アプリケーションサーバシステムの構成の一例を示す図である。
【００２１】
アプリケーションサーバシステムは、アプリケーションサーバ１と、データベースサーバ２と、予備のデータベースサーバ２’と、複数のクライアント３とを含む。データベースサーバ２はデータベース（ＤＢ）２１を含み、予備のデータベースサーバ２’は予備のデータベース（ＤＢ）２１’を含む。予備のデータベース２１’は、データベース２１と同じデータを格納するデータベースである。アプリケーションサーバ１は、ネットワーク４を介して、データベースサーバ２に接続される。また、アプリケーションサーバ１は、ネットワーク５を介して、複数のクライアント３の各々に接続される。ネットワーク４はネットワーク５と同一であっても良い。また、アプリケーションサーバ１とデータベースサーバ２とが１個のサーバ装置として設けられるようにしても良い。
【００２２】
各々のクライアント３、換言すれば、クライアント装置は、データベースサーバ２へ問合せを行うコンピュータである。具体的には、各々のクライアント３は、データベースサーバ２への問合せ要求をアプリケーションサーバ１へ送信する。
【００２３】
アプリケーションサーバ１は、複数のアプリケーション処理部１１、実行処理部１２、監視処理部１３、監視情報格納部１４と、監視テーブル格納部１５を含む。
【００２４】
複数のアプリケーション処理部１１は、アプリケーションサーバ１に接続された複数のクライアント３に応じて設けられる。実際には、アプリケーション処理部１１は、アプリケーションサーバ１の制御プログラムにより、クライアント３毎に生成されるスレッドである。アプリケーション処理部１１は、クライアント３から受信したデータベースサーバ２への種々の要求に応じて、データベースサーバ２への種々の問合せを発行する。例えば、アプリケーション処理部１１は、データベースサーバ２へのＳＱＬコマンドを実行処理部１２へ発行する。
【００２５】
以下においては、データベースサーバ２への問合せがＳＱＬコマンドである場合について説明する。データベースサーバ２への問合せは、ＳＱＬコマンド以外のコマンド等であっても良い。
【００２６】
実行処理部１２は、複数のアプリケーション処理部１１により発行されたデータベースサーバ２へのＳＱＬコマンドをデータベースサーバ２に対して実行する。実際には、実行処理部１２は、ネットワーク４を介して、ＳＱＬコマンドをデータベースサーバ２へ送信する。データベースサーバ２は、受信したＳＱＬコマンドを実行して、受信したＳＱＬコマンドに対する応答を実行処理部１２に返信する。具体的には、データベースサーバ２は、受信したＳＱＬコマンドに基づいてデータベース２１を検索して、検索した結果を受信したＳＱＬコマンドに対する回答として、実行処理部１２に送信する。
【００２７】
監視処理部１３は、複数のアプリケーション処理部１１により発行されたＳＱＬコマンドを監視対象とする。監視対象であるＳＱＬコマンドは、監視テーブル格納部１５に格納された監視テーブル１５１に登録されたＳＱＬコマンドである。監視テーブル１５１については、図２を参照して後述する。
【００２８】
監視処理部１３は、ＳＱＬコマンドのタイムアウトを監視する。実際には、監視処理部１３は、アプリケーションサーバ１の制御プログラムにより生成されるスレッドである。ＳＱＬコマンドのタイムアウトは、ＳＱＬコマンドが予め定められた期間に実行処理部１２で実行されない状態である。前記期間は、監視処理部１３がＳＱＬコマンドの実行を監視する時間であり、経験的に定めることができ、予め定められる。
【００２９】
監視処理部１３は、予め定められた数のＳＱＬコマンドがタイムアウトした場合に、データベースサーバ２を再起動する。具体的には、監視処理部１３は、再起動コマンドをデータベースサーバ２へ送信する。データベースサーバ２は、受信した再起動コマンドを実行する。これにより、データベースサーバ２の種々の制御プログラムが一旦停止され、データベースサーバ２のＯＳ（オペレーティングシステム）が再起動され、ＯＳの再起動に伴ってデータベースサーバ２の種々の制御プログラムが再起動される。
【００３０】
データベースサーバ２の再起動の間、例えば数分の間、クライアント３は、データベースサーバ２へアクセスすることができない。換言すれば、実行処理部１２は、ＳＱＬコマンドを実行することができない。なお、実際には、再起動されるデータベースサーバ２の予備のデータベースサーバ２’が設けられ、データベースサーバ２の再起動が完了するまでの間、クライアント３から予備のデータベースサーバ２’へのアクセスが可能とされる。予備のデータベース２１’はデータベース２１と同じ内容を格納するので、クライアント３は、実際には、データベースサーバ２の再起動を意識する必要がない。
【００３１】
データベースサーバ２は、予め定められた数、換言すれば、再起動に必要な数のＳＱＬコマンドがタイムアウトした場合に、再起動される。再起動に必要な数は、経験的に定めることができ、予め定められる。
【００３２】
監視処理部１３は、後述するように、監視情報格納部１４に、監視処理におけるパラメータとして全体監視時間を備える。監視情報格納部１４については、図３を参照して後述する。全体監視時間は、複数のアプリケーション処理部１１により発行されたＳＱＬコマンドを監視する時間を定める。監視処理部１３は、複数のアプリケーション処理部１１のいずれかにより発行されたＳＱＬコマンドが最初にタイムアウトした場合に、全体監視時間のカウントを開始させる。監視処理部１３は、全体監視時間内に予め定められた数、換言すれば、再起動に必要な数のＳＱＬコマンドがタイムアウトした場合に、データベースサーバ２を再起動する。
【００３３】
「再起動に必要な数」は、例えば、全体監視時間内に発行可能なＳＱＬコマンドの総数とされる。全体監視時間内に発行可能なＳＱＬコマンドの総数は、全体監視時間と下限ＳＱＬ発行間隔とに基づいて定まる。この場合、全体監視時間内に発行可能なＳＱＬコマンドの全てがタイムアウトした場合に、データベースサーバ２が再起動されることになる。これにより、後述するように、データベースサーバ２の再起動が頻繁に実行されることを防止することができる。
【００３４】
「再起動に必要な数」は、全体監視時間内に発行可能なＳＱＬコマンドの総数に限られず、これ以外の数であっても良い。例えば、全体監視時間内に発行可能なＳＱＬコマンドの総数に基づいて算出した数、換言すれば、前記総数に所定の割合を乗じて算出した値を、再起動に必要な数とするようにしても良い。また、全体監視時間内に発行可能なＳＱＬコマンドの総数とは無関係に定めた数を、再起動に必要な数とするようにしても良い。
【００３５】
図２は、監視テーブルの一例を示す図である。
【００３６】
監視テーブル格納部１５は監視テーブル１５１を格納する。監視テーブル１５１は、基本的には、アプリケーション処理部１１からのＳＱＬ登録処理の依頼に基づいて、登録を依頼されたＳＱＬコマンドを登録することにより、監視処理部１３により作成される。監視テーブル１５１は、ＳＱＬコマンド毎に、スレッドＩＤ、ＤＢコマンド、開始時刻、キャンセル時刻を格納する。
【００３７】
ＳＱＬコマンドは、「ＳＱＬ＃１」等のコマンドＩＤにより表される。コマンドＩＤは、ＳＱＬコマンドを一意に特定する識別情報である。スレッドＩＤは、対応するＳＱＬコマンドを発行したアプリケーション処理部１１、換言すれば、アプリケーション処理スレッドを一意に特定する識別情報である。ＤＢコマンドは、対応するＳＱＬコマンドの内容、換言すれば、ＳＥＬＥＣＴ文等の記述内容である。ＳＱＬコマンド、スレッドＩＤ及びＤＢコマンドは、アプリケーション処理部１１からのＳＱＬ登録処理の依頼に基づいて、登録を依頼された時点で、監視テーブル１５１に格納される。
【００３８】
開始時刻は、対応するＳＱＬコマンドの実行が開始された時刻であり、実際には、対応するＳＱＬコマンドが監視テーブル１５１に登録された時刻である。開始時刻は、アプリケーションサーバ１の備えるタイマから取得される。開始時刻は、アプリケーション処理部１１からＳＱＬコマンドの登録を依頼された時点で、監視テーブル１５１に格納される。
【００３９】
キャンセル時刻は、対応するＳＱＬコマンドの実行がキャンセルされた時刻である。キャンセル時刻は、アプリケーションサーバ１の備えるタイマから取得される。キャンセル時刻は、監視処理部１３から実行処理部１２へキャンセル処理を依頼し、実行処理部１２から前記キャンセル処理の依頼への応答が監視処理部１３へ返信された時点で、監視処理部１３により監視テーブル１５１に格納される。
【００４０】
図３は、監視情報の一例を示す図である。
【００４１】
監視情報格納部１４は、ＳＱＬ監視処理における種々のパラメータを格納する。監視情報格納部１４は、全体監視時間領域１４１、監視間隔領域１４２、下限ＳＱＬ監視間隔領域１４３、下限ＳＱＬ発行件数領域１４４、下限ＳＱＬ発行間隔領域１４５、全体監視開始時刻領域１４６、ＳＱＬタイムアウト件数領域１４７、前回ＳＱＬ実行時刻領域１４８、ＳＱＬ発行件数領域１４９を含む。これらの領域１４１〜１４９に格納される情報が、ＳＱＬ監視処理におけるパラメータである。
【００４２】
全体監視時間領域１４１は全体監視時間を格納する。全体監視時間は、経験的に求めることができ、予め定められる。全体監視時間は、ＳＱＬコマンドの監視処理において、複数のアプリケーション処理部１１により発行された全てのＳＱＬコマンド、換言すれば、監視テーブル１５１に登録されたＳＱＬコマンドを監視する時間である。
【００４３】
監視間隔領域１４２は監視間隔を格納する。監視間隔は、経験的に求めることができ、予め定められる。監視間隔は、ＳＱＬコマンドの監視処理において、監視処理部１３がＳＱＬコマンドの監視を実行する間隔である。
【００４４】
下限ＳＱＬ監視間隔領域１４３は下限ＳＱＬ監視間隔を格納する。下限ＳＱＬ監視間隔は、経験的に求めることができ、予め定められる。下限ＳＱＬ監視間隔は、ＳＱＬコマンドの監視処理において、予め定められた数のＳＱＬコマンドがタイムアウトした場合であってもデータベースサーバ２の再起動に寄与しない条件、換言すれば、再起動の例外条件を定める。具体的には、ＳＱＬコマンドの監視間隔が下限ＳＱＬ監視間隔よりも小さい場合には、その時点でタイムアウトしたＳＱＬコマンド又はその時点までにタイムアウトしたＳＱＬコマンドが、データベースサーバ２の再起動に必要な数としてカウントされない。又は、予め定められた数のＳＱＬコマンドがタイムアウトした場合であっても、ＳＱＬコマンドの監視間隔が下限ＳＱＬ監視間隔よりも小さい場合には、データベースサーバ２は再起動されない。
【００４５】
下限ＳＱＬ発行件数領域１４４は下限ＳＱＬ発行件数を格納する。下限ＳＱＬ発行件数は、経験的に求めることができ、予め定められる。下限ＳＱＬ発行件数は、ＳＱＬコマンドの監視処理において、再起動の例外条件を定める。具体的には、ＳＱＬコマンドの発行件数が下限ＳＱＬ発行件数よりも小さい場合には、その時点でタイムアウトしたＳＱＬコマンド又はその時点までにタイムアウトしたＳＱＬコマンドが、データベースサーバ２の再起動に必要な数としてカウントされない。又は、予め定められた数のＳＱＬコマンドがタイムアウトした場合であっても、ＳＱＬコマンドの発行件数が下限ＳＱＬ発行件数よりも小さい場合には、データベースサーバ２は再起動されない。
【００４６】
下限ＳＱＬ発行間隔領域１４５は下限ＳＱＬ発行間隔を格納する。下限ＳＱＬ発行間隔は、経験的に求めることができ、予め定められる。下限ＳＱＬ発行間隔は、後述するように、再起動可能時刻を算出するために用いられる。
【００４７】
全体監視開始時刻領域１４６は全体監視開始時刻を格納する。全体監視開始時刻は、ＳＱＬコマンドの監視処理において、監視処理部１３がＳＱＬコマンドの監視を開始した時刻、換言すれば、複数のアプリケーション処理部１１のいずれかにより発行されたＳＱＬコマンドが最初にタイムアウトした時刻である。更に言えば、全体監視開始時刻は、複数のアプリケーション処理部１１のいずれかにより発行されたＳＱＬコマンドについて、最初にキャンセル処理を実行するサブルーチンであるキャンセル処理実行部が呼び出された時刻である。全体監視開始時刻は、後述するように、監視テーブル１５１のキャンセル時刻から取得される。全体監視開始時刻は、監視処理部１３がＳＱＬコマンドの監視を開始した時点で、監視処理部１３により全体監視開始時刻領域１４６に格納される。
【００４８】
ＳＱＬタイムアウト件数領域１４７はＳＱＬタイムアウト件数を格納する。ＳＱＬタイムアウト件数は、ＳＱＬコマンドの監視処理において、タイムアウトしたＳＱＬコマンドの件数である。ＳＱＬタイムアウト件数は、監視処理部１３により、ＳＱＬコマンドがタイムアウトする都度にカウントされ、ＳＱＬタイムアウト件数領域１４７に格納される。
【００４９】
前回ＳＱＬ実行時刻領域１４８は前回ＳＱＬ実行時刻を格納する。前回ＳＱＬ実行時刻は、ＳＱＬコマンドの監視処理において、前回発行された、換言すれば、最新のＳＱＬコマンドの直前に発行されたＳＱＬコマンドの発行時刻である。前回ＳＱＬ実行時刻は、監視処理部１３が最新のＳＱＬコマンドを監視テーブル１５１に登録した時点で、監視処理部１３により、監視テーブル１５１において、最新のＳＱＬコマンドの直前に発行されたＳＱＬコマンドの発行時刻を参照して、前回ＳＱＬ実行時刻領域１４８に格納される。
【００５０】
ＳＱＬ発行件数領域１４９はＳＱＬ発行件数を格納する。ＳＱＬ発行件数は、ＳＱＬコマンドの監視処理において、複数のアプリケーション処理部１１から発行されたＳＱＬコマンドの件数である。ＳＱＬ発行件数は、監視処理部１３により、ＳＱＬコマンドが発行される都度にカウントされ、ＳＱＬ発行件数領域１４９に格納される。
【００５１】
図４は、アプリケーションサーバのハードウェア構成の一例を示す図である。
【００５２】
ＣＰＵ１０１は、ＲＯＭ１０３に格納された制御プログラムに従って、アプリケーションサーバ１を制御する。ＣＰＵ１０１は、例えば主メモリであるＲＡＭ１０２上のアプリケーション処理プログラム、実行処理プログラム、監視処理プログラムを実行する。これにより、アプリケーション処理部１１、実行処理部１２、監視処理部１３が実現される。アプリケーション処理プログラム、実行処理プログラム、監視処理プログラムは、例えば、ＣＤ−ＲＯＭやＤＶＤ等の記録媒体１０７に格納され、記録媒体１０７からハードディスク１０６に入力され、ハードディスク１０６からＲＡＭ１０２にロードされる。監視情報格納部１４、監視テーブル格納部１５は、例えばＲＡＭ１０２に設けられる。
【００５３】
入力装置１０４は、例えばキーボードであり、マウス等を含んでも良い。出力装置１０５は、例えばディスプレイであり、プリンタ等の出力装置を含んでも良い。ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、入力装置１０４、出力装置１０５、及び、ハードディスク１０６は、バス１００を介して、相互に接続される。
【００５４】
図５は、アプリケーションサーバにおけるＳＱＬ監視処理の説明図である。
【００５５】
図５において、アプリケーション処理部１１として、複数のアプリケーション処理スレッド３１が生成されている。また、監視処理部１３として、アプリケーションタイムアウトスレッド１３１が生成されている。また、実行処理部１２をＳＱＬコマンド実行部１２１と言うこととする。
【００５６】
アプリケーション処理スレッド３１は、対応するクライアント３からデータベースサーバ２への問合せ要求を受信する。これに応じて、アプリケーション処理スレッド３１は、ＳＱＬ監視処理への登録、換言すれば、監視テーブル１５１への登録をアプリケーションタイムアウトスレッド１３１に依頼し（Ｐ＃１）、その後、ＳＱＬコマンドの実行をＳＱＬコマンド実行部１２１に依頼する（Ｐ＃２）。ＳＱＬコマンド実行部１２１は、実行を依頼されたＳＱＬコマンドの実行をデータベースサーバ２へ依頼する。
【００５７】
この後、アプリケーション処理スレッド３２は、対応するクライアント３からデータベースサーバ２への問合せ要求を受信する。これに応じて、アプリケーション処理スレッド３２は、ＳＱＬ監視処理への登録をアプリケーションタイムアウトスレッド１３１に依頼し（Ｐ＃１’）、その後、ＳＱＬコマンドの実行をＳＱＬコマンド実行部１２１に依頼する（Ｐ＃２’）。ＳＱＬコマンド実行部１２１は、実行を依頼されたＳＱＬコマンドをデータベースサーバ２に対して実行する。
【００５８】
アプリケーションタイムアウトスレッド１３１は、アプリケーション処理スレッド３１及びアプリケーション処理スレッド３２からＳＱＬ監視処理への登録を依頼されたＳＱＬコマンドの全体ついての実行を周期的に監視する（Ｐ＃３）。ＳＱＬ監視処理への登録を依頼されたＳＱＬコマンドを、監視対象ＳＱＬコマンドと言うこととする。監視対象ＳＱＬコマンドは、監視テーブル１５１に登録されたＳＱＬコマンドである。
【００５９】
アプリケーションタイムアウトスレッド１３１は、監視対象ＳＱＬコマンドの実行が予め定められた期間内に終了しない場合、換言すれば、監視対象ＳＱＬコマンドがタイムアウトした場合、キャンセル処理を実行するサブルーチンであるキャンセル処理実行部を呼び出す（Ｐ＃４）。呼び出されたキャンセル処理実行部は、ＳＱＬコマンド実行部１２１に対してＳＱＬコマンドのキャンセルを実行する。
【００６０】
Ｐ＃４の処理において、アプリケーションタイムアウトスレッド１３１は、監視テーブル１５１において、タイムアウトしたＳＱＬコマンドについてキャンセル時刻を格納する。キャンセル時刻は、アプリケーションサーバ１の備えるタイマから取得される。また、アプリケーションタイムアウトスレッド１３１は、タイムアウトしたＳＱＬコマンドについて監視テーブル１５１に格納したキャンセル時刻に基づいて、全体監視開始時刻領域１４６に全体監視開始日時を設定する。
【００６１】
例えば、実行処理部１２が他のアプリケーション処理スレッド３２からのＳＱＬコマンドを実行中でない場合には、ＳＱＬコマンド実行部１２１は、データベースサーバ２へ実行を依頼したＳＱＬコマンドをキャンセルすることができる。また、データベースサーバ２が正常である場合には、実行処理部１２は、データベースサーバ２へ実行を依頼したＳＱＬコマンドをキャンセルすることができる。監視処理部１３は、複数のアプリケーション処理部１１により発行されたＳＱＬコマンドがキャンセルされた場合であっても、キャンセルされたＳＱＬコマンドを監視対象ＳＱＬコマンドとする。
【００６２】
一方、実行処理部１２が他のアプリケーション処理スレッド３２からのＳＱＬコマンドを実行中である場合には、ＳＱＬコマンド実行部１２１は、データベースサーバ２へ実行を依頼したＳＱＬコマンドをキャンセルすることができない。また、データベースサーバ２が正常でない場合には、ＳＱＬコマンド実行部１２１は、データベースサーバ２へ実行を依頼したＳＱＬコマンドをキャンセルすることができない。
【００６３】
以上のように、キャンセルが成功するか失敗するかに拘わりなく、キャンセル処理を実行するキャンセル処理実行部が呼び出されたＳＱＬコマンドが、タイムアウトしたＳＱＬコマンドとしてカウントされる。以上の結果として、データベースサーバ２において、ＳＱＬコマンドがタイムアウトする原因が存在する場合、以下の図６に示すように、監視対象ＳＱＬが、連続してタイムアウトする。
【００６４】
図６は、アプリケーションサーバにおけるＳＱＬ監視処理の説明図である。
【００６５】
例えば、時刻ｔ１１に１番目のＳＱＬコマンドであるＳＱＬ＃１が発行される。しかし、ＳＱＬ＃１は実行されずに、時刻ｔ１２にＳＱＬ＃１のタイムアウトが発生する。これにより、全体監視時間のカウントがスタートし、全てのＳＱＬが監視対象とされる。このために、監視処理部１３は、全体監視時間カウンタを含む。
【００６６】
この後、時刻ｔ１３に２番目のＳＱＬコマンドであるＳＱＬ＃２が発行される。しかし、ＳＱＬ＃２は実行されずに、時刻ｔ１４にＳＱＬ＃２のタイムアウトが発生する。この後、更に、複数のＳＱＬコマンドが発行される。しかし、発行された全てのＳＱＬコマンドが実行されず、発行された全てのＳＱＬコマンドのタイムアウトが発生する。
【００６７】
ここで、ＳＱＬ＃１及び＃２を含めて、全体で１００個のＳＱＬコマンドが発行されたとする。また、１００個のＳＱＬの中で、最後に、時刻ｔ１５に１００番目のＳＱＬコマンドであるＳＱＬ＃１００が発行され、実行されず、時刻ｔ１６にＳＱＬ＃１００のタイムアウトが発生するものとする。
【００６８】
例えば、時刻ｔ１２からカウントを開始した全体監視時間が、時刻ｔ１７に予め定められた時間、例えば６００秒に達したとする。従って、全体監視時間が経過した時刻ｔ１７までに、発行された全てのＳＱＬコマンドのタイムアウトが発生している。換言すれば、全体監視時間が経過し、かつ、発行された全てのＳＱＬコマンドのタイムアウトが発生している。そこで、時刻ｔ１７に、データベースサーバ２が再起動される。これにより、ＳＱＬコマンドのリトライが無駄に繰り返されることを回避することができる。
【００６９】
この後、時刻ｔ１８にＳＱＬ＃１０１が発行され、時刻ｔ１９に１０１番目のＳＱＬコマンドであるＳＱＬ＃１０１が正常に実行され終了する。更に、時刻ｔ１１０に１０２番目のＳＱＬコマンドであるＳＱＬ＃１０２が発行され、ＳＱＬ発行件数がカウントされる。しかし、ＳＱＬ＃１０２は実行されずに、時刻ｔ１１１にＳＱＬ＃１０２のタイムアウトが発生する。これにより、全体監視時間のカウントがスタートし、全てのＳＱＬが監視対象とされる。
【００７０】
この後、時刻ｔ１１２に１０３番目のＳＱＬコマンドであるＳＱＬ＃１０３が発行され、正常に実行され、時刻ｔ１１３に終了する。これにより、全体監視時間のカウントがストップし、全てのＳＱＬについての監視がストップされる。
【００７１】
図６に対して、前述したように、データベースサーバ２の再起動の例外が設けられる。監視処理部１３は、監視情報格納部１４に格納された再起動の例外条件を用いて、タイムアウトしたＳＱＬコマンドをデータベースサーバ２の再起動に必要な数としてカウントしないようにするか、又は、予め定められた数のＳＱＬコマンドがタイムアウトした場合であってもデータベースサーバ２を再起動しないようにする。
【００７２】
図７は、アプリケーションサーバにおけるＳＱＬ監視処理の説明図である。
【００７３】
例えば、監視処理部１３は、前述したように、データベースサーバ２を再起動する場合から除外する例外条件として、下限ＳＱＬ発行件数を備える。下限ＳＱＬ発行件数は、複数のアプリケーション処理部１１により発行されたＳＱＬコマンドの発行件数を定める。
【００７４】
監視処理部１３は、図７に示すように、全体監視時間内に予め定められた数のＳＱＬコマンドがタイムアウトした場合において、タイムアウトしたＳＱＬコマンドの件数が下限ＳＱＬ発行件数より少ない場合には、予め定められた数のＳＱＬコマンドがタイムアウトした場合を、データベースサーバ２を再起動する場合から除外する。
【００７５】
図７において、例えば、時刻ｔ２１にＳＱＬ＃１が発行され、ＳＱＬ発行件数がカウントされる。しかし、ＳＱＬ＃１は実行されずに、時刻ｔ２２にＳＱＬ＃１のタイムアウトが発生する。これにより、全体監視時間のカウントがスタートし、全てのＳＱＬが監視対象とされる。
【００７６】
この後、時刻ｔ２３にＳＱＬ＃２が発行され、ＳＱＬ発行件数がカウントされる。しかし、ＳＱＬ＃２は実行されずに、時刻ｔ２４にＳＱＬ＃２のタイムアウトが発生する。この後、更に、複数のＳＱＬコマンドが発行され、その都度ＳＱＬ発行件数がカウントされる。しかし、発行された全てのＳＱＬコマンドが実行されず、発行された全てのＳＱＬコマンドのタイムアウトが発生する。
【００７７】
ここで、ＳＱＬ＃１及び＃２を含めて、全体で５０個のＳＱＬコマンドが発行されたとする。また、５０個のＳＱＬの中で、最後に、時刻ｔ２５に５０番目のＳＱＬコマンドであるＳＱＬ＃５０が発行され、実行されず、時刻ｔ２６にＳＱＬ＃５０のタイムアウトが発生するものとする。ＳＱＬ＃５０のタイムアウトが発生した時点におけるＳＱＬ発行件数は「５０」である。
【００７８】
例えば、時刻ｔ２２からカウントを開始した全体監視時間が、時刻ｔ２７に予め定められた時間、例えば６００秒に達したとする。従って、全体監視時間が経過した時刻ｔ２７までに、発行された全てのＳＱＬコマンドのタイムアウトが発生している。換言すれば、全体監視時間が経過し、かつ、発行された全てのＳＱＬコマンドのタイムアウトが発生している。
【００７９】
しかし、この場合、全体監視時間が経過し、かつ、発行された全てのＳＱＬコマンドのタイムアウトが発生しているにも拘らず、データベースサーバ２は再起動されない。これは、全体監視時間が経過した時点におけるＳＱＬの発行件数が、「５０」であり、下限ＳＱＬ発行件数「６０」より小さいためである。
【００８０】
この結果、全体監視時間が経過した時点におけるＳＱＬの発行件数が少ない場合には、これらのタイムアウトが、データベースサーバ２の再起動の原因とならない。これにより、データベースサーバ２の再起動が頻繁に実行されることを防止することができる。
【００８１】
図８は、アプリケーションサーバにおけるＳＱＬ監視処理の説明図である。
【００８２】
例えば、監視処理部１３は、下限ＳＱＬ発行間隔を備える。下限ＳＱＬ発行間隔は、データベースサーバ２を再起動する場合から除外する例外条件として、複数のアプリケーション処理部１１により発行されるＳＱＬコマンドの発行の時間間隔を定める。
【００８３】
監視処理部１３は、図８に示すように、複数のアプリケーション処理部１１により発行されたＳＱＬコマンドの発行の時間間隔が下限ＳＱＬ発行間隔よりも長い場合には、その時点までに発行されたＳＱＬコマンドを監視対象から除外し、その時点における全体監視時間のカウントをリセットしてその時点から再スタートさせる。
【００８４】
図８において、例えば、時刻ｔ３１にＳＱＬ＃１が発行され、現在時刻ｔ３１を前回ＳＱＬ実行時刻とする。しかし、ＳＱＬ＃１は実行されずに、時刻ｔ３２にＳＱＬ＃１のタイムアウトが発生する。これにより、全体監視時間のカウントがスタートし、全てのＳＱＬが監視対象とされる。
【００８５】
この後、時刻ｔ３３にＳＱＬ＃２が発行され、現在時刻ｔ３３が前回ＳＱＬ実行時刻とされる。しかし、ＳＱＬ＃２は実行されずに、時刻ｔ３４にＳＱＬ＃２のタイムアウトが発生する。
【００８６】
この後、前回ＳＱＬ実行時刻ｔ３３から例えば７０秒経過した後において、時刻ｔ３５にＳＱＬ＃３が発行される。
【００８７】
この時、ＳＱＬの発行の時間間隔に基づいて、時刻ｔ３２からスタートした全体監視時間のカウントが中止される。これは、最新のＳＱＬ＃３の発行時刻ｔ３５において、前回ＳＱＬ実行時刻ｔ３３から現在時刻ｔ３５までの時間が、「７０秒」であり、下限ＳＱＬ発行間隔「６０秒」より大きいためである。なお、全体監視時間のカウントの中止の後、現在時刻ｔ３５が新たな前回ＳＱＬ実行時刻とされる。
【００８８】
この結果、時刻ｔ３２におけるＳＱＬ＃１のタイムアウト及び時刻ｔ３４におけるＳＱＬ＃２のタイムアウトが、データベースサーバ２の再起動の原因とならない。これにより、データベースサーバ２の再起動が頻繁に実行されることを防止することができる。
【００８９】
図９は、アプリケーションサーバにおけるＳＱＬ処理フローチャートである。
【００９０】
アプリケーション処理部１１は、前述したように、監視処理部１３にＳＱＬコマンドの監視、換言すれば、監視テーブル１５１へのＳＱＬコマンドの登録を依頼する。これに応じて、監視処理部１３は、ＳＱＬコマンドを監視テーブル１５１に登録するＳＱＬ登録処理を実行する（ステップＳ１１）。ＳＱＬ登録処理については、図１０を参照して後述する。
【００９１】
この後、アプリケーション処理部１１は、前述したように、実行処理部１２にＳＱＬコマンドの実行を依頼する。これに応じて、実行処理部１２は、登録されたＳＱＬコマンドを実行する（ステップＳ１２）。
【００９２】
この後、監視処理部１３は、実行されたＳＱＬコマンドを監視テーブル１５１から削除するＳＱＬ登録解除処理を実行する（ステップＳ１３）。ＳＱＬ登録解除処理については、図１１を参照して後述する。
【００９３】
図１０は、ＳＱＬ登録処理フローチャートである。
【００９４】
監視処理部１３は、監視テーブル１５１を排他状態とした上で（ステップＳ２１）、監視テーブル１５１に、スレッド、ＤＢコマンド、開始時刻を登録する（ステップＳ２２）。監視処理部１３は、ＳＱＬ発行件数領域１４９に格納されているＳＱＬ発行件数を「ＳＱＬ発行件数＋１」とする（ステップＳ２３）。この後、監視処理部１３は、監視テーブル１５１を排他解除状態とする（ステップＳ２４）。
【００９５】
図１１は、ＳＱＬ登録解除処理フローチャートである。
【００９６】
監視処理部１３は、監視テーブル１５１を排他状態とした上で（ステップＳ３１）、監視テーブル１５１から、実行されたＳＱＬについての情報であるＳＱＬ情報を削除する（ステップＳ３２）。監視処理部１３は、ＳＱＬ発行件数領域１４９に格納されているＳＱＬ発行件数を「ＳＱＬ発行件数−１」とする（ステップＳ３３）。この後、監視処理部１３は、監視テーブル１５１を排他解除状態とする（ステップＳ３４）。
【００９７】
図１２は、ＳＱＬ監視処理フローチャートである。
【００９８】
監視処理部１３は、監視テーブル１５１を排他状態とした上で（ステップＳ４１）、データベース監視処理を実行し（ステップＳ４２）、更に、タイムアウト監視処理を実行する（ステップＳ４３）。データベース監視処理については、図１３を参照して後述する。タイムアウト監視処理については、図１４を参照して後述する。この後、監視処理部１３は、監視テーブル１５１を排他解除状態とした上で（ステップＳ４４）、スリープ状態となり（ステップＳ４５）、監視間隔領域１４２に格納された監視間隔が経過するのを待って、ステップＳ４１を繰り返す。
【００９９】
図１３は、データベース監視処理フローチャートである。
【０１００】
監視処理部１３は、全体監視開始時刻領域１４６に全体監視開始日時が設定されているか否かを判断する（ステップＳ５１）。全体監視開始日時が設定されていない場合、監視処理部１３は、処理を終了する。
【０１０１】
全体監視開始日時が設定されている場合、監視処理部１３は、全体監視開始時刻に全体監視時間を加算することにより監視終了時刻を算出する（ステップＳ５２）。この後、監視処理部１３は、算出した監視終了時刻が現在時刻に到達しているか否かを判断する（ステップＳ５３）。現在時刻が監視終了時刻に到達していない場合、監視処理部１３は、処理を終了する。
【０１０２】
現在時刻が監視終了時刻に到達している場合、監視処理部１３は、更に、ＳＱＬ発行件数が下限ＳＱＬ発行件数領域１４４に格納された下限ＳＱＬ発行件数以上であるか否かを判断する（ステップＳ５４）。ＳＱＬ発行件数が下限ＳＱＬ発行件数以上でない場合、監視処理部１３は、処理を終了する。
【０１０３】
ＳＱＬ発行件数が下限ＳＱＬ発行件数以上である場合、監視処理部１３は、前回ＳＱＬ実行時刻領域１４８に格納された前回ＳＱＬ実行時刻に、下限ＳＱＬ発行間隔領域１４５に格納された下限ＳＱＬ発行間隔を加算することにより、再起動可能時刻を算出する（ステップＳ５５）。この後、監視処理部１３は、算出した再起動可能時刻が現在時刻に到達しているか否かを判断する（ステップＳ５６）。現在時刻が再起動可能時刻に到達していない場合、監視処理部１３は、次のステップＳ５７を実行することなく、処理を終了する。
【０１０４】
現在時刻が再起動可能時刻に到達している場合、監視処理部１３は、再起動スクリプトを呼び出し（ステップＳ５７）、処理を終了する。
【０１０５】
ステップＳ５４において、ＳＱＬ発行件数が下限ＳＱＬ発行件数領域１４４に格納された下限ＳＱＬ発行件数より小さい場合、監視処理部１３は、全体監視開始時刻領域１４６の全体監視開始日時を「ＮＵＬＬ」に設定して（ステップＳ５８）、処理を終了する。
【０１０６】
図１４は、タイムアウト監視処理フローチャートである。
【０１０７】
監視処理部１３は、監視テーブル１５１から発行順に１個のＳＱＬコマンドを取り出す（ステップＳ６１）。取り出されたＳＱＬコマンドを「ＳＱＬｎ」と言うこととする。監視処理部１３は、ＳＱＬｎ開始時刻に下限ＳＱＬ時間を加算することにより終了日時を算出する（ステップＳ６２）。この後、監視処理部１３は、算出した終了日時がＳＱＬｎ現在時刻に到達しているか否かを判断する（ステップＳ６３）。終了日時がＳＱＬｎ現在時刻に到達していない場合、監視処理部１３は、後述するステップＳ６１１を実行する。
【０１０８】
終了日時がＳＱＬｎ現在時刻に到達している場合、監視処理部１３は、更に、監視テーブル１５１に、「ＳＱＬｎ」のキャンセル時刻であるＳＱＬｎキャンセル時刻が設定されているか否かを判断する（ステップＳ６４）。ＳＱＬｎキャンセル時刻が設定されている場合、監視処理部１３は、後述するステップＳ６１１を実行する。
【０１０９】
ＳＱＬｎキャンセル時刻が設定されていない場合、監視処理部１３は、現在時刻をＳＱＬｎキャンセル時刻に設定し（ステップＳ６５）、キャンセル処理実行部を呼び出す（ステップＳ６６）。
【０１１０】
この後、監視処理部１３は、全体監視開始時刻領域１４６に全体監視開始時刻が設定されているか否かを判断する（ステップＳ６７）。全体監視開始時刻が設定されていない場合、監視処理部１３は、現在日時を全体監視開始時刻領域１４６の全体監視開始時刻に設定し（ステップＳ６８）、ＳＱＬ発行件数領域１４９のＳＱＬ発行件数を「１」とする（ステップＳ６９）。全体監視開始日時が設定されている場合、監視処理部１３は、ＳＱＬ発行件数領域１４９のＳＱＬ発行件数を「ＳＱＬ発行件数＋１」とする（ステップＳ６１０）。
【０１１１】
この後、監視処理部１３は、ＳＱＬｎが最後のＳＱＬであるか否かを判断する（ステップＳ６１１）。ＳＱＬｎが最後のＳＱＬでない場合、監視処理部１３は、ステップＳ６１を繰り返す。ＳＱＬｎが最後のＳＱＬである場合、監視処理部１３は、処理を終了する。
【符号の説明】
【０１１２】
１    アプリケーションサーバ
２    データベースサーバ
３    クライアント
４、５    ネットワーク
１１    アプリケーション処理部
１２    実行処理部
１３    監視処理部
１４    監視情報格納部
１５    監視テーブル格納部
【図１】
0005567444.tif 000002
【図２】
0005567444.tif 000003
【図３】
0005567444.tif 000004
【図４】
0005567444.tif 000005
【図５】
0005567444.tif 000006
【図６】
0005567444.tif 000007
【図７】
0005567444.tif 000008
【図８】
0005567444.tif 000009
【図９】
0005567444.tif 000010
【図１０】
0005567444.tif 000011
【図１１】
0005567444.tif 000012
【図１２】
0005567444.tif 000013
【図１３】
0005567444.tif 000014
【図１４】
0005567444.tif 000015
【図１５】
0005567444.tif 000016