一条语句查询可以恢复时间

AntTech_PZFBUG · 2025 年2 月 27 日 17:30

【使用环境】生产环境 or 测试环境测试
【 OB or 其他组件】 OB 4.0
【使用版本】 OB 4.0
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

问题：
如何一条SQL 语句查询可以该集群下的所有租户的可恢复时间？

【备注】基于 LL

M 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

论坛小助手 · 2025 年2 月 27 日 17:31

根据文档库中的信息，您可以使用以下 SQL 语句查询集群下所有租户的可恢复时间。此查询基于 oceanbase.CDB_OB_BACKUP_TASK_HISTORY 视图，该视图记录了每个租户的备份任务历史，包括开始时间和结束时间等信息。

查询所有租户的可恢复时间

SELECT 
    TENANT_ID,
    MAX(START_TIMESTAMP) AS earliest_recover_time,
    MAX(END_TIMESTAMP) AS latest_recover_time
FROM 
    oceanbase.CDB_OB_BACKUP_TASK_HISTORY
GROUP BY 
    TENANT_ID;

解释：

TENANT_ID: 租户的唯一标识符。
earliest_recover_time: 最早的可恢复时间，即最近一次备份任务的开始时间。
latest_recover_time: 最新的可恢复时间，即最近一次备份任务的结束时间。

注意事项：

备份任务历史记录：上述查询依赖于备份任务的历史记录。如果某个租户没有备份任务记录，则不会出现在结果中。
时间精度：START_TIMESTAMP 和 END_TIMESTAMP 是备份任务的开始和结束时间戳，精确到纳秒级别。
权限要求：需要在 sys 租户中执行此查询，以确保有足够的权限访问所有租户的备份任务历史记录。

如果您需要更详细的恢复时间信息（例如具体的 SCN 或时间点），可以根据实际需求调整查询条件或使用其他相关视图进行联合查询。

希望这能解决您的问题。如果有更多疑问，请随时联系 OceanBase 的人工答疑以获取更多帮助。

检索到的文档如下:

AntTech_PZFBUG · 2025 年2 月 28 日 09:24

论坛小助手:

SELECT 
    TENANT_ID,
    MAX(START_TIMESTAMP) AS earliest_recover_time,
    MAX(END_TIMESTAMP) AS latest_recover_time
FROM 
    oceanbase.CDB_OB_BACKUP_TASK_HISTORY
GROUP BY 
    TENANT_ID;

SELECT TENANT_ID, MAX(START_TIMESTAMP) AS earliest_recover_time, MAX(END_TIMESTAMP) AS latest_recover_time FROM oceanbase.CDB_OB_BACKUP_TASK_HISTORY GROUP BY TENANT_ID
TENANT_ID earliest_recover_time latest_recover_time
0 1074 2025-02-26 15:58:25.677097 2025-02-26 15:59:57.548932
1 1076 2025-02-26 15:57:59.339557 2025-02-26 16:00:50.782597
2 1078 2025-02-26 14:19:46.602359 2025-02-26 14:30:00.413885
3 1080 2025-02-26 05:30:05.873229 2025-02-26 05:43:22.475032

今天是2月28日，查询结果可恢复时间为2-26日，只要本地存放日志，是否可以恢复到2月28日呢？

论坛小助手 · 2025 年2 月 28 日 09:36

根据您提供的查询结果和当前日期（2月28日），要确定是否可以恢复到2月28日，需要进一步检查日志归档情况以及日志恢复源的信息。具体来说，您可以按照以下步骤进行确认：

1. 检查日志归档情况

首先，确认是否有足够的归档日志覆盖从最近一次备份任务结束时间（2月26日）到当前时间（2月28日）的时段。可以通过查询 oceanbase.CDB_OB_LOG_RESTORE_SOURCE 视图来获取日志恢复源信息。

SELECT 
    TENANT_ID, 
    TYPE, 
    VALUE, 
    RECOVERY_UNTIL_SCN 
FROM 
    oceanbase.CDB_OB_LOG_RESTORE_SOURCE;

2. 检查归档日志的时间范围

确保归档日志的时间范围涵盖了从2月26日到2月28日的时段。如果归档日志存在并且完整，理论上可以恢复到2月28日。

3. 使用 `RECOVER` 命令恢复到指定时间点

如果确认归档日志完整，可以使用 ALTER SYSTEM RECOVER STANDBY 命令将租户恢复到指定的时间点。例如，恢复到2月28日的具体时间：

ALTER SYSTEM RECOVER STANDBY [TENANT = tenant_name] UNTIL TIME='2025-02-28 12:00:00';

4. 确认日志模式

确保租户的日志模式为 ARCHIVELOG，这可以通过查询 oceanbase.DBA_OB_TENANTS 视图来确认：

SELECT 
    TENANT_ID, 
    TENANT_NAME, 
    LOG_MODE 
FROM 
    oceanbase.DBA_OB_TENANTS;

如果 LOG_MODE 是 NOARCHIVELOG，则无法通过归档日志进行恢复。需要确保日志模式为 ARCHIVELOG 才能进行基于时间点的恢复。

综合总结

查询日志恢复源：确认归档日志的存在和完整性。
检查日志模式：确保租户的日志模式为 ARCHIVELOG。
执行恢复命令：在确认归档日志完整的情况下，使用 ALTER SYSTEM RECOVER STANDBY 命令恢复到指定时间点。

如果您确认所有条件都满足，则可以恢复到2月28日。如果有任何疑问或不确定的地方，请联系 OceanBase 的人工答疑以获取更多帮助。

检索到的文档如下:

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

淇铭 · 2025 年2 月 28 日 09:45

可以看看这个文档

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002013165

AntTech_PZFBUG · 2025 年2 月 28 日 09:49

ELECT TENANT_ID, TYPE, VALUE, RECOVERY_UNTIL_SCN FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE

	TENANT_ID	TYPE	VALUE	RECOVERY_UNTIL_SCN
0	1074	LOCATION	file:///data/obbackup_obclu_test_ncore_2/obclu_test_ncore/1666081998/tenant_incarnation_1/1188/clog	4611686018427387903
1	1076	LOCATION	file:///data/obbackup_obclu_test_ncore_2/obclu_test_ncore/1666081998/tenant_incarnation_1/1190/clog	4611686018427387903
2	1078	LOCATION	file:///data/obbackup_obclu_test_ncore_2/obclu_test_ncore/1666081998/tenant_incarnation_1/1192/clog	4611686018427387903
3	1080	LOCATION	file:///data/obbackup_obclu_test_ncore_2/obclu_test_ncore/1666081998/tenant_incarnation_1/1198/clog	4611686018427387903

-》这里输出RECOVERY_UNTIL_SCN，如何获取该SCN 号对应的时间戳。比如4611686018427387903 对应哪个时间戳，同时一条语句查询出来可以恢复的时间？

独善其身 · 2025 年2 月 28 日 10:23

问题我都没有看明白

淇铭 · 2025 年2 月 28 日 10:43

select SCN_TO_TIMESTAMP(number) from dual;可以用很这个函数进行转化看看时间戳
你查看的视图是日志恢复源的信息查看

上面的可以恢复的位点怎么计算上面我发给你了

AntTech_PZFBUG · 2025 年2 月 28 日 10:55

通过转换时间，查看可以恢复的时间，好像不对，2116-02-21 ？

sELECT TENANT_ID, TYPE, VALUE, RECOVERY_UNTIL_SCN,SCN_TO_TIMESTAMP(RECOVERY_UNTIL_SCN) from oceanbase.CDB_OB_LOG_RESTORE_SOURCE

	TENANT_ID	TYPE	VALUE	RECOVERY_UNTIL_SCN	SCN_TO_TIMESTAMP(RECOVERY_UNTIL_SCN)
0	1074	LOCATION	file:///data/obbackup_obclu_test_ncore_2/obclu_test_ncore/1666081998/tenant_incarnation_1/1188/clog	4611686018427387903	2116-02-21 07:53:38.427387
1	1076	LOCATION	file:///data/obbackup_obclu_test_ncore_2/obclu_test_ncore/1666081998/tenant_incarnation_1/1190/clog	4611686018427387903	2116-02-21 07:53:38.427387
2	1078	LOCATION	file:///data/obbackup_obclu_test_ncore_2/obclu_test_ncore/1666081998/tenant_incarnation_1/1192/clog	4611686018427387903	2116-02-21 07:53:38.427387
3	1080	LOCATION	file:///data/obbackup_obclu_test_ncore_2/obclu_test_ncore/1666081998/tenant_incarnation_1/1198/clog	4611686018427387903	2116-02-21 07:53:38.427387

AntTech_PZFBUG · 2025 年2 月 28 日 11:20

上面的可以恢复的位点怎么计算上面我发给你了

-》sql?

淇铭 · 2025 年2 月 28 日 11:22

文档有说明怎么计算需要你自己计算一下就好了没有sql 需要自己写

AntTech_PZFBUG · 2025 年2 月 28 日 14:08

文档描述大而全，不知道哪个视图才是我需要的

淇铭 · 2025 年2 月 28 日 14:09

AntTech_PZFBUG · 2025 年2 月 28 日 14:10

谢谢标注

AntTech_PZFBUG · 2025 年2 月 28 日 14:16

是不归档今天上午8点左右出了问题，不知道我的理解是否对？

查看CHECKPOINT_SCN_DISPLAY =2025-02-28 08:13:11.808758
并且status = stop.

select * from oceanbase.CDB_OB_ARCHIVELOG

	TENANT_ID	DEST_ID	ROUND_ID	INCARNATION	STATUS	START_SCN	START_SCN_DISPLAY	CHECKPOINT_SCN	CHECKPOINT_SCN_DISPLAY	COMPATIBLE	BASE_PIECE_ID	USED_PIECE_ID	PIECE_SWITCH_INTERVAL	UNIT_SIZE	COMPRESSION	INPUT_BYTES	INPUT_BYTES_DISPLAY	OUTPUT_BYTES	OUTPUT_BYTES_DISPLAY	COMPRESSION_RATIO	DELETED_INPUT_BYTES_DISPLAY	DELETED_OUTPUT_BYTES_DISPLAY	PATH
0	1074	1001	2	1	STOP	1740685505126057276	2025-02-28 03:45:05.126057	1740701591808758102	2025-02-28 08:13:11.808758	1	88	88	86400000000	1	none	96778684	92.30MB	96778684	92.30MB	1.0	0.00MB	0.00MB	file:///data/obbackup_obclu_test_ncore2/obclu_test_ncore2/1666082002/tenant_incarnation_1/1074/clog
1	1076	1001	2	1	STOP	1740685503819329780	2025-02-28 03:45:03.819329	1740701589811395670	2025-02-28 08:13:09.811395	1	88	88	86400000000	1	none	83284973	79.43MB	83284973	79.43MB	1.0	0.00MB	0.00MB	file:///data/obbackup_obclu_test_ncore2/obclu_test_ncore2/1666082002/tenant_incarnation_1/1076/clog
2	1078	1001	3	1	STOP	1740685504848973040	2025-02-28 03:45:04.848973	1740701588463536812	2025-02-28 08:13:08.463536	1	84	84	86400000000	1	none	416684667	397.38MB	416684667	397.38MB	1.0	0.00MB	0.00MB	file:///data/obbackup_obclu_test_ncore2/obclu_test_ncore2/1666082002/tenant_incarnation_1/1078/clog
3	1080	1003	4	1	STOP	1740685504683139774	2025-02-28 03:45:04.683139	1740701589399675489	2025-02-28 08:13:09.399675	1	88	88	86400000000	1	none	239745039	228.64MB	239745039	228.64MB	1.0	0.00MB	0.00MB	file:///data/ob_backup_zhob4_obclu_test_ncore2/core_bt_10/obclu_test_ncore2/1666082002/tenant_incarnation_1/1080/clog

淇铭 · 2025 年2 月 28 日 14:25

是的归档在这个时间停止了
status 归档状态：

PREPARE：准备归档起点 START_SCN
BEGINNING：正在启动日志归档
DOING：正在进行日志归档
INTERRUPTED：日志归档中断，需要人工介入
STOP：日志归档已停止
STOPPING：正在停止日志归档
SUSPENDING：正在暂停日志归档
SUSPEND：日志归档已暂停

CHECKPOINT_SCN：当前归档位点
CHECKPOINT_SCN_DISPLAY：将 CHECKPOINT_SCN 转换成时间单位之后的展示

AntTech_PZFBUG · 2025 年2 月 28 日 14:29

谢谢你的答复

旭辉 · 2025 年2 月 28 日 21:28

这个不是一条SQL能得出结果，这个是OCP 通过 OBServer 的 ob_admin 工具，解析备份源文件，然后根据解析结果，分析数据备份集和日志归档区间计算得到解析可恢复时间。

1.解析 tenant_info 文件得到备份源租户信息
#/home/admin/oceanbase/bin/ob_admin dump_backup -d"file:///obbackup/backup_3245/1704259770/incarnation_1/tenant_info"

2.解析 tenant_data_backup_info 文件得到租户的数据备份集信息
#/home/admin/oceanbase/bin/ob_admin dump_backup -d"file:///obbackup/backup_3245/1704259770/incarnation_1/1001/data/tenant_data_backup_info"

3.解析 tenant_clog_backup_info 文件得到租户的日志归档信息
#/home/admin/oceanbase/bin/ob_admin dump_backup -d"file:///obbackup/backup_3245/1704259770/incarnation_1/1001/clog/tenant_clog_backup_info"

4.根据数据备份和日志归档的结果，计算得到可恢复时间。

AntTech_PZFBUG · 2025 年3 月 5 日 10:35

理解，所以每次调用这个界面，后台触发这个命令？

Yuanshuai · 2025 年3 月 6 日 19:22

明白了