Добрый день.

Описание.
Конфа: ЖКХ, DBF
Сервер: Xeon 5200/Intel/160 Гб/4 Гб (никто не работает локально)
Движок: 027. 7.7 бухгалтерия

Сеть: 10 машин (но все юзеры работают в терминале)
Памяти используется 1,5 Гб максимум, проц не загружен полностью. Места на диске еще 80%. В Антивире отключена проверка DBF, cdx, md.

Предыстория
Поставили эту конфу 1,5 года назад. Сперва все летало, естественно. ) Но т.к. база заполнялась быстро то и проблемы появились. Сейчас база весит около 5,5 Гб. Причем файл 1sentry весит 1,7 Гб. Каждый месяц база увеличивается на 300-350 мб.
Про то что долго отчеты формируются я уже даже не спрашиваю. Это итак ясно. Появились симптомы нестабильной работы.
1. Человек сидит, работает. нажимает кнопку "сформировать отчет" (любой) и программа может просто закрыться. Причем это происходит с каждым пользователем по нескольку раз в день. В отчетах стоят ссылка на различные dll-ки 1с-овские.
2. Если запускать формирование нескольких отчетов на разных машинах (читай терминалах) то БЫВАЕТ! что отчеты искажаются. Т.е. если идет отчет по нескольким домам, то один дом может попросту вывалиться из выборки.
Раньше (читай, "когда база была поменьше") таких глюков не было в принципе. все работало как часы.
Несколько месяцев грешил на сервер. Заменил на другой несколько дней назад. Все повторяется. Причина не в этом.

Вопросы.
1. Реально ли это все происходит из-за большого объема инфы в базе? Кто сталкивался с такими большими базами?
2. Какого размера базу может потянуть движок семерки? Опять же желательно чтобы написали те кто сталкивался с такими базами.
3. Стоит ли переходить на SQL или лучше уже рассматривать восьмерку. Опять же если смотреть на восьмерку ,потянет ли она такую базу?

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

1. Может быть такое - надо смотреть, как отчеты написаны
2. И большего бывают :) В разы
3. SQL на 7 в данном случае можно попробовать, 8-ка при таких объема не париться :) Конкретно сейчас работаю в базе >20гб

Автор не описал дисковую подсистему. Возможное "узкое место".

1. Пока вся инфа со слов пользователей. Сейчас дал задания им записывать во время выполнения каких отчетов чаще всего база вылетает. Возможно, действительно с увеличением объема данных, какой-то начал грести.
2. )
3. Сам SQL не использовал. Опыта нет. В основном могу судить лишь на основании прочитанного в инете. Для нашей организации переход на SQL достаточно дорог будет. И если вариантов больше нет, то хотелось быть уверным, что он потянет такой объем прежде чем говорить об этом с руководством.
А у Вас база (> 20 Гб) на 8-ке или на 7-ке?



А можно поподробнее в чем может быть "узкое место"? И что конкретно нтересует про дисковую систему?

Есть ли аппаратный RAID? И вообще, нужно замерить среднюю длинну очереди диска в момент работы 1С.

Аппаратный RAID был на старом сервере. На текущем сервере пока нет. Система стоит на одном обычном винте HDD 250 Gb SATA-II 300 Seagate Barracuda ES <3250620NS> 7200rpm 16Mb
Среднюю длинну очереди диска постараюсь замерить сегодня днем. После отпишусь.

В любом случае стоит почисть базу для уменьшения размера. Удалить неиспользуемое, объединить дубли, свернуть после сдачи годового баланса, сделать тестирование и исправление с упаковкой.

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

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

Тестирование и справление делается каждый месяц. Толку нет (в смысле уменьшения размера)
Свернуть базу нельзя, т.к. В ней хранятся начисления за весь период по квартиросъемщикам и операторам приходится почти каждый день разным товарисЧам распечатывать информацию по их лицевому счету с детализацией по месяцу и в разбивке по услугам. Соответственно не вариант каждый раз открывать базы с разными годами для того чтобы распечатать один отчет для человека.

Я с семеркой уже несколько лет не дружу :) Категорически не нравиться мне она...

blacat, если ваше железо не испытывает проблем-то софтина 1cv7.7 исчерпала себя, переходите на 1cv8+sql, юзайте терминал и будет вам счатье.
Железки должны быть: камень один или два 4 ядра 3Гц, 8 гигов оперативы, аппаратный RAID5 на четырех SAS или скази дисках, гигабитная сетка или десятигигабитная.

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

Вобщем я уже тоже склоняюсь к тому, что семерка себя изжила и переход на восьмерку неизбежен. А жаль... 4 года конфа постепенно настраивалась под организацию, а теперь опять все заново ((((

PS: 1. Спасибо за советы.
2. Какой смысл в гигабитной сетке, если юзаешь терминал?

Неа. это не вариант. ) Объясню.
С базой постоянно работает 8 человек. 1 главбух которому как раз и пофигу на всю базу, ему нужны только итоги и 7 операторов, которые общаются с людьми и которым каждый день помимо текущей информации нужна еще инфа за ВЕСЬ период существования базы. Допустим мы сворачиваем базу 1 раз в год. Т.е. на текущий момент имеем 2 базы предыдущие( 2007, 2008) и одну текущую.

Так вот. Приходит к нам истеричная бабушка и начинает с порога орать, что дескать ей в феврале 2007 года льготу посчитали на 20 копеек меньше чем она должна быть. При этом оператору надо найти во всех трех базах эту бабку. Распечатать отчет по ее Лицевом счету полный за год. Проверить правильно ли была сделана выплата и если правда была ошибка сделать перерасчет в текущей базе. Это нереально. Т.е. может и реально на 3х базах, а если их будет уже 6? А бабка не уходит. стоит и орет что вы тут все сволочи обираете пенсионеров и теперь еще ей ждать надо пока вы все не перепроверите. Это реальная история. И такие случаи происходят часто. Т.ч. ПОЛНАЯ база как раз нужна практически всем сразу.

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

Надеюсь убедил, что свертка базы это не всегда однозначный вариант. )

Возможно сервер не тянет. Сервер у Вас слабенький, а вы его загузили терминалами.
У нас много предприятий у котоых в качестве сервера работают двухядерные компьютеры с SATA винтами. 10 и больше компьютеров подключены и работают с 1С в сетевом режиме.
Проблем не возникает. По крайней мере таких ужастных картин мы не видели.
1 раз в три-четыре года приходится обрезать базу.
Есть более крупные фирмы где стоят двухпроцессоные(четырехпроцессорные) выделенные сервера.
Везде работают в сетевом режиме. В терминальном режиме подключаются 1-3 ведущих сотудника.
Те кто занимается серьезным анализом, сведением баланса и т.д(т.е. требуется быстодействие).
Для ввода данных используется сетевой режим. И все работает номально.

Не убедил. Есть подобная проблема у клиентов. ЕЖЕДНЕВНЫЙ документооборот 3-5тыс штук. 20 операторов (не считая бухгалтеров). Подход следующий. Руководство хочет иметь динамику продаж за все периоды + статискику по ценам и долгам. Сами понимаете - база пухнет на глазах,а SQL не решение проблемы (из-за медленного восстановления последовательности). Решение: Ежегодно переносятся справочники и остатки в пустую базу(т.о. начинаем год с нуля). А для руководства написаны отчеты использующие технологию OLE. Все крутится и вертится без проблем. База к концу года составляет окого 5-7Гб.
Вот и построй отчет по мерзопакостной бабушке и спокойно реж базу. Это проще чем перейти на 8ку. Все зависит от того ЗНАЕШЬ ли ты ее.Остается еще скуль - тоже вариант. (там ничего сложного).

И еще. По поводу отчетов. Можно легко добавить общую процедуру в ГМ и подпихнуть ее в каждый отчет для ведения лога (при открытии, при закрытии) Особо не доверяй юзерам. Так надежнее. А лучше еще сохрани параметры отчета. Может выяснится какая-то закономерность

Ребята, blacatа нет уже больше 3х месяцев на форуме.... Не думаю, что он ваши доводы примет к учету.