Предельный размер базы 1С 7.7 в файловом режиме

Рухнет... Можете не сомневаться. Как альтернативу перехода на SQL Server можно регулярно резать предыдущие периоды, но я бы предпочел все же перейти. В данный момент на SQL'е наша бухгалтерия весит около 15ГБ - и ничего, все работает.

 

вот почитай
сам работал с базой в 4 Гб без проблем

 

Какой-то странный вопрос. С чего бы ей рухать. Файловых больше 4Гб не видал, но все равно непонятно что конкретно должно рухнуть.
ЗЫ: Скульную видел на 90 Гб. Ничего вроде не рухнуло.

Это не альтернатива, а абсолютно малосвязанные вещи.

 

ссылка не работает и у меня

 

вот для тех у кого не открывается

 

Ключевой момент безопасность такой базы, а не сколько она проживёт. Под SQL она проживёт гораздо дольше, чем в dbf. Не дай бог что с железом dbf рухнет так что восстанавливать будешь очень долго и малорезультативно!
Опять же, онлай-бэкапы на dbf-ах сделать не получится, на sql-очень просто!
Опять же, если кол-во юзеров в базе довольно высоко (этот параметр очень сильно зависит от кол-ва транзакций в единицу времени) то sql-сервер справится гораздо легче.
Так что помоему ответ очевиден...

PS.Сам живу с базой на 1Сv81+SQL (53Gb)

 

ГостьNNN,

Всё зависит от непрерывности задачи, которую автоматизируете. В моём случае перерыв в работе системы 6 часов раз в неделю, вот из этого и говорю...

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

 

Вчитайтесь: база более 2 Гб. Ежедневный бэкап? При редком изменении?? Гораздо эффективнее перейти на sql-версию хотя бы только для бэкапов.
Вот сейчас у меня дома на mysql висит несколько тренировочных баз, в одной из них две таблички - по 34 Гб. Я бы застрелился это добро бэкапить полностью.

 

Пересмешник,
Согласен! Different-backup здесь прям напрашивается!

 

4,5 гига, 20 пользователей одновременно плюс еще 3-5 в распределенном режиме, полет нормальный. Не обрезали базу с 2002 года. Никаких SQL-ей и прочих дорогостоящих штучек нет. Сервер чуть ли не один в один с описанным в первом посте. Когда обрезали, то преследовали исключительно цель ускорить работу. Ускорялось или нет - не помню уже, 5 лет прошло, как-никак

добавлено через 4 минуты
Да, забыл сказать: база росла неравномерно, основное наполнение пришлось на 2003-2004 года, размер в 2 гига уже, кажется, в 2003 и перешагнули.

 

White,
везёт. очень...

 

Сорри, торможу. Автор пишет о размере именно *.dbf, а я просто размер папки глянул. dbf тянут 3,25 гига. Нашел какой-то архив за февраль 2005, там они весили 1,3 гига, но что за архив - не пойму, и на фиг столь старый архив нужен - тоже не пойму. Видимо это какая-то из периферийных баз.

 

Ты шо, сам педали крутишь чтоли? Какая разница сколько бэкапить.
ИМХО описанный автором случай вполне позволяет обойтись ДБФ-ной версией. Хотя скуль упрощает много вещей связанных с администрированием.

 

Вообще-то стандарт dbf какой-то там редакции ограничивал объем файла 2 Гб. Я не помню нюансов, но что-то связанное с размерностью указателей внутри файла... Возможно, 1С использует какой-то хитрый вариант dbf, но на foxpro (правда, это было очень давно) не получалось никак это обойти.

добавлено через 56 секунд

А какой объем самого большого файла dbf?

добавлено через 11 минут

7.7 еще в строю. Не надо забывать про бухгалтеров, особенно бюджетников. У них нет конфигураций под 8.0.

А после выхода 8.1 и появления там управляемых блокировок транзакций однозначно рекомендую связку 1C + Linux + PostgreSQL, конечно, если вам зачем-то не понадобилось com-соединение с серверной частью 1С. В этом режиме 1С умеет работать на кластерах и запросы к СУБД аналогичны MS SQL server. Т.е. потерь по скорости в части СУБД (исключая только работу кластера СУБД, хотя тут надо тестировать) на небольших объемах данных (до 10-50 Gb) не будет. PostgreSQL серии 8 - очень достойный вариант.

Опять-таки не надо забывать, что стоимость этого решения = стоимости услуг по настройке и инсталляции. Софт предлагается бесплатно по лицензиям GPL (Linux) и BSD (PostgreSQL). Средняя экономия достигает 3500 долларов по розничным ценам для 10 пользователей. Есть над чем задуматься, если для работы пользователей не видно разницы. Не так ли?

 

Если Вы не цЕните своё время, то ценИте хотя стоимость хранения 1 Гб.

 

Не, не верно. Если у вас на dbf база достигла хотя бы одного гига, то вероятность падения индексов очень велика (после закрытия всех подключений более 70%). Это статистика, спорить тут не надо. Соответственно на ночь запускаем переиндексацию базы. Если учесть, что регламентные процедуры на предприятиях заканчиваются где-то около 7-9 вечера, а переиндексация базы несколько часов (если по сети, то и на пол-суток)... а еще предлагаете бэкап делать (например, через rar в пакетном режиме - действительно, минут 10-20)... Для чего все эти трудозатраты? Понятно, что можно пакетную обработку запустить, но вы уверены, что все завершится к началу следующего рабочего дня? Не проще ли уйти в sql, поработать "профилером", оптимизировать где можно проведение и радоваться.
Помниться, в начале 2000 года оптимизировали процедуры проведения документов - ускорили относительно стандарной конфигурации почти в 10 раз. Много нового узнали про специфику выполнения отдельных команд в 7.7. Время работы в dbf и sql режимах отличалось на порядки, хотя в доке про это ничего и не сказано было.

Все-таки, sql придумали не зря. Как ни старайся, но dbf реально гнется на объемных данных.

Правда, в варианте 7.7 использование sql сервера такое, что хочется плакать...

 

1. Я приводил ситуциацию домашнюю, прошу не смешивать. Если я в 11 вечера сделаю ошибку, то ни ждать сутки пока всё восстановится за ночь, ни сидеть ждать полный restore 34 Гб я не собираюсь. Я своё время ценю: и сутки простоя жалко и один час на науку с одинадцати до двенадцати ночи нелегко даётся после полноценного рабочего дня.
2. Если кому-то интересно сравнить инкрементальный, дифференциальный и полный бэкап - в отдельную тему, а ещё лучше - читайте учебники, благо их много сейчас.
Ну а раз мы говорим про производство... Ну давайте.

1. Тут уже говорили про слетание индексов.
2. Искренне радуюсь, что у некоторых товарищей не работа, а "детсад первая четверть". Обычно и база должна бэкапиться несколько раз в день (к вопросам о целостности данных, ушедших в бэкап; размеру того бэкапа и о том, что каждый час будет запускаться архиватор, положивший на 100% проц), и по ночам базы должны быть доступны (для подразделений во Владивостоке) и много других периодических задач на сервере много запускается.
3. В этой теме есть товарищи, "умеющих готовить кошек", но прежде чем вы дорастёте до такого уровня - ну ГОРАЗДО ПРОЩЕ ЖИТЬ на sql с такими базами. Хотя если нравится "файловое мышление" - да ради бога.

 

Все верно, но 4Гб это довольно таки небольшой объем.

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

А что если введена некорректная запись в БД, то нужно поднимать бэкап. Потом я все таки думал, что мы общаемся не о домашнем использовании.

Ну можно еще много предположений сделать. Я и сам бы в большинстве случаев рекомендовал бы при таком объеме Скуль, причем исключительно с точки зрения облегчения административных задач.
Однако автор задал по сути простой вопрос. Есть у него сейчас база. Каши не просит. Никто насколько я понимаю ей особливо не занимается (иначе бы не было такого вопроса) и более того не хочет. Т.е. людей абсолютно устраивает текущее положение вещей, за исключением того, что кто-то их испугал, что это ненадолго. Отсюда, имхо, нормальная им рекомендация оставаться с тем что есть и не пугаться.

Для эски - без разницы. Нет там ни такого, ни такого мышления.
ЗЫ: Про 3500 баксов и терминал ДБФ даже комментировать не буду.

добавлено через 9 минут

Нет, не использует.

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

 

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