SQL Server 2005 / 2008-несколько файловых групп?
Я разработчик в глубине души , но время от времени у клиента нет достойного DBA для решения этих проблем, поэтому меня вызывают, чтобы решить....
каковы ваши стратегии / рекомендации, когда дело доходит до работы с базой данных SQL Server разумного размера (что - либо большее, чем Northwind или AdventureWorks) - вы используете несколько файловых групп? Если да, то сколько? И почему?
каковы ваши критерии, чтобы решить, когда отойти от " одной файловой группы для все " подходим:
- размер базы данных?
- сложность базы данных?
- требования к доступности / надежности?
- что еще?
Если вы используете несколько групп файлов, сколько вы используете? Один для данных, один для индекса, один для журнала? Несколько (сколько) для данных? Каковы причины вашего выбора -почему вы используете это точное количество файловых групп: -)
6 ответов
методология Microsoft trained and best practice выглядит следующим образом:
- файлы журналов размещаются на отдельном физическом диске
- файлы данных размещаются на отдельном физическом диске
- несколько групп файлов: когда конкретная таблица очень большая. Часто бывает в транзакционной базе данных (отдельный физический диск)
- несколько групп файлов: при использовании диапазонов или при желании разделить данные поиска в файл базы данных только для чтения (Отдельный Физический Диск)
имейте в виду, что МДФ технически работает аналогично разделу жесткого диска, когда дело доходит до хранения данных. MDF-это файл случайного чтения, а LDF-файл последовательного чтения. Поэтому разделение их на отдельные диски вызывает огромный прирост производительности, если только не работают твердотельные диски, и в этом случае выигрыш все еще существует.
там по крайней мере один хорошая причина наличия нескольких (по крайней мере двух) файловых групп в SQL Server 2008 : если вы хотите использовать функцию FILESTREAM, вы должны иметь выделенную и пользовательскую файловую группу для данных FILESTREAM :-)
Марк
поддержка нескольких файловых групп помогает снизить нагрузку на ввод-вывод. Это также позволяет гибкость хранения, где вы можете создать резервную копию файловой группы легко, а не один файл и разделить их на отдельный диск для каждой группы файлов.
обычно у вас должна быть только одна основная файловая группа и один файл журнала.
иногда, когда у вас есть очень статические данные, вы можете создать второй файловая группа, содержащая эти статические данные. Затем вы можете создать файловую группу только для чтения что улучшает вашу производительность. В конце концов, это довольно статичные данные. Это не стоит того, если у вас есть низкое количество строк только для чтения (например. значения таблицы поиска). Но для некоторых вещей (например. архивы содержимого еще можно читать), то это может быть отличным вариантом.
Я получил идею от этот блог.
HTH.
Я работал над хорошим диапазоном DBs, и единственный раз, когда мы использовали файловые группы, был, когда на диске не хватало места, и нам пришлось создать новую файловую группу на другом шпинделе. Я уверен, что есть хорошие причины для производительности, почему это не идеально, но это была реальность.
среди других причин дополнительные файловые группы имеют смысл, если вы хотите разбить таблицу. и это имеет смысл, если есть много конкурирующих чтений с разными где-условиями этой таблицы. вы можете настроить каждый раздел так, чтобы он отражал одно такое условие where и располагался на другом диске, тем самым отправляя каждое чтение на другой диск, таким образом, параллельные чтения и меньше конфликтов.