🛑

Db2「SQL1032N」データベース・マネージャー未起動の切り分けと復旧

2026/07/24に公開

Db2でデータベースに接続しようとしたとき、SQL1032N と表示されて一切の操作が弾かれることがあります。

$ db2 connect to sample
SQL1032N  No start database manager command was issued.  SQLSTATE=57019

これは「Db2のインスタンス（データベース・マネージャー）が起動していない」というエラーです。原因は単なる db2start の実行忘れから、メモリ不足（OOM Killer）による強制終了、OSリブート後の自動起動漏れまで様々です。

この記事では、SQL1032N に遭遇したときの「インスタンスプロセスの確認」「OSログ・db2diag.logの突き合わせ」「正しい起動と復旧の手順」を解説します。

1. 現状の確認（本当に起動していないか）

まず、本当にDb2インスタンスプロセスが存在しないのかを確認します。Db2のメインプロセスは db2sysc です。

ps -ef | grep db2sysc

プロセスがいなければインスタンスはダウンしています。このまま db2start で起動しても良いですが、**「なぜ落ちていたのか（意図的な停止か、クラッシュか）」**を調べずに起動すると、後から原因を追うのが困難になる場合があります。

2. なぜ落ちていたのか？ログからの原因究明

原因は大きく2つに分かれます。

正常な停止（誰かが db2stop を実行した、OSが再起動された）
異常な停止（プロセスがクラッシュした、OOM Killerに殺された）

OSの再起動履歴を確認

OSごと再起動されていた場合は、Db2の自動起動（Fault Monitor）が設定されていないとインスタンスは止まったままになります。

uptime
last reboot

OOM Killer の確認（Linuxの場合）

Db2プロセスが突然消えている場合、LinuxではOOM Killerによる強制終了がよくある原因です。OSのシステムログ（/var/log/messages や dmesg）を確認します。

dmesg -T | grep -i oom-killer
# または
sudo grep -i oom /var/log/messages

もし db2sysc が犠牲になっていれば、OSのメモリ不足が原因です。Db2のメモリ設定（INSTANCE_MEMORY）を絞るか、OSに物理メモリを追加する必要があります。

db2diag.log の確認

Db2自身のログである db2diag.log の末尾を確認します。

db2diag -t "2026-07-24" | tail -n 50

正常に db2stop が発行されていた場合は、次のようなログが残ります。

2026-07-24-12.15.37.XXXXXX+540 IXXXXX       LEVEL: Event
PID     : XXXXX      TID : XXXXX   CORE : 0
...
MESSAGE : DB2STOP processing was successful.

これがあれば、誰かが（あるいは自動スクリプトが）正常に停止したと判断できます。

3. インスタンスの起動と接続確認

原因の目星がついたら、インスタンスを起動します。Db2インスタンスオーナー（db2inst1 など）で実行します。

$ db2start
07/24/2026 12:20:00     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

SQL1063N が返ってくれば起動成功です。再度接続を試します。

$ db2 connect to sample

   Database Connection Information

 Database server        = DB2/LINUXX8664 12.1.4.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLE

これで復旧完了です。

db2start が SQL1063N で成功するのに db2 connect だけが通らない場合は、インスタンスではなくデータベース側の状態を疑います。バックアップ保留なら SQL1116N、ロールフォワード保留なら SQL1117N が返ります。

4. 再発防止：OS起動時のDb2自動起動設定

OS再起動のたびに SQL1032N が発生する場合、Fault Monitor（db2fm）や、db2iauto によるOS起動時の自動起動が有効になっていない可能性があります。

# 現在の自動起動設定を確認
db2set DB2AUTOSTART

オンにする場合は、rootユーザーで設定を行うか、インスタンスオーナーで db2iauto -on <インスタンス名> を実行します（OSとDb2のバージョンにより手順が異なります）。

📕 もっと深く：Db2運用を12章で体系化した本を書きました

この記事で扱った SQL1032N とプロセスの監視・ダウン調査は、Db2運用のほんの一部です。

Db2はRDBMS市場でシェア数%。情報が少なく、頼れるのは膨大な公式マニュアルだけ——そんな現状を変えたくて、「なぜこの値にするのか」「この障害のとき次に何を見るのか」という、マニュアルに載っていない現場の文脈を1冊にしました。実機で検証した内容と、Db2の設計上そうなる理由をまとめました。

日々の運用監視や障害対応の初動をまとめた**第10章「運用と日常点検」・第11章「障害・トラブルシューティング」**をはじめ、アーキテクチャ／構成パラメーター選定／バックアップ・リカバリ／HADR／pureScale／メモリ・ロック競合／SQLチューニング／RUNSTATS・REORG／MON_GET監視／現場の難題・解決集まで、全12章＋運用シェルスクリプト集です。

Db2の運用で踏んだ地雷や、扱ってほしいテーマがあれば、ぜひコメントで教えてください。次の記事のネタにさせてもらいます。