v7: Размер базы ДБФ максимальный #694221

Доброго времени суток профессионалы и пользователи! Система ТИС переписанная работает по УРБД. 3 базы(сейчас станет 5). ЦБ в себя все получает + ведет выписки по банку + бухпроводки(минимал). 3-5 баз ПБ в ней создаются документы складские,реализации + касса(чтоб склады друг к другу не лазили). ЦБ достигла показателя 2,54 гб за 1 год. Максимальный файл ДБФ 455 мб. НА этот год скорость роста увеличиться. 1. Вопрос какие максимальные значения возможны для ДБФ-баз. 2. И как правильнее действовать переходить на Скуль или ДБФ каждый год сворачивать? 3. Сейчас говорят о переходе на 8-ку УТ. Какая там БД испоьзуется и если делать, какую БД использовать? Заранее спасибо, думаю тема обсуждалась не раз. Но мне хочется понять актуальную ситуацию особенно по 8-ке....

Гиг для файла - безопасный лимит. Два - предельный.

мелкая базенка.

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

только сразу считай если на 8-ку переходить - сервер 1С, сервер MSSQL (бесплатный постгрес у нас был - никому не посоветую)

ну из опыта - на хорошем сервере ДБФ вполне себе живет до 6-8 гб. Конечно переиндексация имеет место быть - но в общем жить можно. нужно только следить за отдельными файлами - как уже писалось - гиг и больше это уже не есть хорошо. Кроме того регулярная дефрагментация тоже не лишней будет. если база за год не достигает предельного размера - лучше все же сворачиваться или обрезаться. Перегруз в СКЛ - гарантированные тормоза раза в 3-4 все станет медленнее. СКЛ - это последний вариант - если база достигла предельного размера - а разбивать год на части не хочется. Будет тупить, но зато не будет падать. Есть правда подводный камень - для перехода на СКЛ нужно следить за файлом выгрузки - если он превысит 2 Гб - то стнадартными средствами перейти на СКЛ не получится. Есть правда обходные решения позволяющие выгрузить базу когда файл выгрузки больше 2 Гб, но лучше не рисковать, да и если файл выгрузки достигает 2 гб - то это очень большой ДБФ.

Только не файловый снеговик! Ставьте SQL, будет надежность лучше и администрировать лучше. Резать не всегда удобно (и нужно).

в сиквеле все нормально работает.

А я за дбф и резать каждый год (безопасность и все такое) А инфу сливать в 8-ку на скуле где уже и смотреть аналитику за последние 20 лет

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

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

надо просто "доработать напильником"©.

в продолжение темы. Сейчас нужно было делать перепроводку центральной базы. ГП восстановить и пере провести предыдущий период. А именно 04/2013. НА проводку 10 дней ушло 5 часов. С чем может быть связано. На копии запустил ТИИ, но это минимум часов на 12.... Что скажите? Может свернуть началом года. Из этой документы с 01/01/14 по сг перенести в новую базу, это реально?

+ на сервер терминалов не винить. Там железо мать не горбюй. Максимальная нагрузка в монопольном режиме от 1С 25%.

Проводить со сдвигом ТА или штатной фичей

В 8-ке СКД-ные отчеты прикольные

штатной!

К тому же RLS, проще ограничить отчеты по дате или по какому то параметру

8-ка в принципе удобнее. Мы из ТИС переливаем данные для работы бухии в 8-ку Бухию... Просто стандартную УТ придется так допиливать под наши процессы...

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

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

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

правда мы это делаем каждые 2 недели

регистр заявки самое больное место для ТИСа? А как со связками с документом реализацией?

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

у меня проще 1 заявка = 1 реализация! Я и задаюсь вопросом почему регистр такой большой. Я думал что реализация должен быть больше!

ну у меня 95% это доставки, и цикличность 2-3 раза в неделю, так что менеджер обычно пару дней "принимает" заявку добиваю в нею то что пришло или что клиент дополнительно заказал, поэтому чтобы задом не правили  вот и пришлось вводить систему "сторно" т.е. заявку провели и редактировать нельзя, а для изменения вводим на основании она отсторнирует старые записи и проведёт текущим числом новые

Ну так приход-расход однако записывается в заявки, резервы?

Ну да. Наверное можно. Только когда лет 5 назад вопрос задали столичным спецам занимающимся как раз таким допилом и они обозначили ценник 7-значный с негарантированным результатом - то как то желание у заказчика пропало. Тем более тормоза хоть и заметные - но поскольку все работает - то тормоза можно и потерпеть.

резервирование не используем. В качестве заявки идет документ "Неподтвержденная заявка".

Это из МагкойТочки? да, они цены ломят огого... Я сам допилил. 130 000 документов в месяц сейчас держит. Правда, нашел узкое место совершенно в другом - у меня один юзверь создает 15% нагрузки системы (из 85!). ну и проблема 85+ пользователей осталась непобежденной... по-идее, если заявка не полностью закрывается реализацией - (например, граммовка весового товара), то в штатной реализации регистр не закрывается. Или если резерв по одной фирме, отгрузка по другой....

и как решать проблему не закрытого регистра? Для нас вариант не полной отгрузки заявки постоянная ситуация.

самое больное место в ТиСе - пользователи и кривые руки автоматизаторов. я не претендую на уровень Левши, но когда вижу RG файл 1.7 гига и при этом RA-файл 280 мб, который называется УчетКредита - то только профсолидарность спасает меня... . а в реализациях тупо подчищаем и перезаписываем без проведения

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

заявка не полностью закрывается реализацией - (например, граммовка весового товара), то в штатной реализации регистр не закрывается. . исправляется добавлением одного опенатора в нужное место, типа чтото = 1; //вот таким простым оператором. и реализация будет полностью закрывать заявку

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

"ЦБ достигла показателя 2,54 гб за 1 год. Максимальный файл ДБФ 455 мб." - Это детские размеры. Если плохо работает, то значит, что либо железо слабое, либо структура базы неправильная.

как-как... закрывать регистр... прочитай, что такое закрытие регистра, и дописывай "типовую". не всегда. ну и этот вариант не единственный.

2.35, это ты размер каталога БД нам привел? Тогда не дрейф, мала твоя поделка :) Самое страшное, это какой либо файлик DBF до 2 Гб :)

для немонопольной работы - 1 гиг. а у него один файлис, считай, пол-гига... он "готовит сани летом", что правильно

Ха... а ты поинтересуйся, за какой срок у него пол гига файлик вырос :)

+ Ежегодная свертка БД спасет отца демократии :)

типа за год. значит, еще год может протянуть (хотя если  RG, то не протянет.)

За год?... Им бы уже на SQL переходить :) И не волнует...

дорого, и смысла не имеет на таких копеечных объемах.. дешевле резать.

1 Год, и уже пол гига? 2 года и гиг... 3 года ... её колбасит лихорадочно с крахом итогов :) 4 года и БД Отдыхает :)

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

Насколько я понимаю то это макс размеры ЦБ? Вообще если есть УРБД то ЦБ лучше держать в скуле. На то есть много причин. И лучше в ней неработать, держите ее тупо для обмена с другими базами. Приведите размеры ДБФ ПБ, а также количество пользователей. Тогда можно будет сказать что делать с ПБ. А вы уверены что регистр у вас незакрывается? Если это так то пните программиста и пусть он решит вопрос. Собственно нерешаемых вопросов небывает.

Тут наткнулся на засаду с реализацией розницей и пко введенном на основании этой реализации. Если коротко, то пко по покупателям не закрывает реализацию.

А должен? Соственно и недолжен. Это если ПКО на основании обычной продажи а не розницы то закроет.

Хеерня какая-то. у меня типовая ТиС, ПКо прекрасно закрыаает документ "Реализаци (розница)"

возможны варианты - распечататй структуру подчиненности от розничнйо реализации и отчет по движениям документа ПОК - что именно закрывает будет видно...