《讓DB2跑得更快——DB2內部解析與效能優化》

DB2資料庫領域的精彩強音，DB2技巧精髓的熱心分享，資深資料庫專家牛新莊、幹毅民、成孜論、唐志剛聯袂推薦！

本書作者在DB2China資料庫論壇擔任熱點討論版塊版主，主持多次熱點討論以及專家現場診斷，擅長DB2資料庫及相關產品的效能調優及故障分析，對DB2技能及實踐經驗有多年積累，並且近年來與多位業界專家一直在積極推動DB2領域的技術交流，真正理解DB2技術人員真正的需求與痛楚，是DB2系統知識及技巧精髓的熱心分享者及貢獻者。

作者本人出於對DB2的狂熱與追求，通過長期的凝練與匯聚，將DB2知識系統化，把DB2資料庫調優技巧的精髓熱心地分享給廣大讀者，並且憑藉深厚而紮實的理論及經驗，對

單看“內部解析”四個字，就已經能體現本書的寶貴价值，在“內部解析”的基礎上進行“效能優化”，定會讓您的DB2“跑得更快”！

內容提要

本書以優化為主題，根據資料庫內部原理將DB2資料庫對SQL語句及其他操作的內部機制進行詳細剖析，並將RDS、DMS、IXM、BPS等DB2內部元件不為人知的一面展現給大家，以期做到對資料庫的調優過程知其然並知其所以然。同時本書結合響應時間與資源瓶頸兩種效能問題的現象，對資料庫調優的整體思路進行詳細講解，對原來老式的調優思路進行整理和改動，結合了DB2 V10.1版本的一些新的監控工具及特性，以一種全新的方式闡述

本書結構

全書分為5大篇共13章。第1篇主要對效能問題的定義、影響效能問題的因素、DB2的整體元件結構，以及對於各種型別語句的處理機制進行詳細的探討；第2篇主要針對DB2提供的各個監控工具進行闡述，並提供了一些監控建議；第3篇主要闡述DB2的內部執行機制及各個元件的原理；第4篇包含DB2中內部工具的優化與執行機制，以及DB2在各個平臺中需要注意的效能引數；第5篇對效能優化思路進行了概括性的總結。

第1篇效能定義及整體架構第 1 章主要對效能問題的目標進行了闡述和定義，並描述了可能影響各個工作負載的特徵，以及可能對其產生效能影響的因素。第2章對DB2的體系結構進行了基本介紹，並描述了DB2各個元件處理SQL語句的基本原理與機制。

第2篇效能監控工具及監控技巧第3章按照監控特性對DB2提供的監控工具進行了基本介紹，並介紹了一些基本的監控技巧。

第3篇效能分析及內部原理剖析第4章對優化器的原理進行了探討，闡述了優化器的重寫機制、優化原理及編譯原理，並介紹瞭如何檢查優化器的估算結果的兩種方法。第5章介紹瞭解決優化器編譯問題的的7種性能優化武器，以及何時且如何才能有效地使用這些武器解決實際問題。第6章描述了為了避免效能問題應該如何對資料庫表及索引進行有效設計，針對合適的場景使用適合的技術才能更有效地避免效能問題的發生。第7章詳細描述了DB2資料庫的I/O原理，I/O效能通常是資料庫執行過程中最為耗時的一環，本章詳細介紹了DB2相關I/O情景，以及如何有效地提高I/O效能。第8章詳細介紹了DB2中各個記憶體池的分配以及作用，並講述了怎樣定位及修復記憶體洩露的方法。第9章對資料庫的物理結構進行了詳細剖析，並講解了各種情況下物理結構對於資料庫效能的負面影響及避免方法。第10章對DB2中鎖及latch等待事件進行了描述與分析，並分享部分等待事件解決案例及心得。

第4篇實用工具調優及作業系統優化第11章講述了backup、restore、export、import、load、reorg、runstats等DB2提供的多種實用工具的執行原理以及效能調優方法。第12章介紹了AIX及Windows平臺上CPU、記憶體、磁碟I/O及網路等方面的相關優化引數。

第5篇效能分析思路及優化總結第13章對效能分析思路進行了歸納與總結，並按照資源佔用問題及響應時間緩慢的問題對資料庫效能問題提供了整體分析的思路與解決方案。

精彩內容

SQL語句分類

一個SQL請求傳送給DB2例項時，DB2例項會建立一個代理執行緒（db2agent）為該語句服務，db2agent首先呼叫RDS元件對該語句進行優化並編譯，然後傳送給RTI元件執行這些編譯後的section，並呼叫DMS元件申請對於表或索引的訪問要求，DMS在接受資料讀取請求後，從緩衝池中讀取資料並將結果集返回給RDS元件。RDS元件將DMS返回的結果集進行最終處理（比如排序等操作），處理完成後返回給客戶端。

RDS元件和DMS元件都會執行評估SQL謂詞的操作並過濾部分資料。但從效能角度來講，相對於RDS而言，DMS對效能更為重要，因為DMS可以提前過濾掉無效的資料，避免RDS重複處理無效資料。

盛水的木桶是由許多塊木板箍成的，盛水量也是由這些木板共同決定的。若其中一塊木板很短，則此木桶的盛水量就被短板所限制。這塊短板就成了這個木桶盛水量的“限制因素”（或稱“短板效應”）。而DB2資料庫也是由各個元件組成的，當我們面對一個數據庫效能問題時，首先要了解最短的木板到底發生在哪個元件上，才能有針對性地解決效能問題。

我們開始面對一個數據庫效能問題時，首先要弄明白當前系統究竟發生了什麼，是什麼動作引起了效能問題，進而根據動作判斷引發效能問題的瓶頸。就像之前提到的水管，我們首先要了解當前的水量，進而判斷水管中的瓶頸。

瞭解DB2的機制前，我們首先來討論下SQL語句的分類。SQL語句主要分為以下5類。

（1）資料查詢語言（DQL）：其語句也稱為“資料檢索語句”，用以從表中獲得資料，確定資料怎樣由應用程式給出。保留字SELECT是DQL（也是所有SQL）用得最多的動詞，其他DQL常用的保留字有WHERE、ORDER BY、GROUP BY和HAVING。這些DQL保留字常與其他型別的SQL語句一起使用。

（2）資料操作語言（DML）：其語句包括動詞INSERT、UPDATE和DELETE。它們分別用於新增、修改和刪除表中的行。也稱為動作查詢語言。

（3）事務處理語言（TPL）：它的語句能確保被DML語句影響的表的所有行得以及時更新。TPL語句包括COMMIT和ROLLBACK。

（4）資料控制語言（DCL）：它的語句通過GRANT或REVOKE獲得許可，確定單個使用者和使用者組對資料庫物件的訪問。某些RDBMS可用GRANT或REVOKE控制對錶單個列的訪問。

（5）資料定義語言（DDL）：其語句可在資料庫中建立新表（CREAT TABLE）、為表加入索引等。DDL包括許多與資料庫目錄中獲得資料有關的保留字。它也是動作查詢的一部分。

一條Select語句叢生到死的處理過程

以一條普通的“select * from table order by …”語句為例。圖2-21中顯示為該語句在資料庫中各個元件之間的處理過程，各個步驟分別代表：

（1）select語句通過網路傳送給代理執行緒；

（2）SQL語句經過重寫及編譯，將編譯結果存放在Package cache中；

（3）協調代理執行緒（coordinating agent）按照執行計劃執行語句，將預取請求傳送給預取執行緒；

（4）預取執行緒在容器間並行執行非同步I/O，將資料頁放入緩衝池中（如果沒有發生預取，則略過第4步）；

（5）將容器中的資料頁放入緩衝池中；

（6）將需要排序的資料移動到排序堆中；

（7）如果排序堆不夠，則將排序資料放到臨時表空間中；

（8）排序完成的行被子代理送回客戶端。

執行過程中要注意以下幾個細節，這些細節也是影響效能的關鍵因素：

（1）SQL語句的執行計劃可能會極端影響效能；

（2）如果發生預取，預取執行緒會從磁碟中取出連續的資料頁，此時代理執行緒處於等待狀態；

（3）如果沒發生預取，則協調代理會並行地從磁碟中取出資料。

到此為止，一條select語句就徹底執行完了，我們可以看到，一條最基本的查詢語句在DB2中經過各個元件的協調，歷經了8個步驟最終完成。在遇到一個性能問題時，任何一個環節都可能成為效能瓶頸。

索引分裂
當事務向索引中最後一個葉子節點資料塊上插入一條大於或等於（ROWID大於最大值的ROWID）資料塊上最大值的資料，且該資料塊上不存在其他未提交事務時，如果沒有足夠空間，就會發生 9-1 分裂，即分裂時，絕大部分資料保留在原有節點資料塊上，僅少量資料被轉移到新資料塊上。假設當前有一個根節點及PAGE1、PAGE2、PAGE3三個葉子節點，如圖7-24所示。當葉子節點PAGE1或者PAGE3進行分裂時，都會選擇9-1分裂方式。

向索引中插入大於、等於最大值的資料時，PCTFREE會被忽略。如果葉子節點分裂導致枝節點也分裂，枝節點的分裂比例和葉子節點的分裂比例是相同的。

實際上，無論是9-1分裂還是5-5分裂，其目的都是減少分裂，因為索引分裂是一個代價高昂的操作。發生9-1分裂時，通常索引的鍵值是遞增的，且表上的主要操作是插入操作且事務併發量比較低的情況，應保證新的資料塊上有最大的空閒空間插入新值，以減少了分裂的發生。發生5-5分裂時，通常表上的併發事務較多，且插入、刪除的資料比較分散，因此需要保持分裂的新、老資料塊上有相當的空閒空間以容納新事務、新資料。當我們持續不斷地對葉子節點進行插入操作時，就會引發葉子節點分裂，可以使用db2pd工具進行檢視。

記憶體洩露檢測

尋找記憶體洩漏時，這部分的輸出結果通常沒有用處。我們不關心記憶體塊從哪分配，只關心相關記憶體塊耗費了多少記憶體。所以只需搜尋“Memory blocks sorted”關鍵字，每個記憶體池中都會有這樣的一部分，例如DBMS記憶體集中的kernelheap部分：

輸出結果已經按照大小進行了排序，我們可以很容易地看到在該記憶體堆中消耗最大的記憶體塊。此時需要關注兩件事情，分配的整體大小及記憶體塊分配的頻率。“TotalCount”的數值是我們在檢測記憶體洩漏中最關注的事情，“TotalCount”通常來說應該非常小，或者與當前執行緒數成比例（除了基於快取的記憶體池，例如package cache、bufferpool等），在上面的例子中，可以看到sqlowlst.C的第566行分配了36次記憶體塊，通過db2pd -edus檢視當前資料庫內的執行緒，可以看到每個執行緒都會對應一次分配。假設發現當前分配的次數遠遠超過當前資料庫內的執行緒數量，則可以說明當執行緒中斷時資料庫沒有釋放對應的記憶體。這樣的話，就可以繼續檢視記憶體洩漏是由哪部分元件引起的。

轉載於:https://blog.51cto.com/bvbroadview/1310875