SQL Server: файловая группа только для системных таблиц?

11

Одним из наших корпоративных стандартов является отдельная файловая группа / файл для пользовательских таблиц / индексов. Это установлено по умолчанию, поэтому нет необходимости квалифицировать операторы CREATE TABLE.

Так это выглядит

fileid 1 = системные таблицы, MDF
fileid 2 = t-log = LDF
fileid 3 = пользовательский материал = NDF

Может ли кто-нибудь здесь помочь мне понять первоначальное обоснование, почему это было предписано?

Я приду чисто и скажу, что я думаю, что это вуду. Am Я не так ...?

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

sql-server filegroups disk-structures

— ГБН
источник

9

Учебное пособие Microsoft 70-432 гласит: «Основная причина не помещать какие-либо ваши объекты в первичную файловую группу - это обеспечить как можно большую изоляцию при вводе / выводе. Данные в системных объектах меняются не так часто, как данные в ваших объектах. Минимизируя активность записи в первичный файл данных, вы уменьшаете вероятность появления повреждений из-за аппаратных сбоев. Кроме того, поскольку состояние первичной файловой группы также определяет состояние базы данных, вы можете увеличить доступность базы данных, сводя к минимуму изменения, внесенные в первичную файловую группу. "

Итак, примите это как хотите. Другие говорят, что в определенных обстоятельствах это не нужно и, конечно, нужно больше поддерживать. Просто подумал, что предоставлю обоснование Microsoft.

— Джаред
источник

Разумное, какое-то письменное обоснование для этого. Я приму это

— gbn

1

Другая причина заключается в том, что восстановление базы данных PARTIAL позволяет восстановить файловую группу PRIMARY плюс выбранные другие файловые группы, что позволяет быстрее восстанавливать правильно спроектированный VLDB. Позволяет восстановить архивные / вторичные файловые группы позже.

— MartinC

@MartinC: я знаю о частичном восстановлении и т. Д., Но я никогда не понимал логику явного разделения системных таблиц. Файловые группы для производительности, архивирования, обслуживания, разбиения и т. Д. Но системные таблицы? Джаред предложил лучшее объяснение до сих пор ..

— ГБН

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

— MartinC

12

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

Если это - то, почему они заявляют это, я не могу сказать, но это было бы преимуществом наличия нескольких групп файлов только с системными объектами в файловой группе PRIMARY.

Тем не менее, вы должны пнуть в мусорное ведро, сказав, что AutoShrink должен быть включен.

— mrdenny
источник

Чтобы узнать больше об этом, вы можете найти онлайн восстановление кусочка в Books Online.

— Брент Озар

1

Я всегда думал, что это тоже вуду, учитывая, что две файловые группы находятся на одном томе (в сети SAN). Является ли риск коррупции таким высоким? (Фактический эксплуатационный АБД установить Autoshrink ложь)

— GBN

Скорее всего, если будет повреждение, это будет одна страница в одном файле, так как хранилище будет работать при записи страницы на диск. Что-то вроде 99,9999% повреждения базы данных является проблемой хранения. Половина остальных проблем - плохая память, остальные - ошибки SQL. По мере того, как базы данных становятся больше (мульти-ТБ), это становится более важным, так как восстановление мульти-ТБ базы данных займет несколько дней.

— Мрденный

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

— Элли Рейли

4

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

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

— SQLRockstar
источник

Спасибо. Не оправдывай, а объясни. Это та же команда разработчиков БД, которая говорит AutoShrink. Учитывая, что системные таблицы занимают несколько мегабайт и в любом случае будут в памяти, вы верите в какой-нибудь прирост производительности?

— ГБН