KhodАлексей КуренковНа текущем сервере в районе 12 рабочих баз - причем все активно используются, в том числе и на запись, базы относительно небольшие 100-200Гб каждая. Две из них в планах хочется секционировать хронологически. И соответственно журналы транзакций разделять по дискам.

12 баз - 12 дисков.
Зачем больше?

В MS-SQL база состоит минимум из двух файлов - файл данных.mdf и журнал транзакций.ldf
здесь актуально журналы транзакций прежде всего выносить по шпинделям при активной записи в базу данных - что бы отойти от random seek - несколько log файлов на один диск и дают рандомный доступ к дискам, в то время как один log на одном шпинделе линейный. Поэтому 12 баз в идеале 24 логических и физических диска + если их зеркалировать вот и 48.
в моем случае несколько баз придется все таки объединять на одни шпиндели, из за активности tempdb.

The Dim!Само по себе разнесение по дискам ничего не даст 0 будь их 100 или 1 000. Проблема в ином.
Тормоз может быть уже просто в пропускной способности, в архитектуре базы - теже индексы, запросы...

Если вам нужна была скоросная дисковая подсистема, то брали бы SSD. Почему нет?
Допустим под теже самые tempdb.

Что хранится в базах по 200-300 гиг? Может как-то можно сыграть секционированием - отделив старые (архивные) данные от рабочих.

Что вы собрались ложить на "шпиндель"?

Насколько я читал про твердотельные накопители, то бытует мнение что они долговечны при активном чтении, но при интенсивной записи их хватает на полгода год, исходя из этих знаний я склонен ко мнению, что старые секции, которые нужны на чтение имеет смысл сваливать на SSD диск, пусть даже один а не несколько. Но не tempdb который в постоянной записи (при желании можно темпдб в рам диск вынести, он все равно пересоздается при каждом рестарте службы SQL). Возможно со временем технологии изменятся. А разбитие на шпиндели: это во первых рекомендация Microsoft, а во вторых тесты на рабочей базе которые я сам делал - мониторя дисковую очередь, показывают что две базы работая на 2х разных шпинделях не создают дисковую очередь, в то время когда я их же запускал на едином raid10 - очередь растет.

Алексей КуренковThe Dim!Само по себе разнесение по дискам ничего не даст 0 будь их 100 или 1 000. Проблема в ином.
Тормоз может быть уже просто в пропускной способности, в архитектуре базы - теже индексы, запросы...

Если вам нужна была скоросная дисковая подсистема, то брали бы SSD. Почему нет?
Допустим под теже самые tempdb.

Что хранится в базах по 200-300 гиг? Может как-то можно сыграть секционированием - отделив старые (архивные) данные от рабочих.

Что вы собрались ложить на "шпиндель"?

Насколько я читал про твердотельные накопители, то бытует мнение что они долговечны при активном чтении, но при интенсивной записи их хватает на полгода год, исходя из этих знаний я склонен ко мнению, что старые секции, которые нужны на чтение имеет смысл сваливать на SSD диск, пусть даже один а не несколько. Но не tempdb который в постоянной записи (при желании можно темпдб в рам диск вынести, он все равно пересоздается при каждом рестарте службы SQL). Возможно со временем технологии изменятся. А разбитие на шпиндели: это во первых рекомендация Microsoft, а во вторых тесты на рабочей базе которые я сам делал - мониторя дисковую очередь, показывают что две базы работая на 2х разных шпинделях не создают дисковую очередь, в то время когда я их же запускал на едином raid10 - очередь растет.

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

KhodАлексей КуренковВ MS-SQL база состоит минимум из двух файлов - файл данных.mdf и журнал транзакций.ldf
здесь актуально журналы транзакций прежде всего выносить по шпинделям при активной записи в базу данных - что бы отойти от random seek - несколько log файлов на один диск и дают рандомный доступ к дискам, в то время как один log на одном шпинделе линейный. Поэтому 12 баз в идеале 24 логических и физических диска + если их зеркалировать вот и 48.
в моем случае несколько баз придется все таки объединять на одни шпиндели, из за активности tempdb.

Случайное и линейное чтение - пережиток ИДЕ-винтов.
Используя САТА2 в нативном режиме или САС вы практически не заметите нелинейной скорости.
Главное - найти быстрые винты с хорошим кешем.
И не поскупиться на рейд-контроллер.

А само увеличение памяти, как сказано выше, даст ощутимый еффект.

Процент попадания в хэш память также и при 4х гигах ниже 95% не падал... на мой взгляд хранимки и запросы хорошо написаны. Может быть и действительно подобная подстраховка в моем случае излишняя с разнесением каждой базы на свои родные 2 независимых шпинделя, хотя ито этого не произойдет. А винты и так что старые что новокупленные с интерфейсом SAS 10000rpm. (15шки не стали брать - был опыт на 5х райдах их вылет и при перестройки райда, когда заменяли один вылетивший - вылетело еще два - диски заменили гарантийные, но время на восстановления из бэкапа и останов производственной базы - это больший урон по предприятию, поэтому сейчас используем 10к рпм диски). На них также ощутимы дисковые очереди и чувствуется разница когда random seek когда linear read. Да при использовании RAM-disk или SSD - будет фиолетово на рандомное чтение. Но пока к этому не пришли.

The Dim!Тогда программистов за шкирку и переписывать так, чтоб можно было разнести по разным серверам. Это снимет огромное число вопросов.

В одной из 2х больших баз данных хранимых процедур и функций больше 3000 и почти все работают сразу с несколькими базами этого сервера в коде. Сама система эвалюционировала, программисты так же уходят и приходят. И реально правка 12 баз это очень трудоемкий процесс. Плюс я не исключаю что в клиентских программах идет не чистый вызов хранимой процедуры а также и запросы сразу получающие данные с нескольких баз. Эту систему начали разрабатывать более чем 15 лет назад и корректировка всего кода боюсь может затянуться ну всяко более чем на время перехода с 2000 на 2008й SQL. И... мало вероятно что руководство оценит идею в ближайшее время задействовать программистов на перепись работающих задач с отрывом от текущих производственных задач.

KhodАлексей КуренковДа при использовании RAM-disk или SSD - будет фиолетово на рандомное чтение. Но пока к этому не пришли.

SSD - всё-таки пока экзотика.
Ещёсистему на неё поставить можно.
А базы... И дорого и ненадёжно.
Смотри, какие базы наиболее активны - те можешь и сделать с разбивкой на 2 винта.
Но пока можно хранить на 1 диске.

Да тему то я спрашивал даже не как куда базы распределять. А про то что букв не хватает - шпинделя есть - хранилище есть - винда буквами ограничивает количество подключаемых разделов. mountvol позволяет монтировать логический диск к папке - но у меня они не работают стабильно - причину я не понимаю. И именно в этом вопросе и хочу разобраться.

KhodАлексей Куренков,

Если выбросить всякую лирику типа: неисправное железо, глюки ПО, то:
прооверить индексацию раздела, аудит файлов, наличие слежения за восстановлением системы, нарезанными правами и их отношениям к подпапкам.
Т.е. отключить службы индексации и слежения за железом? И mountvol решение - я правильно понял?
Если не сложно, перечислите какие конкретно службы тормозить нужно?
В любом случае спасибо за совет... Тут реально моя проблема или mountvol или сторонние драйвера для монтирования логических дисков в папки... другого я не вижу. Просто я не настолько глубоко знаю взаимодействие служб в виндовс.

KhodНаапример, для ХР.

Диск С: - свойства - вкладка "Общие"
Убрать галочку "Разрешить индексирование диска для быстрого поиска".

Мой компьютер - Свойтсва - вкладка "Восстановление системы". Можете восстановление или отключить полностью или снять наблюдение за необходимыми действиями.

Диск С: - свойства - вкладка "Безопасность".
Просмотреть и при необходимости подправить.

Мой компьютер - Свойтсва - вкладка "Дополнительно" - кнопка "Быстродействие".

ПС. Вместо диска С: выберите интересующий.

Попробую, еще раз спасибо. По результату отпишусь.

Спустя долгое время и подзабив на эту тему, в очередной раз столкнулся с этим же вопросом. Разрешилось!!!! )))))
Монтирование дисков к папкам! Ранее не получалось настроить из за того, что в корне логического диска в папке при форматировании по умолчанию права минимальны - т.е. добавляем папку типа - DATA и в ней нормально можно размещать файлы баз данных.