Добрый вечер,
работать с РБД никогда не доводилось, но
предстоит свернуть распределенную базу:
7.70.027,дремучая ТиС, исписана вдоль и поперек
Скульная, переферийка по-моему дбф
Подскажите порядок действий.
Нужно ли выполнять ту же свертку в переферийной?
или просто выполнить обмен?

Выполнить обмен.
А потом в конфигураторе сжать базу, пересчитать индексы и итоги.

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

1) собрать всю инфу в центральную базу
2) удалить все периферийные базы из списка
3) обрезать цб как обычную
4) создать периф. базы заново с теми же кодами
5) раздать первичные выгрузки
6) ура

А потом придётся заполнять какие-нибудь настройки в периферийках.

я так обрезал огромную распред базу 5 розн магазинов.
случаи конечно разные бывают. например какие настройки слетят?

Я когда-то сворачивал УРБД с одной переферийкой на бух итогах. Проблем вообще никаких.
Свернул ЦБ. результаты переехали в переферийку и все.

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

это да. + регистры переезжают значительно дольше.

думаю, что после свертки, база будет не большая:
справочники Контрагенты и Номенклатура, десяток документов ввода остатков и 5 регистров

на перенос из ЦБ в переферию влияет то, какая база была до свертки.
Время переноса (в основном время втягивания в переферийку) примерно равно времени удаления документов в ЦБ.

Вопрос вдогонку:
Сколько по времени может занять "переезд" в периферийку
В ДБФ база весила 3,3 ГБ
В основной убиты все доки, остались толь около 10 штук ввод остатков по четырем регистрам
в периферийке загрузка началась в 4:00
а у меня время только до завта

необходимо зарегистрироваться для просмотра ссылки

быстрее сделать новые ПБ.

я после свертки основной базы сделала ее выгрузку
а если в существующей периферийной поднять эту выгрузку

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

честно, боюсь удалять настройки,
а если так:
файлы автоматического обмена прибить
В ЦБ в "управлении распределёнными данными"-> "Выгрузить данные"
а в ПБ "Загрузить данные"?

потребуется 18 часов
всем большое спасибо за помощь

откройте секрет!
какой обработкой вы делали свертку?
сколько лет?
сколько времени удалялись доки в ЦБ?

никаких секретов:
данные в базе были с сентября 2011 до 01.02.2014
только оперативный учет
всего удалила чють более 500 000 доков
для свертки написала к каждому из четырех регистров документ ввода остатков
пометила на удаление все доки простенькой обработкой(с транзакцией каждой недели) - 2ч
"Удаление помеченных объектов" - 1,5ч

Я ж вам говорил надо периферийные базы удалять управились бы за день.

теперь, набив собственную шишку, буду умнее

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

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

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


хм. странное решение.
1) чтобы неактуальные данные собрались в одну большую кучц, которая расползется по всем периферийкам?
2) дополнительно - не мигрирующие данные могут иметь конфликт в части дублирования ключевых полей (дублирование кодов справочников и номеров документов) при сборке в кучу;
3) и - м.б. я чего-то не понимаю, но каким образом собрать, а потом распихать по периферийкам значеня не мигрирующих констант?..
или - хм, а что подразумевается под "там скопировать эти объекты"?

так я ж и говорю что зависит от контекста.
мало ли какие у кого условия? у кого две базы и объекты везде ходят, так это все вообще не актуально.
немигрирующих констант у меня не было.
номера и коды - уникальные.
документы удалялись долго.
связь - так себе.
15 баз в разных городах за ночь - вы прямо Дартаньян :)
П.С.
но ваш метод конечно интересный. ...

холдинг. фирмы, префиксы, основные склады и структурные единицы, налогообложение, и т.п.


со сдвигом ТА - быстрее. ещё быстрее - нештатно (штатно - только составление и сохранение списков ИД объектов для удаления и плоских таблиц остатков, опять таки, с ИД)


Вопросов со связью вообще не стояло. радмин/тимвьюер и по одному консольному компьютеру в каждой ИБ. подключился - запустился - отключился, ответки по завершеням прямо на емыл (с протоколами на сверку, сверка - авто-сравнением). причем все это не так сложно, как может показаться.


а вот обзываться нехорошо.

ну. удалять документы со сдвигом ТА я догадался, а вот если кто кинет ссылочкой на нештатное удаление по спискам - думаю многие будут благодарны.
П.С.
при чем тут "обзываться" 15 баз за раз обычно обрезают Дартаньяны, а обычные селяне, типа меня, обрезают одну нераспределенную базу уже вторую неделю