SQL Server 2005 / 2008-несколько файловых групп?

Я разработчик в глубине души , но время от времени у клиента нет достойного DBA для решения этих проблем, поэтому меня вызывают, чтобы решить....

каковы ваши стратегии / рекомендации, когда дело доходит до работы с базой данных SQL Server разумного размера (что - либо большее, чем Northwind или AdventureWorks) - вы используете несколько файловых групп? Если да, то сколько? И почему?

каковы ваши критерии, чтобы решить, когда отойти от " одной файловой группы для все " подходим:

  • размер базы данных?
  • сложность базы данных?
  • требования к доступности / надежности?
  • что еще?

Если вы используете несколько групп файлов, сколько вы используете? Один для данных, один для индекса, один для журнала? Несколько (сколько) для данных? Каковы причины вашего выбора -почему вы используете это точное количество файловых групп: -)

13
database-design filegroup sql-server sql-server-2005 sql-server-2008

6 ответов

методология Microsoft trained and best practice выглядит следующим образом:

  • файлы журналов размещаются на отдельном физическом диске
  • файлы данных размещаются на отдельном физическом диске
  • несколько групп файлов: когда конкретная таблица очень большая. Часто бывает в транзакционной базе данных (отдельный физический диск)
  • несколько групп файлов: при использовании диапазонов или при желании разделить данные поиска в файл базы данных только для чтения (Отдельный Физический Диск)

имейте в виду, что МДФ технически работает аналогично разделу жесткого диска, когда дело доходит до хранения данных. MDF-это файл случайного чтения, а LDF-файл последовательного чтения. Поэтому разделение их на отдельные диски вызывает огромный прирост производительности, если только не работают твердотельные диски, и в этом случае выигрыш все еще существует.

13

там по крайней мере один хорошая причина наличия нескольких (по крайней мере двух) файловых групп в SQL Server 2008 : если вы хотите использовать функцию FILESTREAM, вы должны иметь выделенную и пользовательскую файловую группу для данных FILESTREAM :-)

Марк

3

поддержка нескольких файловых групп помогает снизить нагрузку на ввод-вывод. Это также позволяет гибкость хранения, где вы можете создать резервную копию файловой группы легко, а не один файл и разделить их на отдельный диск для каждой группы файлов.

3

обычно у вас должна быть только одна основная файловая группа и один файл журнала.

иногда, когда у вас есть очень статические данные, вы можете создать второй файловая группа, содержащая эти статические данные. Затем вы можете создать файловую группу только для чтения что улучшает вашу производительность. В конце концов, это довольно статичные данные. Это не стоит того, если у вас есть низкое количество строк только для чтения (например. значения таблицы поиска). Но для некоторых вещей (например. архивы содержимого еще можно читать), то это может быть отличным вариантом.

Я получил идею от этот блог.

HTH.

1

Я работал над хорошим диапазоном DBs, и единственный раз, когда мы использовали файловые группы, был, когда на диске не хватало места, и нам пришлось создать новую файловую группу на другом шпинделе. Я уверен, что есть хорошие причины для производительности, почему это не идеально, но это была реальность.

0

среди других причин дополнительные файловые группы имеют смысл, если вы хотите разбить таблицу. и это имеет смысл, если есть много конкурирующих чтений с разными где-условиями этой таблицы. вы можете настроить каждый раздел так, чтобы он отражал одно такое условие where и располагался на другом диске, тем самым отправляя каждое чтение на другой диск, таким образом, параллельные чтения и меньше конфликтов.

0