Тупик в зависимых операторах множественного обновления

Question

В SP три таблицы обновляются в одной транзакции.Эти обновления зависят друг от друга.Но периодически происходит тупик во время этого обновления.Это происходит не последовательно, а скорее периодически.

Вызывается служба WCF, которая вызывает SP.Ввод SP является XML.XML анализируется с помощью метода OPENXML, а значения используются для обновления таблиц.

@ Table - табличная переменная, заполняемая OPENXML при применении входного XML SP.Входной XML содержит только один идентификатор.

<A>
  <Value>XYZ</Value>
  <ID>1</ID>
</A>

BEGIN TRAN
--update Table1  
Update Table1
Set ColumnA = A.value
JOIN @Table A
ON Table1.ID = A.ID

--update Table2    
Update Table2
Set ColumnA = Table1.ColumnA
JOIN Table1
ON Table1.ID = Table2.ID

--update Table3
Update Table3
Set ColumnA = Table1.ColumnA
JOIN Table1
ON Table1.ID = Table3.ID

COMMIT TRAN

В таблице 1 столбец идентификатора является первичным ключом.В таблице 2 в столбце идентификатора нет доступных индексов.

Здесь иногда возникает тупик при обновлении таблицы 2.

Получение сообщения об ошибке «Транзакция (идентификатор процесса 100) заблокирована для ресурсов блокировки с другим процессоми был выбран в качестве жертвы тупика. Перезапустите транзакцию. "

Требуется консультация по устранению этой периодически возникающей проблемы тупика.

Answer 1

Взаимные блокировки часто являются результатом того, что к ним обращаются больше данных, чем требуется запросам.Настройка запросов и индексов может помочь обеспечить доступ и блокировку только тех данных, которые необходимы запросам, уменьшая как блокировку, так и вероятность взаимных блокировок при одновременных сеансах.

Поскольку ваши запросы объединяются в ID без других критериев, индексв этом столбце может помочь избежать соприкосновения операторов UPDATE и DELETE с другими строками.Я вижу из ваших комментариев, что в столбце table2 ID не было индекса, поэтому было выполнено сканирование кластерного индекса.Мало того, что сканирование привело к неоптимальной производительности, оно может привести к блокировке и взаимной блокировке, когда параллельные сеансы конкурируют за одни и те же строки.

Добавление некластеризованного индекса в ID изменило план с полного кластеризованного индексасканирование для поиска не кластеризованного индекса.Это должно уменьшить, если не устранить, взаимные блокировки и значительно повысить производительность.Мне нравится говорить, что производительность и параллелизм идут рука об руку, особенно важная деталь в операторах модификации данных.