概述：事務是數據庫系統中的核心概念之一。作為數據庫系統的邏輯工作單元(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. 實驗環境
