事務是數據庫系統中的核心概念之一。應用程序可以通過啟動、提交、回滾等操作來控制一個事務的執行與停止。從應用的角度來看，一個事務往往對應一系列緊密關聯的用戶操作，因此事務的性能是影響用戶體驗的重要因素之一。本文提出了一種方法，利用 DB2 的事件監測器和快照監測器，來分析運行於 DB2 系統的事務的性能。在分析報告中，提供了事務的平均執行時間，執行次數，事務中每一個 SQL 語句的執行時間以及執行 SQL 語句時應用程序的狀態。根據事務的性能分析報告，數據庫管理員和開發者可以更好的進行性能調優。
概述
事務是數據庫系統中的核心概念之一。作為數據庫系統的邏輯工作單元（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 語句和事務語句的事件監測器：
mkdir C:db2eventmon
db2 "create event monitor SMEVM for statements write to file ' C:db2eventmon '"
db2 "set event monitor SMEVM state=1"
其中第一步需要新建一個目錄，本例中給出在 Windows 系統下的命令，生成的目錄需要給數據庫管理員賬號讀寫權限。第二步用 db2 命令行工具[3]創建一個事件監控器，監控語句事件。在 DB2 中有很多種事件可以被監控，應根據需要選擇被監控的事件類型，由於監控本身有比較大的性能開銷，盡量不要選擇無關事件。在這一步中 write to file 子句後面的參數必須是一個存在的並且可寫的目錄，否則在第三步打開監測器的時候會出現錯誤。第三步即通過 db2 命令行工具打開事件監測器。在實驗結束後需要將事件導出成文本形式，以供後面繼續分析：
db2evmon -db tradedb -evm SMEVM > C:db2eventmon.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語句的參數會被?代替
用 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語句序列，所以很難全自動的將事務實例分類，最好引入一定的規則來作為判斷的依據。常見的分類方法有：
自動匹配法。將執行的SQL語句逐一進行字符串匹配，每一個SQL語句都相同的事務實例被劃分為同一類事務。這種方法的優點是簡單， 缺點是可能把原本屬於同一個類型的事務劃分成兩類。
將含有SQL語句的應用程序源代碼作為劃分依據。這樣可以較為精確的匹配事務實例，並且由於源程序中包含了程序邏輯，即使一個 類型的事務有不同的邏輯也可以被匹配。
用戶輸入規則作為劃分依據。例如，用戶給出規則：將含有“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 系統中，一個前端的界面操作往往對應後端數據庫的一個事務，因此提高事務的性能對於終端用戶的體驗有較為直接的改善。
