sql сервер, как долго SELECT ожидает до тупика

Question

Я выполняю тест параллелизма на sql сервере 2019, у меня есть инструмент SQLTest, который выполняет параллельные запросы, в моем тесте я использую один единственный запрос SELECT (звездообразная схема), а в SSMS у меня при l oop, что обновляет записи таблицы фактов. при выполнении обоих процессов я вижу, что некоторые потоки / запросы отменены из-за взаимоблокировки, что ожидается, но вариант, который я ищу, или есть ли возможность добавить время ожидания для моего выбора перед взаимоблокировкой? другими словами, сколько времени сервер SQL ожидает, прежде чем он создаст ошибку взаимоблокировки.

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

любые предложения или мысли

Answer 1

есть ли возможность добавить время ожидания на мой выбор до тупика?

Нет. Это не имеет никакого смысла.

Дедлок определяется как тупик блокировки, который ни при каких обстоятельствах не будет исправлен простым ожиданием. Одна из сторон должна отменить.

Т.е. Tx1 имеет блокировку для таблицы a, ожидает блокировки для таблицы b Tx2 имеет блокировку для таблицы b, waitf для блокировки для таблицы a

Обычно SQL Сервер ждет (тайм-аут) и отменяет. В этом случае обнаруживается взаимоблокировка и понимает, что нет, если только одна сторона не выброшена, это никак не может быть решено, поэтому она отменяет одну сторону. Там нет ожидания, потому что это на самом деле программная ошибка. Без шуток.

Там, Tx2 должен сначала запросить блокировку на столе a. Хорошей практикой является блокировка транзакции в определенном порядке, чтобы этого не произошло.

Answer 2

Я бы посоветовал немного изменить стратегию тестирования.

В вашем тестовом комплекте я бы SET DEADLOCK_PRIORITY LOW;, чтобы при обнаружении тупика процесс тестирования добровольно принимал один для команды, позволяет себе стать жертвой тупика и позволяет конфликтующему процессу продолжаться.

Затем оберните сценарий тестирования в TRY...CATCH. В предложении CATCH проверьте, не является ли причиной ошибки тупик (код ошибки 1205), и, если это так, повторите тест. Вероятно, это хорошая идея - встроить в нее инкрементный счетчик, чтобы вы не оказались в бесконечном тупике l oop.