---
title: 强关归档场景下物理恢复卡住-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 强关归档场景下物理恢复卡住相关的常见问题和使用技巧，帮助您快速解决 强关归档场景下物理恢复卡住的难题。
---
切换语言

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

划线反馈

# 强关归档场景下物理恢复卡住

更新时间：2026-05-12 09:06

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

## 问题现象

物理恢复场景，执行 `alter system restore` 做物理恢复后，物理恢复卡住，租户同步位点不推进。

通过查看内部表 `__all_rootservice_event_history` 有关物理恢复任务执行状态，查询语句如下。

```shell
select * from oceanbase.__all_rootservice_event_history where module like 'physical_restore' and event like 'change_restore_status' and value1=xxx order by gmt_create;

```

上述查询语句中 xxx 填写该次物理恢复任务的 job id。

物理恢复在卡 `PHYSICAL_RESTORE_WAIT_RESTORE_TO_CONSISTENT_SCN` 状态，不往下推进。

![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/backup-and-restore/20250124physical-recovery-stuck02.png)

## 关键诊断信息

### 触发条件

主库至少执行过两轮归档，比如两轮归档分别为 `round 1` 和 `round 2`，并且 `round 1` 在关闭归档任务时，访问归档介质出现过问题（如归档介质写满、归档介质权限变更、归档介质异常等），该场景下关闭归档会导致 `round 1` 的归档元信息缺失。如果物理恢复时依赖的归档日志属于 `round 2`，但由于 `round 1` 元文件的缺失和实现上的原因，会导致消费日志被错误定位到 `round 1`，而此时 `round 1` 的日志很有可能已经被删除/回收，进而导致无法消费日志，恢复任务卡住。

### 事前巡检

首先，到物理恢复指定的归档目录下，查看 `rounds` 目录下的文件。假设当前有两轮归档，正常情况下，目录下的文件内容如下。

```shell
round_d1001r1_start.obarc
round_d1001r1_end.obarc
round_d1001r2_start.obarc

```

但在该问题场景下，目录下的文件内容如下。

```shell
round_d1001r1_start.obarc
round_d1001r2_start.obarc

```

即 `round 1` 的 `end` 元文件缺失，此时如果恢复依赖的日志内容是 `round 2`，那么需要将 `round1` 的 `start` 元文件先从目录中移走再执行恢复，恢复完成后再移回。

### 事后诊断

查看物理恢复进度/历史表，获取恢复租户 `restore` 任务对应的 `backup_piece_list` 语句如下。

```shell
select tenant_id, backup_piece_list from cdb_ob_restore_progress where tenant_id=XXXX;

```

查询得到的 `backup_piece_list` 可能为：`s3://xxx/bucket_name/tenant_1/archive/piece_d1001r2p2?host=xxxxxxx`。

然后根据关键字 `T1002_RFL` 查看 OBServer 日志信息，打印的日志内容如下。

```shell
INFO  [ARCHIVE] build_restore_prefix (ob_archive_path.cpp:43) [15041][T1002_RFLWorker][T1014][YXXXXXXXXXXXXX-XXXXXXXXXXX-0-0] [lt=0] build restore prefix succ(prefix={cur_pos:xxx, path:"s3://xxx/bucket_name/tenant_1/archive/piece_d1001r1p1/logstream_1/log"})

```

`piece_d1001r2p2` 与 `piece_d1001r1p1` 不一致，后者偏小且 `rounds` 目录下缺失对应的 `round end` 元文件，此时说明遇到了该问题。

## 问题原因

内核 BUG。

## 问题的风险及影响

物理恢复/归档备库卡住。

## 影响租户

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

## 影响版本

OceanBase 数据库企业版 V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本、V4.3.0 （oceanbase-4.3.0.0-100000072024020200）及之后版本。

## 解决方法

- 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.5（oceanbase-4.2.5.0-100000082024102022）版本。
 - 确认物理恢复卡住后，按照上述的检查确认该问题后，获取恢复任务依赖的 `backup_piece_list`，比如依赖的最小日志轮次为 `round2（piece_d1001r2p2` 中 `r2` 代表 `round 2`），然后到归档目录的 `rounds` 目录下，将 `round 1` 对应的 `round_d1001r1_start.obarc` 文件暂时移动到其他位置（如果有多个缺失的 `round`，均需要移动），等物理恢复任务完成后再将该文件移回。

  上述操作后，如果本次物理恢复任务最终失败，需要重新发起恢复任务，然后再将文件移回到原来位置。

## 规避方式

尽量保证归档介质可用，避免访问归档介质出现问题。

上一篇

[归档问题排查](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001231133)

下一篇

[日志归档延迟或日志归档慢的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001808671) ![有帮助](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) 咨询热线