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
补充1:如果应用状态是UOW Waiting,如何判断它是“等着执行同一事务中下一条SQL”,还是“执行完了一个事务,在等着执行下一个事务”?
在db2 +c "select * from t1 where id = 300" 命令完成之后,抓取应用的snapshot,可以看到UOW stop timestamp为空,说明这个事务目前没有结束,在等着执行下一条SQL
Application Snapshot
Application handle = 196
Application status = UOW Waiting
UOW start timestamp = 2017-03-07 12:57:32.931235
UOW stop timestamp =
UOW completion status =
在第一条commit命令之后,再查看snapshot,会发现UOW stop timestamp不为空了,说明上一个UOW完成,正等待执行下一个事务
UOW start timestamp = 2017-03-07 12:57:32.931235
UOW stop timestamp = 2017-03-07 13:24:47.092684
UOW completion status = Committed - Commit Statement
对于前者,可以加大LOGBUFSZ以避免log buffer full(可以从MON_GET_DATABASE表函数的num_log_buffer_full列查看log buffer full的次数)
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 = 196
Application status = UOW Waiting
UOW start timestamp = 2017-03-07 12:57:32.931235
UOW stop timestamp =
UOW completion status =
在第一条commit命令之后,再查看snapshot,会发现UOW stop timestamp不为空了,说明上一个UOW完成,正等待执行下一个事务
UOW start timestamp = 2017-03-07 12:57: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,这说明需要检查文件系统的布局和存储的配置了。最佳的实践是将容器磁盘和存放日志的磁盘物理上分开。
更多更详细的应用状态介绍,请参考信息中心