問題判別の手引き
DB2 を使用してある編成をサポートしている場合、
種々の問題を解決するためにユーザーからの連絡を受けることがあります。
どのように応答するかは、以下の事柄によって左右されます。
- 問題の重大度
- 問題固有の性質
- 収集できる関連情報
- 類似した問題を解決した経験の度合い
問題を解決するには、その問題に関する包括的な記述を得ることが先決です。
その際、問題箇所を判別することから始めます。
たとえば、問題が以下のいずれかにある場合があります。
- ハードウェア
- オペレーティング・システム
- ネットワーキング・システムまたはその他のサブシステム
- DB2 サーバー
- DB2 クライアント
- ホスト・システムに接続した DB2 コネクト ゲートウェイ
ほとんどのアプリケーションは、クライアント / サーバー環境で実行します。
問題がクライアント、サーバー、
またはクライアントとサーバーの間のどこか (つまり、LAN または通信プロトコル・スタック内) にあるのかどうかを判別しなければなりません。
まず最初に、問題が検出または報告された場所を調べます。
たとえば、クライアント上で予期しない SQLCODE を受け取った場合には、
そのクライアント上の SQLCODE を調べてください。
(詳細については、予期しないメッセージまたは SQLCODE への応答を参照。)
SQLCODE だけで問題が起きた場所と原因を十分判別できる、ということもよくあります。
SQLCODE の情報だけでは問題が起きた場所をはっきりと判別できない場合には、
問題が報告された区画サーバーの db2diag.log ファイルを調べます。
たとえば、問題がクライアントで報告された場合には、
そのクライアントにある db2diag.log ファイルをまず調べます。
db2diag.log ファイルは、DB2 によって書き込まれる ASCII ファイルで、DB2 が使用する診断情報が含まれています。
db2diag.log ファイルは、DB2 コード中で検出された例外を報告します。
問題が発生した日時が分かる場合には、
それに対応する db2diag.log 項目に直接進むことができます。
注: | ユーザー・アプリケーションの問題に関するエラー・メッセージが出ても、
DB2 で例外が起きることはほとんどありません。
この種の問題は、通常の DB2 処理の一部として扱われます。
したがって、db2diag.log ファイルではこの種の問題は報告されません。
|
この重要なファイルについては、初期障害データ捕そく機能を参照してください。
このファイルを調べるときには、
最新の条件が常に最後にあることを忘れないようにしてください。
予期しないメッセージまたは SQLCODE を受け取った場合には、
問題を判別できるまで以下のステップを実行してください。
- メッセージを受け取ったならば、
以下の内容を含む利用可能なすべての情報に注目します。
- コード。8 桁の英数字メッセージ識別番号。
このコードは、先頭に SQL、DBA、または CCA という接頭部が付いています。
また、すべての理由コード、戻りコード、および戻されるメッセージと
関連したその他の情報にも注目します。
-
受け取ったすべての SQLSTATE。
SQLSTATE はどのプラットフォームでも同じものが使われているので、
問題を診断するのに役立ちます。
SQLSTATE のリストについては、メッセージ解説書 を参照してください。
- メッセージのテキスト (メッセージに識別番号またはコードが含まれていない場合には特に必要です)。
- 使用可能であれば SQLCA
- メッセージの中で推奨されている処置
- db2diag.log ファイルなどの診断ファイル。
さらに、トレースバック・ファイル、コア・ファイル (UNIX ベースのシステムの場合)、
イベント・ログ (Windows NT の場合)、syslog ファイル (OS/2 の場合)、
およびダンプなどの、オペレーティング・システムの診断ファイルに注目します。
第 2 部, DB2 での高度な問題判別を参照してください。
- メッセージが生成された環境。
たとえば、メッセージ生成時にユーザーが実行していた操作、
問題が生じるまでに実行した処理手順、オペレーティング・システムの種類、
実行していたアプリケーション、通信プロトコル。
RUNSTATS、REORG、LOAD、
IMPORT などのユーティリティーが使用されていたかどうかにも注目します。
- エラーが発生した SQL ステートメント、および同じ作業単位内の先行ステートメント。
- コマンド・プロンプトで db2 "? message" と入力して、
オンライン・メッセージ・ヘルプを調べます。
ここで、message は完全な SQLCODE、
SQLSTATE、またはメッセージ番号を表します。
推奨されている処置を読み、それに従ってください。
- 追加情報については、SQLCODE またはメッセージ番号を使用して、
利用可能な DB2 資料を検索します。
- 問題が解決されない場合には、
以下の情報をできるだけ多く入手してから、DB2 カスタマー・サポートと連絡をとります。
- DB2 診断ログ (db2diag.log)、およびその中に示されているトラップまたはダンプ・ファイル。
初期障害データ捕そく機能を参照してください。
- db2diag.log または syslog ファイルからの SQLCA 構造、
またはアプリケーションによって取り込まれた SQLCA 構造。
SQLCA 構造の解釈を参照してください。
- DB2 ではなく、ベンダー提供のアプリケーションに問題があることが分かった場合は、
そのベンダーと連絡をとってください。
本書では、異常終了 という用語には、
以下のことが含まれます。
- Windows システム上でのセグメンテーション違反および一般保護障害 (GPF)
- OS/2 上でのトラップ
- UNIX ベース・システム上での例外状況
異常終了が起きた場合、
問題を判別できるまで以下のステップを順番に実行してください。
- 特に、修正パックを最近インストールした場合、
すべての DB2 コンポーネント (クライアント、サーバー、DB2 コネクト、
エンタープライズ拡張エディション・システム中の個々の区分サーバー) が、同じサービス・レベルであることを確認します。
DB2 製品の更新を参照してください。
- 異常終了を報告した実行可能モジュールに注目します。
- 問題が解決されない場合には、
以下の追加情報を収集してから、DB2 カスタマー・サポートと連絡をとります。
- すべてのログ記録情報。特に以下の情報。
- 問題が再現可能であり、再びシステムを異常終了させることができるのであれば、
クライアント上およびサーバー上のトレースは役立ちます。
ファイルを使用したトレースの例のステップに従ってください。
詳細については、第 2 部, DB2 での高度な問題判別を参照してください。
- DB2 ではなく、ベンダー提供のアプリケーションに問題があることが分かった場合は、
そのベンダーと連絡をとってください。
システムが中断またはループしているような場合、
以下のステップを実行して問題を識別します。
- メッセージ、db2diag.log ファイル、およびその他の情報を使用して、
中断またはループが発生した理由を判別します。
中断またはループの原因となる一般的な問題の中には、
以下が含まれているものもあります。
- システムを回復します。
- オペレーティング・システムが中断している (ディスクが動いている様子がない) 場合、
マシンをリブートし、db2diag.log ファイルを見て問題を調べます。
また、ハードウェアのオペレーティング・システム・レポートを調べます。
たとえば、AIX の場合は errpt -a を使用します。
- オペレーティング・システムにアクセスできても、
アプリケーションにアクセスできない場合には、以下のようにします。
- コントロール・センターまたは LIST APPLICATIONS FOR DATABASE database-alias コマンドを使用してアプリケーションの状況を調べます。
状況情報には、
アプリケーションがデータベース管理プログラムの内部で中断されているかどうかではなく、
実行中か (UOW Executing)、ロックを待機しているか (Lock Wait)、
それともユーザー入力を待機しているか (UOW Waiting (W;大文字)) が示されます。
- CPU モニターを使用して、大量の CPU 時間を使用しているアプリケーションを調べ、
アプリケーションが中断されているか否かまたは期待通りに実行しているかどうかを判別します。
- AIX の iostat などのオペレーティング・システム・コマンドを使用して、
ディスクの活動を調べます。
- DB2 の問題があるかどうか、db2diag.log ファイルを調べます。
- UNIX ベースの環境では、DB2 インスタンスを停止するまで以下のステップを実行します。
- db2stop を使用して、
通常の方法で DB2 インスタンスを停止します。
- db2stop force を使用して、DB2 インスタンスを停止し、
残りのアプリケーションをすべて強制終了します。
上記の方式を使用して DB2 インスタンスを停止できない場合もあります。
できる限り多くの情報を収集してから、以下のステップを実行してください。
これには以下のステップが含まれます。
- 個々の区分サーバーからスナップショットを取ります。
- 個々の区分サーバー上で ps -ef を使用して、結果を保管します。
- 個々の区分サーバー上で ipcs を使用して、結果を保管します。
- db2_call_stack を使用して、結果を保管します。
上記のステップを実行し終えたら、以下のステップをすべて実行してください。
- db2stop -kill を使用して DB2 インスタンスを強制終了します。
DB2 UDB エンタープライズ拡張エディション (EEE) システムの場合、db2_kill を使用できます。
単一の区分サーバー環境の場合、db2kill を使用します。
- kill コマンドを使用して、
停止できない DB2 エージェントを終了します。
- kill コマンドを使用し、db2sysc プロセスを強制終了して DB2 を終了します。
- 最終手段として、システム全体をリブートします。
kill コマンドを使用しなければならない場合、DB2 プロセス間通信 (IPC) リソースはすべて削除されることを確認してください。 以下のいずれかになります。
- 問題が解決されない場合には、
以下の追加情報を収集してから、DB2 カスタマー・サポートと連絡をとります。
- DB2 のログ記録情報。
初期障害データ捕そく機能を参照してください。
- システムが中断している場合には、以下のようにします。
- DB2 トレースをセットアップし、ファイルにダンプ出力します。
ファイルを使用したトレースの例の指示に従ってください。
- UNIX ベースのシステムの場合、アプリケーション用のスタック・トレースバックを入手します。
スタック・トレースバックには、
中断に至るまでのプロセス ID ごとのシステム呼び出しに関する情報があります。
詳細については、UNIX ベースのシステムでのスタック・トレースバック情報の収集を参照してください。
- AIX の場合、db2sysc プロセスと、
インスタンスおよび区分サーバー上のすべての DB2 プロセスに対して kill -36 コマンドを発行します。
- HP-UX の場合、db2sysc プロセスと、
インスタンスおよび区分サーバー上のすべての DB2 プロセスに対して kill -29 を発行します。
- Solaris 操作環境の場合、db2sysc プロセスと、
インスタンスおよび区分サーバー上のすべての DB2 プロセスに対して kill -21 を発行します。
- DB2 ではなく、ベンダー提供のアプリケーションに問題があることが分かった場合は、
そのベンダーと連絡をとってください。
[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]