SSIS数据流在Azure DB开启auto-scaling时仅返回部分数据的问题咨询

是否为已知Bug？ #

这是Azure SQL DB自动缩放与OLE DB连接结合时的已知兼容性问题。核心原因是自动缩放触发时，Azure会对数据库实例进行无感知故障转移/资源重分配，而OLE DB连接管理器在这种场景下无法自动检测连接中断并重建，导致数据流任务中途停止读取源数据，但SSIS不会将此判定为错误，仍标记任务执行成功。

解决方案 #

1. 错开执行时间与缩放窗口 #

• 查看Azure监控中的自动缩放触发历史，将ETL任务调度到低负载、不会触发缩放的时间段执行。
• 若无法调整时间，可在ETL执行前通过Azure CLI或PowerShell手动将DB调整到足够DTU级别，执行完成后再恢复自动缩放规则。示例命令：

  # 手动设置DTU
  Set-AzSqlDatabase -ResourceGroupName "yourRG" -ServerName "yourServer" -DatabaseName "yourDB" -RequestedServiceObjectiveName "S3"
  # 执行完ETL后恢复自动缩放逻辑
  

2. 优化SSIS包的连接与校验逻辑 #

• 启用OLE DB连接重试：在OLE DB连接管理器的属性窗口中，设置ConnectRetryCount（建议设为3-5）和ConnectRetryInterval（建议设为10秒），让连接在故障转移后自动重试。
• 添加行计数校验：在数据流任务末尾添加行计数组件，将计数结果写入包变量；在包最后添加脚本任务，对比源数据预期行数（可通过预执行查询SELECT COUNT(*) FROM 归档表 WHERE 条件获取）与实际加载行数，不匹配则抛出错误标记包执行失败。
• 替换为ADO.NET连接管理器：ADO.NET对Azure SQL DB的故障转移兼容性更好，能自动处理实例切换，避免数据流中途中断。

3. 调整数据库与缩放规则 #

• 优化查询与表结构：针对COLUMNSTORE_ARCHIVE压缩表，简化查询条件，避免全表扫描；或在ETL执行前临时解除压缩（ALTER TABLE 归档表 REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = NONE)），完成后重新压缩，降低查询负载。
• 调整自动缩放规则：提高缩放触发的DTU使用率阈值（比如从70%提升至90%），延长冷却时间（比如设置为30分钟），避免ETL查询误触发缩放；或为ETL时间段设置专属的缩放规则，临时提高最低DTU限制。

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