データベースに接続しようとしたとき、あるいはコマンドを実行した際に、次のエラーが返ってくることがあります。
SQL1032N No start database manager command was issued. SQLSTATE=57019SQL1032N は「Db2のインスタンスが起動していない」というエラーです。この記事ではまず確認すべき点と、考えられる原因の逆引きを最短でまとめます。OOM Killerの確認など、OSのログを含めた切り分け（実機ログ・深掘り）は末尾のZenn記事にあります。
まず見る（結論）
「インスタンスが落ちている」ことは確定なので、本当にプロセスがいないかを確認します。
# Db2のメインプロセス（db2sysc）が存在するか確認
ps -ef | grep db2syscプロセスがいなければダウンしています。すぐに db2start で起動して復旧できますが、「なぜ落ちていたのか」を先に確認しないと、再発時に原因が追えなくなるため注意が必要です。
症状（背景） → 原因 → 対処（逆引き）
| 背景・状況 | よくある原因 | まず打つ手 |
|---|---|---|
| OSを再起動した直後 | Db2の自動起動がオフになっている | db2start を手動実行し、必要なら db2iauto で自動起動を設定 |
| 誰も操作していないのに突然ダウン | OOM Killer等によるプロセス強制終了 | /var/log/messages や dmesg で oom-killer の痕跡を探す |
| パッチ適用後・メンテナンス後 | 正常な db2stop 後に起動し忘れ |
db2diag.log に正常停止のログがあるか確認し、db2start |
すぐに復旧させたい場合はインスタンスオーナーで db2start を実行し、SQL1063N（成功）が返るか確認してください。
いちばん多い真因：メモリ枯渇（OOM Killer）による強制終了
Linux環境で突然 SQL1032N になる場合、OSのメモリ不足により db2sysc がOS側から強制終了されたケースが非常に多いです。この場合、Db2自身のログにはダウンの理由が綺麗に残らないため、OSログの確認が必須になります。
それでも切り分からないとき（実機ログつきの詳解）
OSログの具体的な見方、db2diag.log を使った正常停止と異常終了の見極めなど、本番環境を想定した詳しい調査手順は、Zennのフル記事にまとめています。