问题现象
物理恢复场景，执行 alter system restore 做物理恢复后，物理恢复卡住，租户同步位点不推进。
通过查看内部表 __all_rootservice_event_history 有关物理恢复任务执行状态，查询语句如下。
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 状态，不往下推进。
关键诊断信息
触发条件
主库至少执行过两轮归档，比如两轮归档分别为 round 1 和 round 2，并且 round 1 在关闭归档任务时，访问归档介质出现过问题（如归档介质写满、归档介质权限变更、归档介质异常等），该场景下关闭归档会导致 round 1 的归档元信息缺失。如果物理恢复时依赖的归档日志属于 round 2，但由于 round 1 元文件的缺失和实现上的原因，会导致消费日志被错误定位到 round 1，而此时 round 1 的日志很有可能已经被删除/回收，进而导致无法消费日志，恢复任务卡住。
事前巡检
首先，到物理恢复指定的归档目录下，查看 rounds 目录下的文件。假设当前有两轮归档，正常情况下，目录下的文件内容如下。
round_d1001r1_start.obarc
round_d1001r1_end.obarc
round_d1001r2_start.obarc
但在该问题场景下，目录下的文件内容如下。
round_d1001r1_start.obarc
round_d1001r2_start.obarc
即 round 1 的 end 元文件缺失，此时如果恢复依赖的日志内容是 round 2，那么需要将 round1 的 start 元文件先从目录中移走再执行恢复，恢复完成后再移回。
事后诊断
查看物理恢复进度/历史表，获取恢复租户 restore 任务对应的 backup_piece_list 语句如下。
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 日志信息，打印的日志内容如下。
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，均需要移动），等物理恢复任务完成后再将该文件移回。上述操作后，如果本次物理恢复任务最终失败，需要重新发起恢复任务，然后再将文件移回到原来位置。
规避方式
尽量保证归档介质可用，避免访问归档介质出现问题。
