DB2 效能優化快速入門

2021-06-28 23:37:29 字數 3316 閱讀 4813

db2 效能優化是一件較為複雜的綜合性的工作 , 需要對問題的根源作全方位的探索和思考。同時也需要較深厚的資料庫管理經驗與優化知識。這對於初學者來說可能有些勉為其難。但是在很多情況下,隨著 db2 資料庫中的資料量的不斷增長或者使用者數的激增,資料庫系統的效能會顯著下降,而此時快速定位效能上的瓶頸則至關重要。下面簡要地介紹一下 db2 的調優的一些因素和工具,以及一些原理,使初學者對效能優化能夠有乙個大致的了解。

db2 的效能優化可以從三個方面分析:記憶體,cpu 和 i/o 。

在記憶體方面,主要是考慮緩衝池 (bufferpool) 的使用。緩衝池是一片用來緩衝從磁碟上讀取的資料和索引的記憶體區域,這些資料和索引資訊在緩衝池中進行運算後最終還要寫回磁碟。緩衝池的頁面大小有四種 (4k,8k,16k,32k),分別對應四種不同頁面大小的表空間。緩衝池的大小決定了能夠從磁碟上緩衝資料的容量大小。當然緩衝池也不是越大越好,緩衝池過大可能會導致連線資料庫的時間過長,因為在連線資料庫時要為資料庫的緩衝池分配記憶體空間。可以通過計算緩衝池的命中率來評估緩衝池的使用效率:緩衝池命中率 =(1-(( 資料物理讀 + 索引物理讀 )/( 資料邏輯讀 + 索引邏輯讀 ))) *100%,緩衝池命中率越大說明緩衝池的使用效率高。緩衝池命中率太**明緩衝池太小應當調大。其中的資料物理讀,索引物理讀以及資料邏輯讀和索引邏輯讀都可以從緩衝池的快照中獲取。

在記憶體方面要考慮的另外幾個重要因素是排序堆 (sortheap),鎖列表 (locklist), 日誌緩衝區 (logbufsz) 。排序堆在查詢結果帶有排序選項而沒有相關索引對應時將會被使用,排序堆太小會產生排序溢位 (overflowed), 那些在排序堆中裝不下的排序資料將會溢位到乙個臨時表中,這會使效能下降。與 sortheap 引數相關的是 sheapthres_shr 和 sheapthres,sheapthres_shr 限制了乙個資料庫中共享排序的最大記憶體,sheapthres 限制了私有排序的最大記憶體。 locklist 指的是乙個資料庫中用來存放鎖的記憶體空間,當這個引數設得過小會導致在鎖用光這部分資源後導致鎖公升級(即多個行鎖轉化為乙個表鎖來釋放出更多的資源)。這會導致系統的並行性下降,很多應用連線出現掛起,使得系統的效能衰退。所以盡可能調大 locklist 引數,這裡需要指出 locklist 指的並不是鎖的個數,而是以資料庫頁為單位的一片記憶體區域(在 32 位系統中每個鎖需要 96 個位元組,鎖上加鎖的話每個鎖則需 48 個位元組。在 64 位系統中每個鎖需要 128 個位元組,鎖上加鎖的話每個鎖則需 64 個位元組)。與 locklist 引數對應的是 maxlocks 引數,maxlocks 定義的是乙個百分數,它指定了乙個應用程式所能占用的最大的鎖空間佔 locklist 的比例。日誌緩衝區 (logbufsz) 指的是日誌在寫到磁碟以前用於緩衝的一片記憶體空間,這樣可以減少寫日誌帶來的過多的 i/o 。

從版本 9 以後 db2 推出了乙個新特性自調節記憶體管理器 (stmm: self tuning memory manager), 這個特性使得很多記憶體引數如前面所述的 sortheap,locklist,logbufsz 等進行自動調節,當資料庫引數 self_tuning_mem 設為 on, 這些引數設為 automatic 即可以進行自動調整。這樣可以節省很多人工調整的時間。

關於 cpu 因素首先是考慮 db2 優化器 (optimizer) 對訪問計畫 (access plan) 的分析與優化。一般來說,一條 sql 在執行時首先會被解析,然後進行語義分析,進而重寫 sql, 優化器會對重寫過的 sql 進行基於成本的分析最終選擇最有效的訪問計畫。最終生成可執行**(執行計畫)來執行這條語句。查詢訪問計畫的工具有很多,既有圖形化工具 visual explain,也有命令 db2exfmt 來格式化解釋表 (explain tables) 中的資料生成 access plan 。還有命令 db2expln 查詢 access plan 。

在 db2 裡的優化級別分為九級,預設是第五級,級別越高優化器分析得程度越深。這個級別有資料庫配置引數 dft_queryopt 決定。並不是級別設得越高效能越好,因為對於一些較為簡單的 sql 語句,如果優化級別過高那麼花在優化 sql 上的時間就會過長,而執行時間相對來說很短,有些得不償失。在選擇訪問計畫時,索引掃瞄的效率往往會比表掃瞄要高,所以索引的優化也是值得注意的。正確的建立索引會使查詢效能大幅度的提高。

在 db2 中連線 (join) 分為三種:巢狀迴圈連線 (nest-loop join), 合併連線 (merge-join), 雜湊表連線 (hash-join) 。一般來說效率最低的是巢狀迴圈連線,這種連線採用的是笛卡兒集,進行多次迴圈遍歷得到結果。而合併連線和雜湊表連線只進行一次迴圈遍歷,相對來說效率較高。其中雜湊表連線可以採用多個等式做為條件而合併連線只能採用單個等式作為條件。但是在有索引掃瞄的情況下巢狀迴圈連線效率則更高。當優化級別等於零時,連線只能採用巢狀迴圈連線, 當優化級別大於等於 1 時,連線可以採用合併連線。當優化級別大於 5 時連線可以採用雜湊表連線。雜湊表連線要求 sortheap 比較大,因為要為生成雜湊表準備空間。

在考慮 cpu 因素時還要考慮 cpuspeed 這個引數,這個引數標明了 cpu 的執行速度,它會幫助優化器評估最好的訪問計畫。一般來說這個引數設為 -1,優化器將自動計算 cpu 的速度。另外運用多分割槽的特性可以把乙個資料庫分布到多台機器上,這樣可以充分利用多台機器的 cpu 的資源對應用程式的事務進行並行處理,從而提高資料庫的效能。

關於 i/o 因素要考慮以下幾個方面:首先是磁碟的 i/o, 為了能夠最大化磁碟的 i/o 可以把資料,索引以及日誌分別放在不同的硬碟上。因為在乙個事務中資料和索引可能需要同時訪問,而在事務提交時,資料和日誌要同時寫入磁碟,而且有可能索引也要同步維護,所以將它們放在不同的硬碟上可以使它們的讀寫並行執行,從而不致使磁碟成為瓶頸。同時選擇資料庫管理表空間 (dms) 要比系統管理表空間 (sms) 效能要好,因為讀寫 sms 需要經過作業系統的 cache 再到緩衝池,而可以採用裸裝置的 dms 則不需要。但是 dms 相對 sms 來說維護起來較麻煩。

其次要考慮的是日誌檔案的大小,當資料庫在寫事務日誌時當乙個日誌檔案寫滿後會轉向另外乙個日誌檔案,這種日誌檔案的切換會造成作業系統上的開銷。所以應當盡量將日誌檔案大小(logfilsiz)設得大一些,這樣可以減少日誌檔案切換的次數。但是日誌檔案過大難免會造成一些空間的浪費。

同時也要考慮到隔離級別的因素,在 db2 中隔離級別分成 4 級:可重複的讀,讀穩定性,游標穩定性和未提交的讀。這四種級別逐個降低。越高的隔離級別越能保證資料完整性,但卻會降低併發性,所以應當綜合權衡後做出決定。隔離級別可以通過如下命令來改變:

change isolation to=cs|rr|rs|ur

在連線方面還要考慮到**和連線的關係,這也會影響到資料庫的併發性,具體資訊可以參考資源部分。

最後要考慮的還是關於多分割槽的特性。在多分割槽資料庫中,乙個請求首先傳到協調分割槽,然後由協調分割槽將請求細分成多個部分傳送到其他分割槽,這樣資料可以在各個分割槽進行並行讀寫,實現 i/o 最大化。

參考原文:

DB2效能優化聖經 優化準則

在制定乙個效能優化總體方案時,應當考慮下列準則 1.牢記縮減回報定律 最大的效能收益通常來自最初的努力。以後的修改一般只產生越來越小的效益,並且需要付出更多的努力。2.不要為了優化而優化 優化是為了解除一致的約束。如果優化資源不是引起效能問題的主要原因,那麼除非接觸了主要約束,否則這種優化對響應時間...

Db2效能優化 表分割槽

前言 實驗環境 os 名稱 microsoft windows server 2008 r2 enterprise os 版本 6.1.7601 service pack 1 build 7601 product name db2 enterprise server edition license ...

db2效能問題排查與優化

最近在做公司產品的排查性穩定性測試中,遇到乙個小問題。在更換的資料初時化資料後,由加壓機鏈結應用伺服器變的非常緩慢。由此,判斷為以下幾種情況,再在與研發一起分析完was6.0的伺服器日誌後,決定對db2引數進行調整。1 情況一 區域網資料報傳輸問題,經過對區域網內包的監控沒有發現異常情況排除情況一。...