База на SQL сервере , стоят РЕСПОСы для торговой сети. Где то с середины лета начались конфликты блокирововок. Может подскажите в какую сторону рыть?

sql.ru

Ну анализируй ожидания на блокировках. Какими запросами образуется и почему.

Ну или Технологический Журнал настрой, может помочь.
На ИТС есть подробное описание настройки и принципа работы.

оперативно:
С помощью консоли кластера серверов. Показывает Кто кого заблокировал, длительность блокировки, гранулярность.

С помощью монитора активности. Показывает кто кого заблокировал (id сеансов),какой ресурс ,если конфигурация в автоматическом режиме, то можно увидеть и текст запроса на языке SQL, гранулярность, режим(тип блокировки).
И неоперативно

SQL profiler. С помощью фильтра lock acquired> 1мс; (ресурс, длительность, режим,гранулярность,  id кого забокировали.

https://fex.net/411658612621
Вот скриншот. Если есть мысли , подскажите.

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

последовательность партионного учета подтягиваете?

последовательность не подтягиваем.
Статистику обновить. Это где.?

(8) Именно поэтому и проблемы с запросом к регистру партий.
Статистика обновляется в SQL.

(5) На картинке дедлок у вас, а не ожидания на блокировке

восстановить последовательность?

что такое дедлок

(12) штука неприятная и непростая в диагностике, погуглите, теорию писать не буду здесь

причем дедлок возникает в СУБД судя по описанию ошибки

в базе ? Могут быть это злонамеренные действия. В теории я это допускаю. Какие то изменения могли быть произведены.

потому что работала раньше нормально.

(15) Это 100% злонамеренные действия. Не обновлять статистику - это чистое зло со стороны адимнистратора БД )))

(16) если спеца по этой теме у вас нет, попробуйте самое простое - обновлять статистику и чистить процедурный кэш на SQL

статистика обновляется и процедурный кеш чистится. я спросил у нашего адимина. Каждую ночь.

ДАА! Только что уточнили. Не обновляется статистика и не чистится кеш. Попробуем. это делать. Поможет не поможет, посмотрим. Спасибо!

Если можно описать процедуру очистку процедурного кеша. это как и где.

DBCC FREEPROCCACHE
http://www.gilev.ru/forum/viewtopic.php?f=17&t=358
Вот зачем мне эти знания? У вас же админ есть.

цитата с ИТС:
Статистика может обновляться настолько часто, насколько это необходимо.
Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем.
В реально работающей системе разные таблицы требуют различной частоты обновления статистик. Путем анализа планов запроса можно установить, какие таблицы больше других нуждаются в частом обновлении статистик, и настроить две (или более) различных регламентных процедуры: для часто обновляемых таблиц и для всех остальных таблиц.

Спасибо всем. Будем пробовать.

(24) у вас ничего не получится

почему

https://ausevich.ru/ekspert/blokirovka-indeksa-na-urovne-stranits-prakticheskoe-rassledovanie-vzaimoblokirovki/

тоже в сетевой рознице как-то столкнулись с резким замедлением и блокировками sql в какой-то момент.
Уже не вспомню, помогал ли рестарт sql.
Реально помогало dbcc opentran - как правило "start time" не должно быть больше 3 минут и kill[[id процесса].
А вообще в этой статье описано подробно http://catalog.mista.ru/public/277252/.

Взаимоблокировка разруливается как 2 пальца.
Но см (25).

я посмотрел код напичкан НачатьТранзакцию() везде.
Как же разрулить взаимоблокировку.

(30) Например, ускорить выполнение запросов за счет обновления статистики.

это будет делаться каждый день. Я посмотрел - стоит режим блокировки - управляемый. на конфе

(32) Управляемые, на то и управляемые, что их ставить самому надо. У тебя один путь - найти и устранить по предложенной методике или (25).  
Возможно(не имея никаких фактов, пальцем в небо), при переводе конфы с автоматических блокировок в партионном учете забыли БлокироватьДляИзменения = Истина.

В модуле ОбщийМодуль.УправлениеЗапасамиПартионныйУчет ,
Который вызывает блокировки, действительно нет ни одной записи БлокироватьДляИзменения = Истина.
Да и вообще во всей конфе нет.
Я подозреваю, что база была ранее файловая, где это не нужно было. Теперь скл

при том что регистри накопления например партии товаров имеют разрешить разделение итогов = истина.

(34) (35)
Вот они фактики:
1. Нет БлокироватьДляИзменения
2. Есть разделение итогов

Еще раз...это, чтобы гарантировано понять в чем проблема
https://ausevich.ru/ekspert/blokirovka-indeksa-na-urovne-stranits-prakticheskoe-rassledovanie-vzaimoblokirovki/

А это, чтобы проверить/исправить, то что понаписано в конфе
https://its.1c.ru/db/metod8dev#content:5839:hdoc

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

(37)
Точно придется комментировать Новый БлокировкаДанных

(5) конфа нетиповая?

дидлок - следствие разного порядка захвата ресурсов. Измените порядок захвата ресурсов - чаще всего этого уже хватает.

(37) не забудь сделать бэкап - к нему откатываться придется