Есть задача организации двухуровнего РИБа.
Количество баз исчисляется сотнями, но количество документов, в принципе, небольшое. Вентилируя эту тему, иногда встречаю способ организации с двумя планами обмена:
1. РИБ для передачи только конфигурации
2. Не РИБ для обмена данными

Коллеги, поделитесь, кто использует подобное?
В каких случаях интересна подобная методика?

(65) Надежность. Загрузка конфигурации произойдет всегда, даже если какие-то реквизиты или объекты для периферии сильно изменятся. Не приходилось наступать на грабли, что обмен по рИБ не проходит из-за каких-то не вполне объяснимых причин, точнее, из-за измененной конфигурации?

(66) Какие именно причины?

(67) если программист не вполне аккуратно курочит объекты конфигурации, то тогда она (перекуроченная неудачным образом) через риб в узлы перифериек не проходит с классическим сообщением об ошибке: "Конфигурация узла не соответствует ожидаемой". И все приходится перезапускать по методе из (61)

(0) сабж нужен как раз для двухуровневой структуры баз. При этом по "риб" логично не только конфу гонять, но и НСИ, общие для всей сети.

(62) "вырузить конфигурацию ЦБ / отвязать узел / загрузить конфигурацию в ПУ / привязать узел" - это общеизвестная альтернатива штатному обновлению конфигурации подчиненного узла. Иногда обновление конфигурации на ПУ глючит, сваливается по ошибке и тогда, кроме как альтернативы ничего из штатных возможностей платформы не помогает.

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

(67) Погугли, например, ошибку "Конфигурация узла распределенной ИБ не соответствует ожидаемой" или "демоническое обновление". Иногда бывает так, что загрузка конфигурации - единственный способ решить проблему.

(69) а по второму плану обмена?

(72) а что по второму? НСИ идут от центра на периферию по РИБ, а оперативные данные, которые массово идут от периферии к центру - по плане НЕриб (как он там у тебя в топике назван :) )

(73) и для чего тогда два плана?

(74) например, мне? в том варианте, с которым я работал недавно? или у тебя в твоем проекте?

(75) ну ты отвечаешь на (69)(72), мне интересны именно детали реализации

(74) чтобы можно было крутить данные как того требуется бизнес на предельных скоростях платформы.

(74) Дык понятно же для чего. По т.н. "не РИБ" данные сливаются в центр независимо от обновлений конфы, можно это делать часто, ограничив обмен первичкой и т.д. Второй план - для еженедельного обновления конфы, ну и ночной выгрузки НСИ в периферию.

(0) как может "РИБ" иметь "неРИБ"???
Можно мозг сломать.
Подправьте тему кто может...

У меня получилось так.
Есть некоторая значимая часть НСИ - их относительно не много, но они критичны для нормального запуска сеансов пользователей и последующих обменов. Тем более, что у меня предусмотрен вариант многоуровневого погружения, скажем так. Я наличие таких НСИ связал с РИБ и идет их трансляция только от центра у узлам.

А есть еще планы обмена, связанные с произвольно создаваемыми узлами в них. Т.е. внутри объектов узел в ТЧ прописаны соотв разделители. Все данные от узлов для центра регаются только под этими планами. И можно создать самые причудливые вариации, например: это подразделение и вот это выгружу и еще одно - по узлу А1, а вот это только одно подразделение - по узлу Б12. Ну в ответку могут, на практике, идти корректировки всех данных из центральной базы, если такая необходимость возникает. Вообще, т.к. в обратную сторону поток данных существенно меньше, возвращаются исправления без особых проблем.

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

И между прочим, в самых последних новациях по практическому использованию КД 3 можно увидеть ровно такой же методический подход.

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

(80) я убираю все с плана обмена РИБ (который овечтает из отправку изменений конфигурации) и реализовываю обмен НСИ или другими критическими для бизнеса объектами через второй план обмена с классической сериализацией (или можно уже через json). При таком подходе  можно реализовывать безумную логику, которая классическому РИБу и не снилась никогда.
примеры:
- конфигурация изменена, но нужно срочно прогрузить изменения цен, добавление новых элементов справочников.
- работа с веб\http сервисы c пообъектной выгрузкой
- реализация сложной выгрузки\загрузки цепочки объектов как одного целого.
- отказ от добавления в план обмена регистров подчиненных регистратору и при этом частичная выгрузка.
- и тд, там можно бесконечно перечислять
.
PS ну и классика, решение проблем с блокировками при обменах.

(82) > отказ от добавления в план обмена регистров подчиненных регистратору и при этом частичная выгрузка
Какую здесь роль играет наличие двух планов обмена, а не одного?

(83) в классическом РИБе нужно регистрировать изменения не только документа, но и его движения для обмена. Соответственно будет дольше блокировка при начале обмена и сложно сделать исключение из обмена определенных движений для определенных узлов. При двух планах обмена можно вообще не добавлять регистры в состав второго плана.

(84) > При двух планах обмена можно вообще не добавлять регистры в состав второго плана.
...и выгружать их своим кодом вслед за документом?

(85) Документ проводить при загрузке, например.

(74) например, чтобы обновление конфигурации не зависело от данных. Или, чтобы легче и гибче было управлять тем, какие данные будут в центре. Еще, несколько планов обмена создают, чтобы разными данными с разной регулярностью или/и разной интенсивностью. Да много для чего.

каких деталей тебе надо?

(85) да вслед за этим идет выгрузка подчиненных объектов.
например движения, регист сведений свойства объекта и тд. в подчиненной базе это все записывается в единой транзакции.

Коллеги, правильно я понимаю, что проблемы блокировок возникают именно при чтении в ЦБ, не при записи?

+(89) проблемы, которые вынуждают создавать два плана обмена и прочие ухищрения

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

(91) но у меня вопрос именно про блокировки

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

(92) Имхо, самое "слабое звено" - это таблицы регистрации изменений. Работа с ними (и проблема блокировки естественно) происходит как во время выгрузки данных, так и во время загрузки данных одновременно с работающими пользователями, которые тоже претендуют на регистрацию изменений в эти же самые таблицы.

Вероятность возникновения конфликта всегда есть, от этого не уйти. Почитай, подумай: http://v8.1c.ru/overview/Term_000000316.htm

(94) не увидел там ответа на свой вопрос из (89)
задал вопрос из-за такого простого теста:
- Создал базу ЦБ с двумя узлами пб1, пб2
- в ЦБ делаю выгрузку изменений в пб1, делаю останов выгрузки в процедуре ПриОтправкеДанныхУзлаПодчиненному()
- во втором сеансе ЦБ делаю выгрузку изменений в пб2, которая прерывается по ошибке "Конфликт блокировок".

Аналогичная же паралельная загрузка в ЦБ, с остановом в ПриПолученииДанныхОтПодчиненного() выполняется без проблем.

Понимаю, что это не нагрузочное тестирование, но мне интересно, что принципиально в ЦБ параллельно писать можно. Или нет?

(95) да, при выгрузке данные самые большие ожидания на блокировку при типовом подходе к работе с РИБ.

(95) это у тебя какие узлы? одного и того же плана обмена? да еще и включенным РИБ ?

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

(97) Да

(98) в (95) я пишу о том, что загрузка не блокируется

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

Эээ... не совсем так. Попытаюсь объяснить.

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

Так почему тогда блокировка возникает только во время выгрузки?

(95) Причина возникновения блокировки при выгрузке данных - обеспечение целостности данных с учетом многопользовательского режима работы. Например, чтобы документы, измененные/проведенные во время сеанса обмена, не попали в этот же сеанс обмена.

Иначе, если оперативно читать/обрабатывать все записи регистрации изменений, то можно получить парадокс: передача измененных документов без обновленных движений или обновленные движения без измененных документов. Просто напомню: в РИБ документы и их движения - автономны и независимы друг от друга; раздельно регистрируются; раздельно передаются; их взаимный порядок в сообщениях обмена не установлен и не определен.

Уф, как много буковок.

почти 2000 салонов 2-х уровневый риб, работает несколько лет.А теперь неудачники рассказывайте про не взлетит

(103) расскажи схему обмена
с какой периодичностью обмен, что из центра выгружается

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

Щас мейнстрим вообще не использовать план обмена. А ты аж две штуки собрался использовать. Хотя. Хотя тема именно с центральной пустой РИБ, в качестве матки конфы, для всех остальных - очень знатная.

(106) > Щас мейнстрим вообще не использовать план обмена
а как же регистрация объектов?

(105) правильно я понял, что у тебя три уровня:
Центр, Филиал, Точка
и инициатором обмена являются Центр к Филиалам и
Филиалы к Точкам
?

(107) наверное, хотели сказать, не использовать РИБ. Планы обменов вроде бы как остаются, т.к. регистрация изменений остатется, состав объектов тоже. Это нужно пересмотреть видеокурсы по использованию КД 3.0 - там сейчас действительно новые методики продвигают.

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

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

(111) >  пишешь измененную ссылку, куда-то - где можно параллельно писать без блокировок.
Ну так план обмена как раз подходит для этого

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

В (0) описанный вариант можно рассматривать как вырожденный случай "каждый с каждым".

Нарисуйте треугольник. Вершины - это узлы, линии - пути обмена данными. Любую вершину назовите "ЦУ"(центральный узел), а остальные - "ПУ"(подчиненные узлы).

"Каждый с каждым" в данном случае - это когда ЦУ обменивается данными(и обновлением конфигурации) с ПУ по первому риб-плану обмена и не "знает", что ПУ обмениваются данными между собой по второму плану обмена (не риб). При этом составы планов обмена могут быть одинаковыми или различными.

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

в чем выгода такого метода? только то что не нужно два плана поддерживать?

(113) вроде бы упоминали, например в (69)
нет?

(114) так можно делать когда у тебя уже все работает и нужно быстро и дешево костыльнуть.

(116)  почему считаешь, что это костыли?

(117) потому что сам процесс перерегистрации довольно длительный на больших объемах.

(103) расскажите теперь удачники, сколько прогов у вас бдит день и ночь за этой вундервафлей и как вы огребаете когда несрастухи с обменом?

(119) Есть мнение, что там только оперативная инфа в центр идет. И следить там, собственно, не за чем.

(118) я не увидел узких мест
что за перерегистрация?

РИБ или НеРИБ ? Хороший вопрос. РИБ использую очень редко, только для простых типовых обменов. Не использую: во-первых из-за разных конфигураций, например, периферийные базы типа УТ/УТАП 10.3, центральная - УПП/КА1.1. Во-вторых система регистрации измененных объектов РИБ тоже ресурсы потребляет. Мне проще за ночь выгрузить все документы отрытого периода (обычно за 2 дня, поскольку дата запрета редактирования - динамическая). Но было как-то при внедрении бюджетирования пришлось добавить 2-й "план обмена" для быстрых обменов документами оплаты и заявок на списание ДС. Понадобилось регистрировать их изменения (чтобы только измененные включать в обмен), хотел было использовать РИБ, но как то обошелся без него - в старых редакциях 8.2 доработки конфигурации обычное дело.
Сейчас в редакциях для 8.3 стараюсь не вносить серьезных изменений (обхожусь внешними обработками). Последний раз делал РИБ с фильтром по подразделению в УТ11.2 - кое что пришлось подправить в фильтрации РИБ, но в целом работает. Теперь заказчик пожелал общую консолидирующую базу заменить на КА2.0/ERP, оставив периферийные базы в УТ11.2. Возможно такое, РИБ будет работать в такой схеме?

Во-первых термин "РИБ" допустимо использовать между базами с идентичными(!) конфигурациями. При чём "идентичные" - это не равно "одинаковые". Всё, более никаких "во-вторых", "в-третьих" и т.д.

По поводу регистрации изменений (ты сам напросился)
"Мне проще за ночь выгрузить все документы отрытого периода" - а если будут изменены документы закрытого периода? А если в документах ссылки на новые или измененные позиции справочников?

Контрольный выстрел :) а теперь расскажи всем как без регистрации изменений настроить обмена записями независимого непериодичного регистра сведений? :)

(123) > Во-первых термин "РИБ" допустимо использовать между базами с идентичными(!) конфигурациями.
Вроде первые в 7-ке РИБ - это полные копии базы во всех узлах. Никаких РИБ с отборами по складу или подразделению не предполагалось. Поэтому в первую очередь пересел с РИБ на МОД. У меня была ТС (торговая сеть), мне не хотелось, чтобы в одном магазине знали что творится в других магазинах. Да еще в 90-х годах не было безлимитных трафиков Инета, чтобы гонять всю базу по всем узлам. Разные конфигурации стал использовать позднее, например, у магазина есть особая специфика, или другое налогообложение, а делать конфигурацию универсальной - сильно усложняло ее, снижало надежность.
А теперь гляжу РИБ с отборами - в разряде типовых обменов. Вот с подумал, что теперь условие идентичности конфигураций не обязательно?
Существуют же планы обмена между различными конфигурации. Разве планы обмена не составная часть РИБ? В моем понимании РИБ - это то, что делается на системном уровне, на уровне платформы, но могу использовать, или не использовать, т.е. РИБ или НеРИБ.
> По поводу регистрации изменений (ты сам напросился)
По 1-му плану обмена - он был практически односторонный, из торговых баз в общую УПП, и только документами. Справочники и РС выгружались только те, которые имели ссылки в этих документах. В УПП они не играли особой роли, это была упр. платежная система. Если задним числом ГБ или финики что-то правили, то отдельно говори какой период пере выгрузить. А в торговых базах ни-ни, строго. Еще на особом положении было то, что касалось структуры предприятия: организации, подразделения, склады, собственные контрагенты, их договора - создавались и правились только в ЦБ.
По второму плану обмена (быстрому) документами оплаты, да в КД2 писал отдельно правила регистрации изменений, но использовал ли РИБ (его элементы) затрудняюсь ответить.

Сейчас (см. выше) в конфигурациях 8.3 максимально хочу использовать элементы РИБ, если возможно. Например, КА2.0/ERP с УТ11.2 возможно? Или по старинке делать как УПП/КА1.1 с УТ10.3.

+ Максимально использовать элементы РИБ с целью минимального внесения в конфигурацию своих изменений. Но вносить их придется. Например, основная работа в периферийных базах планируется автономной, но некоторое взаимодействие будет, например, передача товара между организациями/подразделениями. Для этого структура предприятия должна быть полной во всех периферийных базах. И у заказчика есть особые требования по обмену: что-то только одностороннее, что-то нет, приоритеты измененных объектов тоже нестандартные... в общем РИБ или НеРИБ для меня очень актуально.

"Особенности организации многоуровневой распределенной информационной базы"
http://its.1c.ru/db/metod8dev#content:2273:hdoc

> Однако данный вариант исключает возможность внесения изменений в конфигурацию - в узле с установленным значением главного узла изменения конфигурации запрещены.
Этот признак устанавливает обязательную идентичность конфигурацию. Если его не устанавливать, то элементы РИБ можно использовать для различных конфигураций?

Необходимо уточнить, что имеется ввиду, когда говорится об "элементах РИБ". У универсального обмен данными и РИБ-обмена нет общих "элементов" - механизмы платформы различны. Есть только общие принципы. Например, поддержание целостности данных, сериализация, сообщения обмена в формате XML и т.д.

Если я правильно понял, то миграция конфигурации от корневого узла к подчинённым - это "нежелательный элемент РИБ"?

Установлено в подчинённом узле значение в ГлавныйУзел или нет - роли не играет. Корневой узел всё равно будет отправлять изменения конфигурации в подчиненные узлы вместе с обменом до тех пор, пока не получит от них подтверждения. Это встроенно платформой в сам механизм обмена.

Соответственно, если в подчинённом узле неустановлено значение ГлавныйУзел, то невозможно будет принять и обработать сообщение обмена, содержащее изменение конфигурации. Финиш.

(128) > У универсального обмен данными и РИБ-обмена нет общих "элементов" - механизмы платформы различны. Есть только общие принципы. Например, поддержание целостности данных, сериализация, сообщения обмена в формате XML и т.д.

Удачный пример! Сделал РИБ с фильтром по подразделению для УТ11.2. В образы периферийных баз не перенеслись некоторые Ввод остатков с новыми типами операций, надо было править фильтрацию РИБ. Сначала решил не трогать конфигурацию, перекинуть через Универсальный обмен данными в формате XML, поскольку Ввод остатков не рабочий документ, скорее ввод в эксплуатацию базы - один раз надо сделать. И что же "Документ не может быть изменен в подчиненном узле распределенной информационной базы" - не прошли ту же фильтрацию РИБ.
> Необходимо уточнить, что имеется ввиду, когда говорится об "элементах РИБ".
Да, критерий: РИБ - это то, что делается на уровне платформы (системном). Не совсем верный, уж больно все повязано между собой.

(129) универсальный обмен настолько универсален, что умеет читать и работать по готовым узлам РИБ, с соблюдением всего дописанного в РИБ кода :)

(130) Дык, прописал новые типы операций Ввода остатков в фильтрации РИБ, документы сами пришли в периферийные базы без Универсальный обмен данными в формате XML.
Вопрос темы РИБ или НеРИБ осложняется тем, где РИБ и НеРИБ?

+ (125) Ладно, сделал целиком все РИБ с фильтром по подразделению для УТ11.2. Теперь заказчик вроде просит, центральную консолидирующую базу обуть в ERP или КА2.0. Загрузил в копию его УТ11.2 свежую КА2.0, чтобы хотя бы посмотреть как будет это выглядеть. И целый час вычищал РС, где есть ссылки на РИБ, иначе записи не уникальны! Оказывается в ERP многого нет в части РИБ: ни полного, ни с отборами!?
Не пойму, что из чего делается: когда ERP бетой была, понятно - собиралась из составных частей: УТ11, БП3.0 и ЗУП3.0. А сейчас вроде наоборот должно - УТ11 вырезаться из ERP. И что, тенденция такова, что РИБ исчезнет из УТ11 тоже?

(131) РИБ в терминах платформы 1С, когда в плане обмена стоит флаг "Распределенная информационная база"
со всеми вытекающими

(133) Тогда в ERP РИБ вообще отсутствует!? Не доделака 1С, или такова тенденция? Если тенденция, то в 1С вообще РИБ исчезнет?

(134) > Тогда в ERP РИБ вообще отсутствует!?
похоже на то

Хех :)

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

Непонятно сказал?

Тогда скажу другими словами: вы много видели организаций, которые готовы купить ERP не только для своего главного офиса, но и всем своим многочисленным филиалам по экземпляру?

РИБ для ERP не скоро станет актуальным.

(136) поскольку вовсю продвигают КД3, то не будет появления в ERP каких-то иных решений, взамен КД3.

(137) только не иные решения взамен КД3, а КД3 взамен обменов, которые были до этого
планы обмена никуда не денутся

Не путайте божий дар с яичницей, универсальный механизм обмена данными (http://v8.1c.ru/overview/Term_000000314.htm) и механизм распределенных информационных баз (http://v8.1c.ru/overview/Term_000000315.htm) - для обмена РИБ конвертация данных не нужна.

PS: не я придумал эти термины - все претензии к фирме 1С.

(136) Тогда скажу другими словами: вы много видели организаций, которые готовы купить ERP не только для своего главного офиса, но и всем своим многочисленным филиалам по экземпляру?

Каждый рабочий день вижу такую организацию, когда на работу прихожу :)
И отсутствие в типовой ERP РИБ - серьезное препятствие для перехода.

РИБ интегрировать в ERP, да и в любую другую конфигурацию, - как два пальца об асфальт. Если только подходить к делу без излишних наворотов и фанатизма в глазах :)

(136) > РИБ для ERP не скоро станет актуальным.
Я им редко пользуюсь, только для простых типовых случаев. Для сложных обменов свое пишу, но стараюсь максимально использовать то, что уже есть в конфигурации для этого. А как это называется: РИБ или НеРИБ мне не так важно.
(137) В В 1С КА 20 и ERP нет РИБ другая информация (6):
> В "планируемых изменениях в редакции 2.2.1" обещали полный РИБ, но в последней версии этого документа нет ни слова про это.

(142) "А как это называется: РИБ или НеРИБ мне не так важно" - это важно другим. Помогает профессионалам общаться. И составить верное мнение как о вопросе, так и о авторе вопроса.

(офф) А иначе на вопрос "Как?" можешь получить инструкцию от мастера:
- Слухай сюда! Положь колдобину со стоpоны загогулины и два pаза деpгани за пимпочку. Опосля чего долбани плюхалкой по кувыкалке и, кады чвакнет, отскочь дальшее, пpикинься ветошью и не отсвечивай...

(143) Понятие РИБ трансформируется, раньше (в 90-е в 7-ке) РИБ - полные копии во всех узлах, а РИБ с отбором - уже не считался как РИБ. Теперь, в порядке вещей. Мне суть важна, а не название (профессионалам думаю так же).

коллеги, спасибо за полезную дискуссию

(145) К какому выводу пришел? Мое мнение в сложных, 2-х двухуровневых схемах обмена РИБ использовать нельзя, даже самых простых случаях как РИБ с фильтром по подразделению в УТ11.2 очень осторожно - не целиком РИБ, как расширением платформы, а только отдельные процедуры.

(144) Не надо ляля.

РИБ это галочка "РИБ"! И это коренным образом решает многое.

РИБ это мать и дочка. РИБ это клон дочки при гибели дочки.

А все остальное это уже кухня.

(146) РИБ - это механизм платформы, грубо говоря, - инструмент. И ничего более. То, как Вы его используете (или не используете), - на Вашей совести.

Молоток в неумелых руках одинаково сильно бьёт по гвоздям, мимо и по пальцам. Но есть отличия: по пальцам - ещё и больно.

"И на душе у меня -- замечательно. Как и должно быть у человека, забившего гвоздик любимым микроскопом."(с)

(148) "Постучать по пальцам" неопытному ИТ-шнику полезно - опыта наберется. А вот если за "молоток" хватаются ГБ или финик - опасно!? Ситуация следующая: обратилась контора с предложением "по разделению баз". В общей базе 3 организации: основная, и 2 вспомогательные. РИБ был настроен изначально только для основной организации. Как позже выяснилось этот узел РИБ не для работы. На случай, если нагрянут маски-шоу, то виртуальный сервер с общей базой гасится, на его место встает сервер с этим узлом РИБ, где только одна база (2 другие какие-то "левые", их нельзя показывать).
Сделал им РИБ с фильтром по организации (точнее по подразделению), создал для каждой организации свой РИБ узел. После 2 периферийные "левые" базы увезли в другое место. 3-ю для основной организации похерили, вместо нее решили использовать общую базу, почистив от 2-х других. Пометить на удаление пометили, но почти ничего не удалилось из-за ссылок. Спрашиваю, за чем так, у вас же есть 3-я РИБ только с основой организацией? - Решение финика - лень сверять, вдруг в ту РИБ что-то не перенеслось из документов!?
А как же общая консолидирующая база? - Пока она не нужна, не знаем какая она должно быть по функционалу (пробовал общую базу обувать в КА2.0 (132) - не устроило), после решим, тогда и сделаем... Ладно думаю, хозяин - барин, после так после...
Теперь обмены РИБ не ведутся, регистрация об измененных объектах копится! Предел этому есть, не рухнут ли из-за переполнения регистрационных данных?

(149) "Ладно думаю, хозяин - барин, после так после... "

Это ты виноват! Врачу скажут реж ногу или руку он тоже должен резать здоровую ногу или руки?
Надо было объяснить или делаете обмен или живите без РИБ. Третьему не дано.
О пределе накопление тебе вряд ли кто скажет ибо такой фигней ни кто не возится. Попробуй раскажешь.

(149) или поставить очистку регистрации с какой-то периодичностью или пометить временно "не нужный, не используемый" узел на удаление. Насколько я понимаю сам себе, то регистрация объектов туда производиться не будет. Есть еще более надежный вариант - пометить весь состав выбранных метаданных в этом плане обмена в авторегистрации: "запретить".

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

(150) Я же писал: обратилась контора с предложением "по разделению баз". Как она распорядится сделанным узнал позже, о возможных последствиях такого использования предупредил. Хотелось бы уточнить, как долго продержатся РИБ базы от такого использования, если не принять меры? Им лень вручную сделать сверку узла РИБ основной организации с общей - предложил написать обработку сверки. Отказались. Пока решают вопрос какая должна быть общая консолидирующая база: по составу документов вроде все устраивает - должны быть документы всех 3-х организаций. По функционалу определяются - что-то хотят из КА2.0/ERP, но весь БУ им не нужен. Как долго будут определяться - не знаю.
(151) Если в периферийных базах отключить РИБ, то потом сложно будет собрать общую базу. Пока РИБ включен изменения регистрируются, как понадобится общая база, достану ее из архива (есть копия до "чистки"), и сделаю обмен. Но как долго они продержатся без обмена?

(152) тут нужно понимать главное: РИБ в терминах 8.* - это просто принципиальное наличие обмена ГлавныйУзел туда-обратно ПодчиненныйУзел с дополнением к обмену данными обменом изменениями конфигурации. Все остальное, в том числе, состав объектов метаданных и способ регистрации конкретных объектов ( авторегистрация разрешена / авторегистрация запрещена ) - абсолютно настраиваемо.

(152) т.е. отключи авторегистрацию всех объектов и будут накапливаться только изменения конфигурации, которые не отключаемы никак.

"Хотелось бы уточнить, как долго продержатся РИБ базы от такого использования, если не принять меры? "

На вряд ли кто-то конкретно ответит. Ибо такой практики почти нет. Бывает что какой-то объект не хотят передавать между базами но потом приходит решение что надо передавать такое решение приходит быстро от силы в течение 1-2 месяцев.

(149) "регистрация об измененных объектах копится"
(150) "О пределе накопление тебе вряд ли кто скажет ибо такой фигней ни кто не возится"

Эээ... если этой фигнёй завозиться :) то быстро можно сообразить: количество записей регистрации изменений объектов, в принципе, не превысит количество этих самых объектов.

Если в РИБ-базе надолго остановить обмен, то базы узлов будут вести себя как автономные базы (каковыми они и являются на самом деле)

На вскидку, не особо думая: если восстановить обмен данными после длительного перерыва, то в риб-базе вы обнаружите множество "задублированных" объектов. Если подумать, то вы сами поймёте почему появление дубли неизбежно.

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

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

Ну при чём тут это?

Ну ты сам подумай: обмен остановлен, но в базах продолжают работать... и возникает необходимость добавлять новые объекты. Но если раньше объект создавали в одной базе и он мигрировал в другую базу, то теперь такие объекты каждый сам для своей базы самостоятельно добавляет.

Всё, этого достаточно. Эти новые объекты, даже если они полные копии друг друга, с возобновлением обмена, первым же сеансом, породят дубли. Потому что соответствие объектов при риб-обмене идет по внутренним идентификаторам,  а они - различны.

(159) Да им эти дубли ничем существенным навредить не смогут. Просто у Васи свой "любимый" элемент справочника Контрагенты, а у Коли - свой. Возникнет конфликт в работе в этими дублями или нет? У пользователя с какой функциональностью это возникнет - очевидно, что у бухгалтера может быть, хотя и не на 100% это будет обязательным.

(160) Да, Контрагенты обычно плодятся как кролики, их дубли иногда клиент-банк подбрасывает. Но это уже другая проблема с РИБ не связана.

"(160) Возникнет конфликт в работе в этими дублями или нет?" - из-за дезориентации пользователей между дублями записей справочников, в первую очередь рассыпаются всё, что связанно с взаиморасчетами.

PS: бесполезный разговор. Дубли - зло. Точка.

(162) главное, чтобы в процессе их уничтожения пользователи не забывали работу работать. А так-то, да - это зло.

(156) Записи регистрации изменений объектов куда пишутся, не разбирался?

(164) Если у тебя 8.2, то в таблицах с подстрокой "ChangeRec" в наименовании.