Добрый день. Подскажите у кого был опыт практический или какие альтернативы может быть есть драйвера или еще что.
Вопрос в следующем:
дисковое хранилище для 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 либо другим серверам. Но тем не менее, готовность к большему в любом случае должна быть. И все таки решить такой вопрос лучше заранее чем в боевых условиях.