SQL Server阻塞blocking案例分析

今天在性能测试过程中发现大量阻塞报警，检查whoisactive(https://github.com/amachanic/sp_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同时更新相同的行造成的阻塞链

分析结果提交给测试人员，检查配置并联系开发人员进行修正。