Troubleshooting
Problem
Db2 が異常終了した場合の回復方法と、原因の調査に必要な資料の取得方法について記述します。
Symptom
ハードウェア障害や Db2 自身の障害などにより Db2 のインスタンスが異常終了し、トランザクションが続行できなくなることがあります。
インスタンスが異常終了すると、UNIX/Linux 環境の場合は db2sysc をはじめとする各 Db2 エンジン・プロセス、Windows 環境の場合は db2syscs.exe プロセスが終了します。
例えば、トランザクションがコミットされる前にこのような障害が発生すると、データベース内のデータが矛盾した、または使用不能な状態のままになっている可能性があります。このままではトランザクションの継続ができないため、クラッシュ・リカバリーによってデータベースを整合性があり使用可能な状態に戻す必要があります。
インスタンスが異常終了すると、UNIX/Linux 環境の場合は db2sysc をはじめとする各 Db2 エンジン・プロセス、Windows 環境の場合は db2syscs.exe プロセスが終了します。
例えば、トランザクションがコミットされる前にこのような障害が発生すると、データベース内のデータが矛盾した、または使用不能な状態のままになっている可能性があります。このままではトランザクションの継続ができないため、クラッシュ・リカバリーによってデータベースを整合性があり使用可能な状態に戻す必要があります。
Cause
インスタンスが異常終了する主な原因は以下のようなケースが考えられます。
- db2agent や db2pclnr などのスレッド (プロセス) が不正なアドレスをアクセス (SEGV, AV) するなどにより異常終了し、データの整合性を保つために、Db2 自身がインスタンスを強制終了
- db2agent や db2pclnr などのスレッド (プロセス) がデータベース破損などクリティカルなエラーにより続行不可能と判断し abort() によってインスタンスを強制終了
- なんらかの原因で Db2 エンジン・プロセスが SIGKILL で強制的に kill され、その結果インスタンス全体が終了
Resolving The Problem
データベースを矛盾したまたは使用不能な状態から回復するために以下の手順を実施してください。
Unix/Linux 環境ではインスタンス・オーナーとしてログインして実行してください。
Windows 環境では Administrator としてログオンし、 「DB2 コマンドウィンドウ - 管理者」から実行してください。
a) 異常終了後、db2start を実行したが、インスタンスを起動できない
b) クラッシュ・リカバリーが終わらない
すべての Db2 プロセスの停止 (Linux および UNIX)
クラッシュ・リカバリー
トラップ・ファイル
Unix/Linux 環境ではインスタンス・オーナーとしてログインして実行してください。
Windows 環境では Administrator としてログオンし、 「DB2 コマンドウィンドウ - 管理者」から実行してください。
- インスタンスを再起動します。
db2start
- 障害発生時に未完了になっている作業単位があった場合には、データベースを整合性があり使用可能な状態に戻すためにクラッシュ・リカバリーが必要になります。
自動再始動 (AUTORESTART) データベース構成パラメーターの値によって対応方法が異なるため、下記コマンドで設定を確認します。db2 get db cfg for <db_name> 自動再始動有効 (AUTORESTART) = ON
- 上記パラメーターの値により、データベースの異常終了後、アプリケーションがデータベースに接続するときにデータベース・マネージャーが自動的にデータベース再始動ユーティリティーを呼び出すかどうかが決まります。
- ON (デフォルト値) に設定している場合:
データベース・マネージャーによって自動的にクラッシュ・リカバリーが実行されます。 - OFFに設定している場合:
自動再始動は動作しません。クラッシュ・リカバリーが実行される必要がある (再始動される必要がある) データベースに接続を試みたアプリケーションは、SQL1015N エラーを受け取ることになります。この場合は、そのアプリケーションで RESTART DATABASE コマンドを発行し、データベースを再始動する必要があります。db2 restart database <db_name>
- ON (デフォルト値) に設定している場合:
- クラッシュ・リカバリーが正常に完了すると db2diag.log に以下のような ADM1531E メッセージが記録されます。
MESSAGE : ADM1531E Crash recovery has completed successfully.
なお、回復時に以下の事象が発生する可能性があります。
a) 異常終了後、db2start を実行したが、インスタンスを起動できない
b) クラッシュ・リカバリーが終わらない
- 異常終了後、db2start を実行したが、インスタンスを起動できない
インスタンスの異常終了後、不正な IPC リソースが残っていることで、SQL1042C や SQL1072C が発生し、インスタンスの起動に失敗する場合があります。
対応方法
インスタンスの起動に失敗した場合には、以下手順にてインスタンスを強制終了後、IPC リソースを削除し、インスタンスを再起動してください。
[AIX]- インスタンスを強制終了します。
- 以下のコマンドでインスタンスを強制終了します。
db2_kill
- Db2 10.1 以前の一部のエディションで db2_kill コマンドが存在しない場合、以下のコマンドでインスタンスを強制終了します。
db2nkill 0
- 以下のコマンドでインスタンスを強制終了します。
- 不正な IPC リソースを解放します。
- 異常終了前の Db2 が使用していた IPC リソースを解放します。
ipclean
- IPC リソースが残っているか確認します。
ipcs -a | grep <インスタンス・オーナー名>
- IPC リソースが残っている場合には、以下コマンドで除去してください。
ipcrm -q <msgid> (メッセージキューの場合。ipcs で先頭がqのもの) ipcrm -m <shmid> (共有メモリーの場合。ipcs で先頭がmのもの) ipcrm -s <semid> (セマフォーの場合。ipcs で先頭がsのもの)
- 異常終了前の Db2 が使用していた IPC リソースを解放します。
- インスタンスを起動します。
db2start
[Linux]- インスタンスを強制終了します。
- 以下のコマンドでインスタンスを強制終了します。
db2_kill
- Db2 10.1 以前の一部のエディションで db2_kill コマンドが存在しない場合、以下のコマンドでインスタンスを強制終了します。
db2nkill 0
- 以下のコマンドでインスタンスを強制終了します。
- 不正な IPC リソースを解放します。
- 異常終了前の Db2 が使用していた IPC リソースを解放します。
ipclean
- IPC リソースが残っているか確認します。
ipcs -q | grep <インスタンス・オーナー名> ipcs -m | grep <インスタンス・オーナー名> ipcs -s | grep <インスタンス・オーナー名>
- IPC リソースが残っている場合には、以下コマンドで除去してください。
ipcrm -q <msgid> (メッセージキューの場合) ipcrm -m <shmid> (共有メモリーの場合) ipcrm -s <semid> (セマフォーの場合)
- 異常終了前の Db2 が使用していた IPC リソースを解放します。
- インスタンスを起動します。
db2start
[Windows]- db2syscs.exe およびその子プロセスを強制終了します。
- 単一の Db2 製品と Db2 インスタンスのみの環境
taskkill /f /im db2syscs.exe /t
- 複数インスタンスの環境
- Db2 インスタンスのインスタンス名と PID を確認します。
tasklist /svc /fi "imagename eq db2syscs.exe"
- Db2 インスタンスを終了します。
taskkill /f /pid <DB2 インスタンスの PID> /t
- Db2 インスタンスのインスタンス名と PID を確認します。
- 単一の Db2 製品と Db2 インスタンスのみの環境
- インスタンスを起動します。
db2start
- インスタンスを強制終了します。
- クラッシュ・リカバリーが終わらない
更新処理をしていた場合に異常終了となった場合には、次回起動後にデータベースの再始動の際にクラッシュ・リカバリーが行われ、未コミット・トランザクションのロールバックなどが行われます。
対応方法
クラッシュ・リカバリーは異常終了後のデータベースを正常な状態に戻すために必要な処理です。途中で停止することはできず、クラッシュ・リカバリーが完了するのを待つ必要があります。
進行状況は、以下のコマンドで確認できます。db2 list utilities show detail
取得すべき資料
- 再現シナリオや、問題発生時の処理内容が分かっている場合には下記の情報をご送付ください。
- 問題発生の時刻・時間帯
- 問題発生時の処理内容 (特定の SQL を実行したなど)
- 再現性の有無
- 特定の操作により起こった場合は、その操作により再度問題が起こるかどうか
- 発生頻度
- 再起動によって回復はしているか
- db2support (db2diag.log ファイル、 db2level や データベース構成情報、 トラップ・ファイルなどが含まれます)
以下のページを参照して取得してください。
[Db2] db2support の取得手順 (Linux/UNIX 版)
[Db2] db2support の取得手順 (Windows 版)]
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
すべての Db2 プロセスの停止 (Linux および UNIX)
クラッシュ・リカバリー
トラップ・ファイル
[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"ARM Category":[{"code":"a8m500000008PlkAAE","label":"DB2 Tools-\u003Edb2fodc"},{"code":"a8m500000008PlhAAE","label":"DB2 Tools-\u003Edb2pd"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Type":"MASTER"}]
Was this topic helpful?
Document Information
Modified date:
03 November 2023
UID
swg21503288