Здравствуйте.

Попал в ситуацию, из которой не знаю, как выбраться. Если кто может - помогите.

Имеется УРБД с тремя базами. Конфигурация самописная. SQL.
Размер базы данных превысил 20 ГБайт, приняли решение наконец-то сворачивать базу.
Перед сверткой сделал бэкап всех трех баз средствами SQL.
Свернул центральную, запустил обмен между базами. размер файла выгрузки из ЦБ составил порядка 40 МБайт, в итоге за сутки периферийные базы так и не смогли принять информацию. Решили откатить обратно. Периферийные базы восстановились нормально, а вот с центральной..
В общем, видимо, забыл отключить ежедневный бэкап и файл бэкапа перед сверткой оказался перезаписан файлом бэкапа свернутой базы. Метод восстановления - SIMPLE
Есть, правда, еще один бэкап, делал его для тренировки в свертке, но он двухнедельной давности.
Как можно выкрутиться, есть ли какие-то рекомендации?

Заранее благодарен.

(0) А какая схема обмена?

документы и большая часть справочников - место создания и центр

(1) наврал. Документы и бОльшая часть справочников - все ИБ

(2) То есть всё создается в перифириях, и мигрирует в центр?
Тогда просто смигрируй всё из переферий в центр.

(3) А создаются элементы как правило где? В центре или перефириях?

Если все ИБ, то тоже без проблем.

мд-шничек из переферийки в цб попробуй тупо подложить

(7) это с какой целью, если не секрет?

(5) в основном в центре. На периферии только документы.

(7) Разве элементы справочников и документы сами смигрируют?
Их для этого вроде нужно программно перебрать, записать, и если нужно провести.

(9) Если у тебя все ИБ, то всё из центра есть в перефериях.

(11)
как инициировать передачу с периферии в центр документов начиная с 19 января по текущую дату?

(0)главное горячку не пороть. Оставь профи - самая большая проблема - найти их! - но это не ко мне.

(12) Разобартьсчя с счетчиком, чтоб центральная база была готова принять с переферии, а потом в переферии-
Док.Выбратьдокументы('19.01.2013',ТекущаяДата());
пока Док.ПолучитьДокумент()=1 цикл
Док.НомерДок=Док.Номердок // на всякий случай
Док.Записать();
конеццикла;

а как разобраться со счетчиком? вот это для меня основная проблема..

Т.е. проблема бы решилась если из копии одной перефирийной базы сделать центр? Где-то читал методуду, по моему какой-то байт сделать 1, Но умоляю на копии, можно и на DBF потренироваться а затем загрузить в sql. Но перед каждым действием КОПИЯ!!!!

(16) нет, не решилась бы, к сожалению. Все таки базы разные

(16) Две перефирии, нет смысла. Проще как в (14)
(15) счетчик сейчас найду.

УРБД. Где система хранит значение внутреннего счетчика номера файла (пакета

Книга знаний: Нетипичное использование компоненты УРБД в системе 1С:Предприятие 7.7
Тут в конце есть про счетчик

А если очистить 1supdts и 1SDWNLDS во всех трех базах? Затем сделать то, что было предложено в (14). Начнется ли счетчик заново?

(21) Нет, это не выход. Надо просто с счетчиками разобраться, и правильно их выставить.

(22) а почему?

(22) Прав. Сам сталкивался с подобной ситуацией и тоже после свертки. Со счетчиками разобраться несложно, путем научного эксперимента, в результате утром верооятнее всего базы будут восстановлены.
(23) Думаю вопрос чисто академический, лучше бы поразбираться неторопясь, когда все уже работает.

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

Если есть живая свернутая центральная база и вся нужная информация в ней есть, то можно просто заново инициализировать новые периферийки, а старые выкинуть.

(0) (26)
Угу ..непарся ..создай просто заново новые переферийки. :)
Главное что центральная жива а остальное побоку.

(26)быстрее склонировать.
только зачем? Если и без этого никаких проблем....

О'май год... (0) Мазохист... 20 Гб, не предел :)
Скорости все ровно не прибавится. :)

>>>> файл бэкапа перед сверткой оказался перезаписан файлом бэкапа

А это тебя за это надо БИТЬ и сильно... трудно было сделать бекап ручёнками? :)

(0) в базе цб прибить табличку 1supdts.
в ПБ перезаписать все справочники и доки. только не все сразу а частями. ЦБ будет как новая.

В общем, сделал так:
1. Создал копию ЦБ, куда восстановил бэкап по 19 января 2013 (несвернутая)
2. Очистил во всех трех базах updts и dwnlds
3. перезаписал все документы и их содержимое в одной из ПБ с 19-01-2013 по тек. момент (по сути, инициировал обмен)
4. Провел обмен, после чего подгрузил обработкой недостающие документы из текущей ЦБ в копию ЦБ, сделанную в п.1

Собственно, все работает вроде.

(29) а почему скорости не прибавится, если уменьшить размер ИБ?

(30), согласен, но я же говорю - просто забыл. В двух ПБ автобэкап отключил, а в ЦБ каким-то образом забыл.

(26) переинициализировать новые ПБ - не совсем целесообразно, так как базы все же по ряду объектов уникальны

Всем большое спасибо за участие и поддержку, особенно NS за (19) и (20)
Удачного дня.

(0)Я много раз делал так: лезешь каким нить редактором досовским внутрь файлов ПБ и правишь им счетчики , и добиваешься приемки в ЦБ. как то так - там нет ничего сложного - погугли - инфы море.

Я бы не рекомендовал делать полную миграцию из ПБ в ЦБ
т.к. файл обмена может получить похлеще чем после свертки
хотя можно частями обновиться
---
имхо можно по другому пути пойти, хотя и посложнее:
1. Сделать ПБ1 - центральной
2. "прикрутить" к ней ПБ2
3. сделать ПБ3

И нафига ?
У тя же есть нормально свернутая ЦБ.
Всего то надо было - свернуть ПБ тем же алгоритмом и привет.

Кстати базы потом работают нормально хоть и бытует мнение , что лазить и исправлять счетчики некамильфо - неверь - все будет ок. У меня уже  6 лет все работает - иной раз срочно нужно принять ПБ до исправлений в ЦБ - а кто то из шаловливых бухгалтеров залез под админом и сделал выгрузку из ЦБ - что делат? тупо ломаешь счетчик как надо и грузишься в ЦБ. раз в месяц такая зараза  происходит регулярно...

(35) кстати да
проще от свернутой ЦБ отпочковать новые (свернутые) ПБ1 и ПБ2

(0) А вообще прежде чем резать что то надо сделать тучу архивов и не извратом через скуль , а средствами самой 1с. как то так.

(38) Это изврат делать средствами 1с архивы, если база на скуле. Да и про размер базы циферки в (0) ты упустил.

(34,37) Документооборот в базах одинаковый, но есть справочники, уникальные для каждой ИБ, кроме того, трудно предположить, сколько по времени займет переинициализация новых ПБ при весе ЦБ свыше 20 гигабайт.

(35) думал об этом. Свертка ЦБ заняла около 17 часов (к сожалению, прямыми запросами не владею), опять же фактор времени

(36) Ознакомившись с тем, что любезно предоставил NS в (19) и (20) соглашусь с Вами.

(38) архивы были сделаны, проблема в том, что один из архивов.. впрочем, уже было сказано выше. 1С в штатном варианте не сумеет создать архив от базы в 20 ГБайт, искать и разбираться с компонентой
Кроме того, в чем преимущество архива, сделанного средствами 1С, перед архивом, сделанным SQL?

черт, в догон к последнему посту:

(38) архивы были сделаны, проблема в том, что один из архивов.. впрочем, уже было сказано выше. 1С в штатном варианте не сумеет создать архив от базы в 20 ГБайт, искать и разбираться с компонентой от Romix опять же не было времени.
Да и в чем преимущество архива, сделанного средствами 1С, перед архивом, сделанным SQL?

(41) преимущество в том, что такой архив содержит в себе ещё и конфигурацию и список пользователей.

(40) дык перепиши свёртку.

Сейчас же один хрен переписывать надо, а 17 часов - это моветон для любой базы.

(40) Не слушай завсома...

(44) Завсом - это, простите, кто?)

(42) Это у меня скриптом копируется папка с каталогом ИБ целиком.

(46) хорошо, сколько тогда весит архив СКЛ и архив средствами 1с?

(45) это 2012_12_17

(47) Архив СКЛ весит столько же, сколько и БД СКЛ (в моем случае)
Архив 1С - х его з, штатными средствами сделать не представляется возможным

(48) а почему "завсом"??))))))

(48) а почему "завсом" ???))))

А вот если сделать следующее:

1. Убедиться, что между тремя ИБ прошли все-все-все обмены.
2. Одновременно запустить свертку во всех трех ИБ, по одному и тому же алгоритму
3. после свертки снова почистить таблицы dwnlds и updts

Взлетит?

(52) одинаковый алгоритм не гарантирует одинаковых конечных данных..
а в принципе - "взлетит" :-)
(50) это него главный ник, забаненый очень надолго...

(52) Делать очень просто!
Сворачиваешь одновременно все 3 базы.
Чистишь файлы обмена
Загружаешь очищенные файлы
От радости пьешь коньяк

(54) А что Вы подразумеваете под "чистишь файлы обмена"? От чего их чистить и каким макаром?

(53) почему не гарантирует? при одинаковых начальных данных и алгоритмах свертки - почему могут быть расхождения в конечных результатах?

(55) Удаляешь из файлов обмена из ЦБ ВСЕ справочники и документы.
Из ПБ только одна пустая "заготовка"

(57) по сути, это то же, что я предположил в п.3 поста (52). Разве нет?

(58) По сути ДА

(58) если быть точным, это аналогично очистке апдейтса.
(56) на строго идентичных данных - расхождений не будет. но строго идентичных данных я в распределенке не видел...

(60) За идентичностью менеджмент следит. Утверждают, что все поровну)

ладно, идея имеет право на жизнь. В выходные попробуем)

(61) Строки из моего резюме
"Создание и администрирование распределенной базы (УРИБ) 1С:Бухгалтерия 7.7 на 97 переферийных баз.
Производство обменов нештатными методами.
..."

(62) "через жопу"©? :-)

(61) ты лучше подумай - а оно тебе надо?
20 г - не такая уж и большая база...

(63) А ты попробуй на 97

(65) ну а чего бы и нет? :-)