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