【DB2】connect reset と terminateの違い

コマンドライン（CLP）でデータベースから切断するときってこの2つあるけど、いまいち違いをちゃんと理解していなかったのです。
初心に戻って改めて調べてみました。

- 目次 -

1 調べてみた
- 1.1 IBM Documentationではなんと？
- 1.2 バックエンドプロセスとはなんぞ？
2 試してみた
- 2.1 検証の流れ
- 2.2 結果まとめ
3 【蛇足】気になったから確認したくなったこと
4 まとめ

調べてみた

IBM Documentationではなんと？

terminateコマンドのIBM Documentaionでは以下の様な記載でした。

TERMINATE と CONNECT RESET は両方ともデータベースへの接続を中断しますが、TERMINATE のみがバックエンド・プロセスを終了します。
https://www.ibm.com/docs/ja/db2/11.5.0?topic=commands-terminate　より抜粋

正直どんな動作するかいまいち理解できなかったですが、
・connect reset はデータベースとの接続断のみ
・terminate はプロセスも終了させる
ってことは理解しました。

バックエンドプロセスとはなんぞ？

db2bpのことのようです。
じゃあこいつはなにもの？となったので調べてみました。

コマンド行プロセッサーは、ユーザー・インターフェースとして機能するフロントエンド・プロセス ( Db2 コマンド) と、データベース接続を維持するバックエンド・プロセス (db2bp) の 2 つのプロセスで構成されます。
https://www.ibm.com/docs/ja/db2/11.1.0?topic=clp-command-line-processor-features より抜粋

対話モード（プロンプトが「db2 =>」ってなってるモード）などの、DB2のコマンド行を起動したり、データベースに接続したりするときに動くプロセッサーのようでした。

試してみた

じゃあ実際にどんな感じなの？ってことで検証しました。

検証の流れ

■db2CLP
・db2コマンドで対話モードに移行
・connect to <DB名> でデータベースへ接続
・psコマンドでdb2bpプロセスを確認
・terminate または connect reset で切断
・確認①：対話モードの状態確認
・確認②：psコマンドでdb2bpプロセスを確認

■コマンドライン
・db2 connect to <DB名> でデータベースへ接続
・psコマンドでdb2bpプロセスを確認
・db2 terminate または db2 connect reset で切断
・確認②：psコマンドでdb2bpプロセスを確認

結果まとめ

表にまとめてますが、connect resetは対話モードでもdb2コマンドでもdb2bpプロセスは起動したままでした。

	db2CLP	コマンドライン
connect reset	①対話モード：継続 ②db2bpプロセス：起動	②db2bpプロセス：起動
terminate	①対話モード：終了 ②db2bpプロセス：停止	②db2bpプロセス：停止

DB2を停止させる前にデータベースを切断する場合はterminate の方がよいようです。
connect reset した後に再度接続したところ、初回は１秒程度にかかたのに対し、0.05秒程度でした。作業で接続・切断を繰り返すようなことがあるときはconnect resetの方がよいようです。

【蛇足】気になったから確認したくなったこと

（蛇足１）terminateもconnect rest どちらも実行せずに終わったら？

データベースに接続したままターミナルからログアウト（db2CLPならquit）した場合、データベースとの接続はどうなるのだろう、と試してみました。

# su - db2inst1
$ db2 connect to sampleDB
$ ps -ef | grep db2bp | grep -v grep
db2inst1   1月 1日 1 0 01:00 …　/home/db2inst1/sqllib/bin/db2pd …
$ exit

# ps -ef | grep db2bp | grep -v grep
# 
↑ db2bpプロセスが停止した

<別ターミナルで確認＞
$ db2 list applications 

Auth Id Application   Appl.    Application Id      DB    # of
        Name          Handle                       Name  Agents
------- ------------- -------- ------------------- ----- -------
$
↑ アプリケーション接続も存在しない

案の定ですが、切断されdb2bpプロセスも停止しました。

（蛇足２）db2bpプロセスのタイムアウト

connect resetだけだとdb2bpプロセスが残ることがわかったのですが、これって放置したらタイムアウトするの？って気になりました。
この辺りのタイムアウト値を調べたのですが見つからずでした。

検証したところ、15分以上放置してもプロセスは残ったままでした。
db2CLPも放っておいても切断されないため、ログアウトやterminate、quitしないとプロセスは残り続けるようです。

（蛇足３）バックグランドで処理を実行したまま切断したらどうなるの？

バックエンドプロセスと聞いてはじめに思いついたのがバックグラウンド処理かな？でした。
↓のような感じでバックグラウドでsleepプロシージャをバックグランドで実行し、処理中に切断してみました。

$ db2 connect to sampleDB
$ db2 "call dbms_lock.sleep(10)" &
[1] <PID>
$ db2 terminate       # またはdb2 connect reset

   リターン状況 = 0
DB20000I  SQL コマンドが正常に完了しました。
[1]+ 終了　　　db2 "call dbms_lock.sleep(10)"
　　＃　↑  sleep(10)が完了してから切断された
$

この結果、処理が終わるまでデータベースから切断はされませんでした。
このため、ここで言うバックエンドプロセスはバックグランドでの処理とは別のものだと理解できました。

（蛇足４）su <インスタンス名> -c “db2 connect to <DB>”の時ってどうなるの？

インスタンスじゃなくてもいいのですが、suコマンドの -c でデータベースに接続し、その後selectなど実行したら受け付けるのかな？と思ったので検証しました。
過去にAIXだとうまくいったのでRHELだったらどうだろうと、と試したのですが失敗に終わりました。

# su - db2inst1 -c "db2 connect to sampleDB"
# ps -ef | grep db2bp | grep -v grep
db2inst1   1月 1日 1 0 01:00 …　/home/db2inst1/sqllib/bin/db2pd …
↑ db2bpプロセスは残ってた（5秒程度で停止した）
# su - db2inst1 -c "db2 'select * from syscat.tables'"
SQL10224N データベース接続が存在しません。　SQLSTATE=08003
↑ db2bpは残っていても切断されている様子