Файл и файловая группа SQL Server - PullRequest
4 голосов
/ 23 февраля 2009

Я не могу придумать каких-либо причин, почему нам нужно иметь несколько файлов внутри файловой группы. Причина, по которой я так думаю, заключается в том, что мы можем контролировать уровень файловой группы на уровне T-SQL (конечный пользователь), но не можем контролировать уровень отдельных файлов файловой группы на уровне T-SQL (конечный пользователь). Любые комментарии или идеи, почему файлы все еще нужны?

спасибо заранее, George

Ответы [ 3 ]

5 голосов
/ 23 февраля 2009

Наличие нескольких файлов на группу файлов полезно только по следующим причинам:

  1. Распределение дискового ввода-вывода по нескольким дискам по соображениям производительности. то есть в тех случаях, когда перенастройка конфигурации RAID с дополнительными дисками невозможна или отсутствует RAID.
  2. В тех случаях, когда у вас есть VLDB и вы не хотите иметь дело с очень большими отдельными файлами по логистическим причинам.

Существует «городская легенда» о том, что SQL Server использует только 1 поток на файл, поэтому количество файлов должно соответствовать количеству процессоров. Это, однако, неверно, так как обсуждается Microsoft здесь .

Исторически, есть другая причина. Верьте или нет, во времена SQL Server с 4.2 по 7 sql сервер иногда устанавливался в файловых системах FAT32, которые имели ограничение в 4 гигабайта. Возможность объединять файлы в цепочки (в том, что мы сейчас называем файловыми группами) - это способ обойти ограничения файловой системы и позволить устанавливать базы данных размером более 4 гигабайт при установке на основе FAT.

2 голосов
/ 29 апреля 2013

старый поток, я знаю, но вот что имеет смысл для меня: в те времена максимальный размер файла в файловой системе Windows FAT32 составлял 2 ГБ. Если ваш файл базы данных стал больше, вы были испорчены (однажды случилось со мной с MS Access-Database). Следовательно, они позволили определить максимальный размер файла (например, 2 ГБ), и вы можете добавить больше файлов. Если ваша база данных увеличилась и максимальный размер превысил, следующий файл заполняется до тех пор, пока он не будет заполнен и так далее. Все эти файлы могут быть адресованы как одна файловая группа. Вы можете определить местоположение данных таблиц, выбрав файловую группу, но вы не видите, в каком файле в этой файловой группе окажутся данные таблицы. Все, что вы знаете, это то, что данные ваших таблиц могут оказаться в любом из файлов внутри файловой группы. При таком «разделении» ваша файловая система никогда не увидит файл, размер которого превышает максимальный размер файла (здесь: 2 ГБ), хотя таблицы в вашей базе данных могут быть во много раз больше. Сегодня настройка нескольких файлов может быть полезна для того, чтобы большие файлы данных «нарезались» на более мелкие части для резервного копирования на основе файлов (спросите у сетевых администраторов, что они хотят, потому что во время резервного копирования запись большого (например, 1 ТБ) файла в раздел занимает много времени, даже в быстром RAID. Все другие операции записи должны были бы ждать долго. Более короткие интервалы ожидания позволяют быстрее выполнять операции с высоким приоритетом). Если вы заботитесь о параллельном доступе к одной и той же таблице, рассмотрите горизонтальное разбиение, как в http://msdn.microsoft.com/en-us/library/ms188730%28v=sql.105%29.aspx., это позволяет распределить данные таблицы по разным жестким дискам, таким как «все продажи января на диске R:», «все продажи Февраль на диске S: ", без создания отдельных таблиц. Во время процедуры разбиения таблицы вы можете определить, какая часть должна идти в какую файловую группу.

1 голос
/ 23 февраля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...