Добрый день!
Коллеги, у меня вопрос. Может кто-то сталкивался...
Если создать план обмена и вообще все элементы на него назначить в регистрацию, то может ли он повесить базу?
Каждый день предположительно много данных будет через базу проходить.
Можно каждый день его чистить. Не будет ли проблем с производительностью базы?

Может. Будут.

Ещё 100 узлов в нём создай.

узел один будет

реально у кого-то проблемы были или это только предположение?

Был срыв промышленного старта одной системы.

а с чем связано, почему так, просто чтобы понимать

если был старт, то как на старте повесило - получается при старте план обмена пустой будет

(6) Связано с планом обмена. Включение объекта в план обмена — это ответственное действие. Если это регистр сведений и там неправильно расставлены флажки "основной отбор", то запись в регистр будет вызывать каскад записей в таблицу регистрации изменений.

(7) Сначала пустой, а потом быстро наполняется. И потом начинаются выгрузки и удаления. Это всё повесит базу.

https://www.youtube.com/watch?v=E6wy_UItkdw

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

(11) У вас теоретически "не должно", а я на обменах собаку съел.

поняла, спасибо коллега)

Посмотрела видео, я как раз так и хочу делать через запрос - как в видео вторым способом говорят.
Создать план обмена на него назначить все объекты. Потом что попало в регистрацию считываю запросом, записываю в xml файл и удаляю регистрацию по этому объекту.

(2) тоже мякотка :)

(14) накидал к видео комментов - как раз классическое ВыбратьИзменения используют чтобы записать номерсообщения и номерпринятого для квитирования обмена - второй способ не подойдет. Если квитирование не нужно то и второй план обмена не нужен - сразу удалять в рабочем плане.

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

Считывать записи из плана обмена буду запросом. Записи удаляться будут сразу из первого плана обмена как записала их в xml. При таком раскладе все норм будет или база повиснет?

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

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

(0) Банально просто мертвые узлы которые давно не нужны мешают работать. Ну не точно торомозит базу конечно.
Вот я в компании новой обнаружил кучу узлов и регистрация все шла и шла.  Удалил регистрации и удалил узлы сократил базу на 70 Гигов!
Удалил 635 млн регистраций!

(19) Инфа 100% ?

(21) Конечно же. Я вчера прям в скуле удалял эти таблицы.
В таблицах скуля если есть суффикс  в названии "Chng" это и есть таблица изименений объекта метаданных.
Пример
DocumentChngR6522
InfoRgChngR4431
ReferenceChngR6371
DocumentChngR3246
AccumRgChngR5472
DocumentChngR3204
ReferenceChngR6385
InfoRgChngR5121
InfoRgChngR6961
DocumentChngR3754
DocumentChngR1182
DocumentChngR7665
DocumentChngR2007
DocumentChngR1720
ReferenceChngR449
ReferenceChngR724

(19) >>автономная от других элементов плана обмена
нужно читать как "таблица автономная от других элементов метаданных". таблица изменений все-таки одна на объектМД, неважно в скольких планах он состоит, т.к. в таблице изменений есть колонка "узел"

(22) А... Мне показалось, что речь про узлы.

(21) Я своим замечание решил уточнить возможное недопонимание утверждения "Таблица изменений одна общая" - по моему мнению, это утверждение как-то двойственно звучит. И потому уточняю:

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

Источник: "Служба регистрации изменений" - https://v8.1c.ru/platforma/sluzhba-registratsii-izmeneniy/

НО: Aleksey в (18) прав, относительно множества планов обмена: каждая из таблиц регистрации изменений предназначена для всех(!) узлов.

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

1. Выборка = ПланыОбмена.ВыбратьИзменения(Узел, ОбУзел.НомерОтправленного);
2. ПланыОбмена.УдалитьРегистрациюИзменений(Узел, ОбУзел.НомерОтправленного);

Вроде и то и другое не должно долго отрабатывать.

(26) выбрать изменения устанавливает исключительную блокировку.
А другие в это время хотят писать

(27) Я потому и упомянул про раз в день. Ночью, например.

Коллеги, так в итоге если план обмена создать со всеми объектами и при обращении к нему НЕ использовать ПланыОбмена.ВыбратьИзменения, а использовать запрос, то база ляжет?

(29) извини, конечно, но это сильно на троллинг смахивает.

Ну используешь запрос, чтобы выбрать изменения из таблиц и...? Кроме этого запроса что-то дальше будет происходить или нет?
Тебе не для того, чтоб просто выборкой надо список измененных объектов выбрать и все, но и дальше их как-то обработать. Как будешь обрабатывать?

Начнешь обработку выполнять и либо положишь, либо не положишь - как напишешь, так и будет.

(29) Нет, не ляжет. У меня РИБ (полный состав объектов базы данных) используется много лет и ни разу ничего подобного не было нри с одной базой. Если хотите уменьшить этот теоретически потенциально конфликтный период - чаще проводите сеансы обмена данными. Чем меньше данных в сеансе обмена - тем быстрее он проходит и вероятность возникновения deadlock уменьшается.

И кстати: если используется ВыбратьИзменения() - это вовсе не означает блокировку всех объектов на всё время выборки изменений - таблицы регистрации будут поочередно обрабатываться (и поочередно блокироваться на запись).

Фрэнки, после запроса единственное что будет происходить что объект запишется в xml файл и все.

(29) Делай, все норм. Альтернатив не видно все равно.
Основные мысли в (26). Ну и в (31) тоже по делу.

(33) Читал давно (подробности не помню) в качестве альтернативы РС на который можно наложить управляемую блокировку

(16) Тоже накидал комментов к видео. В целом исповедую такой же подход к обмену через узлы - вызов ВыбратьИзменения по подготовленному запросом списку объектов с ограничением количества объектов каждого типа.

Serg_1960 а у Вас в регистрации все объекты? Я то всю базу, все объекты, все данные и все матаданные в базе собираюсь поставить в регистрацию

(36) Да все. Точнее, все те, которые могут участвовать в миграции данных. Дело в том, что в типовых конфигурациях есть объекты, которые не предназначены для миграции данных так, как они предназначены для содержания "локальных" данных узлов. Например, некоторые настройки не мигрируют по узлам (они у каждого узла свои собственные); элементы электронного документооборота автономны по узлам, каждый со своими настройками... Последовательностями документов, например, нет смысла обмениваться - он у каждого узла свой собственный...

*(37) Эээ... по поводу последовательности документов: там всё не так однозначно :)
"Особенности использования последовательности документов в распределенной информационной базе (РИБ)"
https://its.1c.ru/db/metod8dev/content/2270/hdoc

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

Нет, у меня значительно всё скромнее. Единственно только, когда месяц закрывают по УУ и БУ расчетами себестоимости (а у меня РАУЗ) или обработки обновления массово перезаполняют/перепроводят документы - вот тогда эти самые пресловутые "миллионы" :) и бывают.

(39) У меня есть РИБ ЦБ+ Управленка
Есть РИБ по Орг-ции там было порядка 23 так вот.
РИБ уже года 2 не юзают а узлы есть.
В итоге регистрации у меня были миллионы записей.
Я сначала удали регистрации  потом сам узлы базу с 686 ГБ сократил до 565 ГБ

Serg_1960 значит получается миллионы бывают и база из-за этого не тормозит

(42) Скажу так: тема блокировок во время выполнения ВыбратьИзменения() для пользователей базы неактуальна.