目次


DB2問題判別 習熟シリーズ

第1回 問題判別の概要

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: DB2問題判別 習熟シリーズ

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:DB2問題判別 習熟シリーズ

このシリーズの続きに乞うご期待。

セクション1 : この回について

目的

第1回では、DB2で発生した問題の記述および調査のための技術を身に付け、それらの問題を診断情報を使って切り分けられるようにすることを目的としています。問題を切り分けることができれば、既知の問題を検索して、対策や回避方法、修正の有無などを確認することができます。また、既知の問題を見つけることに慣れると、問題を事前に回避できます。ここでは、これらの目的を達成するために、よくあるタイプの問題をいくつか例に挙げながら説明していきます。

対象読者と前提事項

Linux、OS/2、Windows®、UNIX® (AIX、Solaris、HPなど)でDB2を使用しているすべてのユーザーを対象としています。これには、DB2 Personal Editionのユーザーから、複数のパーティションからなるDB2 EEEクラスターの管理者まで、あらゆるユーザーが含まれます。この回では、読者がオペレーティング・システムやそのツールの使い方に慣れていること、およびDB2の操作に関する実践的な知識を持っていることを前提としています。

『IBM Software Support Handbook』は、問題判別全般についての優れたリソースとなっており、問題判別のサポートとして利用できます。このハンドブックは、(http://techsupport.services.ibm.com/guides/handbook.html)にあり、このシリーズ全体にわたる参照資料となっています。

例で使われているコマンド・オプションは、その後に変更されている可能性があります。すべてのコマンドおよびそのオプションについては、DB2のマニュアルを参照してください。

開始前のセットアップ

DB2をインストールし、DB2インスタンスとデータベースを作成します。

表記規則

ツールやユーティリティーの名前は、初出時には太字で表記されています。すべてのコマンド文およびその出力は、モノスペース・フォントで表記されています。

著者について

Lloyd D. Buddは、IBMトロント研究所(カナダ、マーカム)のDB2サポート・アナリストであり、IBM認定ソリューション・エキスパート(DB2 UDB Version 5、6、および7のデータベース管理)です。最近では、レッドブック『The Practical Guide to DB2 Data Replication Version 8』を共同で執筆しています。専門分野は、ロギング、バックアップ、およびリカバリーです。

Chris Fenderは、DB2テクニカル・サポート・チームのテクニカル・マネージャーです。IBMに入社して5年になりますが、その5年の間、一貫してDB2カスタマー・サポート業務に携わっており、DB2エンジン・コンポーネント(主にデータベース・リカバリーとデータ保護)を専門としています。最近では、『DB2:The Complete Reference』のPD/PSIの章を執筆しています。IBMトロント研究所に勤務する彼は、オンタリオ州では広く認められたプロフェッショナル・エンジニアの1人です。

セクション2 : 問題の記述

概要

的確な問題分析は、まず問題を余すところなく記述することから始まります。問題の記述なくしては、問題の原因の調査をどこから始めてよいのかわかりません。問題を記述する際には、以下のような基本的な問いに答えていきます。

  • 問題は何ですか?
  • 問題が発生しているのはどこですか?
  • 問題が発生するのはいつですか?
  • 問題はどのような状況で発生しますか?
  • 問題は再現可能ですか?

上の問いやその他の問いに答えていくことによって、ほとんどの問題を的確に記述することができます。これは、問題解決への道の第1歩として最善の方法です。ここでは、こうした問いのサンプルをいくつか紹介します。また、よくあるタイプの問題の状況を例として示します。

問題は何ですか?

問題の記述を開始するにあたって最も明白な問いは、「問題は何ですか?」という問いです。この問いは、直接的に見えるかも知れませんが、複数の問いに分割することによって、問題をより明確に記述することができます。たとえば、次のような問いに分割できます。

  • 誰(何)が問題を報告していますか?
  • 症状は何ですか?
  • どのようなビジネス・インパクトがありますか?

こうした問いをいつどのように使えばよいのかを理解するには、例を見てみるのが一番でしょう。

アプリケーションがエラーになりました

ここで紹介する(「アプリケーションがエラーになりました」というぴったりのタイトルの)例は、ソフトウェア開発者やデータベース管理者なら誰もが一度は遭遇するごく一般的な状況です。通常このような状況では、ユーザーが部屋に飛び込んでくるか電話やポケベルを使うかして、上のせりふを大声でわめき散らします。

ユーザーが落ち着いたら、問題判別を開始します。ユーザーに対するまず最初の問いは、「問題の症状は何ですか?」という問いです。上の「アプリケーションがエラーになりました」という返答は、問題を報告している最初の層(アプリケーション)の質問に対する答えとなっているため、続いて「そのときアプリケーションは何をしていましたか?」という問いに移ることができます。この例では、このアプリケーションのロギングに関するコーディングには問題はないと仮定しているため、この問いに対する答えは、「アプリケーションは給与情報を処理していたところで、ログを見ると、SQL INSERTが複数回にわたって失敗し、戻り値としてSQLCODE SQL0289Nが返されています」というものになります。

ここまでの段階で、問題の大まかな概要と、発生した場所、および調査の開始点となるSQLCODEが得られました。さらに調査を進めるには、このメッセージの意味を調べる必要があります。

DB2の通知メッセージの解釈

報告されたSQLCODEから調査を始めることができます。DB2の通知メッセージは、常にCCCnnnnnSという形式になっています。CCCはメッセージを返したDB2コンポーネントを表し、nnnnnは4桁または5桁のエラー・コード、Sはエラーの重大度を表します。たとえば、この例のメッセージからは、メッセージを返したSQLコンポーネントがデータベース・マネージャーであることがわかります。メッセージ内の記号とコンポーネントの対応を以下に示します。

  • SQL データベース・マネージャーのメッセージ
  • DB2 コマンド行プロセッサーのメッセージ
  • ASN レプリケーションのメッセージ
  • CLI コール・レベル・インターフェースのメッセージ
  • SQJ Javaの組み込みSQLJのメッセージ
  • SPM 同期点マネージャーのメッセージ
  • DBI インストールまたは構成のメッセージ
  • DBA コントロール・センターおよびデータベース管理ユーティリティーのメッセージ
  • CCA クライアント構成アシスタントのメッセージ
  • DWC データウェアハウス・センターのメッセージ
  • FLG インフォメーション・カタログ・マネージャーのメッセージ
  • SAT サテライトのメッセージ

DB2の戻りコードのメッセージは、DB2のコマンド行を使って調べることができます。次のように、db2コマンドとエラー・コードを疑問符(?)で区切って入力します。

 D:\>db2 "? sql0289"
 SQL0289N Unable to allocate new pages in table space
       "< tablespace-name> ".

ほとんどのエラー・メッセージには、エラーの説明やユーザーが取れる対策など、上の例より多くの情報が含まれています(上の例では、スペースの都合で省略しています)。『DB2 UDB Messages Reference, Volumes 1 & 2』には、DB2メッセージの形式についての完全な情報と、すべてのメッセージの一覧が含まれています。メッセージ・テキストは、問題を調査するにあたってすぐに参照できる貴重な情報源です。問題を記述する際には、必ず確認するようにしてください。

これで、ユーザーが遭遇している状況は、表スペースが新しいページを割り当てることができないという状況らしいことがわかりました。この例の調査をさらに進めていけば、問題のその他の症状が明らかになるでしょう。ここで役に立つのが、「エラーが発生するアプリケーションはこれだけですか?」というような問いです。問題の記述を順調に始めることができましたが、まだ問題の全体像は見えてきていません。

環境はどのようになっていますか? 問題はどこで発生していますか?

問題が発生している箇所を特定するのは必ずしも容易なことではありませんが、問題を解決する上で最も重要なステップの1つとなります。エラーを報告しているコンポーネントとエラーが発生しているコンポーネントとの間には、何層ものテクノロジーが介在している場合がほとんどです。ネットワーク、ディスク、およびドライバーは、問題を調査するにあたって検討しなければならないコンポーネントのほんの一部にすぎません。

  • アプリケーションはデータベース・サーバー上でローカルで実行されていますか? それともリモート・サーバー上で実行されていますか?
  • 間にゲートウェイはありますか?
  • データベースは個別のディスクに置かれていますか? それともRAIDアレイに置かれていますか?

この種の問いは、問題の層を切り分けるのに役立ちます。問題の発生箇所を特定するためには、こうした問いに答えていく必要があります。問題を報告している層が1つだからと言って、そこに根本原因があるとは限らないという点に注意してください。

問題の発生箇所を特定する作業には、その環境を把握する作業が含まれます。必ずある程度の時間をかけて、オペレーティング・システム、そのバージョン、関連するすべてのソフトウェアとそのバージョン、およびハードウェアの情報も含め、問題の環境を完全に記述するようにしてください。また、一緒に実行できないソフトウェアや、一緒に実行できるかどうかを十分にテストされていないソフトウェアが問題の原因になっている場合も多いため、実行環境の構成がサポートされているかどうかを確認してください。

現在取り上げている例については、説明を簡潔にするために、エラーが発生しているアプリケーションは、サポートされている構成のサーバー上で直接実行されていることにします。したがって、ここではサーバー側の調査のみに集中できます。

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

問題の分析に必要な次のステップは、エラーが発生するまでのイベントの詳細なタイム・ラインを作成することです。エラーが1度しか発生しない場合には、このステップがとりわけ重要になります。この作業を行う最も簡単な方法は、エラーが報告された時点から始めて、利用可能なログや情報を時間を遡って調べていく方法です(ミリ秒に至るまで、できる限り厳密に行います)。通常は、なんらかの診断ログで、疑わしい最初のイベントが見つかった時点でこの作業は終わりになります。しかし、それを見極めるのは必ずしも簡単ではなく、ある程度の慣れが必要です。それぞれ個別の診断情報を持つ複数の層のテクノロジーが関与している場合には、どこで調査を終了すべきかの判断がとりわけ難しくなります。

  • 問題が発生するのは昼または夜の特定の時間だけですか?
  • 問題が報告された時間までのイベント・シーケンスはどのようになっていますか?
  • 問題が発生するのと同じ時刻に開始される自動スクリプトやcronジョブはありますか?

この種の問いに答えることによって、イベントの詳細なタイム・ラインを作成し、調査の枠組みを得ることができます。上の最後の問いは、次のトピックにもつながります。

この例では、問題が再現可能であることがユーザーから知らされているため、問題が発生した正確な時間を特定することは、問題が1度しか発生しない場合ほど重要ではありません。エラーに至るまでのステップがいくら決定的であっても同じことです。この場合は、スタンドアロンのアプリケーションを実行するだけで問題を再現できるので、イベントの詳細なタイム・ラインは必要ありません。

問題はどのような状況で発生しますか?

問題が発生するときにほかに何が実行されているのかを把握することは、問題を完全に記述する上で重要です。問題が特定の環境や特定の状況で発生している場合には、それが問題の原因を特定するための重要な手がかりになります。

  • 問題が発生するのは、ほかにも何か実行されているときだけですか?
  • 問題が表面化するのは、特定のイベント・シーケンスが発生した場合だけですか?
  • 他のアプリケーションでも同時にエラーが発生しますか?

この種の問いに答えることによって、問題が発生する環境を明らかにし、依存関係を把握できます。複数の問題が同時に発生したからと言って、それらの間に相関関係があるとは限らないという点に注意してください。

この例では、先にも述べたように、問題は単独で再現可能なため、問題原因の究明に役立つような外的条件や他のアプリケーションとの依存関係はないと考えられます。

問題は再現可能ですか?

問題の記述および調査の観点から言えば、「理想的な」問題とは再現可能な問題です。再現可能な問題では、ほとんどの場合、問題の調査に役立つツールや方法が豊富にあるため、デバッグや解決がより簡単になります(ただし、再現可能な問題の方が不利な点もあります。たとえば、問題が重大なビジネス・インパクトを持つ場合、何度も再現されては困ります。再現可能な問題は、場合によっては、直ちに解決しなければならない緊急の問題となります)。

  • 問題をテスト用コンピューターで再現できますか?
  • プラットフォームに固有の問題ですか? それとも複数のプラットフォームに共通の問題ですか?
  • 複数のユーザーやアプリケーションで同種の問題が発生していますか?
  • 1つのコマンド、一連のコマンド、または特定のアプリケーションを実行することによって問題を再現できますか?
  • DB2のコマンド行からコマンドやクエリーを入力すると問題が再現しますか? それともアプリケーションを使用するだけで問題が再現しますか?

多くの場合は、1度しか発生しない問題をテスト環境や開発環境で再現する方が望ましいと言えます。なぜなら、通常こうした環境では、問題を調査するにあたってより柔軟に環境を制御できるからです。

ここで取り上げている例は再現可能です。影響を受けているのは問題を報告してきたユーザーだけのようですが、このユーザーによれば、テスト環境では同じアプリケーションが問題なく動作したということなので、問題判別の作業は、問題が見つかった実稼動環境で行うしかありません。これはつまり、この問題が、すばやい解決を要する緊急の問題である可能性があるということになります。うかうかしてはいられません。

結論

正確かつ完全に記述するのが簡単な問題もあれば、非常に困難な問題もあります(一般に、環境が複雑になればなるほど問題の記述は困難になります)。しかし、必要な問いは常に同じで、だれが、何を、どこで、いつ、どのように、というものになります。『IBM Software Support Handbook』の「Before Contacting IBM」にあるProblem Resolution Worksheetは、こうした問いの優れたチェックリストとなっています。問題の把握に役立つでしょう。

このセクションで例として取り上げた問題の記述をまとめると、次のようになります。

  • アプリケーションは、SQL INSERTの際にSQL0289Nを報告しています。
  • アプリケーションでエラーが発生するのは、実稼動データベース・サーバーに対してローカルで実行されているときです。
  • このエラーは、単独で再現可能です。

ここでは、問題を記述するための技術を身に付けました。次のセクションでは、問題の調査と判別のための技術を学びます。また、DB2のほとんどの問題の分析に利用できる情報についても紹介します。

セクション3 : DB2のデータの収集

概要

DB2 (およびそれが実行されている環境)では、発生した問題の解決のための情報が提供されます。ここでは、どのような情報が提供されるのか、それをどこで見つけてどのように利用するのかを説明します。

DB2のファイル

DB2の問題を調査するにあたって利用できる最も重要な情報は、DB2自体が生成するファイルです。DB2が生成するファイルには、次のようなものがあります。

  • db2diag.logファイル
  • トラップ・ファイル
  • ダンプ・ファイル
  • メッセージ・ファイル

さまざまなイベントや問題が発生するたびに、これらのファイルが生成されたり更新されたりします。以降では、それぞれの種類のファイルを調べる方法、およびその情報を解釈する方法について説明します。

db2diag.logファイル

db2diag.logは、DB2の問題の調査に最もよく使用されるファイルです。このファイルは、データベース・マネージャー構成のDIAGPATH変数によって定義されるDB2診断ディレクトリーにあります(このセクションで紹介するDB2の診断ファイルの多くがこのディレクトリーに作成されます)。このディレクトリーは、デフォルトで次のように定義されています。

  • UNIX: $HOME/sqllib/db2dump
    • $HOMEは、DB2インスタンス所有者のホーム・ディレクトリーです。
    • たとえば、UNIXのfenderというインスタンス所有者の場合、db2diag.logのデフォルトの場所は/home/fender/sqllib/db2dump/db2diag.logになります。
  • WindowsまたはOS/2: INSTALL PATH\SQLLIB\<db2instance>
    • INSTALL PATHは、DB2がインストールされているディレクトリーです。
    • たとえば、WindowsのDB2というインスタンス所有者の場合、db2diag.logのデフォルトの場所はC:\Program Files\SQLLIB\DB2\db2diag.logになります。

データベース・マネージャー構成では、DIAGLEVEL変数で診断レベルを設定することによって、db2diag.logに記録される情報量を制御することもできます。設定できる値は0〜4です。それぞれの値の違いは以下のとおりです。

  • 0 - メッセージなし
  • 1 - 重大エラー・メッセージ
  • 2 - エラー・メッセージのみ
  • 3 - すべてのエラー・メッセージと警告メッセージ(デフォルト)
  • 4 - すべてのエラー・メッセージ、警告メッセージ、通知メッセージ、内部診断メッセージ

デフォルトの診断レベルは3で、問題判別には通常これで十分です。診断レベルを4に設定すると、大量のデータがファイルに記録されるため、パフォーマンスの問題を引き起こす可能性があります。この設定は、遭遇した問題の種類、問題の調査に必要なデータの量、および問題が発生した環境に応じて調整する必要があります。

db2diag.logの例

db2diag.logファイルには、通常の操作(ロード・ユーティリティーなど)の管理情報や、エラーおよび通常とは異なる操作(クラッシュ・リカバリーなど)の診断情報が含まれています。DB2 UDB Version 8では、管理者やサポート担当者がこれらのイベントを区別しやすいように、このファイルが2つの別のファイルに分割されています。以下は、Windowsプラットフォームでのコマンド・エラーの例と、それに対応する診断レベル3のdb2diag.logのエントリーです(この問題は、z:\を存在しないパスに置き換えることによって、お使いのコンピューターでも再現できます)。

D:\> db2 backup db sample to z: SQL2036N The path for the file or device "z:\" is not valid.

2002-10-28-19.12.54.825000   Instance:DB2   Node:000
PID:1124(db2syscs.exe)   TID:680   Appid:none
database_utilities  sqluMCTestDevType4Backup   Probe:60 

Media controller -- invalid device path: z:\

エラー・メッセージと、それに対応するdb2diag.logのエントリーの両方から、z:\というパスが存在しないことがはっきりわかります。これが、バックアップが失敗した原因です。診断レベル3でdb2diag.logに記録されるエントリーはこれだけではありませんが、ユーティリティー・コマンドの失敗によって生成されるメッセージの種類は上の例から十分わかります。

上のdb2diag.logのエントリーを分析すると、次のようになります。

  • メッセージが生成された時刻は2002-10-28-19.12.54.825000です。
  • インスタンス名はDB2です。
  • パーティション番号(ノード、EEの場合は0)は0です。
  • プロセス名はdb2sysc.exeです。
  • プロセスID (PID)は1124です。
  • スレッドID (TID)は680です。
  • アプリケーションID (Appid)はありません。
  • DB2内部コンポーネントIDはdatabase_utilitiesです。
  • DB2内部関数IDはsqluMCTestDevType4Backupです。
  • 報告された関数内で固有のエラーID (probe ID)は60です。

メッセージ・エントリーの最後の部分はメッセージになっており、多くの場合、エラー・コード、ページ・ダンプ、またはその他の詳しい情報が含まれています。この情報は複雑になる場合もありますが、通常はここから、エラーを引き起こした操作の種類に関する手がかりや、調査に役立つ情報を得ることができます。

トラップ・ファイル

DB2プロセスが、DB2シグナル・ハンドラーによって認識されるシグナルや例外(システム・イベントの結果としてオペレーティング・システムが発生させる)を受け取るたびに、DB2診断ディレクトリーにトラップ・ファイルが生成されます。ファイルは、以下の命名規則に従って作成されます。

  • UNIX: tpppppp.nnn
    • pppppp: プロセスID (PID)
    • nnn: トラップが発生したノード
    • 例: t123456.000
  • Intel: DBpppttt.TRP
    • ppp: プロセスID (PID)
    • ttt: スレッドID (TID)
    • 例: DB123654.TRP

受け取ったシグナルや発生した例外によって、これらのファイルの存在が示す結果は、さらなる診断のための単純なスタック・トレースバックが生成されたというようなものから、内部または外部の重大な問題によってDB2インスタンスが完全にシャットダウンしたというものまで、多岐にわたります。お使いのオペレーティング・システムで利用できるシグナルのリストは、以下のファイルから入手できます。

  • UNIX: /usr/include/sys/signal.h
  • Windows (ソフトウェア開発キットが必要): Winnt.h
  • OS/2 (ソフトウェア開発キットが必要): bsexcpt.h

トラップ・ファイルの調査に関する詳細や、問題の診断のためにトラップ・ファイルを生成する方法については、別の回で紹介します。

ダンプ・ファイル

DB2は、内部情報を収集する必要があると判断すると、多くの場合、(この回で既に説明したように)診断ディレクトリーにダンプ・ファイルを作成します。ダンプ・ファイルには2つの種類があり、それぞれ次の形式で生成されます。

タイプ1: バイナリー・ダンプ・ファイル

  • UNIX: pppppp.nnn
    • pppppp: プロセスID (PID)
    • nnn: 問題が発生したノード
    • 例: 123456.000
  • WindowsおよびOS/2: pppttt.nnn
    • ppp: プロセスID (PID)
    • ttt: スレッドID (TID)
    • nnn: 問題が発生したノード
    • 例: 123654.000

タイプ2: ロックリスト・ダンプ・ファイル

  • UNIX: lpppppp.nnn
    • pppppp: プロセスID (PID)
    • nnn: 問題が発生したノード
    • 例: l123456.000
  • WindowsおよびOS/2: lpppttt.nnn
    • ppp: プロセスID (PID)
    • ttt: スレッドID (TID)
    • nnn: 問題が発生したノード
    • 例: l123654.000

メッセージ・ファイル

BIND、LOAD、EXPORT、IMPORTなどの一部のDB2ユーティリティーには、ユーザーが定義した場所にメッセージ・ファイルを生成するオプションが用意されています。生成されたファイルには、実行されたユーティリティーの進捗、成功、失敗を報告する有益な情報が含まれています。問題が発生した場合に、最も可能性の高い情報を取得できるように、これらのファイルの生成機能を活用するようにしてください。

db2support

DB2の問題に関する情報を収集するにあたって実行する必要がある最も重要なDB2ユーティリティーは、db2supportです。

db2supportユーティリティーは、DB2とシステムの利用可能なすべての診断情報(これまでに説明した情報も含む)を自動的に収集するように作られています。問題の調査でさらなる支援が必要な場合は、オプションの対話形式の"Question and Answer"セッションを利用して情報を収集することもできます。db2supportを利用すると、「GET DATABASE CONFIGURATION FOR <database name>」や「LIST TABLESPACES SHOW DETAIL」などのコマンドを入力する必要がなくなるため、人的なエラーが入り込む余地がなくなります。また、実行するコマンドや収集するファイルに関する指示も必要ないため、問題判別のための情報収集をよりすばやく行うことができます。

このコマンドは、Linux、OS/2、Windows、およびUNIXのDB2製品にVersion7 Fixpak 4以降含まれるようになり、その後も強化され続けています。たとえば、Version 7 FixPak 7では、それまで1つの巨大なHTMLファイルに対して出力されていたのが、デフォルトで複数のテキスト・ファイルに分割して出力されるようになりました。これにより、ファイルを読んだり解析したりしやすくなりました。db2support-hを実行すると、このユーティリティーで利用できるすべてのオプションのリストが表示されます。通常は、以下に示す基本的な呼び出しによって、問題のデバッグに必要なほとんどの情報を収集できます(-cオプションを使用すると、データベースへの接続が確立されます)。

 db2support <output path> -d <database name> -c

さらなる情報が必要な場合は、どのオプションが役に立つかを調べる必要があります。収集された結果は圧縮ZIPアーカイブ(db2support.zip)に格納されるため、あらゆるシステムで簡単に転送したり解凍したりできます。

結論

ここでは、DB2の問題を分析するための診断情報を取得する方法を紹介しました。ほとんどの場合は、これらのファイルを調べれば、DB2の問題の根本原因を特定できます。しかし、調査が完了するまでにより多くの情報が必要になる場合もあります。次のセクションでは、システムで問題を解決する際に利用できるDB2の外部の情報を簡単に紹介します。

セクション4 : その他のデータの収集

概要

問題の分析に役立つファイルやユーティリティーは、DB2の外部にもたくさんあります。こうした外部のファイルやユーティリティーが、問題の根本原因を特定する上でDB2のファイルと同じくらい重要になることもよくあります。こうした情報の一部は、以下の領域のログやトレースに含まれています。

  • オペレーティング・システム
  • アプリケーションおよびサードパーティー・ベンダー
  • ハードウェア

稼動環境によっては、ここで紹介する以外の場所でも情報を得られる場合もあります。したがって、システムで問題をデバッグする際には、調査の対象を見逃さないように、あらゆる領域に目を配る必要があります。

オペレーティング・システム

すべてのオペレーティング・システムには、アクティビティーやエラーが記録されている一連の診断ファイルがあります。中でも最も一般的(また通常最も便利)なのは、エラー報告書やイベント・ログです。この情報は、以下のような方法で収集できます。

  • AIX: /usr/bin/errpt -aコマンド
  • Solaris: /var/adm/messages*ファイルまたは/usr/bin/dmesgコマンド
  • Linux: /var/log/messages*ファイル
  • HP-UX: /var/adm/syslog/syslog.log*ファイルまたは/usr/bin/dmesgコマンド
  • Windows NT®/Windows 2000®: システム、セキュリティー、アプリケーションのイベント・ログ・ファイルおよびwindir\drwtsn32.logファイル(windirはWindowsのインストール・ディレクトリー)
  • OS/2: INSTALL_DRIVE\OS2\SYSTEM\RAS\LOG*.DATファイル(INSTALL_DRIVEはOS/2のインストール・ディレクトリー)

各オペレーティング・システムには、このほかにもトレース・ユーティリティーやデバッグ・ユーティリティーがあります。お使いのオペレーティング・システムのマニュアルやサポート資料で、ほかにどのような情報を利用できるのかを調べてみてください。また、このシリーズの別の回である「DB2の診断とOSの診断の組み合わせ」でも、このトピックについて詳しく扱っています。

アプリケーションおよびサードパーティー・ベンダー

セクション2で説明したように、各アプリケーションには、それぞれ専用のログ・ファイルや診断ファイルがあるはずです。DB2の一連の情報をこれらのファイルの情報で補足することによって、問題の可能性がある領域をより正確に把握することができます。

ハードウェア

ハードウェア・デバイスは通常、オペレーティング・システムのエラー・ログに情報を記録します。しかし、それ以外の追加情報が必要になる場合もあります。そのような場合は、現在の環境の各ハードウェアで、どのようなハードウェア診断ファイルやハードウェア診断ユーティリティーを利用できるのかを調べる必要があります。たとえば、不正なページやなんらかの種類の破損がDB2によって報告された場合などが、このような状況にあたります。このような場合は、一般にディスクに問題があると考えられるため、ハードウェアの診断が必要になります。お使いのハードウェアのマニュアルやサポート資料で、どのような情報を利用できるのかを調べてみてください。

結論

問題の完全な理解および評価のためには、DB2、アプリケーション、オペレーティング・システム、および背後のハードウェアから、利用可能な情報をすべて収集しなければならない場合もあります。db2supportを使えば、DB2やオペレーティング・システムのほとんどの必要な情報を自動的に収集できますが、それ以外にも問題の調査に役立つ情報があるということを意識しておく必要があります。

セクション5 : 問題の調査

概要

DB2で発生するほとんどすべての問題は、以下の5つの問題タイプのいずれかに分類できます。

  1. システムの問題
  2. インスタンスの問題
  3. データベースの問題
  4. ユーティリティーの問題
  5. トランザクションの問題

どのタイプの問題に遭遇したのかを特定できれば、問題のデバッグに必要な情報や、その調査をどのように開始すればよいのかをすばやく把握できます。

システムの問題

発生した問題が「きわめて大規模」に見える場合、たいていはシステムの問題が発生しています。たとえば、DB2サーバー・コンピューターにTelnetでログインしようとすると必ずエラーになる場合や、ディレクトリーの一覧を取得する単純なコマンドを入力するたびにコンピューターが停止する場合、一般的なファイル移動コマンドを実行するたびにコンピューター・システムがダンプを出力する場合などには、システム全体の問題が発生していると考えられます。このような問題は実際に発生します。そして実際に発生した場合、DB2の調査という観点からは、ほとんど何もできることはありません。このようなタイプの問題が発生した場合は、オペレーティング・システムの管理者が問題の診断にあたる必要があります。この場合DB2は(そのコンピューター上の他のソフトウェアと同様に)、より大きな問題の被害者になっていると考えられます。

インスタンスの問題

インスタンスが既にアクティブになっているはずなのに、データベース・マネージャーを起動する必要があるという内容のメッセージが表示される場合は、インスタンスの問題が発生している可能性があります。この問題が発生する場合は、一般に、DB2プロセスがオペレーティング・システムから受け取ったシグナルが原因となっています。シグナルを受け取った結果呼び出されたシグナル・ハンドラーが、インスタンスをダウンさせています。このようなシグナルは、たとえば次のような場合に発生します。

  • DB2のスタックが他のソフトウェアによって上書きされた場合
  • 許可ユーザーがDB2プロセスに対して手動でkillシグナルを送った場合
  • DB2自体が原因となっている場合(ソフトウェア障害の可能性)

こうしたインスタンスの問題が発生する場合は、ほぼ必ず、db2diag.logに重要な情報が記録されます。また、トラップ・ファイルやダンプ・ファイルが生成される場合もあります。データベース・マネージャーをオンラインに戻したらすぐに、まずこれらのファイルを確認することから問題原因の特定を開始します。

このシリーズの別の回である「DB2の問題判別ツール」では、この問題について、通常スタック・トレースバックの一番上の関数が原因となって発生するということを、サンプル・トラップ・ファイルを使って説明しています。DB2に関する限り、トレースバックの一番上の関数は、DB2の既知の問題のリストで問題を調べる際に非常に有効な検索用語となります。たとえば、この回のセクション3のsqluMCTestDevType4Backupは、有効な検索用語となります。既知の問題の調査については、この回の後のセクションで詳しく説明します。

データベースの問題

同じデータベースを使用しているほとんどのユーザーが共通の問題を経験している場合、その問題はデータベース自体の問題である可能性があります。データベース自体の問題には、パフォーマンスの問題から、データ・ページの破損によってデータベースにアクセスできなくなるような問題まで、さまざまな問題があります。報告された問題の性質によって、問題の判別に使用する技術も変わってきます。

データベースのパフォーマンスの問題のデバッグについては、このシリーズの別の回「パフォーマンスの問題判別」を参照してください。

データベースの可用性の問題をデバッグする場合は、db2diag.logファイルと、関連するシステム情報(この回のセクション4を参照)に集中します。通常は、これらの情報を組み合わせることによって、データベース・レベルのクラッシュの問題のほとんどを解決できます(注: このようなエラーが発生したときにトラップ・ファイルやダンプ・ファイルが作成される場合もよくありますが、一般にそれらの情報は、DB2サービスのアナリストに対して、エラー発生時のDB2内部の動作の詳細情報を提供するためのものです。ユーザーが行う一般的な調査にとっては、db2diag.logファイルほど有効なものではありません)。

ユーティリティーの問題

この回のセクション3で使った例は、ユーティリティーの問題のよい例になっています。この例は、無効なターゲット・パスが指定されたためにDB2のバックアップ・コマンドが失敗した、というものでした。一般に、この種の問題をデバッグする際には、db2diag.logファイルを調べるのが最も有効です。

さらに、この回のセクション3でも説明したように、DB2のユーティリティーには、独自のメッセージ・ログを作成するためのオプションが用意されています(DB2バックアップ・コマンドでは利用できません)。一般にこれらのファイルは、その操作のみに関連する重要な情報を提供してくれるため、問題を調査する上でdb2diag.logと同じくらい重要です。

一般に、ユーティリティーの問題の調査を開始する際には、db2diag.logファイルとユーティリティー・メッセージ・ファイルを組み合わせて使用するのが最善の方法になります。ユーティリティーがリモート・クライアントから実行されている場合には、接続の問題も考慮に入れなければならないという点に注意してください。その場合は、問題の接続についての側面をデバッグする方法について、別の回である「接続の問題判別」を参照してください。複数のパーティションがある環境では、ユーティリティーがローカルで実行されている場合でも通信の問題が絡んでくる可能性があります。

トランザクションの問題

DB2のトランザクションの問題は、DB2内で実行するあらゆるSQLコマンドで発生する可能性があります。これには、SELECT文、INSERT文、UPDATE文、DELETE文などの一般的なコマンドだけでなく、『DB2 SQL Reference』にリストアップされているあらゆるコマンドが含まれます。通常SQLの問題は、パフォーマンスの問題またはコマンド・エラーに分類されます。

SQLのパフォーマンスの問題のデバッグについては、このシリーズの別の回である「パフォーマンスの問題判別」を参照してください。

一般に、SQLエラーのデバッグにあたっては、返されたメッセージの情報を調べることが、問題とその原因を特定し、解決策を見極める上で最も有効な方法になります。この回のセクション2では、こうしたメッセージが問題判別のための強力なツールとなる例を紹介しました。

結論

これまで見てきたように、DB2の使用中に発生する問題を診断するにあたっては、それぞれの問題に応じた異なるアプローチが必要になります。遭遇した問題を正確に記述し、このセクションで説明した一般的な問題タイプのいずれかに分類し、そのタイプの問題に関連するすべての情報を収集したら、問題判別のあらゆる技術を駆使して問題の解決にあたる必要があります。

この回では説明しませんでしたが、実行時の再現可能な問題をデバッグする際には、DB2のトレース機能(db2trc)を使用するとよいでしょう。DB2のトレース機能については、このシリーズの別の回で説明します。

こうしたさまざまなタイプの問題を、それぞれ難なくデバッグできるようになるためには、実践を重ね、経験を積んでいく以外にありません。既知の問題を自分で生成して、学んだ技術を試してみるのもよいでしょう。データベースをバックアップしようとしているときや深夜に実行しているときに問題に直面するより、制御された環境で落ち着いて問題のデバッグに取り組む方が安心です。

これまでの段階で、問題の記述とデータの収集の技術を身に付けました。次のセクションでは、既知の問題や関連する問題を効果的に検索する方法について学びます。

セクション6 : 関連する問題や修正済みの問題の調査

概要

問題の要素をよく把握できるようになったので、同様の問題を調べて、問題を回避する方法や修正する方法を学ぶことができます。このセクションでは、まず最初に、マニュアルと検索について説明します。このセクションの大半は、DB2の障害(APAR)がどのように外部に公表されているかについての説明に割かれています。セクションの終わりでは、DB2の問題を調査するための追加リソースを紹介します。

DB2 Technical Supportサイト

DB2で問題が発生した場合にまず最初に見るべきなのはマニュアルです。リリース・ノートは特に重要です。Linux、OS/2、Windows、およびUNIXのDB2 Technical Supportサイトには、マニュアルの最新のコピーが用意されています。このWebサイトは、http://www.ibm.com/software/data/db2/udb/winos2unix/supportにあります。

関連する問題を検索する際にも、まずここから始めるとよいでしょう。

2つ目の例

ここでは、セクション2で紹介した「アプリケーションがエラーになりました」という問題の、別の例を紹介します。この例を使って、これまでに学んだ問題の記述や調査の技術を練習しつつ、既知の問題を調べる方法について見ていきます。

ユーザーによる説明: DB2がクラッシュします

アプリケーションでDB2にアクセスしようとすると、DB2がクラッシュします。問題が起きたのは勤務時間も間もなく終わりという頃で、その時間にこのデータベースを使っていたのはほんの数人のはずです。そのとき私が実行していたジョブは、昼間実行したのと同じジョブです。今日中に終わらせなければならない仕事なのです。環境の安定性についても、とても心配です。

ユーザーと協力し、診断データを調べることによって、以下のような問題の記述ができあがりました。

  • 環境はAIX 4.3.3 / DB2 EE v7.2 fixpak 6です。
  • このインスタンスは、zSeriesホストへのゲートウェイとして使用されています。
  • 通信にはSNAが使用されています。
  • DB2インスタンスがクラッシュしています。
  • このクラッシュは、特定のユーティリティーやスケジュールされているジョブに関連するものではなさそうです。
  • ほとんど誰もゲートウェイを使用していないときにだけ問題が発生しています。
  • この新しい問題は再現不可能ですが、複数回にわたって発生しています。
  • ハードウェアやソフトウェアの構成は何か月も変更されていません。
  • ホスト側にエラー・メッセージは出ていません。
  • AIXのerrptでは、「software program abnormally terminated」というメッセージがたくさん表示されます。プログラム名はDB2 executableになっています。
  • db2dumpディレクトリーを見ると、かなりの数のtnnnnn.000ファイル(トラップ・ファイル)がありました。これらのファイルを開いてみたところ、プレーン・テキストのスタック・トレースバックであることがわかりました。これらのファイルは、1つを除いてすべてがシグナル6 (SIGABRT)のファイルでした。これは、DB2がシャットダウンするときに自動的に生成されるものです。それ以外のもう1つのトラップ・ファイルでは、ファイルの先頭に、エラーが最後に発生したときに近い日付と時間が記録されていました。このファイルは、シグナル4 (SIGILL)でした。ファイルの中程にはスタックが記録されており、その最初の行(スタックの一番上)は次のようになっていました。
offset      178 in function
sqlccgetattr__FP15sqlcc_comhandleP10sqlcc_attrP10sqlcc_cond

悪い影響が出ているとは言え、大量の処理を抱えている時間には発生していないため、ビジネス・インパクトは重大なものではありません。

関連する問題の検索

DB2 Technical Support Webサイトにアクセスして、シナリオに従って作業します。

有効な検索用語には、多くの場合、以下の要素が含まれます。

  • 実行したコマンドを表す語
  • 症状を表す語
  • 診断から得られたトークン

トラップ・ファイルについては、セクション5で説明しました。トラップとスタック・トレースバックについては、このシリーズの別の回でさらに詳しく説明します。前のページのUNIXのトレースバックは、トラップしている関数がsqlccgetattrであることを示しています。DB2のマニュアルを調べてみても何もわかりませんでした。DB2 APARを検索すると、以下の図のような結果が得られます。

リンクをクリックしてどのようなドキュメントが含まれているのかを見る前に、まずAPARとは何かを説明します。

APARとは

IBMでは、お客様によって発見された障害をAPAR (Authorized Program Analysis Reports:プログラム診断依頼書)で解決しています。APARという略語が広く普及しているため、「プログラム診断依頼書」という呼び方をされることはほとんどありません。APARは、IBMの障害を外部化したものにすぎません。APARには、それぞれ固有のIDがあります。次のページのIY16397とIY09706は、いずれもDB2 APARのIDです。DB2 APARは、常に特定のバージョンのみを対象としていますが、複数のプラットフォームで実行されるDB2ファミリーの複数の製品に影響する場合もあります。

APARの検索結果の選択

APARとは何かがわかったところで、[APAR Library]をクリックして結果を見てみます(以下の図を参照)。

APAR search results
APAR search results

2つのAPARが表示されました。いずれかのAPAR IDをクリックすると、そのAPARが表示されます。では、この2つのAPARは何が違うのでしょうか。

言葉遣いの若干の違いに気付いた方は正解です。さらに重要な点として、リンクを辿ってみるとわかりますが、この2つのAPARは、対象となるDB2のバージョンも異なります。DB2 APAR IY16397がバージョン7を対象としているのに対し、IY09706の対象はバージョン6です。

該当する問題が記述されているAPARを見つけたのに、対象としているバージョンが違っていた場合は、そのAPARの用語を使って検索すると、正しいバージョンのAPARが見つかる場合があります。たとえば、バージョン7で問題が発生した場合に、上のIY09706しか見つからなかったときなどがこれに該当します。

これで、sqlccgetattrのトラップの解決策がわかりました。FixPak 7以降のFixPakをDB2サーバーにインストールすれば、この問題を解決できます。

以降では、APARのその他の側面について説明します。

DB2 Technical SupportサイトでのAPARへのアクセス

DB2 Technical Supportサイトの各ページの左端には、ナビゲーション・メニューが用意されています。このメニューで[APARs]をクリックすると、以下の操作を行うことができるページに移動できます。

  • 検索文字列に一致するすべてのAPARを検索する
  • HIPER APARを表示する
  • オープンなAPARを表示する
  • APARをFixPak別に表示する

最初のDB2 APAR検索オプションは、先ほど実行した検索と同じです。それぞれのビューでは、APARが逆日付順に並べられており、最も新しいAPARが最初に表示されます。

APARの例

検索文字列として「IY16397」と入力し、[Search]をクリックします。その後、このAPARのテキストが表示されるまで、ページをクリックしながら移動していきます。

DB2 APAR IY16397はまた別のバックアップの問題を対象としていますが、ここで問題となっていたのはDB2の不適切な動作です。この問題は、その性質上、前のAPARより詳細な説明を必要とします。以下はこのAPARのテキストです。

Abstract:
SQL2025N RC=-50 ON A DB2 BACKUP TO ADSM AFTER A NODE IS ADDED
THAT DOES NOT CONTAIN DATA (EG. TEMP TABLESPACE) 
Status:
CLOSED - 2001-05-12 

APAR First Reported In:
DB2 UDB Enterprise Extended Edition for AIX v710
Note: APARs are not necessarily limited to one specific product.

APAR Description:

ERROR DESCRIPTION: 
On backup of a node that was added in v5 and migrated to v7 FP2,
it failed with an SQL2025N rc=-50 from ADSM. 
LOCAL FIX: 
Add data on the empty node. 
PROBLEM SUMMARY: 
The estimate size we send to TSM is 0, so the dsmSendObj TSM 
api was not flushing its buffer, and we would fail on the 
dsmSendData because the dsmSendObj did not get processed. We 
need to give an estimate size larger than the TCP buffer size 
to ensure the dsmSendObj gets flushed. 

TEMPORARY FIX: 

First Fixed In: 
DB2 V7 FixPak 3

Note: With the exception of Fixpak 2a for V7, a letter appended to 
the FixPak number indicates that it is an Interim FixPak. Interim 
FixPaks are temporary solutions. The official DB2 FixPak must be 
applied when it is available. 

Latest DB2 FixPak containing a fix for this APAR:
DB2 V7 FixPak 7

APARの各パートを見ていきます。abstractは、問題の要約です。error descriptionは、確認された症状の詳しい記述です。問題の複雑さによっては、この情報によって、発生した問題がここに記述されている問題かどうかを確認できます。local fixとtemporary fixには、問題を回避する方法や修正の手順が説明されています。これらは、ない場合もあります。problem summaryでは、問題の原因についてやや詳しい説明がなされています。

このAPARの場合、temporary fixはありません。この問題は既にFixPakで修正されているのでしょうか?

オープンなAPARとクローズになったAPAR

APAR IY16397には、以下のような記述があります。

 DB2 UDB Enterprise Extended Edition for AIX v710
 Note: APARs are not necessarily limited to one    
 specific product.

ここで注目すべき情報は、DB2のバージョン番号です。このAPARは、バージョン7のDB2を対象としています。

ステータスは次のようになっています。

CLOSED - 2001-05-12

ステータスがクローズ(CLOSED)ということは、このAPARが公式のFixPakに含まれていること、および最初に含まれたFixPakでその解決が確認されていることを意味します。この記録を読み進めると、最初に修正されたのがいつなのかも書いてあります。

 First Fixed In:     
 DB2 V7 FixPak 3

さらに、最新のFixPakについての記述もあります。

 Latest DB2 FixPak containing a fix for this APAR:
 DB2 V7 FixPak 7

ステータスがオープンの場合、そのAPARはまだFixPakに含まれていません。オープンのDB2 APARは、いったん文書化されると、すべてDB2 Technical Supportサイトでアクセスできます。

通常のAPARとHIPER APAR

DB2 Technical Support APAR Webページの2つ目のオプションは、HIPER (High-Impact or PERvasive) APARを表示するオプションです。『IBM Software Support Handbook』では、HIPER APARについて次のように説明されています。

  • お客様のデータの消滅や汚染を引き起こす問題
  • お客様が1つ以上のシステムまたはサブシステムを再IPL、リブート、リサイクル、または再起動しなければならなくなるような問題
  • 機能の大部分が損なわれるような問題
  • システムのパフォーマンスやスループットに深刻な影響を与える問題

IBMのDB2サポート・チームでは、さらに、広くまん延している問題もこのリストに含めています。なぜなら、こうした問題は、多くのお客様が遭遇している重要な問題であるからです。DB2 Technical Support Webページにも書かれているとおり、「HIPER APARとは、DB2のすべてのお客様が知っておくべき重大なバグです」。APARはすべて、できるだけ早く外部化されますが、HIPER APARの外部化は緊急に(多くの場合は回避策が見つかったその日のうちに)行われます。

HIPER APARの記録の形式は、他のすべてのAPARと同じです。そのAPARがHIPER APARかどうかは、Technical Support WebサイトのHIPER APARリストで確認できます。

HIPER APARへの対処

実行しているDB2のバージョンおよびFixPakで解決されていないHIPER APARについて、それぞれよく調べておく必要があります。これにより、そのFixPakのレベルで使い続けることにどのようなリスクが伴うのかを評価できます。このほか、HIPER APARほど重大ではないオープンなAPARの要約を読むことも、リスクの評価に役立ちます。

オープンなAPAR

オープンなAPARとは、まだFixPakに含まれていないAPARです。DB2 Technical Support APAR Webページの3つ目のオプションは、オープンなAPARを表示するオプションです。

ここには、オープンなHIPER APARも表示されます。ただし、それらがHIPER APARかどうかは、HIPER APARのページでないと確認できません。

オープンなAPARは、たいてい、それがオープンになったバージョンの次のFixPakで解決されます。ただし、これには2つの例外があります。1つは、APARが確認されたのが、FixPakの開発/テスト・サイクルに含めるには遅すぎた場合、もう1つは、APARが将来のリリースで修正されるためにクローズになる場合(FINとしてクローズされる場合)です。以下は、FIN APARの説明です。

障害の影響が比較的小さく、永続的な修正が即座に必要とはされないと判断された場合、IBMは、その修正を将来のリリースまで延期することがあります。このように修正が延期されたAPARには、将来のリリースに含まれる予定であることを示す"FIN" (Fixed If there is a Next release)というクローズ・コードが付けられます。

IBM Software Support Handbook

FixPak別のAPAR

DB2 Technical Support APAR Webページの最後のオプションは、APARをFixPak別に表示するオプションです。DB2の修正は、FixPakによって届けられます。1つのFixPakには、多数のAPARが含まれています。他の製品では、サービス・パックや更新などの用語が使用されています。DB2では、サポート対象のバージョンに対して、およそ3か月おきにFixPakがリリースされています。

FixPakには、以前のFixPakのAPARが含まれていますが、DB2のポイント・リリースの間をスキップすることはできません。たとえば、version 7.1 FixPak 2レベルのDB2を実行している場合に、version 7.2 FixPak 7レベルに移行するには、先にFixPak 3 (version 7.2と同等)をインストールする必要があります。この種の中間ステップについては、FixPakのREADMEを参照してください。

FTP FixPakダウンロード・ディレクトリーに含まれているAPARリスト(プレーン・テキストとhtml)を利用することもできます。以下は、APARリストを取得する方法を示す例です。入力されているパスからもわかるように、ここで取得しているのは、AIX 4.3.3 32ビットDB2 version7 FixPak 7のAPARリストとサポート資料です。

C:\>ftp ftp.software.ibm.com
User (none): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: ldbudd@ca.ibm.com
ftp> cd /ps/products/db2/fixes/english-us/db2aixv7/FP7_U484480/
ftp> dir
total 559832
-rw-rw-r-- 1 4975300 1    159293 Sep  7 21:14 APARLIST.TXT
-rw-rw-r-- 1 4975300 1    573489 Sep  7 21:14 APARLIST.html
-rw-rw-r-- 1 4975300 1 285769770 Sep  7 21:06 FP7_U484480.tar.Z
-rw-rw-r-- 1 4975300 1     22540 Sep  7 21:01 FixpakReadme.txt
lrwxrwxrwx 1 4975300 1        65 Jun 19 16:55 Release.Notes 
ftp> mget APARLIST.html

APARリストでは、最新のAPARが一番上に表示されます。また、最初に含まれたFixPak別にAPARがグループ分けされています。以下は、架空のAPARリストです(実際のリストはもっと長くなります)。

************************************************************
 Product Name : DB2 UDB V7 32-bit for AIX
 PTF Number   : U111111
 Package Date : Fri Sep  6 12:34:43 EDT 2002
 Build Level  : s020616
************************************************************

APAR fixes included in U111111 (Fixpak 2)

APAR No.  Abstract
--------  --------------------------------------------------
GG04246   DATA LOSS WITH DATAPROPAGATOR APPLY WHEN THE
          SET HAS A LARGE
          NUMBER OF MEMBERS AND THE SOURCE IS A CCD.
GG04250   APPLY DOES NOT TERMINATE WHEN COPYONCE IS
          SPECIFIED AND
          THE SET FAILS WITH A -1.
GG04251   APPLY COULD MISS THE HINT AND RESULT IN
          MISSING ROWS IF
          CAPTURE ENCOUNTERS -911

APAR fixes included in U481406 (Fixpak 1)

APAR No.  Abstract
--------  --------------------------------------------------
GG04218   FULL REFRESH APPLY TROUBLE WHEN HANDLING MANY COLUMNS
GG04238   ASNLOAD SHOULD NOT ISSUE RUNSTAT
IC32474   CANNOT CREATE MAPPING FOR SYBASE TEXT DATA TYPE

APARLIST.TXTとAPARLIST.htmlの違いは、HTMLの方では、APARのIDをクリックすると、そのAPARが記述されているページに移動できるという点だけです。

以上で、APARについての説明を終わりにします。

ニュースグループ

APARと利用可能なリソースについて理解したら、これまでのセクションで学んだことを活かしてあらゆる問題を解決できます。

ここでは、覚えておくべきリソースをもう1つ紹介します。それは、他のDB2エキスパートです。

comp.databases.ibm-db2などのニュースグループにアクセスすると、膨大な数のトピックについて、他のユーザーの知識を借りたり、問題や解決法を参照したりすることができます。DB2には、ニュースグループを通じて活発に交流しているオンライン・コミュニティーがあります。

このほか、NNTPサーバーnews.software.ibm.comには、IBMが運営しているDB2ニュースグループもあります。かなりの数のニュースグループがありますが、中でも最もよく利用されているのはibm.software.db2.udbです。

ユーザー指向のWebサイトはほかにも数多くありますが、最も豊富なコンテンツを誇るのは、今後もUSENETニュースグループであり続けるでしょう。

DB2の最近のマニュアル

DB2 Magazineの記事

結論

ここでは、関連する問題の検索にまつわる、以下のような多くの概念について学びました。

  • DB2 Technical Support Webサイトの場所
  • DB2 Technical Supportサイトのほとんどのコンテンツ
  • APARの概要
  • APARの特性
  • APARのステータスの意味
  • DB2 Technical SupportサイトでのAPARの検索
  • ニュースグループの検索

セクション7 : サマリー

この回で学んだこと

ここでは、DB2の問題を特定および診断する方法、診断ツールや診断ファイルの基本、問題の一般的な種類、および他のユーザーが遭遇した類似の問題を見つける方法について学びました。

こうしたスキルは、技術者としてのスキルと同じくらい重要であるといえます。ここで学んだことは、これからDB2の問題解決のスキルに磨きをかけていくための基礎となります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=322420
ArticleTitle=DB2問題判別 習熟シリーズ: 第1回 問題判別の概要
publish-date=10042005