Наші повні (і періодичні диференціальні) резервні копії стають досить великими, в основному за рахунок кількості індексів на наших таблицях; приблизно половина розміру резервної копії складається з індексів.
Ми використовуємо просту модель відновлення для резервного копіювання.
Чи можна за допомогою FileGroupsабо іншого методу розділення файлів виключити індекси з резервних копій?
Було б непогано, якби це можна було поширити і на повнотекстові каталоги.
Відповіді:
Якщо ви перейдете в режим повного відновлення, ви можете зробити це за допомогою файлових груп, але це дійсно, дуже незграбно. Ви залишаєте дані в основній групі файлів, а індекси поміщаєте в окрему (не за замовчуванням, це ключова) група файлів.
Потім ви розміщуєте свої резервні копії так, щоб ви робили резервні копії файлових груп первинних щовечора, і резервні копії журналу транзакцій кожні X хвилин.
Під час катастрофи ви відновлюєте основну групу файлів самостійно. Дані раптово в Інтернеті, але індекси - ні. Однак, щоб повернутися до нормального стану, вам потрібно буде експортувати ці дані в нову чисту базу даних і звідти додати індекси. Ви не можете повністю підключити базу даних до Інтернету, не відновивши всі групи файлів, і ви не можете сказати: "Мені вже не потрібна ця інша файлова група".
Щоб дізнатися більше про те, як це працює, перегляньте мій відео-посібник про відновлення файлових груп.
Чесно кажучи, ти справді не хочеш цього робити, навіть якщо ти подолаєш інші питання, які тут виникають інші.
Коли ви відновите резервну копію в екстреному випадку, ви не хочете чекати відновлення індексів, і ви будете страждати від гнучкої продуктивності, поки цього не зробите.
Я не можу придумати ситуацію, коли ви хочете відновити резервну копію без індексів, тому у всіх випадках ви дійсно захочете їх одночасно створити резервну копію.
Ймовірно, вам доведеться шукати інші рішення цієї проблеми ...
-Адам
Здається, це не підтримується. З цієї інформації про звіт про помилку :
Цей інтерес викликав велику зацікавленість, тому я розповім трохи детальніше про те, що відбувається за лаштунками, і що означатиме реалізація цієї функціональності. Деякі типи сторінок індексу поділяються на окремі розподільні одиниці, а інші змішуються зі сторінками даних. Де ми зараз дивимося лише на біт-карту розподілу, щоб побачити, чи виділяється масштаб, тепер нам доведеться зайти і інтерпретувати те, що зберігається у кожному блоці розподілу. Далі ми зараз не зможемо виконати лінійне сканування файлів даних, що копіюють дані, ми пропустили б файл. Вся ця інтерпретація структур даних різко уповільнить резервне копіювання. Відновлення стає ще цікавішим, оскільки існує багато структур, які доведеться зафіксувати, щоб врахувати отвори в резервній копії. Інакше ви мали б виділити карти розподілу, які вказують на сторінки, які не були резервні копії, і в них є сміття тощо. Отже, впроваджуючи це, ми б економили менше даних, займемо більше часу та займемо багато довше відновлюючи його. Інший аспект, який слід врахувати, полягає в тому, що для знаходження цього потрібно значні зусилля інженерії. Незважаючи на те, що це не ваша проблема на поверхні, врахуйте, що це означає, що інші функції, які ви, можливо, хочете побачити, не будуть вбудовані.
може бути шаленою ідеєю, але ось іде.
Звичайно, ви можете реально це зробити, лише якщо база даних дозволяє певний час простою в день.
Крім того, не кидайте кластеризовані індекси, оскільки SQL Server витратить багато часу на перетворення їх у купу.
Чи здається, що придбання цього додаткового простору на диску є більш простим рішенням?
Чи думали ви робити стиснуті резервні копії ? це нова особливість 2008 року, можливо, це варіант для вас.