本文へジャンプ

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名(非表示設定にしていない限り)とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

  • 閉じる [x]

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


送信されたすべての情報は安全です。

  • 閉じる [x]

IBM Lotus Notes/Domino 7の新しい保守機能

Jon Champlin, Software Engineer, IBM
Jon Champlin is a Software Engineer on the Level 3 Support team focusing on many areas of Lotus Notes/Domino, including serviceability. He works with IBM to get new releases rolled out internally. Jon joined Iris/Lotus in June 2000.

概要: 自動診断収集機能の拡張と新しいFault Analyzer機能により、Lotus Notes/Domino 7の保守機能が強化されました。これらの改善が、サーバーまたはクライアントのクラッシュを扱う上でどのように役に立つのかを理解しましょう。

日付:  2006年 3月 28日
レベル:  初級 この記事の原文:  英語
アクティビティー: 2815 ビュー
お気軽にご意見・ご感想をお寄せください: 


クライアントとサーバーのクラッシュは誰もが避けたいものですが、ひとたびそれが発生した場合は、再発を防止し、迅速な復旧を行うために必要なデータを入手することが最優先事項となります。 この記事では、IBM Lotus Notes/Domino 7に追加された新しい保守機能について解説します。この記事は、IBMサポートに送信するためにクラッシュ関連の適切なデータを取得したいDominoのシステム管理者、およびNotes Clientが突然停止したときに何が起きたのかを知りたいユーザーの方を対象に書かれています。



障害復旧と自動診断収集に関する背景

障害復旧はリリース 4からUNIXプラットフォーム向けのLotus Dominoに搭載されましたが、マニュアルに記載がなく、やや使いづらいものでした。 Lotus Notes/Domino 6から、障害復旧はLotus Notes/Dominoが実行されているすべてのプラットフォームで機能するようになり、サーバー文書で容易に設定できるようになりました。 障害復旧は、クライアントまたはサーバーに使用されているすべてのリソースを追跡し、クラッシュが発生したときは、これらをすべてクリーンアップします。 Domino Serverについては、診断情報を取得した後に、これを再起動するオプション機能があります。 ユーザーにとって、これはNotes Clientによって開始されたすべてのプロセスを停止しなくても、クラッシュ後にNotes Clientを再起動できることを意味します。

障害復旧により、Lotus Notes/Dominoはクラッシュごとに適切な診断情報を収集できます。しかし、クラッシュが発生した各マシンで、この情報にアクセスしなければならないため、 Notes Clientクラッシュの場合はこれが問題となることがあります。各マシンからデータを収集する必要性をなくすために、自動診断収集(ADC)機能がLotus Notes/Domino 6.0.1に追加されました。 ADCを使用してメール受信データベースを設定することにより、Notes ClientまたはDomino Serverのクラッシュから収集された診断情報を中央の1箇所のリポジトリーに集約することができます。

ADCは、サーバー設定文書(サーバー用)およびデスクトップポリシー設定文書(クライアント用)を通じて設定できます。データは、クライアントまたはサーバーが再起動するときに、メール受信データベースに送られます。 クライアント・クラッシュの場合、ポリシー文書によって、ユーザーに診断情報の送信の選択を許可するかどうか、クラッシュ前にユーザーが何をしていたかを示すコメントの入力を許可するかどうかを設定できます。


Lotus Notes/Domino 7の自動診断収集(ADC)に追加された新機能

Lotus Notes/Domino 7では、ADC機能が拡張されました。このセクションでは、新しい機能について紹介し、より適切な診断情報を収集し、機能停止に至るまでの傾向を把握する方法について解説します。 新しい機能は次のとおりです。

  • クラッシュ発生時に収集するファイルの設定
  • SametimeおよびQuickPlaceのクラッシュで収集される追加情報
  • Dominoドメインモニター(DDM)へのサーバーの再起動の通知
  • ログ用オプションの拡張
  • 電子メール通知に含まれる情報の拡張
  • 添付ファイルサイズの制限
  • NSDの実行が設定されていない場合の警告
  • Fault Analyzer

収集するファイルの設定

Lotus Notes/Domino 6.xでは、ADCはあらかじめ決められたファイルのリストに沿って収集していました。これには、NSD出力、コンソール・ログ、メモリー・ダンプが含まれます。 標準的なクラッシュのデバッグにはこれらの情報で十分ですが、固有のログ・ファイルを持つサード・パーティー製アプリケーションがクライアントまたはサーバーで実行されている場合はどうなるでしょうか。 あるいは、セマフォーで競合があり、それが停止の原因となったためにSEMDEBUG.TXTファイルを取得したい場合はどうすればよいでしょうか。

Lotus Notes/Domino 7では、デフォルトで取得されるファイルの数が増え、クラッシュ時に追加ファイルを収集するためのオプションも設けられています。デフォルトで収集されるファイルは次のとおりです。

  • NSD出力:システム情報のダンプと、クラッシュ時にすべてのNotes/Dominoプロセスの各スレッドが何をしていたかを示す情報です。
  • コンソール出力:Dominoコンソールに書き込まれたメッセージを含むテキスト・ファイルです。
  • メモリー・ダンプ:特定の時刻にNotes/Dominoプロセスによって割り当てられていたメモリー・ブロックのスナップショットです。
  • Notes_Child_PID出力:各プロセスの作成時のプロセス IDと、終了時のステータス情報です。
  • Memcheckエラー:Notes/Dominoメモリー・プールをスキャンするときに、memcheckプログラムによって検出されたエラーです。
  • セマフォー・デバッグ:競合するセマフォーを示すテキスト・ファイルです。
  • HTTPセッション/スレッド・ログ:各HTTPセッションとスレッドが何をしていたのかを示す詳細情報です。これは、クラッシュがHTTPで発生し、セッション/スレッド・ロギングが有効になっている場合にのみ収集されます。
  • NSD-sysinfo出力:クライアント/サーバーの起動時に記録されたシステム情報です。
  • NSD-kill出力:クライアントまたはサーバーを終了するためにnsd -killを使用したときに収集される情報です。

これらのファイルに加え、サーバー設定文書またはデスクトップポリシー設定文書を設定することにより、クラッシュ時に存在する可能性がある任意のファイルを収集できます。 これらのいずれかの文書で[診断情報]タブをクリックすると、次の図1に示すようなセクションが表示されます。これは、Domino 7のDominoディレクトリの設計を使用します。


図1. [診断情報コレクションオプション]セクション


[診断情報ファイルのパターン]フィールドには、クラッシュ時に検索し、メール受信データベースに送る文書に情報を添付するファイル名またはパターンのリストを入力します。 ただし、添付されるのは、設定されたサイズの制限を超えない場合です(サイズの制限については、後述の「添付ファイルのサイズの制限」セクションを参照してください)。 パターンには、1つ以上の文字を示すアスタリスク(*)、または1文字を示す疑問符(?)を含めることができます。

ファイルが現在の診断ディレクトリー(通常は、<データ・ディレクトリー>/IBM_TECHNICAL_SUPPORT)にある場合は、ファイル名だけを指定します。 ファイルがこのディレクトリーの外部にある場合は、ファイルの絶対パスを指定する必要があります。

SametimeおよびQuickPlaceのクラッシュに関する追加情報

クラッシュがSametimeサーバーまたはQuickPlaceサーバーで発生した場合は、デフォルトで追加情報が収集され、メール受信データベースに送られる文書に添付されます。 具体的には、Sametimeでのクラッシュの場合は、stdiags_*ファイルがメール受信文書に追加されます。 QuickPlaceでのクラッシュの場合、Lotus Dominoは問題の診断に役立つqpconfig.xmlファイルとadmin.nsfファイルの添付を試みます。

Dominoドメインモニターにポストされたサーバーの再起動情報

Dominoドメインモニター(DDM)はLotus Domino 7の新機能で、ドメイン全体がどのように機能しているかを示す高レベルのビューをシステム管理者に提供します。 クラッシュ後にサーバーが再起動するとメッセージがDDMにポストされ、システム管理のコンソールでイベントを追跡できます。また、DDMによって、ドメイン全体にわたりこれらのイベントを追跡した履歴も得られます。

ログの選択肢の拡張

Lotus Notes/Domino 6.xでは、クライアントまたはサーバーでコンソール・ロギングが有効になっていないと、メール受信データベースにコンソール情報が収集されません。 しかし、特定のケースでは問題の原因を把握するためにこれらの情報が必要になるため、Lotus Notes/Domino 7では、情報を得るためにさまざまな工夫がされています。

ログが有効であるかどうかにかかわらず、サーバーがDominoコントローラー(Javaコントローラーとも呼ばれます)下で実行されている場合、ADCは最初にDominoコントローラーのログ(サーバー上)でコンソール情報を検索します。 サーバーがDominoコントローラー下で実行されている場合、ADCはそのログを使用します(サーバー設定でのサイズ制限に従います)。 このログはコンソールに出力された情報のスーパーセットであり、メッセージと各メッセージの重大度を示すコードを含んでいます。

ADCがクライアントで実行されている場合、またはサーバーがDominoコントローラー下で実行されていない場合、ADCはコンソール・ログが有効かどうかをチェックします。 有効な場合は、Lotus Domino 6.xのときと同様に、ADCはコンソール出力を使用します。

コンソール・ログが有効でない場合、ADCはlog.nsfに書き込まれた情報を使用します(これは、コンソール・ログに含まれる情報のサブセットです)。 情報を得る方法としては、log.nsfの[Miscellaneous Events]ビューでクラッシュの時刻までさかのぼってテキストを抽出し、疑似コンソール出力ファイルを作成します。 そして、コンソール・ログの場合と同様に、このファイルを文書に添付します。log.nsf全体を文書に添付しない理由は、ほとんどのケースで、設定されているサイズの制限値よりもlog.nsfが大きくなるためです。 また、log.nsfはバイナリー・ファイルなので、単純に切り捨てて最後の部分だけを送ることができないためです。

電子メール通知に含まれる情報の拡張

Lotus Domino 6.xには、サーバーが再起動するときにユーザーまたはグループに通知を送信する設定オプションがあります。 しかし、この通知には、サーバーがクラッシュした日時や現在は回復していることを示す基本的な情報しか含まれていません(図2参照)。


図2. Domino 6のサーバー再起動通知

Lotus Notes/Domino 7ではこの通知が拡張され、件名と本文により多くの情報が含められるようになりました。このため、通知リストによって、クラッシュに関する詳細な情報をより素早く得ることができます。 図3に示されるように、[件名]フィールドには、Dominoのバージョン、クラッシュしたプロセス、およびクラッシュの時刻が含まれています。 [本文]フィールドには、メール受信データベースに送信されたほとんどすべての情報が(添付ファイルを除く)、メール受信データベースへのデータベースリンクと共に含まれています(クラッシュしたサーバーと同じドメインにメール受信データベースがある場合)。


図3. Domino 7のサーバー再起動通知

[件名]行の拡張により、通知リストに登録されていてハンドヘルド・デバイスやページャーを使用しているユーザーも、メール受信データベースにアクセスせずに、必要な情報を得られます。 6.x形式を使いたい場合は、6.x形式でメッセージを送信させるすべてのサーバーのNotes.iniファイルで、Notes.iniパラメーター「ADC_USE_OLD_EMAIL_FORMAT=1」を設定します。

Notes.iniパラメーターFR_ATTACH_NSDは、Lotus Domino 7でも使用できます。FR_ATTACH_NSDは、サーバーの再起動時に送信される通知メッセージにNSD出力ファイルを添付するかどうかを指定します。 このパラメーターを 1に設定すると、NSD出力が通知メッセージに添付されます。1よりも大きな値を設定した場合、NSD出力のサイズが、設定値をキロバイト単位で示した値以下の場合にのみ、NSD出力が添付されます (たとえば、「FR_ATTACH_NSD=5」と設定すると、NSD出力のサイズが5KB以下のときにのみ添付されます)。 この設定は、NSD出力を通知メッセージに添付するかどうかだけに適用され、メール受信データベースに送信されるメッセージに何を添付するかについては影響しません。

添付ファイルサイズの制限

ADCがメール受信データベースに送るメッセージに添付ファイルを追加するときの問題の1つとして、メッセージのサイズが大幅に増加する点が挙げられます。メッセージを転送するための十分なディスク・スペースがない場合や、社内でルーター・コントローラーを使用して環境内で送信されるメッセージのサイズを制限している場合は、サイズの増加が問題となります。

Lotus Notes/Domino 7では、メール受信データベースに送信されるメッセージの合計サイズを制限できるだけでなく、どれだけの量のNSD出力を[診断情報コレクションオプション]セクションに添付するのかを指定できます(これは、前のセクションで説明したINIパラメーターとは無関係です)。図4をご覧ください。


図4. [診断情報コレクションオプション]セクションの最大サイズ・フィールド

図4に示されるように、デフォルトでは、メッセージ・サイズの合計は5MBで、NSD出力は2MBです。これはファイルの先頭からの値で、最初の2MB分が使用されます。

ADCがメッセージを構築するとき、次の順序でファイルを添付します。

  1. NSD出力(設定されたサイズまで)
  2. コンソール出力(設定されたサイズまで)
  3. Diagindex.nbfファイル。このファイルには、サーバーの前回の再起動以降に生成されたすべての診断情報ファイルのリストが含まれています。
  4. それ以外のすべてのファイル。他のデフォルトのファイルや収集するよう設定したファイルなどが含まれます。

NSDファイルを切り捨てる必要がある場合、または制限を超えるためにファイルをメッセージに添付できない場合、これらのファイルはメール受信データベースに格納されるので、手動で取り出すことができます。サーバー・クラッシュの例を図5に示します。


図5. サーバー・クラッシュのADCメッセージの例


クライアント・クラッシュの場合は、どのデスクトップポリシー設定が有効になっているかを示す追加情報が得られます(図6参照)。


図6. クライアント・クラッシュのADCメッセージの例


NSDが設定されていないときの警告

ADCは、その多くの情報をNSD出力に依存しているので、クラッシュ時にNSDが実行されるよう設定されていないと、有効な情報がADCレポートにほとんど収集されません。特に、IBMサポートがお客様の問題を解決するために使用する情報は得られません。これをシステム管理者に警告するために、クラッシュ時にNSD出力が検出されない場合は、次の警告がメール受信データベースに表示されます。

WARNING: Crash information not extracted! Make sure NSD is configured to run on the Server document.


Fault Analyzer

Lotus Domino 7でのADCの最大の新機能はFault Analyzerです。Fault Analyzerは、メール受信データベース内のクラッシュ・レポートと、情報を送信するADCを比較できるDomino Serverの新しいアドイン・タスクです。

Fault Analyzerは多くのメール受信データベースを処理できますが(たとえば、クライアント・クラッシュとサーバー・クラッシュ用に異なるデータベースを使用している場合など)、現在処理中のデータベースでのみ一致を検索し、複数のデータベースにわたって一致を検索することはありません。

Fault Analyzerが新しいクラッシュについて一致を検出できない場合、そのクラッシュは親クラッシュとして指定されます(このクラッシュが初めて検出されたことを意味します)。Fault Analyzerが一致を検出すると、そのクラッシュは子クラッシュとして指定され、同じクラッシュの最初の出現例がその親となります。この親子関係については後述しますので、ここでは、2つのクラッシュが一致するかどうかを判断するプロセスについて説明しましょう。

一致プロセス

2つのNotes/Dominoクラッシュが根本的に同じ問題から発生したのかどうかを判断することは、常に簡単であるとは限りません。Lotus Notes/Dominoは階層型アーキテクチャーであるため、エラー・メッセージだけに基づいて原因を識別することはできません。異なるコード・パスが同じエラー・メッセージを生成する可能性があるからです。

Fault Analyzerは、クラッシュしたスレッドに呼び出された関数のシーケンスを使用して、クラッシュの固有のシグニチャーを作成します。この関数呼び出しのシーケンスは、クラッシュへのパスを示します。

さまざまなNotes/DominoプラットフォームでのNSD出力ファイルを調べると、オペレーティング・システムによってコール・スタック情報を表示する方法が大きく異なることがわかります。ADCは、レポートをメール受信データベースに送信する前に、これらの違いを正規化します。この正規化には、関数を日時的に逆順でリストアップしたり、C++関数をデマングルする(<クラス>::<関数>という形式にする)処理が含まれます。

Fault Analyzerは、スタックの先頭から下方に順番に読み込むことによってその一致プロセスを開始し、2つのスタック間で一致しない関数名に遭遇するまで、読み込みを続けます。スタックの先頭はPanic関数によって決められます。Panic関数は、Windows 32プラットフォームではアクセス違反となったスタックの最初の関数で、UNIXではfatal_error後の最初の関数です。

Fault Analyzerはstack1内の各関数を順番に読み取り、stack2の同じ位置に一致する関数があるか調べます。このプロセスは、関数が一致しなくなるまで繰り返されます。一致しなくなった時点で、2つのスタック間の一致率(パーセント)が決められます。一致率は、2つのスタック間で共通する関数の数を、各スタックの関数の数の平均で割ることによって算出します。

たとえば、stack1に10個の関数、stack2に15個の関数があり、スタック間で最初の5個の関数が一致するとき、一致率は 5 / ((10+15) / 2) = 41パーセントとなります。

もし、2つのスタック間ですべての関数が共通する場合、一致率は100パーセントとなり、これは完全一致と呼ばれます。この場合、2つのクラッシュは同じ根本原因を持つと判断してもよいでしょう。しかし、2つのスタックが同じ根本原因を持っていても、コール・スタックが一致するとは限りません。これは、Lotus Dominoが、サブシステムを相互に積み上げて構築するレイヤー型モデルとして成り立っているためです。もし、データベース(NSF)にアクセスするレイヤーで問題が発生すると、多くの他のサブシステム(たとえば、ルーター、レプリケーターなど)が同じ根本的問題に遭遇しますが、その問題につながるコール・スタックの内容は、それぞれ異なるものになります。

2つのスタックが部分的に一致するかどうかを決めるために、2つのコール・スタックの平均スタック長に基づいてパーセントで分類する方法が用いられています。平均スタック長は、stack1とstack2の関数の数を加え、これを2で割って求めます。平均コール・スタック長に基づいて判断するときのカットオフ・パーセントを下表に示します。

コール・スタック長カットオフ・パーセント
< 4完全一致であること。スタックに存在する関数の数が少なすぎるため、一部の関数が同じであっても、部分一致と認めるのは危険です。
4一致率が75パーセント以上であること。
5 〜 7一致率が60パーセント以上であること。
8 以上一致率が40パーセント以上であること。

平均スタック長が増加すると、部分一致と認めるためのパーセンテージが低下しています。これは、より長いスタックでは、スタックの最上位で共通する関数が多いほど、問題が同じであることの信頼性が高まるからです。

このアルゴリズムは、Fault Analyzerを実行するサーバー上のNotes.iniファイルでパラメーター「FAULT_ANALYZER_MATCH_PERCENTAGE」を設定することにより、手動で変更できます。パラメーターの設定範囲は1〜99です。この設定を用いると、平均スタック長にかかわらず、すべてに同じ一致率が適用されます。

Fault Analyzerの設定

Fault Analyzerは、デフォルトでオフになっています。メール受信データベースでFault Analyzerを機能させるには、そのデータベースがDomino 7サーバーでホストされている必要があります。また、Dominoディレクトリをリリース 7の設計にアップグレードしなければなりません。これによって、Fault Analyzerを設定するための新しいフィールドがサーバー文書の[診断情報]タブに追加されます(図7 参照)。


図7. サーバー設定文書のFault Analyzerに関するフィールド


デフォルトでは、Fault Analyzerを有効にすると、Fault Analyzerはサーバー上のすべてのメール受信データベースに対して有効になり、サーバーの開始時に起動されます(Notes.iniファイルのServerTasks行に追加する必要はありません)。Fault Analyzerは、メール受信データベースが定義されているサーバー設定文書またはデスクトップポリシー設定文書をローカルDominoディレクトリで検索し、サーバー上のどのデータベースがADCメール受信データベースであるのかを識別します。該当するデータベースがローカル・サーバーにあるときは、それをモニターします。該当するデータベースがローカル・サーバーで見つからない場合は、Fault Analyzerはシャットダウンします。

Fault Analyzerは、起動時にメール受信データベースで新規クラッシュをすべて処理し、次のクラッシュが発生するまでアイドル状態となります。クラッシュが発生するとFault Analyzerはすぐに実行を開始し、新しいクラッシュを処理します。

選択したデータベースに対してFault Analyzerを実行するよう設定することもできます(図8 参照)。サーバー上の一部のデータベースだけにFault Analyzerを実行したい場合、または複数の場所でFault Analyzerを実行する代わりに、すべてのメール受信データベースを1つのサーバーに複製し、その1箇所で処理する場合に、このオプションを選択します。


図8. 選択されたデータベースで実行するように設定されたFault Analyzer


また、コンソール・コマンド「load faultanalyzer」を発行することで、Fault Analyzerを手動で実行できます。引数を渡さないと、Fault Analyzerは前述の方法を用いて、現在のサーバー上ですべてのADCメール受信データベースを検索します。データベース、ディレクトリー、またはインダイレクト・ファイル(データベースのリストを含む *.IND)を示す引数を渡すことにより、Fault Analyzerが処理する対象を指定できます。Fault Analyzerを手動でロードした場合、Fault Analyzerはデータベース内の新規クラッシュを処理して終了します。次のクラッシュが発生するまでアイドル状態で待機することはありません。

メール受信データベースのスペースを節約するために、子クラッシュ(完全一致と部分一致の両方)から添付ファイルを削除するオプションを使用できますこれは、同じクラッシュであると判断された場合は診断情報を2つ保存する必要はないという考えに基づいています。メール受信データベースから削除するよう選択した場合でも、データはクライアントまたはサーバーに残っています。

メモ:Lotus Domino 6.xでADCを実行していて、Lotus Domino 7にアップグレードし、Fault Analyzerを有効にすると、Fault Analyzerの最初の実行時に、メール受信データベース内の現在のすべてのエントリーが処理されます。

Notes/Domino Fault Reportsデータベースの変更点

Notes/Domino Fault Reports (lndfr.ntf)テンプレートがDomino 7サーバー用にアップグレードされ、ADCメール受信データベース内にあるすべての新規情報が見られるようになりました。サーバーをリリース 7にアップグレードし、designタスクを実行すると、現在のメール受信データベースが新しい設計にアップグレードされます。

データベースの新しいアウトラインを図9に示します。[By Date]、[Clients]、[Servers]の各ビューに [Standard]ビューと[Fault Analyzed]ビューが追加されたので、現在の日付による分類に加えて、親子関係を表示できます。


図9. Domino 7 Fault Reportsデータベースのアウトライン


新しい[Fault Analyzed]ビューでは、子クラッシュは、それに対応する親クラッシュのもとへカテゴリー化されます。親クラッシュ文書を開くと、それに関連するすべての子クラッシュが、文書の一番上にある埋め込みビューに表示されます。文書をダブルクリックすることで、埋め込みビューから子クラッシュ文書を直接開くことができます。完全一致または部分一致の場合は親クラッシュまでの文書リンクが含まれているので、文書リンクを使って親クラッシュに移動できます。また、部分一致の場合は一致率も示されるので、2つのスタックがどれぐらい一致しているかを確認できます。

出現数

それぞれの親クラッシュの出現数は、現在のメール受信データベースでそのクラッシュが検出された回数の合計を示します。この数は、親クラッシュ文書の[Administrative]セクション(図10 参照)と、メール受信データベースのすべてのビューに表示されます。


図10. 親クラッシュ文書内の[Administrative]セクションの[Occurrences]フィールド


固有ID数

Fault Analyzerは、合計出現数に加え、特定のクラッシュによって影響を受けた固有のクライアントまたはサーバーの数も追跡しています。これは、問題の重みを決定するときに役立ちます。たとえば、20人の異なるユーザーが20回のクラッシュを経験した場合、同じユーザーが20回のクラッシュを経験した場合よりも、より重大であると判断されます。固有IDは、親クラッシュ文書の管理セクションに、問題を経験した回数の降順でリスト表示されます。また、この数はメール受信データベースのビューでも見ることができます。

解決されたクラッシュ

クラッシュの根本原因を特定し、その修正を含むリリースにアップグレードするか、修正用のホット・フィックスを適用した後は、同じスタックによる以降のクラッシュを子クラッシュとして扱わず、別の親クラッシュとして扱いたいと考えます(クラッシュはすでに解決されているため)。

以降の一致するスタック・コールを新しい親として扱うには、既存の親クラッシュ文書の管理セクションでクラッシュを解決済みとしてマークします。解決されたクラッシュは、ビュー内でその横に緑色のチェックマークが表示されます。

クラッシュを解決済みとしてマークするとき、すべてのクライアント/サーバーに修正を適用済みとして指定するか、修正を含むNotes/Dominoバージョンおよびホット・フィックスのリストを入力できます(図11 参照)。Fault Analyzerは、あるリリースで問題が解決されているならば、それ以降のリリースでも問題は解決済みであるとみなします(これは、Notes/Dominoリリースとホット・フィックス、つまりコンボ・ホット・フィックスにも適用されます)。また、Fault Analyzerはリリース 6.x と 6.5xとの関係も考慮するため、6.0.4で修正済みの件は6.5.2でも修正済みとして扱います。


図11. 親クラッシュを修正済みとして編集する


まとめ

この記事では、Lotus Notes/Domino 7で強化された保守機能について説明しました。これらの機能を使用すると、クライアント・クラッシュとサーバー・クラッシュをより効率よく扱うことができます。これを機に、Lotus Notes/Domino 7にアップグレードして、コード・ネームHannoverと呼ばれるIBM Lotus Notesの次期リリースを楽しみに待ちましょう。


参考文献

学ぶために

製品や技術を入手するために

議論するために

著者について

Jon Champlin is a Software Engineer on the Level 3 Support team focusing on many areas of Lotus Notes/Domino, including serviceability. He works with IBM to get new releases rolled out internally. Jon joined Iris/Lotus in June 2000.

不正使用の報告のヘルプ

不正使用の報告

ありがとうございます。 このエントリーは、モデレーターの注目フラグが設定されました。


不正使用の報告のヘルプ

不正使用の報告

不正使用の報告の送信に失敗しました。


developerWorks: サイン・イン


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 利用条件

 


お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。 プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。 お客様の姓名(非表示設定にしていない限り)とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

表示名をお選びください

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

(半角英数字で3文字以上31文字以下にする必要があります)


「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 利用条件

 


この記事を評価する

コメント

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=340581
ArticleTitle=IBM Lotus Notes/Domino 7の新しい保守機能
publish-date=03282006
author1-email=champlin@us.ibm.com
author1-email-cc=

タグ

Help
このタグで、My developerWorks のすべてのタイプのコンテンツを見つけるために検索フィールドを使用します。

スライダーバーを使用することで、より多く(少なく)タグを表示します。

人気のタグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するトップのタグを表示します。

マイ・タグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するお客様ご自身のタグを表示します。

このタグで、My developerWorks のすべてのタイプのコンテンツを見つけるために検索フィールドを使用します。人気のタグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するトップのタグを表示します。マイ・タグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するお客様ご自身のタグを表示します。