Я отправил это в переполнение стека (Вот), но понял, что это действительно должно быть на сервере. поэтому извиняюсь за неправильную и повторяющуюся публикацию:
Хорошо, я только что прошел курс SQL Server, и мы обсудили сценарии использования нескольких файловых групп и файлов при использовании на локальном RAID и локальных дисках, но мы не касались сценариев SAN, поэтому мой вопрос следующий;
В настоящее время у меня есть 250-гигабайтная база данных, работающая на SQL Server 2005, где некоторые таблицы имеют огромное количество операций записи, а другие довольно статичны. База данных и все объекты находятся в одной файловой группе с одним файлом данных. Файл журнала также находится на том же томе. Я считаю, что отдельные файлы данных должны использоваться на разных дисках, чтобы уменьшить конкуренцию за диск, и что группы файлов должны использоваться для разделения данных. Однако с SAN у вас, очевидно, действительно нет той же проблемы с конкуренцией за диск, что и с небольшой настройкой RAID (или, по крайней мере, у нас нет в данный момент), а стандартная версия не поддерживает разделение.
Что мне делать, чтобы улучшить параллелизм?
Насколько я понимаю, различные публикации Microsoft заключаются в том, что если я увеличиваю количество файлов данных, отдельные потоки могут работать с каждым файлом отдельно. Это приводит меня к вопросу, сколько файлов у меня должно быть. По одному на ядро? Должен ли я помещать таблицы и индексы с высоким уровнем активности в отдельные группы файлов, каждая с тем же количеством файлов данных, что и у нас в ядрах?
Спасибо
Каждая файловая группа должна иметь X файлов данных и журналов, где X - количество видимых ядер диспетчера задач - это обеспечивает оптимальное поведение ввода-вывода.
Это особенно важно для tempdb - файлы иногда полностью блокируются для SQL Server, когда выделяются / освобождаются экстенты (группы по 8 страниц). Tempdb покрывает МНОГО объектов.
Распространение на несколько дисков имеет смысл только для лучшего ввода-вывода. Хорошая SAN - может перегрузить выдающиеся возможности драйвера ввода-вывода (длина очереди часто достигает 256 PER DISC), поэтому для хорошей SAN может потребоваться несколько дисков, чтобы поддерживать достаточное количество невыполненных операций ввода-вывода для его полного использования.
Но даже без хорошего SAN несколько файлов позволяют избежать узкого места, связанного с доступом к одному файлу при вставке и т. Д.
Наличие большего количества X не имеет смысла - максимально каждое ядро может запускать один поток в данный момент. Распределение является атомарным, поэтому каждое ядро не будет переключать потоки при этом. Но всем X-ядрам может потребоваться расширение одновременно;)
Что важно: правильно форматируйте диски. Убедитесь, что разделы (до сервера 2008) выровнены, убедитесь, что вы форматируете диски с размером узла 64 КБ - в противном случае вы можете потратить до 40% производительности ввода-вывода прямо здесь.
Разметка в эту игру вообще не входит;)
Вы должны тщательно взвесить погоду, чтобы использовать несколько файлов, чтобы избежать конфликта за выделение (т.е. не распределять их на несколько шпинделей) или нет. Специально для tempdb. После того, как лучшая практика была изначально опубликована, некоторые вещи изменились в способе работы движка, а также улучшилось общее понимание проблемы.
Краткая версия заключается в том, что вам действительно следует провести некоторое тестирование, чтобы увидеть, действительно ли у вас есть такая проблема конкуренции. Вы можете прочитать больше в этом посте (и связанных ссылках):