概述：事務是數據庫系統中的核心概念之一。作為數據庫系統的邏輯工作單元(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 事物的性能，從上文可以看出是個比較復雜的過程，大家在分析時一定要注意一些小細節，個個環節都要考慮周全，只有這樣才能做到萬無一失，完善了工作。

【編輯推薦】

1. DB2數據庫性能監控的具體步驟
2. 講解IBM DB2數據庫的常用日期操作函數
3. DB2 跨平臺數據庫遷移步驟和注意事項
4. DB2數據庫優化超有用的幾條基本策略