本地1.2TB SQL Server可重复迁移至Azure SQL PaaS方案咨询

直接给结论：不需要优先考虑切IaaS，ADF存在适配方案，也有原生/第三方工具可以满足快速、可重复迁移的要求，具体方案按优先级排序如下：

优先方案：无额外成本的原生栈适配（适配1.2TB数据量要求） #

• 关于ADF无法处理系统版本化表的问题，本质是ADF默认的"表/视图"读取模式会拉取系统版本化表的特殊元数据属性，不需要关闭源端版本功能，改两个配置就能解决：
  1. 源端数据集切换为自定义查询模式，不要直接选表对象。如果只需要迁移当前生效数据，查询写SELECT <需要的字段列表> FROM [源Schema].[版本化表名]即可；如果需要同步全量历史版本数据，查询写SELECT <字段列表> FROM [源Schema].[版本化表名] UNION ALL SELECT <同顺序字段列表> FROM [源Schema].[版本化表名_History]，这种模式下只会读取纯数据，不会触发版本化相关的校验报错。
  2. 目标端不要提前开启系统版本化功能，先在指定的独立Schema下建好和查询输出字段完全匹配的普通表，不要加版本化相关的约束。ADF复制活动的写入前行为选TRUNCATE TABLE，就可以重复执行全量迁移，不会有版本化冲突。
• 如果追求更快的全量迁移速度，比ADF复制吞吐高2-3倍的原生方案是用bcp命令行工具导出源端数据：bcp直接读取表数据行，完全不碰系统版本化的元数据，不需要关闭源端版本功能，导出为压缩格式后上传到Azure Blob，再通过Azure SQL的BULK INSERT批量导入到目标独立Schema的普通表，1.2TB数据全量迁移通常1.5-2.5小时就能跑完，导出导入脚本可以固化，重复执行前先清空目标表即可。
• 针对源端跨库查询的存储过程、函数问题，不需要用DMA做评估迁移：数据迁移阶段不需要同步这些逻辑对象，把所有跨库涉及的源库数据都迁到同一个Azure SQL库的不同独立Schema下，后续改造存储过程时，把原跨库的多部分名称（比如OtherDB.dbo.TableA）直接替换为同库的Schema引用（比如SchemaA.TableA）即可，完全不需要用存在性能损耗的外部表。

是否需要改用IaaS部署 #

• 仅就数据重复迁移+后续ETL转换的需求，完全不需要切IaaS。只有当后续ETL改造完成、业务上线前，确认存在大量Azure SQL PaaS不支持的特性（比如依赖CLR自定义程序、Windows认证链路、特定服务器级权限要求）时，再评估IaaS的必要性，否则IaaS带来的运维成本、性能开销远高于PaaS。

第三方工具选项（低代码投入场景） #

• 如果不想自行配置ADF、写bcp脚本，可以选SQL Server生态成熟的商用数据对比迁移工具，这类工具原生适配SQL Server 2017系统版本化表，不需要关闭源端版本功能，支持直接配置源表到目标独立Schema表的字段映射，可以保存迁移项目文件实现重复执行，内置的批量写入性能和ADF相当甚至更高，适合不想投入开发成本的团队，缺点是需要支付商用授权费用。

重复迁移效率优化建议 #

• 第一次全量迁移完成后，后续测试阶段的重复迁移不需要每次同步全量1.2TB数据：系统版本化表自带SysStartTime/SysEndTime时间戳字段，可以基于这个字段做增量同步，每次只导上次迁移节点之后新增/修改的行，把单次迁移时间压缩到分钟级，等上线前再做一次全量最终同步即可。
• 数据导入阶段目标端不要提前建非聚集索引、外键约束，等所有数据写入完成后再统一创建索引、加约束，最后再开启目标表的系统版本化功能，整体导入速度可以提升3-5倍。

内容的提问来源于stack exchange，提问作者Keith Miller