学习完命令之后来看一下表重组，然后再看索引重组哈。
表重组的方法
DB2 V8之后有两种不同的表重组的方法：
- 脱机REORG
- 联机REORG
REORG命令的INPLACE选项指定联机重组。如果未指定此选项，那么将运行脱机REORG。
可以通过两种方法来重组表：传统重组（脱机）和原位置重组（联机）。
1).缺省行为是脱机重组。
2).要指定联机重组操作，请使用 REORG TABLE 命令的 INPLACE 选项。
3).另一种方法是，使用联机表移动存储过程进行原位置重组。即使用 ADMIN_MOVE_TABLE 过程以联机方式移动表。
每种方法都有其优点和缺点，下面各节对其进行了概述。选择重组方法时，应考虑哪种方法提供的优点是您优先要解决的方面。例如，如果发生故障时进行恢复比性能更重要，那么最好使用联机重组方法。
脱机重组的优点
此方法具有下列优点：
- 最快速的表重组操作，未包括大对象 (LOB)或长字段数据时尤其如此
- 完成后将生成集群情况完美的表和索引
- 在表之后自动重建的索引已被重组；不需要执行单独的步骤来重建索引
- 使用临时表空间来构建影子副本；这降低了包含目标表或索引的表空间的空间需求
- 使用除集群索引以外的索引对数据进行重新集群
脱机重组的缺点
此方法具有下列缺点：
- 对表的访问受限：在重组操作的排序和构建阶段，只能进行读访问
- 正在重组的表的影子副本需要大量空间
- 对重组过程的控制能力较低；脱机重组操作无法暂停和重新启动
联机重组的优点
此方法具有下列优点：
- 除重组操作的截断阶段以外，允许对表进行全面的访问
- 对重组过程的控制能力较高，该过程以异步方式在后台运行，并可以被暂停、继续或停止；例如，如果正在对表运行大量的更新或删除操作，那么您可以暂停进行中的重组操作
- 重组过程在发生故障后可恢复
- 由于以递增方式处理表，因此降低了工作存储空间需求
- 重组的好处将立即体现，甚至可以在重组操作完成前体现
联机重组的缺点
此方法具有下列缺点：
- 数据或索引的集群情况并不完美，这取决于在重组操作期间访问表的事务的类型
- 与脱机重组操作相比，性能欠佳
- 日志记录需求可能较高，这取决于移动的行数、对表定义的索引数以及那些索引的大小
- 由于此过程执行的是索引维护操作而非重建操作，因此可能需要执行后续的索引重组操作
- 由于联机重新组织无法移动内部记录1，因此空间回收不完整。
注：无法移动内部记录：
表 1. 联机重组与脱机重组的比较
| 特征 | 脱机重组 | 联机重组 |
|---|---|---|
| 性能 | 快 | 慢 |
| 完成后数据的集群因子 | 良好 | 非最佳集群 |
| 并行性（对表的访问） | 从不能访问到只读访问 | 从只读访问到完全访问 |
| 数据存储空间需求 | 非常大 | 不是非常大 |
| 日志记录存储空间需求 | 不是非常大 | 非常大 |
| 用户控制（暂停和重新启动重组过程的能力） | 控制能力较低 | 控制能力较高 |
| 可恢复性1 | 不可恢复 | 可恢复 |
| 索引重建 | 进行 | 不进行 |
| 支持所有类型的表 | 是 | 否 |
| 是否能够指定除集群索引以外的索引 | 是 | 否 |
| 是否使用临时表空间 | 是 | 否 |
这里的这个可恢复性指的是如果重组期间down机，那么数据库恢复之后重组是否可以恢复。我是这么理解的哈。
表 2. 联机重组和脱机重组支持的表类型
| 表类型 | 是否受脱机重组支持 | 是否受联机重组支持 |
|---|---|---|
| 多维集群表 (MDC) | 是1 | 否 |
| 插入时间集群 (ITC)表 | 是1 | 否 |
| 范围集群表（RCT） | 否2 | 否 |
| 追加方式表 | 是 | 否3 |
| 包含长字段或大对象 (LOB)数据的表 | 是4 | 是5 |
系统目录表：
|
是 | 否 |
注意：
- 由于通过 MDC 块索引自动维护集群，所以 MDC 表的重组只涉及空间回收。不能指定索引。同样，对于 ITC 表，不能使用集群索引来指定重组。
- RCT 的范围区域始终保持集群。
- 可以在将追加方式禁用后执行联机重组。
- 重组长字段或大对象 (LOB) 数据相当耗时，并且无法提高查询性能；仅当需要回收空间时，才应该重组这些数据。
- 联机表重组不会对 LONG/LOB 数据进行重组，但会对其他列进行重组。
监视表 reorg 操作的进度
有关当前表重组操作的进度信息将写入历史记录文件。历史记录文件包含每个重组事件的记录。要查看此文件，请对正在重组的表所在的数据库执行 LIST HISTORY 命令。
此外，也可使用表快照来监视表重组操作的进度。无论如何设置数据库系统监视器表开关，系统均会记录表重组监视数据。
如果发生错误，那么 SQLCA 消息将写入历史记录文件。对于原位置表重组操作而言，状态将被记录为 PAUSED。
1.传统（脱机）重组
传统表重组使用影子副本方法，从而构建正在重组的表的完整副本。（Classic table reorganization uses a shadow copy approach, building a full copy of the table that is being reorganized.）（也就是说这种方法是把指定的表拷贝一份出来，然后对这个拷贝出来的副本进行重组，重组完成之后替换原来的表，我是这样理解的）
传统的脱机表重组操作包括四个阶段：
脱机表重组的步骤
- SORT 排序阶段 - 在此阶段，如果 REORG TABLE 命令中指定了索引，或者已对表定义集群索引，那么首先根据该索引对表行进行排序。如果指定了 INDEXSCAN 选项，那么使用索引扫描方法对表进行排序；否则，使用表扫描排序方法。此阶段仅适用于集群表重组操作。空间回收重组操作（Space reclaiming reorg operations）从构建阶段开始。
表上IX锁定，可以进行只读访问，效率低； - BUILD 构建阶段- 在此阶段，将构建整个表的重组副本，此操作在该表的表空间或者 REORG TABLE 命令中指定的临时表空间中执行。
表上U锁定，可以进行只读访问，效率低； - REPLACE置换阶段 - 在此阶段，将原始表对象替换为临时表空间中的副本，或者在所重组表的表空间中创建指向新构建的对象的指针。
表上Z锁定1，不能进行读访问了； - RECREATE ALL INDEXES重建索引阶段 - 在此阶段，重新创建先前对该表定义的所有索引。
表上Z锁定，不能进行读访问了；
Z锁：该锁不是通过应用程序的DML语句来产生的。一般是通过对表进行删除（Drop）和更改（Alter）操作，或创建和删除索引而获得的。如果对表加上Z锁，其他应用程序（包括未提交读程序）都不能对表进行存取。
那在replace阶段，Z锁应该是由Alter table name产生的吧？
那在recreate indexes阶段，Z锁应该是由创建索引产生的吧？
问题：创建索引会产生Z锁？那我们在一个已存在的表上创建索引时，其他用户可以访问不？我觉得应该可以并行访问的呀。。。。
步骤个人理解（不保证对哈）
reorg table t2 using tempspace1
所以，使用临时表空间的重组应该是这么一个过程：
- 将表t2拷贝到系统临时表空间tempspace1中，假设叫t2_shadow吧
- 对tempspace1中的t2_shadow表进行排序，
or： - 对t2表进行排序，
- 把排序好的t2表拷贝到系统临时表空间tempspace1中，假设叫t2_shadow吧，
3.构建： During this phase, a reorganized copy of the entire table is built, either in its table space or in a temporary table space that was specified on the REORG TABLE command.在系统临时表空间tempspace1对表t2进行重新组织，包括提交Deleted Record，pseudo EMPTY 的页，从而能进行Space Reclaim，使表的逻辑顺序重新对应存储顺序。
4.置换：the original table object is replaced by a copy from the temporary table space,原始表被来自临时表空间的拷贝所取代：应该是把这个重组好的t2_shadow从 系统临时表空间tempspace1中拷贝到当前的表空间，然后实行表的替换，把原来的t2换成一个别的名字，这里应该也包含原表的索引页重命名了，之后删除把t2_shadow名称换成t2，删除原来的t2表，
这里应该有个问题就是：从系统临时表空间拷贝到当前表空间的时候将会拷贝到哪里去呢？
- 重新创建索引：重新创建先前对该表定义的所有索引
♦ 假使当前的表空间中有EXTENT22-28是EMPTY的，29-59是有内容的，高水位就在EXTENT58；
♦ 原来的t2表占据EXTENT13,14，48,49,50,51,52,53,54,55,56,57,58，59，
♦ t2_shadow经过重新组织之后需要占据 11 个EXTENT，
♥ 那么t2_shadow拷贝过来时先占据22-28这7个EXTENT，然后还有4个EXTENT，这4个EXTENT就要新申请存储空间，故会占据EXTENT60,61,62,63；然后置换完成之后space reclaim 原来的t2表占据的EXTENT 13,14，48,49,50,51,52,53,54,55,56,57,58，59，这14个EXTENT会变成EMPTY的。
您可以使用快照监视器或快照管理视图来监视表重组操作的进度并确定当前阶段。
脱机方式下的锁定条件的限制性与联机方式更强。构建副本期间，可以对表进行读访问。但是，在将原始表替换为已重组的副本期间以及在重建索引期间，需要对表进行互斥访问。
在整个表重组过程中，需要挂起 IX 表空间锁定。在构建阶段，将获取 U 锁定并对该表挂起该锁定。U 锁定允许锁定所有者更新表中的数据。虽然没有其他应用程序能够更新数据，将允许进行读访问。替换阶段开始后，U 锁定将升级为 Z 锁定。在此阶段，任何其他应用程序都无法访问数据。此锁定将一直挂起到表重组操作完成为止。
脱机重组过程将创建多个文件。这些文件存储在数据库目录中。它们的名称以表空间标识和对象标识为前缀；例如，0030002.ROR 是表空间标识为 3 且表标识为 2 的表重组操作的状态文件。
以下列表提供了脱机表重组操作期间在系统管理的空间 (SMS) 表空间中创建的临时文件：
.DTR - 数据影子副本文件
.LFR - 长字段文件
.LAR - 长字段分配文件
.RLB - LOB 数据文件
.RBA - LOB 分配文件
.BMR - 多维集群 (MDC) 表和插入时间集群 (ITC) 表的块对象文件
在索引重组操作期间，将创建以下临时文件：
.IN1 - 影子副本文件
以下列表提供了排序阶段在系统临时表空间中创建的临时文件：
.TDA - 数据文件
.TIX - 索引文件
.TLF - 长字段文件
.TLA - 长字段分配文件
.TLB - LOB 文件
.TBA - LOB 分配文件
.TBM - 块对象文件
您不应以手动方式从系统中除去与重组过程相关联的文件。
1.以脱机方式重组表
以脱机方式重组表是整理表碎片的最快方法。重组可减少表所需的空间量并提高数据访问和查询性能。
开始之前
您必须具有 SYSADM、SYSCTRL、SYSMAINT、DBADM 或 SQLADM 权限或者对所要重组的表具有 CONTROL 特权。您还必须建立数据库连接才能重组表。
关于此任务
在标识需要重组的表之后，可以对那些表运行 REORG 实用程序，并且可以选择对那些表的任何索引运行该实用程序。
过程
要使用 REORG TABLE 命令来重组表，只需指定该表的名称。例如：
reorg table employee您可以使用特定的临时表空间来重组表。例如：
reorg table employee use mytemp您可以重组表并根据特定索引对行进行重新排序。例如：
reorg table employee index myindex要使用 SQL CALL 语句来重组表，请通过 ADMIN_CMD 过程来指定 REORG TABLE 命令。例如：
call sysproc.admin_cmd ('reorg table employee')要使用管理应用程序编程接口来重组表，请调用 db2Reorg API。
下一步做什么
在重组表之后，请收集有关该表的统计信息，以便优化器掌握最准确的数据来评估查询存取方案。
2.脱机表重组的恢复
在替换阶段开始之前，脱机表重组是一个完全成功或完全失败的过程。如果系统在排序或构建阶段崩溃，那么重组操作将回滚，并且不会在崩溃恢复期间重新执行。
如果系统在替换阶段开始之后崩溃，那么重组操作必须完成，这是因为已完成所有重组工作，原始表可能不再可用。在崩溃恢复期间，需要已重组的表对象的临时文件，而不是用于执行排序的临时表空间。恢复操作将完全重新开始替换阶段，并且需要恢复副本对象中的所有数据。在这种情况下，系统管理的空间 (SMS) 表空间与数据库管理的空间 (DMS) 表空间之间有一个差别：必须将 SMS 中已重组的表对象从一个对象复制到另一个对象；但在 DMS 中，如果在同一个表空间中执行重组，那么只需指向已重组的表对象，并且将删除原始表。将不重建索引，但在崩溃恢复期间会将索引标记为无效。数据库将根据一般规则确定重建索引的时间：在数据库重新启动时或第一次访问索引时。
如果在索引重建阶段发生崩溃，那么由于新的表对象已存在，因此不会重新执行任何操作。将按先前描述的方式来处理索引。
在前滚恢复期间，如果旧版本的表在磁盘上，那么重新进行重组操作。前滚实用程序使用构建阶段记录的记录标识（RID）来重新应用创建了已重组的表的操作，从而重复构建和替换阶段。将按先前描述的方式来处理索引。仅当最初使用了临时表空间时，已重组的对象的副本才需要临时表空间。在前滚恢复期间，可以同时重新执行多个重组操作（并行恢复）。
3.提高脱机表重组的性能
脱机表重组的性能在很大程度上由数据库环境的特征决定。
以 ALLOW NO ACCESS 方式运行的重组操作与以 ALLOW READ ACCESS 方式运行的重组操作在性能方面几乎没有任何差别。差别在于，在 ALLOW READ ACCESS 方式的重组操作期间，实用程序可能必须先等待其他应用程序完成扫描并释放它们的锁定，然后才能替换该表。在以任何一种方式运行的重组操作的索引重建阶段，该表都不可用。
有关提高性能的技巧
- 如果有足够的空间，那么请对原始表和表的重组副本使用同一个表空间，以代替使用临时表空间。这将节省从临时表空间复制已重组的表所需的时间。
- 考虑在重组表之前删除不必要的索引，以便减少重组操作期间需要维护的索引数目。
- 确保正确设置已重组的表所在的表空间的预取大小。
- 调整 sortheap 和 sheapthres 数据库配置参数，以便控制可用于排序的空间量。由于每个处理器都将执行私有排序，因此 sheapthres 的值至少应该是 sortheap x 使用的处理器数。
- 调整页清除程序数，以确保尽快清除缓冲池中的脏索引页。
2.联机/原位置重组
原位置表重组在您能够对表数据进行全面访问的情况下重组该表。数据访问不中断的代价是，表重组操作的运行速度较慢。
在原位置（即联机）表重组操作期间，不是立即重组整个表，，而是按顺序重组表的各个部分。不会将数据复制到临时表空间；而是，在现有表对象中移动行以重新建立集群、回收可用空间并消除溢出行。
联机重组步骤
联机表重组操作分为 4 个主要阶段：
（1） 选择 n 页（SELECT N pages）
在此阶段，数据库管理器将选择由 n 页组成的范围，其中 n 是至少包含 32 个要进行重组处理的顺序页的扩展数据块的大小。
（2） 腾出范围(vacate the range)
选定N页后，联机表重组将第一阶段选定范围内的所有行移至表中的可用页1。每个被移动的行都保留一条RP(REORG TABLE Pointer)记录，该记录包含行的新位置的RID。将行作为包含数据的RO(REORG TABLE Overflow)插入到表的可用页中。
重组表完成移动一组行后，它将等待表中进行的所有现有数据访问（例如，通过当前执行的应用程序）完成。这些现有访问称为旧扫描程序，他们在访问数据时使用旧RID。在此等待过程中启动的任何访问都称为新扫描程序，它们使用新的RID来访问数据。在所有旧扫描程序都完成后，重组表操作将清除已移动的行、删除RP记录并将RO记录转换为正常的记录。
或者使用下面的表述方式
REORG 实用程序将此范围内的所有行移至表中的可用页。每个被移动的行 的原位置 就不存储行了，而是存储 一条重组表指针（RP REORG TABLE Pointer）记录，该记录包含该行的新位置的记录标识 (RID)。将行作为包含数据的重组表溢出（RO REORG TABLE Overflow）记录被放入到表的可用页。此实用程序移动一组行完成后，它将等待所有访问该表中数据的应用程序完成。这些“旧扫描者”在访问表数据时，将使用旧 RID。在等待阶段开始的任何表访问（“新扫描者”）都将使用新 RID 来访问数据。在所有旧扫描者都完成后，REORG 实用程序将清除已移动的行、删除 RP 记录并将 RO 记录转换为常规记录。
（3） 填充范围（Fill the range）
腾出特定范围内的所有行之后，将采用已重组的格式、根据先前使用的任何索引进行排序后的顺序并遵循先前定义的任何预取限制写回这些行。重写该范围内的所有页之后，将选择该表中的后续 n 个顺序页并重复以上过程。
（4） 截断表（truncate table）
缺省情况下，重组表中的所有页后，缺省情况下将截断表以回收空间。如果指定了 NOTRUNCATE 选项，那么不会截断已重组的表。By default, when all pages in the table have been reorganized, the table is truncated to reclaim space. If the NOTRUNCATE option has been specified, the reorganized table is not truncated.
&esmp;在这里的truncate table 与命令执行truncate table table_name的truncate含义应该不一样吧？
truncate：切去头端, 截棱成平面, 缩短：在在这里理解成缩短的意思吧，经过重组之后可能会有一本空间EMPTY了，阶段表是将这些EMPTY的页截断回收利用吧。
1: 要是没有可用页怎么办？或者可用页不够怎么办？
这个，既然是要重组表了哈，一般应该是有可用页的哈，然后这个N至少是32，但是N具体是多少是重组程序内部控制的吧不是外部指定的哈？），那么reorg应该在重组开始之前 首先通过搜索 FSCR 来找到空 page，看看有多少空page，如果空page比较少，那么这个N应该会比较少，如果比较多就会比较自由了哈，如果实在是找不到，可能会重新申请一个EXTENT吧/FSCR：可用空间控制行：DB2 每个表对象的存储里有一种特殊的记录叫做 FSCR（Free Space Control Record），从 Page 0 开始每 500 个 page 有一个 FSCR 记录，用来记录当前 500 个 page 中空闲空间情况。
从上面的描述中可以看出，联机重组之所以也被称为原位置重组，就是因为它最后会把排序好的行写回去，写回原位置。也正是因为她是N pages->N pages这样进行的，那两组N pages之间的一些相关的行呀是没有重组的，所以可能有一些顺序还是不对的，所以第一个表格中完成后数据的集群因子不是最优的，非最佳集群，但是因为这些N pages行的转换都是记录了日志的，所以可以恢复重组之前的状态，而N pages 只需要比较小的空间，脱机重组需要拷贝整个表所以需要的空间比较大。
联机表重组操作期间创建的文件
联机表重组操作期间，将为每个数据库分区创建一个 .OLR 状态文件。这个二进制文件的名称格式为 xxxxyyyy.OLR，其中 xxxx 是表空间标识，yyyy 是十六进制的对象标识。此文件包含从暂停状态继续执行联机重组操作所需的下列信息：
- 重组操作的类型
- 正在重组的表的生存日志序号（LSN）
- 要腾出的下一个范围
- 重组操作是为了对数据进行集群还是仅仅为了回收空间
- 正在用于对数据进行集群的索引的标识
将对 .OLR 文件执行校验和检查。如果该文件已损坏并导致校验和错误，或者表 LSN 与生存 LSN 不匹配，那么将启动新的重组操作并创建新的状态文件。
如果 .OLR 状态文件被删除，那么重组过程无法继续，将返回 SQL2219，并且必须启动新的重组操作。
您不应以手动方式从系统中除去与重组过程相关联的文件。
1.以联机方式重组表
联机或原位置表重组允许用户在重组表的同时访问该表。
开始之前
您必须具有 SYSADM、SYSCTRL、SYSMAINT、DBADM 或 SQLADM 权限或者对所要重组的表具有 CONTROL 特权。您还必须建立数据库连接才能重组表。
关于此任务
在标识需要重组的表之后，可以对那些表运行 REORG 实用程序，并且可以选择对那些表的任何索引运行该实用程序。
过程
要使用 REORG TABLE 命令以联机方式重组表，请指定表名和 INPLACE 参数。 例如：
reorg table employee inplace要使用 SQL CALL 语句以联机方式重组表，请通过 ADMIN_CMD 过程来指定 REORG TABLE 命令。 例如：
call sysproc.admin_cmd ('reorg table employee inplace')要使用管理应用程序编程接口以联机方式重组表，请调用 db2Reorg API。
下一步做什么
在重组表之后，请收集有关该表的统计信息，以便优化器掌握最准确的数据来评估查询存取方案。
2.联机表重组的恢复
联机表重组的故障通常是由于处理错误（例如磁盘已满或日志记录错误）所致。如果联机表重组失败，那么系统会将 SQLCA 消息写入历史记录文件。
如果运行时发生故障，那么联机表重组操作将暂停，然后在崩溃恢复期间回滚。以后，您可以通过在 REORG TABLE 命令中指定 RESUME 参数来继续执行重组操作。由于联机表重组过程进行全面的日志记录，因此保证可恢复。
在某些情况下，联机表重组操作可能会超出 num_log_span 数据库配置参数所设置的限制。在这种情况下，数据库管理器将强制控制 REORG 实用程序并将其置于 PAUSE 状态。在快照监视器输出中，REORG 实用程序的状态将显示为 PAUSED。
联机表重组暂停由中断驱动，这意味着它既可以由用户触发（使用 REORG TABLE 命令的 PAUSE 参数或者 FORCE APPLICATION 命令），也可以由数据库管理器在某些情况（例如系统崩溃）下触发。
如果分区数据库环境中的一个或多个数据库分区遇到错误，那么返回的 SQLCODE 将是来自第一个报告错误的数据库分区的 SQLCODE。
3,暂停和重新启动联机表重组
用户可以暂停和重新启动正在进行中的联机表重组。
开始之前
您必须具有 SYSADM、SYSCTRL、SYSMAINT、DBADM 或 SQLADM 权限或者对要暂停或重新启动联机重组操作的表具有 CONTROL 特权。您还必须建立数据库连接才能暂停或重新启动联机表重组。
过程
-
要使用 REORG TABLE 命令来暂停联机表重组，请指定表名、INPLACE 参数和 PAUSE 参数。 例如：
reorg table employee inplace pause -
要重新启动已暂停的联机表重组，请指定 RESUME 参数。 例如：
reorg table employee inplace resume暂停联机表重组操作之后，无法开始对该表执行新的重组。您必须继续执行或停止已暂停的操作，然后才能开始新的重组过程。 发出 RESUME 请求之后，重组过程将考虑当前 RESUME 请求所指定的截断选项。例如，如果未在当前 RESUME 请求上指定 NOTRUNCATE 参数，那么原始 REORG TABLE 命令上指定的 NOTRUNCATE 参数或带有任何先前 RESUME 请求的命令被忽略。 执行复原和前滚操作后，无法恢复表重组操作。
4.联机表重组的锁定和并行性注意事项
联机表重组的其中一个重要方面是如何控制锁定，因为这对应用程序并行性而言至关重要。
联机表重组操作可以挂起下列锁定：
- 为了确保能够对表空间进行写访问，获取对重组操作所影响的表空间的 IX 锁定。
-
在整个重组操作期间获取并挂起表锁定。锁定级别取决于重组期间实施的访问方式：
- 如果指定了 ALLOW WRITE ACCESS，那么获取 IS 表锁定。
- 如果指定了 ALLOW READ ACCESS，那么获取 S 表锁定。
- 在截断阶段，将请求对表挂起 S 锁定。在获取 S 锁定之前，并发事务可以插入行。这些插入的行可能不会被 REORG 实用程序检测到，并可能导致表无法被截断。获取 S 表锁定之后，导致表无法被截断的行将被移走，以便能够对表进行压缩。在压缩表之后，会将其截断，但仅当确定所有在截断点访问该表的事务都完成后才会执行此操作。
-
可能会获取行锁定，这取决于表锁定的类型：
- 如果已对该表挂起 S 锁定，那么不需要单独的行级别 S 锁定，并且不必进一步执行锁定。
- 如果已对该表挂起 IS 锁定，那么移动行之前将获取 NS 行锁定，并在移动完成后释放该锁定。
- 在联机表重组操作期间，还可能获取某些内部锁定。
锁定会影响联机表重组操作和并发用户应用程序的性能。您可以使用锁定快照数据来帮助您了解联机表重组期间发生的锁定活动。
监视表重组
您可以使用 GET SNAPSHOT 命令、SNAPTAB_REORG 管理视图或 SNAP_GET_TAB_REORG 表函数来获取有关表重组操作的状态信息。
过程
要使用 SQL 来访问有关重组操作的信息，请使用 SNAPTAB_REORG 管理视图。 例如，下列查询将返回有关对当前所连接数据库的所有数据库分区执行的表重组操作的详细信息。如果未重组任何表，那么不会返回任何行。
select
substr(tabname, 1, 15) as tab_name,
substr(tabschema, 1, 15) as tab_schema,
reorg_phase,
substr(reorg_type, 1, 20) as reorg_type,
reorg_status,
reorg_completion,
dbpartitionnum
from sysibmadm.snaptab_reorg
order by dbpartitionnum要使用快照监视器来访问有关重组操作的信息，请使用 GET SNAPSHOT FOR TABLES 命令并检查表重组监视元素的值。
结果
由于脱机表重组操作是同步操作，所以错误将返回给实用程序的调用者（应用程序或命令行处理器）。并且，由于联机表重组操作是异步操作，所以这种情况下不会将错误消息返回给 CLP。要查看执行联机表重组操作期间返回的 SQL 错误消息，请使用 LIST HISTORY REORG 命令。
联机表重组操作作为 db2Reorg 进程在后台运行。即使调用应用程序终止其数据库连接，此进程也将继续运行。
3.admin_move_table
当调用 SYSPROC.ADMIN_MOVE_TABLE 过程时，会:
- 创建源表的影子副本（shadow table）
- 在复制阶段期间，会使用触发器来捕获对源表的更改（更新、插入或删除）并将其放置到staging table中
- 当复制阶段完成后，会对影子副本重放登台表中捕获的更改。
- 存储过程会迅速使源表脱机并将源表名称和索引名称指定给影子副本及其索引。
- 然后，使影子表联机，从而替换源表。缺省情况下，会删除源表，但可以使用 KEEP 选项来以另一个名称保留该源表。
