SqlBulkCopy *非常に*ゆっくりとAzureのSQLとC＃

Question

に私はローカルでSqlBulkCopyとFastMemberに

を使用してSQLにレコードを挿入しています私は約2秒で100kのレコードを挿入することができます。 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)を使用してトランザクションを削除しようとしましたが、それは何の違いを作ったんです。

誰かが私に何か愚かなミスをしたのか、これを診断するためのヒントを教えてくれますか？それは本当にイライラしています！ 時間の違いが大きすぎるので、私はここで何か根本的に欠けていると確信しています。そのワークロードを実行している間、あなたは高いログ書き込みパーセントを検証するために、クエリの下に実行することができます

Answer 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 

あなたはさまざまな方法の1 this記事で説明を使用して、そのワークロードに関連付けられている待機をも集めることができます。そのワークロードの実行中にIO関連の高い待機が発生する可能性があります。

高IO負荷のワークロードの実行中にスロットルを回避するには、実行前にスケールアップして、ワークロードが完了した後に最初のティアにスケールダウンすることができます。

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

Answer 2

私はすべてのインデックスを削除しましたが、いくつかの違いがありましたが、バッチはまだ10分でタイムアウトしていました。 （TransactionScope.Suppressを使用するのではなく）外側のアンビエントトランザクションスコープを削除しました。突然、すべての時間が再び「正常」に戻っています。挿入するのに約50秒かかり、実行中はDTUを最大に近づけていますが、それ以前は約20％にしか達していません。

それは周囲のトランザクションと2秒でローカルに動作しますなぜ私はまだ分かりませんが、それは答えすべて

おかげで体験してアップチョークする一つのことがあるでしょう - と、少なくとも良いで私を指摘します学習する方向に！