den-mark...но до сих пор не могу дать себе ответ какой максимальный объем БД может нормально 7.7 переваривать (у меня 12 гигов было, потом отрезал побоявшись)

7.7 - 112 гб, критично количество пользователей и быстрота дисковой подсистемы

Танцор Пасадобля Stix den-mark...но до сих пор не могу дать себе ответ какой максимальный объем БД может нормально 7.7 переваривать (у меня 12 гигов было, потом отрезал побоявшись)

7.7 - 112 гб, критично количество пользователей и быстрота дисковой подсистемы
Круто!!! в где такое работает?

работает там, где до этого работал

sql 2000,1с нетиповая, торговая сеть, база чек-монитора, работают с ней правда одновременно 2-3 человека - отчетность, данные в базу пишутся автоматом ночью в пакетном режиме

есть другая база 7, непосредственно торгово-учетная (нетиповая, типовая бы я думаю умерла бы на первом месяце работы) - за год собирается 70-90 гигов, после чего базу открывают заново, распределенка, порядка 40 периферийных баз, в центре в базе одновременно сидит 60-70 пользователей, местами дикие тормоза, в основном от обменов, по счетчикам производительности на первом месте стояла проблема производительности, сейчас не знаю может быть подняли.
По слухам сейчас уходят по товароучетной программы на другое, не 1с решение

не дописал в предыдущем посте "проблема производительности дисковой подсистемы" :)

uraВведение...
Есть холдинг, в который входит порядка 20-ти дистрибьюторов.
Объем продаж - у трех дистрибьюторов порядка сотни накладных в день, в каждой по сотне позиций.
У остальных объем поменьше.
Все компании территориально распределены, у каждой свой сервер.

Недавно на вышеуказанном холдинге проводили презентацию 1C УПП 8.0.
На вопрос о быстродействии с приведенными выше объемами был получен ответ: система без проблем проработает пять лет без обрезки данных.
Да, конфигурация сервера - среднего уровня.
Хотелось бы узнать - реально ли это ? Есть ли примеры работающих компаний с подобной спецификой и объемами ?
ЗЫ При условии, что функционал используется по полной, не только для бухгалтерии и зарплаты
к сути вопроса, работаю как раз с УПП, распределенные базы, количество несколько поменьше, около 8 распределенных баз..
Кто Вам сказал что необходим средненький сервер? и вообще что имеется ввиду по средним сервером?

1. В файловой конфигурации работать в УПП в сетевом режиме практически невозможно, ориентировочные требования для более-менее сносного функционирования системы для клиента П-4 -3 Ггц (селики не подойдут), 1 Гб Ram (лучше 2), средний занимаемый объем памяти 1 экземпляра 200-300 мб, далее не забудьте про блокировки.

2. в виде решения sql,сервер приложений, терминал (в филиале) необходимо 2 сервера
конфигурации терминал - 2xXeon E5335, 8 Gb RAM,RAID,2003-64bit; sql+ сервер приложений - 2 x Xeon 5120,4 GB RAM, RAID, 6-7 активно работающих пользователей вполне уживаются на таком железе. (возьмите калькулятор и посчитайте железо), может выгоднее заказать отдельное решение (если необходима торгово-учетная система) не на 1С + 1с бухгалтерия на центре с загрузкой данных изз этого решения, не забудьте про обслуживание как 1С так и подобной системы, как в филиалах так и на центре

3. в sql варианте за 3 месяца стандартной работы бухгалтерия, зарплата, кадры, 1 филиала
объем базы 1,2 GB, объем базы при инициализации системы пустая (с забитой номенклатурой, кладр, сотрудники, перенесенные итоги) ~600 мб, среднее количество документов около 100 в день, выгрузка 1 файла обмена после обновления для 1 периферийоной базы занимает около 3 часов, есть проблемы в типовой конфигурации УПП с настройкой миграции данных... что такое потом поймете

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