問題判別の手引き
この節では、DB2 エンタープライズ拡張エディションを使用する際にユーザーが直面する問題を処理する方法について説明しています。
以下のトピックを扱います。
重要: この節では、DB2 カスタマー・サポートから利用可能な情報の簡単なサンプルを示します。
DB2 に関する完全な最新情報については、DB2 Product and Service Technical Library (URL は http://www.ibm.com/software/data/db2/library/) を参照してください。
- 症状
- DB2 ユニバーサル・データベース エンタープライズ拡張エディション製品をインストールできない。
- 処置
- 以下のことを確認してください。
- [ ]
- 各ノード上にある DB2 製品ディレクトリーに空きディスク容量が十分ある。
- [ ]
- 前提条件のソフトウェア製品すべてがシステムにインストールされている。
- [ ]
- 同じバージョンの製品がすでにシステム上にインストールされている。
どのノードに障害があるかを検出するには、
アプリケーションの調整ノードにある db2diag.log を調べてください。
ノードがエラーまたは警告を戻す場合、
ノード番号は SQLCA の SQLERRD(6) フィールドに示されます。
この番号は、db2nodes.cfg ファイルのノード番号に対応しています。
(SQL ステートメントまたは API 呼び出しが成功した場合、SQLERRD(6) フィールドのノード番号は調整プログラム・エージェントのノード番号になります。)
- 症状
-
db2start が、ID が "N" のエラー・メッセージを戻します。
たとえば、エラー・メッセージ SQL6048N が戻されます。
- 処置
- 以下のことを確認してください。
- [ ]
- ユーザー ID が、SYSADM、SYSCTRL、または SYSMAINT 権限を持っている。
これらの権限の詳細については、管理の手引き: インプリメンテーション を参照してください。
- [ ]
- すべてのノード上のインスタンス所有者に、同じユーザー ID、グループ ID、
およびパスワードが設定されている。
- [ ]
- db2nodes.cfg ファイル内に定義されたすべてのノードに、DB2 インスタンス ID から rsh コマンドを使用することができる (UNIX プラットフォームの場合)。
これを行うには、$HOME/.rhosts ファイルまたは hosts.equiv ファイルを追加してください。
これらのファイルのファイル許可で、すべてのユーザーが読み取りアクセスできるようにしてください。
これらのタスクが完了したら、rsh date またはこれと同等の db2_all 'date' コマンドのような、UNIX コマンドを使用することができます。
- [ ]
- db2nodes.cfg ファイル ($HOME ディレクトリーの下の sqllib サブディレクトリー内にある) に、
システムで定義されているすべてのノードに関する正しい情報が含まれている。
ホスト名およびネット名が有効であることを確認してください。
- [ ]
- DB2INSTANCE 環境変数の値がすべてのノードで同じであり、
開始しようとしているインスタンス名と一致している。
- [ ]
- 適切な許可を持っている。
sqllib サブディレクトリーの下の tmp サブディレクトリーの許可を検査し、
必要であれば、インスタンス ID がディレクトリーに対する書き込み許可を持つようにそれらを更新してください。 許可が正しくない場合、
システムのインストールおよびセットアップ中に問題が起こった可能性があります。
- 症状
-
db2start が、ID が "C" のクリティカル・システム・エラー・メッセージを戻します。
たとえば、エラー・メッセージ SQL0902C または SQL1042C が戻されます。
- 処置
- 以下のことを確認してください。
- [ ]
- その製品は正常にインストールされた。
- [ ]
- FCM 通信が適正に使用できる。
/etc/services ファイルに、各 DB2 論理ポートの項目を作成しなければなりません。
FCM の詳細については、
ご使用のオペレーティング・システムの DB2 エンタープライズ拡張エディション 概説およびインストール を参照してください。
- 症状
-
db2start が応答を戻しません。
- 処置
- 以下のことを確認してください。
- [ ]
- RS/6000 SP システム上でハイ・パフォーマンス・スイッチ (HPS) を使用している場合、
すべてのノードで HPS を使用できるようにする。
- [ ]
- db2diag.log ファイルの内容を検査して、
db2start の失敗の原因となりそうなことがないか調べてください。
- [ ]
- インスタンス所有者の $HOME ディレクトリーがすべてのノードを介して NFS にマウントされており、
かつ NFS が実行していることを確認してください。
lockd および statd デーモンが実行していない場合、
db2start がハングすることがあります。
デーモンを開始するには、rc.nfs を実行し、
このコマンドが etc サブディレクトリーの下の inittab サブディレクトリーにあることを確認してください。
- 症状
- 応答しない区画、あるいはハングしている区画があります。
- 処置
- 以下のことを確認してください。
- [ ]
- 以下の質問に答えて、問題を特定してください。
- すべての区画ですべてのコマンドがハングしますか?
- 特定の区画ですべてのコマンドがハングしますか?
これらの質問のいずれかの答えが "はい" になる場合には、
スイッチを含むご使用の環境のハードウェアを検査しなければなりません。
次の点を調べてください。
- すべての区画ですべての db2 コマンドがハングしますか?
- 特定の区画ですべての db2 コマンドがハングしますか?
問題の原因と考えられるプロセスがあるかもしれません。
原因と考えられるプロセスのプロセス ID を、db2_call_stack ツールで使用します。
db2_call_stack を実行してから数分後にアプリケーション・スナップショットを使用し、
アプリケーションが進行しているかどうかを調べてください。
db2_call_stack の詳細については、トラップ・ファイルを参照してください。
- 症状
- いくつかのノードが始動していないか、
または実行していても処理が極端に遅くなっています。
- 処置
- 以下のことを確認してください。
- [ ]
- すべてのノードに DB2 エンタープライズ拡張エディション製品をインストールした。
RISC/6000 クラスター内の NFS マウント・ファイル・システムに製品をインストールすることができますが、
パフォーマンスは犠牲になります。
各ノードに製品をインストールする必要があります。
- [ ]
- すべてのノードで同じレベルの DB2 エンタープライズ拡張エディションがインストールされている。
- [ ]
- NFS が実行しており、
インスタンス所有者のホーム・ディレクトリーがあるマシンに割り振られた NFS デーモン (nfsd) 処理が十分ある。
NFS デーモン (nfsd) プロセスの数は、
マシン上のブロック I/O デーモン (biod) プロセスの数に、
インスタンスにあるマシンの数をかけた数であるはずです。
たとえば、10 個の biods のあるマシン・システムが 4 つある場合には、
インスタンス・ホーム・ディレクトリーの NFS デーモン・プロセスの数は 40 でなければなりません。
- 症状
- データベースを作成できません。
- 処置
-
どのノードに問題が起きているかを判別します。
障害が起きたノード番号は、CREATE DATABASE コマンドとともに戻された SQLCA の SQLERRD(6) フィールド内に保管されます。
障害が起きたノードが分かったら、以下のことを確認してください。
- [ ]
- データベース・ディレクトリー・パスの許可が正しい。
インスタンスには、データベース・ディレクトリー・パスに書き込むための許可がなければなりません。
- [ ]
- すべてのノードに存在するパス上にデータベースを作成している。
- [ ]
- ファイル・システムがマウントされている。
データベースのファイル・システムがマウントされていない可能性があります。
すべてのファイル・システムを再びマウントしてから、データベースを作成してみてください。
マウントされていないファイル・システムがあるか、すべてのノードを検査してください。
- [ ]
- ディスク容量が十分でない。
小規模のテスト・データベースを作成し、
ディスク容量をほとんど必要としないように設定していたことが分かることがあります。
ただし、データベースを作成する場合、デフォルト表スペースおよびデフォルト・ログのために、
一定量のディスク容量が必要になります。
詳細については、管理の手引き: 計画 を参照してください。
- 症状
- DB2 コマンドまたはオペレーティング・システム・コマンドが認識されません。
- 処置
- 以下のことを確認してください。
- [ ]
- DB2 エンタープライズ拡張エディション・システムが正しくインストールされている。
- [ ]
- コマンドを実行するための十分な権限を持っている。
- [ ]
- インスタンス所有者 ID のホーム・ファイル・システムがイーサネットまたはハイ・パフォーマンス・スイッチ上 (RS/6000 SP マシン上) にマウントされる場合、
イーサネットまたはハイ・パフォーマンス・スイッチが実行している。
これが問題であるかどうかを判別するには、
root としてシステムにログオンするか、
インスタンス所有者のホーム・ファイル・システムにあるファイルへのアクセスを試行するか、
netstat コマンドを使用してハイ・パフォーマンス・スイッチの状況を判別してください。
- 症状
- すべてのデータベース区画のデータをバックアップしようとすると、
問題が生じます。
- 処置
- db2_all コマンドを使用して一連のデータベース区画をバックアップする場合は、
最初にデータベースのカタログ・ノードをバックアップする必要があります。
このバックアップをとった後で、残りのデータベース区画をバックアップすることができます。
たとえば、カタログ・ノードをバックアップした後で、
以下の db2_all コマンドを発行して、
残りのデータベース区画をバックアップすることができます。
db2_all '<<-n< db2 backup db <database-alias>'
n はカタログ・ノードのノード番号です。
- 症状
- Windows 2000 で Dynamic Disk モードを使用して作成する区画が多すぎると、
区画が消え、データが消失する可能性があります。
- 処置
- 代わりに、Basic Disk モードを使用してください。
(Basic Disk モードは、Windows NT が使用するモードです。)
- 症状
- Basic Disk モードでデータベース区画を作成する場合、
最も近いシリンダーの倍数 (ある場合にはこれから 1 トラック引かれる) の値に区画サイズが丸められます (切り上げまたは切り捨て)。
たとえば、シリンダーがおよそ 7 MB の場合には、
区画サイズは、要求されたサイズと比較すると 3.5 MB ほどの誤差が生じます。
- 処置
- データベース区画は、表スペースに指定されている大きさよりも 3.5 MB 大きく作成しなければなりません。
LOAD ユーティリティーを使用する方法、
またはオートローダーを使用して、データを分割し、
そのデータをノードにロードする方法に関する詳細については、
データ移動ユーティリティー 手引きおよび解説書 を参照してください。
db2atld コマンドについては、sqllib サブディレクトリーの下の misc サブディレクトリーから db2atld -h を入力してください。
- 症状
- LOAD がデータをロードしません。
- 処置
- 以下のことを確認してください。
- [ ]
- 正しい権限を持つユーザーが LOAD を実行した。
インスタンス所有者と同じグループに属し、SYSADM または DBADM 権限を持つユーザーが、LOAD を実行することができます。
- [ ]
- ロードされている表または表スペースが、まだ別のアプリケーションによって使用されていない。
LOAD は表を共用できないので、
すべての必須の表をロックできるまで実行しません。
表がすでにロックされている理由を判別し、ロックが解除されるようにしてください。
- [ ]
- LOAD がすべてのノード上で開始された。
データが並列にロードされるようにするために、
すべてのノード上で LOAD を実行しなければなりません。
すべてのノードにシェルを送信するスクリプトがある場合、LOAD 実行がリモート・シェルによって逐次化されないようにしてください。
LOAD がノード上で失敗したかどうかを検査するには、
次のメッセージ・ファイルを調べてください。
- 直接 LOAD コマンドを発行する場合、コマンドに MESSAGES オプションを使用して、
メッセージ・ファイルの名前と位置を指定することができます。
- db2atld コマンドを使用する場合、
メッセージ・ファイルは現行作業ディレクトリーにあります。 ノードごとに 1 ファイルあり、
各ファイルには load_log.nnn という名前が付けられます。
nnn は、db2nodes.cfg ファイルに指定されているノード番号です。
- [ ]
-
データの形式が正しい。
正しいデータ形式の使用に関する詳細については、コマンド解説書 を参照してください。
以下のことに注意してください。
- 症状
- LOAD がすべての行を拒否しました。
- 推定原因
- 列定義が正しくありません。
- 処置
- METHOD L を使用している場合、データ列仕様が正しいか確認します。
列をシフトすると、切り捨てエラーになったり、データが表の列定義と一致しなくなります。
- 症状
- LOAD が完了しましたが、行がロードされていません。
- 推定原因
- LOAD がすべての行を拒否しました。
- 処置
- db2atld を実行した一時ディレクトリーにある db2load ファイルを検査し、
すべての行が拒否されたかどうかを確かめます。
複数の行がロードされている場合には、データ移動ユーティリティー 手引きおよび解説書 を参照してください。
- 症状
- ロード操作に失敗しました。
- 推定原因
- データ・ファイルが存在しない、またはカラム名が無効であるなどの、ユーザーのエラーが原因でロード・ユーティリティーが開始しません。
- 処置
- 最後に整合性のあった地点からロード操作を再始動する (RESTART オプションを使用) か、
または表全体を再ロードします (REPLACE オプションを使用)。
以前に呼び出したのと同じパラメーターを指定し、
ユーティリティーが必要な一時ファイルを検出できるようにしてください。
LOAD についての追加情報は、データ移動ユーティリティー 手引きおよび解説書 を参照してください。
- 症状
- db2atld プログラムは正常に完了しましたが、
データが分割されていません。
- 推定原因
- db2atld プログラムが、
データのアナライズだけを実行するように設定されました。
- 処置
- オートローダー構成ファイルを調べて、
Mode パラメーターがデータをアナライズするようには設定されないようにします。
このオプションはデータを分割しません。
データのアナライズのみを行って、新しい区分化マップを提案します。
詳細については、データ移動ユーティリティー 手引きおよび解説書 を参照してください。
- 症状
- db2atld プログラムは正常に完了しましたが、
データが正しく分割されていません。
- 処置
- 以下のことを確認してください。
- [ ]
- 2 進データがストリング列にない。
BINARYNUMERICS または PACKEDDECIMAL オプションがロード・コマンド上に指定されない限り、db2atld プログラムがデータ・タイプの列内に 2 進データを検出することはできません。
- [ ]
- SplitNodes および OutputNodes パラメーターが正しく設定されている。
そうでない場合、出力データ・ファイルは正しくないことがあります。
詳細については、データ移動ユーティリティー 手引きおよび解説書 を参照してください。
- 症状
- ロードされているデータが選択カウントと一致していません。
- 処置
- 以下のことを確認してください。
- [ ]
- データが変換プログラムによって正しく分割されている。
db2atld プログラムはヘッダー・ファイルを作成して、
データが間違ったノードにロードされないようにします。
ヘッダー情報は LOAD によって検査されます。
変換プログラムを使用して 2 進列を文字形式に変換する場合、
変換は db2atld プログラムによって行われるものとは同じにならないことがあります。
データが正しいノードでは分割されますが、変換中にデータが異なる値に変換され、
同じ方法でハッシュされないことがあります。
- [ ]
- 区画列がヘッダーと一致している。
データが 1 組の区分化キーを使用して分割され、他の列で区画済みだった表にロードされる場合、LOAD 操作は失敗します。
区画列情報は、分割データ・ファイルのヘッダーにあります。
ヘッダーを手動で更新した場合、
構築された妥当性検査方法はオートローダーに変更されてしまいます。
- 症状
- CREATE INDEX ステートメントが失敗またはハングします。
- 推定原因
- 表スペースがいっぱいであるか、またはログ・スペースが足りません。
- 処置
- 索引ページおよびソートのために十分なディスク容量があり、
ログ・スペースも十分あるか確認します。
ディスク・サイズの計算およびログ・サイズの判別については、管理の手引き: 計画 を参照してください。
- 症状
-
接続が中断しているように見えます。
- 推定原因
- データベースが再始動されましたが、まだ回復中です。
破損回復が進行中の場合、障害からデータベースを回復するのにしばらく時間がかかります。
これは、データベースが破損する前、
ログ記録の活動を多量に必要とする操作を実行していた場合に生じます。
これは、通常の状態です。
- 処置
- すべてのデータベース区画上の db2diag.log を調べて、
破損回復が完了したかどうかを確かめます。
db2diag.log の項目には、回復を開始したときと終了したときが示されます。
すべてのデータベース区画でログ・ファイル・ディレクトリーを検査して、
入出力アクティビティーを調べます。
入出力アクティビティーがある場合には、障害回復が続行していることを意味します。
- 症状
- RESTART DATABASE コマンドが、SQL1034C、SQL1042C、または SQL1072C を戻します。
- 推定原因
- 直前のアクティビティーのプロセス間通信 (IPC) リソースが、破損回復の正常な実行を妨げています。
- 処置
- db2stop を使用してデータベース・インスタンスを遮断します。
以下を発行して、すべての区画で DB2 プロセスを検査します。
ps -ef | grep <instance name>
以下を発行して、すべての区画で IPC リソースを検査します。
ipcs | grep <instance name>
db2stop の後でプロセスまたは IPC リソースのいずれかが存在する場合には、
db2_kill を発行してこれらを削除します。
db2_kill の発行後、再びプロセスおよび IPC リソースを検査します。
それでもこれらが存在する場合には、プロセスに対しては kill コマンド、
IPC リソースに対しては ipcrm コマンドを使用して、別々に除去する必要があります。
ipclean コマンドも、各リソースに ipcrm を実行する前に使用できます。
すべてのプロセスおよび IPC リソースが除去されたら、カタログ・ノードにログオンし、以下を発行します。
db2 restart database <database-alias>
次に、以下のようにして残りの区画またはノードの再始動を実行します。
db2_all "<<-n< db2 restart database <database-alias>"
n はカタログ・ノードのノード番号です。
SQL1034C、SQL1042C、または SQL1072C エラー・メッセージが続く場合には、DB2 顧客サポートに連絡してください。
以下の情報が回答できるように収集しておいてください。
- すべてのデータベース区画からの db2diag.log
- RESTART DATABASE に障害が起きているデータベース区画
- 障害が起きているデータベース区画からの RESTART のトレース
- すべてのノードからのデータベース構成
- すべてのノードからのデータベース・マネージャー
- db2nodes.cfg ファイル
- 障害が起きているデータベース区画からの SQLOGCTL.LFH ファイル
- 障害が起きているデータベース区画からのアクティブ・ログ・ファイル
- 症状
- 回復中に SQL1061W メッセージを受け取ります。
- 推定原因
- 通常、1 つまたは複数のノードを始動できないために、
完了できない未確定トランザクションがあります。
データベースが回復され、ユーザー接続のためにオープンしますが、
未確定トランザクションがメモリーと他のリソースを処理しています。
- 処置
- 調整プログラム・ノードの db2diag.log を調べて、
すべてのノードが始動しているかどうか確かめます。
できるだけ早く未確定トランザクションを解決します。
詳細については、管理の手引き: 計画 にある発見的手法に関する説明を参照してください。
区分データベース環境では、DB2 は SQL ステートメントをサブセクションに区切ります。
各サブセクションは関係するデータがあるノードで処理されます。
結果として、アプリケーションにアクセスできないノードでエラーが起こることがあります。
複数ノード用のアプリケーションを開発する場合には、以下のことを考慮してください。
- 症状
-
区画データベース環境では、
アプリケーションからの SQL ステートメントは、異なる区画で処理されます。
すべての区画ですべての SQL ステートメントが完了するまで、アプリケーションも完了しません。
1 つまたは複数の区画が完了しない場合には、アプリケーションは完了しません。
- 処置
- 以下のことを確認してください。
- [ ]
- ハングしているまたは遅すぎると思われる特定のアプリケーションを書き留めます。
どのアプリケーションおよび区画が遅延の原因となっているかを判別するには、以下のようにします。
- アプリケーションが "ロック待機" 状態である可能性があるため、
すべての区画でアプリケーション状況を検査します。
これは、LIST APPLICATIONS コマンドを使用して、
すべての区画でアプリケーション状況を検査することにより実行できます。
- 処理された、またはログに記録された行について GET SNAPSHOT コマンドからの出力を検査します。
- 使用中のメモリーに影響を与える構成パラメーター設定を検査します。
これがパフォーマンスの問題を引き起こしている可能性があります。
管理の手引き: パフォーマンス も役立つ場合があります。
LIST APPLICATIONS および GET SNAPSHOT コマンドの詳細については、
コマンド解説書 を参照してください。
重大エラーには 2 つの主なタイプがあります。
- プログラム例外のため、DB2 処理が強制終了 (kill) される。
この場合、データベース管理プログラムはノードで即時に終了されますが、
活動作業単位はロール・バックされません。
他のノードが障害を検出する場合、
障害が起きたノードとの関係によって以下のように回復しようとします。
- 障害の起きたデータベース区画がデータベースのカタログ・ノードであった場合、
すべてのエージェントがノードから強制的に切断されるため、
データベース全体が他のすべてのノードでダウンします。
このような状況のときは、
そのデータベース区画上のすべてのデータベースに対して RESTART DATABASE を実行し、
すべてのデータベース区画を再始動しなければなりません。
従属ノードの一部においても破損回復が必要である可能性があります。
詳細については、コマンド解説書 を参照してください。
- 障害の起きたデータベース区画がアプリケーションの調整プログラム・ノードだった場合、
その調整プログラム・ノードの代わりにノードで実行しているすべてのサブエージェントがデータベース区画で強制的にオフにされ、
活動作業単位はロール・バックされます。
このような状況のときは、db2start で調整ノードを再始動して、
それからその区画上のすべてのデータベースに対して RESTART DATABASE を実行し、
破損回復手順を実行しなければなりません。
詳細については、コマンド解説書 を参照してください。
- 障害の起きたノードが従属ノードである場合、
調整プログラム・エージェントがまだ COMMIT フェーズに入っていなければ、
障害が起きたノードを含む活動作業単位を持つ調整プログラム・エージェントはその活動作業単位をロール・バックします。
COMMIT フェーズに入っている場合には、
トランザクションが未確定であることを示す SQL コード -279 が戻されます。
- 問題が生じて、データベースが不整合になる。
データベースにアクセスしようとすると、SQL コード -1034 (SQL 状態 58031) または SQL コード -1015 (SQL 状態 55032) が戻されます。
この場合、
すべての調整プログラム・エージェントおよびサブエージェントがデータベースから強制的にオフにされます。
その後、これらのエージェントは現在の作業単位をロール・バックし、
データベースから切断します。
他のノード上にあるアプリケーションがこのノードにあるデータベースにアクセスできる場合、
データベースに対して RESTART DATABASE を実行することによって、
データベースを整合性のある状態に保たなければなりません。
様々な理由で、
重大エラー SQL コード -1224 (SQL 状態 55032) が起こりえます。
このメッセージを受け取ったならば、どのノードに障害が起こったか SQLCA から調べ、
付加的な詳細情報について db2diag.log を調べてください。
詳細については、障害が起きたノードの判別を参照してください。
注: 複数のマシンが関係する重大エラーが起きたときは、
マシンが db2diag.log の NFS ロックを獲得できなかった場合、db2diag.log ではなく各マシンの syslog ファイルで診断情報を見つけることができます。
障害の起きている区画またはノードが分かったら、db2start nodenum コマンドを使用します。
たとえば、"3" が障害の起きているノードだとすると、次のようになります。
db2start nodenum 3
個々の区画またはノードで db2start が失敗する場合には、
すべての区画で db2stop を実行してから db2start を実行しなければなりません。
nodenum が指定されていない場合には、
ノード構成ファイルに定義されているすべての区画が開始されています。
整合性のない区画でデータベースを再始動します。
どの区画に整合性があるかを調べるには、
各区画で database_consistent 情報データベース・パラメーターを参照してください。
RESTART DATABASE コマンドを使用することの詳細については、コマンド解説書 を参照してください。
[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]