1C, DBF версия, > 2 Gb база, пересчет итогов #17279

Вопрос для тех кто реально работал на больших объемах 1C+DBF. Текущее состояние: база работает, однако, из-за аппаратного сбоя неделю назад слетели остатки на 01.04. Таким образом, по некоторым регистрам пошли неверные остатки. Пересчет итогов из конфигуратора не помогает, в том смысле что итоги не успеваються пересчитываться за _ДВОЕ_ суток (выходные), на более большой промежуток времени поставлять пересчет нет возможности - необходима работа базы. Внимание вопрос: что можно СЕЙЧАС сделать для устранения не поладки. Что НАДО сделать в будущем в принципе понятно. Спасибо.

DBF > 1 Gb уже опасен как таковой, надо ставить СКЛ. Не успевают за _ДВОЕ СУТОК_ - тряси бабло на более быстрый проц и больше памяти! СЕЙЧАС МОЖНО ПРЕДУПРЕДИТЬ, что правильность остатков не гарантирована!

Делаешь копию,пересчитываешь итоги,затем синхронизируешь её с рабочей базой

за $100 000 можно купить нормальный сервак с 96 процессорами. (с) Витаэль --- 13 постов после очередного бана. Личный рекорд -35 постов.

Да брось, опасен...

Реальный совет, лучше в этой ситуации не найти (без смены мощностей и установки сиквеля). - советую так и сделать.

to : я уже и сам пришел к такому же выводу, посоветуйте обработки для синхронизации на моем объеме. to все остальные: спасибо за поддержку :/

Скажи пжалста, что за система у тебя (хард и софт)?

CPU: 2 х Xeon 2.7Ghz, 2 x 1GB DDR PC2100, HDD: 2 x 36GB Seageate 10000prm Софт: MS Server 2000, MS Терминал Сервер.

1С какая (конфа, билд)?

1C SQL версия 18 релиз

Конфа: Типовая ТиС с доработками

Если идет набивка в реалтайме, то можно будет воспользоваться переносом (взять с ХИППО) ... Если уж было изменение старых данных .. хм, то можно опять переносом с заменой с определенного периода

На Сейчас, просить еще пару суток. Была база 1 ГБ, правда компы были Р166, но период за год они считали, мене суток. Документов было порадка 200 в день. поэтому проводил не все документы, а только те которые влияют на остатки товара.

перепроведение документов не помогает, так как перекосячились остатки на начало 01.04, и никакое перепроведение доков тутни при чем, к тому же у нас в базе за день появляется порядка 2500 разных документов. Пара суток заткнет только брешь (уже переписаны несколько отчетов с учетом корячества, правда время их формирования оставляет желать лучшего), а сама суть останется, нужно радикальное решение

набивка идет в реале и немного задним числом, но задним числом можно и пренебречь или решить как ты посоветовал. осталось выбрать обработку переноса, что бы смогла за разумное время сделать загрузку выгрузку. Если не трудно посоветуйте что-нить реальное. Под рукой только тоhvjpyst типовые с xml'ем :(

Воспользуйся конфой "Конвертация данных".Возьми типовые правила обмена и доработай под свою конфу.Придется повозиться, но ИМХО еще не раз пригодится

Товарищ... 18 релиз в части запросов по регистрам на дбфе криво работает...

спасибо, просветил. А то я думал почему это у меня отчеты покривому формируются (это еще было до косячества, и не есть тема ветки) и тем не менее другого релиза нема. Решать проблему необходимо на тех ресурсах что есть.

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

просто боюсь потерять время поэтому и переспрашиваю, для _МОЕГО_ объема эта конфа подойдет? Т.е. не будет так что загрузка-выгрузка займет столько же времени сколько и пересчет итогов?

ты читал что я писа в ? твоим методом за неполных 9 месяцев база не успела сработать за _17_ часов :( Вариант по частям отпадает, потому как на утро (в 9:00) начинается выписка и все регламентные работы прекращаются А еще у нас иногда ночью свет выключают! но это так, крик души :)

Я пользовался ExImDocs, она есть на // А движок давно пора сменить

Других вариантов у тебя нет. Остатки по другому ты не восстановишь. Я это уже проходил.

mota Ты случайно не таблетки продаешь?

еду :)

Почти коллега

Однако хочу попробовать по методу

Есть обработки по фоновому перепроведению документов и  выправления последовательностей документов. Пробовал на 1Gb базе в DBF работающей в SQL рапределял нагрузку по времени и пользователя даже и не чувствовали что проходит этот процесс.. весьма удобно..

восстановление последовательности и пересчет итогов не одно и тоже. В моем случае как раз последовательность более менее восстановлена а итоги корявые :( з.ы. сам пользуюсь своей разработкой "Проводник" жутко замечательная весчь! :)

Может стоит под такое дело проапгрейдить сервер? Поставить более быструю дисковую систему?

имхо дальнейшее увеличение по стоимости несоизмеримо с увеличением производительности

При таком документообороте(>2000) нагрузка на дисковую подсистему в любом случае должна быть велика... И сервер получается не сбалансированый. . Попроси у кого-нибудь хороший RAID контроллер и 4-е диска, поставь 10 RAID. Загрузи туда копию базы и попробуй пересчитать итоги.

хм, возьму на заметку твои замечания

Сервер апгрейд это обязательно по такому поводу.. А может просто реальнее сделать расчет по документам и просто переустановить(скорректировать) значения регистров? Хотя глюки с движениями по отчетами гарантирую..

хотелось бы исправить текущее положение, а не плодить новые косяки...

Ну брат и то тебе не так и эдок не эдок.. Ну тогда ручками сиди и все документы проводи... так глюков не будет.. :))

На самом деле всем спасибо за идеи, все они имеют место и по своему верны, но мне нужно действенное для _МЕНЯ_ решение, а по сему я и отбрасываю, то что считаю не уместным в моем положении. Кстати по "поводу проведение документов ручками" - это не исправить положение, если не трогать ТА, а ТА трогать низя, потому что в базе пользователи копашаца :)

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

Ой чувствую нескоро они будут.. синхронизация???? интересно.. почти тоже самое что и проведение тока ТА не двигная... интересно что получится.. сообщай..

фишка не в синхронизации а в пересчете итогов _НА КОПИИ_ и последующей синхронизации а по поводу будущего: закинул удочку на смену релиза и установку RAID-массива

"...из-за аппаратного сбоя неделю назад слетели остатки на 01.04. Таким образом, по некоторым регистрам пошли неверные остатки..." - сам этот факт говорит о том, что дело нечисто, т.е. какие-то действия с базой явно некорректны. Если потеря итогов последнего периода - вполне реально, то потеря итогов годичной давности - это результат либо постоянных изменений в том периоде (что странно), либо - откровенно хакерских действий с DBF. На будущее стоит уделить внимание этому моменту. RAID для такой базы - практически неизбежно необходим (может дать увеличение производительности в 2 раза). "...по некоторым регистрам пошли неверные остатки..." - так ведь можно отдельно пересчитать эти регистры, причём каждый по-отдельности - это будет гораздо быстрее всеобщего пересчёта итогов - в твоём случае, ИМХО, лучший выход. Ко всему прочему есть ещё и такой метод: если достоверность движений регистров не подвергается сомнению - можно взять таблицы движений, и на их основе САМОМУ построить таблицы итогов. Для этого можно просто свернуть таблицы каким-нибудь внешним средством, например VFP. Это, конечно, экстремально, но по скорости может побить все рекорды.

1 - это было в результате действий с базой в том периоде, почему - это другой вопрос 2 - а как пересчитать итоги по конкретным регистрам? 3 - неприемлемо, т.к. немного не владею квалификацией :(

1) Переносишь куда-нибудь из базы таблицы RA... и RG... всех регистров, кроме того, какой нужно пересчитать 2) Входишь монопольно - эти таблицы создаются пустые 3) Делаешь пересчёт итогов 4) Возвращаешь обратно таблицы, которые были убраны => один регистр пересчитан. Можно потом поработать в базе день, а на другую ночь повторить то же с другим регистром - большой плюс, так называемый "частичный пересчёт".

А зачем пересчитывать сразу все итоги? Периодичность итогов месяц? Вот и перепроводи по одному месяцу! Один перепровел, заархивировался - перепроводи следующий! Если за выходные успеваешь перепровести не один месяц, а два или три - еще лучше. А вообще - на будущее - заархивируй по мере перепроведения регистры за каждый месяц, в будущем могут пригодиться. Если знаешь структуру регистров в DBF (а если не знаешь - посмотри, ничего сложного там нет) - понимаешь, что можно хранить "правильные" движения за каждый отдельно взятый месяц. А потом складывать как из кубиков то, что тебе надо. Причем при известной сноровке это можно делать даже Экселем ;) Или FoxPro, или твоим любимым DBF-Viewer'ом (если есть любимый). Итоги тоже можно хранить помесячно, а можно восстанавливать движением ТА "назад-вперед". Индексы же хранить "по частям" не получится, но они автоматически восстанавливаются при монопольном запуске.

Я бы посоветовал пересчитать базу на резервном компьютере, а затем выправить остатки исправительным документом, который цепляет правильные остатки, например, из текстовичка, сверяет, и если надо, корректирует проводкой в + или в -. А вообще надо или делать частые свертки базы (в новых релизах ТиС это встроено в конфу), либо переходить на SQL. Там все с этим гораздо проще и спокойнее.

: База 2 гектара! Да на таком железе как в в СКЛ класть надо!.. ЗЫ: только - да, не 18-й релиз!.. Сам как-то искал вместо него замену (у меня, правда, в СКЛ-данных неправильно разворот в бухитогах считало). 21-й пробуй (я поставил 23-й, но он, сцука, как оказалось в ДБФ и на СКЛ по разному бухзапросы выполняет - на СКЛ при запросе оборотов и фильтам по счетам и корсчетам выдает обороты не между теми счетами, которые в фильтре по счетам, и теми, что в фильтре по корсчетам, а обороты между каждыми двумя из проставленных в фильтры счетами - как будто я и в фильтре по счетам и в фильтре по корсчетам перечислил все счета из обоих фильтров... а в ДБФ-е - на локальной девелоп-базе, считал все правильно... ох я и намучился вылавливать!..)

Большая база? Ернда, Бывает хуже иногда... Один же Эс такая весчь И глюков в ней не перечесть.

Так что простой "тупорылый" перебор (с каким-нибудь одним фильтром) рулит. Жалко, что 1С не применяет автоматических тестов. Ну что за контора! Знакомые франчи все время говорят про такие несоответствия.

47,49 - что я глюков на бухзапросах не заметил.

Pit кажется говорил что у него есть образцы глюков, или он знает где их взять.

23 у меня вылетал на отчетности, поставил 23 - ОК.

23 у меня вылетал <=> 21 у меня вылетал

седня буду пробывать методом , в принципе необходимо пересчитать итоги только по трем регистрам. Только вопрос: насколько надежны такие манипуляции? Не накосячит ли 1Сина еще что-нить не имея все регистры при пересчете? помесячный пересчет итогов не возможен потому что для пересчета итогов документы надо перепроводить со сдвигом ТА, но при этом на начало рабочего дня ТА должна равняться РабочаяДата з.ы. вариант отработал на отлично, но непосредственный начальник не дал окончательное добро на его реализацию :( эпопея продолжается...

А чем он мотивировал свое не одобрение этого варианта ?

своей некомпетентностью, это мое мнение конечно. А вообще, не верит он что синхронизация прошла успешно, вот сидит ща все подокументно сверяет две копии, причем обе по любому уже канули в лето ибо неактуальны. Наверное на свой страх и риск седня сам все буду исправлять.

можно только посочувствовать тебе

1С не накосячит. Пересчитываются все регистры, просто в обнулённых регистрах нечего пересчитывать. Вполне понятны его опасения. Лично я бы не стал рисковать с такой синхронизацией. Либо тщательно её проработал бы, прежде чем...

как раз по поводу порегистрового пересчета у него еще больше скептиса чем по синхронизации :) к тому же по времени вариант с синхронизацией пройдет быстрее p.s. седня в ночь поставлю твой вариант, правда на другой машине, так ради запасного плана "Ы" :)

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

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

Ни фига там не описано. Мельком упоминается ExImDocs, но в описании этой вещи ни слова о регистрах.

хм, в том то и дело что там пересчитываются все регистры методом "пересчет итогов" из конфигуратора на копии БД, и затем синхронизируются данные с рабочей БД. Ни про какую "синхронизацию регистров" там не говориться, и не говорилось, видно мы не поняли друг друга

Для непонятливых ... 1. Переносятся недостающие доки, котрые забили во время востановления итогов 2. Они проводятся Вот и все ... Ньюанс с измененными доками - его можно обойти путем переноса всех доков за определенный период (неделя) с полной их заменой ... Вот и все помидоры.

именно такой вариант понравился всем

Извини, но если слетели итоги регистров (то, что слетели остатки, как раз указывает на это), то никакие перепроведения документов делу не помогут. Если в итогах, скажем, 800 штук, а должно быть 0, т.к. приход=800 и расход=800, то если ты перепроведёшь расход, то остаток сперва возрастёт на 800 (поскольку отменяется расходное движение на 800 штук), а потом уменьшится на 800 (поскольку выполняется расходное движение на 800 штук) - и всё останется на своих местах. При перепроведении итоги не пересчитываются, а корректируются в рамках выполняемых движений, поэтому сколько документы не перепроводи, а косяки в итогах будут болтаться туда-сюда. И выход тут один - пересчёт итогов. Еще можно, как уже говорили, откатить ТА назад (на тот месяц, где итоги ещё верные). В этом случае все итоги после ТА будут убиты, а при передвижении ТА вперёд - будут рассчитаны по принципу (итоги текущего месяца=итоги прошлого месяца+движения за текущий месяц). ... А вот перепроведение документов будет неизбежно, если помимо итогов регистров оказались побиты сами движения. Но тут всё гораздо прозаичнее.

Это ты к чему демагогию развел ? Еще раз, с самого начала: 1. Делаем копию рабочей базы, скажем в пятницу в конце рабочего дня 2. Запускаем копию на перерасчет итогов 3. Когда заканчивается (например во вторник), в конце рабочего дня мы переносим из рабочий базы в нашу копию (в которой уже итоги перерасчитаны) документы которые были добавлены или изменены. 4. Перепроводим их 5. Делаем соответсвующие проверки 6. Копию делаем рабочей Что еще не понятного ?

Это уже не синхронизация. Это называется - загрузка новых данных. И решение это, мягко скажем - близорукое. Помимо документов придётся переносить ещё и элементы справочников со всей периодикой, возможно, константы отслеживать, короче - полное сравнение двух баз на несовпадения. Если умеючи, то можно это реализовать, хотя, ИМХО, через УРБД это можно вообще сделать махом.

Можно, но не нужно ... Потом прейдется базу ковырять ... из переферийной делать нераспределённую.

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

На сколько я знаю - то ошибаешься

и снова здравствуйте %) Для сочувствующих и интересующихся: Итак ошибка описанная в успешно исправлена, методом понятным всем , кроме Fеникс'a (без обид). Вариант оказался очень удачным решением, к сожалению запоздавшим. Резюме: если, не дай бог, случица , то самое безгеморное, но продолжительное по времени решение - , как запасной рабочий и более быстрый вариант - . Всем спасибо, за поддержку. хеппи энд.

mota, а что базу не обрезаешь?

до сих пор такой необходимости не было: время проведения и формирования отчетов незначительное, к тому же нужна история за прошлые годы (только не спрашивайте меня кому и зачем - сам голову ломаю :) К тому же, когда полгода назад я поднял вопрос о размере базы и принятия мер, ответ был примерно таким: "а зачем? все и так работает, вот начнеца новый год тогда видно будет...". Сбой произошел во время аппаратного сбоя (выключили свет на продолжительное время) во время ночного восстановления последовательности за 04.04. Тут то и вспомнили разговор полугодовой давности... В связи этих событий буду выходить с след. предложением: 1. Смена релиза на 23 и > 2. Свертка базы с сохранением истории в несколько периодов. 3. Развертывание сиквела и перевод работы БД на него 4. установка на рабочий сервер RAID-массива

Сильно! А калькуляцию расходов сделал? Речь подготовил? :)

+ Не забудь бесперебойник включить в список

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

Бесперебойник вряд ли поможет, если тока не будет продолжительное время, которое попадет на восстановление последовательности, то ничего не поможет. Если только какой-нибудь генератор автономный, но это у же из области фантастики :) А так бэкап рулит

Вот кстати по поводу безперебойника... Наш UPSник, который сейчас установлен на серваке держит отсилы полчаса (это вполне приемлемо в дневное время, можно все корректно завершить, и практически не приемлемо ночью, когда идут регламентные работы на серваке). А свет у нас выключают иногда в самый не подходищий момент, и частенько на 31 минуту :) Так что наверное 5-тым пунктом пойдет, резервный дизельный генератор :) з.ы. кстати пока писал пост, выключали свет на 5 минут :)

Mota, ты только не откладывай в долгий ящик предложения из ,пока руководство в трансе от случившегося бери их тепленькими голыми руками :)

Моя база в dbf-формате тянет на 2.27 Г, пересчет итогов длится часов 9-10. Железо: 2-Xeon 2.4ГГЦ 1Г оперативной.

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

Не знаю, моей базы объем 2.6, железо примерно такое же, пересчет итогов за неполных 2 года занимает больше 40 часов, см.

Мдя... Посмотрел я ExImDocs. Реализовано как раз то, что в . Хоть и кривовато, но подойдёт для конфигураций с прямой логикой. А вот если в модулях документов используется гибкая логика, то с таким переносом можно влететь по полной. Если эти издержки устраивают, то можно использовать, но при этом надо понимать, что точной копии данных не будет - 100%. Про перекрёстные ссылки вообще молчу. А дизельный генератор, кстати, это - вполне реально. На практике его возможно завести за 5-10 минут. Так что вполне оправдывает себя.

для справки поясни, а что подразумеваеца под "гибкой логикой"?

"Гибкая логика" - это когда действия при проведении зависят не только от содержимого документа, но и от значения констант, наличия/отсутствия элементов в справочниках, наличия/отсутствия других документов, значений периодических реквизитов, остатков в конце концов и т.д. Т.е. при гибкой логике один и тот же документ будет выполнять разные действия при проведении, в зависимости от других данных на момент проведения.

хм, по моему все более менее рабочие конфигурации обладают т.н. "гибкой логикой". Вот только имхо перенапрягать излишней "гибкостью" проведение документа (не регламентного) нецелесообразно.

Почему бы не воспользоваться универсальной выгрузкой/загрузкой СDexport.ert/CDimport.ert?

+88 если базы по структуре близнецы, то xml-правила обмена не особо хлопотно наваять

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