通过日志重放服务将Azure SQL VM的MSSQL库恢复到SQL托管实例失败咨询

报错信息：(InternalServerError) An unexpected error occured while processing the request. Tracking ID: '59763add-7356-4fe4-b797-be1fca9db677'

报错截图：

1. 前置配置合规性校验 #

• 校验源SQL Server 2016版本：必须为SQL Server 2016 SP2 CU10及以上版本，低于该版本会触发内部服务处理异常
• 校验源数据库配置限制：确认源库未启用TDS端点、内存优化表（通用层SQL MI部分版本对内存优化表的LRS迁移支持存在限制），单库文件大小未超过通用层存储上限，同时不存在未提交的分布式事务，未使用系统数据库作为迁移源
• 权限校验：确认Azure CLI执行身份对源备份存储账户、目标SQL MI均持有SQL Managed Instance Contributor、Storage Blob Data Contributor权限，存储账户防火墙已放通SQL MI出站IP以及CLI执行环境的IP

2. LRS任务参数与备份文件校验 #

• 确认CLI命令参数正确性：连续模式下必须指定--auto-complete为false，--last-backup-name无需赋值，正确命令结构参考：

az sql midb log-replay start --subscription <订阅ID> --resource-group <资源组名> --managed-instance <目标MI名称> --name <目标库名> --storage-uri <备份存储容器SAS URI> --sql-server-logins --auto-complete false

• 校验备份存储SAS URI有效性：确认SAS令牌未过期，权限包含读、列权限，有效期覆盖整个迁移周期，未绑定额外IP限制导致服务侧无法访问
• 备份文件合规性校验：所有全量、差异、日志备份均未加密、未损坏，备份采用NORECOVERY模式生成，日志备份链连续无断裂，备份文件名遵循SQL Server默认命名规范（LRS服务对自定义命名的备份文件识别存在概率性异常）

3. 服务侧日志与资源排查 #

• 进入Azure门户目标SQL MI的【活动日志】，筛选对应时间窗口、关联Tracking ID 59763add-7356-4fe4-b797-be1fca9db677的操作记录，查看操作详情中的子错误码，通用InternalServerError通常会在活动日志中挂载更具体的失败原因，如备份解析失败、存储访问拒绝、MI资源不足等
• 检查SQL MI迁移时段资源使用率：确认CPU、存储、IOPS未达到阈值，资源不足会导致LRS服务内部处理中断触发报错
• 若以上排查均未定位根因，可在Azure门户提交技术支持工单，提供本次报错的Tracking ID，支持侧可通过该ID拉取服务端完整链路日志确认问题

内容的提问来源于stack exchange，提问作者Jagath Jayaprakash