DB2 異常終了時の対処方法と、原因調査に必要な最低限の資料収集方法

問題(概要)

DB2 が異常終了した場合の回復方法と、原因の調査に必要な資料の取得方法について記述します。

症状

ハードウェア障害や DB2 自身の障害などにより DB2 のインスタンスが異常終了し、トランザクションが続行できなくなることがあります。
インスタンスが異常終了すると、UNIX/Linux 環境の場合は db2sysc をはじめとする各 DB2 エンジン・プロセス、Windows 環境の場合は db2syscs.exe プロセスが終了します。

例えば、トランザクションがコミットされる前にこのような障害が発生すると、データベース内のデータが矛盾した、または使用不能な状態のままになっている可能性があります。このままではトランザクションの継続ができないため、クラッシュ・リカバリーによってデータベースを整合性があり使用可能な状態に戻す必要があります。

原因

インスタンスが異常終了する主な原因は以下のようなケースが考えられます。

• db2agent や db2pclnr などのスレッド (プロセス) が不正なアドレスをアクセス (SEGV, AV) するなどにより異常終了し、データの整合性を保つために、DB2 自身がインスタンスを強制終了
• db2agent や db2pclnr などのスレッド (プロセス) が DB 破損などクリティカルなエラーにより続行不可能と判断し abort() によってインスタンスを強制終了
• なんらかの原因で DB2 エンジン・プロセスが SIGKILL で強制的に kill され、その結果インスタンス全体が終了

解決方法

データベースを矛盾したまたは使用不能な状態から回復するために以下の手順を実施してください。

Unix/Linux 環境ではインスタンス・オーナーとしてログインして実行してください。
Windows 環境では Administrator としてログオンし、 DB2 コマンド・ウィンドウから実行してください。

1. インスタンスを再起動します。
   
   db2start
   
2. 障害発生時に未完了になっている作業単位があった場合には、データベースを整合性があり使用可能な状態に戻すためにクラッシュ・リカバリーが必要になります。
   自動再始動 (AUTORESTART) データベース構成パラメーターの値によって対応方法が異なるため、下記コマンドで設定を確認します。
   
   db2 get db cfg for <dbname>
   
   自動再始動有効         (AUTORESTART) = on
   
   
3. 上記パラメーターの値により、データベースの異常終了後、アプリケーションがデータベースに接続するときにデータベース・マネージャーが自動的にデータベース再始動ユーティリティーを呼び出すかどうかが決まります。
   
   1. ON (デフォルト値) に設定している場合：
      データベース・マネージャーによって自動的にクラッシュ・リカバリーが実行されます。
   2. OFFに設定している場合：
      自動再始動は動作しません。クラッシュ・リカバリーが実行される必要がある (再始動される必要がある) データベースに接続を試みたアプリケーションは、SQL1015N エラーを受け取ることになります。この場合は、そのアプリケーションで RESTART DATABASE コマンドを発行し、データベースを再始動する必要があります。
      
      db2 restart database <dbname>
      
4. クラッシュ・リカバリーが正常に完了すると db2diag.log に以下のような ADM1531E メッセージが記録されます。

MESSAGE : ADM1531E Crash recovery has completed successfully.

なお、回復時に以下の事象が発生する可能性があります。

a) 異常終了後、db2start を実行したが、インスタンスを起動できない
b) クラッシュ・リカバリーが終わらない

a) 異常終了後、db2start を実行したが、インスタンスを起動できない
インスタンスの異常終了後、不正な IPC リソースが残っていることで、SQL1042C や SQL1072C が発生し、インスタンスの起動に失敗する場合があります。

対応方法
インスタンスの起動に失敗した場合には、以下手順にてインスタンスを強制終了後、IPC リソースを削除し、インスタンスを再起動してください。

[AIX]

1. インスタンスを強制終了します。
   1. Enterprise Server Edition の場合、以下のコマンドでインスタンスを強制終了します。
      db2_kill
      
   2. Enterprise Server Edition 以外の場合 (db2_kill コマンドが存在しない場合)、以下のコマンドでインスタンスを強制終了します。
      db2nkill 0
      
2. 不正な IPC リソースを解放します。
   1. IPC リソースを解放します。
      ipclean
      
   2. IPC リソースが残っているか確認します。
      ipcs -a | grep <インスタンス・オーナー名>
      
   3. IPC リソースが残っている場合には、以下コマンドで除去してください。
      ipcrm -q <msgid> (メッセージキューの場合。ipcs で先頭がqのもの)　
      ipcrm -m <shmid> (共有メモリーの場合。ipcs で先頭がmのもの)
      ipcrm -s <semid> (セマフォーの場合。ipcs で先頭がsのもの)
      
      ※ ipcs の出力結果を確認し、ipcrm コマンドではそれぞれメッセージキュー、共有メモリー、セマフォーの ID を指定してください。
      
3. インスタンスを起動します。
   db2start

[Linux]

1. インスタンスを強制終了します。
   1. Enterprise Server Edition の場合、以下のコマンドでインスタンスを強制終了します。
      db2_kill
      
   2. Enterprise Server Edition 以外の場合 (db2_kill コマンドが存在しない場合)、以下のコマンドでインスタンスを強制終了します。
      db2nkill 0
      
2. 不正な IPC リソースを解放します。
   1. IPC リソースを解放します。
      ipclean
      
   2. IPC リソースが残っているか確認します。
      ipcs -q | grep <インスタンス・オーナー名>
      ipcs -m | grep <インスタンス・オーナー名>
      ipcs -s | grep <インスタンス・オーナー名>
      
   3. IPC リソースが残っている場合には、以下コマンドで除去してください。
      ipcrm -q <msgid> (メッセージキューの場合)　
      ipcrm -m <shmid> (共有メモリーの場合)
      ipcrm -s <semid> (セマフォーの場合)
      
      ※ ipcs の出力結果を確認し、ipcrm コマンドではそれぞれメッセージキュー、共有メモリー、セマフォーの ID を指定してください。
      
3. インスタンスを起動します。
   db2start

[Windows]

1. db2syscs.exe およびその子プロセスを強制終了します。
   1. 単一の DB2 製品と DB2 インスタンスのみの環境
      taskkill /f /im db2syscs.exe /t
      
   2. 複数インスタンスの環境
      1. DB2 インスタンスの PID を確認します。
         tasklist /svc /fi "imagename eq db2syscs.exe"
         
      2. DB2 インスタンスを終了します。
         taskkill /f /pid <DB2 インスタンスの PID> /t
         
         ※ /t オプションを指定しないとシステムを再起動までインスタンスを起動できないことがあります。
         
2. インスタンスを起動します。
   db2start

b) クラッシュ・リカバリーが終わらない
更新処理をしていた場合に異常終了となった場合には、次回起動後にデータベースの再始動の際にクラッシュ・リカバリーが行われ、未コミット・トランザクションのロールバックなどが行われます。

対応方法
クラッシュ・リカバリーは異常終了後のデータベースを正常な状態に戻すために必要な処理です。途中で停止することはできず、クラッシュ・リカバリーが完了するのを待つ必要があります。
進行状況は、以下のコマンドで確認できます。

db2 list utilities show detail

上記手順で復旧できない場合や、原因の調査が必要な場合は、IBM テクニカル・サポートへ連絡し、下記資料をご送付ください。

取得すべき資料

1. 再現シナリオや、問題発生時の処理内容が分かっている場合には下記の情報をご送付ください。
2. • 問題発生の時刻・時間帯
   • 問題発生時の処理内容 (特定の SQL を実行したなど)
   • 再現性の有無
     • 特定の操作により起こった場合は、その操作により再度問題が起こるかどうか
   • 発生頻度
   • 再起動によって回復はしているか
     
3. db2support (db2diag.log ファイル、 db2level や データベース構成情報、 トラップ・ファイル等が含まれます)

以下のURL内の手順をご参照の上、ご取得ください。

【db2support 取得手順 for UNIX(UNIX/Linux)】
http://www.ibm.com/jp/services/its/support/svcdoc/db2/db2support_u.html

【db2support 取得手順 for Windows】
http://www.ibm.com/jp/services/its/support/svcdoc/db2/db2support_w.html

db2support がすぐに取得できない場合は以下の資料をご取得ください。

• db2level の出力
• db2set -all の出力
• get db cfg の出力
• get dbm cfg の出力
• db2diag.log ファイル
• トラップ・ファイル
  • データベース・マネージャー構成パラメーター DIAGPATH で設定したパスに作成されます。
  • SIGKILL(シグナル#9) 以外を受けた場合は、異常終了時にトラップ・ファイルという形でクラッシュした際の情報が出されます。
  • 通常は、根本原因をキャプチャーするトラップ・ファイルが一つと、その問題が他の DB2 プロセスに及ぼす影響をキャプチャーするトラップ・ファイルがいくつか存在します。
  • トラップ・ファイル名は [プロセス ID (PID).スレッド ID (TID).パーティション番号.trap.bin] となります。
  • Windows 環境の場合はトラップ・ファイルはバイナリー・ファイルのため、フォーマット後、バイナリー・ファイルとともにご送付ください。
    
    実行例：
    188.2916.trap.bin というトラップ・ファイルが DIAGPATH に作成されている場合、以下のようにフォーマットできます。
    
    db2xprt 188.2916.trap.bin 188.2916.trap.bin.txt
    
    db2xprt - トラップ・ファイルのフォーマット 
    

http://www-01.ibm.com/support/docview.wss?uid=swg21503288