我正在使用Azure Data Factory v2在Azure SQL Server上进行数据加载。我开始加载数据，数据库设置为具有 800 个 DTU 的标准定价层。它很慢，所以我将 DTU 增加到 1600。(我的管道自 7 小时以来仍在运行(。
我决定更改定价层。我将定价层更改为"高级"，DTU 设置为 1000。(我没有进行任何其他更改(。
管道因失去连接而失败。我重新运行管道。
现在，当我监视管道时，它工作正常。当我监视数据库时。DTU 使用率平均不超过 56%。
我正在处理大量数据。如何加快流程？
我希望 DTU 必须最大化。但平均利用率约为 56%。
请按照此文档复制活动性能和可伸缩性指南进行操作。
本教程为我们提供了性能调整步骤。
一种方法是使用更多 DTU 增加 Azure SQL 数据库层。你已将 Azure SQL 数据库层增加了 1000 个 DTU，但平均利用率约为 56%。我认为您不需要如此高的价格层。
您需要考虑其他方法来提高性能。例如设置更多的数据集成单元(DIU(。
数据集成单元是一种度量值，表示 Azure 数据工厂中单个单元的功率(CPU、内存和网络资源分配的组合(。数据集成单元仅适用于 Azure 集成运行时，不适用于自承载集成运行时。
希望这有帮助。
Microsoft的标准答案似乎是您需要调整目标数据库或扩展到更高的层。这表明 Azure 数据工厂不是复制性能的限制因素。
但是，我们已经对单个表、单个副本活动、~15 GB 数据进行了一些测试。该表不包含varchar(max(，精度高，只有简单明了的数据。
结论：选择哪种层(当然不会太低(并不重要，大致高于 S7/800 DTU，8 个 vcore，复制活动的性能为 ~10 MB/s，并且不会上升。目标数据库的负载为 50%-75%。
我们的假设是，由于我们可以针对此问题继续抛出更高的数据库层，但未看到复制活动性能有任何改进，因此这与 Azure 数据工厂相关。
我们的解决方案是，由于我们要加载大量单独的表，因此通过 for each 循环和将批处理计数设置为至少 4 进行横向扩展而不是纵向扩展。
增加DIU的方法仅适用于某些情况： https://learn.microsoft.com/en-us/azure/data-factory/copy-activity-performance#data-integration-units
大于 4 的 DIU 的设置当前仅在复制时适用 来自 Azure 存储、Azure Data Lake Storage、Amazon S3 的多个文件， Google Cloud Storage、Cloud FTP 或 Cloud SFTP 到任何其他云数据 商店。
在我们的例子中，我们从关系数据库复制数据。