SqlBulkCopy的*非常*在Azure上的Sql缓慢和C＃

我插入记录使用SqlBulkCopy的和FastMemberSqlBulkCopy的*非常*在Azure上的Sql缓慢和C＃

本地我可以在约2秒插入10万条记录的SQL。当我在Azure Web应用webjob和Azure Sql数据库上运行此应用时，需要超过10分钟时间并将事务超时。表格定义与表格中的相同数量的数据相似。没有锁定，它只是很慢。当我在本地运行它并尝试写入Azure Sql数据库时，它也需要大于10分钟。

的实际通话很简单，因为它可以：

using(var bulkCopy = new SqlBulkCopy(connection){DestinationTableName="Table") 
using(var reader = ObjectReader.Create(entities, columnList) 
{ 
    await bulkCopy.WriteToServerAsync(reader).ConfigureAwait(false); 
}

我试图消除使用TransactionScope(Suppress)交易，但它并没有区别。

任何人都可以帮助让我知道我做了什么愚蠢的错误，或给我一些关于如何诊断这个错误的提示？这真让人沮丧！时间的差异非常大，我确信我错过了一些基本的东西。

来源

2017-11-18 Carl

什么是您的数据库层？在此期间，DTU（log/cpu/Io/Memory）的哪部分内容会被刷新？ – TheGameiswar

S3/P1（类似的结果），并且DTU在两种情况下都不能达到最大值。 DTU短暂高达70％左右，然后坐在10-20％左右 – Carl

然后你必须等待......在这段时间你可以收集等待 – TheGameiswar

-1

您可以运行下面的查询，以验证高日志写入％的存在，而负载运行：

SELECT 
    (COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent > 80 THEN 1 ELSE 0 END) * 1.0)/COUNT(end_time) AS 'CPU Fit Percent' 
    ,(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent > 80 THEN 1 ELSE 0 END) * 1.0)/COUNT(end_time) AS 'Log Write Fit Percent' 
    ,(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent > 80 THEN 1 ELSE 0 END) * 1.0)/COUNT(end_time) AS 'Physical Data Read Fit Percent' 
FROM sys.dm_db_resource_stats

您还可以收集使用不同的方法之一是工作负载相关的等待上this文章解释。在执行该工作负载期间，您可能会看到与IO相关的高等待时间。

为避免在执行高IO密集型工作负载期间节流，您可以在运行它们之前进行扩展，并在工作负载完成后向下缩小到初始层。

ALTER DATABASE [db1] MODIFY (EDITION = 'Premium', SERVICE_OBJECTIVE = 'P15');

来源

2017-11-18 15:10:40

好吧。我删除了所有的索引，并且它有所不同，但批处理仍然在10分钟后超时。我删除了外部环境交易范围（而不是使用TransactionScope.Suppress），并且突然之间时间再次看起来“正常”。大约需要50秒才能插入，它在运行时越来越接近DTU，而之前它只能达到20％左右。

我仍然不知道为什么它在本地2S与环境事务，但它必须是一个粉笔体验

感谢所有谁回答 - 至少我指出在一个良好学习的方向！

来源

2017-11-19 02:18:54 Carl

SqlBulkCopy的*非常*在Azure上的Sql缓慢和C＃

回答

相关问题

SqlBulkCopy的非常在Azure上的Sql缓慢和C＃