SQL Server: правильно разбить диски для данных и логов. #431810

Есть такой вопрос к специалистам по железу и серверам: Сейчас система работает стабильно, но иногда подтормаживает. Необходимо увеличить быстродействие дисковых подсистем. Сейчас есть боевой сервер, на нем крутится только SQL. 8 дисков, 15к об., в массиве RAID 10. Этот массив разбит на 2 логических диска, на одном из которых - система, на другом - данные и логи. Также есть внешнее хранилище. Проверял диски программой HD_Speed на чтение, с полной нагрузкой на сервер(все пользователи работают, час пик). Чтение с массива RAID ~ 300-400 Mbs Чтение с внешнего хран. ~ 60-85 Mbs на запись не проверял, ссыкотно. Есть ли смысл переносить логи во внешнее хранилище, или же лучше разбить RAID?

бамп

Или оставить все как есть?

Бамп

хм, а количесто баз / размер / кол-во пользователей? --- я бы систему с райда убрал и рейд на 2 по 4 разбил

Количество баз = 2, 30 и 7 гб. Пользователей 150. Я бы тоже систему вынес на отдельный диск, только вот этим всем занимается сисадмин, я хочу ,пока что, то, что могу своими силами сделать.

Если разбить на 2 по 4, то скорость будет уже не та, т.к. количество веников в стрипе уменьшится.

Есть ли смысл хотя бы пробовать перенести логи на внешнее хранилище?

4 базы по 40 гб, разнос mdf и ldf на разные физ диски - никакого заметного изменения а вот разнос mdf по разным физ дискам - заметный прирост скорости но это при соотношении 40 gb mdf + 500 mb ldf и модель simple

при модели full может быть иная ситуация

зато это будет другое физ. устройство

Систему на рейде держать смысла нету никакого. Т.е. под систему небольшой отдельный диск. Базу и логи на физически разные диски - как объединить в рейд думаю системщик знает. Ну и какой именно рейд ставить тоже вопрос к системщику, ибо он отвечает за данные. "...своими силами сделать" - это как? Не чуди, и неотбирай кусок хлеба у системщика. Если у тебя возникает вопрос как сделать, то лучше и не лезь. Пиши прямые запросы - это тоже полезно.

Модель full. База в 7гб используется не интенсивно. Вопрос вот в чем - хватит ли скорости внешнего хран. для записи логов базы? В мониторе производительности скорость очереди к диску зашкаливает как раз при торможениях. Делал анализ простоев в SQL, Показало, что 60% времени простоя - ожидание записи в лог.

Все и так уже на прямых запросах.

имхо при небольших размерах ldf внешнее хранилище (SATA диск?) справится. поставь только рост метров по 300 какое соотношение mdf и ldf? --- а вообще тупо попробуй - делов-то, не устроит, обратно вернешь

какой рейд ставить вопрос также и ко мне, потому, что дело не только в сохранности данных, но и в быстродействии системы учета.

Ну и что ты хочешь без параметров железа, моделей баз, замеров производительности?.. Могу только посочувствовать.

Внешнее хранилище - по интерфейсу iSCSI, тоже стоит рейд 10.

Моя твоя не понимай.

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

recovery model full/simple/bulk

еще мне здорово помогло max degree of parallelism = 1 т.е. отключение распараллеливания одиночного запроса, но это на 8-ми процессорном серваке

max degree of parallelism = 1 . уже стоит, у меня 4 ядра.

В общем, спасбо всем :)