【 使用环境 】测试环境
根据官方文档查询，end_scn卡在1704352845734310600 （15:20）无法推进，经测试，15：20之前的时间是能恢复成功的，15：20之后的时间就会卡在这个1704352845734310600
做了多次增备，最近的备份为中午11点56和下午15：42都做了一次增备，增备完复制的归档日志，备份集和归档如下：
【复现路径】问题出现前后相关操作https://www.alipan.com/s/WTQarMd2bZY observer.7z (8.6 MB)observer11.19分.7z (9.0 MB)
补充：经过比对日志，好像是logstream_1001缺失的原因， 我是15:42复制的日志，复制过来66.obarc大小为0
这是现在看到的原归档目录logstream_1001的数据情况
而这里看15：42的checkpoint也已经出来了
所以是什么原因导致15：20-15：40的logstream_1001日志没有复制过来
1 个赞
王利博
2024 年1 月 8 日 15:51
#2
云盘点不开。如果日志过大建议把observer.log 压缩切分后再上次下
1 个赞
与义
2024 年1 月 8 日 16:31
#4
重新复制 66.obarc 之后恢复正常了吗？这里描述的恢复是把备份数据拷贝到异地目录进行恢复吗？
1 个赞
是的，我是拷到异地进行恢复的，重新复制之后是能正常恢复的，所以我主要疑惑为什么66.obarc文件明明拷贝过来了，为什么大小会是0，这是什么机制造成的么？
另外我是自己拷贝的归档日志文件，如果使用**ALTER SYSTEM BACKUP INCREMENTAL DATABASE PLUS ARCHIVELOG;**会直接将此次增量备份与上次备份（增备或全备）之间的日志都备份下来么？
与义
2024 年1 月 8 日 17:06
#7
与义
2024 年1 月 8 日 17:07
#8
是的，我是拷到异地进行恢复的，重新复制之后是能正常恢复的，所以我主要疑惑为什么66.obarc文件明明拷贝过来了，为什么大小会是0，这是什么机制造成的么？
可能当时这个最新的归档文件并没有完成落盘，导致复制过来的大小是 0。
想了解下为什么需要拷贝到异地进行恢复？
看这里PLUS ARCHIVELOG 主要就是为了用来创建备租户的，我也手动测试了一下，应该是不能用来增备时备份日志的，增备带了这个也不能恢复到中间的时间点
蒙
2024 年1 月 8 日 17:22
#10
这个落盘是有延迟的吗，有什么机制能手动让他完成落盘么
与义
2024 年1 月 8 日 17:28
#11
日志归档是持续进行的，你的截图里 65.obarc 和 66.obarc 两个文件的最后修改时间相同。我刚才想表达的是：可能你复制日志归档文件的时候恰好这个文件刚创建还没写入
蒙
2024 年1 月 8 日 17:35
#12
这两个修改时间相同，是因为我是15：42把他们一起复制过来的，原归档目录下，他们的最后修改时间不同的，65.obrac的最后修改时间是15：20，我当时复制归档日志前查了一下 SELECT * FROM oceanbase.CDB_OB_ARCHIVELOG\G的，当时查出来的CHECKPOINT_SCN_DISPLAY是15:40的，然后15：42去复制的，按理来说，日志应该已经归档的，65.obarc是到15：20的，所以疑问是15：42的时候15：20到15：40的日志为什么没写入到66.obrac
与义
2024 年1 月 9 日 15:43
#13
如果不进行异地拷贝，直接从日志归档目的地进行物理恢复会出现这个问题吗？
蒙
2024 年1 月 9 日 15:48
#14
这个倒没有试过，只是我们想要定时做一些备份，然后能异机按照时间点去恢复起数据库作为测试使用
与义
2024 年1 月 9 日 16:03
#15
可以尝试从原地址恢复看是否会出现卡在某个时间的情况，也可以尝试再进行异地拷贝后物理恢复会不会稳定复现这个问题。如果前者不会出现这个问题后者会的话，请尽量避免这样拷贝日志归档文件进行恢复使用。
在 OB 3.2.x 版本有二次备份的功能，而在 4.x 里是不支持的，所以不可预见手动拷贝出去再进行恢复的结果。
蒙
2024 年1 月 9 日 16:10
#16
好的，这个我再试试，再问一下，还有什么其他能做任意时间点恢复的备份方式么
与义
2024 年1 月 9 日 16:32
#17
至少一次全量备份+完整的日志归档就可以支持恢复到指定时间点
蒙
2024 年1 月 9 日 16:42
#18
可以的化，建议后续提供一个可以保证完整归档的方式，日志可以备份更好，总会有一些特殊场景需要使用复制或备份日志的
1 个赞
