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

Для начала - на все вопросы, где есть "ДЛЯ ИЗМЕНЕНИЯ"

*запросы

(1) нет таких..

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

(0) у Евгения Гилева на эту тему было видео... как-бы вроде делал так: ставил в свойствах корневого узла про блокировки = упр+авт и далее переводил пообъектно... когда перевёл всё - установил в упр. Постепенно перевёл

(5) так и сделаем.

(6) Не надо вам "упр+авто". Граблей будет - море!

(0) Сводная база - центральная в РИБ ? Или конфигурация отличается? Если второе и нет нужны в контроле остатков, нет вычисления себестоимости - ставьте управляемый режим и не парьтесь.

(0) какого эффекта ожидаете от перевода?

(8) чмок! боязно!

(9) хотим:
1. отсутствие избыточных блокировок. сейчас невозможно одновременно писать непересекающиеся данные с отбором по неполному ключу.
2. возможность "грязного" чтения. эта ситуация не отрабатывается и не планируется, совсем ничего не читаем запросом с директивой "ДЛЯ ИЗМЕНЕНИЯ"

(11)
1. а прототип прогоняли? получается такая запись с упр блокировками?
2. а сейчас что мешает грязное чтение делать?

(12)
1. прогоняли на стенде с мониторингом таблицы locks СКУЛя и блокировок сервера 1С
2. типа платформа не даст (??)

(13) не ну могут быть блокировки избыточные, почему нет

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

единственное место где нужно руками блоировки прописывать это там где на основании остатков формируются движения
а ля расчет себестоимости или партии

следует ожидать роста нагрузки на сервер 1С?

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

(17) вполне возможно, если у вас интенсивная запись, особенно если массивные наборы данных

(18) Неправ.
при авт блок простое чтение в транзакции накладывает в скуле блокировки на ЗАПИСЬ.

(0) Автор, просто сделай и не парься.
Можно еще впилить РазделениеИтогов, раз у вас нет контроля остатков, это прям отлично зайдет.
Ну и флаг -t1211, если пишите больше 5000 строк в таблицы.
Ну и обережно работать с наборами записей РС, в некоторых случаях их придется заменить на МенеджерыЗаписей.

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

(20) что значит на запись? я имел ввиду разделяемые блокировки

(21) зачем ты нагружаешь автора советами не относящимися к переходу на упр блокировки?
у него и так риски перехода

(24) Хочу и нагружаю.

(25) в народе это называется мутить воду

(26) Мы не в народе.

(23) Разделяемые блокировки совместимы, поэтому чтение в одной транзакции не заблокирует чтение в другой транзакции. Другое дело, что в типовой конфе, при проведении ты такого не встретишь, так как это путь к deadlock-у и вначале будет Чтение с ключом ДляИзменения, которое вместо разделяемой блокировки наложит эксклюзивную.

(21) c t1211 надо быть предельно аккуратным, т.к. вместо эскалации получаем резкий регресс по производительности. Плавали

(29) Хотелось бы подробностей, так как плаваем и регресса нет.

так и плавали, решали проблему параллельного начисления ЗП на доками, где в  каждом было больше 10к сотров, искали путь, чтобы было оптимально. Если была включена эскалация на субд, то проводилось все параллельно, но пару часов. Если эскалация была по дефолту, то возможны были дедлоки, но проводилось около 20 минут.

*если была вЫключена эскалация на субд, то проводилось все параллельно, но пару часов

(31) Ну так в чем затык то был? Когда пара часов - поймать топ медленных или спам мелкими - вполне реально.

(34) Затык в записи в таблицу, там их несколько вроде было. Блокировки же нет общей на таблицу - вот и расплата скоростью.

(20) верно!

(0) какая цель перевода на управляемые блокировки? Что в текущем режиме не устраивает?

(28) согласен, я неудачно назвал ее блокировкой на чтение, далее я поправился - разделяемая блокировка
это подтверждает мои слова в (18), что поведение чтения в транзакции изменится

(27) не в народе, но воду ты зачем то мутишь) непонятно зачем

(37) выше я уже спрашивал