Зачем нам нужны вторичные файлы данных в SQL Server? - PullRequest
4 голосов
/ 10 ноября 2009

Я всегда игнорирую эту опцию при создании новой базы данных на SQL Server 2005 просто потому, что мы можем игнорировать что-то, чего мы не понимаем, и оставить все как есть. (Я не очень в DBA)

так что теперь мне интересно, о чем это.

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

Ответы [ 3 ]

3 голосов
/ 10 ноября 2009

Множество случаев, когда это может быть полезно - для начала, из соображений доступности, всегда лучше хранить только системные данные в первичном файле данных (с Sql2k5 и выше, при условии, что первичный файл данных доступен, база данных может быть подключенным к сети, что позволяет вам восстанавливать / восстанавливать / и т. д. несистемные данные, имея при этом как можно больше данных в сети). Некоторые другие случаи использования вторичного файла (ов):

  1. Разделение данных на несколько LUN
  2. Разрешение частичное / резервное копирование файловой группы / восстановление
  3. Сегментирование ваших различных типов доступа для чтения / записи по разным LUN (т.е. последовательный или случайный)
1 голос
/ 10 ноября 2009

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

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

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

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

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

0 голосов
/ 15 ноября 2009

Одна из главных причин - ввод / вывод. Возможность разбивать ваши данные означает, что ввод / вывод теперь распределен по нескольким дискам / лунам / и т. Д. что может существенно повысить производительность.

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