DB2 offline reorg的一點(diǎn)筆記

今天陪同新來的DB2 DBA上線，他問了我?guī)讉€(gè)問題，我總結(jié)了一下，雖然很簡單，但是貌似我多年之前也遇到過，疑惑過。
對數(shù)據(jù)庫的幾個(gè)千萬行級別大表加了列，做了offline reorg操作，幾分鐘以后，沒有做完，開始問我，怎么看現(xiàn)在運(yùn)行到哪里了，多長時(shí)間能做完。

對于第一個(gè)問題，比較容易用db2pd看，每5秒看一次輸出
db2pd -d DBNAME -reorg -rep 5

這里不得不提到的DB2的offline reorg分成幾步走，從上面的輸出可以看到 Build,IdxRecreat 這2步
實(shí)際可能有更多步，要看reorg用的命令和表有沒有cluster index，以下是詳細(xì)解釋
There are four phases in a classic or offline table reorganization:

(1) SORT: If an index is specified with the REORG TABLE command, or if a clustering index is defined on the table, the rows of the table are first sorted according to that index. If the INDEXSCAN option is specified, an index scan is used to sort the table, otherwise, a table scan sort is used. This phase only applies to a clustering REORG. Space reclaiming reorganizations begin at the build phase.
(2) BUILD: In this phase, a reorganized copy of the entire table is build, either in the table space that the table being reorganized resides, or in a temporary table space specified with the REORG command.
(3) REPLACE: In this phase, the original table object is replaced by either copying back from the temporary table space, or by pointing to the newly built object within the table space of the table being reorganized.
(4) RECREATE ALL INDEXES: All indexes defined on the table are recreated   

估計(jì)一下運(yùn)行時(shí)間的問題，最好是參考之前的REORG的時(shí)間      
select START_TIME,END_TIME from sysibmadm.db_history where OPERATION='G' and OPERATIONTYPE='F' and TABNAME='XXXXXXXXX'

每次數(shù)據(jù)庫的變更，在組里面討論的時(shí)候，都要估計(jì)一下變更所需要的時(shí)間，對于普通的SQL和DDL來說，時(shí)間消耗很小，如果涉及幾個(gè)大表的reorg & runstats操作，如果不事先做調(diào)查往往估計(jì)和實(shí)際有很大的出入，可能事情做完會(huì)被challenge。這就是吃力不討好。關(guān)鍵還是自己沒有做細(xì)致。

Reorg之后，做runstats，繼續(xù)用db2pd 觀察 db2pd -d DBNAME -runstats

順便說一句，用了幾種數(shù)據(jù)庫，在做監(jiān)控方面，db2pd是我最喜歡的，使用簡單，現(xiàn)在可以監(jiān)控的東西非常多，非常不喜歡用SQL做監(jiān)控的方式，在客戶現(xiàn)場，真心沒有空寫SQL，尤其是問題比較著急的時(shí)候。
DB2的新版本中加入了更多可以用db2pd監(jiān)控的內(nèi)容，希望db2pd能越來越考慮實(shí)際需要，增加更多的監(jiān)控參數(shù)吧。