---
title: 延迟删除异常导致节点冗余副本增长或 server_event_history 大量膨胀问题分析-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于延迟删除异常导致节点冗余副本增长或 server_event_history 大量膨胀问题分析相关的常见问题和使用技巧，帮助您快速解决延迟删除异常导致节点冗余副本增长或 server_event_history 大量膨胀问题分析的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

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

更新时间：2026-08-25 08:16

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

## 问题现象

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

## 关键诊断信息

### 触发条件

- 集群表数量多、大量分区需延迟删除。
 - SYS 租户内存较小，导致 schema cache 被挤占，后台表组自检任务执行缓慢（问题集群 SYS 租户内存低于正常集群，16G vs 30G）。

### 事前巡检

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

### 事后诊断

- 查询主库待延迟删除的冗余副本数量：

```sql
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`，满足延迟删除条件。
 - 表组自检任务执行缓慢，说明瓶颈在于资源不足导致的性能下降。

## 问题原因

该问题为 OceanBase 内核已知 BUG，属于 3.x 版本延迟删除机制的缺陷场景。当集群表数量过多、大量分区需延迟删除，且 SYS 租户内存较小导致 schema cache 被挤占时，后台表组自检任务执行缓慢，阻塞了延迟删除任务的调度队列；一旦某次调度失败，后续任务无法被重新加入队列，导致任务丢失，延迟删除彻底失效，造成冗余分区持续堆积。大量分区等待物理回收时持续产生 GC 事件，导致 `__all_server_event_history` 表大量膨胀。

## 问题的风险及影响

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

## 影响租户

| sys | MySQL | Oracle |
| --- | --- | --- |
| YES | YES | YES |

## 影响版本

| 影响版本 |
| --- |
| 3.x 所有版本 |

## 解决方法

1. 调大 SYS 租户内存，确保 schema cache 有足够的空间，使表组自检任务能正常执行，从而恢复延迟删除任务的调度（会导致备库不同步）。
 2. 若无法调大内存，可手动执行应急方案（会导致备库不同步）：
      1. 在 sys 租户下执行错误注入命令，阻塞表组自检：`alter system set_tp tp_no = 104, error_code = 4016, frequency = 1;`
      2. 切换 RS（RootService）。
      3. 预期 10 分钟左右，观察如下 SQL 有新增返回，证明 GC 任务开始执行：`select * from __all_rootservice_event_history where event = 'force_drop_schema' order by gmt_create desc limit 20;`
      4. 监控待 GC 分区数，需要等待至少 30 分钟以上才会减少：`select count(*) from __all_virtual_clog_stat where table_id in (select table_id from __all_virtual_table_history where drop_schema_version > 0);`
      5. 待延迟删除分区清空后，回滚错误注入命令：`alter system set_tp tp_no = 104, error_code = 4016, frequency = 0;`
 3. 建议在恢复后重建备库，以确保主备数据一致性，避免因延迟删除恢复导致备库不同步问题。

## 规避方式

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

上一篇

[带局部索引的表 add/drop/truncate 分区后 DML 出现 4377](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006830282) ![有帮助](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) 咨询热线