Кто-нибудь знает какую-нибудь хорошую информацию о точках монтирования и SQL Server? У меня есть около 80 баз данных для создания на одном экземпляре SQL, и я пытаюсь выяснить, выиграем ли мы от наличия точки монтирования для каждой базы данных. Или мне просто нужно сделать одну точку монтирования для файлов данных, одну для журналов транзакций и одну для tempdb? Конечно, все это поддерживается SAN высокого класса ...
Спасибо за любой совет или ссылки, которые вы можете предложить!
Точка монтирования для каждой базы данных - это сложный способ справиться с ней. Я предпочитаю простой подход с объемами для
Это упрощает администрирование, так как администратор базы данных SQL имеет четкое указание, куда должны идти различные файлы. им не нужно постоянно гадать о конструкции диска.
Если все тома будут поддерживаться одними и теми же дисками в SAN, вероятно, не будет большой разницы, используете ли вы отдельные точки монтирования, тома или папки для хранения файлов - диски будут общими.
Я также считаю, что инструмент ATTO Disk Benchmark отлично подходит для получения быстрого представления о том, как работает дисковый массив.
Вы имеете в виду представить отдельный виртуальный LUN для каждого data & tlog? для каждой из 80 БД? 160 целей? это не выход. Накладные расходы администратора были бы кошмаром, не говоря уже о том, что в окнах закончились буквы дисков!
Сколько реальных дисков вам нужно использовать в сети SAN? Представьте их вашему серверу SQL Server. Есть много документов по конвенции.
РЕДАКТИРОВАТЬ: точки монтирования в порядке, я запутался с Точки соединения NTFS
Если вы используете точки монтирования с кластеризацией, вам следует прочитать это КБ.
Пока что единственные причины точек монтирования, с которыми я столкнулся, - это то, что у вас закончились буквы диска или вам нужно дать больше места в новом каталоге к существующей букве диска.
Один из наших администраторов сервера предложил это, но затем я нашел документацию, в которой говорилось, что это не помогло с очередью на дисках в 2003 году в кластере.
Лучший способ оценить это - запустить некоторые инструменты для тестирования производительности в обеих конфигурациях и выбрать более производительную конфигурацию. Проверьте эти инструменты.
http://support.microsoft.com/kb/231619
Технический документ о том, что делать перед развертыванием ввода-вывода:
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx
Вам действительно нужно изолировать все эти базы данных? Не могли бы вы использовать более стандартный макет:
Луны F и G содержат все 80 файлов данных / журналов базы данных.
LUN D и E содержат системные файлы и базы данных tempdb для каждого экземпляра.
Каждый LUN должен иметь соответствующее количество базовых дисков, чтобы справиться с требуемым вводом-выводом. Используйте конфигурацию RAID 10 для TempDB и файлов журнала. Если ваши базы данных интенсивно пишут, используйте RAID 10 и для файлов данных, если вы можете себе это позволить.
Убедитесь, что на вашем сервере (ах) достаточно памяти для выполнения необходимых операций чтения.
Не забудьте отформатировать LUN с соответствующим смещением раздела. Рассмотрите возможность использования нескольких карт HBA и активного / активного программного обеспечения для работы с несколькими путями. Отклоните свой кеш SAN в сторону записи.