Может ли переключение уровня совместимости со 100 на 130 привести к проблемам с блокировкой или тупиком?

Question

В настоящее время мы тестируем переход на уровень совместимости (cl) 130 (вместо 100) в нашей среде разработки (sql server 2016).После переключения мы заметили некоторые ошибки:

could not execute batch command.[SQL: SQL not available] Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

После некоторых исследований, трассировки и отладки я смог подтвердить, что у нас действительно была проблема взаимоблокировки.Мы используем приложение .net, которое, используя nhibernate, получает доступ к базе данных.Некоторые внутренние задачи (в приложении .net) могут быть настроены на параллелизм для более быстрого завершения.Эти задачи обычно разделяют их рабочую нагрузку таким образом, что (строка) взаимоблокировка должна быть невозможной.Т.е. Задача 1 и Задача 2 могут обращаться к Таблице A и Таблице B примерно в одно и то же время, но они никогда не получат доступ к одним и тем же строкам в каждой таблице.

Задачи вызывают некоторые хранимые процедуры, которые делают что-то простое, например:

UPDATE dbo.Tab1
SET dbo.Tab1.Col1 = 'ValueY'
FROM dbo.Tab2
JOIN dbo.Tab3
JOIN dbo.Tab4
…
WHERE Tab1.Col.2 = 'ValueX'

По сути, это будет проходить через Tab1, искать строки для обновления и обновлять их.

Все это работало нормально на уровне совместимости (cl) 100. После перехода на cl 130 у нас иногда бывают тупики, с которыми мы раньше не сталкивались.

График взаимоблокировки показывает две блокировки ключа для одного и того же объекта id / hobt id, где два разных серверных процесса удерживают X-Lock и запрашивают U.

Если я добавляю нерелевантные строки вТаблица Tab1, для данного конкретного теста, увеличит количество страниц до 23, и проблем больше не будет.

Я прочитал, что эта проблема может быть вызвана небольшим количеством строк / страниц.Оптимизатор / сервер ведет себя по-другому по сравнению с таблицей с миллионами строк, что приводит к другому поведению блокировки и может привести к взаимоблокировкам.

Но это не отвечает на мой Вопрос : совместимость совместима?Уровень, при переключении со 100 на 130, напрямую влияет на блокировку и может даже вызывать проблемы взаимоблокировки, если их раньше не было?

PS: Это не проблема эскалации блокировки, так как я отключил ее для Таблицы Tab1.

Answer 1

Влияет ли уровень совместимости при переключении со 100 на 130 напрямую на блокировку и может даже вызвать проблемы взаимоблокировки, если их раньше не было?

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

Когда уровень совместимости базы данных изменяется на SQL 2014 или более поздний, по умолчанию используется новый оценщик количества элементов,Это может привести к другим планам выполнения, лучше или хуже, чем с устаревшим CE, используемым на более низком уровне совместимости.Может случиться так, что некоторые запросы страдают от регрессии плана.

Попробуйте использовать ALTER DATABASE SCOPED CONFIGURATION, чтобы использовать устаревший CE даже с более новым уровнем совместимости:

USE YourDatabase;
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION=ON;

Еслиэто ослабляет блокировку и взаимоблокировку, взгляните на планы запросов для возможностей настройки запросов и индексов.Нередко запросы, нуждающиеся в настройке, регрессируют после обновления.Кроме того, вы можете попробовать включить опцию QUERY_OPTIMIZER_HOTFIXES, которая по умолчанию отключена из-за предосторожности.

Если вы обнаружите лишь несколько случаев, когда требуется устаревшая версия CE, рассмотрите возможность добавления OPTION (USE HINT('FORCE_LEGACY_CARDINALITY_ESTIMATION')) подсказка запроса к этим запросам.Это позволит вам использовать последнюю версию CE по умолчанию.