SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Azure のデータ更新時に発生する待ち事象を確認してみる

one comment

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)
BEGIN
    INSERT INTO #tmp
    SELECT command, wait_type FROM sys.dm_exec_requests
    WHERE wait_type IS NOT NULL AND command = ‘INSERT’
END

次に他のクエリウィンドウで以下のクエリを実行してデータを INSERT します。

SET NOCOUNT ON
CREATE TABLE [dbo].[Table_1](
    [Col1] [uniqueidentifier] NOT NULL,
    [Col2] [int] NULL,
    [Col3] [char](4000) NULL,
CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED
([Col1] ASC)
)

BEGIN TRAN
DECLARE @i int = 0
WHILE (@i < 1000)
BEGIN
    INSERT INTO Table_1 VALUES(NEWID(), @i , NEWID())
    SET @i += 1
END
COMMIT TRAN
DROP TABLE [dbo].[Table_1]

INSERT が終了したら最初に実行したままにしていたクエリを終了させテーブルの情報を取得します。

SELECT DISTINCT * FROM #tmp

image

[SE_REPL_SLOW_SECONDARY_THROTTLE] というのがコミット時に発生している待ちのようです。
INSRT の BEGIN TRAN / COMMIT TRAN を外して同じデータを取得してみると待ち事象が変わってきます。
image

この時は、[SE_REPL_COMMIT_ACK] となるようです。

データの更新料によってこの辺は変わってきそうですね。
[SE_REPL_xxx] の待ち事象は通常の SQL Server では存在していなかったので SQL Azure 特有かもしれないですね。
# レプリケーションの設定をしたら出てくるかもしれませんがそこまでは試せていません…。

COMMIT 時にレプリケーション関係の待ちが発生してそうという雰囲気がちょっと見えました。

Share

Written by Masayuki.Ozawa

6月 10th, 2011 at 8:11 pm

Posted in SQL Server,Windows Azure

Tagged with

One Response to 'SQL Azure のデータ更新時に発生する待ち事象を確認してみる'

Subscribe to comments with RSS or TrackBack to 'SQL Azure のデータ更新時に発生する待ち事象を確認してみる'.

  1. […] Scalability Compared and Contrasted という技術文書でも紹介されていますね。 昔、SQL Azure のデータ更新時に発生する待ち事象を確認してみる […]

Leave a Reply