---
title: 物理恢复失败报错 can not find table key from meta(ret=-4016-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于物理恢复失败报错 can not find table key from meta(ret=-4016相关的常见问题和使用技巧，帮助您快速解决物理恢复失败报错 can not find table key from meta(ret=-4016的难题。
---
切换语言

- 简体中文
- English

划线反馈

# 物理恢复失败报错 can not find table key from meta(ret=-4016

更新时间：2026-07-31 09:11

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

## 问题现象

恢复任务出现 -4016 错误，同时查看日志出现 `can not find table key from meta(ret=-4016` 报错信息。

```shell
observer.log.20240124123133556:[2024-01-24 12:31:32.188738] WDIAG [STORAGE] inner_init_ (ob_storage_restore_struct.cpp:533) [202143][T2366_TABLET_RE][T2366][YFA30BA2DA6A-00060FA0736E816F-0-0] [lt=33][errcode=-4016] can not find table key from meta(ret=-4016, table_key={tablet_id:{id:246243}, column_group_idx:0, table_type:"MAJOR", scn_range:{start_scn:{val:0, v:0}, end_scn:{val:1705990711226767984, v:0}}})

```

## 关键诊断信息

### 触发条件

问题触发条件比较复杂，需要有备份与 transfer，合并，IO 错误等场景同时并发，导致备份做索引合并的时候使用的 sstable meta 和 sec sstable meta 版本不匹配，导致恢复的时候找不到一致的 sstable meta 导致报错 -4016。

### 事前巡检

检查是否开启了 enable_transfer 或者检查是否开启了自适应合并 `_enable_adaptive_compaction`。

### 事后诊断

在合并、transfer 和备份相互独立的情况下可能会出现问题。可以查询 `__all_virtual_backup_skipped_tablet_history`，检查是否存在 `skipped_type='TRANSFER'` 的 tablet 以及备份是否发生过 retry。如果存在这样的记录，则有可能触发之前提到的问题。

```shell
MySQL [oceanbase]> SELECT A.task_id
       FROM __all_virtual_backup_skipped_tablet_history A
       INNER JOIN __all_virtual_backup_ls_task_info_history B ON A.task_id = B.task_id
       WHERE A.skipped_type = 'TRANSFER' AND B.retry_id <> 0;

```

输出结果如下：

```shell
+---------+
| task_id |
+---------+
|       1 |
+---------+
1 row in set (0.01 sec)

```

## 问题原因

备份、transfer、合并和外部存储介质的 I/O 出现错误这四种情况同时发生，导致备份索引文件上备份记录的 SSTable Meta 版本与 SEC SSTable Meta 版本对应的 SSTable 不是相同版本，从而导致错误。

## 问题的风险及影响

物理恢复失败，报错-4016。

## 影响租户

影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。

## 影响版本

OceanBase 数据库企业版 V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之后版本。

## 解决方法

- 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.1 BP4（oceanbase-4.2.1.4-104000062024022914）及之后版本。
 - 使用其他正常的备份集进行恢复。

## 规避方法

该问题发生在备份期间，需要同时进行 transfer、medium compaction 和备份，并且可能会遇到一些可重试错误（例如写入 OSS 失败）。只要其中任何一种因素不发生，这个问题就不会出现。因此以下给出两种在线上规避这个问题的方法。

- 降低备份和 transfer 并发的概率。

  在备份期间可以考虑关闭 Transfer。

  ```shell
  obclient> alter system set enable_transfer = false tenant = xxx;

  ```
 - 降低备份与 medium/major compaction 同时发生的机率。

  降低备份与合并同时发生的机率。假若问题暂未出现，可首先在租户级别 `_enable_adaptive_compaction` 配置，并确保数据合并完成后再进行备份，以确保该操作不会相互影响。

  ```shell
  obclient> alter system set _enable_adaptive_compaction = false tenant = xxx;

  ```

Previous

[Transfer 导致物理恢复完成后某些副本不可读](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001298182)

Next

[备租户合并卡住](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000766225) ![有帮助](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) 咨询热线