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: Я знаю про часткове відновлення тощо, але я ніколи не розумів логіку явного поділу системних таблиць. Групи файлів для виконання, архівування, обслуговування, розділення тощо. Але системні таблиці? Джаред запропонував найкраще пояснення дотепер ..

— gbn

Якщо база даних в цілому дуже велика, первинна файлова група може мати більш регулярне резервне копіювання, ніж основні дані. Для відновлення потрібна буде лише резервна копія журналу хвоста та відновлення первинної файлової групи та журналів транзакцій, оскільки резервна копія групи файлів плюс хвіст. Оскільки системні таблиці невеликі, це був би швидший процес відновлення порівняно з цим для всієї бази даних, так що це може скоротити час простою в разі виникнення проблеми.

— MartinC

12

Це не приріст ефективності для цього, потрібно досягти відновлення. Якщо у системних таблицях відбувається пошкодження файлів, то база даних втрачається. Якщо ви зберігаєте дані користувача в окремій групі файлів (або групах), тоді ви можете відновити лише ті файли, що зберігають решту бази даних в режимі онлайн під час відновлення (припускаючи Enterprise Edition тут).

Якщо це те, чому вони заявляють це, я не можу сказати, але це було б користю від наявності декількох груп файлів із лише системними об'єктами в PRIMARY файловій групі.

Однак вам слід ударити в сміття, сказавши, що функцію AutoShrink слід включити.

— мрденний
джерело

Щоб дізнатися більше про це, ви можете шукати Відновлення в Інтернеті за допомогою Piecemeal в Книгах Інтернет.

— Брент Озар

1

Я завжди думав, що це теж вуду, враховуючи, що 2 групи файлів мають однаковий об'єм (у SAN). Чи ризик корупції такий високий? (Фактичні діючі DBA встановили AutoShrink неправдивим)

— gbn

Шанси є, якщо є корупція, це буде одна сторінка в одному файлі, так як сховище буде примусово записувати сторінку на диск. Щось на зразок 99,9999% пошкодження бази даних - це проблема зберігання. 1/2 решти проблем - це погана пам'ять, решта - помилки SQL. У міру збільшення баз даних (мультитуберкульозних) це стає більш важливим, оскільки відновлення бази даних з багатьма ТБ займе кілька днів.

— mrdenny

Хіба я не маю рації, думаючи, що якщо системні об'єкти знаходяться лише в первинній групі файлів, якщо вам потрібно, в майбутньому ви зможете зробити наступне. Створіть додаткові файли x в іншій групі файлів. Пропорційно заповнюйте ці файли, переміщуючи свої дані з існуючого файлу даних?

— Еллі Рейлі

4

Не впевнений, що я розумію, ти просиш когось виправдати твій корпоративний стандарт? Я б подумав, що той, хто написав, що стандарт Doc для вашої компанії, зможе пролити трохи світла на те, чому це буде зроблено.

Незважаючи на це, для деяких магазинів незвично, що вони хочуть вивести системні дані з даних користувачів. І якщо використовувати їх разом із виділеними наборами дисків, ви можете отримати певні підвищення продуктивності.

— SQLRockstar
джерело

Дякую. Не виправдовуйте це, а поясніть. Це та сама команда DB Engineering, яка говорить про включення AutoShrink. Враховуючи, що системні таблиці займають декілька МБ і все одно залишаться в пам’яті, чи вірите ви в будь-яке підвищення продуктивності?

— gbn