您好,登錄后才能下訂單哦!
什么是REORG?
我們知道,數(shù)據(jù)庫中有許多表的存在,而我們可能會經(jīng)常地需要對表數(shù)據(jù)進(jìn)行增刪改等操作,經(jīng)過一系列更改后,邏輯上連續(xù)的數(shù)據(jù)可能會位于不連續(xù)的物理數(shù)據(jù)頁上,在許多插入操作創(chuàng)建了溢出記錄時尤其如此。按這種方式組織數(shù)據(jù)時,數(shù)據(jù)庫管理器必須執(zhí)行其他讀操作才能訪問順序數(shù)據(jù)。而在刪除大量行后,也需要執(zhí)行其他的讀操作。
REORG(重組)表的操作會整理數(shù)據(jù)碎片來減少浪費(fèi)的空間,并對行進(jìn)行重新排序以合并溢出記錄,從而加快數(shù)據(jù)訪問速度并最終提高查詢性能。
什么時候需要做REORG?
當(dāng)數(shù)據(jù)庫里某個表中的記錄變化量很大時,則需要在表上做REORG操作來優(yōu)化數(shù)據(jù)庫性能。
針對數(shù)據(jù)庫對象的大量操作,如反復(fù)地刪除表,存儲過程,會引起系統(tǒng)表中數(shù)據(jù)的頻繁改變,在這種情況下,也要考慮對系統(tǒng)表進(jìn)行REORG操作。
完整的REORG表的過程
一個完整的REORG表的過程應(yīng)該是由下面的步驟組成的:
RUNSTATS -> REORGCHK -> REORG -> RUNSTATS -> BIND或REBIND
注: 執(zhí)行此部分命令前需要連接數(shù)據(jù)庫
此處我們就不對REORG做過多介紹,此次主要分享造成REORG慢的原因。
情景:
某電信網(wǎng)絡(luò)發(fā)票系統(tǒng)每周五晚上9點開始做數(shù)據(jù)庫維護(hù),包括REORG,RUNSTAT,REBIND,維護(hù)時間需要大約10 個小時,期間會影響系統(tǒng)正常作業(yè)。經(jīng)優(yōu)化腳本生成詳細(xì)維護(hù)日志,檢查維護(hù)部分表的REORG時間過長。整個數(shù)據(jù)庫大小為500GB。
操作系統(tǒng)版本:AIX 7.1
數(shù)據(jù)庫版本 :DB2 V9.7
問題:
當(dāng)前使用串行REORG的腳本,維護(hù)時間需要大約10個小時;
改用并行的REORG的腳本,維護(hù)時間仍然需要大約9個小時;
恢復(fù)到使用串行的REORG腳本,并觀察系統(tǒng)資源消耗情況,一開始REORG速度很快,但過了不久后,到達(dá)了REORG比較慢的表此時使用topas查看系統(tǒng)資源,發(fā)現(xiàn)資源消耗下降到一個較低的值,如IO吞吐量:
理想的吞吐量
當(dāng)前REORG 慢的吞吐量
分析:
1. 首先查看DB2的診斷日志(db2diag.log)及DB2的管理通知日志(db2inst1.nfy),均沒有發(fā)現(xiàn)報錯;
2. 列舉有可能造成REORG時數(shù)據(jù)量低的原因
1)表空間參數(shù)限制(PREFETCH)讀寫速度
2)操作系統(tǒng)參數(shù)瓶頸
3)存儲性能瓶頸
4)DB2 Bug
5)數(shù)據(jù)損壞
下一步計劃方向
-操作系統(tǒng)
-存儲
-DB2
-網(wǎng)絡(luò)
-內(nèi)存
既然我們是負(fù)責(zé)數(shù)據(jù)庫的,那就先由數(shù)據(jù)庫入手,
解決:
1. 從DB2入手,監(jiān)控DB2的監(jiān)控進(jìn)度
db2pd -d sample -reorg
觀察CurCount字段增長,增長慢的話表示REORG的速度很慢
2. 找到正在執(zhí)行的語句,REORG語句db2 reorg table schema.tablename longlobdata
DB2 9.7 中表重組功能也相應(yīng)做了擴(kuò)充,REORG 命令多了 LONGLOBDATA 參數(shù)。LONGLOBDATA 參數(shù)只對 long 和 LOB 列有效。 默認(rèn)情況下是不啟用 LONGLOBDATA 的,因為對 long 和 LOB 列的重組很消耗時間。
官方說明請查看以下鏈接:
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1008kongzh/index.html
我們知道DB2表普通數(shù)據(jù)和LONG/LOB數(shù)據(jù)是分開存放的,普通數(shù)據(jù)只存放有LONG/LOB的數(shù)據(jù)指針和長度,而且在處理LOB數(shù)據(jù)都是按記錄逐條解析,所以REORG時按記錄逐條解析就會變得很慢。(如果需要轉(zhuǎn)換分開存放的 LOB 到內(nèi)聯(lián)的 LOB 就要使用這個參數(shù);當(dāng)表特別大時,LOB 的重組耗費(fèi)的時間會較長)
3. 去掉longlobdata, 再次REORG
REORG的時間由原來的6個小時下降到10分鐘,系統(tǒng)吞吐量也恢復(fù)到理想狀態(tài)。
總結(jié):
這里列舉一下數(shù)據(jù)庫出現(xiàn)問題時的初步解決思路——
1. 查看DB2的診斷日志(db2diag.log)及DB2的管理通知日志(db2inst1.nfy),看是否有報錯,如果有報錯信息,可根據(jù)對應(yīng)的報錯信息了解目前可分析的問題方向。
2. 如果數(shù)據(jù)庫有報錯,根據(jù)報錯信息對可造成此問題的原因做出假設(shè);如果數(shù)據(jù)庫沒有報錯,則結(jié)合系統(tǒng)各項指標(biāo)分析可能的原因。
3. 對做出的假設(shè)做一步步推論,論證所有可能性,并從中找出根本的原因。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。