1. 程式人生 > >DB2性能優化- REORG慢的分析

DB2性能優化- REORG慢的分析

數據庫 DB2

什麽是REORG?

我們知道,數據庫中有許多表的存在,而我們可能會經常地需要對表數據進行增刪改等操作,經過一系列更改後,邏輯上連續的數據可能會位於不連續的物理數據頁上,在許多插入操作創建了溢出記錄時尤其如此。按這種方式組織數據時,數據庫管理器必須執行其他讀操作才能訪問順序數據。而在刪除大量行後,也需要執行其他的讀操作。

REORG(重組)表的操作會整理數據碎片來減少浪費的空間,並對行進行重新排序以合並溢出記錄,從而加快數據訪問速度並最終提高查詢性能。

什麽時候需要做REORG?

當數據庫裏某個表中的記錄變化量很大時,則需要在表上做REORG操作來優化數據庫性能。

針對數據庫對象的大量操作,如反復地刪除表,

存儲過程,會引起系統表中數據的頻繁改變,在這種情況下,也要考慮對系統表進行REORG操作。

完整的REORG表的過程

一個完整的REORG表的過程應該是由下面的步驟組成的:

RUNSTATS -> REORGCHK -> REORG -> RUNSTATS -> BINDREBIND

註: 執行此部分命令前需要連接數據庫

此處我們就不對REORG做過多介紹,此次主要分享造成REORG慢的原因。

情景:

某電信網絡發票系統每周五晚上9點開始做數據庫維護,包括REORGRUNSTATREBIND,維護時間需要大約10 個小時,期間會影響系統正常作業。經優化腳本生成詳細維護日誌,檢查維護部分表的

REORG時間過長。整個數據庫大小為500GB

操作系統版本:AIX 7.1

數據庫版本 DB2 V9.7

問題:

當前使用串行REORG的腳本,維護時間需要大約10個小時;

改用並行的REORG的腳本,維護時間仍然需要大約9個小時;

恢復到使用串行的REORG腳本,並觀察系統資源消耗情況,一開始REORG速度很快,但過了不久後,到達了REORG比較慢的表此時使用topas查看系統資源,發現資源消耗下降到一個較低的值,如IO吞吐量:

技術分享圖片

理想的吞吐量



技術分享圖片

當前REORG 慢的吞吐量

分析:

1. 首先查看DB2的診斷日誌(db2diag.log)DB2的管理通知日誌(db2inst1.nfy),均沒有發現報錯;

2. 列舉有可能造成REORG時數據量低的原因

1)表空間參數限制(PREFETCH)讀寫速度

2)操作系統參數瓶頸

3)存儲性能瓶頸

4DB2 Bug

5)數據損壞

下一步計劃方向

-操作系統

-存儲

-DB2

-網絡

-內存

既然我們是負責數據庫的,那就先由數據庫入手,

解決:

1. DB2入手,監控DB2的監控進度

db2pd -d sample -reorg

觀察CurCount字段增長,增長慢的話表示REORG的速度很慢

技術分享圖片


2. 找到正在執行的語句,REORG語句db2 reorg table schema.tablename longlobdata

DB2 9.7 中表重組功能也相應做了擴充,REORG 命令多了 LONGLOBDATA 參數。LONGLOBDATA 參數只對 long LOB 列有效。 默認情況下是不啟用 LONGLOBDATA 的,因為對 long LOB 列的重組很消耗時間。

官方說明請查看以下鏈接:

https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1008kongzh/index.html

我們知道DB2表普通數據和LONG/LOB數據是分開存放的,普通數據只存放有LONG/LOB的數據指針和長度,而且在處理LOB數據都是按記錄逐條解析,所以REORG時按記錄逐條解析就會變得很慢。(如果需要轉換分開存放的 LOB 到內聯的 LOB 就要使用這個參數;當表特別大時,LOB 的重組耗費的時間會較長)

3. 去掉longlobdata, 再次REORG

REORG的時間由原來的6個小時下降到10分鐘,系統吞吐量也恢復到理想狀態。

總結:

這裏列舉一下數據庫出現問題時的初步解決思路——

1. 查看DB2的診斷日誌(db2diag.log)DB2的管理通知日誌(db2inst1.nfy),看是否有報錯,如果有報錯信息,可根據對應的報錯信息了解目前可分析的問題方向。

2. 如果數據庫有報錯,根據報錯信息對可造成此問題的原因做出假設;如果數據庫沒有報錯,則結合系統各項指標分析可能的原因。

3. 對做出的假設做一步步推論,論證所有可能性,並從中找出根本的原因。


DB2性能優化- REORG慢的分析