SQL-сервер 2005 Медленный доступ
Если у Вас есть высвечивание диска, и Вы не уверены, что это плохо (это должно отметить его, как отказавший на экранах BIOS Setup), попытайтесь подкачать ее место с другим из дисков, которые поднимают зеленый светодиод. Если желтый свет следует за ним, диск, вероятно, плох.
Принятие этого имеет место, Вас оставляют с 2 дисками на 73 ГБ и 2 дисками на 146 ГБ. Предположение, что у Вас нет никого для замены в пробелах, я сделал бы RAID 1 73 ГБ и RAID 1 146 ГБ.
Если Вы собираетесь использовать это для производства, Вы собираетесь хотеть по крайней мере еще один диск на 146 ГБ действовать как горячее резервирование. Я полагаю, что 146 дисков могут действовать как горячее резервирование к зеркалу на 73 ГБ, но я протестировал бы это перед доверием ему.
Если Вы находитесь в диске, делая покупки настроение, необходимо смочь найти тех, которые по относительно низкой цене. Просто ищите Google Shopping модель, и необходимо будет также искать "поставщиков услуг диска", которые являются санями, что диски живут в и позволяют заменять в горячем режиме.
Если Вы действительно заканчиваете тем, что покупали больше дисков, воздерживаетесь от 73 и просто получаете более крупные диски, то сделайте массив RAID-5 (с одним горячим резервированием). Хотя RAID-5 обычно осуждается для "современных" дисков, Ваши диски на 146 ГБ будут прекрасны.
Править
Хорошо, как icky2000 связанный с, чрезвычайно емкость дисков превысила уровень неисправимой ошибки чтения (URE), так, чтобы "современные" диски (1-2TB +) в конфигурации RAID, статистически, вероятно, пострадали, неисправимая ошибка во время RAID восстанавливают.
Другими словами, если диск перестает работать, и Вы добираетесь, отказ во время восстанавливают, Ваших данных не стало с RAID5.
Вам нужно понять, что происходит в БД. Проверьте текущую активность, чтобы увидеть, что выполняется в системе - могут быть запущены большие запросы, операторы, содержащие множество блокировок, блокировки и т. Д.
Вы также можете изучить некоторые примеры операторов, которые теперь выполняются медленно, чтобы посмотреть на фактическое выполнение планы и статистика - попадают ли они в нужные индексы или генерируют сканирование таблиц?
Сильно ли фрагментированы индексы?
Произошло ли что-нибудь серьезное в последнее время, например, большой рост объема данных после массового импорта или чего-то подобного?
Обновление:
Фрагментация индекса является внутренней для SQL Server (и отдельной проблема из-за физической фрагментации файлов на уровне ОС). Вам следует подумать о том, чтобы установить регулярный график, чтобы справиться с фрагментацией.
Брент Озар написал об этом серию хороших постов http://www.brentozar.com/archive/2009/02/index-fragmentation-findings-part-1-the-basics/ . Он включает ссылку на хорошие индексы scrupt defaging, которые в этом нуждаются. В качестве альтернативы, если вы можете настроить план обслуживания, чтобы сделать это, но обратите внимание на ограничения, упомянутые в статье.
Как минимум, вам необходимо учитывать влияние этих задач обслуживания, выполняемых на действующей системе - идеальным является планирование работы для если возможно, выходят нерабочее время.