---
title: 带局部索引的表 add/drop/truncate 分区后 DML 出现 4377-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于带局部索引的表 add/drop/truncate 分区后 DML 出现 4377相关的常见问题和使用技巧，帮助您快速解决带局部索引的表 add/drop/truncate 分区后 DML 出现 4377的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

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

划线反馈

# 带局部索引的表 add/drop/truncate 分区后 DML 出现 4377

更新时间：2026-08-26 12:01

适用版本： V4.4.x 内容类型：Troubleshoot  

## 基本信息

**问题现象**
 对某些特定行执行 DELETE 或 UPDATE 操作时，必现 4377 错误（`OB_ERR_DEFENSIVE_CHECK`）。该错误的本质是主表中存在这些行的记录，但对应的索引表中没有。

**适用版本**
 OceanBase 4.4.2 BP1（oceanbase-4.4.2.1-101080012026081217）

## 问题分析

### 触发条件

同时满足以下三个条件会导致 Schema 数据不正确，但此时不一定会立即出现 4377 错误：

1. 集群使用了 4.4.2 BP1 版本的 observer。
 2. 存在分区表，且表上建有局部索引。最近一次执行的 DDL 操作是 `ALTER TABLE ADD/DROP/TRUNCATE PARTITION` 等分区变更操作。
 3. Schema History 的回收发生在上述分区 DDL 操作之后。

### 错误产生机制

要最终产生 4377 错误，还需要在写入数据时通过延迟校验方式获取 Table Schema，典型场景包括：

- 写入数据时存在远程执行。
 - 远程执行的对端机器 Schema 缓存中没有源端机器传递的 Schema Version 对应的信息（可能是源端机器的 Schema 刷新过于落后，或对端机器缓存发生切换等情况）。

## 解决方案

### 事前巡检

对于尚未升级到 4.4.2 BP1 的集群：

- 暂停升级。
 - 直接升级到 4.4.2 BP1 Hotfix1 版本。
 - 无需进行额外处理。

对于已升级到 4.4.2 BP1，但尚未升级到 4.4.2 BP1 Hotfix1 的集群：  
 请尽快执行以下操作进行规避：

1. 记录 `schema_history_expire_time` 配置项的原值，以便后续恢复。
 2. 在 sys 租户下执行以下命令，调大 Schema History 的过期时间：

```sql
ALTER SYSTEM SET schema_history_expire_time = '30d' TENANT = ALL;

```

3. 在 sys 租户下执行以下命令，关闭所有用户租户的 Schema History 回收定时任务（需为每个用户租户单独执行，替换 `tenant_name`）：

```sql
CALL DBMS_SCHEDULER.DISABLE('SCHEDULED_RECYCLE_SCHEMA_HISTORY') TENANT = 'tenant_name';

```

4. 在 sys 租户下执行以下 SQL，确定最近一次 Schema History 回收的 Schema Version：

```sql
-- VALUE1 列为最近一次回收的 schema version
SELECT * FROM cdb_ob_tenant_event_history
WHERE
  tenant_id = xxx  -- 租户 id
  AND event LIKE '%batch_recycle_by_tenant%'
ORDER BY timestamp DESC LIMIT 1;

```

5. 在 sys 租户下执行以下 SQL，查询可能存在潜在问题的主表：

```sql
SELECT DISTINCT t1.tenant_id, t1.table_id, t1.schema_version
FROM oceanbase.__all_virtual_table t1
WHERE EXISTS
(
  SELECT 1 FROM oceanbase.__all_virtual_table t2
  WHERE
    t2.tenant_id = t1.tenant_id
    AND t2.data_table_id = t1.table_id
    AND t2.schema_version > t1.schema_version
)
AND t1.schema_version < [上一步查询出的回收版本号];

```

如果查询结果不为空，则说明这些表存在 Schema 不一致的风险。

### 修复与恢复

1. **尽快升级**到 4.4.2 BP1 Hotfix1 版本。
 2. 升级完成后，执行以下恢复操作：
      - 在 sys 租户下执行以下命令，将 Schema History 过期时间恢复为原值：

```sql
ALTER SYSTEM SET schema_history_expire_time = '原值' TENANT = ALL;

```

```plain
- 在 sys 租户下执行以下命令，重新打开所有用户租户的 Schema History 回收定时任务（需为每个用户租户单独执行，替换 `tenant_name`）：

```

```sql
CALL DBMS_SCHEDULER.ENABLE('SCHEDULED_RECYCLE_SCHEMA_HISTORY') TENANT = 'tenant_name';

```

## 事后诊断

当出现 4377 错误时，可以通过以下 SQL 进行诊断，确认问题是否由本案例所述原因导致：

```sql
-- 诊断 SQL
SELECT DISTINCT t1.tenant_id, t1.table_id, t1.schema_version
FROM oceanbase.__all_virtual_table t1
WHERE EXISTS
(
  SELECT 1 FROM oceanbase.__all_virtual_table t2
  WHERE
    t2.tenant_id = t1.tenant_id
    AND t2.data_table_id = t1.table_id
    AND t2.schema_version > t1.schema_version
)
AND t1.schema_version < [最近一次回收的 schema version];

```

如果查询结果不为空，则表明问题符合本案例描述的场景。

上一篇

[查询列包含 UDF 导致 OMA 回放 SQL 执行缓慢的排查与优化方案](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006896962)

下一篇

[延迟删除异常导致节点冗余副本增长或 server_event_history 大量膨胀问题分析](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006897663) ![有帮助](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) 咨询热线