v7: Свертка ТиС, УРБД (30 узлов), нетиповая #655103

Господа, как и чем лучше выполнять сабж с минимальным отрывом операторов от работы? На форумах пишут по-разному, кто говорит нужно параллельно настраивать новую УРБД и в час Х делать финальный обмен и переносить оставшиеся документы, кто говорит что можно как-то из центральной всё это провернуть... Кто и как решал подобную задачу? Центральная база порядка 8 гигов на dbf'е. последняя свёртка была в 10 году (возможно типовой обработкой "Сервис-Свертка базы") - с тех пор было много доработок

план обмена каков с узлами?

Для начала затолкай ее в SQL а там прямыми запросами. У меня свертка 7 лет заняла от силы 2 часа.

место создания и центр

во времени ограничен, + по форумам обрезка через скул - не даёт обрезки перефериек

тогда сложнее

24*7 работа на ПБ идет?

да - сеть магазинов на АЗС

может обрезать только центр, а потом по-ходу перефирийные постепенно в процессе работы?

или всё-таки параллельно новую УРБД настраивать?

Ну... тогда сворачивать на ПБ нет смысла В центре запускаем суперобработку и делаем заново первичную выгрузку ПБ Я бы так сделал

+1 я бы тоже... Но, 30 узлов...

А свертывать ПБ поочередно? 30 ПБ выгружать одновременно как? Закрывать сеть на день?

В принципе можно свернуть только центр, затем размножить базы путем тупого копирования и потом отрезать ненужное Вот технология для SQL Правда нужно много думать чтобы не облажаться Но ведь тренировку никто не отменял? Главное чтобы в час X все прошло гладко потом переписываем файлы DBF на флешки и рассылаем 30 гонцов на лошадях 9чтобы не тратить время на пересчеты итогов при загрузке) :)

Переходи на 8-ку, там все есть :)

Нее.... переходите на терминал, если с интернетом проблем нет

Сколько весит самый большой файл с расширением DBF? То что каталог весит 8 гиг, это ни о чем не говорит...

+ Как вариант переходи на SQL и вообще забей на свертку :)

Переходите на один большой магазин :)

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

это смотря как обрезать. ЕСли через SQL то незабывай что есть таблица _1supdts.

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

Расскажу как у меня: у меня остатки по ПБ и остатки по ЦБ должны быть разными. Поэтому свернуть ЦБ и разослать по ПБ не катит. Значит сделал два документа: Остатки по счетам ( у меня в Раруснефтебазе есть еще и счата бухучета и ОСВ и анализ счета все как в бухии) и Остатки по регистрам. (Проверяю регпринтом содержимое регистров.) Вся сложность при свертке только в налисии "парных документов" документов сделанных на основании других ( у меня это перемещение и пересортица и актынасливГСМ с приходнойвпутиГСМ и еще ВыпускПродукции с заказомвпроизводство)

>>...у меня остатки по ПБ и остатки по ЦБ должны быть разными... круто

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

А что крутого? У ПБ свои остатки по кассе и на складе, в холдинге свои. Нафига кассиру ПБ знать кассу офиса?

В холдинге много хранимого чертте где товара не обязательно в ПБ. В ПБ же только то что реально налито в танки.

ну и немножко на путях в соседних станциях :)

Прикольный там учет поди - номенклатура не справочник, а перечисление (80,92,95,98, ДТ, ДТ зимнее)? :)

самый большой файл 1,2 Гб

Центральную базу (копию) уже свернул (по одной инструкции с удалением файлов документов из каталога базы и последующим переносом остатков по всем регистрам на 31.12.12 + все документы этого года)  - еще на прошлой неделе, но там слетел механизм распределёнки

Ну работайте еще пару лет, а до этого тренируйтесь.

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

что за суперобработка?

Еще вопрос: если делать свёртку только ЦБ (ПБ пока оставим - времени столько не будет, а нам нужно сейчас и сразу) стандартной обработкой "Сервис-Свёртка базы" всё ли пройдёт нормально? (в базе есть нетиповые регистры/справочники/документы и т.д.)

ну не совсем так 95-РС SHELL V-POWER RACING вид III SHELL V-POWER-95 вид II Аи-92 Аи-95 БГС Бензин газовый стабильный Бензин А-76 Бензин А-76 н/э Бензин Аи-92 Бензин неэтилированный марки Аи-92 ЭКп Бензин Аи-95 Бензин Аи-98 Бензин Нормаль 80 Бензин неэтилированный марки Премиум Евро-95 вид 1 Бензин Регуляр  92 Бензин Регуляр-92 Бензин-95экп Битум БНД 60/90 БПЦ Дизельное топливо зимнее (до -25С) Дизельное топливо зимнее Дизельное топливо РТ Топливо ТС-1 Добавка МТМ Дизельное топливо "З" - 0,2-35 Дизельное топливо Л-0,2-62 ДЭКп-З-0,005 класс 4 Дизельное топливо ДЭКп-З-0,035 Топливо дизельное ЕВРО сорт Е Топливо дизельное ДТ Е (-20) Топливо дизельное ЕВРО класс 1 вид 1 ДТ Евро класс 1 вид 2 Топливо дизельное ЕВРО класс 3 вид1 Топливо дизельное ЕВРО, сорт С Дизельное топливо класс II вид I Топливо дизельное Л 0,05 ДТ ТНК КВД Керосин ММА Пирополимер Присадка А Присадка в ДТ для предотвращения роста кристаллов парафинов Пропан АЗС Регулятор горения АДМ-6 СНО СПБТ Супер холод Топливо дизельное зимнее 0.05 Топливо печное

Синхронная обрезка каждой базы без регистрации изменений.

РарусНефтебаза это скорее ТИС + автосервис, к моему еще и бухучет присандалили ну и учет и по литражу и по массе в добавок.

(19,36) +голоса разума, можно резать даже несинхронно. и вообще 8гб можно не резать, переводи на SQL и не парься еще 2-3 года проживет, а там уже апгрейд на 1С 8.

Если резать каждую - труднее управлять процессом И когда резать? Бывает же у людей хоть один выходной или там праздник? Можно отмучиться за одни раз

Перед обрезкой делаешь обмены с ПБ. На ПБ делаешь бекапы и высылаешь в центр. Переводишь ЦБ в скуль. Быстренько все режешь. Разворачиваешь в центре ПБ и загружаешь в них обрезку из ЦБ. Отсылаешь обрезанные ПБ на места. На местах в обрезанные ПБ затягиваешь документы которые появились в промежутке. Все.

: да, там у меня "синхронность" - немного некорректный термин, скорее "одинаковость алгоритма".

: не труднее. ночь+треминал - можно и за один раз управиться. а можно и растянуть - протоколирование процесса ещё никто не отменял, какой контроль нужен - такой и нарисовать.

, как это делается (перевод в SQL)? )))) 7-кой уже сто лет не занимался... Т.е. ЦБ в SQL'е будет, а ПБ по-прежнему на dbf?

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

Если сворачивать без выкрунтасов - не нужен СКЛ

Вот давно делал, протестировано не раз на нетиповых регистрах Рядом лежит для SQL

+ Для больших объемов лучше взять для SQL обработку, а то может загнуться

перефирийка в этом случае остаётся не свёрнутой ведь? - там ничего не нарушится (итоги, остатки)?

русские буквы в кодах есть - какие могут быть проблемы и как их лучше решать?

или перефирийки следом за ЦБ позже сворачивать? или можно вообще отложить это дело до перехода на 8-ку?

,: там только регистры сворачивает?.. а бух.итоги?.. а периодику (и - как?). (такие вещи вообще неплохо бы в самом описалове на страничке указывать)

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

Да, регистры

Периодику - тоже несложно.

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

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

dbfscrubber

Прикольно Самописка? Есть какой-то регистр с большим кол-вом измерений?

да, и не один. Конфигурация на базе типового ТиСа

Ненужно. Ты скулем сразу можешь из регистров поудалять движения помеченных документов. Потом просто пересчет итогов сделать нужно будет.

можно по-подробнее? база дбф-овская

что мне сейчас нужно сделать?

открыть базу в sql-платформе (какой скул выбрать 2000 или 2005?) и там что-то сделать?

Движений у помеченных и так нет Быстрее пересчитать итоги разом а не выкусывать удаленные из них 1С сама более или менее успешно пересчет делает Если такие плохие регистры - попробуй выполнять полностью свертку в SQL (лучше в 2005)

т.е. я открываю дбф-базу (до этого она работала не под скулем) в скул-платформе и запускаю пересчёт/переиндексацию и свертку там?

Придется выгрузить-загрузить Ты потренируйся и так и сяк Возможно на SQL быстрее получится

и если ЦБ после этого так и оставить на скуле - с пб на дбф проблем не будет? с обменом?

или потом лучше опять перегрузить в дбф?

Не будет Но кто мешает держать ПБ на экспрессе? Или там уже объем зашкаливает

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

лишь бы база свернулась нормально и не за 4-5 дней ))))

Проблема решилась банальной выгрузкой-загрузкой данных... ))))) сразу всё нормально пересчиталось

Хых, наверное мусора много осталось

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

Народ! Тут проблемка получилась... - короче база свернулась нормально (и итоги быстро пересчитываться стали и размер базы в 3 раза меньше стал), выгрузка в ПБ тоже прошла штатно. Проблема возникла при приёме изменений в ПБ - точнее сказать они уже 15 часов принимаются (размер файла обмена 14 мб - в нём была изменённая конфа и файл данных порядка 120 Мб) В чём может быть дело? почему так долго принимается?

какие могут быть "пути отступления"? (запасные варианты) - сеть простаивает - а это не есть хорошо!

Они тебе счас насоветуют - дбфная база в разы быстрее скульной пересчет делает.

у меня отработало всё на дбф

я когда режу базу то выгружаю из скуля в дбф обычно - так 7 лет уже делаю и все шустро работает, а в скуле это у меня сутки делать будет - нафига? когда в дбфной за ночь.

просто у тебя руки кривые...

единственное что было - после удаления доков персчёт итогов шёл почти 2 дня (перенос ТА на прежнее место), после сделал тестирование и исправление со всеми галками (в т.ч. упаковка)

и всё вроде стало ок, далее выгрузка

теперь вот почти сутки принимается...

есть предположение что и там такая же хрень с итогами - что на них повисло (у себя на копии ПБ делал локально обмен - тоже уже больше суток идёт - время последнего изменения файлов в каталоге ПБ - через 1,5-2 часа после начала приёма изменений в ПБ и с тех пор всё)

есть идеи?! )))

Кстати делал свёртку вот этой обработкой - очень удобно и быстро! Спасибо автору!!!

ЦБ и сейчас хорошо пересчитывается (сейчас проверял), что может быть с ПБ? Не слишком долго идёт обмен?

может как-то проинициировать первоначальную выгрузку?

или всё-таки подождать пока отвиснет?

что значит "проинциализировать"?

может есть способ чтобы заново выгрузить все доки на свои ПБ?

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

(добавлялся новый документ в конфиг)

(документ, которым и были введены остатки на 31.12.12)

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

а если сейчас завершить зависший обмен - переиндексировать и упаковать ПБ и снова попробовать принять изменения - ПБ не запорится?

получается в ПБ та же проблема с итогами что и в ЦБ была (в ЦБ после пометки документов на удаление - делал упаковку таблиц и потом после долгого и мучительного переноса ТА на сегодня и повторной упаковки - теперь ЦБ работает как часы)