按照事务类型分析 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. 实验环境

 

回页首

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

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

1. mkdir C:\db2\eventmon
2. db2 "create event monitor SMEVM for statements write to file ' C:\db2\eventmon '"
3. db2 "set event monitor SMEVM state=1"

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

1. db2evmon -db tradedb -evm SMEVM > C:\db2\eventmon.txt
2. 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语句的参数会被?代替

 

回页首

用 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
		

 

回页首

预处理语句事件

本步的任务是处理从上一节中得到的事件记录文件 eventmon.txt，将其中无关的事件过滤掉。一个事件记录文件往往会包含很多种事件，例如 SQL 语句事件、事务语句事件、数据库连接事件、死锁时间等。由于在本方法中只关心语句事件，因此需要将所有的非语句事件过滤掉。在事件记录文件中，每一个事件的第一行均为一个事件序号和事件名称：

• Connection Header Event ...
• Statement Event ...

SQL 语句和事务语句的事件名称均为“Statement Event…”，因此可以将名称不是“Statement Event…”的事件全部过滤掉，得到语句事件文件。

 

回页首

将事件按照事务分组

本步的任务是将属于同一事务的语句事件聚为一类，将原本无关的语句事件划分为一组事务的实例，每个事务实例中包含其执行的 SQL 语句和事务语句。

图 4. 事务分组

由于数据库系统是支持并发访问的，即不同的应用程序可能同时进行数据库操作，因此捕获到的语句事件可能是多个事务交叉进行的。例如图 4 所示，SQL Event 1，SQL Event 2 和 Commit 1 是由一个应用程序执行的一个事务，而 SQL Event 3-6 和 Commit 2 是另一个应用程序执行的事务。 但是在输出的事件记录文件中，SQL Event 3 在 Commit 1 之前。因此不能简单的通过 Commit/Rollback 语句事件来作为区分事务的边界。

在 DB2 中，事件监测器的事件记录中有两个属性 Appl Id 和 Appl Seq number，这两个属性一起唯一地标识一个事务，每当事务结束（即 COMMIT 或 ROLLBACK 终止工作单元）时，Appl Seq number 就会递增。在本方法中就是通过这两个属性来划分事务的。通过程序或文本处理软件将上一节 中得到的语句事件文件按照 Appl Id 和 Appl Seq number 分类，将这两个值相同的作为一个事务。

清单 3. 事务实例文件 

Transation Instance 1
    AppHandle = 138
    SqlNumber = 0001
    StartTime = 01/12/2007 17:41:14.773360
    EndTime = 01/12/2007 17:41:27.483101
    ExeTime = 12.709741  Second
    SQL 1 in Transation 1
        	SqlStatement = SELECT COUNT(*) FROM ACCOUNTEJB
        	Operation = Open
    		StartTime = 01/12/2007 17:41:14.773360
EndTime = 01/12/2007 17:41:14.993548
    		ExeTime = 0.220188 Second
Operation = Close
        		StartTime = 01/12/2007 17:41:14.995881
        		EndTime = 01/12/2007 17:41:15.086653
        		ExeTime = 0.090772 Second
waitTime = 0.002333 Second
SQL 2 in Transation 1
	SqlStatement = SELECT * FROM ACCOUNTEJB WHERE ACCOUNTID = ?
        	Operation = Open
    		StartTime = 01/12/2007 17:41:19.957377
       		EndTime = 01/12/2007 17:41:19.958135
        		ExeTime = 0.000758 Second
        		waitTime = 4.870724 Second
Operation = Close
StartTime = 01/12/2007 17:41:20.037864
EndTime = 01/12/2007 17:41:20.039575
ExeTime = 0.001711 Second
waitTime = 0.079729 Second
SQL 3 in Transation 1
	SqlStatement =
	Operation = Static Commit
Start Time: 01/12/2007 17:41:27.483077
  		Stop Time:  01/12/2007 17:41:27.483101
  		Exec Time:  0.000024 seconds
Transaction Instance 2
	…
		

 

回页首

将事务实例按照类型聚类

在上一节中已经生成了关于事务实例的执行信息报告，可以从中得到一个事务实例中各个SQL语句的执行时间以及语句之间的等待时间。但是在数据库操作中，往往会反复的执行同一个类型的事务。例如一个网上银行系统，登陆、转账等事务会被不同的应用程序不断的调用。这样就会出现一种现象，即一个数据库系统的事务实例报告中，有很多实例属于同一个事务类型。属于同一个类型的实例是由同一段应用程序代码执行的，但是参数值可能有所不同。如登陆事务，每次登陆的用户账号可能不一致。

为了统计同一类型的事务的性能，还需要将事务实例按照类型划分，然后计算其中的SQL语句的平均、最大最小时间。如何判断哪些事务实例属于同一类型是一个比较复杂的问题。由于在系统运行过程中一个事务类型的逻辑会发生变化，例如登陆事务可能会根据密码正确与否执行不同的SQL语句序列，所以很难全自动的将事务实例分类，最好引入一定的规则来作为判断的依据。常见的分类方法有：

1. 自动匹配法。将执行的SQL语句逐一进行字符串匹配，每一个SQL语句都相同的事务实例被划分为同一类事务。这种方法的优点是简单， 缺点是可能把原本属于同一个类型的事务划分成两类。
2. 将含有SQL语句的应用程序源代码作为划分依据。这样可以较为精确的匹配事务实例，并且由于源程序中包含了程序逻辑，即使一个 类型的事务有不同的逻辑也可以被匹配。
3. 用户输入规则作为划分依据。例如，用户给出规则：将含有“select * from accountejb where accounted=?”语句的事务划分为一类。

按照如上方法划分之后，可以得到如表 2 所示的事务性能数据：

表 2. 事务类型性能报告

 

回页首

综合事务类型信息和应用程序状态，得到事务性能分析报告

在上一节中得到的事务性能数据已经比较详细的反映了一个数据库系统中的事务执行情况，包括该类型事务执行的次数，执行时间，其中每一个 SQL 语句的执行时间以及每两个 SQL 语句之间的等待时间。数据库管理员和开发者可以根据这些数据决定是否需要调优一个事务的性能，以及应该调整哪一个 SQL 语句。

针对某一个 SQL 语句，如果其执行时间比较长，往往有两种可能，一种是其在等待其他数据库操作释放锁，另一种是该 SQL 语句自身比较复杂，需要较多的 CPU 计算资源或 I/O 操作。为了区分是哪一种原因，需要将快照得到的应用程序状态和事务性能数据综合分析。

应用程序的快照中包含应用程序 ID 和快照时间戳。比较快照结果文件和事务实例文件中应用程序 ID 和发生时间相同的记录，可以得到该应用程序在执行一个 SQL 语句时的状态，是 UOW Executing 还是 Lock wait。将应用程序状态的统计信息加入事务性能报告，则可以帮助数据库管理员和开发者找到调优该 SQL 语句的方法。

表 3. 事务性能报告

 

回页首

总结

数据库的事务性能分析比 SQL 语句性能分析粒度大，比调整数据库参数影响的范围小。本文介绍的方法通过利用 DB2 的监测工具和对监测数据的分析，得到关于事务的性能报告，为数据库性能调优提供了更多的信息。在典型的 OLTP 系统中，一个前端的界面操作往往对应后端数据库的一个事务，因此提高事务的性能对于终端用户的体验有较为直接的改善