13518219792
今天陪同新来的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能越来越考虑实际需要，增加更多的监控参数吧。
