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同时更新相同的行造成的阻塞链

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注