删除/插入时,对同一排他锁定的集群键(使用NHibernate)上的SQL死锁


29

我已经在这个僵局问题上研究了好几天了,无论我做什么,它都会以一种或多种方式持续存在。

首先,一般的前提是:我们具有与VisitItems具有一对多关系的Visits。

VisitItems相关信息:

CREATE TABLE [BAR].[VisitItems] (
    [Id]                INT             IDENTITY (1, 1) NOT NULL,
    [VisitType]         INT             NOT NULL,
    [FeeRateType]       INT             NOT NULL,
    [Amount]            DECIMAL (18, 2) NOT NULL,
    [GST]               DECIMAL (18, 2) NOT NULL,
    [Quantity]          INT             NOT NULL,
    [Total]             DECIMAL (18, 2) NOT NULL,
    [ServiceFeeType]    INT   NOT NULL,
    [ServiceText]       NVARCHAR (200)  NULL,
    [InvoicingProviderId] INT   NULL,
    [FeeItemId]        INT             NOT NULL,
    [VisitId]          INT             NULL,
    [IsDefault] BIT NOT NULL DEFAULT 0, 
    [SourceVisitItemId] INT NULL, 
    [OverrideCode] INT NOT NULL DEFAULT 0, 
    [InvoiceToCentre] BIT NOT NULL DEFAULT 0, 
    [IsSurchargeItem] BIT NOT NULL DEFAULT 0, 
    CONSTRAINT [PK_BAR.VisitItems] PRIMARY KEY CLUSTERED ([Id] ASC),
    CONSTRAINT [FK_BAR.VisitItems_BAR.FeeItems_FeeItem_Id] FOREIGN KEY ([FeeItemId]) REFERENCES [BAR].[FeeItems] ([Id]),
    CONSTRAINT [FK_BAR.VisitItems_BAR.Visits_Visit_Id] FOREIGN KEY ([VisitId]) REFERENCES [BAR].[Visits] ([Id]), 
    CONSTRAINT [FK_BAR.VisitItems_BAR.VisitTypes] FOREIGN KEY ([VisitType]) REFERENCES [BAR].[VisitTypes]([Id]), 
    CONSTRAINT [FK_BAR.VisitItems_BAR.FeeRateTypes] FOREIGN KEY ([FeeRateType]) REFERENCES [BAR].[FeeRateTypes]([Id]),
    CONSTRAINT [FK_BAR.VisitItems_CMN.Users_Id] FOREIGN KEY (InvoicingProviderId) REFERENCES [CMN].[Users] ([Id]),
    CONSTRAINT [FK_BAR.VisitItems_BAR.VisitItems_SourceVisitItem_Id] FOREIGN KEY ([SourceVisitItemId]) REFERENCES [BAR].[VisitItems]([Id]),
    CONSTRAINT [CK_SourceVisitItemId_Not_Equal_Id] CHECK ([SourceVisitItemId] <> [Id]),
    CONSTRAINT [FK_BAR.VisitItems_BAR.OverrideCodes] FOREIGN KEY ([OverrideCode]) REFERENCES [BAR].[OverrideCodes]([Id]),
    CONSTRAINT [FK_BAR.VisitItems_BAR.ServiceFeeTypes] FOREIGN KEY ([ServiceFeeType]) REFERENCES [BAR].[ServiceFeeTypes]([Id])
)

CREATE NONCLUSTERED INDEX [IX_FeeItem_Id]
    ON [BAR].[VisitItems]([FeeItemId] ASC)

CREATE NONCLUSTERED INDEX [IX_Visit_Id]
    ON [BAR].[VisitItems]([VisitId] ASC)

参观信息:

CREATE TABLE [BAR].[Visits] (
    [Id]                     INT            IDENTITY (1, 1) NOT NULL,
    [VisitType]              INT            NOT NULL,
    [DateOfService]          DATETIMEOFFSET  NOT NULL,
    [InvoiceAnnotation]      NVARCHAR(255)  NULL ,
    [PatientId]              INT            NOT NULL,
    [UserId]                 INT            NULL,
    [WorkAreaId]             INT            NOT NULL, 
    [DefaultItemOverride] BIT NOT NULL DEFAULT 0, 
    [DidNotWaitAdjustmentId] INT NULL, 
    [AppointmentId] INT NULL, 
    CONSTRAINT [PK_BAR.Visits] PRIMARY KEY CLUSTERED ([Id] ASC),
    CONSTRAINT [FK_BAR.Visits_CMN.Patients] FOREIGN KEY ([PatientId]) REFERENCES [CMN].[Patients] ([Id]) ON DELETE CASCADE,
    CONSTRAINT [FK_BAR.Visits_CMN.Users] FOREIGN KEY ([UserId]) REFERENCES [CMN].[Users] ([Id]),
    CONSTRAINT [FK_BAR.Visits_CMN.WorkAreas_WorkAreaId] FOREIGN KEY ([WorkAreaId]) REFERENCES [CMN].[WorkAreas] ([Id]), 
    CONSTRAINT [FK_BAR.Visits_BAR.VisitTypes] FOREIGN KEY ([VisitType]) REFERENCES [BAR].[VisitTypes]([Id]),
    CONSTRAINT [FK_BAR.Visits_BAR.Adjustments] FOREIGN KEY ([DidNotWaitAdjustmentId]) REFERENCES [BAR].[Adjustments]([Id]), 
);

CREATE NONCLUSTERED INDEX [IX_Visits_PatientId]
    ON [BAR].[Visits]([PatientId] ASC);

CREATE NONCLUSTERED INDEX [IX_Visits_UserId]
    ON [BAR].[Visits]([UserId] ASC);

CREATE NONCLUSTERED INDEX [IX_Visits_WorkAreaId]
    ON [BAR].[Visits]([WorkAreaId]);

多个用户希望通过以下方式同时更新VisitItems表:

单独的Web请求将使用VisitItems(通常为1)创建一个Visit。然后(问题请求):

  1. Web请求进入,打开NHibernate会话,启动NHibernate事务(使用READ_COMMITTED_SNAPSHOT上的重复读取)。
  2. 阅读VisitId所给定访问的所有访问项。
  3. 代码评估这些项目是否仍然相关,或者我们是否需要使用复杂的规则(运行时间太长,例如40毫秒)使用新的规则。
  4. 代码发现需要添加1个项目,使用NHibernate Visit.VisitItems.Add(..)将其添加
  5. 代码确定需要删除一项(不是我们刚刚添加的一项),然后使用NHibernate Visit.VisitItems.Remove(item)将其删除。
  6. 代码提交交易

我使用工具模拟了12个并发请求,这很可能在未来的生产环境中发生。

[编辑]根据要求,删除了我在此处添加的许多调查详细信息以使其简短。

经过大量研究,下一步是考虑一种方法,该方法如何将提示锁定在与where子句中使用的索引不同的索引(即主键,因为该键用于删除),因此我将lock语句更改为:

var items = (List<VisitItem>)_session.CreateSQLQuery(@"SELECT * FROM BAR.VisitItems WITH (XLOCK, INDEX([PK_BAR.VisitItems]))
        WHERE VisitId = :visitId")
        .AddEntity(typeof(VisitItem))
        .SetParameter("visitId", qi.Visit.Id)
        .List<VisitItem>();

这稍微减少了频率上的僵局,但仍在发生。这是我开始迷路的地方:

三个排他锁?

<deadlock-list>
  <deadlock victim="process3f71e64e8">
    <process-list>
      <process id="process3f71e64e8" taskpriority="0" logused="0" waitresource="KEY: 5:72057594071744512 (a5e1814e40ba)" waittime="3812" ownerId="8004520" transactionname="user_transaction" lasttranstarted="2015-12-14T10:24:58.010" XDES="0x3f7cb43b0" lockMode="X" schedulerid="1" kpid="15788" status="suspended" spid="63" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2015-12-14T10:24:58.013" lastbatchcompleted="2015-12-14T10:24:58.013" lastattention="1900-01-01T00:00:00.013" clientapp=".Net SqlClient Data Provider" hostname="ABC" hostpid="10016" loginname="bsapp" isolationlevel="repeatable read (3)" xactid="8004520" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
        <executionStack>
          <frame procname="adhoc" line="1" stmtstart="18" stmtend="254" sqlhandle="0x0200000024a9e43033ef90bb631938f939038627209baafb0000000000000000000000000000000000000000">
            unknown
          </frame>
          <frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
            unknown
          </frame>
        </executionStack>
        <inputbuf>
          (@p0 int)SELECT * FROM BAR.VisitItems WITH (XLOCK, INDEX([PK_BAR.VisitItems]))
          WHERE VisitId = @p0
        </inputbuf>
      </process>
      <process id="process4105af468" taskpriority="0" logused="1824" waitresource="KEY: 5:72057594071744512 (8194443284a0)" waittime="3792" ownerId="8004519" transactionname="user_transaction" lasttranstarted="2015-12-14T10:24:58.010" XDES="0x3f02ea3b0" lockMode="S" schedulerid="8" kpid="15116" status="suspended" spid="65" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2015-12-14T10:24:58.033" lastbatchcompleted="2015-12-14T10:24:58.033" lastattention="1900-01-01T00:00:00.033" clientapp=".Net SqlClient Data Provider" hostname="ABC" hostpid="10016" loginname="bsapp" isolationlevel="repeatable read (3)" xactid="8004519" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
        <executionStack>
          <frame procname="adhoc" line="1" stmtstart="18" stmtend="98" sqlhandle="0x0200000075abb0074bade5aa57b8357410941428df4d54130000000000000000000000000000000000000000">
            unknown
          </frame>
          <frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
            unknown
          </frame>
        </executionStack>
        <inputbuf>
          (@p0 int)DELETE FROM BAR.VisitItems WHERE Id = @p0
        </inputbuf>
      </process>
    </process-list>
    <resource-list>
      <keylock hobtid="72057594071744512" dbid="5" objectname="BAR.VisitItems" indexname="PK_BAR.VisitItems" id="lock449e27500" mode="X" associatedObjectId="72057594071744512">
        <owner-list>
          <owner id="process4105af468" mode="X"/>
        </owner-list>
        <waiter-list>
          <waiter id="process3f71e64e8" mode="X" requestType="wait"/>
        </waiter-list>
      </keylock>
      <keylock hobtid="72057594071744512" dbid="5" objectname="BAR.VisitItems" indexname="PK_BAR.VisitItems" id="lock46a525080" mode="X" associatedObjectId="72057594071744512">
        <owner-list>
          <owner id="process3f71e64e8" mode="X"/>
        </owner-list>
        <waiter-list>
          <waiter id="process4105af468" mode="S" requestType="wait"/>
        </waiter-list>
      </keylock>
    </resource-list>
  </deadlock>
</deadlock-list>

产生的查询数量跟踪如下所示。
[编辑]哇。好一个星期。现在,我用未完成的有关陈述的未完成的跟踪更新了跟踪,我认为这导致了僵局。

exec sp_executesql N'SELECT * FROM BAR.VisitItems WITH (XLOCK, INDEX([PK_BAR.VisitItems]))
                WHERE VisitId = @p0',N'@p0 int',@p0=3826
go
exec sp_executesql N'SELECT visititems0_.VisitId as VisitId1_, visititems0_.Id as Id1_, visititems0_.Id as Id37_0_, visititems0_.VisitType as VisitType37_0_, visititems0_.FeeItemId as FeeItemId37_0_, visititems0_.FeeRateType as FeeRateT4_37_0_, visititems0_.Amount as Amount37_0_, visititems0_.GST as GST37_0_, visititems0_.Quantity as Quantity37_0_, visititems0_.Total as Total37_0_, visititems0_.ServiceFeeType as ServiceF9_37_0_, visititems0_.ServiceText as Service10_37_0_, visititems0_.InvoiceToCentre as Invoice11_37_0_, visititems0_.IsDefault as IsDefault37_0_, visititems0_.OverrideCode as Overrid13_37_0_, visititems0_.IsSurchargeItem as IsSurch14_37_0_, visititems0_.VisitId as VisitId37_0_, visititems0_.InvoicingProviderId as Invoici16_37_0_, visititems0_.SourceVisitItemId as SourceV17_37_0_ FROM BAR.VisitItems visititems0_ WHERE visititems0_.VisitId=@p0',N'@p0 int',@p0=3826
go
exec sp_executesql N'INSERT INTO BAR.VisitItems (VisitType, FeeItemId, FeeRateType, Amount, GST, Quantity, Total, ServiceFeeType, ServiceText, InvoiceToCentre, IsDefault, OverrideCode, IsSurchargeItem, VisitId, InvoicingProviderId, SourceVisitItemId) VALUES (@p0, @p1, @p2, @p3, @p4, @p5, @p6, @p7, @p8, @p9, @p10, @p11, @p12, @p13, @p14, @p15); select SCOPE_IDENTITY()',N'@p0 int,@p1 int,@p2 int,@p3 decimal(28,5),@p4 decimal(28,5),@p5 int,@p6 decimal(28,5),@p7 int,@p8 nvarchar(4000),@p9 bit,@p10 bit,@p11 int,@p12 bit,@p13 int,@p14 int,@p15 int',@p0=1,@p1=452,@p2=1,@p3=0,@p4=0,@p5=1,@p6=0,@p7=1,@p8=NULL,@p9=0,@p10=1,@p11=0,@p12=0,@p13=3826,@p14=3535,@p15=NULL
go
exec sp_executesql N'UPDATE BAR.Visits SET VisitType = @p0, DateOfService = @p1, InvoiceAnnotation = @p2, DefaultItemOverride = @p3, AppointmentId = @p4, ReferralRequired = @p5, ReferralCarePlan = @p6, UserId = @p7, PatientId = @p8, WorkAreaId = @p9, DidNotWaitAdjustmentId = @p10, ReferralId = @p11 WHERE Id = @p12',N'@p0 int,@p1 datetimeoffset(7),@p2 nvarchar(4000),@p3 bit,@p4 int,@p5 bit,@p6 nvarchar(4000),@p7 int,@p8 int,@p9 int,@p10 int,@p11 int,@p12 int',@p0=1,@p1='2016-01-22 12:37:06.8915296 +08:00',@p2=NULL,@p3=0,@p4=NULL,@p5=0,@p6=NULL,@p7=3535,@p8=4246,@p9=2741,@p10=NULL,@p11=NULL,@p12=3826
go
exec sp_executesql N'DELETE FROM BAR.VisitItems WHERE Id = @p0',N'@p0 int',@p0=7919
go

现在,我的锁似乎已生效,因为它已显示在死锁图中。但是呢 三个互斥锁和一个共享锁?在同一个对象/键上如何工作?我以为只要拥有独占锁,就无法从别人那里获得共享锁?反之亦然。如果您拥有共享锁,则没有人可以获得独占锁,他们必须等待。

我认为我对锁在同一张桌子上的多个键上的工作方式缺乏更深入的了解。

以下是我尝试过的一些方法及其影响:

  • 在lock语句中在IX_Visit_Id上添加了另一个索引提示。没变
  • 在IX_Visit_Id(VisitItem列的ID)中添加了第二列;牵强附会,但还是尝试了。没变
  • 将隔离级别更改回读取已提交(我们项目中的默认设置),仍然发生死锁
  • 将隔离级别更改为可序列化。死锁仍在发生,但更糟(不同的图)。无论如何,我真的不想这么做。
  • 取得桌锁会使他们(显然)消失,但是谁愿意这么做呢?
  • 采取悲观的应用程序锁(使用sp_getapplock)是可行的,但这与表锁几乎是同一件事,不想这样做。
  • 将READPAST提示添加到XLOCK提示没有区别
  • 我已经关闭了索引和PK上的PageLock,没有区别
  • 我已经在XLOCK提示中添加了ROWLOCK提示,没有区别

关于NHibernate的一些补充说明:它的使用方式以及我的理解方式是,它会缓存sql语句,直到真正发现有必要执行它们为止,除非您调用flush,否则我们将尝试不这样做。因此,大多数语句(例如,懒惰加载的VisitItems => Visit.VisitItems的聚合列表)仅在必要时执行。提交事务后,我事务中的大多数实际更新和删除语句都会在提交时执行(从上面的sql跟踪中可以明显看出)。我真的无法控制执行顺序;NHibernate决定何时执行操作。我最初的锁定语句实际上只是一个变通方法。

另外,使用lock语句,我只是将项目读入未使用的列表中(我没有尝试覆盖Visit对象上的VisitItems列表,因为据我所知,这不是NHibernate应该如何工作的)。因此,即使我先使用custom语句阅读列表,NHibernate仍会使用单独的sql调用将列表再次加载到其代理对象集合Visit.VisitItems中,当需要将其延迟加载到某个地方时,我可以在跟踪中看到它。

但这没关系吧?我已经在所说的钥匙上锁了吗?再次加载不会改变吗?

最后一点,也许需要澄清一下:每个进程都首先添加带有VisitItems的自己的Visit,然后进入并对其进行修改(这将触发删除和插入以及死锁)。在我的测试中,从来没有任何过程可以更改完全相同的Visit或VisitItems。

有人对如何进一步解决这个问题有想法吗?我可以尝试以一种聪明的方式解决此问题(没有表锁等)吗?另外,我想学习为什么在同一对象上甚至可以使用tripple-x锁定。我不明白

请让我知道是否需要更多信息来解决这个难题。

[编辑] 我用涉及两个表的DDL更新了问题。

还要求我对期望进行澄清:是的,这里有一些僵局,没关系,我们将重试或让用户重新提交(通常来说)。但是按照目前有12个并发用户的频率,我希望最多每几个小时只有一个小时。目前,它们每分钟弹出多次。

除此之外,我还获得了有关trancount = 2的更多信息,这可能表明嵌套事务存在问题,而我们并未真正使用过。我也将对此进行调查,并在此处记录结果。


2
不要使用SELECT *。这可能是导致您的问题的一个因素。见stackoverflow.com/questions/3639861/...
JamieSee

另外,SELECT OBJECT_NAME(objectid, dbid) AS objectname, * FROM sys.dm_exec_sql_text(0x0200000024a9e43033ef90bb631938f939038627209baafb0000000000000000000000000000000000000000)在每个executionStack框架上运行sqlhandle,以进一步确定实际执行的内容。
JamieSee '16


大家好,恐怕我不再属于这个项目了:-/,所以我不能尝试您的建议。但是,我已将线程和所有信息转发给了一些团队成员,以便他们可以代替我进行研究。
2016年

您可以使用我的PowerShell脚本对此问题进行解答,以获得更多可能对您有所帮助的死锁详细信息。具体来说,它将检索“未知”堆栈帧的SQL语句信息。dba.stackexchange.com/questions/28996/...
JamieSee

Answers:


2

我对此发表了一些评论,但是当您将“可重复读取”事务隔离级别与“读取已提交快照”结合使用时,我不确定您是否会获得理想的结果。

死锁列表中报告的TIL是可重复读取,它比“读取已提交”更具限制性,并且鉴于您描述的流程,很可能导致死锁。

您可能想要做的是使您的数据库TIL保持可重复读取,但是将事务设置为通过设置的事务隔离级别语句显式使用快照TI​​L。参考:https : //msdn.microsoft.com/zh-cn/library/ms173763.aspx 如果是这样,我认为您一定有不正确的地方。我对nHibernate并不熟悉,但似乎这里有一个参考:http : //www.anujvarma.com/fluent-nhibernate-setting-database-transaction-isolation-level/

如果您的应用程序的体系结构允许,则可以选择尝试在数据库级别读取已提交的快照,如果仍然遇到死锁,请启用带有行版本控制的快照。请注意,如果执行此操作,则在启用快照(行版本控制)后,您需要重新考虑您的tempdb设置。如果您需要,我可以为您提供各种各样的材料-让我知道。


2

我有几点想法。首先,避免死锁的最简单方法是始终以相同的顺序进行锁定。这意味着使用显式事务的不同代码应以相同的顺序访问对象,但显式事务中按键分别访问行也应在该键上进行排序。Visit.VisitItems在执行此操作之前,请尝试按其PK进行排序,Add或者Delete除非这是一个巨大的集合,否则我将对其进行排序SELECT

不过排序可能不是您的问题。我猜想有2个线程在VisitItemID给定的所有s 上抓住共享锁VisitID,线程A DELETE直到线程B释放它的共享锁才完成,直到线程B释放它才DELETE完成。应用程序锁将在这里工作,并且没有表锁那么糟糕,因为它们仅按方法阻塞,而其他SELECTs可以正常工作。您也可以Visit在给定的表上使用排他锁,VisitID但同样,这可能会导致过度杀伤力。

我建议将您的硬删除变成软删除(UPDATE ... SET IsDeleted = 1而不是使用DELETE),并在以后使用一些不使用显式事务的清理作业来批量清理这些记录。显然,这将需要重构其他代码以忽略这些已删除的行,但这是我首选的用于处理显式事务中DELETE包含的的方法SELECT

您也可以SELECT从事务中删除并切换到开放式并发模型。实体框架是免费的,不确定NHibernate。如果DELETE返回的0行受到影响,EF将引发乐观并发异常。


1

在对visitItems进行任何修改之前,您是否尝试过移动“访问”更新?该X锁应保护“子”行。

完全锁定获取的跟踪记录(并将其转换为人类可读的记录)是很多工作,但可能会更清楚地显示序列。



-1

READ COMMITTED SNAPSHOT ON表示在READ COMMITTED ISOLATION LEVEL中运行的每个事务都将充当READ COMMITTED SNAPSHOT。

这意味着读者不会阻止作家,作家也不会阻止读者。

您使用可重复的读取事务隔离级别,这就是为什么出现死锁的原因。Read Committed(无快照)将行/页面上的锁保持到语句结尾,而Repeatable Read则将这些锁保持到事务结尾。

如果您查看死锁图,您会看到获得了“ S”锁。我认为这是第二点的锁定->“通过VisitId读取给定访问的所有访问项。”

  1. 将您的NHibernate连接事务隔离级别更改为“已提交读”
  2. 您需要分析第二点的查询,并了解如果在visitID列上有索引的原因,为什么它会在PK上获得锁(这可能是因为索引中缺少包含的列)。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.