Чи можуть зовнішні ключі спричинити тупики та перешкоджати ЧИТАТИ ЗВ'ЯЗАНО ЗНАЧЕНО?

Це додаткове запитання від /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically

У мене все ще виникають ситуації в глухому куті / тайм-ауті в додатку ASP.NET, коли одночасно запускаються великі звіти READ_COMMITTED_SNAPSHOT ON.

Тож у мене є два питання:

1. Як я можу перевірити, чи працює знімок рівня ізоляції транзакцій, як очікувалося / взагалі?
2. Я припускаю, що зовнішні ключі (у таблицях веб-додатка до таблиць звітів) відповідають за тупикові місця. Я знайшов цю цікаву статтю :

Примітка. SQL Server отримує спільні блокування під час перевірки зовнішніх ключів, навіть якщо транзакція використовує зроблений знімок зчитування (читання здійснено за допомогою версії версій) або рівень ізоляції знімків. Пам’ятайте про це, вивчаючи графіки тупикових ситуацій від транзакцій, коли використовуються ці рівні ізоляції транзакцій. Якщо ви бачите загальні блокування, перевірте, чи зроблені блоки на об'єкт, на який посилається зовнішній ключ.

Як я можу перевірити, чи дійсно ФК відповідає за ситуацію з тупиком / тайм-аутом, чи це означає, що я міг би видалити ці зовнішні ключі, щоб запобігти тупік (що було б прийнятним зусиллям)?

Примітка . Я читаю лише з таблиць, які призводять до тупиків.

Будь-які думки на цю тему дуже вдячні.

Редагувати ось графік тупику . Можливо, хтось міг би допомогти мені зрозуміти, що викликає тупик. Здається, що це сталося без будь-яких звітів, запущених лише через веб-додаток, коли дві транзакції хочуть написати одну і ту ж таблицю (одне оновлення та одна вставка; вставка є як Stored-Procedure). Чому він набуває блокування сторінок і як увімкнути лише блокування рядків? 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-Куб (Molap).

Редагувати : До речі, більше не було тупиків, оскільки я видалив ці тригери :)

Якщо команда SQLCAT каже, що перевірка FK проводиться за допомогою ізоляції, що читається, вони повинні знати, про що вони говорять. Акцент на валідацію . Справжнє питання: Чому звіт викликає перевірку FK ? Перевірка відбувається під час запису , і звіти повинні бути прочитані . Або ваші звіти викликають записи, і в цьому випадку рівень ізоляції знімків нічого не допоможе, або причина тупикової ситуації є іншою.

Єдиний спосіб досягти прогресу - це зафіксувати графік тупикової ситуації.

Щодо іншого питання, як ви можете перевірити, чи працюєте ви в ізоляції знімків: дивіться sys.dm_tran_active_snapshot_database_transactions.

Перевірка зовнішнього ключа має відбуватися під (замок) читати вчинені на правильність. Дивіться ізоляцію знімків: загроза цілісності? Хуго Корнеліс для деталей.

Графік глухого кута показує два одночасні виконання RM2.dbo.RMAпричини спричинення тупикової ситуації. У ваших тригерах відсутня умова з'єднання між RMAі inserted.

Мабуть, ймовірно, що це нагляд, і ваш тригер випадково оновлює всі рядки в RMAтаких тупикових ситуаціях, вкрай вірогідні випадки, якщо буде більше ніж одночасне виконання тригера.