DB2 LUW表重组时机判定：两种查询语句该如何选择？

核心结论 #

仅用 REORG_PENDING = 'Y' 能覆盖必须立即重组的场景，但结合 NUM_REORG_REC_ALTERS > 0 可以实现主动预防式重组，避免业务突发中断。

两种条件的具体说明 #

• REORG_PENDING = 'Y'：强制重组场景
  当表累计3次「推荐重组」类ALTER TABLE操作后，会进入REORG挂起状态，此时表完全无法访问，必须立即执行重组才能恢复业务。这个条件筛选的是已经影响可用性的紧急情况。

• NUM_REORG_REC_ALTERS > 0：推荐重组场景
  该列记录了表上已执行的「推荐重组」类ALTER操作次数（比如添加列、修改列数据类型等）。虽然此时表仍可正常访问，但每执行一次这类操作都会增加后续触发挂起的风险。提前重组可以避免累计到3次时突然出现的业务中断。

两种查询策略的适用场景 #

1. 仅处理紧急情况：如果运维策略是只在表不可用时才处理，原查询足够：

   SELECT TABNAME FROM SYSIBMADM.ADMINTABINFO WHERE TABSCHEMA = 'DB2ADMIN' AND REORG_PENDING = 'Y'
   

2. 主动预防业务中断：如果希望提前处理潜在风险，避免突发的表不可用问题，推荐使用包含NUM_REORG_REC_ALTERS > 0的查询：

   SELECT TABNAME FROM SYSIBMADM.ADMINTABINFO WHERE TABSCHEMA = 'DB2ADMIN' AND (REORG_PENDING = 'Y' OR NUM_REORG_REC_ALTERS > 0)
   

额外建议 #

• 核心业务表建议采用主动预防策略，定期检查并重组NUM_REORG_REC_ALTERS > 0的表，避免累计到3次触发挂起。
• 重组操作会占用系统资源，建议在业务低峰期执行，同时做好备份。

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