База где редкие массовые перерегистрации 150 тыщ на 500 узлов вызывает негодование, собственник топает ножкой и выделяет ресурсы для того, чтоб такой кейс не вызывал таймауты у пользователей, вбивающих эти данные в режиме 24/7? :)

Ну я скорее про те в которых 150 тыщ записей это нормальная нагрузка за 15 минут.)

Если юзеры вбивают в таких объёмах, то эскалации просто не возникнет, так как table lock не пройдёт

Ну я вполне отдаю себе отчёт в том что большинство 1Сников никогда в жизни не будет даже рядом с этой проблемой проходить. Так что это не самая полезная в жизни информация

150 тыщ одного типа объекта, правильно понял?

Ну условно у тебя фактуровщики фигачат 150 тыщ реализаций в 15 минут.) Ну может не только фактуровщики, ещё и обмен с сайтом например чешет

Почему не пройдет? А какая там механика в СУБД при попытке заблокировать всю таблицу целиком? Что-то может воспрепятствовать такому намерению скуля?

Ну существующие блокировки других транзакций же

Lock escalation cannot occur if a different SPID is currently holding an incompatible table lock.

Тогда можно и не нарушать лиц. соглашение? Задача закрыта, вычеркиваем :)

))
а вот с средненагруженными может быть проблема, да
А как запрет эскалации на SQL нарушает лицензионное соглашение?

Рс вместо плана обмена это хорошо, а что делать с регистрацией изменений независимого рс?

Сериализовывать значения измерений из основного отбора.
Или держать в РС заготовочные составные "Измерение1", "Измерение2" ... "Измерение10" любого типа :)
Ну и третий вариант - отдельный РС под регистрацию для каждого своего обычного РС. Как таблицы регистрации изменений :)

Ну на моей памяти он еще узким местом не становился.
А вот справочники/документы - боль\

Интересно какая топология сети из 150 баз. Все через центр ходит?

Это боль, нужно регистрировать набор

Делали третий вариант когда выгружаемых регистров не много было, не универсально конечно и в режиме 1С предприятие новый не добавишь, но когда сущности все заранее определены и новые не планируется добавлять, то вполне себе проходной вариант, тем более повысишь параллельность размазав ещё сильнее по разным таблицам

А я правильно понимаю, что отсутствие атомарности в разрезе объектов нужно только для РИБ ? На сколько знаю например интеграция ДО реализована пообьектно без использования плана обмена

мне видится, что запрет эскалации не сыграет никакой роли, если регистрация выполняется на все узлы.

Док зарегился передзаписью, соседняя сессия стала на блокировке выгрузки изменений узла, заблокировала запись в таблицу изменений для узла и сообщения=NULL. Даже без эскалаций.
Текущий доказаписывается, проводится, все это неспешные 5-20 сек. Например, потому что дернулись взаиморасчеты крупной сети.
Все остальные доки благодаря выгрузке изменений сосут, если хотят зарегиться на этот узел. Хотя сама выгрузка могла бы за доли секунды проапдейтить сообщения.