您需要具體分析使您能夠對 DB2 和 DB2 應用程序進行控制和調優的一些要害性能因素嗎？您希望提前診斷性能和可用性問題嗎？或者您曾在運用 DB2 服務器時遭遇某一問題，但卻無法使用當前的快照判定造成該問題的原因，因此希望使用歷史的監視數據？IBM DB2 Performance Expert 就是一個能夠幫助您完成這些任務的工具。使用場景下面這些使用場景可以展示如何分析和解決各種性能問題，并在 DB2 Performance Expert V2.1 的幫助下完成故障檢修任務：確定索引是否可以改進性能　;;;;;重新回顧排序的性能檢查對表進行重構的需要確保有足夠的 DB2 代理可以處理工作負載解決鎖沖突的問題使用 cache 包中提供的 SQL 語句經常檢查數據庫分析緩沖池監視系統的健康狀況確定是否需要索引DB2 PE 步驟在 System Overview 面板中選擇 Application Summary。圖 1. System Overview在 Application Summary 視圖中選擇適當的應用程序（在本例中是 db2bp.exe）。圖 2. Application Summary在 Application Details 視圖中選擇 SQL Activity。圖 3. Application Details方法圖 3中給出的 SQL Activity 界面顯示了有關應用程序執行的語句的信息，其中包括任務單元（UOW）、光標、讀取的行、選擇的行等等。要判定我們是否需要索引，需要查看讀取的行與選擇的行的比率。;讀取的行與選擇的行讀取的行與選擇的行的比率說明了為了要找到目標記錄行，一共要讀取多少行數據。假如讀取的行數與選擇的行數的比值大于推薦值，那么我們就應該對查詢進行分析，并對可能的索引進行檢查。計算：(讀取的行數) / (選擇的行數)理想值：對于 OLTP 來說，該值為 2 到 3結論DB2 讀取了 99,145 行，但只選擇了 2,000 行。這就是說，它讀取了整個表的內容，卻只選擇了 2,000 行。因此，創建索引可能會提高性能。重新回顧排序性能　　DB2 PE 步驟在 System Overview 面板中選擇 Application Summary。在 Application Summary 視圖中選擇適當的應用程序（在本例中是 db2bp.exe）。在 Application DetailsSelect 視圖中選擇 Sort，如 圖 4 所示。圖 4. Application Details方法Sort 界面中顯示了有關排序操作的具體信息，其中包括所有排序、所有排序時間、排序溢出、hash 連接等。排序溢出這個數字說明了排序時用光排序堆而需要磁盤空間臨時進行存儲的行數。在數據庫或應用程序級，使用這個元素可以計算溢出到磁盤上的排序的百分比。假如這個百分比很高，那么您可能希望通過增加排序堆來調整數據庫的配置。在語句級上，可以使用該元素判定需要大型排序的語句。這些語句可以從減少所需排序數量的其他調優中獲益。在出現排序溢出情況時，可能導致其他開銷，因為假如需要將數據寫入磁盤，那么排序需要一個合并階段，這可能需要更多的 I/O。該元素為一條語句、一個應用程序或訪問一個數據庫的所有應用程序都提供了有用的信息。實質上，要排序的數據都會從緩沖池溢出到 TEMPSPACE 表空間中。;計算：(排序溢出行數) / (總排序行數)理想值：對于非 DSS 型的任務來說，該值為零或接近零的值結論在出現排序溢出的情況時，可能會造成額外的開銷，因為假如要將數據寫入磁盤，那么排序就會需要一個合并階段，這可能需要更多的 I/O。為了避免出現這種溢出，可以增加排序堆的大小，并對查詢進行分析，以確定查詢是否需要使用索引。檢查對表進行重構的需要DB2 PE 步驟在 System Overview 面板中選擇 Statistic Details。圖 5. System Overview在 Statistic Details 視圖中選擇 Tables，并選中 Receive table information。圖 6. Statistic Details　　方法 Statistic Details 中的 Table 視圖給出了有關表的具體信息，其中包括表名、數據庫名、寫入的行數、讀取的行數、溢出的行數、表的文件 id、表的類型、頁面重構等。訪問溢出的行這個數字說明了對該表中溢出行進行存取（讀和寫）的數目。溢出行說明了數據中的碎片情況。假如這個數字很高，那么您可以通過使用 REORG 工具對表進行重構，從而提高表的性能，這會清理數據中的碎片。當一行數據被更新并且不再適合原來寫入的數據頁時，就會出現行溢出的情況。這通常是對 VARCHAR 列進行更新的結果，或者是執行 ALTER TABLE 語句的結果。頁面重構：這個數字說明了需要對一個表進行重構的頁數。對太多頁進行重構可能會導致性能比優化插入方式的性能還要低。您可以使用 REORG TABLE 工具對表進行重構，從而消除數據碎片。您還可以使用 ALTER TABLE 語句的 APPEND 參數來說明插入某個表的所有數據都要附加到該表的末尾，以避免頁面重構問題。在對行進行更新導致該行的長度增加的情況下，雖然頁面可能有足夠的空間來容納新行，但是為了整理這段空間的碎片，可能需要對頁面進行重構。或者，假如頁面中沒有足夠的空間來容納更大的行，就會創建一條溢出記錄。您可以使用固定長度而不是可變長度的列來避免這兩種情況。結論對太多頁進行重構可能會導致性能比優化插入方式的性能還要低。假如您有大量的頁面需要重構，可以使用 REORG TABLE 工具對表進行重構，并消除數據碎片。調優 DB2 代理的個數現在，您的目標是確保有足夠多的 DB2 代理來處理工作負載。DB2 PE 步驟在 System Overview 面板中選擇 Statistic Details。在 Statistic Details 視圖中選擇 Instance Information，如 圖 7 所示。圖 7. Statistic Details方法Statistic Details 中的 Instance Information 視圖給出了有關當前實例的具體信息，其中包括實例名、當前的連接數、已注冊的代理數、已注冊最大代理數、等待令牌的代理數、從緩沖池中分配的代理數、已竊取的代理數等。已注冊的代理該值說明了在正被監視的數據庫治理實例中注冊的代理（協調代理和子代理）個數。您可以使用這個元素來幫助評價最大代理配置參數的設置。已注冊的最大代理該值是從數據庫啟動以來，曾經同時在數據庫治理程序中注冊的代理（協調代理和子代理）的最大個數。您可以使用這個元素來幫助評價最大代理配置參數的設置。等待令牌的代理該值是等待令牌以便在數據庫治理程序中執行事務的代理的個數。您可以使用這個元素來幫助評價最大代理配置參數的設置。已竊取的代理：該值是從應用程序中竊取的代理的次數。當一個與應用程序關聯的空閑代理被重新分配給一個普通的應用程序執行任務時，就會出現代理竊取。可以用該元素來評價應用程序對系統的負載情況。; 結論假如您發現有"等待令牌的代理" 或 "已竊取的代理"，就增大數據庫治理程序中可用代理的個數（MAXAGENTS 和/或 MAX_COORDAGENTS）。解決鎖沖突的問題DB2 PE 步驟在 System Overview 面板中選擇 Locking Conflicts。圖 8. System Overview在 Locking Conflicts 視圖中選擇適當的鎖沖突。圖 9. Locking Conflicts要分析等待某個鎖的應用程序，請選擇 Waiter（等待鎖的）應用程序。圖 10. 鎖沖突的應用程序 —— waiter 應用程序在 Application Details 視圖中選擇 SQL Statement and Package。圖 11. waiter 應用程序的 SQL Statement and Package　　在 Application Details 視圖中選擇 Locks。圖 12. waiter 應用程序的 Locks　　為了對持有鎖的應用程序進行分析，請選擇一個 Holder（持有鎖的） 應用程序。圖 13. 鎖沖突中的應用程序 —— holder 應用程序在 Application Details 視圖中選擇 SQL Statement and Package。;圖 14. holder 應用程序的 SQL Statement and Package在 Application Details 視圖中選擇 Locks。圖 15. holder 應用程序的 Locks　　要找到哪個用戶正在運行 holder 應用程序，可以選擇 Application Details 視圖中的 Identification。圖 16. holder 應用程序的 User Identification方法在 System Overview 面板中選擇 Applications in Lock Conflicts，顯示鎖沖突所設計的所有應用程序，當您選擇 Locking Conflicts時，這些應用程序都與一個非凡的資源相關聯。Application in Lock Conflicts 面板顯示了 holder 和 waiter 應用程序，其中包括應用程序的狀態、鎖的模式、鎖等待時間等。Application Details 視圖中的 SQL Statement and Package 展示了加鎖的應用程序的 SQL 語句。Application Details 視圖中的 Locks 顯示了具體的加鎖信息，例如應用程序所持有的鎖、檢測到的死鎖、鎖升級、等待鎖的代理等。Application Details 視圖中的 Identifcation 顯示了有關正在運行該應用程序的用戶的具體信息。應用程序所持有的鎖：這個數字說明當前的應用程序持有多少個鎖。假如監視信息是在數據庫級上進行的，那么該值就是數據庫中所有應用程序所持有的鎖的總數。假如監視信息是應用程序級的，那么該值就是這個應用程序的所有代理目前持有的鎖的總數。從連接以來等待的鎖：這個數字是應用程序或連接已經等待鎖的次數。在數據庫級上，該值是應用程序在這個數據庫上等待鎖的次數。而在應用程序連接級上，該值是在某個連接請求一個鎖但由于另外一個連接正持有該數據的鎖而必須等待的次數。可以使用該元素計算在數據庫級上等待一個鎖的平均等待時間。這種計算可以在數據庫級或應用程序連接級上進行。假如鎖的平均等待時間很長，那么您應該查看一下持有很多鎖的應用程序；或者假如是這種情況導致等待時間過長，就對該鎖進行升級，從而重點對應用程序進行調優，以改進并發性。假如升級是導致鎖平均等待時間很長的原因，那么可能是 locklist 或 maxlocks 這兩個配置參數值中的一個太小了，也可能這兩個參數值都太小了。鎖升級這個數字說明了某個鎖作為鎖升級的一部分被升級的次數。升級的范圍可以從（一個表中的）許多行鎖到單獨某個表鎖。可以使用這個元素更好地理解死鎖的原因。假如您曾經碰到過有關應用程序執行鎖升級而導致死鎖的情況，那么就可能希望增加鎖內存的數量（locklist）或修改一個應用程序可以請求某個鎖的百分比（maxlocks）。檢測到的死鎖該值是已經出現死鎖的總數。可以用該元素來判定應用程序正出現爭用問題。這些問題可能是由于以下情形引起的：數據庫中正在進行鎖升級。應用程序可能在系統生成足夠多的行鎖時顯式地對表進行鎖定。應用程序可能在綁定時使用了不恰當的隔離級別。為了可以重復讀而鎖定目錄表。應用程序正在對不同的訂單使用相同的鎖，從而導致死鎖。您可以通過判定死鎖是在哪個應用程序（或應用程序進程）上產生的來解決問題。然后可以修改應用程序，使其能夠更好地并行執行。然而，有些應用程序可能不能并行運行。您可以使用連接的時間戳監視元素，判定死鎖的嚴重性。例如，在 5 分鐘之內出現 10 次死鎖就比在 5 小時內出現 10 次死鎖嚴重得多。對上面列出的這些相關元素的描述還提供了其他一些調優建議。;等待鎖的代理：該值說明了等待某個鎖的代理個數。這個元素是應用程序等待某些鎖的百分比的一個指示器。假如這個數字很大，那么您的應用程序可能存在并行問題，您應該對現在持有鎖或者長期持有互斥鎖的應用程序進行分析。結論:檢查 waiter 和 holder 應用程序的 SQL 語句，確定諸如應用程序中頻繁進行提交操作而導致釋放鎖或檢查應用程序使用的隔離級別之類的操作。當執行很多更新時，在更新之前，要在整個事務的持續時間內鎖定整個表。雖然這樣可以只使用一個鎖，同時還可以防止其他鎖妨礙更新操作，但是這樣做會減少數據對于其他用戶的并發能力。經常使用 cache 包中的 SQL 語句進行檢查DB2 PE 步驟在 System Overview 面板中選擇 Statistic Details。在 Statistic Details 視圖中選擇 Dynamic SQL Statements。圖 17. Dynamic SQL Statements下拉滾動條，查看語句的具體資料。圖 18. 語句的具體資料方法Statistic Details 中的 Dynamic SQL Statements 視圖給出了有關 SQL 語句的具體信息，其中包括訪問的數據庫、執行次數、已經過去的執行時間、最差和最佳的預備時間、排序，以及在選中 Receive statement cache information時每條語句占用的 CPU 時間等。通過點擊如 圖 17所示的標題中的 Executions列，可以按照執行次數對 SQL 語句進行降序排列，這樣就可以看到執行最頻繁的 SQL 語句。;執行次數該值是一條 SQL 語句已經被執行的次數。您可以使用該元素來判定系統中執行最頻繁的 SQL 語句。每條語句占用的 CPU 時間這個數字說明了一條 SQL 語句占用的所有 CPU 時間。可以將該元素與“已經過去的執行時間和“每條用戶語句占用的 CPU 時間一起使用，來評價語句的最大花費。最佳預備時間：該值是預備一條特定的 SQL 語句所需要的最短時間。可以用該值來判定編譯耗時的 SQL 語句。最差預備時間：該值是預備一條特定的 SQL 語句所需要的最長時間。可以用該值來判定編譯耗時的 SQL 語句。結論這個執行監視元素可以您幫助判定系統中執行最頻繁的 SQL 語句。在本例中，某個查詢運行了 500 次，并且進行了 500 次排序。這是進行查詢優化的很好的一個選擇，可以檢查排序值，并驗證是否需要創建新的索引。分析緩沖池DB2 PE 步驟在 System Overview 面板中選擇 Buffer Pool Analysis。圖 19. System Overview在 Buffer Analysis 中選擇 File-> Generate new report。圖 20. 緩沖池分析圖 21顯示了緩沖池跟蹤報告的結果。圖 21. 緩沖池跟蹤報告下拉滾動條，查看緩沖池分析的具體內容。圖 22. 緩沖池分析的具體內容方法 上一頁12345678910下一頁 Buffer Pool Analysis 中提供了緩沖池跟蹤報告，它以 HTML 的格式顯示，或者以可選的圖形交互式報告格式顯示。緩沖池命中率這個比率說明了為頁面請求提供服務時，數據庫治理器不需從磁盤裝入頁（即該頁已經在緩沖池中）就能處理頁請求的時間百分比。計算：BPHR = (1 - ((緩沖池數據物理讀 + 緩沖池索引物理讀) /(緩沖池數據邏輯讀 + 緩沖池索引邏輯讀) ) ) * 100%索引命中率這個比率表明了可以在緩沖池中找到的頁面能夠滿足的對索引頁的所有讀請求所占的百分比。計算：IHR = (1 - (緩沖池索引物理讀 / 緩沖池索引邏輯讀) ) ) * 100%數據命中率這個比率說明了可以在緩沖池中找到的頁面能夠滿足的對數據頁的所有讀請求所占的百分比。計算：DHR = (1 - (緩沖池數據物理讀 / 緩沖池數據邏輯讀) ) ) * 100%結論緩沖池命中率大于 80% 被認為是理想的。對于 OLTP 系統來說，該值的理想情況是盡可能接近于 100% （索引命中率更是如此）。要提高緩沖池的命中率，可以增加緩沖池的大小，也可以考慮分配多個緩沖池，可以為每個經常訪問的具有自己的表空間的大型表使用一個緩沖池，也可以為一組小型表使用一個緩沖池。監視系統的健康狀況DB2 PE 步驟在 System Overview 面板中選擇 System Health。圖 23. System overview在導航器中選擇 Data View。圖 24. Data view　　右擊 Open Predefined Data View。圖 25. Open Predefined Data View　　選擇您要監視的數據庫。圖 26. Open Predefined Data View - 選擇數據庫圖 27給出了系統健康狀況視圖的一個例子。圖 27. System Health View方法 System Health 視圖以圖形化的方式在數據視圖中顯示了很多重要的性能計數器。您可以使用預定義的數據視圖，也可以定制自己的數據視圖。結論 System Health 是一個理想的圖形化監視重要性能指標的工具。一旦定義之后，它們就可以用來在 System Overview 面板中顯示系統性能數據。結束語 本系列文章的第1部分對 DB2 Performance Expert 進行了簡介，第2部分又展示了可以用來簡化數據庫調優任務和系統治理工作的具體方法。您可以使用 DB2 PE 來幫助理解影響性能的多個因素，例如索引、緩沖池的使用、語句緩存、鎖、重構要求等等。另外，它還可以用來存儲性能數據，供以后分析，并根據您定義的各種因素產生警報。致謝 非凡感謝 IBM 開發實驗室的 DB2 性能專家 Ute Baumbach，是他審校了這篇文章；感謝 IBM 美國高級技術支持中心的 Cintia Y Ogura，是他為本文提供了教學材料。;