Версия для печати темы (https://pro1c.org.ua/index.php?showtopic=16378)

Автор: nysysimara 27.01.14, 19:38

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

Автор: Ardi 27.01.14, 19:41

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

Автор: nysysimara 27.01.14, 19:49

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

Автор: XBrut 27.01.14, 19:57

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

Автор: Ardi 27.01.14, 20:05

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

Автор: XBrut 27.01.14, 20:20

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

Автор: alex040269 28.01.14, 7:13

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

Автор: XBrut 28.01.14, 7:27

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

Автор: alex040269 28.01.14, 8:16

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

Автор: nysysimara 28.01.14, 8:16

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

Автор: alex040269 28.01.14, 8:31

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

Автор: nysysimara 02.02.14, 12:33

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

Автор: alex040269 02.02.14, 16:15

http://pro1c.org.ua/index.php?s=&showtopic=16378&view=findpost&p=80930

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

Автор: nysysimara 02.02.14, 18:39

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

Автор: alex040269 02.02.14, 20:48

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

Автор: nysysimara 02.02.14, 21:17

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

Автор: nysysimara 02.02.14, 23:10

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

Автор: alex040269 05.02.14, 8:05

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

Автор: nysysimara 05.02.14, 17:34

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

Автор: XBrut 05.02.14, 17:52

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

Автор: nysysimara 06.02.14, 11:36

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

Автор: Cthulhu 23.02.14, 23:50

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

Автор: XBrut 24.02.14, 8:33

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

Автор: Cthulhu 26.02.14, 15:41

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


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

Автор: XBrut 26.02.14, 16:00

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

Автор: Cthulhu 26.02.14, 16:14

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


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


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


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

Автор: XBrut 26.02.14, 18:36

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