db2 应用的最常见状态（转）

db2 的应用最常见的状态为UOW Executing, UOW Waiting,  Connect Completed等，这里做一个简单的介绍。

UOW全称是Unit Of Work, 可以认为是事务。

Connect Completed:           应用连库成功了。
UOW Executing:               应用正在执行某个SQL语句
UOW Waiting:                 应用执行完一条SQL了，在等着执行同一事务中下一条SQL。 或者执行完了一个事务，在等着执行下一个事务。
Commit Active:               在做commit操作
Lock Wait:                   在等其他应用hold住的锁
Rollback Active:             在做rollback操作
Pending Remote Quest:        DPF环境下才有，在等其他节点的响应
Federated request pending:   联邦环境才有，在等联邦数据源的返回结果

下面的示例中，应用连接到数据库，完成了两个事务，并断开与数据库的连接，分别指示了各个时间的DB2应用的状态

$ db2 connect to sample                                 <--Database Connect Pending

<-- Connect Completed

$ db2 +c "update t1 set id = 200 where id = 100"        <--Uow Executing

<--Uow Waiting

$ db2 +c "insert into t1 values(300)"                   <--Uow Executing

<--Uow Waiting

$ db2 +c "select * from t1 where id = 300"              <--Uow Executing

<--Uow Waiting

$ db2 commit                                            <--Commit Active

<--Uow Waiting

$ db2 +c "insert into t2 values(200)"                   <--Uow Executing

<--Uow Waiting

$ db2 commit                                            <--Commit Active

<--Uow Waiting

$ db2 terminate                                         <--Database Disconnect Pending

补充解释1：

如果应用状态是UOW Waiting，如何判断它是“等着执行同一事务中下一条SQL”，还是“执行完了一个事务，在等着执行下一个事务”？

在db2 +c "select * from t1 where id = 300" 命令完成之后，抓取应用的snapshot，可以看到UOW stop timestamp为空，说明这个事务目前没有结束，在等着执行下一条SQL.

            Application Snapshot
Application handle                         =
Application status                         = UOW Waiting

UOW start timestamp                        = -- ::32.931235
UOW stop timestamp                         =
UOW completion status                      =

在第一条commit命令之后，再查看snapshot，会发现UOW stop timestamp不为空了，说明上一个UOW完成，正等待执行下一个事务

UOW start timestamp                        = -- ::32.931235
UOW stop timestamp                         = 2017-03-07 13:24:47.092684
UOW completion status                      = Committed - Commit Statement

补充解释2：

有时应用的状态是Commit Active，Commit Active是指应用正在做提交操作，当db2loggw把日志记录写到磁盘上之后，这个状态就会消失。

如果一个应用保持CommitActive状态太久，比如好几秒钟，这说明有性能问题，原因要么是db2loggw太忙，要么是日志所在磁盘的IO太繁忙。

对于前者，可以加大LOGBUFSZ以避免log buffer full（可以从MON_GET_DATABASE表函数的num_log_buffer_full列查看log buffer full的次数）

对于后者，可以通过'iostat -DT 1'命令查看avgserv列，如果超过3 ms，这说明需要检查文件系统的布局和存储的配置了。最佳的实践是将容器磁盘和存放日志的磁盘物理上分开。

补充解释3：

事务占用日志情况

可以通过db2pd -db <dbname> -transactions 查看每个事务正在使用的日志的情况。

查看每个应用使用的日志大小

db2 "select application_handle,UOW_LOG_SPACE_USED,UOW_START_TIME FROM TABLE(MON_GET_UNIT_OF_WORK(NULL,-1)) order by UOW_LOG_SPACE_USED" 

查看数据库整体日志的作用率：

https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.rtn.doc/doc/r0060791.html

重点关注的参数有：
ApplHandl
The application handle of the transaction.
SpaceReserved
The amount of log space that is reserved for the transaction.
LogSpace
The total log space that is required for the transaction, including the used space and the reserved space for compensation log records.