Прорыв блокировок на MS SQL через Управляемые

Недавно разбирали очень странную проблему…
На MS SQL фиксировалось огромное количество таймаутов, при том что конфигурация на управляемых блокировках и по идее таймауты если могут быть, то должны фиксироваться на уровне 1С с событием TTIMEOUT, а не EXCP

Пользователи сотни раз в час получали сообщение вида:

Конфликт блокировок при выполнении транзакции Microsoft SQL Server Native Client: Превышено время ожидания запроса на блокировку

При этом виновниками блокировок судя по анализу таймаутов на СУБД были совершенно безобидные запросы select…
Но по мимо них и update, и insert, и delete, да ещё и на разных таблицах…
Т.е. никакой системности, никакого одного подозреваемого и совершенно непонятное поведение СУБД.
Как будто мы работаем на автоматических, а не на управляемых блокировках…

Долго ломали голову с какой стороны подойти даже к анализу, не то что к решению проблемы, так как по ощущениям в системе не просто проблема, а «ушиб всей бабки»…

Запрос:
SELECT DB_NAME(tl.resource_database_id) AS database_name, tl.request_session_id, tl.request_mode AS lock_type,* FROM sys.dm_tran_locks tl WHERE DB_NAME(tl.resource_database_id) = 'erp' ORDER BY tl.request_session_id

Показывал очень странный вывод – в колонке resource_type была только запись OBJECT, что означает что виновник блокировки блокирует всю таблицу, а не конкретную запись/записи в ней

Если бы блокировались записи, то в колонке resource_type должна быть запись KEY.

Получается, что мало того что мы каким-то чудесным образом прорываемся сквозь управляемые блокировки, ещё и блокируем каждый раз таблицы целиком…

Но мы точно знаем – чудес не бывает!
На соседней базе, на этом же сервер СУБД выполняем запрос, который начинает транзакцию на чтение, внутри становится на паузу в 1С минуту, чтобы мы успели увидеть, что и как он блокирует
BEGIN TRANSACTION;
SELECT * FROM dbo._InfoRg178 T1 WITH (HOLDLOCK) WHERE T1._Fld80 = 'test'
WAITFOR DELAY '00:01:00';
COMMIT TRANSACTION;

И видим что СУБД совершенно корректно блокирует по KEY, т.е. конкретную запись в таблице.
Такой же запрос в проблемной базе, блокирует всю таблицу – OBJECT
Значит разница именно в какой настройке в базе, а не в сервере СУБД.

В итоге – нашли!

А именно: https://its.1c.ru/db/metod8dev/content/5837/hdoc
Важно! Начиная с версии платформы 8.3.22 необходимо выполнять дефрагментацию индексов по следующему алгоритму:
До дефрагментации индекса необходимо включить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON);
Выполнить дефрагментацию.
Обратно выключить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON);

При этом в плане обсуживания проблемной базы в самом последнем шаге устанавливается ALLOW_ROW_LOCKS = OFF
Что отключает у MS SQL возможность использовать индексы и SQL Server будет вынужден использовать только табличные блокировки

Вывод – читать документацию нужно очень внимательно, там всё написано верно, но так, что может и ввести в заблуждение)))
И проверьте свои планы обслуживания баз на MS SQL