---
title: 转储错误，错误代码 4138/ORA-01555-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于转储错误，错误代码 4138/ORA-01555相关的常见问题和使用技巧，帮助您快速解决转储错误，错误代码 4138/ORA-01555的难题。
---
切换语言

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

划线反馈

# 转储错误，错误代码 4138/ORA-01555

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

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

当读事务很长时，租户进行转储会报 4138/ORA-01555 错误。本文介绍该错误的处理方法。

## 适用版本

OceanBase 数据库 V2.X 及以后的版本

## 问题现象

当读事务很长，租户进行转储时会出现以下错误。

```unknow
Oracle 租户：
ORA-01555：snapshot too old
MySQL 租户：
ERROR 4138 ( HY000 ): Request to read too old versioned data

```

对应错误码，日志中会记录以下信息，表示无法找到指定版本的历史数据。

```unknow
[2019-05-14 14:30:05.533606] WARN [STORAGE] get_inc_read_tables (ob_table_store.cpp:592) [98811][1313][YA4110AF40426-000588D011D3DED2] [lt=12] [dc=0] not table found for specified version((ret=-4138, major_sstable=0x7f9b8326a140, snapshot_version=1557815286383342, *this={this:0x7f9f4775f290, pkey:{tid:1110506744528557, partition_id:0, part_cnt:0}, table_id:1110506744528557, uptime:1557815401424782, table_count:2, start_pos:0, inc_pos:1, is_ready_for_read:true, replay_tables:[{table_type:1, pkey:{tid:1110506744528557, partition_id:0, part_cnt:0}, table_id:1110506744528557, trans_version_range:{multi_version_start:1557805624036243, base_version:0, snapshot_version:1557805624036243}, version:"41-0-0"}, {table_type:4, pkey:{tid:1110506744528557, partition_id:0, part_cnt:0}, table_id:1110506744528557, trans_version_range:{multi_version_start:1557815324038719, base_version:1557805624036243, snapshot_version:1557815324038719}, version:"0-0-0"}], [{i:0, type:1, partition_id:0, version:"41-0-0", version_range:{multi_version_start:1557805624036243, base_version:0, snapshot_version:1557805624036243}, ref:2}, {i:1, type:4, partition_id:0, version:"0-0-0", version_range:{multi_version_start:1557815324038719, base_version:1557805624036243, snapshot_version:1557815324038719}, ref:2}, ]}, *last_memtable={ObITable:{this:0x7f9ae6e669e0, key:{table_type:0, pkey:{tid:1110506744528557, partition_id:0, part_cnt:0}, table_id:1110506744528557, trans_version_range:{multi_version_start:1557815324038719, base_version:1557815324038719, snapshot_version:9223372036854775807}, version:"0-0-0"}, ref_cnt:2}, timestamp:1557815324045746, active_trx_count:0, state:0, max_schema_version:1557815227050056, write_ref_cnt:0, local_allocator:{ListHandle:{freeze_stat:1, id:62, clock:64975960024}, host:0x7fa2e58316f8, arena_handle:{allocated:376315264}}})

```

## 可能原因

OceanBase 数据库转储的数据会保留多个版本的历史数据行，您可以通过 `undo_retention` 来控制转储中保留的多版本数据范围。undo_retention 默认为 0（单位为秒），表示仅保留当前最新版本的数据。

这些多版本信息可以用来构造一致性读以及用于一系列的闪回，如果闪回请求的时间点在开启 `undo_retention` 前，或者闪回请求的时间点距离现在的时间大于 `undo_retention` 的设置，则会出现该问题。

有关 `undo_retention`的详细信息，参见《OceanBase 数据库 参考指南》中的 **系统变量** 章节。

## 解决方式

可以通过调整 `undo_retention` 的值来缓解该问题。

```unknow
obclient> SET GLOBAL undo_retention=7200;

```

该配置表示开启多版本转储，并且转储文件保留 7200 秒以内的多版本行数据，这部分数据会在多次转储中保留。

#### 注意

租户开启多版本转储后，大版本合并会保留对应增量转储文件，但 major SSTable 中不会存放多版本数据。避免对该参数设置过大，该参数过大时可能导致合并超时。

## 注意事项

多版本查询的生效时间在设置 `undo_retention` 后，并不能立刻实现多版本回溯到 `undo_retention` 之内的任何时间。例如在时间点 T1 设置了 `undo_retention=900s`，此时并不能回溯任何 900s 内的版本；需要等到时间点 T2 = T1 + 900s 后，才可以查询 T1~T2 的数据。这是由于多版本数据需要时间来填充。

上一篇

[undo_retention 介绍](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207639)

下一篇

[OB_MINOR_FREEZE_NOT_ALLOW(-4263)](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000209924) ![有帮助](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) 咨询热线
