---
title: 延迟删除异常导致节点冗余副本增长或内部表 __all_server_event_history 大量膨胀问题分析-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于延迟删除异常导致节点冗余副本增长或内部表 __all_server_event_history 大量膨胀问题分析相关的常见问题和使用技巧，帮助您快速解决延迟删除异常导致节点冗余副本增长或内部表 __all_server_event_history 大量膨胀问题分析的难题。
---
切换语言

- 简体中文
- English

划线反馈

# 延迟删除异常导致节点冗余副本增长或内部表 __all_server_event_history 大量膨胀问题分析

更新时间：2026-07-01 08:31

适用版本： V3.1.x、V3.2.x 内容类型：Troubleshoot  

## 问题现象

在集群表数量多、大量分区需延迟删除的场景下，出现延迟删除任务未执行，导致大量已删除表的分区长期未被物理回收，分区数持续增长，存在单节点分区数达到上限的风险。用户观察到存在以 `DELAY_DELETE` 开头的表，且 `__all_tenant_gc_partition_info` 表为空，但延迟删除任务未触发，无相关日志输出。同时可能观察到 `__all_server_event_history` 中 GC 模块 `event = 'gc_candidates'` 的事件大量膨胀。

## 关键信息

- 主库有大量待延迟删除副本冗余，查询方法：`select count(*) from __all_virtual_clog_stat where table_id in (select table_id from __all_virtual_table_history where drop_schema_version > 0);`。
 - 内部表 `__all_rootservice_event_history` 中长期没有 `event = 'force_drop_schema'` 事件，表明任务未被成功调度或执行。
 - 内部表 `__all_tenant_gc_partition_info` 为空，说明系统未记录待回收的分区信息，但实际存在延迟删除的表。
 - `drop_schema_version > 0` 且 `reserved_schema_version = 0`，满足延迟删除条件。
 - 表组自检任务执行缓慢，说明瓶颈在于资源不足导致的性能下降。
 - 问题集群 SYS 租户内存低于正常集群（16G vs 30G），为关键资源瓶颈。

## 问题原因

该问题为 OceanBase 内核已知 BUG，属于 V3.x 版本延迟删除机制的 Bad Case。当集群表数量过多、大量分区需延迟删除，且 SYS 租户内存较小导致 Schema Cache 被挤占时，后台表组自检任务执行缓慢，阻塞了延迟删除任务的调度队列。由于延迟删除任务依赖于定时调度机制（`schedule_force_drop_schema_task` → `add_timer_task`），一旦某次调度失败，后续任务将无法被重新加入队列，导致任务丢失，延迟删除彻底失效，造成冗余分区持续堆积。大量分区等待物理 GC，会持续写 `gc_candidates` 事件，导致内部表 `__all_server_event_history` 大量膨胀。

## 问题的风险及影响

单节点冗余副本持续增长，可能达到单节点分区数上限，引发写入失败或集群稳定性风险；内部表 `__all_server_event_history` 不断膨胀影响存储资源利用率，增加运维管理复杂度。

## 适用版本

OceanBase 数据库 V3.x 所有版本。

## 解决方法

1. 调大 SYS 租户内存，确保 Schema Cache 有足够的空间，使表组自检任务能正常执行，从而恢复延迟删除任务的调度。（会导致备库不同步）
 2. 若无法调大内存，可考虑手动执行应急方案（会导致备库不同步）：

   a. 在 SYS 租户下，执行 `ALTER SYSTEM SET_TP TP_NO = 104, ERROR_CODE = 4016, FREQUENCY = 1;`。（错误注入阻塞表组自检）

   b. 切 RS。

   c. 预期 10 分钟左右观察如下 SQL 有新增返回。

   ```sql
   SELECT * FROM oceanbase.__all_rootservice_event_history WHERE EVENT='force_drop_schema' ORDER BY gmt_create DESC LIMIT 20;

   ```

   证明 GC 任务开始执行。

   d. 监控待 GC 分区数。

   ```sql
   SELECT COUNT(*) FROM oceanbase.__all_virtual_clog_stat WHERE table_id IN (SELECT table_id FROM oceanbase.__all_virtual_table_history WHERE drop_schema_version > 0);

   ```

   需要等待至少 30 分钟以上才会减少。

   e. 待延迟删除分区清空后，执行回滚命令。

   ```sql
   ALTER SYSTEM SET_TP TP_NO = 104, ERROR_CODE = 4016, FREQUENCY = 0;

   ```
 3. 建议在恢复后重建备库，以确保主备数据一致性，避免因延迟删除恢复导致备库不同步问题。

## 规避方式

- 避免 SYS 租户内存配置过低，尤其在表数量多、DDL 频繁的场景下。
 - 存在冗余副本时，定期监控 `__all_rootservice_event_history` 中 `event = 'force_drop_schema'` 的事件，确认正常运行。监控延迟删除任务日志，及时发现延迟删除异常。
 - 在集群表数量较多或频繁执行 DDL 操作前，提前评估 SYS 租户资源是否充足。

Previous

[lob 过程中语句超时导致连环 core](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002165952)

Next

[OceanBase 数据库事务问题排查指南](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000000026) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线