Итак, я создаю SQL Server 2008 R2 x64 ... Буду работать с однопользовательской базой данных размером около 2 ГБ, может быть, 80/20 для чтения / записи и около 100 пользователей.
Базовым оборудованием будет DL380, 12 ГБ ОЗУ и два 6-ядерных процессора Xeon. Теперь зациклился на конфигурации диска ...
Опция 1
RAID 1 60 ГБ SSD (ОС, файлы SQL, TLog, TempDB)
RAID 1 120 ГБ SSD (файлы DB)
или
Вариант 2
RAID 1 146 ГБ 15 КБ (ОС, файлы SQL)
RAID 1 146 ГБ 15 КБ (Tlogs, TempDB)
RAID 10 4x148GB 15K (файлы БД)
Некоторые номера perfmon с моего текущего рабочего сервера:
Доступная память, МБ - 813 (у сервера 4 ГБ памяти)
Ожидаемая продолжительность жизни страницы - 496854ср.
Пакетный запрос / сек - 7.5avg 97.595max
Компиляции SQL - 3.422avg 27.599max
Повторная компиляция SQL - 0,002 0,200 макс.
Приоритетом для бизнеса является надежность, а не производительность.
Какую из вышеперечисленных конфигураций дисков вы бы предпочли? Разница в стоимости составляет около + 2700 долларов за SSD (также нужен второй зеркальный сервер). Будет ли SSD иметь значение для такой маленькой базы данных ?? Я мог представить, что с 12 ГБ мне хватит физической памяти для всей базы данных, верно ???
Ценю любые отзывы ... Спасибо!
Я читал о SSD с высоким частота отказов; так что, если надежность является приоритетом, я бы выбрал диски SAS 15k.
В любом случае, с RAID у вас есть отказоустойчивость диска, но вам, вероятно, больше всего повезет с 15k SAS. Мы запустили множество серверов dell с дисками SAS 15 КБ, и они оказались безупречными.
При использовании SSD повышается вероятность сбоя дисковых блоков. Если у вас есть база данных OLTP, это не очень хорошая идея, даже если вы получаете гораздо более быстрое время поиска для ваших операций чтения / записи. Вам также может потребоваться гораздо более частые проверки DBCC для БД, чтобы исключить поврежденные разделы на SSD. Для системы OLAP SSD становится немного более приемлемым, но у вас все те же плюсы и минусы.
Если приоритетом является надежность, выберите вариант 2 и держитесь подальше от SSD.
С таким большим объемом памяти и такой маленькой базой данных производительность хранилища при чтении в любом случае не будет иметь большого значения.
После некоторого запроса к базе данных все будет в ОЗУ. SQL не должен снова касаться диска, за исключением обновления через ленивую запись.
Я бы оставил эту пару только для журнала и поместил файлы данных tempdb на том RAID вместе с другими файлами данных. Кажется маловероятным, что вы будете выполнять физический ввод-вывод для файлов данных и базы данных tempdb одновременно. Размещение журналов на этой паре облегчит кэширование записи для этой пары и минимизирует движение головки диска, которое является настоящим врагом. Вы хотите, чтобы записи в журнал выполнялись быстро, потому что они синхронны по отношению к вашему DML. Запись данных может происходить медленнее, поскольку они кэшируются SQL Server и являются асинхронными.