1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

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

Тема в разделе "Программирование", создана пользователем Гость, 26.03.07.

  1. Гость

    Гость Гость

    Есть 1С 7.7.
    база на серваке (*.dbf), все работают с ней в терминальном режиме, сервак простенький 2Гб ОЗУ, 2хКсеона 2,4, размер базы (сумма всех ДБФ файлов) 1,3 Гб!!
    Пока все нормально, но всякие разные товарисчи.... утверждают что база начнет сыпатся когда достигнет размера 2ГБ и никаким апдейтом железа эту проблему не решиш...... только переводить на SQL!!
    Внимание, вопрос!
    У кого был опыт работы с базамитакого размера, кто что умного по этому поводу сказать может....
     
  2. Читатель снов

    Читатель снов Активный участник

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

    buffoon Активный участник

    6.379
    0
  4. Гость

    Гость Гость

     
  5. Mix

    Mix Активный участник

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

    buffoon Активный участник

    6.379
    0
     
  7. SAshock

    SAshock Активный участник

    577
    0
    ссылка не работает и у меня
     
  8. buffoon

    buffoon Активный участник

    6.379
    0
    вот для тех у кого не открывается
     
  9. NoMAD525

    NoMAD525 Участник

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

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

    ГостьNNN Гость


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


    Совершенно согласен. Вместе с тем, это значимо только если юзеры сидят в базе круглосуточно или бьют очень много документов за сутки.


    Но связка 1С77 с SQL реализована из рук вон плохо с точки зрения производительности. У меня скорость проведения доков в одной и той же базе в дбф под терминалом в несколько раз выше, чем в SQL варианте (одновременно работающих юзеров около 20, размер базы 1 Гб)
    Хотя, справедливости ради, надо заметить, что с помощью внешних компонент и переписывания модулей проведения документов, можно и от SQL варианта 1С77 добиться бОльшей скорости.


    Вот именно: 1С _8_. Восьмерка с SQL пошустрее вертится, естественно, мощное железо нужно.
     
  11. NoMAD525

    NoMAD525 Участник

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

    Пересмешник Участник

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

    NoMAD525 Участник

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

    White Активный участник

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

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

    NoMAD525 Участник

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

    White Активный участник

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

    Mix Активный участник

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

    ZCom Новичок

    27
    0


    Вообще-то стандарт 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 пользователей. Есть над чем задуматься, если для работы пользователей не видно разницы. Не так ли?
     
  19. Пересмешник

    Пересмешник Участник

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

    ГостьNN Гость


    И что же такого в этом страшного - cбэкапить ночью 2 гига дбфок? У меня 1-гиговая база раром упаковывается за 10 минут. Соответственно 2 гига заархивируются за 20.
    Наверное это очень трудно - найти целых 20 минут для бэкапа за все ночное время :)
    Зато при проведении документов под терминалом дбфка летает в _н_е_с_к_о_л_ь_к_о_ _р_а_з_ _б_ы_с_т_р_е_е_ скл варианта 1с77.
     
  21. ZCom

    ZCom Новичок

    27
    0


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

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

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

    Пересмешник Участник

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

    Mix Активный участник

    7.766
    0
    Все верно, но 4Гб это довольно таки небольшой объем.
    Ну где тут трудозатраты. Пишется пакетник, который все это проделывает. Не говоря уже о том, что кое-кто имедж разделов на ленту бэкапит. Ему вообще пофиг фактически сколько размер базы.
    Я еще раз спрошу - вы что сами чтоли педали крутите?
    А что если введена некорректная запись в БД, то нужно поднимать бэкап. Потом я все таки думал, что мы общаемся не о домашнем использовании.
    Ну можно еще много предположений сделать. Я и сам бы в большинстве случаев рекомендовал бы при таком объеме Скуль, причем исключительно с точки зрения облегчения административных задач.
    Однако автор задал по сути простой вопрос. Есть у него сейчас база. Каши не просит. Никто насколько я понимаю ей особливо не занимается (иначе бы не было такого вопроса) и более того не хочет. Т.е. людей абсолютно устраивает текущее положение вещей, за исключением того, что кто-то их испугал, что это ненадолго. Отсюда, имхо, нормальная им рекомендация оставаться с тем что есть и не пугаться.
    Для эски - без разницы. Нет там ни такого, ни такого мышления.
    ЗЫ: Про 3500 баксов и терминал ДБФ даже комментировать не буду.

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

    Пересмешник Участник

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

    ГостьNN Гость


    Непонятно, какая статистика? Вам что, со своего места виднее, что у меня в базе делается? :) Тогда я пас :) Хотя нет, все же придется рассказать: уже почти год как перевели одну базу с скл на дбф, ее размер почти как у автора ветки - 1,2 гб, и индексы не рушатся.


    Кто это вам такое рассказал? На нашем железе реиндексация 1с 77 конфигурация - немного измененная типовая бухгалтерия занимает не более _п_о_л_у_ч_а_с_а_.


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


    Не проще, но гораздо интереснее. Но в нашей суматошной конторе такого, увы, не удастся сделать :(

     
  26. ГостьNN

    ГостьNN Гость


    Да ваш случай здесь при чем? ветка-то о базе 1с77 размером 1-2гб.


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


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


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