以下のセクションはTeradataサービス担当者を対象としており、クラッシュダンプのトラブルシューティング方法に関する一般的な質問の一部を示します。
- クラッシュダンプの処理中に発生する最も一般的なエラーは何ですか。そしてその発生理由は何ですか。
質問 answer エラー2644は何を示していますか。 DBC.Crashdumpsデータベースがいっぱいです。 不要なテーブルを削除して領域をさらに解放するか、追加の領域をCrashdumpsデータベースに追加します。
エラー「Filesystem full(ファイルシステムがいっぱいです)」は何を示していますか。 ローPDEクラッシュダンプ ディレクトリがいっぱいです。 CSPユーティリティのclearオプションを使用して、不要なクラッシュダンプをダンプ ディレクトリから削除する必要があります。詳細については、Teradataコマンド プロンプトで
csp -h
コマンドを実行します。
エラー「Control GDO maxdumps exceeded; no more dumps will be captured(Control GDO maxdumpを超えています。これ以上のダンプはキャプチャされません)」は何を示していますか。 このエラーは、maxdumpパラメータに到達し、別のクラッシュダンプが発生した場合に表示されます。 次のような名前のクラッシュダンプがあります。 Crash_yyyymmddhhmmss_nn_Part
これはどういう意味ですか?
これは部分的なクラッシュダンプです。クラッシュダンプはCrashdumpsデータベースにまだ保存されていない場合、部分的なクラッシュダンプと見なされます。クラッシュダンプが処理されるまで待機し、より多くの時間をかける必要があります。待機してもクラッシュダンプが使用できるか不明な場合、保存されたクラッシュダンプに対しcsppeekユーティリティを実行します。 クラッシュダンプがダンプ ディレクトリに完全に保存されていない場合、クラッシュダンプは不完全なクラッシュダンプと見なされます。
オペレーティング システムのログのクラッシュダンプ エラー メッセージを検索できます(Teradataクラッシュダンプ メッセージの表示を参照)。
- “.Err”ファイルが存在する場合は何を意味しますか。
BTEQで次のコマンドを実行した場合:
HELP DATABASE CRASHDUMPS;
.Err1ファイルや.Err2ファイルなどの.Errファイルが表示されることがあります。
これは、システムがまだクラッシュダンプを保存中である場合、正常である可能性があります。これらのエラー ファイルは、保存が完了すると消去されます。ただし、CSPがクラッシュダンプを正常に保存せず、.Errファイルが残っている(つまり消去されないまま)ことがログに示されている場合、ダンプの保存中に問題があったことを表わします。
- クラッシュダンプを保存できない場合はどうすればよいですか。CSP保存が失敗した場合、常にまずログを確認します。次に、以下の項目を確認します。
確認項目 説明 ホスト エントリが正しく構成されていますか。ホスト グループIDがすべてのホストで定義されていますか。 クライアントがデータベースにログインするには、COPエントリがhostsファイルで必要です。copname は、/etc/hostsファイルで構成する必要があります。
ホスト名のエントリに加え、クラッシュダンプにアクセスするすべてのクラッシュダンプ ツールに対し各ノードのホスト名COPの別名も定義する必要があります。設定は通常、クライアント ユーティリティのステージングまたは構成中に行なわれます。COPエントリの設定には、次の点を考慮してください。- cop別名エントリは、標準のTeradataネットワークCLIプロトコルに従う必要があります。
- ファイル内のcopエントリの1つがdbccop1である必要があります。この名前は、CLIのデフォルトとして使用されます。hostsファイルにdbccop1がない場合、次のエラーが表示されます。
MOSI: ER_HOST (117): DBC name not found - possible HOSTS file problem. *** ERROR 204: Can't Init Things. Exiting!
COPエントリは連続している必要があり、連続していない場合、CLIは正常に返されない最初のCOPエントリ内のCOPエントリの検索を停止します。例えば、dbccop1、dbccop2、dbccop3、dbccop5がhostsファイルのエントリである場合、CLIはdbccop4がないため、サーバーへの接続にdbccop5を使用しません。
システムが4つのCOPに接続できる場合、hostsファイルのCOPエントリは次のようになります。
[IP address of NODE1] COPNAMEcop1 [IP address of NODE2] COPNAMEcop2 [IP address of NODE3] COPNAMEcop3 [IP address of NODE4] COPNAMEcop4
COPNAMEが異なる限り、ノードごとに複数のCOPエントリを持つことができます。 例えば、次のようになります。
39.64.8.9 smp001-4 dbccop1 hotwmacop1 wmahotcop1 39.64.8.10 smp001-5 dbccop2 hotwmacop2 wmahotcop2 39.64.8.11 smp001-6 dbccop3 hotwmacop3 wmahotcop3 39.64.8.12 smp001-7 dbccop4 hotwmacop4 wmahotcop4
任意の時点で実行されているFastLoadセッションの数をスロットルするために、チューニングの変更を行ないましたか。 FastLoadユーザーが実行中で、クラッシュダンプがPEベースのホスト グループの使用時にセッションにログオンしようとすると、利用可能なセッションが十分でない可能性があります。 Crashdumpsデータベースにダンプの保存に十分な領域がありますか。 Crashdumpsの領域を確認する方法および追加の領域を割り当てる方法については、Crashdumpsデータベースの構成を参照してください。また、より多くの領域を確保するために不要なクラッシュダンプを削除する必要がある場合もあります。 CSPは、指定されたホスト グループ内のノードあたりの最小セッション数を超えて割り当てることはできませんか。 この状況ではクラッシュダンプを保存できません。システムがより静止状態のときに、別の時間枠を見つけます。 - CSPがセッションを使い切ってしまった場合はどうすればよいですか。
クラッシュダンプを保存するには、CSPに対しリソース ファイルで定義されている最小セッション数で記録できる必要があります。デフォルトは、ノードごとに4セッションです。また、PEごとにシステムに設定されている内部セッションの最大数もあります。
CSPがセッションを使い切ってしまった場合、システムがより静止状態のときに、別の時間にCSPを実行します。
- クラッシュダンプを使用できるかどうかはどのようにしてわかりますか。
- CSPユーティリティを使用して、次のコマンドでローPDEクラッシュダンプを確認します。
csp -mode list -source dump
出力は次のように表示されます。
# csp -mode list csp: Searching for dumps in raw dump directory /var/opt/teradata/tddump csp: 4 dumps found, 4 dumps to process csp: Sel ID (date-time-token) Nodes Event Instigator Status csp: --- ---------------------- ----- ----- --------------- ------ csp: * 2008/09/09-17:03:13-02 1 10196 16384/0/(11480) csp: dump_20080909_180130 1 16384 Required files are missing or corrupted csp: 2008/08/14-11:35:58-01 1 10196 16384/0/(15160) csp: * 2008/07/11-14:41:58-01 1 10416 1/11/(28272) csp: * 2008/07/01-11:58:42-05 1 10196 16384/0/(6418) #
ステータス列に“Required files are missing or corrupted(必要なファイルがないか、破損しています)”または“Dump belongs to a different PDE version(ダンプは別のPDEバージョンのものです)”と表示された場合は、クラッシュダンプは使用しないでください。ただしステータス列が空白の場合、クラッシュダンプが使用可能であることを意味します。
- csppeekユーティリティを使用するには、保存されているクラッシュダンプに対しTeradataコマンド プロンプトで次のコマンドを送信します。
csppeek -i -d crashdumpnameここで、crashdumpnameはCrash_ yyyymmdd_hhmmss_nnの形式になっています。
csppeekがクラッシュダンプに関する情報を次のように報告する場合:
Dump (version 20) contains 1 node, 10 vprocs, 35 pids, 839 tids, 0 memos nodeids: 16384(I) Software versions: PDE 13.10.00.00 TDBMS 13.10.00.00 TGTW 13.10.00.00 TCHN 13.10.00.00 TDGSS 13.10.00.00 NODE 16384 is system noun Dump token: Crash_080911_080707_01 instigator: 33//3268 Caused by logevent: 10196-60 reported by /32382720 (3268/16384/0) node 16384 contains vprocs 16384(N) 16383(P) 16382(P) 10238(V) 10237(V) 8192(G) 3(A) 2(A) 1(A) 0(A)
これは、クラッシュダンプが使用可能であることを意味します。何も報告されない場合またはエラーが報告された場合、これはクラッシュダンプ情報を読み取れなかったためクラッシュダンプに問題があることを示しており、クラッシュダンプは使用しないでください。
- CSPユーティリティを使用して、次のコマンドでローPDEクラッシュダンプを確認します。
- 2644の障害(Crashdumpsデータベースに領域がこれ以上ない)が報告されたとき、CSPでクラッシュダンプの自動保存を再開するにはどうすればよいですか。
CSPがこの障害を報告すると、CSPとcspslaveはcspwakeというユーティリティまたはtparesetによって再起動されるまでスリープ状態になります。Crashdumpsデータベースにより多くの領域を追加した後、コマンド プロンプトで引数なしでcspwakeを実行し、自動ダンプ保存を再開できます。自動ダンプ保存が行なわれていなかった場合、代わりに– forceオプションを使用して手動でCSPを起動する必要があります。