Уважаемые эксперты, нужна ваша подсказка. Конфигурация упп1.3 на упр.блокировках.
Наблюдаю событие эскалации блокировок до уровня таблицы при данном запросе:

DELETE FROM T1
FROM _AccumRg21611 T1
WHERE T1._RecorderTRef = P1 AND T1._RecorderRRef = @P2

Насколько я понимаю, совсем не обязательно блокировать всю таблицу для удаления движений по одному регистратору.

Аналогичные запросы еще встречаются, вот пример:

DELETE FROM T4
FROM _Document417_VT10391 T4
WHERE _Document417_IDRRef = P1

Вопрос: в чем может быть проблема?

блокировка на уровне скуля?

таблица слишком маленькая по объему - оптимизатору лень париться с записью

Спросить у пользователя P1 - не предлагать)

(1) Таблица _AccumRg21611 - самая большая в базе. 47млн записей и более 30 гигабайт на диске.

не попадает в индекс
слишком много блокировок - оптимизатор задалбался рулить блокировками

(4) индекс "Регистратор + НомерСтроки" всегда существует
про слишком много блокировок - это понятно, но не понятно, почему их много?

>индекс "Регистратор + НомерСтроки" всегда существует

а кто сказал что он всегда используется? вполне "безобидный" запрос может давать table/index scan

смотри план выполнения

(6) Эскалация блокировок может быть не связана с планом. Ну тоесть, у него может быть православный indexseek и блокирована вся таблица.

хуже от того что он посмотрит реальный план не станет. доп. информация не повредит

флаг трассировки 1224

ушел смотреть план

(3) При большом количестве записей в одной транзацкии - эскалируется.

(11) хорошо, например удаляются движения документа Требование-накладная (пускай из 1000 строк).

в итоге блокируем 47млн записей?

(0) эскалацией можно управлять

(12) Скуль сам считает блокировки, и то что 1к строк не значит что это 1к блокировок, есть некий range на котором происходит эскалация блокировок на уровне субд. Ещё есть блокировки по памяти.
Поставьте флаг трассировки 1224, не будет эскалации по количеству блокировок, есть ещё флаг отвечающий за эскалацию по памяти, но им баловаться не рекомендую.

(13)(14) Зачем баловаться флагами и пытаться управлять эскалацией? Я ведь не говорю, что скуль - дурачок и не нужно эскалировать блокировку. Однозначно эскалация - это добро. Иначе можно все ресурсы сервера положить на разруливание блокировок. А вот причина эскалации - это зло. Меня интересует - почему безобидная казалось бы операция по удалению движений одного документа приводит к блокировке таблицы в 30 гб.

(7)(8) Посмотрел план. Действительно - сканируется индекс по регистратору. В предикате: CONVERT_IMPLICIT(varchar(4),[database].[dbo].[_AccumRg21611].[_RecorderTRef] as [T1].[_RecorderTRef],0)='0x00000134' AND CONVERT_IMPLICIT(varchar(16),[database].[dbo].[_AccumRg21611].[_RecorderRRef] as [T1].[_RecorderRRef],0)='0x90160025904DA97E11E4D31107D43E91'

Что это? По этой информации можно понять, почему вместо поиска по индексу - сканирование?

(15) А P1 чему равен?

P1 - тип регистратора, ну допустим ТН.
Р2 - сама ссылка.

(17) да я в курсе. Значение его какое. чему он равен?

>По этой информации можно понять, почему вместо поиска по индексу - сканирование?

может статистика плохая

(18) вот в этом запросе выше видно, что = 0x00000134
(19) статистика обновляется еженочно с фулл сканом

(12) Ну наверное в данном случае SQL выгоднее заблокировать одну таблицу чем наложить 1000 блокировок.

вон у Гилева почитай: http://www.gilev.ru/escalation/

(19) есть вариант конечно, что нужно чаще обновлять.. например массовые перепроведения какие-то.

с какой-то версии скуля при обновлении 20 000 записей стата сама рефрешится по таблице

(24) с какой-то версии введен более интеллектуальный алгоритм определения порога автообновления.. с 2012 вроде. по % количеству от объема таблицы.

А тип параметров varbinary или varchar?

N'@P1 varbinary(4),@P2 varbinary(16)'
В запросе так параметры заданы?

(26) Это запрос, формируемый платформой при распроведении документа.

(@P1 varbinary(4),@P2 varbinary(16)) вот так