Это дополнительный вопрос от: /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatics
У меня все еще возникают ситуации блокировки / тайм-аута в приложении ASP.NET при одновременном запуске больших отчетов READ_COMMITTED_SNAPSHOT ON.
Итак, у меня есть два вопроса:
- Как я могу проверить, работает ли моментальный снимок уровня изоляции транзакции как ожидалось / вообще?
- Я предполагаю, что внешние ключи (в таблицах веб-приложения к таблицам отчетов) отвечают за взаимоблокировки. Я нашел эту интересную статью :
Примечание. SQL Server получает общие блокировки при проверке внешних ключей, даже если в транзакции используется моментальный снимок с фиксацией чтения (подтверждение с фиксацией строк) или уровень изоляции моментального снимка. Помните об этом при изучении графиков взаимоблокировок из транзакций, когда используются эти уровни изоляции транзакций. Если вы видите общие блокировки, проверьте, приняты ли блокировки для объекта, на который ссылается внешний ключ.
Как я могу проверить, действительно ли FK отвечает за ситуации тупиковой ситуации / тайм-аута, означает ли это, что я могу удалить эти внешние ключи, чтобы предотвратить взаимные блокировки (что было бы приемлемым усилием)?
Примечание : я читаю только из таблиц, которые вызывают тупики.
Любые мысли на эту тему с благодарностью.
Редактировать Вот тупиковый график . Может быть, кто-нибудь может помочь мне понять, что вызывает тупик. Похоже, что это происходило без запуска каких-либо отчетов, вызванных только веб-приложением, когда две транзакции хотят записать одну и ту же таблицу (одно обновление и одна вставка, вставка как хранимая процедура). Почему он блокирует страницы и как включить только блокировки строк? Insert-SP использует уже TRANSACTION ISOLATION LEVEL REPEATABLE READ.
У меня есть сильное подозрение, что два триггера (одно обновление и одна вставка) отвечают за взаимоблокировки. Вот триггер вставки:
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, 112) = tdefDate.Text),
[fiManufactureDate]=(SELECT idDate FROM tdefDate
WHERE CONVERT(VARCHAR, INSERTED.Manufacture_Date, 112) = tdefDate.Text)
FROM INSERTED;
ENDТаким образом, этот триггер обновляет таблицу RMA, что вызывает срабатывание триггера обновления (что делает подобное). График взаимоблокировки подтверждает мое предположение? Я думаю, что удаляю эти триггеры и создаю SP, который запускается раз в день, что будет вполне достаточно, потому что эти столбцы предназначены только для SSAS-Cube (Molap).
Редактировать : Кстати, тупика больше не было, так как я удалил эти триггеры :)