"複数のサーバが、それぞれ、自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部を備えることを特徴とする相互監視システム。請求項1記載の相互監視システムにおいて、前記イベント監視部は、ログを受信することにより、該ログに基づいて障害の復旧方法を求め、該求めた復旧方法を管理端末装置へ送信することを特徴とする相互監視システム。請求項2記載の相互監視システムにおいて、前記複数のサーバは、それぞれ、障害の種別を示す障害IDと、該障害IDによって示される種別の障害を復旧するための復旧方法とが関連付けて記録された復旧方法記憶部を備え、前記ログは、発生した障害の種別を示す障害IDを含み、前記イベント監視部は、ログに含まれている障害IDと関連付けて記録されている復旧方法を前記復旧方法記憶部から検索して前記管理端末装置へ送信することを特徴とする相互監視システム。請求項1,2または3記載の相互監視システムにおいて、前記複数のサーバは、データベースを管理する2重化された第1および第2のデータベースサーバと、クライアントからの処理要求を前記第1および第2のデータベースサーバを利用して処理する2重化された第1および第2のアプリケーションサーバであり、前記第1および第2のデータベースサーバ上のイベント監視部と、前記第1および第2のアプリケーションサーバ上のイベント監視部は、他サーバ上のイベント監視部からの障害発生通知を受信した場合、自イベント監視部を搭載しているサーバの種別が前記障害発生通知の送信元のサーバの種別と異なり、且つ、自イベント監視部を搭載しているサーバが予備系である場合、前記障害発生通知の送信元のサーバに対して、ログ要求を送信することを特徴とする相互監視システム。請求項4記載の相互監視システムにおいて、前記第1および第2のデータベースサーバと前記第1および第2のアプリケーションサーバは、自サーバを除いた他サーバに対して、定期的に状態確認要求を送信し、該状態確認要求に応答して前記他サーバから状態確認応答が返信されたか否かに基づいて、前記他サーバの死活を判定すると共に、前記他サーバから送られてきた状態確認要求に応答して状態確認応答を返信する死活監視部を備え、前記第1および第2のデータベースサーバ上のイベント監視部は、それぞれ、自イベント監視部を搭載しているデータベースサーバがマウント状態になった場合、他サーバに対してマウント状態通知を送信し、自イベント監視部が搭載されているデータベースサーバが運用状態になった場合、他サーバに対して運用状態通知を送信し、前記第1および第2のデータベース上の死活監視部と前記第1および第2のアプリケーションサーバ上の死活監視部は、他サーバからマウント状態通知が送られてきた後、前記他サーバから運用場外通知が送られてくるまでの間は、前記他サーバに対する状態確認要求に応答して状態確認要求が返信されなくとも、前記他サーバが正常であると判定することを特徴とする相互監視システム。複数のサーバから構成される相互監視システムの構成要素となるサーバであって、自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部を備えることを特徴とするサーバ。複数のサーバが、それぞれ、自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録することを特徴とする相互監視方法。複数のサーバから構成される相互監視システムの構成要素となるサーバをコンピュータによって実現するためのプログラムであって、前記コンピュータを、自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部として機能させるためのプログラム。上述した特許文献1,2に記載されている技術によれば、特別な監視用サーバを設けることなく、相手サーバを監視することができる。しかしながら、特許文献1,2に記載されている技術は、一定時間毎に、他サーバに障害が発生しているか否かを判定するものであるので、障害発生から障害検出までに時間がかかってしまう場合がある。そして、障害発生から障害検出までに時間がかかると、障害復旧を迅速に行うために必要になる、障害発生時のログ情報が失われてしまう場合があるという問題がある。つまり、ログ情報を記録しておくログ記憶部には、容量的な制限があり、ログ記憶部が満杯になった場合には、再び、先頭番地からログ情報を記録する等の処置がとられるため、障害発生時のログ情報が、その後に発生したログ情報によって上書きされ、消えてしまう場合があるという問題がある。発明の目的そこで、本発明の目的は、障害復旧を迅速に行うために必要になる、障害発生時のログ情報が失われてしまう場合があるという課題を解決した相互監視システムを提供することにある。本発明にかかる第1の相互監視システムは、複数のサーバが、それぞれ、自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部を備える。本発明にかかるサーバは、複数のサーバから構成される相互監視システムの構成要素となるサーバであって、自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部を備える。本発明にかかる相互監視方法は、複数のサーバが、それぞれ、自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録する。本発明にかかるプログラムは、複数のサーバから構成される相互監視システムの構成要素となるサーバをコンピュータによって実現するためのプログラムであって、前記コンピュータを、自サーバに発生した障害を検出して前記他サーバに対して障害発生通知を送信し、前記他サーバからの障害発生通知を受信することにより前記他サーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、該ログを記憶部に記録するイベント監視部として機能させる。本発明によれば、障害復旧を迅速に行うために必要となる、障害発生時のログ情報を残すことができる可能性を高いものにすることができるという効果を得ることができる。次に、図面を参照して本発明の実施の形態について説明する。本発明の第1の実施の形態図1を参照すると、本発明にかかる相互監視システムの第1の実施の形態は、プライマリサイト側に配置されたアプリケーションサーバ10A、データベースサーバ20A、ルータ等の装置群30A、管理端末装置40Aおよびパーソナルコンピュータ等からなるクライアント群50Aと、スタンバイサイト側に配置されたアプリケーションサーバ10B、データベースサーバ20B、ルータ等の装置群30B、管理端末装置40Bおよびパーソナルコンピュータ等からなるクライアント群50Bとから構成され、プライマリサイトとスタンバイサイトとは同一サブネットのネットワークNで接続されている。運用系のアプリケーションサーバ10Aは、クライアントからの処理要求を、運用系のデータベースサーバ20Aを利用して処理し、処理結果を要求元に返す一般的な機能の他に、定期的に他のサーバ10B20A20Bの死活を監視する機能や、自サーバで障害が発生した際、他のサーバ10B20A20Bに対して障害発生通知を送信する機能を有する。図2を参照すると、アプリケーションサーバ10Aは、送受信部11と、アプリケーション処理部12と、サーバ状態監視プロセス13と、ディスク装置などの記憶装置14とから構成されている。記憶装置14には、状態記憶部141と、復旧方法記憶部142と、ログ記憶部143とが設けられている。状態記憶部141には、各サーバ10A10B20A20Bの状態が、INT初期状態、ACT運用系、SBY待機系、FLT障害中の何れであるかを示す情報が記録される。図3は、状態記憶部141の内容例を示す図であり、同図の例は、アプリケーションサーバ10Aおよびデータベースサーバ20Aが運用系で、アプリケーションサーバ10Bおよびデータベースサーバ20Bが待機系であることを示している。復旧方法記憶部142には、障害の種類を示す障害IDに関連付けて、その障害の復旧方法が記録されている。図4は、復旧方法記憶部142の内容例を示す図であり、同図の例は、障害IDがID00000001の障害の復旧方法がxxxxx。であること等を示している。ログ記憶部143には、障害ログ情報などのログ情報が記録される。ログ情報には、発生したイベントの種類を示すイベントID障害に関するイベントIDを障害IDと記す場合があるが含まれる。送受信部11は、ネットワークNを介して他のサーバ等との間でデータをやり取りする機能を有する。アプリケーション処理部12は、クライアントから送られてくる処理要求を受け付け、この処理要求によって要求されている処理を、運用系のデータベースサーバ20Aを利用して処理し、処理結果を要求元に返す機能を有する。サーバ状態監視プロセス13は、他のサーバ10B20A20Bの状態を監視するプロセスであり、死活監視部131と、イベント監視部132とを備えている。死活監視部131は、定期的に他のサーバ10B20A20Bに対して状態確認要求を送信し、これに応答して状態確認応答が返信されてきたか否かに基づいて、サーバ10B20A20Bに障害が発生しているか否かを判定する機能や、他のサーバ10B20A20Bから送られてきた状態確認要求に応答して、状態確認応答を返信する機能を有する。イベント監視部132は、自サーバ10Aに障害が発生したことを検出した場合、他のサーバ10B20A20Bに対して障害発生通知を送信する機能や、他のサーバ10B20A20Bから障害発生通知が送られてきた場合、その送信元のサーバに対してログ要求を送信する機能や、ログ要求に応答して他のサーバ10B20A20Bから送られてきたログ情報と復旧方法記憶部142の内容とに基づいて、障害の復旧方法を求め、求めた復旧方法を管理端末装置40A40Bへ送信する機能や、他のサーバ10B20A20Bから送られてくるログ要求に応答してログ記憶部143からログ情報を読み出して要求元に送信する機能などを有する。ここで、イベント監視部132で検出できる障害は、ポート障害、ミドルウェア障害、ソフトウェア障害、アプリケーション障害などである。なお、待機系のアプリケーションサーバ10Bも、アプリケーションサーバ10Aと同様の構成を備えている。また、アプリケーションサーバ10Aは、コンピュータによって実現可能であり、コンピュータによって実現する場合は、次のようにする。コンピュータをアプリケーションサーバ10Aとして機能させるためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、アプリケーション処理部12、死活監視部131、及び、イベント監視部132を実現する。運用系のデータベースサーバ20Aは、データベースを管理する一般的な機能の他に、定期的に他のサーバ10A10B20Bの死活を監視する機能や、自サーバ20Aにおいて障害が発生した際、他のサーバ10A10B20Bに対して障害発生通知を送信する機能などを有している。図5を参照すると、データベースサーバ20Aは、送受信部21と、データベース処理部22と、サーバ状態監視プロセス23と、ディスク装置などの記憶装置24とを備えている。記憶装置24は、状態記憶部241と、復旧方法記憶部242と、ログ記憶部243と、データ記憶部244とが設けられている。状態記憶部241には、各サーバ10A10B20A20Bの状態を示す情報が記録される。復旧方法記憶部242には、障害の種類を示す障害IDに関連付けて、その障害を復旧するための復旧方法が記録されている。ログ情報記憶部243には、障害ログなどのログ情報が記録される。データ記憶部244には、アプリケーションサーバ10Aから依頼された処理を行うために必要なデータが記録されている。送受信部21は、ネットワークNを介して他のサーバなどとの間で、データを送受信する機能を有する。データベース処理部22は、アプリケーションサーバ10Aから依頼された処理を、データ記憶部244に記録されているデータを利用して行い、処理結果をアプリケーションサーバ10Aに返す機能を有する。サーバ状態監視プロセス23は、他のサーバ10A10B20Bの状態を監視するプロセスであり、死活監視部231と、イベント監視部232とを備えている。死活監視部231は、定期的に他のサーバ10A10B20Bに対して状態確認要求を送信し、この要求に応答して状態確認応答が戻ってきたか否かに基づいて、他のサーバ10A10B20Bに障害が発生しているか否かを判定する機能や、他のサーバ10A10B20Bから送られてきた状態確認要求に応答して、状態確認応答を返信する機能を有する。イベント監視部232は、自サーバ20Aに障害が発生したことを検出した場合、他のサーバ10A10B20Bに対して障害発生通知を送信する機能や、他のサーバ10A10B20Bから障害発生通知が送られてきた場合、その送信元のサーバ10A10B20Bに対してログ要求を送信する機能や、ログ要求に応答して送られてきたログ情報と復旧方法記憶部242の内容とに基づいて、障害の復旧方法を求め、求めた復旧方法を管理端末装置40A40Bに送信する機能や、他のサーバ10A10B20Bから送られてくるログ要求に応答してログ記憶部243に記録されているログ情報を要求元に送信する機能などを有する。なお、待機系のデータベースサーバ20Bもデータベース20Aと同様の機能を有する。また、データベースサーバ20Aは、コンピュータによって実現可能であり、コンピュータによって実現する場合は、例えば、次のようにする。コンピュータをデータベースサーバ20Aとして機能させるためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、自コンピュータ上に、データベース処理部22、死活監視部232、及び、イベント監視部232を実現する。第1の実施の形態の動作の説明次に、本実施の形態の動作について、図面を参照して詳細に説明する。先ず、図6のフローチャートを参照して、アプリケーションサーバ10A内の死活監視部131の動作について説明する。アプリケーションサーバ10A内の死活監視部131は、一定時間が経過する毎にステップS61がYESとなる毎に、次のような処理を行う。先ず、他のサーバ10B20A20Bの内の1つのサーバ例えば、データベースサーバ20Aとするに対して、状態確認要求を送信し、状態確認応答が返信されるのを待つステップS62、S63。データベースサーバ20Aが正常動作している場合には、状態確認要求を受信した、データベースサーバ20A内の死活監視部131がアプリケーションサーバ10Aに対して状態確認応答を送信するが、データベースサーバ20Aにディスク障害や電源障害などの障害が発生している場合には、アプリケーションサーバ10Aに対して状態確認応答が送信されない。尚、状態確認要求としては、Pingを利用することができる。そして、一定時間以内に、データベースサーバ20Aから状態確認応答が戻ってきた場合ステップS63がYESは、データベースサーバ20Aは正常であると判断し、次のサーバ例えば、アプリケーションサーバ10Bに対して状態確認要求を送信し、上記サーバからの応答を待つステップS62、S63。これに対して、一定時間以内に、データベースサーバ20Aから状態確認応答が送られてこなかった場合ステップS63がNOは、データベースサーバ20Aに障害が発生したと判断し、障害処理を実行するステップS65。このステップS65の障害処理では、例えば、データベースサーバ20Aに障害が発生したことを管理端末装置40A40Bに送信する処理や、状態記憶部141に記録されている、データベースサーバ20Aの状態情報を障害中FLTに変更する処理や、予備系のデータベースサーバ20Bを運用系にするための処理などを行う。障害処理が完了すると、次のサーバ例えば、アプリケーションサーバ10Bに対して状態確認要求を送信し、上記サーバ10Bからの応答を待つステップS62、S63。以上の処理を全てのサーバに対して行うとステップS64がYESとなると、アプリケーションサーバ10A内の死活監視部131は、一定時間が経過するのを待ちステップS61、再び前述したステップS62~S65の処理を行う。次に、図7及び図8のシーケンス図と、図9のフローチャートとを参照して、運用系のデータベースサーバ20A内のイベント監視部132が障害を検出した場合の動作について説明する。図7に示すように、データベースサーバ20A20Bがそれぞれ運用系、待機系となっているときに、データベースサーバ20Aで障害が発生し、それをデータベースサーバ20A内のイベント監視部132が検出した場合の動作について説明する。尚、アプリケーションサーバ10A10Bは、それぞれ運用系、待機系になっているとする。また、以下の説明では、アプリケーションサーバ10A10B内のイベント監視部132をイベント監視部132A132Bと記し、データベースサーバ20A20B内のイベント監視部をイベント監視部232A232Bと記す場合がある。イベント監視部232Aは、自サーバ20Aでソフトウェア障害、ミドルウェア障害などが発生したことを検出するとステップS71、他のサーバ内のイベント監視部132A132B232Aに対して障害発生通知を送信すると共に、自サーバ内の状態記憶部241を更新し、自サーバ20Aの状態を障害中に更新するステップS72,S73。障害発生を通知する際には、trap等を利用することができる。イベント監視部132A132B232Aは、データベースサーバ20Aからの障害発生通知を受信すると、図9のフローチャートに示すように、自サーバ内の状態記憶部141241を更新し、データベースサーバ20Aの状態を障害中に更新するステップS91。これにより、各サーバ内の状態記憶部141241の内容は、図3に示すものから図10Aに示すものに変更される。その後、各イベント監視部132A132B232Aは、それぞれ自サーバ内の状態記憶部141241の内容を参照し、予め定められている規則に基づいて、自サーバが障害解析を担当するサーバとなるか否かを判定するステップS92。ここで、予め定められている規則は、複数のサーバの中から1台のサーバを選択するための規則であり、例えば、障害の発生したサーバとは種類の異なるサーバの、予備系のサーバが最も優先的に選択されるような規則を使用することができる。今、この規則に従って障害解析処理を実施するサーバを決定するようにすると、予備系のアプリケーションサーバ10Bが障害処理を担当することになる。アプリケーションサーバ10B内のイベント監視部132Bは、自サーバが障害解析処理を担当すると判断するとステップS92がYES、障害発生通知の通知元のデータベースサーバ20Aに対してログ要求を送信する図7のステップS74、図9のステップS93。これにより、データベースサーバ20A内のイベント監視部232Aは、ログ記憶部143からログ情報を読み出し、読み出したログ情報を要求元のアプリケーションサーバ10Bに対して送信するステップS75。アプリケーションサーバ10B内のイベント監視部132Bは、データベースサーバ20Aからのログ情報を受信すると、それを記憶装置14に記録し、更に、ログ情報を解析して障害の復旧方法を求め、求めた復旧方法を管理端末装置40A40Bへ送信する図7のステップS76、図9のステップS94S95。管理端末装置40A40Bでは、送られてきた復旧方法を表示部に表示する。ここで、障害の復旧方法の求め方を説明すると、次のようになる。先ず、受信したログ情報に含まれているログIDの1つに注目し、注目したログIDと同じ障害IDが復旧方法記憶部142に記録されているか調べる。そして、記録されている場合は、記録されている障害IDと、それに対応する復旧方法とを保持し、その後、次のログIDに注目し、前述した処理と同様の処理を行う。これに対して、記録されていない場合は、直ちに次にログIDに注目し、前述した処理と同様の処理を行う。そして、全てのログIDについて処理が完了すると、保持している障害IDと復旧方法との対を管理端末装置40A40Bへ送信する。その後、イベント監視部132Bは、障害発生通知に対する処理が正常終了したことを示す状態通知応答を、データベースサーバ20Aに返す図8のステップS801。これにより、データベースサーバ20Aは、ダウンするステップS802。一方、イベント監視部132Bは、状態記憶部141を参照して、障害発生通知の通知元ではない方のデータベースサーバ20Bの状態が待機系となっているか否かを調べ、待機系になっている場合は、切り替え可能と判定する図8のステップS803、図9のステップS97。この例の場合、図10Aに示すように、データベースサーバ20Bの状態は待機系SBYになっているので、切り替え可能と判断しステップS97がYES、切り替え処理を行うステップS98。切り替え処理においては、先ず、イベント監視部132Bは、管理端末装置40A40Bに対して切り替え開始を通知しステップS804、その後、待機系のデータベースサーバ20Bに対して、状態設定要求を送信し、データベースサーバ20Bの状態を運用系にすることを要求するステップS805。この通知を受けると、データベースサーバ20Bは、データ適用処理を行うステップS806。データ適用処理では、データベースサーバ20A20Bを最後に同期させた時点から、データベースサーバ20Aに障害が発生した時点までに、データベースサーバ20Aにおいて行われた更新処理をデータベースサーバ20Bに反映させるための処理である。データベースサーバ20B内のイベント監視部232Bは、データ適用処理が完了すると、自サーバ内の状態記憶部241の内容を図10Bに示すものに変更してデータベースサーバ20Bが運用系になったことを表示する共に、他のサーバ10A10B20Aに対して状態が運用系ACTに設定されたことを示す状態設定応答を送信するステップS807。これにより、各サーバ10A10B20A内のイベント監視部132A132B232Aは、状態記憶部141241の内容を図10Bに示すものに変更する。その後、アプリケーションサーバ10B内のイベント監視部132Bは、管理端末装置40A40Bに対して、データベースサーバ20Bを運用系に切り替えるための切り替え処理が完了したことを示す切り替え完了通知を送信するステップS809。その後、管理者などが管理端末装置40A40Bの表示部に表示された復旧方法に基づいて、データベースサーバ20Aに発生した障害を復旧し、データベースサーバ20Aを起動すると、データベースサーバ20A内のイベント監視部232Aは、他のサーバ10A10B20Bに対して、自サーバ20Aの状態が初期状態INTになったことを通知すると共に、状態記憶部241の内容を図10Cに示すものに変更し、自サーバが初期状態になったことを表示するステップS810S811。一方、データベースサーバ20Aからの通知を受けた他のサーバ10A10B20B内のイベント監視部132A132B232Bは、状態記憶部141241の内容を図10Cに示すものに変更してデータベースサーバ20Aが初期状態になったことを表示し、その後、データベースサーバ20Aに対して、状態記憶部141241の書き替えに成功したことを示す状態通知応答を返すステップS812、S813。その後、アプリケーションサーバ10B内のイベント監視部132Bは、初期状態になったデータベースサーバ20Aに対して、状態設定要求を送信し、その状態を待機系にすることを要求するステップS815。この要求に応答して、データベースサーバ20A内のイベント監視部232Aは、状態記憶部241の内容を図10Dに示すものに変更し、自サーバ20Aが待機系になったことを表示すると共に、他のサーバ10A10B20Bに対して、自サーバ20Aが待機系になったことを通知するステップS816~S818。これにより、サーバ10A10B20Bは、状態記憶部の内容を図10Dに示すものに変更する。その後、データベースサーバ20Aは、他のサーバ10A10B20Bに対して障害復旧を通知するステップS819、S820。尚、データベースサーバ20Aは、障害発生後のサーバであるため、システムに組み込むためには、運用者によるサーバ確認作業が必要である。次に、図9のフローチャート及び図11、図12のシーケンス図を参照し、二重障害が発生した際の動作について説明する。今、図11に示すように、データベースサーバ20A20Bがそれぞれ運用系、障害中のときに、データベースサーバ20Aにおいて障害が発生したとする。このときの各サーバ内の状態記憶部141241の内容は、図13Aに示すものになっている。データベースサーバ20A内のイベント発生部232Aは、データベースサーバ20Aに発生したソフトウェア障害、ミドルウェア障害などを検出すると、他のサーバに対して障害発生通知を送信すると共に、自サーバ20A内の状態記憶部241の内容を図13Bに示すものに変更し、自サーバ20Aが障害中であることを表示するステップS112、S113。各サーバ10A10B20B内のイベント監視部132232は、データベースサーバ20Aからの障害発生通知を受信すると、図9のステップS91の処理を行い、自サーバ内の状態記憶部141241の内容を図13Bに示す内容とし、データベースサーバ20Aが障害中であることを表示する。その次のステップS92では、自サーバが障害解析処理を担当するサーバであるか否かを判定する。前述した規則に従って障害解析処理を担当するサーバを決定するようにすると、アプリケーションサーバ10Bが障害解析処理を担当することになる。その後、アプリケーションサーバ10B内のイベント監視部132が前述したステップS93~S96、S72~76と同様の処理を行い、障害の復旧方法を管理端末装置40A40Bへ送信するステップS112~S116。その後、アプリケーションサーバ10B内のイベント監視部132Bが、障害発生通知に対する処理が正常終了したことを示す状態通知応答を、データベースサーバ20Aに返す図12のステップS1201。これにより、データベースサーバ20Aは、ダウンするステップS1202。一方、イベント監視部132Bは、状態記憶部141を参照して、障害発生通知の通知元ではない方のデータベースサーバ20Bの状態が待機系となっているか否かを調べ、待機系になっている場合は、切り替え可能と判定する図12のステップS1203、図9のステップS97。この例の場合、図13Bに示すように、データベースサーバ20Bの状態は障害中FLTになっているので、切り替え不可能と判断しステップS97がNO、切り替え失敗通知を管理端末装置40A40Bへ送信する図9のステップS99、図12のステップS1204。その後、管理者などが管理端末装置40A40Bの表示部に表示された復旧方法に基づいて、データベースサーバ20Aに発生した障害を復旧し、データベースサーバ20Aを起動すると、データベースサーバ20A内のイベント監視部232Aは、他のサーバ10A10B20Bに対して、自サーバ20Aの状態が初期状態INTになったことを通知すると共に、状態記憶部241の内容を図13Cに示すものに変更し、自サーバ20Aが初期状態になったことを表示するステップS1205S1206。一方、データベースサーバ20Aからの通知を受けた他のサーバ10A10B20B内のイベント監視部132A132B232Bは、状態記憶部141241の内容を図10Cに示すものに変更してデータベースサーバ20Aが初期状態になったことを表示し、その後、データベースサーバ20Aに対して、状態記憶部141241の書き替えに成功したことを示す状態通知応答を返すステップS1207、S1208。その後、アプリケーションサーバ10B内のイベント監視部132Bは、初期状態になったデータベースサーバ20Aに対して、状態設定要求を送信し、その状態を待機系にすることを要求するステップS1209。この要求に応答して、データベースサーバ20A内のイベント監視部232Aは、状態記憶部241の内容を図13Dに示すものに変更し、自サーバ2Aが待機系になったことを表示すると共に、他のサーバ10A10B20Bに対して、自サーバ2Aが待機系になったことを通知するステップS1210~S1212。その後、データベースサーバ20Aは、他のサーバ10A10B20Bに対して障害復旧を通知するステップS1213、S1214。尚、データベースサーバ20Aは、障害発生後のサーバであるため、システムに組み込むためには、運用者によるサーバ確認作業が必要である。次に、図14のシーケンス図を参照して、運用系、待機系の切り替え処理について説明する。今、図14に示すように、データベース20A20Bがそれぞれ待機系、運用系となっているときに、データベース20A20Bをそれぞれ運用系、待機系に変更する場合の動作を説明する。運用系、待機系の切り替えを行う場合、管理者などはアプリケーションサーバ例えば、アプリケーションサーバ10Aにデータベース切り替えコマンドを入力するステップS1401。これにより、イベント監視部132は、自サーバ内の状態記憶部141を参照し、データベースサーバの内の一方が運用系、他方が待機系になっているか否かを判定することにより、切り替え可能か否かを判定するステップS1402。この場合、データベースサーバ20A20Bは、それぞれ待機系、運用系となっているので、切り替え可能と判断する。そして、切り替え可能と判定すると、イベント監視部132は、管理端末装置40A40Bに対して切り替え開始を通知しステップS1403、その後、データベースサーバ20A20Bのそれぞれに対して、その状態を運用系、待機系に変更することを要求する状態設定要求を送信するステップS1404、S1405。この通知を受けたデータベースサーバ20A20B内のイベント監視手段232A232Bは、データ適用処理を行うステップS1406S1407。そして、データ適用処理が完了すると、イベント監視手段232A232Bは、それぞれアプリケーションサーバ10Aに対して状態設定が正常終了したことを示す状態設定応答を返すステップS1408、S1409。これにより、アプリケーションサーバ10A内のイベント監視部132Aは、状態記憶部141に記録されているデータベースサーバ20A20Bの状態をそれぞれ運用系、待機系に変更する。更に、データベースサーバ20Aは、アプリケーションサーバ10Bおよびデータベースサーバ20Bに対して、自サーバ20Aが運用系に変更されたことを通知し、データベースサーバ20Bは、アプリケーションサーバ10Bおよびデータベースサーバ20Aに対して、自サーバ20Bが待機系に変更されたことを通知するステップS1408~S1412。その後、アプリケーションサーバ10Aは、管理端末装置40A40Bに対してデータベースサーバの状態変更が完了したことを通知するステップS1412。次に、図15のシーケンス図を参照して、データベースサーバ10A10Bの状態がそれぞれ障害中、運用系のときに、データベース切り替えコマンドを入力した場合の動作について説明する。図16に示すように、管理者などがアプリケーションサーバ例えば、アプリケーションサーバ10Aにデータベース切り替えコマンドを入力するとステップS151、アプリケーションサーバ10A内のイベント監視部132Aは、データベースサーバ20A20Bの状態を切り替えることができるか否かを判定するステップS152。この判定は、前述したように、データベースサーバ20A20Bの内の一方が運用系、他方が待機系になっているか否かに基づいて行う。この場合、データベースサーバ20A20Bは、それぞれ障害中、運用系であるので、イベント監視部132Aは、切り替え不可能と判定し、管理端末装置40A40Bに対して切り替え失敗を通知するステップS163。第1の実施の形態の効果本実施の形態によれば、障害復旧を迅速に行うために必要となる、障害発生時のログ情報を残すことができる可能性を高いものにすることができるという効果を得ることができる。その理由は、各サーバ10A10B20A20Bが、それぞれ、自サーバに発生した障害を検出して他のサーバに対して障害発生通知を送信し、上記他のサーバからの障害発生通知を受信することにより上記他のサーバに対してログ要求を送信し、ログ要求を受信することにより要求元のサーバに対して自サーバのログを送信し、ログを受信することにより、受信したログを記憶部に記録するイベント監視部132232を備えているからである。また、本実施の形態によれば、管理者などが容易に障害の復旧方法を知ることができるという効果を得ることもできる。その理由は、障害IDと復旧方法とが関連付けて記録された復旧方法記憶部を備え、イベント監視部は、ログ情報に含まれている障害IDに関連付けて記録されている復旧方法を復旧方法記憶部から検索して管理端末装置へ送信するようにしているからである。本発明の第2の実施の形態次に、本発明の第2の実施の形態について説明する。本実施の形態は、データベースサーバがマウント状態のときに、アプリケーションサーバの死活監視部が誤ってデータベースサーバに障害が発生したと判定しないようにしたことを特徴とする。データベースサーバがマウント状態のときには、運用系、待機系のデータベースサーバ間でデータを同期させるために通信だけが行われ、アプリケーションサーバとの間の通信は切断されてしまう。このため、データベースサーバがマウント状態のときに、アプリケーションサーバの死活監視部がデータベースサーバに対して状態確認要求を送信しても、状態確認応答は戻って来ず、アプリケーションサーバはデータベースサーバに障害が発生したと判定してしまう。そこで、本実施の形態では、第1の実施の形態におけるデータベースサーバ20A20B上のイベント監視部232およびアプリケーションサーバ10A10B上の死活監視部132に次のような機能を付加することにより、上記した問題を解決した。第1の実施の形態では、データベースサーバ20A20B上の死活監視部232は、自サーバ20A20Bに障害が発生したときだけ、他のサーバに障害検出通知を送信するようにしたが、本実施の形態では、自サーバ20A20Bの状態がマウント状態、運用状態に切り替わったとき、マウント状態通知、運用状態通知をアプリケーションサーバ10A10Bに送信する。また、第1の実施の形態では、アプリケーションサーバのイベント監視部132では、状態確認要求に応答して状態確認応答が戻って来なかった場合は、データベースサーバに障害が発生したと判断したが、本実施の形態では、データベースサーバ20A20Bからマウント状態通知が送られてきてから運用状態通知が送られてくるまでの間は、データベースサーバ20A20Bに対して送信した状態確認要求に応答して状態確認通知が戻ってこなくとも、データベースサーバ20A20Bは正常であると判定する。第2の実施の形態の効果本実施の形態によれば、データベースサーバがマウント状態の時に、アプリケーションサーバが誤ってデータベースサーバに障害が発生したと判定しないようにすることができる。その理由は、データベースサーバ内のイベント監視部は、自サーバの状態がマウント状態、運用状態に変化した場合、アプリケーションサーバに対してマウント状態通知、運上状態通知を送信し、アプリケーションサーバの死活監視部では、マウント状態情報を受信してから運用状態情報を受信するまでの間は、状態確認要求に対する応答がデータベースサーバから戻って来なくとも、データベースが正常であると判定するようにしているからである。"