дано:
windows server 2012r2
sql server 2012
1с 8.3.18.1830

данная связка с горем-пополам, да работала.
решили с нового года усечь базу - путем создания новой, оставив старую как архив.
заодно решил обновить ms sql на 2017 версию.

что мы в итоге имеем ? - массово начались жаловаться на то что в 1с теперь при проведении некоторых документов выходит ошибка:
конфликт блокировок при выполнении тразакции:
превышено время ожидания запроса на блокировку

Похоже еще что обновляли кроме скл

(0) Пригласите специалиста.
Причинами проблем может быть абсолютно всё что угодно.
Начиная с чего-нибудь банального типа того, что на новой СУБД не настроили стандартные регламенты (регулярное обновление статистики и перестроение индексов) или настройки выставили как-то коряво. И заканчивая некорректным усечением базы. А ещё быть может файлы новой базы разместили на медленном диске или просто так совпало и проблемы вызваны какими-то аппаратными сбоями (тормоза сети, умирание диска(ов) и т.п.).
Слишком мало исходной информации для локализации проблемы.

Регламентные задания SQL перенесли ?

Так это же упр блокировки

(2) да, конечно.. их сделал сразу после обновления

единственное, что мне самому в голову приходит, где я мог косячнуть - я удалил старый скуль, установил новый - а базы подключал через attach.. а потом в свойствах поменял совместимость базы на последнюю версию

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

mdop =1

(7) maxdop =1.. тоже сразу было сделано..

так то надо 2019 ставить

темпы скуля хоть где валяются хотя бы ?
в скуле, до того как в старой версии, флаги какие ручками ставили ?
Какие протоколы скуля щас стоят ? Скуль и сервер 1с на 1 машине ?

Для начала.
Проверить настройки СУБД. Проверить настройки сервера(ов), где стоит 1С и СУБД.
Проверить, что регламенты СУБД настроены корректно, действительно выполняются и выполняются корректно.
Посмотреть очереди к диску(ам).
Посмотреть размеры таблиц (нет ли каких-либо странных отклонений - например, какой-нибудь безумно большой таблицы итогов какого-либо регистра).
Сделать полное ТИИ базы с реструктуризацией, переиндексацией и пересчетом итогов.
Проверить периоды рассчитанных итогов по всем используемым регистрам.

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

(11) на стороне 1с сервера ничего не менялось особо...
регламентные задания пашут, настроены корректно.
очередей к дискам нет.. сервер в принципе не сильно загружен - 10-15% cpu и выделено 70гиг под скуль
по таблицам - пока они не такие большие... сама бд весит 8ГБ, самая большая таблица - 3гб

при таких базах по 8 и скулю 70...
шикарно живете! ))
у меня 38 баз и 70 коннектов ютятся на сервачке, на котором скулю 50 отдано ))))

(13) так старая база уже 300 весит, вместе с логом

Чудес не бывает.
При такой маленькой базе и при условии, что настройки СУБД и ОС хотя бы более или менее нормальные, блокировки не должны быть серьёзной проблемой.
Если только у вас не пытаются 10 менеджеров проводить одновременно огромные документы с одинаковой аналитикой.
Ну или кто-то без конца перезапускает перепроведение и/или восстановление последовательностей или какое-то отложенное проведение.

А что хоть ​за конфигурация?
Может где-то допиливали проведение и где-то случайно вкорячили принудительную запись движений по какому-либо из регистров в середине обработки проведения.
Или вообще накосячили в обработке проведения.

(15) конфигурация допиленная - транспортная логистика и экспедирование.
прикол в том, что до нового года (пока работали в старой базе и на старой субд) - ничего такого не было..
да, было конечно что проведение документа долго выполнялось... но вот сейчас - как срабатывает таймаут 20 секунд (родной таймаут конфы в 1с.. в обеих базах он одинаков) на выполнение запроса - так пользователи получают ошибку..

(0) Вот вам еще одна причина, не выполнять сразу все, а обновляться постепенно. Сейчас у вас нет понимания, то ли скуль новый с блокировками и планом запросов глючит, то ли вы коряво перенесли данные.

(0) Если есть возможность, протестируйте архивную базу на новом скуле, как она себя ведет. Либо новую базу на старом скуле.