障害の種類の判別


	BEA ホーム \| イベント \| ソリューション \| パートナ \| 製品 \| サービス \| ダウンロード \| ディベロッパ・センタ \| WebSUPPORT
	e-docs \| サイトマップ \| 検索 \| PDF版 \| お問い合わせ \| 用語集

Tuxedo ホーム \| BEA Tuxedo アプリケーション実行時の管理 \| 先頭へ \| 前へ \| 次へ \| 目次

障害の種類の判別

トラブルシューティングの最初のステップとして、まずどこで障害が発生したかを判別します。ほとんどのアプリケーションでは、障害の発生源として以下の 6 か所が考えられます。

アプリケーション
BEA Tuxedo システム
データベース管理ソフトウェア
Network
オペレーティング・システム
ハードウェア

障害が発生した場所を特定できたら、各箇所の担当者と協力して障害を解決してください。たとえば、ネットワーキングに関する障害が発生した場合は、ネットワーク管理者と協力して解決してください。

アプリケーション障害の原因の判別

アプリケーション障害の原因を検出するには、次の手順に従います。

ユーザ・ログ (ULOG) 内で、BEA Tuxedo システムの警告メッセージとエラー・メッセージを調べます。
発生した問題を反映していると思われる内容のメッセージをいくつか選択します。各メッセージのカタログ名とメッセージ番号を書き留めておき、該当するメッセージをシステム・メッセージで調べます。マニュアルの各項目には次の情報が含まれています。
- メッセージが示すエラーの詳細内容
- エラーを解決するための推奨措置
ULOG 内でアプリケーションの警告メッセージとエラー・メッセージを調べます。
アプリケーション・サーバおよびアプリケーション・クライアントによって生成された警告とエラーを調べます。このようなメッセージは通常、標準出力ファイルおよび標準エラー・ファイルに送られます (デフォルト名はそれぞれ stdout および stderr)。
- stdout ファイルおよび stderr ファイルは APPDIR 変数で定義されたディレクトリにあります。
- クライアント側とサーバ側に設定されている stdout ファイルおよび stderr ファイルの名前は、変更されている場合があります。stdout ファイルと stderr ファイルの名前を変更するには、コンフィギュレーション・ファイル内で、該当するクライアントとサーバの定義にそれぞれ -e または -o を指定します。詳細については、『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』の servopts(5) を参照してください。
APPDIR 変数で定義されたディレクトリにコア・ダンプがないかどうかを調べます。dbx などのデバッガを使用してスタック・トレースを実行します。コア・ダンプが見つかった場合は、アプリケーション開発者に通知します。
sar(1) などのコマンドを実行してシステム・アクティビティ・レポートを表示し、システムが正しく機能しない原因を調べます。以下の原因が考えられます。
- システムのメモリが不足している。
- カーネルが正しくチューニングされていない。

BEA Tuxedo システムでの障害の原因の判別

システム障害の原因を検出するには、次の手順に従います。

ユーザ・ログ (ULOG) 内で、BEA Tuxedo システムの警告メッセージとエラー・メッセージを調べます。
- TPEOS メッセージは、オペレーティング・システムにエラーが発生したことを示します。
- TPESYSTEM メッセージは、BEA Tuxedo システムにエラーが発生したことを示します。
発生した問題を反映していると思われる内容のメッセージをいくつか選択します。各メッセージのカタログ名とメッセージ番号を書き留めておき、該当するメッセージをシステム・メッセージで調べます。マニュアルの各項目には次の情報が含まれています。
- メッセージが示すエラーの詳細内容
- エラーを解決するための推奨措置
次の手順でデバッグの準備をします。
- suspend サービスをシャットダウンします。
- tmboot -n -s(server) -d1 を実行します(このコマンドを実行してもサーバは起動しませんが、サーバを起動するためのコマンド行が出力されます)。dbx などのデバッガを指定して、このコマンド行を使用してください。