DB2 的REORG_学习（3）_索引重组

表被更新后，索引性能可能会下降。

这种下降表现在下列方面：

叶子页碎片化。叶子页碎片化之后，必须读取更多的叶子页才能访存表页，因此 I/O 操作成本会增加。

物理索引页的顺序不再与那些页中键的顺序相匹配，从而产生低密度索引1。叶子页具有低密度时，顺序预取操作的效率将降低，I/O 等待数将增加。但是，如果启用了智能索引预取，并且存在低密度索引，那么查询优化器会切换至提前读预取。这可帮助减少低密度索引对性能的负面影响。

索引发展到层数过多。在这种情况下，应重组索引。

索引重组要求：

对表及其索引具有 SYSADM、SYSMAINT、SYSCTRL、DBADM 或 SQLADM 权限，或者具有 CONTROL 特权

如果选择带有 ALLOW READ 或 WRITE ACCESS 选项的 REBUILD 选项，那么存储索引的表空间中需要一些可用空间。此空间必须等于索引的当前大小2。发出 CREATE TABLE 语句时，考虑将索引放在大型表空间中。

其他日志空间。索引重组实用程序将记录它自己的活动。

如果在 CREATE INDEX 语句中指定了 MINPCTUSED 选项，那么在某个键被删除且可用空间量变为小于指定的值时，数据库服务器将自动合并索引叶子页。此过程称为联机索引整理碎片。

要复原索引集群、释放空间以及降低叶级别，可以使用下列其中一种方法：

删除并重新创建索引。

将 REORG TABLE 命令与允许重组表的选项配合使用并以脱机方式重建其索引4。

将 REORG INDEXES 命令与 REBUILD 选项配合使用以联机或脱机重组索引5。在生产环境中，您可以选择联机重组，因为这将允许用户在重建表索引期间对表执行读或写操作。

如果主要目的是释放空间，请考虑使用 REORG 命令的 CLEANUP 和 RECLAIM EXTENTS 选项。有关更多详细信息，请参阅相关链接。

在 IBM® Data Studio V3.1 或更高版本中，可以使用以下工具的任务助手：重组索引. 任务助手可以指导您执行以下过程：设置选项、查看自动生成的命令以执行任务以及运行这些命令。有关更多详细信息，请参阅使用任务助手管理数据库。

对于 DB2® V9.7 FP1 及更高版本的发行版，对数据分区表使用 REORG INDEXES ALL 命令并使用 ON DATA PARTITION 子句指定某个分区，就会重组单个数据分区的分区索引。在重组索引期间，不受影响的分区将保持可读，而只有受影响的分区才可写。

可以对数据分区表发出 REORG TABLE 命令和 REORG INDEXES ALL 命令，以便同时重组不同的数据分区或者重组分区中的分区索引。同时重组不同的数据分区或者重组分区的分区索引时，用户可以访问不受影响的分区。必须满足下列所有条件，才能发出同时对同一个表运行的 REORG 命令：

每个 REORG 命令必须对 ON DATA PARTITION 子句指定不同的分区。

每个 REORG 命令必须使用 ALLOW NO ACCESS 方式来限制访问数据分区。

如果发出 REORG TABLE 命令，那么分区表必须只有分区索引。不能对表定义非分区索引（由系统生成的 XML 路径索引除外）。

注：

REORGCHK 命令的输出包含有关重组索引的统计信息和建议。对于分区表，此输出包含有关重组分区索引和非分区索引的统计信息和建议。或者，如果目的是回收空间，那么 ADMIN_GET_INDEX_INFO 函数的 RECLAIMABLE_SPACE 输出显示可回收的空间量。将 REORG INDEXES 命令与 RECLAIM EXTENTS 选项配合使用来释放此可回收空间。

注意：

在这里我们主要讨论联机索引重组而不讨论脱机重组是因为脱机重组表的时候最后一步是RECREATE ALL INDEXES,所以大多时候是联机重组表之后再联机重组索引，所以下面主要看联机索引重组哈！⌒＿⌒

联机索引重组

索引重组的步骤，我觉得这个确实不一而论，因为选项不一样，跟表重组的步骤不好比较，那我们再温故一下语法，但看索引这部分，它就有

REORG INDEX indexname FOR TABLE tablename

和

REORG TABLE tablename INDEX indexname

这两种写法，可能是等效的吧，然后还有各个选项，我们再看一下语法，就看

REORG INDEX indexname FOR TABLE tablename

的语法吧，另一种写法估计一样的：

>>-REORG-------------------------------------------------------->

>--+-+-INDEXES ALL FOR TABLE--table-name------------+-->
'-INDEX--index-name--+-----------------------+-'
'-FOR TABLE--table-name-'

.-REBUILD---------------.
>--+--------------------+--+-----------------------+------------|
+-ALLOW NO ACCESS----+  '-space-reclaim-options-'
+-ALLOW WRITE ACCESS-+
'-ALLOW READ ACCESS--'

>--+-------------------------------+---------------------------->
'-| Table partitioning clause |-'

>--+-------------------------------+---------------------------><
'-| Database partition clause |-'

space-reclaim-options

|--+--------------------+--+-----------------+------------------|
|          .-ALL---. |  '-RECLAIM EXTENTS-'
'-CLEANUP--+-------+-'
'-PAGES-'

所以，这个索引重组的步骤根据选项来说是不一样的：

从访问方式ALLOW NO/READ/WRITE三种方式来说：

首先重组索引时的默认访问方式是：

非分区表的REORG INDEXES是ALLOW READ ACCESS；

分区表的REORG INDEX是ALLOW READ ACCESS;

分区表不指定表分区的REORG INDEXES rebuild是ALLOW NO ACCESS

表格2. 分区表和分区表上的索引重组支持的访问模式

命令	表类型	表分区子句	索引子句指定的附加参数	支持的访问模式
REORG INDEXES	非分区表	不适用 Not applicable	Any	ALLOW NO ACCESS, ALLOW READ ACCESS1, ALLOW WRITE ACCESS
REORG INDEX	分区表	不适用 Not applicable	Any	ALLOW NO ACCESS, ALLOW READ ACCESS1, ALLOW WRITE ACCESS
REORG INDEXES	分区表	None	REBUILD (不指定的话 这是默认的)	ALLOW NO ACCESS 1
REORG INDEXES	分区表	ON DATA PARTITION	REBUILD (不指定的话 这是默认的)	ALLOW NO ACCESS, ALLOW READ ACCESS1, ALLOW WRITE ACCESS
REORG INDEXES	分区表	有或没有ON DATA PARTITION 子句	指定CLEANUP 或 RECLAIM EXTENTS	ALLOW NO ACCESS, ALLOW READ ACCESS1, ALLOW WRITE ACCESS

注：标有上标1的是默认的访问模式.

可以看到大部分情况下默认是ALLOW READ ACCESS

- 构建索引对象的影子副本（shadow copy of the index object is built）

- 在索引的重组拷贝 可用 之前的这段时间里面 重构索引 时 是不可以访问表的No access to the table is allowed when rebuilding an index during the period in which the reorganized copies of the indexes are made available.

索引重组的步骤猜想：

应该和脱机表重组比较像：

拷贝一个当前索引对象的影子副本（shadow copy）到该索引的表空间，

构建这个的shadow copy：排序，节点的删除啊什么的，总之就是让它变的物理有序吧，

如果是带有 ALLOW READ/WRITE ACCESS 和 REBUILD ：

置换：用新建的索引来置换原来的索引。置换之前加Z锁，落实在rebuild阶段表上的事务更改，落实之后废弃原始索引对象，置换完成后释放Z锁。

如果使用带有 ALLOW READ/WRITE ACCESS 和 REBUILD 选项的 REORG INDEXES 命令，那么在构建索引对象的影子副本(a shadow copy of the index object is built )时，原始索引对象仍然可用，因为对表的读写访问会继续。如果允许进行写访问，那么在重组期间，会记录对基础表所作的任何将影响索引的更改。重组操作将在重构（rebuild）索引时处理所记录的这些更改。

如果有内部内存缓冲区可供使用，那么对基础表所作的将影响索引的更改还将记录到该空间。内部缓冲区是根据需要从实用程序堆中分配的指定内存区域。使用内存缓冲区会使索引重组实用程序能够按以下方式处理更改：先直接从内存读取，然后在必要时通过日志读取，但通过日志进行读取的时间要晚很多。在重组操作完成后，将释放所分配的内存。

索引表空间中需要额外的存储空间来保存索引的影子副本。一旦构建了索引的影子副本并且已处理影响该影子副本的所有日志，就会对该表生成超级互斥排他（super-exclusive）锁定（就是Z锁）3，并且废弃原始索引。由索引对象的原始副本占用的空间供同一表空间中的任何对象自由复用，但是它不会自动返回给文件系统。

系统不支持对空间索引或多维集群 (MDC) 表和插入时间集群 (ITC) 表执行 ALLOW WRITE ACCESS 方式（无论是否指定了 CLEANUP 选项）的联机索引重组。

联机索引重组的锁定和并行性注意事项

在本主题中，联机索引重组适用于带有 ALLOW READ ACCESS 或 ALLOW WRITE ACCESS 参数运行的索引重组。

这些选项允许您在重组表的索引时访问该表。在运行带有 REBUILD 选项的联机索引重组期间，会将新索引作为另外的副本来构建，而原始索引将保持不变。创建新索引时，并发事务将使用原始索引。重组操作结束时，原始索引将被新索引替换。替换原始索引之后，新索引中将反映同时落实的事务。如果重组操作失败，并且已回滚事务，那么原始索引将保持不变。在带有 CLEANUP 和 RECLAIM EXTENTS 选项的联机索引重组期间，将回收空间，回收的空间可以被表空间中的所有对象使用。

联机索引重组操作可持有以下锁：

为了确保能够访问表空间，应获取对于受重组操作影响的表空间的 IX （Intent eXclusive）锁定。这包括拥有表以及分区和索引对象的表空间。

为了防止受影响的表在重组期间被改变，应获取 X alter table lock。

在整个重组操作期间获取并挂起表锁定。锁定类型取决于表类型、访问方式和重组选项：

对于非分区表：

如果指定了 ALLOW READ ACCESS，那么将获得对此表的 U 锁定。

如果指定了 ALLOW WRITE ACCESS，那么将获得对此表的 IN （无意图）锁定。

如果指定了 CLEANUP，那么将获得对此表的 S 锁定以进行读访问，以及对此表的 IX 锁定以进行写访问。

对于分区表，仅支持在分区级别使用 ALLOW READ ACCESS 或 ALLOW WRITE ACCESS 进行重组：

如果指定了 ALLOW READ ACCESS，那么将获得对此分区的 U 锁定。

如果指定了 ALLOW WRITE ACCESS，那么将获得对此分区的 IS 锁定。

如果指定了 CLEANUP，那么将获得对此分区的 S 锁定以进行读访问，以及对此分区的 IX 锁定以进行写访问。

无论指定了哪种访问方式或哪个选项，都将获得对此表的 IS 锁定。

在索引重组结束时请求了对此表或分区的排他 Z 锁定。如果分区表中包含非分区索引，那么将获得对此表以及此分区的 Z 锁定。此锁定将暂挂表和分区访问，以允许新索引来替换原始索引（This lock suspends table and partition access to allow for the replacement of the original indexes by the new indexes. ）。在新索引中反映重组期间已落实的事务之前，此锁定将一直被挂起。

将获得对于系统目录表 SYSIBM.SYSTABLES 的 IS 表锁定和 NS 行锁定。

对于分区级别的重组，还会获得对于系统目录表 SYSIBM.SYSDATAPARTITIONS 的 IS 表锁定和 NS 行锁定。

在联机索引重组操作期间，还可能获得某些内部锁定。

如果重组操作失败，那么联机索引重组可能会影响并行性。例如，重组可能会由于内存不足、磁盘空间不足或者锁定超时而失败。重组事务在终止之前将执行某些更新。要执行更新，重组操作必须等待落实现有事务。此延迟可能会阻塞正在进行的其他事务。从 DB2® V9.7 FP1 开始，重组操作将请求对索引对象进行特殊的放弃锁定。重组操作将等待完成现有事务；但是，允许新请求来访问索引对象（没完没了怎么办？）(reorganization requests a special drain lock on the index object. Reorganization operations wait for existing transactions to finish; however, new requests to access the index object are allowed.)。

监视索引重组操作

关于此任务

可使用 db2pd 命令来监视数据库上的重组操作的进度。

过程

发出带有 -reorgs index 参数的 db2pd 命令：

db2pd -reorgs index

结果

以下是使用带有 -reorgs index 参数的 db2pd 命令获取的输出示例，它报告带有两个分区的范围分区表的索引重组进度。

注：

第一个输出报告非分区索引的索引重组状态。以下输出报告每个分区上的分区索引的索引重组状态；每个输出仅报告一个分区的索引重组统计信息。

Index Reorg Stats:
Retrieval Time: 02/08/2010 23:04:21
TbspaceID: -6       TableID: -32768
Schema: TEST1    TableName: BIGRPT
Access: Allow none
Status: Completed
Start Time: 02/08/2010 23:03:55   End Time: 02/08/2010 23:04:04
Total Duration: 00:00:08
Prev Index Duration:  -
Cur Index Start: -
Cur Index: 0            Max Index: 2            Index ID: 0
Cur Phase: 0          ( -     )   Max Phase: 0
Cur Count: 0                      Max Count: 0
Total Row Count: 750000

Retrieval Time: 02/08/2010 23:04:21
TbspaceID: 2        TableID: 5
Schema: TEST1    TableName: BIGRPT
PartitionID: 0      MaxPartition: 2
Access: Allow none
Status: Completed
Start Time: 02/08/2010 23:04:04   End Time: 02/08/2010 23:04:08
Total Duration: 00:00:04
Prev Index Duration:  -
Cur Index Start: -
Cur Index: 0            Max Index: 2            Index ID: 0
Cur Phase: 0          ( -     )   Max Phase: 0
Cur Count: 0                      Max Count: 0
Total Row Count: 375000

Retrieval Time: 02/08/2010 23:04:21
TbspaceID: 2        TableID: 6
Schema: TEST1    TableName: BIGRPT
PartitionID: 1      MaxPartition: 2
Access: Allow none
Status: Completed
Start Time: 02/08/2010 23:04:08   End Time: 02/08/2010 23:04:12
Total Duration: 00:00:04
Prev Index Duration:  -
Cur Index Start: -
Cur Index: 0            Max Index: 2            Index ID: 0
Cur Phase: 0          ( -     )   Max Phase: 0
Cur Count: 0                      Max Count: 0
Total Row Count: 375000