SQL Azure のユーザー データベースは 3 重化され、耐障害性が確保されています。
詳しくは蒼の王座さんのブログに書かれていますのでこちらをご参照。
蒼の王座 >> TechEDNAセッション：SQL Azureパフォーマンスの考察とトラブルシューティングまとめ
こちらの記事の中に以下の一文がありました。
コミット時に複製するので、複製できなければコミットできない
コミット時に何か待ち事象が発生していないかな~ということが気になり調べてみました。
■発生している待ち事象を確認してみる
[コミット時に複製する] とあるので今回は以下のクエリを用意してみました。
まずはに [sys.dm_exec_requests] から定期的に情報を取得するクエリを実行しておきます。
# INSERT を実行するユーザーデータベースを選択した状態で実行します。
|
SET NOCOUNT ON CREATE TABLE #tmp(Col1 nvarchar(100), Col2 nvarchar(100)) WHILE(0=0) |
次に他のクエリウィンドウで以下のクエリを実行してデータを INSERT します。
|
SET NOCOUNT ON BEGIN TRAN |
INSERT が終了したら最初に実行したままにしていたクエリを終了させテーブルの情報を取得します。
| SELECT DISTINCT * FROM #tmp |
[SE_REPL_SLOW_SECONDARY_THROTTLE] というのがコミット時に発生している待ちのようです。
INSRT の BEGIN TRAN / COMMIT TRAN を外して同じデータを取得してみると待ち事象が変わってきます。 
この時は、[SE_REPL_COMMIT_ACK] となるようです。
データの更新料によってこの辺は変わってきそうですね。
[SE_REPL_xxx] の待ち事象は通常の SQL Server では存在していなかったので SQL Azure 特有かもしれないですね。
# レプリケーションの設定をしたら出てくるかもしれませんがそこまでは試せていません…。
COMMIT 時にレプリケーション関係の待ちが発生してそうという雰囲気がちょっと見えました。
[…] Scalability Compared and Contrasted という技術文書でも紹介されていますね。 昔、SQL Azure のデータ更新時に発生する待ち事象を確認してみる […]
Azure SQL Database の sys.dm_db_wait_stats を使ってみる « SE の雑記
6 2月 13 at 22:53