Db2「SQL1224N」データベースエージェントが起動できない原因を切り分ける

アクセスが集中する時間帯や、大量のバッチが一斉に走るタイミングで、こんなエラーが返ってくることがあります。

SQL1224N  The database manager is not able to accept new requests,
has terminated all requests in progress, or has terminated the
specified request because of an error.  SQLSTATE=55032

SQL1224N ―― メッセージは抽象的ですが、実体は「接続を捌くためのエージェント（プロセス）を起動できなかった、または起動済みのものが切られた」という状態です。SQL30081N（通信そのものが成立しない）とは違い、Db2までは到達しているのに、Db2側が受け付けられなかったという点がポイントです。

原因の多くは、次の3つに集約されます。①接続数・エージェント数の上限に達した、②メモリが枯渇してエージェントを作れない、③サーバ側が停止・強制切断した。この記事では、この3系統をどう切り分け、どのコマンドで犯人を特定するかを解説します。

まず結論：エージェントは「上限」か「メモリ」か「停止」で作れなくなる

Db2はクライアント接続を コーディネーター・エージェントという単位で処理します。このエージェントが作れない／維持できないと SQL1224N になります。作れなくなる理由は次のとおりです。

間欠的に「ピーク時だけ出る」なら①か②、「ある時刻から一斉に出た」なら③を先に疑う、というのが当たりの付け方です。

系統①：接続数・エージェント数の上限に達していないか

まず現在の上限設定を確認します。Db2の接続まわりは複数のパラメーターが連動するので、まとめて見ます。

# 接続・エージェント関連の上限をまとめて確認
db2 "GET DBM CFG" | grep -iE "MAX_CONNECTIONS|MAX_COORDAGENTS|MAXAGENTS|NUM_POOLAGENTS"

# データベース単位の最大接続数
db2 "GET DB CFG FOR <DB名>" | grep -i MAXAPPLS

次に、今どれだけ接続を使っているかを見て、上限に張り付いていないかを確認します。ここは MON_GET 表関数が使えます。

# 現在の接続数（アプリケーション単位）
db2 "SELECT COUNT(*) AS CONNECTIONS
     FROM TABLE(MON_GET_CONNECTION(NULL, -2)) AS T"

# エージェントの使用状況（プール・実行中の内訳）
db2pd -agents | head -20

db2 "SELECT APPLICATION_HANDLE, APPLICATION_NAME,
     CLIENT_IPADDR, CONNECTION_START_TIME
     FROM TABLE(MON_GET_CONNECTION(NULL, -2)) AS T
     ORDER BY CONNECTION_START_TIME ASC
     FETCH FIRST 20 ROWS ONLY"

系統②：メモリが足りずエージェントを作れないケース

接続数に余裕があるのに SQL1224N が出るなら、エージェント用のメモリが確保できていない可能性があります。INSTANCE_MEMORY の上限に達している、あるいはOS側の ulimit（プロセス数・メモリ）で頭打ちになっているパターンです。

# インスタンスメモリの上限と使用量を確認
db2 "SELECT MEMORY_SET_TYPE,
     MEMORY_SET_USED / 1024 / 1024 AS USED_MB,
     MEMORY_SET_SIZE / 1024 / 1024 AS SIZE_MB
     FROM TABLE(MON_GET_MEMORY_SET('DBMS', NULL, -2)) AS T"

# db2diag.log にメモリ／エージェント生成失敗が出ていないか
db2diag -g "message:=agent" -H 1d

このとき db2diag.log には、メモリ確保失敗やエージェント生成失敗を示すメッセージ（ADM系や Resource temporarily unavailable など）が出ているはずです。OSの ulimit -a（特に max user processes と max memory）も、Db2インスタンスユーザーで確認します。

系統③：サーバ側の停止・強制切断で切られたケース

「ある時刻を境に、全接続が一斉に SQL1224N になった」なら、サーバ側の操作・障害を疑います。次のような操作は、進行中のリクエストを打ち切ります。

• db2stop（特に db2stop force）：インスタンス停止。メンテナンスや障害復旧の最中に起きがち。
• QUIESCE（静止化）：メンテナンスのためにDB／インスタンスを静止させると、一般ユーザーの新規要求は SQL1224N 相当で弾かれます。UNQUIESCE のかけ忘れが地味に多い落とし穴です。
• FORCE APPLICATION：特定接続の強制切断。切られた側にエラーが返ります。
• 異常終了（トラップ）：db2sysc の異常終了。db2diag.log や db2dump 配下のトラップファイルを確認します。

# インスタンス／DBが静止化(QUIESCE)されていないか、稼働状態を確認
db2 "SELECT DB_STATUS FROM TABLE(MON_GET_DATABASE(-2)) AS T"

# db2diag.log から停止・強制・異常のイベントを時刻付きで抽出
db2diag -H 1d | grep -iE "quiesce|force|db2stop|panic|trap"

SQL1224N が出たときのチェックリスト

1. 症状を確認：ピーク時だけ（①②）か、ある時刻から一斉（③）か
2. MAX_CONNECTIONS / MAX_COORDAGENTS / MAXAPPLS の上限を確認
3. MON_GET_CONNECTION / db2pd -agents で現在の使用量が上限に張り付いていないか見る
4. 上限に張り付いているなら、上げる前に接続リーク（返し忘れ・長時間アイドル）を疑う
5. 接続に余裕があるなら INSTANCE_MEMORY と OSの ulimit、db2diag.log のメモリ／エージェント失敗を確認
6. 一斉発生なら db2stop / QUIESCE / FORCE / 異常終了を サーバ側 db2diag.log で確認

db2topでは見えない「なぜ詰まっているのか」を掴む――MON_GET表関数によるリアルタイム監視の実践を、本書 第11章「MON_GET表関数によるリアルタイム監視」にまとめています。

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