INSTANCE_MEMORY を明示値に固定した直後から、Db2 が起動しなくなった。あるいは db2start は成功するのに接続だけが落ちる。メモリ関連として SQL1084C を調べた人が多いはずですが、絞りすぎたときに SQL1084C は出ません。
返るのは SQL1220N / SQL1042C / SQL1643C のいずれかで、絞り具合によって変わります。ここでは症状から原因を引く形でまとめます。実機ログつきの詳解は末尾のZenn記事にあります。
まず見る（結論）
設定値と単位を先に確認してください。INSTANCE_MEMORY の単位は4KBページです。20000 は約78MBであって20,000MBではありません。
db2 get dbm cfg | grep INSTANCE_MEMORYAUTOMATIC なら、この記事の症状ではありません。明示値が入っていて、その値がホストの搭載メモリに対して極端に小さければ該当します。
症状 → 原因 → 対処（逆引き）
| 症状 | 原因 | まず打つ手 |
|---|---|---|
db2start が SQL1220N（共有メモリーの割り振り失敗） |
INSTANCE_MEMORY が起動に必要な量を下回っている |
AUTOMATIC に戻して db2start |
db2start が SQL1042C（予期しないシステム・エラー） |
同じく絞りすぎ。起動処理のより後段で落ちている | 同上。メッセージにメモリの記述が無いので設定値から疑う |
db2start は成功、connect だけ SQL1643C |
インスタンス・メモリー上限への到達 | INSTANCE_MEMORY を上げる |
アプリ側に SQL1032N しか見えない |
インスタンスが起動していない（上2行の二次症状） | サーバー側で db2start の出力を直接確認する |
SQL1084C |
OSカーネル側の上限（SHMMAX 等）。絞りすぎとは別物 |
カーネルパラメーターの見直し／db2osconf |
復旧するとき、インスタンスを先に起動する必要はありません。DBM CFG の更新は停止中でも通ります。
db2 update dbm cfg using INSTANCE_MEMORY AUTOMATIC
db2start「インスタンスは上がっている・接続だけ落ちる・db2diag.log には何も無い」の3点が揃ったら、上限到達を疑ってください。ログを探し続けても出てきません。SQL1220N と SQL1042C は残りますが、Event と Severe なので db2diag -level Error では拾えません。
それでも切り分からないとき（実機ログつきの詳解）
どのページ数でどのコードに変わるかの実測値、db2diag.log に残るレコードの読み方、DATABASE_MEMORY を絞っても効かない理由まで含めた解説は、Zennのフル記事にまとめています。
関連: Db2「SQL1032N」インスタンス未起動の原因を切り分ける ／ Db2「SQL1224N」データベースエージェントが起動できない
この記事のような現場のTIPSを、Db2運用の全体像として12章に体系化しました。公式マニュアルには載らない「あのとき知っていれば」を減らすための1冊です。
現場で引ける Db2 の教科書
現場で引ける！Db2実践エンジニア・バイブル
Db2はRDBMS市場でシェア数%。情報が少なく、頼れるのは膨大な公式マニュアルだけ―― そんな現状を変えたくて、「なぜこの値にするのか」「この障害のとき次に何を見るのか」という、マニュアルに載っていない現場の文脈を1冊にまとめました。書いてあることはすべて実際の現場で経験したことです。
アーキテクチャ／構成パラメーター選定／セキュリティ／バックアップ・リカバリ／HADR／pureScale／日常点検の自動化／メモリ・ロック競合／SQLチューニング／RUNSTATS・REORG／MON_GET監視／現場の難題集 ―― 全12章＋運用シェルスクリプト集。
