什么是REORG?

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：空間域名、虛擬主機、營銷軟件、網(wǎng)站建設、河間網(wǎng)站維護、網(wǎng)站推廣。

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

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

 

什么時候需要做REORG?

當數(shù)據(jù)庫里某個表中的記錄變化量很大時，則需要在表上做REORG操作來優(yōu)化數(shù)據(jù)庫性能。

針對數(shù)據(jù)庫對象的大量操作，如反復地刪除表，存儲過程，會引起系統(tǒng)表中數(shù)據(jù)的頻繁改變，在這種情況下，也要考慮對系統(tǒng)表進行REORG操作。

 

完整的REORG表的過程

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

 

RUNSTATS ->   REORGCHK ->   REORG ->   RUNSTATS -> BIND或REBIND

注： 執(zhí)行此部分命令前需要連接數(shù)據(jù)庫

 

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

 

 

情景：

某電信網(wǎng)絡發(fā)票系統(tǒng)每周五晚上9點開始做數(shù)據(jù)庫維護，包括REORG，RUNSTAT，REBIND，維護時間需要大約10 個小時，期間會影響系統(tǒng)正常作業(yè)。經(jīng)優(yōu)化腳本生成詳細維護日志，檢查維護部分表的REORG時間過長。整個數(shù)據(jù)庫大小為500GB。

 

操作系統(tǒng)版本：AIX 7.1

數(shù)據(jù)庫版本  ：DB2 V9.7

 

問題：

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

改用并行的REORG的腳本，維護時間仍然需要大約9個小時；

 

恢復到使用串行的REORG腳本，并觀察系統(tǒng)資源消耗情況，一開始REORG速度很快，但過了不久后，到達了REORG比較慢的表此時使用topas查看系統(tǒng)資源，發(fā)現(xiàn)資源消耗下降到一個較低的值，如IO吞吐量：

理想的吞吐量

當前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)絡

-內(nèi)存

 

既然我們是負責數(shù)據(jù)庫的，那就先由數(shù)據(jù)庫入手，

 

解決：

1.      從DB2入手，監(jiān)控DB2的監(jiān)控進度

db2pd -d sample -reorg

 

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

2.      找到正在執(zhí)行的語句，REORG語句db2 reorg table schema.tablename longlobdata

DB2 9.7 中表重組功能也相應做了擴充，REORG 命令多了 LONGLOBDATA 參數(shù)。LONGLOBDATA 參數(shù)只對 long 和 LOB 列有效。 默認情況下是不啟用 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ù)；當表特別大時，LOB 的重組耗費的時間會較長）

 

3.      去掉longlobdata,再次REORG

REORG的時間由原來的6個小時下降到10分鐘，系統(tǒng)吞吐量也恢復到理想狀態(tài)。

 

 

總結(jié)：

這里列舉一下數(shù)據(jù)庫出現(xiàn)問題時的初步解決思路——

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

2.      如果數(shù)據(jù)庫有報錯，根據(jù)報錯信息對可造成此問題的原因做出假設；如果數(shù)據(jù)庫沒有報錯，則結(jié)合系統(tǒng)各項指標分析可能的原因。

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

文章名稱：DB2性能優(yōu)化-REORG慢的分析
文章網(wǎng)址：http://www.chinadenli.net/article22/pgcocc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供移動網(wǎng)站建設、搜索引擎優(yōu)化、服務器托管、企業(yè)網(wǎng)站制作、企業(yè)建站、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)