JP3141856B2 - 障害復旧補助方法及びその装置並びにプログラムを記録した機械読み取り可能な記録媒体 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータに障
害が発生した場合、利用者に適切な対処方法を提示する
技術に関し、特に、プログラムが行った処理を原因とす
る障害が発生した場合、利用者に適切な対処方法を提示
する技術に関する。

【０００２】

【従来の技術】オペレーティングシステム，アプリケー
ションプログラム等のプログラムの動作時に障害が発生
した場合、従来は、一般に、利用者が、システム側が出
力する障害メッセージとマニュアル等のドキュメントと
を突き合わせて障害の種類，原因を突き止めたり、対処
方法を得るようにしていた。しかし、この方法は、人手
によっているため、対処方法を得るまでに多くの時間が
費やされるという問題があると共に、利用者に負担がか
かるという問題があった。

【０００３】そこで、このような問題を解決するため、
障害メッセージと、対処方法と、説明文とを対応付けて
格納したテーブルを設けておき、障害メッセージが出力
された際、障害メッセージをキーにして上記テーブルを
検索し、障害メッセージに対応する対処方法，説明文を
利用者に提示するという技術が提案された（例えば、特
開平３−７５８４４号公報）。この従来の技術によれ
ば、障害発生時に、自動的に対処方法が提示されるの
で、利用者に負担をかけることなく、短時間で対処方法
を得ることが可能になる。

【０００４】

【発明が解決しようとする課題】しかしながら、上述し
た従来の技術には、次のような問題があった。つまり、
システム側が出力した障害メッセージに対応してテーブ
ルに登録されている対処方法を利用者に提示しているだ
けであるので、適切な対処方法が利用者に提示されない
場合があるという問題があった。

【０００５】例えば、或るプログラムが特定のファイル
をアクセスした時点で障害が発生したとすると、システ
ム側からは、上記特定のファイルに不正があることを示
す障害メッセージが出力される。しかし、この場合の根
本的な障害の原因は、上記特定のファイルに不正がある
ということではなく、何が上記特定のファイルに不正を
生じさせたかということである。例えば、障害メッセー
ジが出力される前に他のプログラムが上記特定のファイ
ルに不正を生じさせていたり、利用者の操作ミスが不正
を生じさせている場合には、それらが根本的な障害原因
となる。このように、障害メッセージが示す障害原因と
根本的な障害原因とが異なる場合、従来の技術では、根
本的な障害原因に対する対処方法が提示されないので、
提示された対処方法が適切なものでない場合があるとい
う問題があった。

【０００６】そこで、本発明の目的は、根本的な障害原
因に対する対処方法を提示できるようにすることにあ
る。

【０００７】

【課題を解決するための手段】本発明の障害復旧補助方
法は、上記目的を達成するため、プログラムの処理単位
の識別子に対応付けて、その処理単位が根本的な障害原
因となる可能性があるか否かを示す根本情報と、その処
理単位が根本的な障害原因とされた場合に於ける対処方
法とが格納されたドキュメントデータベースを設け、プ
ログラムの処理単位が実行される毎に、その処理単位の
識別子を実行順に状態監視テーブルに格納すると共に、
その処理単位に於いて使用したリソースを示すリソース
情報を、前記状態監視テーブルに格納した前記処理単位
の識別子と関連付けてリソースデータベースに格納し、
障害検出時、前記状態監視テーブルの内容，前記リソー
スデータベースの内容および前記ドキュメントデータベ
ースの内容に基づいて、根本的な障害原因となる処理単
位を求め、該求めた根本的な障害原因となる処理単位の
識別子に対応して前記ドキュメントデータベースに格納
されている対処方法を出力する。

【０００８】上記障害復旧補助方法を実施する好適な装
置として、本発明の障害復旧補助装置は、プログラムの
処理単位の識別子に対応付けて、その処理単位が根本的
な障害原因となる可能性があるか否かを示す根本情報
と、その処理単位が根本的な障害原因とされた場合に於
ける対処方法とが格納されたドキュメントデータベース
と、プログラムの処理単位が実行される毎に、その処理
単位の識別子が実行順に格納される状態監視テーブル
と、プログラムの処理単位が実行される毎に、その処理
単位に於いて使用したリソースを示すリソース情報が前
記状態監視テーブルに格納された識別子と関連付けて格
納されるリソースデータベースと、障害検出時、前記状
態監視テーブルの内容，前記リソースデータベースの内
容および前記ドキュメントデータベースの内容に基づい
て、根本的な障害原因となる処理単位を求める障害原因
調査部と、該障害原因調査部で求めた根本的な障害原因
となる処理単位の識別子に対応して前記ドキュメントデ
ータベースに格納されている対処方法を出力するドキュ
メント編集表示機構部とを備えている。

【０００９】この構成に於いては、障害検出時、障害原
因調査部が、前記状態監視テーブルの内容，前記リソー
スデータベースの内容および前記ドキュメントデータベ
ースの内容に基づいて、根本的な障害原因となる処理単
位を求め、ドキュメント編集表示機構部が、障害原因調
査部で求めた根本的な障害原因となる処理単位の識別子
に対応してドキュメントデータベースに格納されている
対処方法を出力する。

【００１０】

【発明の実施の形態】次に本発明の実施の形態について
図面を参照して詳細に説明する。

【００１１】図１は本発明の実施の形態の構成例を示す
ブロック図であり、オペレーティングシステムやアプリ
ケーションプログラム等のプログラム１と、状態監視テ
ーブル２と、リソースデータベース３と、ドキュメント
データベース４と、障害検出部５と、障害原因調査部６
と、リソース採取機構部７と、ドキュメント編集表示機
構部８と、表示部９とを備えている。

【００１２】プログラム１の処理単位にはそれぞれ異な
る状態識別子が割り当てられている。ここで、処理単位
とは、プログラム作成者が決める処理単位であり、例え
ば、関数を１つの処理単位とすることもできるし、関数
内を複数の部分に分割し、各部分を処理単位とすること
もできる。プログラム１は、その実行時に、処理単位を
実行する毎に、その処理単位の状態識別子を状態監視テ
ーブル２に実行順に格納する機能を有すると共に、その
処理単位で使用したリソースを示すリソース情報を、状
態監視テーブル２に格納されている状態識別子と関連付
けてリソースデータベース３に格納する機能を有する。

【００１３】ドキュメントデータベース４には、プログ
ラムの処理単位の識別子に対応付けて、その処理単位が
根本的な障害原因となる可能性があるか否かを示す根本
情報と、その処理単位が根本的な障害原因とされた場合
に於ける対処方法とが格納されている。

【００１４】障害原因調査部６は、障害検出部５が障害
を検出した時、状態監視テーブル２，リソースデータベ
ース３及びドキュメントデータベース４の内容に基づい
て、根本的な障害原因となった処理単位を求める機能
や、根本的な障害原因に対応する対処方法をドキュメン
トデータベース４から取り出す機能等を有する。

【００１５】リソース採取機構部７は、根本的な障害原
因となった処理単位がアクセスしたメモリアドレスのメ
モリイメージを採取する機能を有する。

【００１６】ドキュメント編集表示機構部８は、障害原
因調査部６がドキュメントデータベース４から取り出し
た対処方法や、リソース採取機構部７が採取したメモリ
イメージを編集して表示部９に表示する機能を有する。

【００１７】次に、本実施の形態の動作について説明す
る。

【００１８】プログラム１は、各処理単位を実行する毎
に、その処理単位に付与されている状態識別子を状態監
視テーブル２に実行順に書き込むと共に、その処理単位
で使用したリソースを示す情報を、状態監視テーブル２
に格納した状態識別子と関連付けてリソースデータベー
ス３に格納する。

【００１９】障害検出部５が障害発生を検出すると、障
害原因調査部６は、状態監視テーブル２，リソースデー
タベース３，ドキュメントデータベース４の内容に基づ
いて根本的な障害原因となった処理単位を探し出す（図
２，Ｓ１）。

【００２０】このＳ１の処理を詳細に説明すると、次の
ようになる。

【００２１】障害検出部５が障害を検出すると、障害原
因調査部６は、状態監視テーブル２の末尾のエントリ
（最後に状態識別子が格納されたエントリ）と関連する
リソースデータベース３のエントリからリソース情報を
取得し、それをキーとする（図３，Ｓ１１）。

【００２２】その後、障害原因調査部６は、状態監視テ
ーブル２のエントリを１つさかのぼり、そのエントリと
関連するリソースデータベース３のエントリの内容を参
照する（Ｓ１２，Ｓ１４）。そして、このエントリに格
納されているリソース情報が示すリソースの中に、キー
としているリソース情報が示すリソース（関連リソー
ス）が存在するか否かを判断する（Ｓ１５）。

【００２３】そして、関連リソースが存在しない場合
（Ｓ１５がＮＯ）は、Ｓ１２の処理に戻る。これに対し
て、関連リソースが存在する場合（Ｓ１５がＹＥＳ）に
は、現在注目している状態監視テーブル２のエントリに
格納されている状態識別子をキーにしてドキュメントデ
ータベース４を検索し、上記状態識別子に対応する根本
情報が参照する。そして、根本情報が、根本的な障害原
因になる可能性があることを示している場合は、上記状
態識別子に対応する処理単位が根本的な障害原因である
と判断して、その状態識別子を保持すると共に、Ｓ１４
で参照したエントリに格納されているリソース情報を保
持する（Ｓ１６）。

【００２４】その後、障害原因調査部６は、Ｓ１４で参
照したリソースデータベース３のエントリ中のリソース
情報に、現在キーにしているリソース情報に含まれてい
ないリソース情報が存在する場合は、そのリソース情報
をキーに追加した後（Ｓ１７）、Ｓ１２の処理に戻る。
尚、そのようなリソース情報が存在しない場合は、キー
の追加処理は行わずに、Ｓ１２の処理に戻る。上述した
処理を、状態監視テーブル２の全てのエントリに対して
行うと（Ｓ１３がＹＥＳ）、障害原因調査部６は、Ｓ２
の処理を行う。

【００２５】Ｓ２に於いて障害原因調査部６は、Ｓ１で
探し出した根本的な障害原因となった処理単位の状態識
別子に基づいてドキュメントデータベース４を検索して
対処方法を取得し、更に、この対処方法と上記処理単位
のリソース情報とを組み合わせた障害情報を生成してド
キュメント編集表示機構部８に渡す。このＳ２の処理に
於いて、障害原因調査部６は、上記処理単位のリソース
情報をリソース採取機構部７に渡す処理も行っている。

【００２６】リソース採取機構部７は、リソース情報が
渡されると、それに基づいてメモリイメージを採取し、
採取したメモリイメージをドキュメント編集表示機構部
８に渡す（Ｓ３）。

【００２７】ドキュメント編集表示機構部８は、障害原
因調査部６からの障害情報と、リソース採取機構部７か
らのメモリイメージとを編集して表示部９に表示する
（Ｓ４，Ｓ５）。

【００２８】このように、本実施の形態によれば、根本
的な障害原因に対する対処方法を利用者に提示すること
が可能になるので、適切な処置をとることが可能にな
る。

【００２９】図４は本実施の形態の第１の実施例のブロ
ック図であり、コンピュータ１０と、磁気ディスク装置
２０と、表示部３０と、記録媒体４０とを備えている。

【００３０】コンピュータ１０は、アプリケーションプ
ログラム１１と、オペレーティングシステム１２と、状
態監視テーブル１３と、リソースデータベース１４と、
障害原因調査部１５と、リソース採取機構部１６と、ド
キュメント編集表示機能部１７とを含んでいる。

【００３１】磁気ディスク装置２０は、ドキュメントデ
ータベース２１と、リソース保存領域２２とを含んでい
る。

【００３２】アプリケーションプログラム１１，オペレ
ーティングシステム１２の各処理単位には、それぞれ異
なる状態識別子が割り当てられている。ここで、処理単
位とは、プログラム作成者が決める処理単位であり、例
えば、関数を１つの処理単位とすることもできるし、関
数内を複数の部分に分割し、各部分を処理単位とするこ
ともできる。アプリケーションプログラム１１，オペレ
ーティングシステム１２は、その実行時に、処理単位を
実行する毎に、その処理単位の状態識別子を状態監視テ
ーブル１３に実行順に格納する機能を有すると共に、そ
の処理単位で使用したリソースを示すリソース情報を、
状態監視テーブル１３に格納されている状態識別子と関
連付けてリソースデータベース１４に格納する機能を有
する。

【００３３】状態監視テーブル１３には、図５に示すよ
うに、状態識別子と、状態識別子の格納順を示す第１ポ
インタと、関連するリソース情報を指し示す第２ポイン
タとが登録される。

【００３４】リソースデータベース１４には、図５に示
すように、状態識別子と、リソース情報とが格納され
る。リソース情報は、使用したリソースを示すものであ
り、使用したファイル（環境設定ファイル，一時ファイ
ル等）のファイル名や、他の処理単位や利用者とやり取
りした入出力値や、使用したメモリのアドレス等を含
む。

【００３５】ドキュメントデータベース２１には、コン
ピュータ１０上で実行される全てのプログラムの処理単
位の状態識別子が格納されると共に、各状態識別子に対
応付けて下記の情報が格納されている。

【００３６】・根本情報…根本的な障害原因になる可能
性があるか否かを示す情報。 ・対処方法…根本情報が根本的な障害原因となる可能性
があることを示している場合のみ設定されるものであ
り、「変数ａの入力値が正しいことを確認して下さ
い。」，「以下の情報を確認して下さい。α，β」等の
ような対処方法を示すものである。 ・コンポーネント種別…アプリケーションプログラムの
ｚ関数，カーネル内のｙ関数等のようなコンポーネント
の種別を示す情報である。 ・動作内容の概要…「変数ａを入力し、ファイルｘに出
力」，「利用者からの入力によってｚｚｚを実行」等の
動作内容の概要を示すものである。

【００３７】障害原因調査部１５は、障害検出部１２ａ
が障害を検出した時、状態監視テーブル１３，リソース
データベース１４及びドキュメントデータベース２１の
内容に基づいて根本的な障害原因となった処理単位を探
し出す機能や、探し出した処理単位の状態識別子に対応
してドキュメントデータベース２１に格納されている対
処方法を取得する機能等を有する。

【００３８】リソース採取機構部１６は、根本的な障害
原因となった処理単位がアクセスしたメモリアドレスの
メモリイメージを採取する機能を有する。

【００３９】ドキュメント編集表示機構部１７は、障害
原因調査部１５がドキュメントデータベース２１から取
り出した対処方法や、リソース採取機構部１６が採取し
たメモリイメージを編集して表示部３０に表示する機能
を有する。

【００４０】記録媒体４０は、ディスク，半導体メモ
リ，その他の記録媒体であり、コンピュータ１０を障害
復旧補助装置として機能させるためのプログラムが記録
されている。この記録媒体４０に格納されているプログ
ラムは、コンピュータ１０によって読み取られ、コンピ
ュータ１０の動作を制御することにより、コンピュータ
１０上に、障害原因調査部１５，リソース採取機構部１
６，ドキュメント編集表示機構部１７を実現する。

【００４１】次に、本実施例の動作を、２つのアプリケ
ーションプログラムＡＰ０１，ＡＰ０２が動作している
場合を例にとって説明する。尚、アプリケーションプロ
グラムＡＰ０１は、利用者の要求によってデータベース
ＤＢ０１を検索し、その結果をファイルＦ０１に出力す
るものとし、アプリケーションプログラムＡＰ０２は、
利用者の入力によってデータベースＤＢ０１の内容を更
新するものとする。

【００４２】今、アプリケーションプログラムＡＰ０１
の実行中に障害検出部１２ａが障害を検出したとする。
この時、状態監視テーブル１３の末尾のエントリには、
図５に示すように、アプリケーションプログラムＡＰ０
１の処理単位の内の、実行中であった処理単位の状態識
別子「ＡＰ０１：００２」が格納されている。また、リ
ソースデータベース１４には、上記処理単位が使用して
いたリソースを示すリソース情報「ファイル名；ＤＢ０
１，エントリ；ＸＸＸ」が、状態監視テーブル１３の末
尾のエントリの関連付けて格納されている。

【００４３】障害原因調査部１５は、障害検出部１２ａ
が障害を検出すると、図３の流れ図に示すように、状態
監視テーブル１３の末尾のエントリに関連付けられてい
るリソースデータベース１４のエントリに格納されてい
るリソース情報「ファイル名；ＤＢ０１，エントリ；Ｘ
ＸＸ」をキーとする（Ｓ１１）。

【００４４】その後、障害原因調査部１５は、状態監視
テーブル１３のエントリを１つ逆上り、そのエントリと
関連するリソースデータベース１４のエントリを参照す
る（Ｓ１２，Ｓ１４）。今、例えば、参照したリソース
データベース１４のエントリに、リソース情報として
「ファイル名；ＤＢ０１，エントリ；ＸＸＸ，入力値；
ＹＹＹ」が格納されていたとすると、Ｓ１５の判断結果
がＹＥＳとなるので、障害原因調査部１５は、Ｓ１６の
処理を行う。

【００４５】Ｓ１６に於いて、障害原因調査部１５は、
現在注目している状態監視テーブル１３のエントリ（末
尾から２番目のエントリ）に格納されている状態識別子
「ＡＰ０２：００６」をキーにしてドキュメントデータ
ベース２１を検索し、状態識別子「ＡＰ０２：００６」
に対応する根本情報を取得する。今、根本情報が、根本
的な障害原因になる可能性があることを示しているとす
ると、障害原因調査部１５は、状態識別子「ＡＰ０２：
００６」を根本的な障害原因となる処理単位の状態識別
子として保持すると共に、Ｓ１４で参照したエントリ中
のリソース情報「ファイル名；ＤＢ０１，エントリ；Ｘ
ＸＸ，入力値；ＹＹＹ」を上記状態識別子と組にして保
持する。

【００４６】その後、障害原因調査部１５は、Ｓ１６で
保持したリソース情報「ファイル名；ＤＢ０１，エント
リ；ＸＸＸ，入力値；ＹＹＹ」に、現在キーにしている
リソース情報「ファイル名；ＤＢ０１，エントリ；ＸＸ
Ｘ」に含まれていないリソース情報「入力値；ＹＹＹ」
が存在するので、現在のキーに「入力値；ＹＹＹ」を追
加した「ファイル名；ＤＢ０１，エントリ；ＸＸＸ，入
力値；ＹＹＹ」を新たなキーとした後（Ｓ１７）、状態
監視テーブル１３のエントリを１つ逆上り、末尾から３
番目のエントリに注目する（Ｓ１２）。その後、障害原
因調査部１５は、上記末尾から３番目のエントリと対応
する、リソースデータベース１４のエントリを参照する
（Ｓ１４）。

【００４７】今、例えば、参照したリソースデータベー
ス１４のエントリに、リソース情報として「出力値：Ｙ
ＹＹ，入力値０００」が格納されていたとすると、Ｓ１
５の判断結果がＹＥＳとなるので、障害原因調査部１５
は、Ｓ１６の処理を行う。

【００４８】障害原因調査部１５は、現在注目している
状態監視テーブル１３のエントリ（末尾から３番目のエ
ントリ）に格納されている状態識別子「ＡＰ０１：００
１」をキーにしてドキュメントデータベース２１を検索
し、状態識別子「ＡＰ０１：００１」に対応する根本情
報を取得する。今、根本情報が、根本的な障害原因にな
る可能性があることを示していないとすると、障害原因
調査部１５は、状態識別子「ＡＰ０１：００１」を保持
することなく、Ｓ１７の処理を行う。上述した処理を状
態監視テーブル１３の最後のエントリまで行うと、障害
原因調査部１５は、図２の流れ図に示すＳ２の処理を行
う。

【００４９】Ｓ２に於いては、Ｓ１６で保持した状態識
別子をキーにしてドキュメントデータベース２１を検索
し、上記状態識別子と対応して格納されている対処方法
を取得する。その後、取得した対処方法と、Ｓ１６で保
持したリソース情報とを組み合わせた障害情報を生成し
てドキュメント編集表示機能部１７に渡すと共に、リソ
ース情報をリソース採取機構部１６に渡す。尚、Ｓ１６
で保持した状態識別子とリソース情報の組が複数存在す
る場合には、それぞれの組に対して上述した処理を行う
ようにしても良いし、最後に保持した組に対してのみ上
述した処理を行うようにしても良い。つまり、最後に保
持した組に含まれている状態識別子の処理単位が、根本
的な障害原因である可能性が高いので、最後に保持した
組に対してのみ、上述した処理を行うようにしても良
い。また、複数の組が保持されている場合には、各組に
ついて障害情報を作成し、更に各障害情報に優先度（最
後に保持した組ついての障害情報の優先度を最も高く
し、最初に保持した組についての障害情報の優先度を最
も低くする）を組み込むようにしても良い。

【００５０】リソース採取機構部１６は、リソース情報
が渡されると、それに含まれているメモリアドレスが示
すメモリイメージを採取し、リソース保存領域２２に格
納すると共に、ドキュメント編集表示機能部１７に渡す
（Ｓ３）。

【００５１】これにより、ドキュメント編集表示機能部
１７は、障害原因調査部１５からの障害情報とリソース
採取機構部１６からのメモリイメージとを編集し、表示
部３０に表示する（Ｓ４，Ｓ５）。

【００５２】図６は第２の実施例のブロック図であり、
コンピュータ１０ａと、磁気ディスク装置２０ａと、表
示部３０と、記録媒体４０ａとを備えている。

【００５３】本実施例のコンピュータ１０ａは、状態監
視テーブル１３，リソースデータベース１４を備えてい
ない点と、障害原因調査部１５の代わりに障害原因調査
部１５ａを備えている点が図４に示したコンピュータ１
０と相違している。

【００５４】障害原因調査部１５ａは、障害検出部１２
ａが障害を検出した場合だけでなく、コンピュータ１０
ａの再起動時にも、図２に示したＳ１，Ｓ２の処理を行
う機能を有する。尚、コンピュータ１０ａの他の構成要
素１１，１２，１２ａ，１６，１７は、第１の実施例に
於いて同一符号を付した構成要素と同様の機能を有す
る。

【００５５】また、本実施例の磁気ディスク装置２０ａ
は、ドキュメントデータベース２１，リソース保存領域
２２の他に、状態監視テーブル１３，リソースデータベ
ース１４を備えている点が図４に示した第１の実施例に
於ける磁気ディスク装置２０と相違している。

【００５６】記録媒体４０ａはディスク，半導体メモ
リ，その他の記録媒体であり、コンピュータ１０ａを障
害復旧補助装置として機能させるためのプログラムが記
録されている。この記録媒体４０ａに記録されているプ
ログラムは、コンピュータ１０ａによって読み取られ、
コンピュータ１０ａの動作を制御することにより、コン
ピュータ１０ａ上に障害原因調査部１５ａ，リソース採
取機構部１６，ドキュメント編集表示機構部１７を実現
する。

【００５７】次に、本実施例の動作を説明する。

【００５８】アプリケーションプログラム１１，オペレ
ーティングシステム１２は、前述した実施例と同様にそ
の処理単位を実行する毎に、状態監視テーブル１３に状
態識別子を格納すると共に、リソースデータベース１４
にリソース情報を格納する。コンピュータ１０ａに、そ
の動作が不可能となる障害が発生した場合であっても、
状態監視テーブル１３，リソースデータベース１４は、
不揮発性の磁気ディスク装置２０ａに設けられているの
で、その内容は保存される。

【００５９】コンピュータ１０ａの再起動時、障害原因
調査部１５ａが、図２の流れ図に示したＳ１，Ｓ２の処
理を行い、リソース採取機構部１６がＳ３の処理を行
い、ドキュメント編集表示機構部１７がＳ４，Ｓ５の処
理を行う。これにより、表示部３０に対処方法を含む障
害情報や、メモリイメージが表示される。

【００６０】このように、本実施例では、状態監視テー
ブル１３，リソースデータベース１４を不揮発性の磁気
ディスク装置２０ａ上に設けるようにしているので、コ
ンピュータ１０ａの動作が不可能になるような障害が発
生した場合であっても、コンピュータ１０ａの再起動時
に、根本的な障害原因に対する対処方法を提示すること
が可能になる。尚、本実施例に於いては、磁気ディスク
装置２０ａ上に状態監視テーブル１３，リソースデータ
ベース１４を設けるようにしたが、他の不揮発性の記憶
装置上に設けるようにしても良い。

【００６１】

【発明の効果】以上説明したように、本発明は、障害検
出時、状態監視テーブル，リソースデータベースおよび
ドキュメントデータベースの内容に基づいて、根本的な
障害原因となる処理単位を求め、更に、根本的な障害原
因となる処理単位の識別子に対応してドキュメントデー
タベースに格納されている対処方法を利用者に提示する
ようにしているので、根本的は障害原因に対応する適切
な対処方法を利用者に提示できる効果がある。

【００６２】また、本発明は、状態監視テーブル，リソ
ースデータベースを不揮発性の記憶装置上に構成したの
で、コンピュータの動作が不可能になるような障害が発
生した場合であっても、再起動時に、根本的な障害原因
に対する対処方法を提示することが可能になる効果があ
る。

【図面の簡単な説明】

【図１】本発明の実施の形態の構成例を示すブロック図
である。

【図２】実施の形態及び第１，第２の実施例の処理例を
示す流れ図である。

【図３】図２に示したＳ１の詳細な処理例を示す流れ図
である。

【図４】本発明の実施の形態の第１の実施例のブロック
図である。

【図５】状態監視テーブル１３，リソースデータベース
１４の内容例を示す図である。

【図６】本発明の実施の形態の第２の実施例のブロック
図である。

【符号の説明】

１…プログラム ２…状態監視テーブル ３…リソースデータベース ４…ドキュメントデータベース ５…障害検出部 ６…障害原因調査部 ７…リソース採取機構部 ８…ドキュメント編集表示機構部 ９…表示部 １０，１０ａ…コンピュータ １１…アプリケーションプログラム １２…オペレーティングシステム １２ａ…障害検出部 １３…状態監視テーブル １４…リソースデータベース １５，１５ａ…障害原因調査部 １６…リソース採取機構部 １７…ドキュメント編集表示機構部 ２０，２０ａ…磁気ディスク装置 ２１…ドキュメントデータベース ２２…リソース保存領域 ３０…表示部 ４０，４０ａ…記録媒体

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平３−75844（ＪＰ，Ａ) 特開 平５−265801（ＪＰ，Ａ) 特開 平６−242989（ＪＰ，Ａ) 特開 平４−287134（ＪＰ，Ａ) 特開 平４−175834（ＪＰ，Ａ) 特開 昭63−188246（ＪＰ，Ａ) 特開 平１−96740（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 11/28 - 11/36 G06F 11/22

Claims (9)

(57)【特許請求の範囲】
1. 【請求項１】 プログラムの処理単位の識別子に対応付
   けて、その処理単位が根本的な障害原因となる可能性が
   あるか否かを示す根本情報と、その処理単位が根本的な
   障害原因とされた場合に於ける対処方法とが格納された
   ドキュメントデータベースを設け、 プログラムの処理単位が実行される毎に、その処理単位
   の識別子を実行順に状態監視テーブルに格納すると共
   に、その処理単位に於いて使用したリソースを示すリソ
   ース情報を、前記状態監視テーブルに格納した前記処理
   単位の識別子と関連付けてリソースデータベースに格納
   し、 障害検出時、前記状態監視テーブルの内容，前記リソー
   スデータベースの内容および前記ドキュメントデータベ
   ースの内容に基づいて、根本的な障害原因となる処理単
   位を求め、 該求めた根本的な障害原因となる処理単位の識別子に対
   応して前記ドキュメントデータベースに格納されている
   対処方法を出力することを特徴とする障害復旧補助方
   法。
2. 【請求項２】 障害検出時、前記リソースデータベース
   に格納されているリソース情報の内の、前記障害検出時
   に実行されていた処理単位のリソース情報を出発点にし
   て前記リソースデータベースに格納されているリソース
   情報を格納順と反対の順番で辿ることにより、前記出発
   点としたリソース情報によって示されるリソースを使用
   している処理単位であって且つ前記ドキュメントデータ
   ベース中の根本情報が根本的な障害原因となる可能性が
   あることを示している処理単位を探し出し、その後、探
   し出した処理単位のリソース情報を出発点にして前記リ
   ソースデータベースに格納されているリソース情報を格
   納順と反対の順番で辿ることにより前記出発点としたリ
   ソース情報によって示されるリソースを使用している処
   理単位であって且つ前記ドキュメントデータベース中の
   根本情報が根本的な障害原因となる可能性があることを
   示している処理単位を探し出すという処理を繰り返し行
   い、探し出した処理単位を根本的な障害原因の処理単位
   とすることを特徴とする請求項１記載の障害復旧補助方
   法。
3. 【請求項３】 前記状態監視テーブル及び前記リソース
   データベースは、不揮発性の記憶装置上に設けられ、 コンピュータの再起動時、前記リソースデータベースに
   格納されているリソース情報の内の、前記障害検出時に
   実行されていた処理単位のリソース情報を出発点にして
   前記リソースデータベースに格納されているリソース情
   報を格納順と反対の順番で辿ることにより、前記出発点
   としたリソース情報によって示されるリソースを使用し
   ている処理単位であって且つ前記ドキュメントデータベ
   ース中の根本情報が根本的な障害原因となる可能性があ
   ることを示している処理単位を探し出し、その後、探し
   出した処理単位のリソース情報を出発点にして前記リソ
   ースデータベースに格納されているリソース情報を格納
   順と反対の順番で辿ることにより前記出発点としたリソ
   ース情報によって示されるリソースを使用している処理
   単位であって且つ前記ドキュメントデータベース中の根
   本情報が根本的な障害原因となる可能性があることを示
   している処理単位を探し出すという処理を繰り返し行
   い、探し出した処理単位を根本的な障害原因の処理単位
   とすることを特徴とする請求項２記載の障害復旧補助方
   法。
4. 【請求項４】 前記リソース情報は、処理単位がアクセ
   スしたメモリアドレスを含み、 根本的な障害原因となる処理単位の識別子に対応して前
   記ドキュメントデータベースに格納されている対処方法
   を出力する際、前記根本的な障害原因となる処理単位の
   リソース情報に含まれているメモリアドレスが示すメモ
   リイメージも併せて出力することを特徴とする請求項２
   記載の障害復旧補助方法。
5. 【請求項５】 プログラムの処理単位の識別子に対応付
   けて、その処理単位が根本的な障害原因となる可能性が
   あるか否かを示す根本情報と、その処理単位が根本的な
   障害原因とされた場合に於ける対処方法とが格納された
   ドキュメントデータベースと、 プログラムの処理単位が実行される毎に、その処理単位
   の識別子が実行順に格納される状態監視テーブルと、 プログラムの処理単位が実行される毎に、その処理単位
   に於いて使用したリソースを示すリソース情報が前記状
   態監視テーブルに格納された識別子と関連付けて格納さ
   れるリソースデータベースと、 障害検出時、前記状態監視テーブルの内容，前記リソー
   スデータベースの内容および前記ドキュメントデータベ
   ースの内容に基づいて、根本的な障害原因となる処理単
   位を求める障害原因調査部と、 該障害原因調査部で求めた根本的な障害原因となる処理
   単位の識別子に対応して前記ドキュメントデータベース
   に格納されている対処方法を出力するドキュメント編集
   表示機構部とを備えたことを特徴とする障害復旧補助装
   置。
6. 【請求項６】 前記障害原因調査部は、障害検出時、前
   記リソースデータベースに格納されているリソース情報
   の内の、前記障害検出時に実行されていた処理単位のリ
   ソース情報を出発点にして前記リソースデータベースに
   格納されているリソース情報を格納順と反対の順番で辿
   ることにより、前記出発点としたリソース情報によって
   示されるリソースを使用している処理単位であって且つ
   前記ドキュメントデータベース中の根本情報が根本的な
   障害原因となる可能性があることを示している処理単位
   を探し出し、その後、探し出した処理単位のリソース情
   報を出発点にして前記リソースデータベースに格納され
   ているリソース情報を格納順と反対の順番で辿ることに
   より前記出発点としたリソース情報によって示されるリ
   ソースを使用している処理単位であって且つ前記ドキュ
   メントデータベース中の根本情報が根本的な障害原因と
   なる可能性があることを示している処理単位を探し出す
   という処理を繰り返し行い、探し出した処理単位を根本
   的な障害原因の処理単位とする構成を有することを特徴
   とする請求項５記載の障害復旧補助装置。
7. 【請求項７】 前記状態監視テーブル及び前記リソース
   データベースは、不揮発性の記憶装置上に構成され、 前記障害原因調査部は、コンピュータの再起動時、前記
   リソースデータベースに格納されているリソース情報の
   内の、前記障害検出時に実行されていた処理単位のリソ
   ース情報を出発点にして前記リソースデータベースに格
   納されているリソース情報を格納順と反対の順番で辿る
   ことにより、前記出発点としたリソース情報によって示
   されるリソースを使用している処理単位であって且つ前
   記ドキュメントデータベース中の根本情報が根本的な障
   害原因となる可能性があることを示している処理単位を
   探し出し、その後、探し出した処理単位のリソース情報
   を出発点にして前記リソースデータベースに格納されて
   いるリソース情報を格納順と反対の順番で辿ることによ
   り前記出発点としたリソース情報によって示されるリソ
   ースを使用している処理単位であって且つ前記ドキュメ
   ントデータベース中の根本情報が根本的な障害原因とな
   る可能性があることを示している処理単位を探し出すと
   いう処理を繰り返し行い、探し出した処理単位を根本的
   な障害原因の処理単位とする構成を有することを特徴と
   する請求項６記載の障害復旧補助装置。
8. 【請求項８】 前記リソース情報は、処理単位でアクセ
   スしたメモリアドレスを含み、且つ、 前記障害原因調査部で根本的な障害原因とされた処理単
   位のリソース情報に含まれているメモリアドレスが示す
   メモリイメージを採取するリソース採取機構部を備え、 前記ドキュメント編集表示機構部は、根本的な障害原因
   となる処理単位の識別子に対応して前記ドキュメントデ
   ータベースに格納されている対処方法と前記リソース採
   取機構部が採取したメモリイメージとを編集して出力す
   る構成を有することを特徴とする請求項６記載の障害復
   旧補助装置。
9. 【請求項９】 プログラムの処理単位の識別子に対応付
   けて、その処理単位が根本的な障害原因となる可能性が
   あるか否かを示す根本情報と、その処理単位が根本的な
   障害原因とされた場合に於ける対処方法とが格納された
   ドキュメントデータベースと、プログラムの処理単位が
   実行される毎に、その処理単位の識別子が実行順に格納
   される状態監視テーブルと、プログラムの処理単位が実
   行される毎に、その処理単位に於いて使用したリソース
   を示すリソース情報が前記状態監視テーブルに格納され
   た識別子と関連付けて格納されるリソースデータベース
   とを有するコンピュータを障害復旧補助装置として機能
   させるためのプログラムを記録した機械読み取り可能な
   記録媒体であって、 前記コンピュータを、 障害検出時、前記状態監視テーブルの内容，前記リソー
   スデータベースの内容および前記ドキュメントデータベ
   ースの内容に基づいて、根本的な障害原因となる処理単
   位を求める障害原因調査部、 該障害原因調査部で求めた根本的な障害原因となる処理
   単位の識別子に対応して前記ドキュメントデータベース
   に格納されている対処方法を出力するドキュメント編集
   表示機構部、として機能させるためのプログラムを記録
   したことを特徴とするプログラムを記録した機械読み取
   り可能な記録媒体。