DB2 LUW：SQL0668N(原因码7)报错表为何未显示待重组状态？

SQL0668N 原因码7明确表示目标表处于待重组状态，但仅查询SYSIBMADM.ADMINTABINFO的REORG_PENDING列会遗漏多种场景，以下是全面识别待重组表及关联对象的方法：

1. 检查表级待重组状态（底层系统表） #

直接查询DB2核心系统表SYSIBM.SYSTABLES的REORG列，这是最权威的表级重组标识：

SELECT TABNAME, TABSCHEMA 
FROM SYSIBM.SYSTABLES 
WHERE TABSCHEMA = 'LIBRAT' 
  AND REORG = 'Y';

2. 排查分区表的分区级重组需求 #

如果目标表是分区表，分区级的待重组状态也会触发SQL0668N，需查询SYSIBM.SYSTABLEPART：

SELECT TABNAME, TABSCHEMA, PARTITION_NUMBER 
FROM SYSIBM.SYSTABLEPART 
WHERE TABSCHEMA = 'LIBRAT' 
  AND REORG = 'Y';

3. 检查关联索引的待重组状态 #

部分场景下，索引的待重组状态会导致表操作受限，需查询SYSIBM.SYSINDEXES：

SELECT INDNAME, TABNAME, TABSCHEMA 
FROM SYSIBM.SYSINDEXES 
WHERE TABSCHEMA = 'LIBRAT' 
  AND REORG = 'Y';

4. 扩展查询ADMINTABINFO的关联列 #

SYSIBMADM.ADMINTABINFO中的REORG_REQUIRED列会包含更多重组需求场景（比如分区级需求），结合REORG_PENDING一起查询：

SELECT TABNAME, TABSCHEMA, REORG_PENDING, REORG_REQUIRED 
FROM SYSIBMADM.ADMINTABINFO 
WHERE TABSCHEMA = 'LIBRAT' 
  AND (REORG_PENDING = 'Y' OR REORG_REQUIRED = 'Y');

补充说明 #

SQL0668N 原因码7的触发场景包括：

• 表结构变更后未重组
• 分区表的某个分区需重组
• 索引损坏或需重组
• 表空间状态导致的间接重组需求

通过上述多维度查询，就能覆盖所有可能触发该报错的待重组场景。

内容的提问来源于stack exchange，提问作者Dave Clark