---
title: 开启 TDE 后合并报错 -4334-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于开启 TDE 后合并报错 -4334相关的常见问题和使用技巧，帮助您快速解决开启 TDE 后合并报错 -4334的难题。
---
切换语言

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

划线反馈

# 开启 TDE 后合并报错 -4334

更新时间：2026-06-12 08:51

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

## 问题现象

开启 TDE 或修改加密算法后合并 OR 查询报错 -4334。

## 关键诊断信息

### 触发条件

主表有索引，开启 TDE 或修改加密算法。

### 事前巡检

```shell
SELECT
    t.table_id,
    CASE
        WHEN s.has_decrease THEN 'NOT INCREASING'
        ELSE 'INCREASING'
    END AS status
FROM (
  SELECT DISTINCT table_id
  FROM __all_virtual_table
  WHERE tenant_id = XXX
) t
LEFT JOIN (
  SELECT
  table_id,
  MAX(CASE WHEN progressive_merge_round < prev THEN 1 ELSE 0 END) AS has_decrease
  FROM (
    SELECT
    table_id,
    progressive_merge_round,
    LAG(progressive_merge_round) OVER (PARTITION BY table_id ORDER BY gmt_create) AS prev
    FROM __all_virtual_table_history where tenant_id = XXX
  ) sub
  GROUP BY table_id
) s ON t.table_id = s.table_id
WHERE s.has_decrease = 1;

```

上述 SQL 会查找 `progressive_merge_round` 出现回退的表，出现这种情况说明有 DDL 操作没有按预期推高 table schema 的 `progressive_merge_round`，但不一定会引发问题。 下面这条 SQL 可以根据第一条 SQL 查到的 table id 进行二次确认，观察 `progressive_merge_round` 是否确实有回退了：

```shell
SELECT gmt_create, gmt_modified, table_id, encryption, progressive_merge_round
FROM __all_virtual_table_history
WHERE tenant_id = XXX AND table_id = XXX
ORDER BY gmt_create;

```

### 事后诊断

合并卡，`__all_virtual_dag_warning_history` 的 diagnose info 列里有 -4334 的报错。

## 问题原因

开启 TDE 后需要修改主表和索引表的 table schema，将 `progressive_merge_round` 推高，存储感知到表的 schema 的 `progressive_merge_round` 被推高后，就会开启新一轮的渐进合并。**渐进合并开启后不会走微块重用**。 然而，开启加密/修改加密算法的 DDL 语句在实现上一直存在问题：索引表 schema 的 progressive_merge_round 不会按照预期推高，反而会出现回退，这就破坏了渐进合并强依赖的一个假设：**即任何涉及到数据重写的 DDL 都需要推高 `progressive_merge_round`**。这个问题会让合并无法按预期走渐进合并，反而走了支持微块重用的增量合并，导致合并在打开宏块做重写时，与增量数据无交叉的微块走了重用，有交叉的微块则使用新的加密算法被重写了一遍，最终导致**一个宏块同时包含了使用了不同加密算法的微块，后续再读这个宏块就会出现 -4334 问题，即宏块不能自解释了**。

OceanBase 数据库 V4.3.3 之前版本中没有该问题，因为任何 DDL 变更都会推高表的 schema version，在 V4.3.3 之前版本的合并逻辑中，只要 schema version 发生变化，都不会重用微块，所以即使加密后没走渐进合并，重写微块也能保证一个宏块中不会出现加密算法不同的微块。 而在 V4.3.3 之后版本，为了优化旁路导入后列存合并的性能，合并放开了 schema version 变化后微块必须重写的限制，这才导致 TDE 一直没有推 merge round 的问题被发现。

## 问题的风险及影响

合并失败，查询报错，数据不可读。

## 影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

## 影响版本

OceanBase 数据库企业版 V4.3.3 GA Hotfix1（oceanbase-4.3.3.0-100000412024101200）及之后版本、V4.3.5 GA（oceanbase-4.3.5.0-100000232024123020）及之后版本。

## 解决方法

- 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.3.5 GA Hotfix8（oceanbase-4.3.5.0-100080012025052715）版本、V4.3.5 BP1 Hotfix5（oceanbase-4.3.5.1-101050012025042323）版本、V4.3.5 BP2（oceanbase-4.3.5.2-102000162025051417）及之后版本。
 - 只有索引表会有问题，需要删除索引。

## 规避方式

1. 建表后先开启 TDE，再写数据。
 2. 开启 TDE 后，设置表的 `progressive_merge_round = 1`，走一次全量合并。

上一篇

[OceanBase 数据库 V3.2.4 版本合并超时 OBServer 日志报错 -4024 advance buffer failed](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002345058)

下一篇

[日志流均衡会转移哪种类型的表](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003332214) ![有帮助](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) 咨询热线