| 前へ | 次へ | 目次 | 索引 |
システム・ディスクへのパスが 2 つ以上あるか，システム・ディスクが複数のメンバを持つシャドウ・セットである場合には，確実にシステム・ダンプをシステム・ディスクに書き込むことができるようにするための追加策を取らなければなりません。
16.6.1 Alpha システムでのシステム・ディスクへのシステム・ダンプ
システム・ディスクへのパスが 2 つ以上ある場合には，コンソール環境変数 DUMP_DEV に，そのシステム・ディスクへのすべてのパスが記述されていなければなりません。このようにすれば，フェールオーバのため元のブートパスが使用不可能になった場合でも，システムは引き続きシステム・ディスクを検索し，そこにシステム・ダンプを書き込むことができます。
システム・ディスクのシャドウ・セットが複数のメンバを持つ場合には，コンソール環境変数 DUMP_DEV に，そのシャドウ・セットのすべてのメンバへのすべてのパスが記述されていなければなりません。このようにすれば，マスタ・メンバが代わった場合でも，システムは引き続きマスタ・メンバを検索し，そこにシステム・ダンプを書き込むことができます。
DUMP_DEV を定義しない場合には，システムは，ブート時に使用されたものと同じ物理パスだけを使用した場合に限って，ブート時に使用された物理ディスクにのみ，システム・ダンプを書き込むことができます。 DUMP_DEV の設定の詳細については， 第 16.7.1 項 を参照してください。
一部の構成 (FC (Fibre Channel) ディスクを使用している場合など) には，システム・ディスクへのパスの組み合わせが，DUMP_DEV にリストできる以上に含まれている場合があります。そのような場合には，通常はシャドウ・セットのマスタ・メンバであるシステム・ディスクへのすべてのパスを DUMP_DEV に含めることをお勧めします。シャドウ・セットのメンバ変更が起きる頻度は，パスの変更が起きる頻度よりも少ないためです。
システム・ダンプを代替ディスクへ書き込むこともできますが ( 第 16.7.1 項 を参照)，その場合にも，エラー・ログを書き込むために，システム・ディスクへのパスを定義しなければなりません。したがって，DUMP_DEV には，代替ダンプ・ディスクへのパスの他に，システム・ディスクへのすべてのパスも含まれている必要があります。
DUMP_DEV に含むことができる以上のパスがある場合には，ダンプ・ディスクへのすべてのパスと，システム・ディスクへのできるだけ多くのパス (ただし少なくとも 1 つ) を定義することをお勧めします。システム・ディスクのパスは，リスト内の最後のエントリでなければならないことに注意してください。
16.6.2 VAX システムでのシステム・ディスクへのシステム・ダンプ
システム・ディスクへのパスが 2 つ以上ある場合や，システム・ディスクのシャドウ・セットに複数のメンバがある場合に，確実にシステムがシステム・ディスクを検索し，そこにシステム・ダンプを書き込むことができるようにするには，プラットフォーム固有のブートに関する指示を守らなければなりません。正しいレジスタ値を設定しなければならない VAX システムがある一方で，特定の環境変数を設定しなければならない VAX システムもあります。詳細については，使用している VAX システムのアップグレードおよびインストールに関するマニュアルを参照してください。
システムに複数の CI スター・カプラがある場合には，シャドウ・セット・メンバはすべて同一のスター・カプラを経由して接続されていなければならないことに注意してください。
16.7 代替ディスクへのシステム・ダンプ・ファイルの書き込み
システム・ダンプ・ファイルは，OpenVMS システムのシステム・ディスク (DOSD) 以外の装置に書き込むことができます。大きいメモリを装備したシステムや，共通のシステム・ディスクを使用しているクラスタで， 1 つのディスクのディスク容量だけでは必要なダンプ・ファイルのサイズを必ずしもサポートできないクラスタでは，この機能は特に便利です。
DOSD を使用するための必要条件は，VAX システムと Alpha システムで多少異なります。しかし，どちらのシステムでも，バグチェック・コードがシステム・ダンプ・ファイルを代替装置に書き込むことができるように，DUMPSTYLE システム・パラメータを正しく有効に設定しなければなりません。
以降の節では，Alpha システムと VAX システムでの DOSD の必要条件について説明します。
16.7.1 Alpha システムでの DOSD の必要条件
Alpha システムでの DOSD の必要条件は次のとおりです。
DUMPFILE_DEVICE = "$nnn$ddcuuuu" |
装置のリストを入力できる。
>>> SET DUMP_DEV 装置名[...] |
DEC 3000 シリーズ・システムでは，DUMP_DEV 環境変数を使用するときに，次の制限事項が適用されます。
|
DUMP_DEV 環境変数を使用してダンプ装置を指定し， DUMPSTYLE システム・パラメータを有効に設定するには，次の操作を実行します。
>>> SHOW BOOTDEF_DEV |
BOOTDEF_DEV dub204.7.0.4.3,dua204.4.0.2.3 |
>>> SHOW DEVICES |
Resetting IO subsystem... dua204.4.0.2.3 $4$DUA204 (RED70A) RA72 dua206.4.0.2.3 $4$DUA206 (RED70A) RA72 dua208.4.0.2.3 $4$DUA208 (RED70A) RA72 polling for units on cixcd1, slot 4, xmi0... dub204.7.0.4.3 $4$DUA204 (GRN70A) RA72 dub206.7.0.4.3 $4$DUA206 (GRN70A) RA72 dub208.7.0.4.3 $4$DUA208 (GRN70A) RA72 >>> |
この例で，次のことに注意する必要がある。
>>> SET DUMP_DEV dua208.4.0.2.3,dub208.7.0.4.3,dub204.7.0.4.3,dua204.4.0.2.3 |
この例で，dua208.4.0.2.3 と dub208.7.0.4.3 はダンプ装置に対するパスである。dub204.7.0.4.3 と dua204.4.0.2.3 はブート装置に対するパスである。
システムはダンプ装置としてリストに指定されている装置のうち，最初の有効な装置を選択する。したがって，リストにはシステム・ディスク・エントリより前にダンプ・ディスク・パス・エントリを指定しなければならない。 |
>>> SHOW * |
auto_action HALT baud 9600 boot_dev dua204.4.0.2.3 boot_file boot_osflags 0,0 boot_reset ON bootdef_dev dub204.7.0.4.3,dua204.4.0.2.3 booted_dev dua204.4.0.2.3 booted_file booted_osflags 0,0 cpu 0 cpu_enabled ff cpu_primary ff d_harderr halt d_report summary d_softerr continue dump_dev dua208.4.0.2.3,dub208.4.0.4.3,dub204.7.0.4.3,dua204.4.0.2.3 enable_audit ON interleave default language 36 pal V5.48-3/O1.35-2 prompt >>> stored_argc 2 stored_argv0 B stored_argv1 dua204.4.0.2.3 system_variant 0 version T4.3-4740 Jun 14 2000 15:16:38 >>> |
>>> BOOT SYSBOOT> SET DUMPSTYLE 4 |
DUMPSTYLE システム・パラメータについての詳細は，『Compaq OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』，およびオンライン・ヘルプを参照してください。
システムの再ブート時にエラー・ログ・バッファを復元できるように，エラー・ログ・ダンプ・ファイルはシステム・ディスクに必ず作成されます。このファイルは，DUMPSTYLE システム・パラメータの設定や， DUMP_DEV 環境変数の設定の影響を受けません。 |
VAX システムでの DOSD の必要条件は次のとおりです。
DUMPFILE_DEVICE = "$nnn$ddcuuuu" |
1 つの装置だけを指定できる。
DUMPSTYLE システム・パラメータについての詳細は，『Compaq OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』，およびオンライン・ヘルプを参照。
システム・クラッシュが発生した後でシステムを再ブートするときにエラー・ログ・バッファを復元するには，エラー・ログをシステム・ディスクに保存しておかなければなりません。 AUTOGEN は，そのためにシステム・ディスクに SYSDUMP.DMP ファイルを作成します。このファイルは，エラー・ログ・バッファの最大サイズを格納できるだけの十分な大きさです。 |
システム・ダンプ・アナライザ・ユーティリティ (SDA)を使用してシステム・ダンプ・ファイルの内容を翻訳し，クラッシュの予想される原因を調べることができます。クラッシュ・ダンプの分析については，『OpenVMS VAX System Dump Analyzer Utility Manual』または『OpenVMS Alpha System Analysis Tools Manual』を参照してください。
システムに障害が発生した場合は， SDA を使用して障害発生時のシステム・ダンプ・ファイルのコピーを作成し，弊社のサポート担当者に連絡してください。システム・ダンプ・ファイルのコピーの作成については， 第 16.12 節 を参照してください。
16.9 SDA CLUE コマンドによるクラッシュ・ダンプ・ファイルの分析 (Alpha のみ)
SDA CLUE (Crash Log Utility Extractor) コマンドは，クラッシュ・ダンプの分析と，スタンドアロン・システムやクラスタで発生した重大なバグのチェックの履歴の管理を自動的に行います。 SDA CLUE コマンドは，SDA とともに使用し，標準の SDA からアクセス困難なダンプ・ファイル補足情報を収集およびデコードすることができます。また，SDA CLUE コマンドを，Dump Off System Disk (DOSD) とともに使用し，システム・ディスク以外のディスクにあるシステム・ダンプ・ファイルを解析することができます。
16.9.1 CLUE について (Alpha のみ)
Alpha システムでは，システム障害後にシステムを再ブートするとき， SDA は自動的に呼び出されます (省略時の設定)。クラッシュ・ダンプの分析をより容易にするために， SDA CLUE コマンドは自動的に CLUE リスト・ファイルのダンプ・ファイル要約情報を取得および保管します。
スタートアップ・コマンド・プロシージャは，次の動作を行うコマンドを起動します。
CLUE HISTORY コマンドは，履歴ファイルに要約エントリを 1 行だけ追加し， SDA CLUE コマンドの次の出力をリスト・ファイルに保存します。
この CLUE リスト・ファイルの内容は，システム障害を分析するときに便利です。
このようなファイルがしきい値 (省略時 5000 ブロック) を超えるまで蓄積される場合，(しきい値の限界内になるまで) 古いファイルから削除されます。 CLUE$MAX_BLOCK 論理名を使って，これをカスタマイズすることも可能です。
システムのスタートアップ時に CLUE を実行しないようにするには， SYLOGICALS.COM ファイル中の論理名 CLUE$INHIBIT を /SYS TRUE と定義します。
CLUE$nodename_ddmmyy_hhmm.LIS にはクラッシュ・ダンプの概要しか入っておらず，常にクラッシュの原因を決定するのに十分な情報が入っているとは限りませんので注意してください。システム・クラッシュの分析を詳細に行わなければならない場合は，常に SDA COPY コマンドを使用して，ダンプ・ファイルを保存しておくことをおすすめします。
| 前へ | 次へ | 目次 | 索引 |