データベースに接続しようとしたとき、あるいはコマンドを実行した際に、次のエラーが返ってくることがあります。
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（成功）が返るか確認してください。
Linux環境で突然 SQL1032N になる場合、OSのメモリ不足により db2sysc がOS側から強制終了されたケースが非常に多いです。この場合、Db2自身のログにはダウンの理由が綺麗に残らないため、OSログの確認が必須になります。
それでも切り分からないとき（実機ログつきの詳解）
OSログの具体的な見方、db2diag.log を使った正常停止と異常終了の見極めなど、本番環境を想定した詳しい調査手順は、Zennのフル記事にまとめています。
この記事のような現場のTIPSを、Db2運用の全体像として12章に体系化しました。公式マニュアルには載らない「あのとき知っていれば」を減らすための1冊です。
現場で引ける Db2 の教科書
現場で引ける！Db2実践エンジニア・バイブル
Db2はRDBMS市場でシェア数%。情報が少なく、頼れるのは膨大な公式マニュアルだけ―― そんな現状を変えたくて、「なぜこの値にするのか」「この障害のとき次に何を見るのか」という、マニュアルに載っていない現場の文脈を1冊にまとめました。書いてあることはすべて実際の現場で経験したことです。
アーキテクチャ／構成パラメーター選定／セキュリティ／バックアップ・リカバリ／HADR／pureScale／日常点検の自動化／メモリ・ロック競合／SQLチューニング／RUNSTATS・REORG／MON_GET監視／現場の難題集 ―― 全12章＋運用シェルスクリプト集。
