按照事务类型分析 DB2 事物的性能

概述：事务是数据库系统中的核心概念之一。作为数据库系统的逻辑工作单元(Unit of Work)，事务必须具有四个属性，即原子性、一致性、隔离性和持久性(ACID)。数据库系统往往通过锁机制保证事务的隔离性，通过日志机制保证事务的持久性。应用程序可以通过启动、提交、回滚等操作来控制一个事务的执行与停止。从应用的角度来看，一个事务往往对应一系列紧密关联的用户操作，例如银行系统中的存款、转账等。对于用户而言，提交一个事务相当于完成某种交易行为，因此执行一个事务前后跨越的时间是影响用户体验的因素之一。

　　数据库系统的性能是评判数据库系统的重要因素之一，DB2 作为一款成功的数据库产品提供了很多性能调优的特征与功能。一方面 DB2 在数据库管理器层和数据库层提供了大量的可配置参数，通过 db2 get/update dbm cfg和db2 get/update db cfg 可以查看和修改这些参数，并且可以通过控制中心(Control Center, db2cc)中的 Configuration Advisor 来获得优化的配置参数值。另一方面DB2提供了针对查询的优化功能，例如 SQL Explain Facility 可以分析一个 SQL 语句优化后的访问计划(Access Plan)，命令行编辑器(Command Editor)中也提供了访问计划的图形化视图。但是如果想监测和分析一个事务的性能，例如事务的执行时间，事务中每一个 SQL 语句的执行时间，事务中的空闲时间等，则无法简单的通过现有工具来实现。本文将介绍一种分析 DB2 的事务性能的方法，从而帮助数据库设计者和管理员调优数据库性能。

　　事务的逻辑组成

　　一个事务在逻辑上可以由一组 SQL 语句和一个提交/回滚操作组成。在 DB2 中，事务由第一个向数据库发出的 SQL 语句隐式启动，而不需要发出启动事务的命令。所有后续的来自同一个应用程序的数据库读写操作都被归入用一个事务，直到该应用程序发出 COMMIT(提交)或者 ROLLBACK(回滚)语句。ROLLBACK 语句会把这个事务造成的对数据库的所有修改都取消掉。如果应用程序没有发出 COMMIT 或 ROLLBACK 就正常退出了，这个事务将自动提交。如果在事物的执行途中应用程序不正常退出，则将自动回滚。一旦发出了 COMMIT/ROLLBACK 命令，这个命令就无法停止了。由于事务只是由一串 SQL 语句组成的，所以不存在事务的物理表示。

　　在执行一个事务的过程中，数据库和应用程序可能处于不同的状态。例如在图 1所示的事务中，应用程序顺序执行了 3 个 SQL 语句并执行了 COMMIT 语句。在 t0 到 t1 时间内应用程序处于 UOW Executing 状态或者 Lock wait，其中 UOW Executing 状态是指应用程序在执行数据库操作， Lock wait 状态是指应用程序在等待对数据库对象的锁;在 t1 到 t2 时间内处于 UOW Waiting， UOW Waiting 是指应用程序当前没有进行数据库操作。一个事务的执行过程消耗的时间可能用于执行 SQL 语句、执行应用程序代码或等待锁，如果某一类事务的性能比较差，需要分辨是在哪一个方面消耗的时间，从而做出调整。

　　图 1. 事务的逻辑组成

　　分析事务的性能

　　由于事务在数据库中没有一个物理的表示，因此无法直接获得一个事务的监控信息。本文将介绍一种方法通过 DB2 的事件监控器捕获的事件和快照得到的信息来综合分析事务的性能。图 2为这种方法的流程。

　　图 2. 分析事物性能的方法流程图

　　下面将按照流程图中的步骤通过一个实验详细介绍分析事物性能的方法。实验环境为 DB2 V9.1，操作系统为 Windows XP。实验中通过压力测试工具访问一个部署在 WebSphere Application Server 上的 J2EE 应用 Trade6 [4] 来执行一系列的数据库操作，同时捕获数据库的性能数据，随后分析得出数据库系统的事务性能。

　　图 3. 实验环境

#p#

　　用 DB2 事件监测器(Event Monitor)来捕获数据库语句事件

　　首先需要打开 DB2 的事件监控器来捕获数据库中执行的 SQL 语句和事务语句。在 DB2 V8 中，提供了两种监测器来让用户得到系统监测信息，即事件监测器(Event Monitor)和快照监测器(Snapshot Monitor)[1]。这两种监测器在 DB2 V9 中得到了保留 [2]。这两种监测器可以用来捕获不同类型的数据库系统信息，在本方法中将利用它们来获得 SQL 语句、事务语句的执行信息和应用程序的状态信息。由于这些监测器本身会带来一些系统开销，例如在进入和完成 SQL 语句的时候需要加入系统调用，并且需要分配更多的内存来保存监测数据，因此一般情况下这些监测器是禁用的。在启动应用程序之前，需要运行如下命令创建并打开针对 SQL 语句和事务语句的事件监测器：

　　mkdir C:\db2\eventmon

　　db2 “create event monitor SMEVM for statements write to file ‘ C:\db2\eventmon ‘”

　　db2 “set event monitor SMEVM state=1”

　　其中第一步需要新建一个目录，本例中给出在 Windows 系统下的命令，生成的目录需要给数据库管理员账号读写权限。第二步用 db2 命令行工具[3]创建一个事件监控器，监控语句事件。在 DB2 中有很多种事件可以被监控，应根据需要选择被监控的事件类型，由于监控本身有比较大的性能开销，尽量不要选择无关事件。在这一步中 write to file 子句后面的参数必须是一个存在的并且可写的目录，否则在第三步打开监测器的时候会出现错误。第三步即通过 db2 命令行工具打开事件监测器。在实验结束后需要将事件导出成文本形式，以供后面继续分析：

　　db2evmon -db tradedb -evm SMEVM > C:\db2\eventmon.txt

　　db2 “set event monitor SMEVM state=0”

　　最后一步用于关闭事件监测器。下面是一个导出的文本文件的例子，部分无关信息被省略。

　　清单 1. 语句事件文件

————————————————————————–
EVENT LOG HEADER
Event Monitor name: SMEVM
…
Server instance name: db2inst1
————————————————————————–

————————————————————————–
Database Name: TRADEDB
…
————————————————————————–

4) Statement Event …
Appl Handle: 7
Appl Id: *LOCAL.db2inst1.070109081142
Appl Seq number: 00078

Record is the result of a flush: FALSE
——————————————-
Operation: Static Commit
Package :
Consistency Token :
Package Version ID :
Cursor :
Cursor was blocking: FALSE
——————————————-
Start Time: 01/09/2007 01:19:48.601550
Stop Time: 01/09/2007 01:19:48.601574
Exec Time: 0.000024 seconds
Number of Agents created: 1
User CPU: 0.000000 seconds
System CPU: 0.000000 seconds
Fetch Count: 0
Sorts: 0
Total sort time: 0
Sort overflows: 0
Rows read: 0
Rows written: 0
Internal rows deleted: 0
Internal rows updated: 0
Internal rows inserted: 0
Bufferpool data logical reads: 0
Bufferpool data physical reads: 0
Bufferpool temporary data logical reads: 0
Bufferpool temporary data physical reads: 0
Bufferpool index logical reads: 0
Bufferpool index physical reads: 0
Bufferpool temporary index logical reads: 0
Bufferpool temporary index physical reads: 0
Bufferpool xda logical page reads: 0
Bufferpool xda physical page reads: 0
Bufferpool temporary xda logical page reads: 0
Bufferpool temporary xda physical page reads: 0
SQLCA:
sqlcode: 0
sqlstate: 00000
…
48) Statement Event …
Appl Handle: 138
Appl Id: 127.0.0.1.8096.070109091708
Appl Seq number: 00024

Record is the result of a flush: FALSE
——————————————-
Type : Dynamic
Operation: Open
Section : 16
Creator : NULLID
Package : SYSSN200
Consistency Token : SYSLVL01
Package Version ID :
Cursor : SQL_CURSN200C16
Cursor was blocking: FALSE
Text : select * from quoteejb q where q.symbol=? For Update
——————————————-
Start Time: 01/09/2007 01:23:05.894949
Stop Time: 01/09/2007 01:23:05.894970
…
SQLCA:
sqlcode: 0
sqlstate: 00000

　　可以看出，该文件由一组事件记录组成，每一条记录有一个唯一的编号和一组属性，如应用程序句柄，操作类型，开始时间，结束时间等。主要内容如表 1所示。

表 1. 事件记录属性列表
属性名称意义值/范围备注
Appl Handle 应用程序句柄整形
Appl Id 应用程序ID 字符串
Appl Seq number 应用程序序号整形每当工作单元结束（即 COMMIT 或 ROLLBACK 终止工作单元）时，此标识就会递增。appl_id 与 sequence_no 一起唯一地标识一个事务。
Operation 操作类型 Static Commit Rollback Open Close Prepare Describe Execute Static Commit 和 Rollback 是事务语句的事件。一个 Select 语句一般会对应 Prepare, Describe, Open, Close 四个事件。如果是已经执行过的Select语句，可能只有Open和Close事件。一个 Update/Delete/Insert 语句一般对应 Prepare, Describe, Execute 三个事件。
Start Time 操作开始时间时间戳
Stop Time 操作结束时间时间戳
Text SQL语句内容字符串动态SQL语句的参数会被?代替

#p#

　　用 DB2 快照(Snapshot)获得应用程序的状态

　　如前所述，在应用程序执行的过程中可能处于不同的状态，因此需要同时打开DB2快照监测器捕获应用程序状态信息。打开DB2快照的命令如下：

　　db2 update dbm cfg using DFT_MON_SORT ON

　　db2 update dbm cfg using DFT_MON_LOCK ON

　　db2 update dbm cfg using DFT_MON_TABLE ON

　　db2 update dbm cfg using DFT_MON_STMT ON

　　db2 update dbm cfg using DFT_MON_UOW ON

　　db2 update dbm cfg using DFT_MON_TIMESTAMP ON

　　这些快照监测器默认设置是关闭的，可以通过如下命令查看其状态：db2 get dbm cfg。在实验结束后，如需要关闭快照监测器，可使用 db2 update 命令关闭，将打开命令中的 ON 改为 OFF 即可。

　　与事件监测器不同，快照监测器不是自动捕获信息的，而是需要通过用户发出快照命令才执行。因此在实验过程中，需要不断的发出针对应用程序的快照命令，并将结果保存到文件中。执行快照的命令如下：

　　db2 get snapshot for applications on TRADEDB >> application.snapshot.txt

　　其中TRADEDB为数据库名称。下面是一个应用程序的快照结果，部分无关信息被省略。

　　清单 2. 快照监测器输出结果

Application Snapshot

Application handle = 26
Application status = UOW Waiting
Status change time = 01/09/2007 00:28:08.472486
Application code page = 1208
Application country/region code = 0
DUOW correlation token = N00A1405.O0B0.070412045634
Application name = db2jcc_application
Application ID = N00A1405.O0B0.070412045634
…

Connection request start timestamp = 01/08/2007 23:56:31.937719
Connect request completion timestamp = 01/08/2007 23:56:31.938028
Application idle time = 10 minutes 9 seconds
CONNECT Authorization ID = DB2INST1
…
Last reset timestamp =
Snapshot timestamp = 01/09/2007 00:38:17.953083

按照事务类型分析 DB2 事物的性能，从上文可以看出是个比较复杂的过程，大家在分析时一定要注意一些小细节，个个环节都要考虑周全，只有这样才能做到万无一失，完善了工作。

【编辑推荐】