DB2数据库在长时间运行后，表空间的使用效率往往会呈现持续下降的趋势。这种下降并非数据增长本身造成的，而是数据在物理存储层面上的分布变得松散、无序。一次看似简单的DELETE操作，在DB2内部只是把对应数据页上的记录标记为删除，并不会立即压缩空间，也不会把页归还给表空间。后续的INSERT操作如果找不到合适的空闲位置，就会把这些空隙跳过，继续往更高的页上写数据。久而久之，表内充斥着大量半空的页，索引的叶子节点也因为频繁的页分裂而变得支离破碎。理解碎片产生的机制，是制定整理策略的第一步。
碎片产生的底层机制与影响评估
DB2的数据存储在数据页中，每个页的大小通常为4KB、8KB、16KB或32KB，由表空间的pagesize参数决定。当一条记录被UPDATE后变长，而原页上已经没有足够的连续空间容纳新版本时，DB2会触发行迁移——把整条记录搬到另一个有足够空间的页上，在原来的位置留下一个指向新页的指针。如果记录只是部分变长，则可能产生溢出记录，把超出部分写到单独的溢出页中。无论是行迁移还是溢出记录，都会导致读取一条逻辑记录需要跨越多个物理页，增加I/O开销。频繁的DELETE操作则会在页内制造大量不可复用的碎片空间，尤其是当删除的记录大小不一、分布不均时，页利用率可能下降到50%以下。
索引碎片同样不可忽视。B+树索引在频繁的随机插入下，叶子节点会不断发生页分裂。页分裂的过程把一个满页的一部分记录移动到新分配的页上，这个新页通常位于表空间的高位区域，与原来的叶子节点在物理上并不相邻。随着分裂次数增多，索引的物理顺序与逻辑顺序严重脱节，范围扫描的效率急剧下降。此外，分裂后留下的半空页不会被自动合并，索引的存储占用量持续膨胀，但有效数据占比却在降低。要量化这些问题的严重程度，就需要借助REORGCHK命令的输出指标，比如F1到F7各字段分别反映了表重组需求、索引重组需求、页利用率等维度。
用REORGCHK检测碎片：指标解读与判断标准
REORGCHK是DB2提供的碎片检测工具，它基于当前统计信息计算出一系列重组指标。执行REORGCHK ON TABLE ALL会扫描数据库中所有用户表的元数据，输出每个表的F1至F7指标。其中F1表示需要进行表重组的程度，数值越大说明表内碎片越严重；F2表示需要重建索引的程度；F3是页利用率指标，反映数据页平均被填满的比例。一般来说，当F1或F2的值超过60时，就应该考虑安排REORG操作；如果F3低于70%，说明有超过30%的空间处于闲置状态，表重组的收益会比较明显。需要注意的是，REORGCHK的准确性完全依赖于统计信息的时效性，如果长时间没有执行过RUNSTATS，这些指标可能会严重失真。
在实际运维中，建议先执行一次RUNSTATS更新统计信息，再运行REORGCHK。下面的代码展示了完整的检测流程：
-- 更新表的统计信息 RUNSTATS ON TABLE sales.order_details WITH DISTRIBUTION AND DETAILED INDEXES ALL -- 检查全库所有表的碎片情况 REORGCHK ON TABLE ALL -- 只检查指定schema下的表 REORGCHK ON SCHEMA sales
输出结果中的F1和F2指标需要结合表的实际大小和访问频率来综合判断。一张几十万行的小表，即使F1指标偏高，REORG的收益可能也微乎其微，因为全表扫描本身就很快。但如果是几千万行的大表，F1偏高的代价就是每次扫描都要多读取数十万个半空页，这时重组的价值就非常突出了。另一方面，对于以随机点查为主的表，索引碎片的影响远大于表碎片，应该优先关注F2指标并重建索引。
REORG TABLE实操：在线与离线模式的选择
REORG TABLE是DB2中用于整理表碎片的核心命令。它的基本思路是读取表中的所有有效记录，按照索引的物理顺序或者指定的排序键重新写入新的数据页中，从而消除页内碎片、合并半空页、重建索引。REORG支持两种执行模式：离线模式（CLASSIC）和在线模式（INPLACE）。离线REORG会在执行期间对目标表加排他锁，阻塞所有读写操作，但整理效果最彻底，不会产生额外的日志量，适合在维护窗口内对中小型表执行。在线REORG则允许在重组过程中对表进行读写访问，但需要借助一个临时表空间来存放中间数据，执行时间更长，且对系统资源的消耗也更大。
选择哪种模式需要根据表的可用性要求来判断。对于核心业务表，通常只能选择在线REORG。下面的代码分别展示了两种模式的典型用法：
-- 离线REORG：锁表执行，效果最彻底 REORG TABLE sales.order_details -- 在线REORG：允许读写，需要临时表空间 REORG TABLE sales.order_details INPLACE ALLOW WRITE -- 在线REORG：索引也需要重建时 REORG TABLE sales.order_details INPLACE INDEX sales.idx_order_date ALLOW WRITE -- REORG后必须更新统计信息 RUNSTATS ON TABLE sales.order_details WITH DISTRIBUTION AND DETAILED INDEXES ALL
执行REORG之前有一个重要的前提条件需要确认：目标表所在的表空间必须有足够的空闲空间来容纳重组过程中的中间数据。在线REORG需要的额外空间大约是被重组表大小的10%到20%，如果表空间剩余空间不足，REORG会中途失败并回滚。对于超大表，建议在业务低谷期分批次执行，或者在执行前先进行表空间扩容。另外，REORG操作会产生大量事务日志，需要确保日志文件系统有足够的容量，否则同样会导致操作失败。一个常见的做法是在REORG前检查MON_GET_TABLESPACE视图中的可用空间，并估算日志用量。
表空间回收：高水位标记与REDUCE操作
表和索引经过REORG整理后，虽然数据在物理上变得紧凑了，但表空间的高水位标记（High Water Mark，简称HWM）并不会自动下降。HWM记录的是表空间中曾经分配过的最高页位置，它只会随着数据增长而上升，不会因为DELETE或REORG而自动回落。这意味着即使删掉了表中80%的数据，磁盘上依然保留着同样大小的容器文件，空间没有归还给操作系统。要让空间真正得到释放，必须显式地降低HWM并缩减容器。在DB2中，ALTER TABLESPACE语句提供了LOWER HIGH WATER MARK和REDUCE两个子句来完成这项工作。前者负责把HWM降低到当前实际使用的位置，后者则根据新的HWM来缩减容器的物理大小。
下面的代码展示了完整的表空间回收流程：
-- 查询表空间当前使用情况
SELECT
tbsp_name,
tbsp_used_pages,
tbsp_free_pages,
tbsp_total_pages,
DECIMAL(tbsp_used_pages * 1.0 / tbsp_total_pages * 100, 5, 2) AS used_pct
FROM sysibmadm.tbsp_utilization
WHERE tbsp_name = 'TS_SALES_DATA'
-- 降低高水位标记
ALTER TABLESPACE TS_SALES_DATA LOWER HIGH WATER MARK
-- 缩减容器大小，将空间归还给文件系统
ALTER TABLESPACE TS_SALES_DATA REDUCE
这里有一个关键细节：LOWER HIGH WATER MARK只会降低到当前所有数据页中最高的那个位置。如果表空间中有多个表，其中某个表的数据仍然位于较高的页上，HWM就无法降得太低。因此，在降低HWM之前，建议先对表空间内的所有大表执行REORG，把数据尽量往低位页压缩。此外，只有DMS（Database Managed Space）表空间和自动存储表空间支持REDUCE操作，SMS（System Managed Space）表空间由操作系统直接管理文件，DB2无法控制其物理大小。对于自动存储表空间，REDUCE会根据AUTO_RESIZE策略自动调整容器大小，如果关闭了自动调整，则和DMS一样手动缩减。缩减操作同样有日志开销，建议在维护窗口内执行。
自动化维护策略与长期监控方案
手工执行REORG和表空间回收虽然直接有效，但在表数量多、变更频繁的生产环境中，靠人工跟进每一张表的碎片状态是不现实的。DB2提供了自动维护机制，通过SYSPROC.AUTOMAINT_POLICY存储过程可以配置自动REORG策略和自动RUNSTATS策略。自动维护的核心思路是：系统按照预设的维护窗口周期性地检查表的碎片指标，当指标超过阈值时自动触发REORG操作，完成后自动更新统计信息。配置时需要设定维护窗口的开始时间和持续时间，以及碎片阈值的触发条件。下面是一个典型的自动维护配置示例：
-- 配置自动维护策略：每天凌晨2点到4点为维护窗口
CALL SYSPROC.AUTOMAINT_POLICY(
'AUTO_REORG',
'MAINTENANCE_WINDOW',
'02:00:00,04:00:00,ALL'
)
-- 设置自动REORG的触发条件
CALL SYSPROC.AUTOMAINT_POLICY(
'AUTO_REORG',
'POLICY',
'ON'
)
-- 配置自动RUNSTATS
CALL SYSPROC.AUTOMAINT_POLICY(
'AUTO_RUNSTATS',
'POLICY',
'ON'
)
自动维护虽然省心，但并非完全没有风险。在业务高峰期如果维护窗口设置不当，自动REORG可能会与在线业务争抢I/O资源。更稳妥的做法是结合定时脚本和人工审核：用REORGCHK定期生成碎片报告，通过脚本筛选出超过阈值的表，再由DBA确认后在维护窗口内执行。同时，建立表空间使用率的趋势监控也很有必要，通过MON_GET_TABLESPACE或SYSIBMADM.TBSP_UTILIZATION视图采集每日的使用率数据，一旦发现空间增长异常或碎片指标恶化，就能在问题扩大之前介入处理。碎片整理不是一次性工作，而是需要纳入日常运维体系的持续性任务。
最后需要强调的是，REORG和REDUCE都不是万能的。如果一张表的数据本身就在持续高速增长，那么任何整理都只是暂时缓解空间压力。更根本的解决思路在于：合理设计表结构，使用合适的页大小，为高频增删改的表设置合理的PCTFREE参数，从源头上减少碎片产生的概率。把预防措施和定期整理结合起来，才能让DB2数据库在长期运行中保持稳定的存储效率和查询性能。