Добрый день. Подскажите у кого был опыт практический или какие альтернативы может быть есть драйвера или еще что.
Вопрос в следующем:
дисковое хранилище для SQL Server приобрели на 48 дисков... предварительно хотим сделать 20-RAID1 и 4JBOD (просто диск не райд). и плюс старые носители на сервере есть. Может букаф не хватать на все разделы. В винде есть возможность, насколько я знаю, монтировать логические диски не к букве D: E: и т.п. а к папке.
так вот... может у кого была практика - использовать такие примонтированные разделы для SQL... я вроде дома пробовал такую схему - у меня периодически вылетал диск связь пропадала... причина не понятна.... У знакомого консультировался на эту же тему - он говорит, что организовывал сетевое файловое хранилище подобным образом (локальные диски не буквами монтировались а в папки) - говорит что жуткие тормоза при этом.
Может быть как то хитро настраивать нужно подобные папки или альтернативные драйвера есть для windows?

Anatoly Podgoretsky,

Ну все таки вопрос к windows настройке дополнительных дисков букв... SQL это позже )

miksoftАлексей Куренковпредварительно хотим сделать 20-RAID1Зачем вам эта лапша?
Почему не хотите сделать 1-2-3 RAID10 ?
Группировку дисков в массивы, имхо, правильнее спрашивать у вашего DBA. Кому, как не ему, знать объемы и нагрузку на разного рода файлы СУБД (файлы с данными, индексами, логами и т.п.) конкретно вашей базы?

Я понимаю что можно сделать RAID 10, 5, 5EE и т.п. На текущем сервере в районе 12 рабочих баз - причем все активно используются, в том числе и на запись, базы относительно небольшие 100-200Гб каждая. Две из них в планах хочется секционировать хронологически. И соответственно журналы транзакций разделять по дискам. Вероятнее всего все базы по шпинделям раскинуть не получится на текущий момент. Вот в этом причина - зачем вам эта лапша. Еще также очень активно используется tempdb - что также требует определенных накладных расходов.
И все таки хочется найти решение и на перспективу. Понимаю, что профессиональный админ сделает большой RAID5 и поставит несколько операционок под VMWare - проще админить, но иногда требуется и производительность, не только удобство администрирования.

The Dim!miksoftпропущено...
Оговорочка по Фрейду :)
Но не могу не согласиться. При отсутствии грамотного DBA дисковое хранилище превратится в понты.
Да :)
Спасибо за комплемент. Я понимаю что опыт работы мой в DBA небольшой всего год. Поэтому я и спрашиваю совета у грамотных DBA.

The Dim!Алексей КуренковВ винде есть возможность, насколько я знаю, монтировать логические диски не к букве D: E: и т.п. а к папке.
так вот... может у кого была практика - использовать такие примонтированные разделы для SQL... я вроде дома пробовал такую схему - у меня периодически вылетал диск связь пропадала... причина не понятна....

Как монтировался диск mountvol?

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

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

Вы - насколько я понимаю - вы говорите о разных вещах. Друг-то монтировал сетевые диски - отсюда и тормоза, а вы-то монтируете локальные - с чего вдруг они начнут тормозить?

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

The Dim!А экземпляр SQL сервера один?
Ну да один. Тут просто годами сложилось еще с 6.5 MS-SQL на этом экземпляре базы установлено. Понимаю что можно разделить базы по разным серверам - только на это время уйдет - много софта написано и в каждом ошибки вылавливать - затянется на долго.

The Dim!Я вот о чем.

tempdb разнети - физически - конечно можно...

Но что если.. - сам никогда так не побывал, но теоретически... - буквы дискам назначаются в рамках сеанса.
Что если сделать несколько инстансов MS SQL, запускать их под разными учеткам. Тогда получится отдать tempdb конкретному инстансу-базе, да и с количеством букв уже легче будет
...теоритически...

А чем легче? не совсем понял, извиняюсь за не быстрое схватывание. Если мы сделаем несколько инстансов одновременно работающих - то у нас сразу станет столько же master, tempdb и т.п.
Если их физически по дискам разделять - еще больше буков надо будет. Каким образом увеличение числа инстансов уменьшит потребность в количестве шпинделей?

Алексей КуренковThe Dim!Я вот о чем.

tempdb разнети - физически - конечно можно...

Но что если.. - сам никогда так не побывал, но теоретически... - буквы дискам назначаются в рамках сеанса.
Что если сделать несколько инстансов MS SQL, запускать их под разными учеткам. Тогда получится отдать tempdb конкретному инстансу-базе, да и с количеством букв уже легче будет
...теоритически...

А чем легче? не совсем понял, извиняюсь за не быстрое схватывание. Если мы сделаем несколько инстансов одновременно работающих - то у нас сразу станет столько же master, tempdb и т.п.
Если их физически по дискам разделять - еще больше буков надо будет. Каким образом увеличение числа инстансов уменьшит потребность в количестве шпинделей?

Аааа возможно Вы имеете ввиду что если каждый инстанс будет от разного пользователя запущен, то у каждого пользователя будут свои буквенные имена разделов? Я так не пробовал честно скажу... Но реально, для текущего момента - 2й инстанс не подойдет - это по сути тоже самое что на другой сервер скинуть часть баз данных. Решение, полагаю со временем, нужное, но... не быстрое.

The Dim!А если инстанс один, то как не разноси ту же tempdb всеравно будет конкуренция. А если несколько инстансов сделать, то каждому можно свой шпиндель с tempdb дать.

Кол-во дисков - ну опетьже, теоритически - подключенных к дискам не уменьшется. Но в если создать для каждого инстанса виндового пользователя, то можно будет - допустим при старте MS SQL - монтировать нужные ему диски.

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

У меня есть подозрение что с локальными дисками такое не пройдет. Я просто не представляю как их можно хотя бы даже расшаривать - под каждым пользователем заходить и создавать шары - как то не вяжется. Но бог с ними этот вопрос меня сейчас меньше всего интересует. Про конкурирование нескольких БД к одному темпдб из практики спасает дополнительный диск для темпдб - alter database add file (name='tempdb'.......) - дисковая очередь падает заметно.
И всеже... все таки вопрос о нехватки буков для логических (не сетевых) разделов. Может есть альтернативы mountvol? доп драйвера? Или какие то иные возможности в windows 2008 server?

The Dim!х.м... тоесть проблема, в том, что в приложении жестко зашито имя сервера?

А порт?

Стандартный по умолчанию, приложения все локальные во внутренней сети работают... полагаю 1433...

The Dim!В таком случае, вы еще не уперлись в производительность процессора и оперативы?

Может стоит поднять кластер серверов, а к этому калстеру уже диски мастырить.

Со временем при поиске всех строк подключений и т.п. которые вшиты в кучу софта наверняка к этому и придем.

Алексей КуренковThe Dim!В таком случае, вы еще не уперлись в производительность процессора и оперативы?

Может стоит поднять кластер серверов, а к этому калстеру уже диски мастырить.

Со временем при поиске всех строк подключений и т.п. которые вшиты в кучу софта наверняка к этому и придем.

Средняя загрузка CPU в районе 20%. Оперативы пока 4Гб - стоит старый MSSQL2000. Сейчас готовимся к переходу на MSSQL2008 на серваке 128Гб оперативы - думаю хватит, на 4х работал

The Dim!А зачем при таких вводных столько дисков?

Не понял вопрос - вводных чего?
Ну а обоснование количества дисков - весьма субъективно в моем случае получилось. На текущем хранилище постоянные дисковые очереди - пользователи жалуются. Как я уже и писал 12 активных пользовательских баз данных, perfmon показывает постоянную активность этих баз + диская активность tempdb. Очевидная необходимость добавления дисков и разнесения баз по своим шпинделям. Приобретать 24 дисковую полку - лучше чем было. Но при этом пока мне сложно спрогнозировать достаточно этого будет или нет - руководство выделило средства на 48 дисковое хранилище, которое уже в наличии. Исходя из этих предпосылок и возникла задача "нехватки буков". Могу предположить что вероятнее всего и можно будет скомпоновать хранилище задействуя ['A:'-'Z', ^'C:'] оставшиеся диски использовать либо в RAID10 либо другим серверам. Но тем не менее, готовность к большему в любом случае должна быть. И все таки решить такой вопрос лучше заранее чем в боевых условиях.

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 и в ней нормально можно размещать файлы баз данных.