SQL Server阻塞blocking案例分析

今天在效能測試過程中發現大量阻塞報警，檢查whoisactive()資料發現，阻塞blocking頭部session當前執行的語句如下：

<?query --

(@p0 int,@p1 datetime,@p2 bigint,@p3 bigint,@p4 bigint)INSERT INTO [LicenseAction]([LicenseActionTypeID], [ActionDate], [LicenseID], [DocumentID], [TransactionDetailID])

VALUES (@p0, @p1, @p2, @p3, @p4)

SELECT CONVERT(BigInt,SCOPE_IDENTITY()) AS [value]

--?>

被block的session有幾十個，但是當前執行的語句都一樣：

<?query --

UPDATE dbo.HT

        SET IQuantity = IQuantity + 1,

            IRIQuantity = IQuantity + 1,

            QuotaFilledDate = CASE WHEN FilledDate IS NULL

                                        AND IssuedQuantity + 1 >= QuotaQuantity THEN dbo.udf_GetCurrentDateTime()

                                   ELSE QuotaDate

                              END

        FROM dbo.Hunt

        WHERE HID = @HID

--?>

鎖等待資訊如下：

<Lock resource_type="KEY" index_name="PK_Hunt" request_mode="U" request_status="WAIT" request_count="1" />

可以看出是主鍵爭用，初步分析是不同事務的同時更新相同的主鍵行造成的，開trace驗證

當前執行的雖然是insert語句，但是從whoisactive對於session持有的鎖分析得出，事務肯定是有其他對於Pk_hunt的key的爭用語句,單個事務的語句資訊果然包含對於pk_hunt表的更新儲存過程

可以看到確實是不同的transactionid同時更新相同的行造成的阻塞鏈

分析結果提交給測試人員，檢查配置並聯系開發人員進行修正。