DB2 10.5 for Linux, UNIX, and Windows

トラブルシューティング技法

良い問題分析の最初のステップは、問題を完全に記述することです。問題記述なしでは、問題の原因を突き止めるためにどこから始めたらよいかが分かりません。

このステップでは、以下のような基本的な質問を自問自答します。

どのような症状か
問題が発生しているのはどこか
問題が発生するのはいつか
どのような条件で問題が発生するか
問題は再現可能か

これらの質問や他の質問に答えることは、ほとんどの問題に対する正しい記述に結びつき、問題解決し始めるための最良の方法です。

どのような症状か

問題を記述し始める際にまず考えられる質問は「何が問題か」というものです。これは平易な質問のように思えます。しかし、問題をより明確にするには、これをさらにいくつかの質問に分割することができます。以下のような質問です。

問題を報告しているのは誰または何か
エラー・コードおよびエラー・メッセージはどのようなものか
どのような障害が起きるか (ループ、ハング、停止、性能低下、結果の誤りなど)
ビジネスにどのような影響があるか

問題が発生しているのはどこか

問題の発生箇所の判別は必ずしも容易ではありませんが、問題の解決において最も重要なステップの 1 つです。報告を行うコンポーネントと障害が起きているコンポーネントとの間には、多くのテクノロジーの層が存在していることがあります。問題を突き止める際に考慮すべきコンポーネントをほんのいくつか挙げるだけでも、ネットワーク、ディスク、ドライバーなどがあります。

問題はプラットフォームに固有のものか、それとも複数のプラットフォームに共通のものか
現行の環境および構成はサポートされているか
アプリケーションはデータベース・サーバー上でローカルに実行しているか、それともリモート・サーバー上で実行しているか
ゲートウェイが関係しているか
データベースは個々のディスク上に保管されているか、それとも RAID ディスク・アレイに保管されているか

これらのタイプの質問は、問題の層を切り分けるのに役立つとともに、問題の発生源を判別するのに不可欠です。 1 つの層が問題を報告しているからといって、根本原因がそこに存在するとは限らないことに注意してください。

問題がどこで発生しているかを識別することには、問題が存在している環境を理解することが含まれます。必ずいくらかの時間を取って、問題の発生している環境を完全に記述する必要があります。それには、オペレーティング・システムとそのバージョン、該当するすべてのソフトウェアとバージョン、およびハードウェア情報が含まれます。実行環境が、サポートされている構成になっているかどうかを確認してください。というのは、一緒に実行するよう意図されていないソフトウェア・レベル、または一緒に十分にテストされていないソフトウェア・レベルを突き止めることで解明可能な問題は少なくないからです。

問題が発生するのはいつか

障害につながる詳細なイベントを時系列上に並べることは、問題分析における別の不可欠なステップです。一回限りの現象である場合には特にそうです。この作業の最も簡単な方法は、過去にさかのぼって行くことです。すなわち、エラーが報告された時刻 (ミリ秒単位にまで至る、可能な限り正確な時刻) を起点に、入手可能なログと情報を過去にさかのぼって作業を進めていきます。通常はいずれかの診断ログで最初に見つかる疑わしいイベントまで調べれば十分です。しかし、これは必ずしも容易に行えることではなく、経験を積む必要があります。特に、テクノロジーの層が複数あり、それぞれに独自の診断情報がある場合には、どこでやめるかを判断するのは困難です。

問題は、昼間または夜間の特定の時刻にのみ発生するか
どれほどの頻度で発生するか
問題の報告される時刻まで、どのような一連のイベントが生じているか
問題が発生するのは、既存のソフトウェアまたはハードウェアのアップグレードや、新規のソフトウェアまたはハードウェアのインストールといった環境の変更後か

このような質問に答えることにより、イベントを時系列に並べるのに役立ち、調査の基準枠を持つことができます。

どのような条件で問題が発生するか

問題の発生時に、他に何が実行されていたかを知ることは、完全な問題記述のために重要です。特定の環境または特定の条件下で問題が発生する場合、それが問題の原因のかぎとなる標識であることがあります。

同じタスクを実行すると、常にその問題が発生するか
問題が表面化するには、特定の順序でイベントが発生する必要があるか
同時に他のアプリケーションにも障害が起きるか ?

これらのタイプの質問に答えることにより、問題が発生する環境を解明し、依存関係を明らかにするのに役立ちます。複数の問題がほぼ同時に発生するというだけでは、必ずしもそれらが関連していることにはならないことを覚えておいてください。

問題は再現可能か

問題記述および調査の観点から見て「理想的」な問題とは、再現可能な問題です。再現可能な問題の場合はたいてい、調査の助けになるツールやプロシージャーのセットがより多く利用できます。その結果、再現可能な問題は、通常デバッグおよび解決をより容易にします。

しかし、再現可能な問題にも欠点があります。すなわち、ビジネス上の大きな影響を伴う問題の場合、これを繰り返し発生させるわけにはいきません。この場合、可能であれば、テストまたは開発環境で問題を再現するほうが望ましいでしょう。

テスト・マシン上で問題を再現できるか
複数のユーザーまたはアプリケーションが、同じタイプの問題に遭遇するか
単一のコマンド、一連のコマンド、または特定の既存アプリケーションや意図的に作成したテスト・アプリケーションのいずれかを実行して、問題を再現できるか
DB2® コマンド行プロセッサーで同等のコマンド/照会を実行して問題を再現できるか

多くの場合、テストまたは開発環境で単一の問題を再現するのが望ましいでしょう。通常、そのほうが、調査を行う際により一層の柔軟性と制御が得られるからです。