前言

DM9 提供SP_REORGANIZE_INDEX_ONLINE在线索引碎片整理存储过程，可以在业务不停机场景回收索引空闲空间。在实际运维场景中，会遇到运维人员主动终止会话、会话因数据库连接超时被切断等情况，导致碎片整理任务中途停止。很多运维人员会担心会话强制终止后，是否会造成索引损坏、业务数据异常。本文站在使用者运维视角，描述该场景下的业务现象、核查手段、标准处置流程，不涉及内核底层实现细节。

1 场景现象描述

在业务低峰窗口执行在线索引碎片整理，任务尚未执行完毕，该执行会话被强制关闭。
触发会话终止常见几种诱因：

1. 运维执行存储过程期间，人为调用会话关闭接口终止该会话；
2. 客户端网络中断，数据库侧会话被断开；
3. 会话触发数据库会话超时参数，会话被数据库自动回收。

现象表现：碎片整理任务直接停止，存储过程不再继续执行，会话退出。业务应用访问该索引对应的表依旧正常，业务 DML 读写不受阻断。

注意区分：本次场景是整理任务的业务会话被关闭，不等同于数据库实例进程重启。

2 业务层面表现

1. 业务表与索引的数据完整性不受破坏，不会出现记录丢失；
2. 已经完成的索引页空间回收结果予以保留；尚未处理完成的索引部分，碎片维持中断前的状态；
3. 索引对象本身状态保持有效，不会变为不可用，业务查询、增删改可以正常使用该索引；
4. 不会产生数据库级别的故障，不需要执行数据库实例重启操作。

3 事后核查操作（使用公开系统视图）

任务中断之后，建议做两步简单核验，确认索引对象状态正常。

1）确认索引对象状态有效

select INDEX_NAME,STATUS from USER_INDEXES where TABLE_NAME='你的表名';

STATUS 为VALID代表索引状态正常可用。

2）可读取索引页相关统计信息，观察碎片回收进度，对比任务执行前后的统计变化，确认哪些部分已经完成回收。

提示：可结合业务基线数据对比，判断碎片剩余情况。

核查要点：只要索引状态为 VALID，业务就可以正常使用，不需要第一时间重建索引。

4 标准处置流程

1. 排查会话被终止的外部原因：确认是人为操作、网络抖动，还是会话超时参数触发，消除外部干扰因素；
2. 确认索引状态为 VALID，业务访问无报错；
3. 在合适的业务低峰窗口，重新调用SP_REORGANIZE_INDEX_ONLINE存储过程，继续对目标索引执行碎片整理；
4. 执行结束后再次核对索引统计信息，确认碎片回收达到预期目标。

误区提醒：遇到整理任务会话中断，不要直接执行索引重建。重建索引会消耗更多资源，并非该场景下的必要操作。

5 运维前置建议，降低会话中断风险

1. 执行在线碎片整理优先选择业务低峰时段，减少网络波动、运维操作冲突；
2. 执行前检查客户端会话超时参数，避免长时间运行的存储过程被会话超时机制强行切断；
3. 执行碎片整理前，留存索引相关统计基线，方便任务中断后对比执行进度；
4. 如果环境网络不稳定，建议使用服务端本地会话执行存储过程，减少客户端网络异常带来的会话断开。

6 小结

当SP_REORGANIZE_INDEX_ONLINE执行会话被强制终止时，DM9 可以保障索引与业务数据安全，索引对象维持可用状态，已经完成的空间回收结果保留。处理核心是消除会话中断的外部诱因，确认索引状态正常后，重新执行碎片整理存储过程即可继续完成工作，无需盲目重建索引。掌握该场景的处置逻辑，可以减少不必要的高危运维操作，保障国产化数据库线上运维稳定。