Db2「SQL30081N」通信エラーを切り分ける

アプリケーションやバッチが、突然データベースにつながらなくなる。ログを見ると、こんなエラーが並んでいます。

SQL30081N  A communication error has been detected.
Communication protocol being used: "TCP/IP".
Communication API being used: "SOCKETS".
Location where the error was detected: "192.168.10.20".
Communication function detecting the error: "connect".
Protocol specific error code(s): "111", "*", "*".  SQLSTATE=08001

SQL30081N ―― 通信エラーです。ここで大事なのは、これはDb2やSQLの問題ではないということ。Db2エンジンにたどり着く前の、ネットワーク・リスナー・カタログ設定のどこかで接続が成立していないことを示しています。SQLをいくら見直しても直りません。

そして SQL30081N の親切なところは、メッセージ自体に原因を絞り込むヒントが全部書いてある点です。「どの関数で（connect / recv / send）」「どんなエラーコードで（111 / 110 / 104…）」失敗したかが記録されています。この記事では、そのメッセージの読み方と、そこからサーバ側・ネットワーク・クライアント側のどこを順に確認するかを解説します。

まず結論：メッセージの「関数」と「エラーコード」で原因は9割絞れる

切り分けの起点は、メッセージ末尾の Communication function と Protocol specific error code(s) です。TCP/IP環境では、この組み合わせでほぼ原因の系統が分かります。

※ errno はOS（Linux）の値です。Windowsクライアントでは 10061（拒否）／10060（タイムアウト）など別の番号になりますが、意味は対応します。この表で当たりを付けたら、下の切り分けフローに進みます。

切り分けフロー：サーバ側 → ネットワーク → クライアント側

迷ったら、サーバに近いところから順に潰していくのが最短です。「クライアントの設定を疑う」のは、サーバが待ち受けていることを確認してからにします。

① サーバ側：Db2がTCP/IPで待ち受けているか

まず、Db2インスタンスが TCP/IP通信を有効化していて、正しいポートで待ち受けているかを確認します。connect / 111（拒否）のときは、ほぼここが原因です。

# TCP/IP通信が有効か（TCPIP が含まれているべき）
db2set DB2COMM

# インスタンスが使うサービス名／ポートを確認
db2 "GET DBM CFG" | grep -i SVCENAME

# SVCENAME がサービス名なら /etc/services で実ポートに解決する
grep <SVCENAMEの値> /etc/services

# 実際にそのポートでLISTENしているか
ss -lntp | grep <ポート番号>

DB2COMM に TCPIP が無い、あるいは ss でポートがLISTENしていないなら、Db2が通信を受け付けていません。設定を入れて（db2set DB2COMM=TCPIP）インスタンスを再起動します。

② ネットワーク：クライアントからポートに到達できるか

サーバが待ち受けているのに繋がらないなら、間のファイアウォールや経路を疑います。connect / 110（タイムアウト）や 113 はこの系統です。クライアント側のホストから、ポートへの到達性を直接叩いて確認します。

# クライアント機から、DBサーバのポートへ到達できるか
nc -vz 192.168.10.20 <ポート番号>
# もしくは
telnet 192.168.10.20 <ポート番号>

ここで繋がらなければ、Db2の問題ではなく純粋にネットワーク（FW・セキュリティグループ・経路）の話です。インフラ／ネットワーク担当と、対象ポートの開放を確認します。

③ クライアント側：カタログ設定が正しいか

サーバもネットワークも問題ないのに繋がらないなら、クライアントのノード／データベースカタログが古い・間違っている可能性があります。特にサーバ移設やIP変更のあとは、カタログが旧IP・旧ポートを指したままになりがちです。

# カタログされているノード（宛先ホスト・ポート）を確認
db2 "LIST NODE DIRECTORY SHOW DETAIL"

# データベースがどのノードに紐づいているか
db2 "LIST DATABASE DIRECTORY"

宛先が間違っていたら、ノードを取り直します。

db2 "UNCATALOG NODE mynode"
db2 "CATALOG TCPIP NODE mynode REMOTE 192.168.10.20 SERVER <ポート番号>"
db2 "TERMINATE"   # ディレクトリキャッシュを反映

要注意ケース：接続後に切られる（recv / 104）

connect ではなく recv で 104（reset by peer）が出るのは、いったん接続できたのに、途中で相手に切られたパターンです。原因が「繋がらない」系とは異なり、次のようなものが多いです。

• アイドル接続がファイアウォールに切断された：コネクションプールが長時間アイドルの接続を保持していると、間のFWがセッションを切ります。次に使おうとした瞬間に SQL30081N。TCP keepalive の調整や、プールの検証クエリ（validation query）で回避します。
• サーバ側がその接続を落とした：db2stop／強制切断／サーバ側リソース枯渇など。この場合は SQL1224N など別のエラーが同時に出ていることも多いので、サーバ側の db2diag.log を発生時刻で突き合わせます。

HADR構成での SQL30081N：フェイルオーバー後の接続

HADRやpureScaleを組んでいる環境で、フェイルオーバー（テイクオーバー）の直後に SQL30081N が多発することがあります。これは、切り替わってプライマリが別サーバになったのに、クライアントが旧プライマリのIPにつなぎに行っているためです。

対策は、自動クライアント・リルート（ACR）を設定し、代替サーバ（スタンバイのIP／ポート）をクライアントに認識させておくことです。これがないと、切り替えのたびに手動でカタログを張り替えるハメになります。HADRの切り替え運用については db2cm を使用した Pacemaker の構成 も参考にしてください。また、Db2 LUWでTLS接続を有効化する方法 のようにTLSを有効化している場合、TLS用ポートと非TLSポートの取り違えでも SQL30081N になるので、カタログのポートを再確認しましょう。

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

1. メッセージの function（connect/recv） と error code（111/110/104…） を控える
2. 111（拒否）なら → サーバで DB2COMM・SVCENAME・ss -lntp を確認（待ち受けているか）
3. 110（タイムアウト）なら → クライアントから nc -vz でポート到達性を確認（FW／経路）
4. サーバ・NWがOKなら → LIST NODE DIRECTORY でカタログの宛先を確認、必要なら張り直す
5. ホスト名登録なら → 名前解決（DNS/hosts）を確認
6. 104（reset）なら → アイドル切断（keepalive／プール検証）か、サーバ側切断（db2diag.log）を疑う
7. HADR環境なら → 自動クライアント・リルート（ACR）の設定を確認

HADRは設定より「切り替え後に何が起きるか」が本番の勝負どころです。テイクオーバー後の再接続対応まで、本書 第5章「HADRの構築と切り替え運用」で扱っています。

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