Мы приобрели новый сервер, который будет выступать в роли серверной части MS SQL. Мне любопытно узнать, какая для него лучшая установка.
Сервер Dell R710 имеет 6 жестких дисков: 2x 74 ГБ 15k и 4x 146GB 15k
В настоящее время это настроено в конфигурации RAID 1 / Raid10.
У меня вопрос: куда (какой массив) должно идти следующее?
TEMPDB (также сколько, размер и рост) Системные БД (главная, модель и т. Д.) Application MDFs Application LDFs System Page file
ОС уже установлена на RAID1.
Некоторое время назад я провел небольшое исследование об оптимизации tempdb и ответил на свой собственный вопрос по Stackoverflow. Вот что я выяснил.
Чтобы оптимизировать производительность базы данных tempdb, обратите внимание на конфигурацию физического диска, конфигурацию файлов, а также на некоторые настройки в базе данных.
Конфигурация физического диска
tempdb должен находиться на его собственные выделенные физические диски. Это позволяет ему отделить транзакции ввода-вывода от остальных томов на SQL Server.
Чтобы переместить базу данных tempdb на новый диск, используйте ALTER DATABASE. Это ключевая команда T-SQL для выполнения этой операции. Microsoft предлагает хороший пример в электронной документации по SQL Server 2005. Название статьи - ALTER DATABASE (Transact-SQL), а конкретный раздел - 'ГРАММ. Перемещение базы данных tempdb в новое место. '
Tempdb - это база данных с очень большим объемом записи. Итак, массив RAID 5 - неподходящее место для этого. Вы должны поместить tempdb на массиве RAID 1 или RAID 10 поскольку они оптимизированы для приложений с высокой скоростью записи. Если вы можете позволить себе дополнительные массивы RAID 1 или RAID 10 для каждого физического файла базы данных для tempdb, вы получите повышенную производительность.
Файлы базы данных
У вас должно быть один физический файл на каждое ядро ЦП на сервере. Итак, если у вас двухчиповый двухъядерный сервер, у вас должно быть четыре физических файла базы данных для базы данных tempdb. При добавлении дополнительных файлов базы данных важно настроить файлы на тот же начальный размер и с такими же настройками роста. Таким образом, SQL Server будет записывать данные в файлы как можно более равномерно.
Размер файла базы данных
Размер базы данных tempdb может повлиять на производительность системы. Например, если размер, определенный для tempdb, слишком мал, часть нагрузки на обработку системы может быть загружается с помощью автоматического увеличения tempdb до размера, необходимого для поддержки рабочей нагрузки, каждый раз, когда вы перезапускаете экземпляр SQL Server. Вы можете избежать этих накладных расходов, увеличив размеры файла данных и журнала tempdb.
Определение подходящего размера для tempdb в производственной среде зависит от многих факторов, включая существующую рабочую нагрузку и используемые функции SQL Server. Microsoft рекомендует проанализировать существующую рабочую нагрузку, выполнив следующие задачи на SQL Server. тест Окружающая среда:
Ниже приведены рекомендации по минимальному размеру базы данных tempdb:
Envir. Size DB Size (MB) Log Size (MB) ----------- ------------ ----------- Small 1024 256 Medium 5120 1024 Large 10024 2048
Настройки базы данных
Вы можете дополнительно увеличить производительность tempdb, отключение автоматического обновления статистики, что избавит вашу tempdb от работы. Вы также можете установить опция автоматического создания статистики на false.
Отказ от ответственности: настройки следует изменять осторожно. В зависимости от типа нагрузки, которую вы помещаете в свою базу данных tempdb, изменение настроек может отрицательно сказаться на производительности системы.
Для достижения оптимальной производительности tempdb следуйте руководствам и рекомендациям, приведенным в Оптимизация производительности tempdb.
Как отслеживать использование tempdb?
Бег не хватает места на диске в tempdb жестяная банка вызывать значительные сбои в производственной среде SQL Server и может препятствовать выполнению операций запущенными приложениями.
Вы можете использовать sys.dm_db_file_space_usage динамическое представление управления для мониторинга дискового пространства, используемого этими функциями в файлах tempdb. Кроме того, для отслеживания активности выделения или освобождения страниц в базе данных tempdb на уровне сеанса или задачи вы можете использовать sys.dm_db_session_space_usage и sys.dm_db_task_space_usage динамические представления управления.
Эти представления можно использовать для идентификации больших запросов, временных таблиц или табличных переменных, которые используют много дискового пространства tempdb. Также есть несколько счетчиков, которые можно использовать для отслеживания свободного пространства, доступного в tempdb, а также ресурсов, использующих tempdb.
Ссылки:
Я бы поместил ОС, файл подкачки и LDF в массив RAID1. Все остальное на массиве RAID10.
Если вы не используете Windows 2008, убедитесь, что ваши разделы правильно выровнены:
http://msdn.microsoft.com/en-us/library/dd758814.aspx
Как уже объяснялось, добавьте 1 файл TEMPDB на каждое ядро процессора - сделайте их всех одинакового размера.
Подберите размер файлов журнала и создайте их за один шаг.
Если возможно, подумайте о резервном копировании ваших баз данных на другой сервер через общий сетевой ресурс - чтобы снизить риск полного отказа вашего массива и унесения с собой базы данных и резервных копий.
Простой общий ответ: все, что связано с большим объемом операций ввода-вывода, должно попадать в группу дисков RAID 10. Вы также определились со своей стратегией разделения или с этой частью вопроса?
Итак, в вашей первой группе дисков я бы, вероятно, создал один раздел (около 70 ГБ), на котором я бы разместил ОС и приложение MSSQL.
На втором я бы создал следующие разделы
1) раздел для файла подкачки (в зависимости от имеющегося у вас объема памяти, но около 10-20 ГБ 2) раздел для файлов журнала транзакций 100 ГБ 3) раздел для файлов данных 100 ГБ
Это оставит вам около 50 ГБ свободных, которые я бы оставил неназначенными, чтобы вы могли увеличивать либо раздел журнала, либо раздел данных по мере изменения ваших требований.
Интересно, что в настоящее время я работаю на той же машине со спецификациями, только я использую Linux и Oracle, вы из параллельной вселенной?
Джеймс
Пока было несколько отличных ответов, поэтому я не буду утруждать себя ответом на них, но задам вам вопрос.
Почему вы не задали этот вопрос перед покупкой сервера? Почему вы пытаетесь втиснуть систему в уже купленный сервер, вместо того, чтобы покупать сервер, отвечающий потребностям системы?
Извините, я задал этот вопрос как незарегистрированный пользователь и теперь не могу отметить его как ответ. Я жду ответа от администраторов, чтобы узнать, смогут ли они снова привязать мою учетную запись к вопросу.
Чтобы дать некоторое представление о том, что этот сервер не будет испытывать огромной нагрузки, на самом деле это серверная часть системы управления версиями. Покупка сервера и DAS, или ISCSI SAN, или чего-то подобного, была бы лишней, а стоимость сокрушила бы шансы проекта. Я работаю в СМБ, где работает около 100 человек, поэтому наш ИТ-бюджет ограничен, особенно сейчас.
@mrdenny
Мы задали вопрос поставщику программного обеспечения, который рекомендовал эту конфигурацию. Мы купили его тогда, когда поставили квест, который я здесь спросил, они сказали, что нужно поместить журнал, базы данных и временные базы данных на раздел raid 10. Я не большой любитель DB (правда ??), но это прозвучало подозрительно, так как почти все знают, что нельзя смешивать ваши ldf и mdf на одних и тех же шпинделях.
@splattne - Спасибо за понимание базы данных tempdb, это пригодится для этой и будущих установок SQL.
@SuperCoolMoss - Я разговаривал с некоторыми людьми в моей собственной сети ИТ, и они согласны с вами в этом. ОС, файл подкачки и LDF на RAID1 и tempdb и MDF на RAID10
Спасибо всем, кто прокомментировал.
Насколько я знаю, это основные правила, которые, как мне кажется, вы должны соблюдать при развертывании SQL, когда дело касается дисков. На мой взгляд, они должны выполняться именно в таком порядке. Дайте мне знать, если вы согласны или не согласны.
Не стесняйтесь поделиться своей измененной версией этого списка.
Какая производительность вам нужна? На основании «вот диск» сложно дать ответ. Кроме того, производительность SQL намного выше, если вы можете поместить все свои данные в кеш, поэтому убедитесь, что у вас достаточно оперативной памяти.
Я бы выбрал ОС и файл подкачки на ваших томах 2x74 ГБ. Если вы попадаете в ситуацию, когда у вас большой трафик журналов, вы можете разделить свой рейд 10 на пару рейдов 1 и разместить там свои журналы.
Очевидно, что из-за «лучшей» компоновки ведется много религиозных войн, но у вас действительно недостаточно дисков для перемещения. Нет смысла разбивать ваши диски с данными, потому что вас действительно волнует количество шпинделей, а вы ограничены тем, что вы можете разместить на сервере.
Возможно, вам будет лучше получить PowerVault или что-то подобное и переработать диски 146 ГБ в него (вместе с таким количеством других дисков, которое может поместиться) и разделить их на тома data / logs / system + tempdb.
Я бы начал со сбора статистики ввода-вывода из старой системы. Например, начните с отчетов Performance Dahsboard: http://www.microsoft.com/downloads/details.aspx?FamilyId=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en Это даст вам статистику операций ввода-вывода для ваших баз данных, и тогда вы сможете принять обоснованное решение, а не универсальный совет «под одну гребенку». Конечно, старый сервер может иметь разные характеристики ввода-вывода для каждой базы данных, чем новый, особенно если доступен другой объем оперативной памяти. Все же лучше, чем просто предположение.
В идеале одна цель - разделить файлы ввода-вывода с более высокой нагрузкой на их собственные устройства, а также не желать смешивать случайный ввод-вывод доступа MDF с линейной записью доступа LDF. В вашем случае комбинаций просто не так много, у вас действительно всего 2 места (2 диска в RAID1 и 4 в RAID10). Вы можете суммировать ввод-вывод для каждой базы данных, собранный со старого сервера, а затем разделить местоположения файлов, чтобы он распределял ввод-вывод между двумя местами назначения в соотношении, вероятно, 1/5 на RAID1 и 4/5 на RAID10 (для учета для ОС и файла подкачки IO на RAID1). Надеюсь, у вас нет приложения с интенсивной записью (высокая последовательная нагрузка записи LDF) ...
Обычно рекомендуется, чтобы макет TempDB составлял 1 NDF на планировщик (ядро ЦП не замаскировано), причем все они имеют одинаковый размер, причины объясняются здесь: http://blogs.msdn.com/sqlserverstorageengine/archive/2009/01/04/managing-tempdb-in-sql-server-tempdb-configuration.aspx. Это устраняет разногласия по поводу распределения страниц, которые могут быть серьезной проблемой при высокая нагрузка на SQL 2K, меньше под 2k5 и еще меньше на 2k8. Но, учитывая, что его настройка практически ничего не стоит, вы все равно должны это сделать.
На самом деле это не очень быстрая дисковая система. Полные благодарности splattne за потрясающий ответ, но на самом деле это не очень быстрая установка диска, поэтому я не уверен, сколько проблем это стоит того.
Двухдисковый RAID1 дает небольшое увеличение производительности по сравнению с одним диском без рейки. Четырехдисковый RAID10 дает вам скорость двухдискового RAID0, который быстр, но не так уж хорош. Это не медленный сервер, но и не очевидный кандидат для работы с действительно требовательной базой данных SQL.
Если бы это был мой сервер, я бы нашел еще два диска по 146 ГБ и сделал бы его шестидисковым RAID5. Хорошо, меня будут кричать за установку tempdb на том же шпинделе (ах), что и файлы данных, но контроллеры Perc очень хороши в RAID5, а RAID5 с шестью дисками будет настолько быстрым, что вы (вероятно) получите лучшая производительность, чем у tempdb на RAID1 и всего 4 диска в RAID5. Я говорю «вероятно», потому что, как и все, это зависит от того, как вы его загрузите.
JR