虽然READ_COMMITTED_SNAPSHOT ON,但在同时运行大型报表时,我仍然在ASP.NET应用程序中出现死锁/超时情况.

所以我有两个问题：

>我如何检查Transaction Isolation Level Snapshot是否按预期工作？
>我假设外键(在Web-Application表中的报表)负责死锁.我找到了this interesting article：

Note sql Server acquires shared locks when validating foreign keys,
even if the transaction is using read committed snapshot (read
committed using row versioning) or snapshot isolation level. Be
mindful of this when examining deadlock graphs from transactions when
these transaction isolation levels are used. If you see shared locks,
check to see whether the locks are taken on an object that is
referenced by a foreign key.

我如何检查FK是否真的对死锁/超时情况负责,这是否意味着我可以删除这些外键以防止死锁(什么是可接受的努力)？

注意：我只是从导致死锁的表中读取.

对此主题的任何想法都非常感谢.

编辑Here is a Deadlock-Graph.也许有人可以帮我理解导致死锁的原因.似乎它发生时没有任何报告只由web应用程序引起,当两个事务想要写同一个表时(一个更新和一个插入,插入是存储过程).为什么它只获取页锁以及如何仅启用行锁？ Insert-SP使用TRANSACTION ISOLATION LEVEL REPEATABLE READ.

我强烈怀疑两个触发器(一个更新和一个插入)是造成死锁的原因.这是insert-trigger：

CREATE TRIGGER [dbo].[CreateRMAFiDates] 
   ON  [dbo].[RMA] 
   AFTER INSERT
AS 
BEGIN
    SET NOCOUNT ON;

    UPDATE RMA 
    SET [fiCreationDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR,INSERTED.Creation_Date,112) = tdefDate.Text),[fiPopDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR,INSERTED.POP_Date,[fiManufactureDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR,INSERTED.Manufacture_Date,112) = tdefDate.Text)
    FROM INSERTED;
END

因此,此触发器更新RMA-Table导致更新触发器触发的原因(类似).死锁图是否证实了我的假设？我想我会删除那些触发器并创建一个每天运行一次的SP,这是完全足够的,因为这些列仅适用于SSAS-Cube(Molap).

编辑：顺便说一句,因为我删除了这些触发器,所以没有死锁:)