Моделі відновлення

Модель відновлення конфігурує налаштування бази даних SQL Server так, щоб забезпечити той тип відновлення, який необхідний базі даних (табл 361) Ключові відмінності між різними моделями відновлення повязані з тим, якою мірою в них задіяний журнал транзакцій і які дані в ньому реєструються

Таблиця 361 в SQL Server

Модель

віднов

новления

Опис

Атомар

ність

транзакцій

Живучість транзакцій

Масові операції

(SELECT INTO І BULK INSERT)

Проста

Журнал транзакцій поступово обрізається в контрольних точках

Так

Ні Можна відновити лише останню повну або диференційовану резервну копію

Чи не протоколюються з метою підвищення продуктивності

З неповним протоколюється ованія

Інструкції SELECT INTO І BULK

insert НЕ протоколюються як транзакції

Так

Не завжди Завжди можна відновити останню повну або диференційовану копію Також можливе відновити останній транзакційний архів, якщо не виконувалися масові операції

Тільки зазначені (з метою підвищення продуктивності)

Модель

віднов

новления

Опис

Атомар

ність

транзакцій

Живучість транзакцій

Масові операції (SELECT INTO І BULK INSERT)

&nbsp

Повна

Усі транзакції заносяться в журнал і зберігаються в ньому до виконання резервування журналу транзакцій

Так

Так Можна до будь-якій точці

Виконуються повільніше, ніж при використанні простої моделі або моделі з неповним протоколюванням

&nbsp

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

Проста модель відновлення

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

Так як журнал транзакцій у цій моделі є тільки тимчасовим місцем зберігання, відпадає потреба в його резервуванні Ця модель відновлення має ряд переваг По-перше, журнал транзакцій має маленькі розміри, однак розплачуватися за це доведеться втратою всіх транзакцій, виконаних з моменту останнього повного або диференційованого резервування Вибір простою моделі відновлення функціонально еквівалентний установці у версіях SQL Server 70 і пізніших параметра бази даних truncate log on checkpoints в значення true

План відновлення, заснований на простій моделі, дозволяє виконувати повне резервування раз на тиждень, а диференційоване – наприкінці кожного дня тижня (рис 361) Повна і диференційовані резервні копії замінюються, коли буде виконано наступне повне резервне копіювання

Рис 361 Типовий план відновлення, що використовує просту модель, містить тільки повні і диференційовані копії резервування

Відновлення в простій моделі припускає дві операції

1 Відновлення з останньої повної резервної копії

2 Відновлення з останньої (не обовязково) однієї диференційованої резервної копії

Повна модель відновлення

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

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

Баланс між високим рівнем цілісності транзакцій і продуктивністю можна підтримувати за допомогою розгляду наступних питань

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

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

■ Резервування та відновлення журналу транзакцій буде віднімати більше часу в порівнянні з іншими моделями відновлення У той же час в кризових ситуаціях відновлення всіх даних може виявитися важливішим, ніж економія часу за рахунок часткового відновлення інформації

Повна модель відновлення може використовувати всі пять типів резервування бази даних Типовий графік створення резервних копій наведено на рис 362

Найчастіше повна модель відновлення передбачає виконання повного резервування двічі на тиждень, а диференційованого – наприкінці кожного дня Резервування журналу транзакцій виконується регулярно протягом усього дня при цьому проміжки часу між окремими сесіями можуть коливатися від декількох годин до декількох хвилин

Відновлення бази даних у цій моделі передбачає виконання таких операцій

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Резервування поточного журналу транзакцій

V Якщо пошкоджена дискова підсистема, що містить журнал транзакцій, то ба-

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

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Виконайте відновлення з останньої повної резервної копії

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Виконайте відновлення з останньої диференційованої резервної копії, створеної після виконання останнього повного резервування (якщо така є)

4&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Послідовно відновите всі резервні копії журналу транзакцій, створені з моменту останнього повного або диференційованого резервного копіювання Якщо останньою створеної резервної копією була повна, то її відновлення буде достатньо Якщо останньою створеної резервної копією була диференційована, то перед її відновленням слід виконати відновлення з останньої повної резервної копії

Рис 362 Типовий план відновлення, що використовує повну модель, містить повні, диференційовані і транзакційні резервні копії

Форма відновлення утиліти Management Studio (на ній ми зупинимося трохи пізніше) автоматично допоможе вам вибрати коректний набір резервних копій, так що ваше завдання на практиці виявиться не такою складної, якою здається на перший погляд

Модель з неповним протоколюванням

Модель відновлення з неповним протоколюванням аналогічна повної моделі, за винятком того, що в журнал транзакцій не заносяться наступні операції:

■ масові вставки (з використанням утиліти ВСР)

■ інструкції DML SELECT * INTO

■ операції над особливо великими обєктами WRITETEXT і UPDATETEXT

■ інструкції CREATE INDEX (включаючи індексовані подання)

Так як ця модель відновлення не передбачає протоколювання перерахованих вище операцій, вони виконуються досить швидко У журнал транзакцій заносяться тільки мітки про виконання даних операцій і відслідковуються тільки екстенти (групи з восьми сторінок даних), на які ці операції вплинули Коли журнал транзакцій резервується, в нього копіюються всі ці сторінки на місце зареєстрованих маркерів

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

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

Ця модель відновлення може виявитися корисною тільки в тому випадку, якщо в базі даних виконується велика кількість масових операцій і дуже важливо підвищити їх продуктивність Якщо продуктивність масових операцій в базі даних вас задовольняє, то краще зупинити свій вибір на повній моделі відновлення

Слід зазначити, що проста модель відновлення взагалі не реєструє масові операції

Використання цієї моделі аналогічно установці параметра бази даних Select Into / Bulkcopy в значення true

Установка моделі відновлення

Модель відновлення, встановлена ​​в системній базі model, застосовується до всіх створюваним баз даних Установка моделі відновлення виконується у вкладці Options діалогового вікна Database Properties утиліти Management Studio Щоб відкрити це вікно, клацніть правою кнопкою миші на базі даних і виберіть у контекстному меню пункт Properties

Модель відновлення можна змінити і програмним шляхом для цього використовується інструкція DDL ALTER DATABASE:

ALTER DATABASE імя_ б а зи_да нних SET Recovery параметр

Допустимими параметрами в цій інструкції є наступні: Full, Bulk-Logged і Simple У наступному прикладі модель відновлення навчальної бази даних СНА2 змінюється на повну:

USE СНА2

ALTER DATABASE СНА2 SET Recovery Full

Настійно рекомендується в програмному коді, що створює базу даних, явно вказувати модель відновлення

Поточну модель відновлення, встановлену в базі даних, можна визначити за допомогою подання каталогу sys Database:

SELECT [name], recovery_model_desc FROM sysdatabases

Зміна моделі відновлення

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

Буде абсолютно резонно протягом робочого дня для реєстрації поточних операцій перемикатися на повну модель відновлення, а вечорами замінювати її моделлю з неповним протоколюванням і виконувати необхідні операції імпорту даних

Під час відновлення беруться в розрахунок існуючі повні, диференційовані і транзакційні резервні копії – систему абсолютно не хвилює, як саме вони створювалися

Так як проста модель відновлення не зберігає постійно весь набір транзакцій, перемикання в неї або з неї вимагає особливого підходу

■ Якщо ви перемикаєтеся в просту модель відновлення, перед цим не забудьте створити резервну копію журналу транзакцій

■ Якщо ви перемикаєтеся з простої моделі відновлення, безпосередньо після перемикання слід виконати повне резервування бази даних

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*