v7: ТИС Файл регистра партий приближается к 2 ГБ, какие риски могут быть ? #803324

ТИС Файловая база! Файл регистра партий приближается к 2 ГБ, какие риски могут быть ? Свертку делать нужно? Но там тогда и периферийки надо сворачивать. Тоже вопрос. Но свертка особо ничего и не даст, слишком быстро растет документооборот, а 5 лет мне желательно держать в базе. У меня у ряда товаров гарантия как раз 5 лет. Сейчас база начинается с 01.01.2012. Вроде все длл-ки для поддержки свыше 1 ГБ у меня стоят. И пока ничего не валится. Есть что-нибудь для поддержки свыше dbf-файлов свыше 2 ГБ? Со скулем засада - сервер win 2008 R2. 1С 7.7 инсталлирована через 64-разрядный инсталлятор, лицензионная с ключом. Ставить скулевую версию 1С 7.7 32-разрядную на win 2008 - тоже проблема, я потому и искал в свое время этот инсталлятор 64-разрядный. Solution 5 и solution 6 у меня установлены в BIN. Лучше бы всего если бы была поддержка файлов dbf до 4 ГБ. Тогда можно 5 лет оставлять и свертывать. Или все-таки переходить на скуль как-то???

1с 77 не нужно инсталлировать

Но вот я-таки инсталлировал. И работает давно и без проблем. Но вот файл в 2 ГБ меня сильно беспокоят. Остальное не так критично

Если тебя сдерживает тольк это...

Есть решения какие-то чтобы поддерживался DBF файл свыше 2 ГБ ???

нет и не было

размер RA и RG этого регистра озвучь, для начала

RA 411166, RG 1700831

Вот что и как лучше делать? Вроде когда-то читал что есть варианты с поддержкой dbf до 4 ГБ. Но это было очень давно и проблемы у меня такой еще не было даже близко

ну вот и ответ, собственна - незакрытый регистр. RG при таком RA Должен быть максимум, 1700 весить

на самом деле, если таблица оборотов по регистру партий превысит 2 гб, то платформа остановится даже она если используется в какой-то любой версии с MSSQL

ЕПРСТ. Так он и весит 1700. Регистр партий вообще-то закрывается у меня нормально. Никогда не бывает чтоб партии не распределялись при проведении документов. Как это проверить? RG это файл движений регистра - их же очень много. А RA файл остатков регистра. Он же не такой большой. Или у меня в мозгах перепуталось что-то?

по стандарту дбф, файло в этом формате не может быть больше 2 гигов, априори

? он у тебя весит 1.7 гига, а должен весить 17 метров. Разницу, чуешь ?

И он у тебя, не закрыт, от слова совсем.

Что можно очень срочно сделать? Если свертывать, то что делать с периферийками? Это же их заново пересоздавать.

Ты тащишь незакрытые итоги из периода в период, табличка пухнет, результат - в

ЕПРСТ. Просто ничего не понимаю. Как может регистр движений весить 17 МБ???

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

Не движений, а итогов

При файле движений в 400метров, файло итогов должно весить метров 20, при твоей базе.

а не 1.7 гига

Так файл итогов весит 411 МБ, а файл движений 1,7 ГБ

RG-это промежуточные ИТОГИ регистра, RA - это табличка движений

прошу прощения. Это я от волнения. RA весит 1.7 ГБ, а RG 411 МБ

что такое "незакрытый" регистр, рисовал как-то табличку одному неучу, для наглядности. Слева - незакрытый регистр, справа - закрытый. Слева, незакрывается из-за введения измерения ТекДок Наглядно показано, как будут копиться лишние итоги в RG из месяца в месяц (если период хранения останков - месяц)

тогда, только свёртка. Максимум, вырезать лишние измерения + обрезать длину числовых полей. Но, это не намного уменьшит табличку движений.

Либо, переход  в скуль. Но, твоя база при таком размере, туда просто так не выгрузиться.

К примеру, если у тебя ТиС и нет розницы, можно смело выкинуть ЦенаПрод, если учет для одной фирмы - то фирму, если один склад - то выкинуть мол и т.д

Будет ли 1С 7.7 работать на скуле на 2008 винде? Как-то все это очень и очень стремно. Какие измерения можно выпилить и до скольки можно можно уменьшить числовые поля? И что при этом будет с обменом УРБД. Это же огроменный файл получится.

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

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

а че тебе до обмена урбд ? Порежешь аналогично в перефирийках и без обменов.

Обмениваешься со всеми ПБ, стопоришь обмен. Делаешь не руками реструктуризацию регистра, пересчитываешь табличку итогов. Очищаешь табличку изменений. Работаешь дальше. В ПБ делаешь аналогично.

Что значит не руками? Ведь если я реструктурирую регистр в конфигураторе, то потом же вре равно придется делать обмен УРБД. Боюсь что файл обмена будет слишком большим. Или я просто туплю?

ты пропустил фразу в - "Очищаешь табличку изменений".

Как ее очистить? И как тогда поменять конфигуратор на периферийках. Ведь он же меняется только через ЦБ или я просто чего-не знаю

1Supdts сохранить а потом восстановить? Но конфигуратор же нельзя менять на периферийках иначе как через обмен с центральной базой?

Я делаю так - подменяю файл обмена на пустой. Прокатывает.

да уж..

если че, всё можно.

А как? Ситуация просто угрожающая уже

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

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

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

уменьшай. Просто в ПБ будет один мд, в цб - чутка другой.

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

потом тоже самое делаешь в пб.

+ нулевые итоги нужно выкинуть из таблички итогов. Чебур тут выкладывал на нимфостарте готовое изделие для этого. Хоть табличка итогов поменьше будет

табличка итогов - будет существенно поменьше.

как вариант: 1. смотришь какие партии = 0. то есть пришли и ушли. и просто прямым запросом удаляешь в движениях и итогах регистров записи по этой партии. !!_Документы остаются_!!. база существенно худеет.

на ИСе искать "Шиышки для мартышки"

А разве пересчет итогов не удаляет нулевые?

Да когда-то была она у меня. Пробовал - эффекта не было. Может не так пробовал ??? Как хоть она называлась - ерт-шка? Попробую еще раз ее, но опять же как обмен тогда пойдет?

полный пересчет надо будет делать, ну и паковать потом. Можно сделать, если пересчитывать только один регистр при этом, как вариант и , предварительно грохнув табличку итогов.

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

Ну и остатки же все сразу летят..

за прошлые периоды.

согласен. а кто говорил что будет легко... . но тут смотрим и делаем как в типовой есть реквизит ФлагСвертки - используем его, или свой добавляем . для "почищенных" доков выставляем "ФлагЗапретдвижений=1", в процедуре проведения - смотрим флаг, если взведен то просто возврат и все... . у меня так сделано, и норм...

Опять же партионку можно сильно ужать если переделать с ФиФо на среднюю (но не всегда даст эффект) . тогда в регистре партий в движениях и итогах проводим "реформацию" по подмене и "свертке" записей... и получаем профит

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

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

база должна за любой период существования показывать верные на 100% данные. Тогда уж, лучше свёртка

То есть вариант один: свертка и дальнейший переход на скуль. Только как будет скулевая 1С-ка работать на 2008 сервере? Не будет ли проблем?

У меня RA328 растет примерно на 1 МБ в день

если свёртка, то скуль не нужен.

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

Но я сверну, база будет с 01.01.2013. Мне только год разрешают свернуть

Скулевая 1С прекрасно работает на Win 2008 с SQL 200-2008. Конечно нужны некоторые действия для этого. 1. SQL 2000 - замена пары файлов, 1С штатная. 2. SQL 2008, ставится стандартно, 1С секретный релиз. Все это работает более чем стабильно. В любом случае для выгрузки в SQL использовать патч ромикса.

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

согласен. подходить надо взвешенно. в зависимости от ситуации.

Снеговик конечно хорошо, но как из 7-ки Все наши доработки перенести в снеговик - сложный вопрос.

почти всё переносится без проблем

В любом случае для выгрузки в SQL использовать патч ромикса. Не работает он под 64-разрядной виндой. Не нашел работающий вариант для этого

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

то есть, если что - на возмездной основе тебя можно будет привлечь на проект перехода на УТ?

Не справится. Там архив выгрузки больше 2 ГБ. Проверял как-то

не справится, упрётся в размер файла. Ну и по времени..будет доооолго

блин копирни базу на офисную машину и там сделай

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

перенести можно прямым запросом, но, т.к структура чутка разная, придётся попотеть над их созданием. типа date time перенести в date_time_iddoc еще и в нужном формате

Да выгрузку копирну без проблем.

Я делал несколько месяцев назад, могу поискать. На 2008 х64 все работало.

Если не трудно - поищи пожалуйста. почта моя tgu82@yandex.ru. Я правда не знаю можно ли в посте почту указывать по правилам форума

Улетело.

это ты про что?

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

почти всё можно перенести один в один, только с доками повозиться.

ээээ.. нафейхоа? в сложных ситуациях?

Рабочий вариант выгрузки любого размера сейчас от Альфа с внешним архиватором.

в смыслe?

Альфавский configspy у меня с ним 8ГБ файл выгрузки проходил.

Builder Пожалуйста пришли еще раз. Случайно удалил письмо а в удаленных оно не сохранилось. Почта tgu82@yandex.ru

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

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

если любишь риск - вот вариант: я пробовал - работает.

он намекает на временные таблицы, которые создаются для запросов и прочего)))