Железо для сервера.

Есть база SQL размером около 600 Mb.
Рабочих станций около 70.
Вопрос такой, какие характеристики рекомендуются для железа под сервер, чтобы не тормозил, при одновременном доступе, хотябы 50 юзеров.

Строго говоря, текущее состояние не так важно, как динамика роста базы. Кроме того, важно куда у Вас смещена вычислительная нагрузка, на сервер или на клиента.
Далее рекомендации:
1. Два камня (для надёжности), один отдайте операционке, а другой SQL;
2. Дисковая подсистема. Желательно иметь пять дисковых RAID массивов:
- для операционки и сервисов SQL;
- для базы данных;
- для журналов;
- для tempdb;
- для устройст резервирования.
Размер массивов выбирайте с учётом роста вашей базы. Желательно иметь столько SCSI каналов на RAID контроллере (а лучше если их несколько), сколько у Вас получится (реально) дисковых массивов. Разумеется PCI шины нужно, как минимум, две (лучше с горячей заменой).
3. ОЗУ выбирайте примерно так - 200Мб для операционки (это из расчёта на W2K), а для сервера SQL самым оптимальным считается иметь размер памяти того же порядка, как и размер баз данных. Итого, для Вас лучший выбор - 768Мб. Кэша должно хватить 512Кб.
4. Сходите на http://mssqlhelp.com.ru/ почитайте первые выпуски рассылки "MS SQL Server - дело тоноке..." - там почерпнёте то, что я забыл здесь указать.

Александр, ну что ж Вы так человека пугаете.
Во-первых неизвестно что это за база, что эти 50 юзеров делают. Если они в основном читают что-то без сложных выборок, а обновление делают пара-тройка человек, то смысла ставить два процессора нет. Но опять же надо бы знать(в общих чертах) что за тип обновлений, как часто они делаются, насколько сложна логика, как важна надежность(насколько допускается посреди дня тормознуться и какая потеря информации допустима) и т.д.

Ставить 5(!) дисковых массивов на базу 600М - мягко говоря, незачем. Да я чесно говоря ни разу не видел, что бы стояло на одной машине больше одного массива.

Что бы я посоветовал.
600М - это очень мало, да сейчас таких и дисков то наверное не делают.
Поэтому можно сделать так.
Иметь конечно нужно минимум 2 диска, лучше иметь и дисковый массив(или сделать зеркало, можно и програмно).
Главное иметь на разных дисках базу и бэкапы, которые надо обязательно периодически делать. Конечно хорошо бы еще разделить на разные диски как перечислил Александр(и еще индексы и таблицы на разных дисках), но для такой небольшой базы это не критично.
Сколько надо памяти сказать опять же трудно. В 95 году у нас работал MS SQL 4.0 аж на 24М(это всего столько было на машине), правда и база была небольшая, 400М. Операционке мы оставляли целых 4М и думали: а не многовато ли, на хрена ей столько? Так что мне как-то страшно читать такие слова как "200Мб для операционки", хоть я и понимаю, что времена меняются.
Выбирать размер оперативной памяти под SQL как размер БД - ну я не знаю как это может считаться оптимальным. У нас была база 7Г. Интересно много ли в России камнпутеров с таким размером ОП? Нам хватало 1Г.
На мой взгляд в рассматриваемой задаче 256М должно вполне хватить. Это при условии что эти 600М не меняются целиком каждый день по нескольку раз. Но с другой стороны память не так уж и дорого стоит, можно и потратиться до 512.
Можно конечно посоветовать еще потратиться и купить крутейший сервер за 100 килобаксов с гигами памяти. И наверняка он будет хорошо работать. Но можно и обойтись раз в 50 дешевле. Вам решать.
Я однозначно посоветовать не могу - информации маловато.

С приветом Сергей
sergsuper@mail.ru
PS. Хорошая штука была SQL 4.0. Дистрибутив занимал всего 4 дискеты. Умели же делать когда-то!

Для БД 600Мб и 70 пользователей не обязательно сразу покупать многопроцесорную систему с несколькими дисковыми массивами.
Лучше позаботится о легкости нерашивания производительностий.
К тому моменту, когда потребуется увеличение производительности, оборудование будет дешевле.
Для этого можно разнести сервер и дисковый масив по разным устройствам.
Это позволит:
1)Легко заменять сервер на более производительный (или если он вышел из строя).
2)Легко увеличивать размер и кол-во дисковых массивов.

Я работаю с конфигурацией:

RAID контроллер Mylex,
корпус для дискового массива из 4 устройств
дисковый массив 3x9GB
накопитель на магн. ленте Sony DDS2 2/4GB

мат. плата Intel815
процессор PIII-800
оп. память 512МБ
SCSI контроллер AHA2940UW
жесткий диск SCSI 4.3
видеокарта S3Trio64 AGP
сетевая карта Asante 10/100

Спасибо за критику. Я, в принципе, её и провацировал. Действительно, если речь не идёт о надёжности, можно эту базу воткнуть на обычную персоналку. Таким образом, можно обозначить две крайние точки для минимальной и разумно избыточной конфигурации. Хотя, если информация в этой базе, например, используется во время хирургических операций и может повлиять на то - останится ли пациент жив, я бы соорудил ещё и кластер из двух (из перврго ответа) серверов и обеспечил его безперебойное питание по полной программе, включая дизель-электрогенератор.
Далее о двух дисках. Насколько я понимаю, имелось ввиду построить на них обычное зеркало. Если так, то я категорически против. Первое правило любого администратора сервера (тем более баз данных) разносить на разные физические устройства данные последовательного и случайного доступа. Таким образом, лучше (коль уж мы решили рисковать)да один диск положить базу, а на другой журнал. При условии, что резервные копии базы будут отписываться на другое устройство (не то, где она физически лежит), у вас останется шан на их восстановление после сбоя.
По поводу памяти. Да, многие задачи и операционки к её объёму не критичны. Но существует масса применений, где становятся жизненно важными такие параметры, как доступность и готовность. Если в ваших клиент-серверных приложениях вычислительная нагрузка перенесена на клиента, то реакцию системы на команды пользователя, как правило, будут определять возможности его персонального компьютера. Если же у вас вычислительную нагрузку несёт сервер, то тут стоит подумать, как бысторо он сможет откликаться на запросы пользователей. Без моделирования реальных условий Вам не обойтись. В любом случае, чем больше страниц будет кешироваться, тем быстрее будет обработан запрос. Кроме того, в отличии от типовых на сегодняшний день задач, сеществуют современные бизнес-задачи, которые требуют весьма и весьма высокой готовности и доступности вашего железа и приложения. Из прессы я для себя сделал следующий вывод, что сервер баз данных начинает показывать свою реальную "силу" только на многопроцессорных узлах и с объёморм памяти от 8Гб. Я понимаю, что подавляющему большинству это не интересно, но посмотрите конфигурации железа, на которых мелкомягкие якобы побили Оракл.
Теперь пример. Что если Pavel построил у себя интернет приложение, к базам данных которого сегодня подключается в среднем 50 человек. Завтра, ихний топ менеджер организует рекламную компанию (к примеру удачную) и в одночасье количество клиентов у сервера возрастёт на пару порядков? И какой же тогда ему нужен сервер?

Активных полбзователей около 6-8 чел. Остальные запускают отчеты-запросы.
У нас сейчас стоит сервер DELL Pentium II -266 Mhz, RAM 224 Mb, HDD 18 Gb SCSI.
На мониторе на сервере, при подключении клиента, CPU процессора на SQL сервере 100%.

Вот теперь ясно о чём говорить!
Проблема явно не в железе а в конфигурации софта. Если всё крутится под NT4 и на сервере не запускается ничего, кроме MS SQL, и если SQL сервер 7 или 2000, проследите, сколько памяти откусывает сервер баз данных. Если он забирает всё, что есть, ограничте его только 190Mb. Операционке ведь тоже надо где-то жить.
Не помешает проследить в Performanc мониторе, что так утилизирует процессор. Тут нужно тотальное исследование в разрезе служб, процессов и пользователей.
Особенно обратите внимание, не лезет ли операционка часто в pagefile. Это бывает заметно, если при малых обращениях к серверу наблюдается бешенная дисковая активность.
Если не знаете с чего начать, полистайте архивы рассылки, я там про это часто писал.
http://mssqlhelp.com.ru/

Для SergSuper - Так ноги-то из правильного места росли ...

HOC'JU SOZDATJ RAID 1 IZ DVUH IDE HDD V WIN XP. RANJSHE DELIL 1 Z'OSTKIJ NA DVA RAZDELA, GDE ODIN RAZDEL BIL POD WINDU, A BOLJSHIJ PO OBJOMU POD DANIE. SMOGU LI JA TAKZ'E SDELATJ V RAID 1.