DB2 offline reorg的一點筆記

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

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

這里不得不提到的DB2的offline reorg分成幾步走，從上面的輸出可以看到 Build,IdxRecreat 這2步
實際可能有更多步，要看reorg用的命令和表有沒有cluster index，以下是詳細解釋
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   

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

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

Reorg之后，做runstats，繼續用db2pd 觀察 db2pd -d DBNAME -runstats

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