Comments
Description
Transcript
第 1 回 問題判別の概要 DB2 問題判別 習熟シリーズ
DB2 問題判別 習熟シリーズ 第 1 回 問題判別の概要 第1回 問題判別の概要 - インデックス ・セクション1: この回について ・セクション2: 問題の記述 ・セクション3: DB2のデータの収集 ・セクション4: その他のデータの収集 ・セクション5: 問題の調査 ・セクション6: 関連する問題や修正済みの問題の調査 ・セクション7: サマリー セクション1: この回について 目的 第1回では、DB2で発生した問題の記述および調査のための技術を身に付け、それらの問 題を診断情報を使って切り分けられるようにすることを目的としています。問題を切り分 けることができれば、既知の問題を検索して、対策や回避方法、修正の有無などを確認す ることができます。また、既知の問題を見つけることに慣れると、問題を事前に回避でき ます。ここでは、これらの目的を達成するために、よくあるタイプの問題をいくつか例に 挙げながら説明していきます。 対象読者と前提事項 Linux、OS/2、Windows(R)、UNIX(R) (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 SPM DBI DBA データベース・マネージャーのメッセージ コマンド行プロセッサーのメッセージ レプリケーションのメッセージ コール・レベル・インターフェースのメッセージ Javaの組み込みSQLJのメッセージ 同期点マネージャーのメッセージ インストールまたは構成のメッセージ コントロール・センターおよびデータベース管理ユー ティリティーのメッセージ 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 」や「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(R)/Windows 2000(R): システム、セキュリティー、アプリケーションの イベント・ログ・ファイルおよび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]をクリックして結果を見てみます(以 下の図を参照)。 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: [email protected] 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. -------GG04246 GG04250 GG04251 Abstract -------------------------------------------------DATA LOSS WITH DATAPROPAGATOR APPLY WHEN THE SET HAS A LARGE NUMBER OF MEMBERS AND THE SOURCE IS A CCD. APPLY DOES NOT TERMINATE WHEN COPYONCE IS SPECIFIED AND THE SET FAILS WITH A -1. APPLY COULD MISS THE HINT AND RESULT IN MISSING ROWS IF CAPTURE ENCOUNTERS -911 APAR fixes included in U481406 (Fixpak 1) APAR No. -------GG04218 GG04238 IC32474 Abstract -------------------------------------------------FULL REFRESH APPLY TROUBLE WHEN HANDLING MANY COLUMNS ASNLOAD SHOULD NOT ISSUE RUNSTAT 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 Alerts email DB2 Support News DB2の最近のマニュアル DB2 Support Newsletter DB2 Magazineの記事 結論 ここでは、関連する問題の検索にまつわる、以下のような多くの概念について学びまし た。 ● ● ● ● ● ● ● DB2 Technical Support Webサイトの場所 DB2 Technical Supportサイトのほとんどのコンテンツ APARの概要 APARの特性 APARのステータスの意味 DB2 Technical SupportサイトでのAPARの検索 ニュースグループの検索 セクション7: サマリー この回で学んだこと ここでは、DB2の問題を特定および診断する方法、診断ツールや診断ファイルの基本、問 題の一般的な種類、および他のユーザーが遭遇した類似の問題を見つける方法について学 びました。 こうしたスキルは、技術者としてのスキルと同じくらい重要であるといえます。ここで学 んだことは、これからDB2の問題解決のスキルに磨きをかけていくための基礎となりま す。