2017-11-18 177 views
2

我插入記錄使用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)交易,但它並沒有區別。

任何人都可以幫助讓我知道我做了什麼愚蠢的錯誤,或給我一些關於如何診斷這個錯誤的提示?這真讓人沮喪! 時間的差異非常大,我確信我錯過了一些基本的東西。

+0

什麼是您的數據庫層?在此期間,DTU(log/cpu/Io/Memory)的哪部分內容會被刷新? – TheGameiswar

+0

S3/P1(類似的結果),並且DTU在兩種情況下都不能達到最大值。 DTU短暫高達70%左右,然後坐在10-20%左右 – Carl

+1

然後你必須等待......在這段時間你可以收集等待 – 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'); 
0

好吧。我刪除了所有的索引,並且它有所不同,但批處理仍然在10分鐘後超時。我刪除了外部環境交易範圍(而不是使用TransactionScope.Suppress),並且突然之間時間再次看起來「正常」。大約需要50秒才能插入,它在運行時越來越接近DTU,而之前它只能達到20%左右。

我仍然不知道爲什麼它在本地2S與環境事務,但它必須是一個粉筆體驗

感謝所有誰回答 - 至少我指出在一個良好學習的方向!