概要：
当对一个表的结构进行改变后，需要reorg表，重新组织其目录统计信息，为数据库的访问计划提供信息，以便高效执行对其的操作。
对表作reorg操作，发生错误，通过db2 "? sql0xxx"查的错误原因为物理空间已满，然后在$DB2_INSTALL_DIR/sqllib/db2dump/查看db2diag.log可以发现是表空间大小不够。
因为reorg table如果没有指定用哪个表空间来做reorg操作的话，会默认使用该表所在的表空间，而reorg table and index xxx即表和其上的索引一起reorg的话，会默认使用系统临时表空间。
由于reorg table 失败导致的告警排查处理
$ db2 reorg table RMADMIN.RMMIGRATIONTASKS index SYSIBM.SQL120321193909130 use tempspace3
加参数use tablespaceName 指定表空间。不指定表空间，默认为reorg表所在表空间。
查询db2diag报错提示如下
MESSAGE : ZRC=0x85020021=-2063466463=SQLB_END_OF_CONTAINER "DMS Container space full" ADM6044E The DMS tablespace "BASEDBS" (ID "3") is full
符合报错信息为BASEDBS表空间所有表
CauseIf the SQL0289N is also reported at around the time of the DMS full error, then this suggests that the rebalance may be preventing an autoresize. In the SQL0289N error message reference, reasons 3 and 11 are relevant in this scenario:**********SQL0289NUnable to allocate new pages in table space tablespace-name.Explanation3A rebalance is in progress, but has not progressed far enough to enable the newly added space to be used.
Diagnosing the problemLook for a SQL0289N error in the db2diag.log file.Collect a tablespace snapshot for that DMS tablespace, and check whether the "Last resize attempt failed = Yes"db2pd -db UIDBSDNX -tablespaces
监视表重组：
select substr(tabname, 1, 15) as tab_name, substr(tabschema, 1, 15) as tab_schema, reorg_phase,reorg_max_phase, substr(reorg_type, 1, 20) as reorg_type, reorg_status, reorg_completion, dbpartitionnum from sysibmadm.snaptab_reorg order by dbpartitionnum
或者通过db2 get snapshot for tables on DBName进行reorg监控：
db2 GET SNAPSHOT FOR TABLES on DBName 通过db2pd reorg选项获得当前正在执行和近期完成的重组信息： db2pd -db DBName -reorg index 通过list history reorg all for DBName获得表或索引重组信息： db2 list history reorg all for DBName 此外db2 list utilities show detail 可以监控 LOAD ，BACKUP ，RESTORE， RUNSTATS
总结
数据库在进行reorg时失败由于系统无法分配新的页，表空间方面可能存在问题，需要扩充表空间或reorg表时重新指定表空间。
创建临时表空间操作
注意 pagesize要和表的pagesize匹配，可以用原来db2 中创建表空间的语句来参照着创建自己新的表空间。
$db2look -d $dbname -l -e -x -o $db.layout
在线重组表：
在线reorg占用资源很少，对系统影响也很小。在线reorg也叫inplace reorg，不会创建数据副本，而是在原表空间进行，表数据的重组是分批次的，每批次只处理一部份数据，因此会比离线reorg慢很多。在线reorg可以随时启动和终止，在线reorg会记录大量日志，保证其可恢复性。在线reorg是在后台异步执行的。db2 reorg table db2inst2.staff inplace allow write access 可以通过db2 list applications show detail |grep db2reorg 查看是否有reorg正在执行Reorg索引：
当离线reorg结束后，会重建表上的所有索引。在线reorg仅仅维护索引，而不会重建索引（聚集索引除外）。当在线索引reorg完成后，如需要进行索引单独重组，可以使用：db2 reorg indexes all for table tabname1.离线重组与在线重组对比：
2.重组过程中出现以外（断电），对正在重组的表或索引有何影响？
离线重组：如果断电时reorg正在进行scan或build,崩溃恢复时改表将恢复到初始状态；如果reorg正在进行replace（copy），崩溃恢复将重新执行改阶段；如果reorg正在index create,崩溃恢复阶段将把索引失效，并延迟索引重建。在线重组：如果断电时reorg正在进行，那么在执行reorg的那个事务会回滚(在线reorg采用增量的方式进行数据处理，已经完成的迁移不会收到影响)。但reorg的状态是终止(paused),可以重新恢复。