Перевод на сиквел большой базы (25Гб). Кто то делал? Какие траблы? #109095

Всему содружеству одинесников доброго дня. Проблема: у клиента распределенная база (Центр + 8 периферийных). Размер центральной базы около 25 ГБ (на дбф) за 2,5 года. Один из файлов регистров перевалил за 2 Гб (а может просто так сложились звезды) и получился CodeBase Erore - 120 . Тестирование и исправление на таких объемах занимает около суток. Перепроведение базы - около недели если нет глюков. Обрезание базы невозможно т.к. данны из прошлых периодов нужны для возвратов. Как я понимаю переход на сиквел это выгрузка всех данных в текстовый файли и загрузка из него в сам сиквел. Потят ли выгрузка такие объемы? 25Гб в один файл загнать - тажко ИМХО. Или я не прав! Кто имеет подобный опыт - поделитесь плиз. Еще буду благодарен за любую литературу/ссылки по этому вопросу. Заранее всем Спасибо!

Максимум жал 3 гига, без проблем и со свистом. Насчет 25 - не знаю...

На какой технике?

на денди 8 бит

Кстати там чо то у 1С ограничение зипчика 2Гб, то есть если файл переноса будет больше 2Гб Конфигуратор скажет ФТОПКУ. Где то читал

Скажи еще, Spectrum ZX. :)

А что если создать на базе Вашего МДшника пустую SQL базу и дальше потабличный перенос данных DBF->соответвующая таблица SQL...не знаю возможно ли такое, но я бы попробовал, боюсь вариантов у вас не много на выбор...

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

А это вариан... Спасибо!

Куясе! 25 гигов!

Хотя нет, не получится. Ведь каждый объект ссылается на другие объекты, которых в еще может не быть в система. К слову у меня в системе около 150 документов...

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

ИМХО Надо что-то кардинальное с базой делать. На SQL ее перевести наверное можно. Но на перепроведении может лечь - закончится место на диске из-за журнала транзакций...

Должно получиться. Ведь ссылки идут по внутренним кодам, а они суть есть текст.

А если частями перепроводить? С очисткой журнала?

Значит сервант суксь  - если место кончается. Должны быть механизмы перекачки данных..Нутром чую что должны!

В Dephi есть DataPumper - там можно через ODBC перегонять. Вот только не в курсе насчет того как из DBF В принципе тоже наверное можно.

Почему лечь может? Ведь на dbf она перепроводится, да долго, да с траблами, но перепроводоися. Или этот механизм для dbf и сиквела отличаются? если я правильно понимаю, по при выгрузке по ОЛЕ надо вручную все описать... а у меня объектов конфигурации под две с половиной сотни.

Попробуй через метаданные. В Цикле бежиш по ним и xe$ачишь. Геммор правда еще то будет. Имхо попробуй перегнать напрямую, если получится. Отладь механизм на полупустой базе - пяток элементов всяких. времени займет несравненно меньше чем написание перегона через ОЛЕ, а если получится -  Джек-пот сорвешь!

Посмотри datapump из Delphi 5 - 7  - может там можно будет перегонять таблицы

К слову техника нормальная: Брендовый интеловский двухголовый сервак (Intel Server Board SE7320Sp2/2*Xeon 2.80/4 Гб/HDD 4*37 Гб (Raid)+ 2*40 Гб (UDMA))

Спрошу неосторожно. А что ето, сиквел ? Скуль имеецца в виду ?

Вот тебе и ограничение на DBF в 2 Гига. Что за база такая, что за два года на 25г уехала? Пока даже ничего придумать не могу. Гипер-маркет что ли? Сколько доков в день? Сколько позиций номенклатуры? Сколько пользователей? А когда 10-20Г было без проблем работало?

Присоединяюсь, уже серьезно. ?.

Не трать время на . Много отличий в структуре между DBF и SQL. Навскидку - строки неограниченной длины (BLOB/Memo), идентификаторы видов (текст/число), метки удаления. Только загружать всю базу или, если обломается из-за , создать пустую базу на основе MD и перенести данные какой-либо обработкой, *написанной на 1С*.

корявая небось, вот и распухла

И я вот +30 Метров в день, это круто!!! А если на SQL будешь переводить у тебя на диске 50-100Г будет?

Похоже.

не так давно тема поднималась: база в 15 гиг за 1,8 мес, таки регистр юзался неправильно, может быть тоже самое ?

2 Траблы могут возникнуть при большом размере архива выгрузки (то ли 2 то ли 4 гига - не помню). Если таки проблемы возникнут, то простейший вариант решения проблемы штатными путями (максимальная надежность) - использовать УРБД. Т.е. сделать базу распределенной, поднять на SQL периферию и заливать данные туда порциями (настраивая параметры миграции). Потом можно сделать базу нераспределённой и исходную базу прибить.

+ да интересно колво доков в день, колво строк

Ну, еще возможны известные проблемы с реквизитами типа "строка неограниченной длины". Но это уже ФАК.

Вот ведь!  Иешуа всех заинтриговал и куда-то свалил.

(all) Xe. Придется рассказывать подробно. Значится так: Документов в день около 700 (500 - центральный головная контора и 200 - филиалы). На счет корявости регистров... вроде нет. Проверяли толпой и там были спецы до которых мне расти еще лет 5-6. Самый большой файл в системе - регистр остатков (фалй движений 250М (ra4158.dbf), файл остатков - 1.8Гб (rg4128.dbf) но это копия, сейчас в боевой больше). В нем 6 измерений и 6 ресурсов. Структура системы такова, что каждой периферийной соответствует свой набор документов (в большинстве своем однотипных, хотя есть чисто торговые филиалы без бухии, а в других и торговля и бухия). В центральной никто не работает, кроме высших управленцев, которые смотрят общую отчетность, формируют цены и т.д. (Зачем так сделано? Это было до меня...)

(+33) Забыл... в документах расхода обычно строк по 15-25. Хотя бывает и больше. Возвраты так же. Приход -  бывает очень много.

А сколько занимает dh*.dbf, dt*.dbf, ra*.dbf, rg*.dbf по отдельности?

У меня нет под рукой центральной базы... перыдущие данные были для одной из периферийных. Ее размер около 5.6Гб dh: 98 Мбайт dt: 510 Мбайт ra: 1 200 Мбайт rg: 3 100 Мбайт Центральная в тех же пропорциях вероятно...

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

Попробуй удалить RG* и RA*. Выгрузить в SQL. Затем в SQL пересчет итогов. Не уверен, что прокатит.

Поделюсь опытом, полученным на прошлой работе: 1. Выгрузка базы (SQL) размером около 30 Гб проходила нормально каждую ночь примерно за 2 часа (примерно на таком же железе). При приближении базы к 40 Гб загиналась напрочь. 2. Для есть DTS (в Enterprise Manager смотри), но имхо не получится... я бы попробовал как в описано

Что значит "Выгрузка базы (SQL)"?

Не прокатит. Можно снять доки с проведения и в таком виде загрузить. >>перепроведение неделю мда...

значит что мы из SQL-й базы выгрузку делали, а у тебя dbf

+ кстати сказать, когда первый раз делали перефирийку из ЦБ размером около 30-40 Гб, то файл выгрузки создавался, а загружаться она никак не хотела... все обрывалось каждый раз в новом месте. Пришлось пользоваться способом и шаманить с подменой md-шника

"фалй движений 250М (ra4158.dbf), файл остатков - 1.8Гб (rg4128.dbf)" ----- Явная корявка в организации регистра. Как я понял этот регистр нужен для учета возвратов. Решал недавно точно такую же проблему, только в бухии (За год выросла на 5 ГБ, после закрытия стала 600 метров). Оказалось, что проще сделать регистр оборотов и по нужному товару вытаскивать обороты. Для того, чтобы учесть уже существующие возвраты можно делать движения со знаком - (сторно).

Кстати, обрезку делать все равно придется, т.к. практика показалачто больше 50 Гб даже SQL не потянет :( Для возвратов можно оставить пердыдущий год-полтора (имхо должно хватить). Ну и структуру еще раз посмотреть, возможно имеет смысл.

Т.е. предлагаешь переделать. А потом перпроводить неделю и посмотреть, что получится? Тем не менее дисбаланс в активной рабочей базе очень большой. А как насчет закрытия ресурсов по измерениям? Может сделаешь простой документ, который на конец каждого месяца сводит остатки всем регистрам остатков в 0. Затем переносишь базу, документы удаляешь. Последовательность ставишь как была до ввода сих документов (ничего другого не меняли), и вперед.

Вторая часть к

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

По поводу промежуточных документов на конец месяца - ЭТО МЫСЛЬ. Как средство для переноса на SQL - отлично. Но вообще нужно лечить эту проблему

Кстати, а если откатить ТА на начало базы, по идее промежуточные итоги рассчитаны не будут ?

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

1. создать структуру БД (пустую)    2. Import and Export Data OlE? не загнется OLE? думаю што не исключено,опасно а вот Imort and Export Data и еще,есть смешной, но может быть реальный вариант. Прсоединить таблицы DBF в Access (не создать!) и Сервис->Мастер Преобразования ...SQL у меня получалось,правда БД была 1.5 Гб

ИМХО не получится. Придется менять алгоритмы др. документов. Ведь если какой то документ в следующем месяце потребует остатки за предыдущий месяц то будет глына! А без перепроведения базы этот способ ничего не даст. И к тому же я уменьшу остатки, но увеличу обороты...

А переделывать придется, а то очень скоро будет 100 гиг

Юкон дело говорит. Нужны временные документы, только для переноса. Они будут заводится в конец каждого месяца и списывать все остатки в 0. После переноса просто удали их.

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

Может глупость скажу, но... как такое сделать без перепроведения? Я этого не представляю! Остатки двигаются документами, я создаю некий док на конец месяца который это дело закрывает в 0, а движения доков та останутся, файлы не уменьшатся! у меня нет ни техники соответствующей ни базы на руках... в том то и проблема. Базу забрать просто, а вот пока будет происходить выгрузка-загрузка-настройка народ работать не может... хочется сначало все для себя прояснить, выбрать путь решения, потестить на меньших объемах, а потом в бой и с песней!!!

Похоже тупим мы и Юконом. Ведь при выгрузке итоги скорее всего не выгружаются. А ты кстати, пробовал делать выгрузку ? Что конфигуратор говорит ?

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

Во общем тебе нужно попробовать сделать выгрузку на реальных данных. Без этого смысла разговаривать нет. Запросто может выгрузиться вообще без проблем.

Отож... чую выходных у кого-то из нас не будет ;-))

Удивил. У меня субботы с 8.00 до 17.00 точно не будет :-) Так что случ чего - встречаемся тут. Ты фикси ?

2 Иешуа: Как база бекапится? Выгрузку данных через "Выгрузить данные" делали? Если да - то посмотри на размер файла 1Cv77.dat в полученном архиве zip. Потолок для него 2 гига. Если этот потолок не достигнут - просто выгрузить таким методом из DBF и загрузить на SQL и все.

одно слово... точне три... бля..бля... бля..