OceanBase 备份与时间点恢复 100 条命令

前言

OceanBase 的物理备份按租户做。数据备份保存一个快照，日志归档持续保存快照之后的变更；要恢复到某个时间点，两边都得接得上。集群有多个日志流时，不能只看一条 LS 的归档进度就认定整个租户可恢复。

这篇从归档模式、备份 Job、备份集依赖和恢复窗口查起，再写受控的备份与隔离恢复。遇到误操作或备份告警，可以按租户 ID、备份集 ID 和目标 SCN 逐项核对，建议先收藏。

示例基于 OceanBase 数据库分布式版 V4.3.0、MySQL 模式。集群级清单在 root@sys 执行；租户 ID、租户名、备份路径和 SCN 均换成现场值。示例只引用该目标版本能核对的视图，不把较新版本的恢复校验功能写进来。

OceanBase 租户数据备份、日志归档和恢复路径 OceanBase 租户数据备份、日志归档和恢复路径

图中数据备份和日志归档是两条独立输入。恢复时 Root Service 创建租户的日志流，Leader 负责恢复数据与日志，Follower 再拉取；恢复结果以所有 LS 完成为准。

一、先确定租户备份的两条链

1. 查看目标租户是否处于归档模式

SQL

1-- root@sys；租户名按现场替换
2SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, LOG_MODE
3FROM   oceanbase.DBA_OB_TENANTS
4WHERE  TENANT_NAME = 'app_tenant';

LOG_MODE=ARCHIVELOG 只是说明租户允许归档。要做时间点恢复，还必须看归档任务有没有运行、检查点推进到哪里，以及数据备份集是否可用。

2. 查看目标租户当前归档轮次与检查点

SQL

1-- root@sys
2SELECT TENANT_ID, DEST_ID, ROUND_ID, DEST_NO,
3       STATUS, START_SCN, CHECKPOINT_SCN,
4       CHECKPOINT_SCN_DISPLAY, PATH
5FROM oceanbase.CDB_OB_ARCHIVELOG
6WHERE TENANT_ID = 1002;

把 STATUS、ROUND_ID、CHECKPOINT_SCN 和归档路径记下来。检查点需要连续取样；归档轮次变化后，不能只拿最新一轮的时间范围推断旧备份集仍可恢复。

3. 查看正在运行的数据备份 Job

SQL

1-- root@sys
2SELECT TENANT_ID, JOB_ID, BACKUP_SET_ID,
3       BACKUP_TYPE, STATUS, START_TIMESTAMP,
4       DESCRIPTION
5FROM oceanbase.CDB_OB_BACKUP_JOBS
6WHERE TENANT_ID = 1002;

这里查当前任务，历史完成任务在下一条。备份命令返回成功，不代表备份已写完；要等 Job 和 Task 完成，再检查备份集文件状态与归档窗口。

4. 查看最近完成或失败的备份 Job

SQL

1-- root@sys
2SELECT TENANT_ID, JOB_ID, BACKUP_SET_ID, BACKUP_TYPE,
3       START_TIMESTAMP, END_TIMESTAMP, STATUS, RESULT, PATH
4FROM   oceanbase.CDB_OB_BACKUP_JOB_HISTORY
5WHERE  TENANT_ID = 1002
6ORDER  BY JOB_ID DESC
7LIMIT 20;

RESULT=0 且 STATUS=COMPLETED 才能作为完成记录。FULL 和 INC 要分开看；备份历史说明任务做过，仍要回读备份集文件状态、目标存储和恢复链。

5. 读取失败 Job 的错误说明

SQL

1-- root@sys
2SELECT JOB_ID, BACKUP_SET_ID, STATUS, RESULT, COMMENT
3FROM   oceanbase.CDB_OB_BACKUP_JOB_HISTORY
4WHERE  TENANT_ID = 1002
5  AND  RESULT <> 0
6ORDER  BY JOB_ID DESC
7LIMIT 20;

先记录 Job ID、错误码和 COMMENT，再按时间查 RootService、OBServer 日志。不要看到日志归档正常就断定数据备份路径也能读写；两者用的是不同的备份目的端。

6. 查看备份 Task 的起止 SCN 和完成量

SQL

1-- root@sys
2SELECT JOB_ID, BACKUP_SET_ID, STATUS,
3       START_SCN, END_SCN, TABLET_COUNT, FINISH_TABLET_COUNT,
4       RESULT
5FROM   oceanbase.CDB_OB_BACKUP_TASK_HISTORY
6WHERE  TENANT_ID = 1002
7ORDER  BY JOB_ID DESC
8LIMIT 20;

备份 Job 完成时，还要对上 Task 的 RESULT 和 Tablet 完成量。START_SCN、END_SCN 是备份 Task 边界，不能直接当作用户要恢复的最终目标；目标必须与备份集最低恢复 SCN、归档范围一起核对。

7. 查看最新备份集的文件状态

SQL

1-- root@sys
2SELECT BACKUP_SET_ID, BACKUP_TYPE, STATUS, FILE_STATUS,
3       MIN_RESTORE_SCN, MIN_RESTORE_SCN_DISPLAY, PATH
4FROM   oceanbase.CDB_OB_BACKUP_SET_FILES
5WHERE  TENANT_ID = 1002
6ORDER  BY BACKUP_SET_ID DESC
7LIMIT 20;

先找 STATUS=SUCCESS 且 FILE_STATUS=AVAILABLE 的备份集。MIN_RESTORE_SCN 是这份备份可用于恢复的最低边界，目标 SCN 早于它时不能靠这一备份集硬恢复。

8. 核对增量备份依赖的全备和前一增量

SQL

1-- root@sys
2SELECT BACKUP_SET_ID, BACKUP_TYPE,
3       PREV_FULL_BACKUP_SET_ID, PREV_INC_BACKUP_SET_ID,
4       FILE_STATUS
5FROM   oceanbase.CDB_OB_BACKUP_SET_FILES
6WHERE  TENANT_ID = 1002
7ORDER  BY BACKUP_SET_ID;

INC 备份不能只留最新一份。把前驱 ID 与实际仍可用的备份集对应起来；删除旧全备或中间增量前，必须证明剩余链可独立恢复。

9. 找出元数据标记为不可用的备份集

SQL

1-- root@sys
2SELECT BACKUP_SET_ID, BACKUP_TYPE,
3       STATUS, FILE_STATUS, PATH
4FROM   oceanbase.CDB_OB_BACKUP_SET_FILES
5WHERE  TENANT_ID = 1002
6  AND  FILE_STATUS <> 'AVAILABLE'
7ORDER  BY BACKUP_SET_ID DESC;

非空时先看备份清理、目标路径变更或文件丢失记录。视图标记可用也不能代替目标存储实际回读；不可用的备份集不要被恢复计划默认选入。

10. 对照备份集的开始重放与最低恢复边界

SQL

1-- root@sys；备份集 ID 按第 7 条结果替换
2SELECT BACKUP_SET_ID, START_REPLAY_SCN,
3       MIN_RESTORE_SCN, CONSISTENT_SCN,
4       PATH
5FROM   oceanbase.CDB_OB_BACKUP_SET_FILES
6WHERE  TENANT_ID = 1002
7  AND  BACKUP_SET_ID = 42;

这些 SCN 代表不同的备份和恢复边界，不能拿某一个值替代日志归档的实际检查点。确认数据备份所需日志与目标时间点之前的归档都在，才有条件做隔离租户恢复。

二、归档轮次、Piece 和日志流

11. 核对目标租户的归档目的端

SQL

1-- root@sys；不要把 VALUE 中的存储凭据复制到工单
2SELECT TENANT_ID, DEST_NO, NAME, VALUE
3FROM   oceanbase.CDB_OB_ARCHIVE_DEST
4WHERE  TENANT_ID = 1002;

LOG_ARCHIVE_DEST 配了路径，还要确认目的端状态和归档任务状态。路径换过以后，旧备份可能仍依赖旧归档目录；恢复方案要记录每轮实际 PATH，不能只抄当前配置。

12. 对照数据备份和日志归档的当前路径

SQL

1-- root@sys；只查路径元数据，不验证对象存储中文件可读
2SELECT TENANT_ID, DEST_TYPE, PATH, EXTENSION
3FROM   oceanbase.CDB_OB_BACKUP_STORAGE_INFO
4WHERE  TENANT_ID = 1002
5  AND  DEST_TYPE IN ('backup_data', 'archive_log');

两个 DEST_TYPE 对应两条独立链。即使路径落在同一存储桶，也应分目录、分别检查访问权与剩余空间。视图返回的是配置，不是对备份文件的实际回读。

13. 找出历史归档轮次的起点和终点

SQL

1-- root@sys
2SELECT ROUND_ID, INCARNATION, STATUS,
3       START_SCN, CHECKPOINT_SCN, PATH
4FROM   oceanbase.CDB_OB_ARCHIVELOG_SUMMARY
5WHERE  TENANT_ID = 1002
6ORDER  BY INCARNATION, ROUND_ID;

停过归档或改过目的端，往往会出现多轮记录。目标 SCN 必须落在可用日志覆盖范围内；只看最新一轮会漏掉历史备份，也可能把轮次之间的缺口藏起来。

14. 定位中断过的归档轮次

SQL

1-- root@sys
2SELECT ROUND_ID, INCARNATION, STATUS,
3       CHECKPOINT_SCN, COMMENT, PATH
4FROM   oceanbase.CDB_OB_ARCHIVELOG_SUMMARY
5WHERE  TENANT_ID = 1002
6  AND  STATUS = 'INTERRUPTED'
7ORDER  BY ROUND_ID DESC;

先看 COMMENT 和最后归档位置，再按轮次查 Piece、日志流及存储错误。后来归档重新进入 DOING，不表示中断期间所需日志已经补齐；恢复目标跨过这段时间时必须实际验证。

15. 查看目标轮次包含哪些 Piece

SQL

1-- root@sys；ROUND_ID 按第 13 条结果替换
2SELECT ROUND_ID, PIECE_ID, STATUS,
3       START_SCN, CHECKPOINT_SCN, END_SCN,
4       FILE_STATUS, PATH
5FROM   oceanbase.CDB_OB_ARCHIVELOG_PIECE_FILES
6WHERE  TENANT_ID = 1002
7  AND  ROUND_ID = 3
8ORDER  BY PIECE_ID;

Piece 是按周期切分的归档文件段。先找目标 SCN 所在段，再检查相邻段是否连续、FILE_STATUS 是否可用；活跃 Piece 的结束边界可能仍在变化，不要把它当成已封存文件。

16. 找出归档文件标记不可用的 Piece

SQL

1-- root@sys
2SELECT ROUND_ID, PIECE_ID, STATUS, FILE_STATUS,
3       START_SCN, CHECKPOINT_SCN, PATH
4FROM   oceanbase.CDB_OB_ARCHIVELOG_PIECE_FILES
5WHERE  TENANT_ID = 1002
6  AND  FILE_STATUS <> 'AVAILABLE'
7ORDER  BY ROUND_ID, PIECE_ID;

结果非空时，先分辨当前活跃 Piece 与历史段，再查清理记录、目标存储和格式文件。元数据异常不能靠改备份集 ID 绕过；恢复窗口必须按仍可读取的归档文件重新计算。

17. 逐条日志流查归档进度

SQL

1-- root@sys；同一 ROUND_ID / PIECE_ID 内比较
2SELECT LS_ID, ROUND_ID, PIECE_ID, STATUS,
3       START_SCN, CHECKPOINT_SCN, FILE_ID
4FROM   oceanbase.CDB_OB_LS_LOG_ARCHIVE_PROGRESS
5WHERE  TENANT_ID = 1002
6ORDER  BY ROUND_ID DESC, PIECE_ID DESC, LS_ID;

租户归档检查点是各 LS 进度的最小值。一条 LS 落后，整租户的可恢复时间就受它限制；别把某条快 LS 的 CHECKPOINT_SCN 误报成租户恢复窗口。

18. 找出当前 Piece 中归档最慢的 LS

SQL

1-- root@sys；轮次和 Piece ID 从第 17 条确认
2SELECT LS_ID, STATUS, START_SCN, CHECKPOINT_SCN,
3       INPUT_BYTES, OUTPUT_BYTES
4FROM   oceanbase.CDB_OB_LS_LOG_ARCHIVE_PROGRESS
5WHERE  TENANT_ID = 1002
6  AND  ROUND_ID = 3
7  AND  PIECE_ID = 7
8ORDER  BY CHECKPOINT_SCN, LS_ID;

排在最前面的 LS 是这一段里归档位点最低的对象。连续采样，看它的 CHECKPOINT_SCN 和输出字节是否推进；只看一个截面可能刚好遇到 Piece 切换。若状态中断，再按 LS ID 定位 OBServer 日志。

三、数据备份任务正在做什么

19. 查看当前备份 Task 的 Tablet 完成量

SQL

1-- root@sys
2SELECT JOB_ID, TASK_ID, BACKUP_SET_ID, STATUS,
3       TABLET_COUNT, FINISH_TABLET_COUNT,
4       MACRO_BLOCK_COUNT, FINISH_MACRO_BLOCK_COUNT
5FROM   oceanbase.CDB_OB_BACKUP_TASKS
6WHERE  TENANT_ID = 1002
7ORDER  BY JOB_ID, TASK_ID;

Job 还在运行时，这条能看到具体 Task 的工作量。Tablet 数和宏块数在不同备份阶段可能变化，不能只用一次百分比预测完成时间；一段时间都不推进，再看任务错误和目标存储写入。

20. 查看当前备份 Task 的吞吐和错误码

SQL

1-- root@sys；隔几分钟采两次
2SELECT JOB_ID, TASK_ID, STATUS,
3       INPUT_BYTES, OUTPUT_BYTES, OUTPUT_RATE_BYTES,
4       RESULT, COMMENT, PATH
5FROM   oceanbase.CDB_OB_BACKUP_TASKS
6WHERE  TENANT_ID = 1002
7ORDER  BY JOB_ID, TASK_ID;

OUTPUT_RATE_BYTES 是当前任务记录的输出速率，零值需要结合任务阶段和两次采样判断。RESULT 非零时保留 COMMENT、Job ID 和时间，再查 RootService 与 OBServer 日志；别因归档正常就排除数据备份路径问题。

21. 查看集群里所有正在运行的备份 Job

SQL

1-- root@sys
2SELECT TENANT_ID, JOB_ID, BACKUP_SET_ID,
3       BACKUP_TYPE, STATUS, START_TIMESTAMP
4FROM oceanbase.CDB_OB_BACKUP_JOBS
5ORDER BY START_TIMESTAMP;

同一时间可能不止一个租户在备份。判断带宽、对象存储或 NFS 压力时，先把全局并发任务查全，别只盯目标租户。

22. 找出长时间没有完成量变化的 Task

SQL

1-- root@sys；间隔几分钟重复执行并对比结果
2SELECT TENANT_ID, JOB_ID, TASK_ID, STATUS,
3       FINISH_TABLET_COUNT, FINISH_MACRO_BLOCK_COUNT,
4       OUTPUT_BYTES, OUTPUT_RATE_BYTES, COMMENT
5FROM oceanbase.CDB_OB_BACKUP_TASKS
6WHERE STATUS NOT IN ('COMPLETED', 'CANCELED')
7ORDER BY TENANT_ID, JOB_ID, TASK_ID;

一次采样不能证明任务卡住。连续两次完成量、输出字节和速率都不变，再结合任务阶段、错误说明和存储端指标判断。

四、发起与停止数据备份

23. 为指定租户发起全量备份

SQL

1-- root@sys；写操作，执行前确认归档任务为 DOING
2ALTER SYSTEM BACKUP TENANT = app_tenant
3  DESCRIPTION = 'weekly_full_20260916';

描述字段写入批次用途和日期，后续排错更容易对上工单。命令只负责发起任务，完成状态仍以 Job、Task 和备份集文件为准。

24. 发起带归档日志的全量备份

SQL

1-- root@sys；写操作
2ALTER SYSTEM BACKUP TENANT = app_tenant PLUS ARCHIVELOG
3  DESCRIPTION = 'portable_full_20260916';

该备份集会带上可恢复到 MIN_RESTORE_SCN 的归档日志，适合制作可独立使用的数据集。它不等于长期 PITR 归档，之后时间点仍依赖持续日志归档。

25. 为指定租户发起增量备份

SQL

1-- root@sys；写操作
2ALTER SYSTEM BACKUP INCREMENTAL TENANT = app_tenant
3  DESCRIPTION = 'daily_inc_20260916';

没有可用全备时，系统会把增量请求转为全量备份。执行后要回读 BACKUP_TYPE，不能只根据提交命令认定本次一定是增量。

26. 同时为两个租户发起全量备份

SQL

1-- root@sys；写操作，先评估备份存储吞吐
2ALTER SYSTEM BACKUP TENANT = app_tenant, report_tenant
3  DESCRIPTION = 'monthly_full_20260916';

批量发起前先看当前任务和存储带宽。多个租户共用同一 NFS 或对象存储前缀时，备份并发可能让业务 IO 与备份窗口一起变差。

27. 取消指定租户正在运行的备份

SQL

1-- root@sys；写操作，仅在确认需要中止时执行
2ALTER SYSTEM CANCEL BACKUP TENANT = app_tenant;

取消不是删除已完成备份。执行后等当前 Job 进入最终状态，记录取消原因，并确认下一次备份是否需要重新做全量。

28. 确认取消后的 Job 状态

SQL

1-- root@sys
2SELECT JOB_ID, BACKUP_SET_ID, BACKUP_TYPE,
3       STATUS, RESULT, COMMENT,
4       START_TIMESTAMP, END_TIMESTAMP
5FROM oceanbase.CDB_OB_BACKUP_JOB_HISTORY
6WHERE TENANT_ID = 1002
7ORDER BY JOB_ID DESC
8LIMIT 5;

看到取消相关的最终状态后再关窗口。若当前 Job 视图仍有记录，说明任务还未完全退出，不能立即切换备份目的端。

29. 查看本租户最近一次成功的全量备份

SQL

1-- root@sys
2SELECT BACKUP_SET_ID, START_TIMESTAMP, END_TIMESTAMP,
3       STATUS, RESULT, PATH
4FROM oceanbase.CDB_OB_BACKUP_JOB_HISTORY
5WHERE TENANT_ID = 1002
6  AND BACKUP_TYPE = 'FULL'
7  AND STATUS = 'COMPLETED'
8  AND RESULT = 0
9ORDER BY END_TIMESTAMP DESC
10LIMIT 1;

这条用于确认增量备份的基线，但还要查对应备份集的 FILE_STATUS 和依赖关系。历史 Job 成功不代表后来没有清理或损坏文件。

30. 查看全量和增量备份耗时

SQL

1-- root@sys
2SELECT JOB_ID, BACKUP_SET_ID, BACKUP_TYPE,
3       START_TIMESTAMP, END_TIMESTAMP,
4       TIMESTAMPDIFF(SECOND, START_TIMESTAMP, END_TIMESTAMP)
5         AS ELAPSED_SECONDS
6FROM oceanbase.CDB_OB_BACKUP_JOB_HISTORY
7WHERE TENANT_ID = 1002
8  AND STATUS = 'COMPLETED'
9ORDER BY JOB_ID DESC
10LIMIT 30;

连续几次耗时抬升，比单次慢更值得关注。结合输出字节、备份类型、合并周期和存储端吞吐一起判断，不要直接归因于数据库负载。

五、配置归档与备份目的端

31. 配置 NFS 日志归档目的端

SQL

1-- root@sys；写操作，路径需在所有相关节点可访问
2ALTER SYSTEM SET LOG_ARCHIVE_DEST =
3  'LOCATION=file:///backup/ob/archive BINDING=Optional PIECE_SWITCH_INTERVAL=1d'
4  TENANT = app_tenant;

各参数之间用空格分隔，等号两侧不能留空格。路径调整会影响后续归档轮次，旧恢复链使用过的目录必须继续保留并记录。

32. 配置 NFS 数据备份目的端

SQL

1-- root@sys；写操作
2ALTER SYSTEM SET DATA_BACKUP_DEST =
3  'file:///backup/ob/data'
4  TENANT = app_tenant;

所有参与备份的 OBServer 都要能访问该路径。命令写入配置后，还要通过存储信息视图回读；真正的读写能力由一次受控备份和存储端检查验证。

33. 回读数据与日志两条目的端

SQL

1-- root@sys；结果可能包含访问参数，导出前脱敏
2SELECT TENANT_ID, DEST_TYPE, PATH, EXTENSION
3FROM oceanbase.CDB_OB_BACKUP_STORAGE_INFO
4WHERE TENANT_ID = 1002
5ORDER BY DEST_TYPE;

确认 backup_data 和 archive_log 都指向计划路径。对象存储 URI 可能含访问标识，工单、截图和文章示例中不要保留真实凭据。

34. 为指定租户开启归档模式

SQL

1-- root@sys；写操作
2ALTER SYSTEM ARCHIVELOG TENANT = app_tenant;

开启前先配置并启用归档目的端。命令返回后要等归档任务进入 DOING，在此之前不能发起数据备份。

35. 确认归档模式已经开启

SQL

1-- root@sys
2SELECT TENANT_ID, TENANT_NAME, LOG_MODE
3FROM oceanbase.DBA_OB_TENANTS
4WHERE TENANT_NAME = 'app_tenant';

ARCHIVELOG 只证明模式已开启。随后仍要核对当前归档任务状态、检查点推进和每条 LS 的进度。

36. 查看归档任务是否进入 DOING

SQL

1-- root@sys
2SELECT TENANT_ID, DEST_ID, ROUND_ID,
3       STATUS, START_SCN, CHECKPOINT_SCN,
4       SCN_TO_TIMESTAMP(CHECKPOINT_SCN) AS CHECKPOINT_TIME
5FROM oceanbase.CDB_OB_ARCHIVELOG
6WHERE TENANT_ID = 1002;

发起数据备份前 STATUS 应为 DOING。检查点时间要连续推进；只看状态不看位点，可能漏掉归档任务实际停滞。

37. 比较归档检查点与当前时间的差距

SQL

1-- root@sys
2SELECT TENANT_ID, ROUND_ID,
3       SCN_TO_TIMESTAMP(CHECKPOINT_SCN) AS CHECKPOINT_TIME,
4       TIMESTAMPDIFF(SECOND,
5         SCN_TO_TIMESTAMP(CHECKPOINT_SCN), NOW()) AS LAG_SECONDS
6FROM oceanbase.CDB_OB_ARCHIVELOG
7WHERE TENANT_ID = 1002;

延迟阈值应按业务 RPO 和正常基线设定。单次延迟增大先连续采样，再下钻到 LS；不要因为状态仍是 DOING 就忽略检查点停滞。

38. 暂停指定租户的日志归档

SQL

1-- root@sys；写操作，会影响 PITR 日志连续性
2ALTER SYSTEM NOARCHIVELOG TENANT = app_tenant;

这不是普通的“暂停一下”。关闭归档模式会结束当前归档轮次，恢复窗口可能因此断开；只有明确评估过备份与恢复影响才能执行。

39. 确认归档模式已经关闭

SQL

1-- root@sys
2SELECT TENANT_NAME, LOG_MODE
3FROM oceanbase.DBA_OB_TENANTS
4WHERE TENANT_NAME = 'app_tenant';

看到 NOARCHIVELOG 后，再检查历史轮次的结束状态并记录停止时间。以后重新开启会形成新的归档轮次。

40. 重新开启归档后确认新轮次

SQL

1-- root@sys；先执行 ALTER SYSTEM ARCHIVELOG TENANT = app_tenant
2SELECT ROUND_ID, STATUS, START_SCN, CHECKPOINT_SCN, PATH
3FROM oceanbase.CDB_OB_ARCHIVELOG_SUMMARY
4WHERE TENANT_ID = 1002
5ORDER BY ROUND_ID DESC
6LIMIT 3;

新轮次开始不代表旧轮次与新轮次之间没有缺口。恢复目标跨越停归档窗口时，应直接判定日志链风险并做实际恢复验证。

六、恢复前先把时间点和资源算清楚

41. 查看目标集群的数据库版本

SQL

1-- root@sys；目标集群执行
2SELECT VERSION();

恢复前要同时记录源备份版本和目标集群版本。OceanBase 只支持恢复到相同或受支持的更高版本，不能只比较主版本号就跳过兼容性说明。

42. 查看备份集记录的兼容版本

SQL

1-- root@sys
2SELECT BACKUP_SET_ID, BACKUP_TYPE, COMPATIBLE,
3       STATUS, FILE_STATUS, PATH
4FROM oceanbase.CDB_OB_BACKUP_SET_FILES
5WHERE TENANT_ID = 1002
6ORDER BY BACKUP_SET_ID DESC;

先选 SUCCESS、AVAILABLE 的备份集，再核对 COMPATIBLE。跨版本恢复要按官方支持矩阵确认，不能用“目标版本更高”自行推断一定支持。

43. 将目标恢复时间换算为 SCN

SQL

1-- root@sys；时间按源租户时区确认后替换
2SELECT TIMESTAMP_TO_SCN('2026-09-16 10:30:00.000000')
3       AS TARGET_SCN;

MySQL 模式时间戳精确到微秒。恢复时间必须带上业务事件、时区和取证来源；只写一个本地时间容易在跨地域环境里恢复错位点。

44. 将目标 SCN 回转为时间检查

SQL

1-- root@sys；SCN 按第 43 条结果替换
2SELECT SCN_TO_TIMESTAMP(1789525800000000000)
3       AS TARGET_TIME;

回转结果应与计划时间一致。该检查能发现抄错位数或时区理解错误，但不能证明日志链已经覆盖该 SCN。

45. 找能覆盖目标 SCN 的备份集

SQL

1-- root@sys
2SELECT BACKUP_SET_ID, BACKUP_TYPE,
3       MIN_RESTORE_SCN, MIN_RESTORE_SCN_DISPLAY,
4       START_REPLAY_SCN, FILE_STATUS, PATH
5FROM oceanbase.CDB_OB_BACKUP_SET_FILES
6WHERE TENANT_ID = 1002
7  AND FILE_STATUS = 'AVAILABLE'
8  AND MIN_RESTORE_SCN <= 1789525800000000000
9ORDER BY BACKUP_SET_ID DESC;

这只是候选清单。最终还要确认目标 SCN 之前所需的归档 Piece 连续可用，不能只凭 MIN_RESTORE_SCN 选中备份集。

46. 找包含目标 SCN 的归档 Piece

SQL

1-- root@sys
2SELECT ROUND_ID, PIECE_ID, STATUS, FILE_STATUS,
3       START_SCN, CHECKPOINT_SCN, END_SCN, PATH
4FROM oceanbase.CDB_OB_ARCHIVELOG_PIECE_FILES
5WHERE TENANT_ID = 1002
6  AND START_SCN <= 1789525800000000000
7  AND CHECKPOINT_SCN >= 1789525800000000000
8ORDER BY ROUND_ID, PIECE_ID;

至少要找到覆盖目标位点的可用 Piece，并向前追到备份集开始重放所需的日志。单个 Piece 命中目标，不代表前面的链条没有缺口。

47. 检查候选 Piece 的连续性

SQL

1-- root@sys；轮次按恢复计划替换
2SELECT PIECE_ID, STATUS, FILE_STATUS,
3       START_SCN, CHECKPOINT_SCN, END_SCN,
4       LAG(CHECKPOINT_SCN) OVER (ORDER BY PIECE_ID)
5         AS PREV_CHECKPOINT_SCN
6FROM oceanbase.CDB_OB_ARCHIVELOG_PIECE_FILES
7WHERE TENANT_ID = 1002
8  AND ROUND_ID = 3
9ORDER BY PIECE_ID;

按相邻 Piece 比较边界，发现明显缺口就停止恢复准备。窗口函数只检查元数据，仍需保证目标存储中的实际文件可读。

48. 确认每条 LS 都归档到目标 SCN

SQL

1-- root@sys
2SELECT LS_ID, STATUS, CHECKPOINT_SCN
3FROM oceanbase.CDB_OB_LS_LOG_ARCHIVE_PROGRESS
4WHERE TENANT_ID = 1002
5  AND CHECKPOINT_SCN < 1789525800000000000
6ORDER BY CHECKPOINT_SCN, LS_ID;

结果为空才说明当前视图中没有落后于目标的 LS。恢复窗口由最慢日志流决定，不能用租户平均进度代替。

49. 查看目标集群各 Zone 的资源余量

SQL

1-- root@sys；目标集群执行
2SELECT ZONE, SVR_IP,
3       CPU_CAPACITY - CPU_ASSIGNED AS CPU_HEADROOM,
4       MEM_CAPACITY - MEM_ASSIGNED AS MEM_HEADROOM_BYTES,
5       LOG_DISK_CAPACITY - LOG_DISK_ASSIGNED AS LOG_HEADROOM_BYTES
6FROM oceanbase.GV$OB_SERVERS
7ORDER BY ZONE, SVR_IP;

恢复需要预先创建资源池。每个 Zone 都要有节点能容纳恢复规格，不能只看整个集群的总余量。

50. 创建恢复租户使用的 Unit 规格

SQL

1-- root@sys；目标集群写操作，规格按源租户和演练目标调整
2CREATE RESOURCE UNIT restore_unit_8c
3  MAX_CPU 8, MIN_CPU 8,
4  MEMORY_SIZE '32G',
5  MAX_IOPS 10000, MIN_IOPS 10000,
6  IOPS_WEIGHT 8,
7  LOG_DISK_SIZE '96G';

恢复演练不等于可以随意压缩资源。资源过小会把恢复耗时和业务验证结果失真；计划接管业务时，尽量与源租户保持同构。

51. 创建恢复租户使用的资源池

SQL

1-- root@sys；目标集群写操作
2CREATE RESOURCE POOL restore_pool
3  UNIT = 'restore_unit_8c',
4  UNIT_NUM = 1,
5  ZONE_LIST = ('zone1', 'zone2', 'zone3');

资源池会立即创建 Unit 并占用配额。Zone 列表应与恢复时的 locality 一致，创建后先确认 Unit 全部处于正常状态。

52. 检查恢复资源池的 Unit 落点

SQL

1-- root@sys
2SELECT u.UNIT_ID, u.ZONE, u.SVR_IP,
3       u.SVR_PORT, u.STATUS
4FROM oceanbase.DBA_OB_UNITS AS u
5JOIN oceanbase.DBA_OB_RESOURCE_POOLS AS p
6  ON p.RESOURCE_POOL_ID = u.RESOURCE_POOL_ID
7WHERE p.NAME = 'restore_pool'
8ORDER BY u.ZONE;

每个目标 Zone 都应有一份正常 Unit。资源还没稳定就发起恢复，后续失败会混淆成备份链或恢复引擎问题。

53. 确认恢复租户名称没有冲突

SQL

1-- root@sys
2SELECT TENANT_ID, TENANT_NAME, STATUS,
3       TENANT_ROLE, IN_RECYCLEBIN
4FROM oceanbase.DBA_OB_TENANTS
5WHERE TENANT_NAME = 'app_restore_20260916';

恢复会创建新租户。正式执行前要求结果为空，同时检查回收站和命名规范，避免复用旧演练租户造成误判。

54. 保存源租户的资源与副本布局

SQL

1-- 源集群 root@sys
2SELECT TENANT_NAME, PRIMARY_ZONE, LOCALITY,
3       UNIT_NUM, COMPATIBILITY_MODE
4FROM oceanbase.DBA_OB_TENANTS
5WHERE TENANT_NAME = 'app_tenant';

这份结果用于制定恢复的 pool_list、locality 和 primary_zone。演练环境可以降配，但必须把与生产的差异写清楚。

55. 保存源租户的系统时区

SQL

1-- 连接源 MySQL 租户执行
2SHOW VARIABLES LIKE 'system_time_zone';

按时间恢复时，时间戳会结合备份租户时区解释。恢复单必须同时保存原始时间、时区和换算后的 SCN。

七、执行租户级 PITR

56. 恢复到指定 SCN

SQL

1-- 目标集群 root@sys；写操作
2ALTER SYSTEM RESTORE app_restore_20260916
3FROM 'file:///backup/ob/data,file:///backup/ob/archive'
4UNTIL SCN = 1789525800000000000
5WITH 'pool_list=restore_pool&primary_zone=zone1&concurrency=8'
6DESCRIPTION = 'pitr_drill_20260916';

路径顺序不是判断依据，两条路径必须分别指向数据备份和日志归档。命令提交后立即进入进度视图跟踪，不能把返回成功当成租户已恢复。

57. 恢复到指定时间

SQL

1-- 目标集群 root@sys；与第 56 条二选一
2ALTER SYSTEM RESTORE app_restore_20260916
3FROM 'file:///backup/ob/data,file:///backup/ob/archive'
4UNTIL TIME = '2026-09-16 10:30:00.000000'
5WITH 'pool_list=restore_pool&primary_zone=zone1&concurrency=8'
6DESCRIPTION = 'pitr_by_time_20260916';

按时间恢复更直观，但更依赖时区记录。生产处置建议在审批单里同时保留等价 SCN，执行时只选一种方式。

58. 恢复到归档可达的最新位点

SQL

1-- 目标集群 root@sys；不指定 UNTIL
2ALTER SYSTEM RESTORE app_restore_latest
3FROM 'file:///backup/ob/data,file:///backup/ob/archive'
4WITH 'pool_list=restore_pool&primary_zone=zone1&concurrency=8'
5DESCRIPTION = 'latest_restore_drill';

省略 UNTIL 表示恢复到可用日志的最新位置，不代表零数据损失。最终位点仍由归档实际覆盖范围决定。

59. 指定完整 locality 发起恢复

SQL

1-- 目标集群 root@sys；locality 与资源池 Zone 必须匹配
2ALTER SYSTEM RESTORE app_restore_3f
3FROM 'file:///backup/ob/data,file:///backup/ob/archive'
4UNTIL SCN = 1789525800000000000
5WITH 'pool_list=restore_pool&locality=F@zone1,F@zone2,F@zone3&primary_zone=zone1&concurrency=8';

显式 locality 适合跨集群恢复时控制副本布局。写错 Zone 或与资源池不匹配会直接导致恢复失败，提交前先对照第 51、52 条。

60. 取消正在进行的租户恢复

SQL

1-- 目标集群 root@sys；写操作，仅在确认中止时执行
2ALTER SYSTEM CANCEL RESTORE app_restore_20260916;

取消后仍要检查恢复历史和租户状态，确认是否需要清理残留租户及资源池。不要直接删除恢复中的租户来代替取消命令。

八、跟踪恢复过程

61. 查看当前恢复任务的完整信息

SQL

1-- 目标集群 root@sys
2SELECT TENANT_ID, JOB_ID, RESTORE_TENANT_NAME,
3       RESTORE_TENANT_ID, BACKUP_TENANT_NAME,
4       BACKUP_CLUSTER_NAME, RESTORE_SCN,
5       RESTORE_SCN_DISPLAY, STATUS, START_TIMESTAMP,
6       TOTAL_BYTES, FINISH_BYTES, DESCRIPTION
7FROM oceanbase.CDB_OB_RESTORE_PROGRESS
8WHERE RESTORE_TENANT_NAME = 'app_restore_20260916';

一个恢复任务通常会出现 sys 租户和目标租户两条记录：前者负责创建并等待租户，后者记录自身的数据恢复进度。两条都要看。

62. 查看恢复任务的关键状态

SQL

1-- 目标集群 root@sys
2SELECT TENANT_ID, JOB_ID, RESTORE_TENANT_NAME,
3       RESTORE_TENANT_ID, STATUS,
4       RESTORE_SCN, RESTORE_SCN_DISPLAY,
5       START_TIMESTAMP
6FROM oceanbase.CDB_OB_RESTORE_PROGRESS
7WHERE RESTORE_TENANT_NAME = 'app_restore_20260916'
8ORDER BY TENANT_ID;

sys 记录可能处于 CREATE_TENANT 或 WAIT_TENANT_RESTORE_FINISH，目标租户记录会经历 RESTORING、POST_CHECK、UPGRADE。阶段不同不能互相替代。

63. 查看恢复字节进度

SQL

1-- 目标集群 root@sys
2SELECT TENANT_ID, JOB_ID, STATUS,
3       TOTAL_BYTES, FINISH_BYTES,
4       ROUND(100 * FINISH_BYTES
5             / NULLIF(TOTAL_BYTES, 0), 2) AS FINISH_PCT
6FROM oceanbase.CDB_OB_RESTORE_PROGRESS
7WHERE RESTORE_TENANT_NAME = 'app_restore_20260916';

创建租户阶段字节数可能为空。进入数据恢复后应连续采样，百分比长时间不变才结合存储、网络和 OBServer 日志排查。

64. 核对恢复实际选择的备份集

SQL

1-- 目标集群 root@sys
2SELECT JOB_ID, RESTORE_TENANT_NAME,
3       BACKUP_SET_LIST, BACKUP_PIECE_LIST
4FROM oceanbase.CDB_OB_RESTORE_PROGRESS
5WHERE RESTORE_TENANT_NAME = 'app_restore_20260916';

把系统实际选择的备份集和 Piece 与恢复计划对照。路径或备份批次不符合预期时，应在激活前停止并复核。

65. 核对恢复参数和目标位点

SQL

1-- 目标集群 root@sys
2SELECT JOB_ID, BACKUP_DEST, RESTORE_OPTION,
3       RESTORE_SCN, RESTORE_SCN_DISPLAY,
4       DESCRIPTION
5FROM oceanbase.CDB_OB_RESTORE_PROGRESS
6WHERE RESTORE_TENANT_NAME = 'app_restore_20260916';

这一条适合直接保存到恢复工单。注意对对象存储 URI 中的访问参数脱敏，不能把真实密钥留在截图或日志附件里。

66. 查看恢复租户的创建状态

SQL

1-- 目标集群 root@sys
2SELECT TENANT_ID, TENANT_NAME, STATUS,
3       TENANT_ROLE, PRIMARY_ZONE, LOCALITY
4FROM oceanbase.DBA_OB_TENANTS
5WHERE TENANT_NAME = 'app_restore_20260916';

恢复过程中 STATUS 可能为 RESTORE，完成后应进入正常状态并保持 STANDBY 角色。未完成前不要让业务连接该租户。

67. 查看恢复租户的同步和可读位点

SQL

1-- 目标集群 root@sys
2SELECT TENANT_NAME, TENANT_ROLE,
3       SYNC_SCN, REPLAYABLE_SCN, READABLE_SCN,
4       RECOVERY_UNTIL_SCN
5FROM oceanbase.DBA_OB_TENANTS
6WHERE TENANT_NAME = 'app_restore_20260916';

这些 SCN 用于判断日志同步、可重放和可读边界。恢复完成并不意味着租户已切成主角色，也不意味着应用验证已完成。

68. 将恢复租户的关键 SCN 转为时间

SQL

1-- 目标集群 root@sys
2SELECT TENANT_NAME,
3       SCN_TO_TIMESTAMP(SYNC_SCN) AS SYNC_TIME,
4       SCN_TO_TIMESTAMP(READABLE_SCN) AS READABLE_TIME,
5       SCN_TO_TIMESTAMP(RECOVERY_UNTIL_SCN) AS RECOVERY_UNTIL_TIME
6FROM oceanbase.DBA_OB_TENANTS
7WHERE TENANT_NAME = 'app_restore_20260916';

转换后更方便与业务事件时间对照，但验收仍保留原始 SCN。时间展示会受时区影响，SCN 才是精确位点。

69. 查看恢复完成后的历史记录

SQL

1-- 目标集群 root@sys
2SELECT TENANT_ID, JOB_ID, RESTORE_TENANT_NAME,
3       RESTORE_TENANT_ID, BACKUP_TENANT_NAME,
4       RESTORE_SCN, RESTORE_SCN_DISPLAY,
5       STATUS, START_TIMESTAMP, FINISH_TIMESTAMP,
6       DESCRIPTION, COMMENT
7FROM oceanbase.CDB_OB_RESTORE_HISTORY
8WHERE RESTORE_TENANT_NAME = 'app_restore_20260916'
9ORDER BY JOB_ID DESC;

当前进度记录结束后转入历史视图。保存 Job ID、最终状态、目标 SCN、耗时和错误信息，作为本次恢复演练的原始证据。

70. 检查是否仍有恢复任务运行

SQL

1-- 目标集群 root@sys
2SELECT JOB_ID, RESTORE_TENANT_NAME, STATUS,
3       START_TIMESTAMP
4FROM oceanbase.CDB_OB_RESTORE_PROGRESS
5ORDER BY START_TIMESTAMP;

验收或回收资源前应为空。若还有其他租户的恢复任务，也要评估是否共享同一存储和节点资源。

九、恢复后先隔离验证

71. 确认恢复租户仍是 STANDBY

SQL

1-- 目标集群 root@sys
2SELECT TENANT_NAME, STATUS, TENANT_ROLE,
3       SWITCHOVER_STATUS
4FROM oceanbase.DBA_OB_TENANTS
5WHERE TENANT_NAME = 'app_restore_20260916';

物理恢复出的租户默认是备租户。业务校验完成前保留 STANDBY，不要为了“测试能写”提前激活并接入生产网络。

72. 查看恢复租户的 Unit 分布

SQL

1-- 目标集群 root@sys
2SELECT UNIT_ID, ZONE, SVR_IP, STATUS,
3       MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE
4FROM oceanbase.GV$OB_UNITS
5WHERE TENANT_ID = (
6  SELECT TENANT_ID FROM oceanbase.DBA_OB_TENANTS
7  WHERE TENANT_NAME = 'app_restore_20260916'
8)
9ORDER BY ZONE, UNIT_ID;

所有 Unit 都应正常落地。资源池配置正确但某个 Unit 异常，仍不能进入业务验证或激活步骤。

73. 查看恢复租户的日志流状态

SQL

1-- 目标集群 root@sys
2SELECT TENANT_ID, LS_ID, STATUS,
3       PRIMARY_ZONE, UNIT_GROUP_ID
4FROM oceanbase.CDB_OB_LS
5WHERE TENANT_ID = (
6  SELECT TENANT_ID FROM oceanbase.DBA_OB_TENANTS
7  WHERE TENANT_NAME = 'app_restore_20260916'
8)
9ORDER BY LS_ID;

恢复由各 LS 协同完成，不能只看租户总状态。异常 LS 要先查副本和日志恢复情况，再继续后续步骤。

74. 连接恢复租户确认当前身份

SQL

1-- 连接恢复后的 MySQL 租户
2SELECT CURRENT_USER(), DATABASE();

先确认连接确实落在恢复租户，避免测试 SQL 误打到源租户。生产演练建议使用独立 OBProxy 路由或隔离地址。

75. 查看恢复租户的数据库清单

SQL

1-- 恢复租户
2SHOW DATABASES;

与恢复前基线核对业务库是否齐全。系统库数量变化可能来自版本差异，业务库缺失则必须停止验收并回查备份范围。

76. 查看业务库中的表数量

SQL

1-- 恢复租户；库名按现场替换
2SELECT TABLE_SCHEMA, COUNT(*) AS TABLE_COUNT
3FROM information_schema.TABLES
4WHERE TABLE_SCHEMA = 'appdb'
5  AND TABLE_TYPE = 'BASE TABLE'
6GROUP BY TABLE_SCHEMA;

表数量是第一层结构检查，不证明数据正确。应与备份前同一时间点的基线比较，并继续检查关键对象和业务记录。

77. 查看业务库中的视图数量

SQL

1-- 恢复租户
2SELECT TABLE_SCHEMA, COUNT(*) AS VIEW_COUNT
3FROM information_schema.VIEWS
4WHERE TABLE_SCHEMA = 'appdb'
5GROUP BY TABLE_SCHEMA;

视图缺失常被简单表数量检查漏掉。关键视图还要实际查询，确认依赖对象和权限都可用。

78. 查看业务库中的存储过程数量

SQL

1-- 恢复租户
2SELECT ROUTINE_SCHEMA, ROUTINE_TYPE,
3       COUNT(*) AS ROUTINE_COUNT
4FROM information_schema.ROUTINES
5WHERE ROUTINE_SCHEMA = 'appdb'
6GROUP BY ROUTINE_SCHEMA, ROUTINE_TYPE;

把函数和过程分开与基线比较。对象数量一致后，再抽查关键过程的定义和执行权限。

79. 核对关键表的行数

SQL

1-- 恢复租户；大表可改用业务侧校验口径
2SELECT COUNT(*) AS ORDER_COUNT
3FROM appdb.orders;

COUNT(*) 只适合规模可控的关键表。超大表应使用分区汇总、业务日结数或预先设计的校验 SQL，避免验收本身压垮恢复租户。

80. 核对目标时间点附近的业务记录

SQL

1-- 恢复租户；时间字段与范围按事故取证结果替换
2SELECT order_id, order_status, update_time
3FROM appdb.orders
4WHERE update_time BETWEEN
5      '2026-09-16 10:29:50' AND '2026-09-16 10:30:10'
6ORDER BY update_time, order_id;

这一步直接回答“恢复到了哪里”。选择能对应误操作或业务事件的表和键值，比只看租户状态更有说服力。

81. 检查误删除对象是否已恢复

SQL

1-- 恢复租户；对象名按事故现场替换
2SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_TYPE
3FROM information_schema.TABLES
4WHERE TABLE_SCHEMA = 'appdb'
5  AND TABLE_NAME = 'orders_archive';

查到对象后还要校验结构和数据时间点。只证明表名存在，不能说明本次 PITR 已满足业务恢复目标。

82. 查看关键表的字段定义

SQL

1-- 恢复租户
2SHOW CREATE TABLE appdb.orders;

与源端基线对比字段、索引、分区和表选项。对象存在但结构落后，也可能让应用启动后出现隐蔽错误。

83. 查看关键账户是否存在

SQL

1-- 恢复租户；需要具备相应权限
2SELECT USER, HOST
3FROM mysql.user
4WHERE USER IN ('app_user', 'report_user')
5ORDER BY USER, HOST;

不要在文章或工单中导出密码散列。这里只核对账号和来源地址，权限内容用下一条单独验证。

84. 查看应用账户授权

SQL

1-- 恢复租户
2SHOW GRANTS FOR 'app_user'@'%';

将授权与灾备基线对比。恢复后若需要修改密码或网络来源，应作为接管流程独立审批，不要混在数据恢复命令里临时处理。

85. 查看关键表的最新业务时间

SQL

1-- 恢复租户
2SELECT MAX(update_time) AS LATEST_UPDATE_TIME
3FROM appdb.orders;

最新时间不应超过计划恢复点太多，也不能明显早于目标。仍要结合事务提交语义和业务表实际更新时间字段解释。

86. 按小时汇总目标时间前后的记录

SQL

1-- 恢复租户
2SELECT DATE_FORMAT(update_time, '%Y-%m-%d %H:00:00') AS HOUR_SLOT,
3       COUNT(*) AS ROW_COUNT
4FROM appdb.orders
5WHERE update_time >= '2026-09-16 08:00:00'
6  AND update_time <  '2026-09-16 11:00:00'
7GROUP BY HOUR_SLOT
8ORDER BY HOUR_SLOT;

这种汇总能快速发现恢复点附近的数据断层。它仍是业务层抽查，最终验收口径应由应用负责人确认。

87. 对关键金额做业务汇总校验

SQL

1-- 恢复租户；字段和状态按业务定义替换
2SELECT order_status,
3       COUNT(*) AS ORDER_COUNT,
4       SUM(order_amount) AS TOTAL_AMOUNT
5FROM appdb.orders
6WHERE business_date = '2026-09-16'
7GROUP BY order_status
8ORDER BY order_status;

数量和金额一起核对，比单表行数更接近真实业务。恢复演练应提前准备这类可重复执行的基线 SQL。

88. 检查恢复租户是否仍保持只读角色

SQL

1-- 目标集群 root@sys
2SELECT TENANT_NAME, TENANT_ROLE,
3       SWITCHOVER_STATUS, STATUS
4FROM oceanbase.DBA_OB_TENANTS
5WHERE TENANT_NAME = 'app_restore_20260916';

完成查询校验后再次确认角色，防止中途有人提前激活。接管前所有写入验证应有单独方案和网络隔离。

十、激活、留证与回收

89. 激活前验证备租户是否满足条件

SQL

1-- 目标集群 root@sys；只做验证
2ALTER SYSTEM ACTIVATE STANDBY
3  TENANT = app_restore_20260916 VERIFY;

返回 OK 才说明当前状态允许激活。验证通过不代表必须立即执行；业务确认、网络切换和回退方案仍要齐全。

90. 将恢复租户激活为主租户

SQL

1-- 目标集群 root@sys；不可逆角色变更，按接管方案执行
2ALTER SYSTEM ACTIVATE STANDBY
3  TENANT = app_restore_20260916;

激活后租户可以提供主库能力。原业务入口、旧主租户隔离和应用连接切换必须与本命令协调，避免双写。

91. 确认激活后的租户角色

SQL

1-- 目标集群 root@sys
2SELECT TENANT_NAME, TENANT_ROLE,
3       SWITCHOVER_STATUS, STATUS
4FROM oceanbase.DBA_OB_TENANTS
5WHERE TENANT_NAME = 'app_restore_20260916';

验收值应为 TENANT_ROLE=PRIMARY、SWITCHOVER_STATUS=NORMAL，租户状态正常。角色正确后再按接管清单开放业务流量。

92. 保存恢复 Job 的最终记录

SQL

1-- 目标集群 root@sys
2SELECT JOB_ID, RESTORE_TENANT_NAME,
3       RESTORE_SCN, RESTORE_SCN_DISPLAY,
4       STATUS, START_TIMESTAMP, FINISH_TIMESTAMP,
5       DESCRIPTION
6FROM oceanbase.CDB_OB_RESTORE_HISTORY
7WHERE RESTORE_TENANT_NAME = 'app_restore_20260916'
8ORDER BY JOB_ID DESC;

最终记录与备份集、Piece 清单、业务校验结果一起归档。字段以现场 V4.3.0 视图为准，导出前移除路径中的敏感参数。

93. 保存本次使用的备份集清单

SQL

1-- 源或可访问备份元数据的 sys 租户
2SELECT BACKUP_SET_ID, BACKUP_TYPE,
3       PREV_FULL_BACKUP_SET_ID, PREV_INC_BACKUP_SET_ID,
4       MIN_RESTORE_SCN, FILE_STATUS, PATH
5FROM oceanbase.CDB_OB_BACKUP_SET_FILES
6WHERE TENANT_ID = 1002
7  AND BACKUP_SET_ID IN (40, 41, 42)
8ORDER BY BACKUP_SET_ID;

ID 列表按恢复任务实际选择结果填写。这样可以在备份清理时保护本次演练或事故恢复依赖的完整链。

94. 保存本次使用的归档 Piece 清单

SQL

1-- 源集群 root@sys
2SELECT ROUND_ID, PIECE_ID, STATUS, FILE_STATUS,
3       START_SCN, CHECKPOINT_SCN, END_SCN, PATH
4FROM oceanbase.CDB_OB_ARCHIVELOG_PIECE_FILES
5WHERE TENANT_ID = 1002
6  AND ROUND_ID = 3
7  AND PIECE_ID BETWEEN 5 AND 7
8ORDER BY PIECE_ID;

范围按恢复进度视图中的实际选择填写。备份保留策略应保护这些 Piece，至少保留到演练复盘和业务确认结束。

95. 查看恢复演练占用的资源池

SQL

1-- 目标集群 root@sys
2SELECT RESOURCE_POOL_ID, NAME, TENANT_ID,
3       UNIT_COUNT, UNIT_CONFIG_ID, ZONE_LIST
4FROM oceanbase.DBA_OB_RESOURCE_POOLS
5WHERE NAME = 'restore_pool';

恢复租户仍使用该池时不能直接删除。决定保留演练租户还是回收前，先由业务方确认取证和复盘已经结束。

96. 删除不再需要的恢复演练租户

SQL

1-- 目标集群 root@sys；破坏性操作，确认无取证和接管用途
2DROP TENANT app_restore_20260916 FORCE;

只有明确放弃该恢复副本时才执行。已激活并接管业务的租户绝不能套用本条；删除前保存验收材料和必要导出。

97. 确认恢复租户已经不存在

SQL

1-- 目标集群 root@sys
2SELECT TENANT_ID, TENANT_NAME, STATUS, IN_RECYCLEBIN
3FROM oceanbase.DBA_OB_TENANTS
4WHERE TENANT_NAME = 'app_restore_20260916';

FORCE 删除后的结果应按现场回收行为判断。确认租户不再占用资源后，才能继续清理专用资源池。

98. 删除不再使用的恢复资源池

SQL

1-- 目标集群 root@sys；写操作，先确认 TENANT_ID IS NULL
2DROP RESOURCE POOL restore_pool;

资源池仍绑定租户时删除会失败。回收后检查相关 Unit 是否消失、OBServer 配额是否释放。

99. 删除不再使用的恢复 Unit 规格

SQL

1-- 目标集群 root@sys；写操作，先确认没有资源池引用
2DROP RESOURCE UNIT restore_unit_8c;

规格本身不占用节点资源，但长期残留会干扰资源规划。共享或计划复用的规格不要删除。

100. 汇总最近一次恢复演练结果

SQL

1-- 目标集群 root@sys
2SELECT h.JOB_ID, h.RESTORE_TENANT_NAME,
3       h.RESTORE_SCN, h.RESTORE_SCN_DISPLAY,
4       h.STATUS, h.START_TIMESTAMP,
5       h.FINISH_TIMESTAMP, h.DESCRIPTION
6FROM oceanbase.CDB_OB_RESTORE_HISTORY AS h
7WHERE h.RESTORE_TENANT_NAME = 'app_restore_20260916'
8ORDER BY h.JOB_ID DESC
9LIMIT 1;

这条只是恢复引擎的最终记录。完整验收还应附上备份链、归档覆盖、恢复资源、业务校验 SQL、实际 RTO 和是否激活等证据。

总结

OceanBase 的 PITR 不是找到一份全备就能开始。先确认增量依赖、归档轮次、Piece 和每条 LS 的检查点，再把目标时间换算成 SCN，恢复计划才算有依据。

恢复最好始终落到新租户，在隔离状态检查对象、数据和业务时间点。恢复任务成功只是技术步骤完成，是否能接管业务还要由应用校验、网络切换和回退方案共同决定。

如果这份清单对你有用，欢迎点赞、收藏，并转给负责备份恢复和容灾演练的同事。

更多数据库运维专题会继续整理到 ORA100 · DBA100：

https://ora100.com/dba100

微信里也可以搜索小程序 「三笠的百令册」，随时查常用命令。

ORA100 DBA100 数据库命令手册 ORA100 DBA100 数据库命令手册