Операції відновлення

Існує безліч причин відновлення бази даних, серед яких наступні

■ Сталося пошкодження дискової підсистеми

■ Неуважний програміст забув вставити пропозицію WHERE в інструкцію UPDATE і замінив зарплату всіх співробітників мінімальною

■ Сервер впав у резервуар з силіконом, і вінчестер перетворився на кругляк

■ Була проведена велика робота по імпорту даних, але не тим числом

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

Ідентифікація проблеми

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

Рис 365 База даних AdventureWorks пошкоджена (для цього я зупинив SQL Server і підправив вручну в шістнадцятковому редакторі заголовок файлу) Management Studio відображає базу без дерева обєктів Нижче в дереві консолі знаходяться вузли журналів SQL Server

Щоб продовжити дослідження проблеми, перегляньте журнал SQL Server Для цього в Management Studio виберіть пункт меню Managements SQL Server Logs SQL Server записує помилки і події в спеціальний файл журналу, який знаходиться в підкаталозі / error папки установки сервера Цей файл створюється заново при кожному запуску SQL Server, при цьому шість попередніх версій цього файлу зберігаються там же Деякі помилки паралельно можуть бути записані в журнал подій додатків операційної системи Windows

Послідовності відновлення

З відновленням даних повязані дві дуже важливі концепції

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

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

Тільки члени фіксованою серверної ролі SysAdmins можуть відтворювати базу даних, яка ще не існує Ті ж бази даних, які вже існують, можуть відтворювати члени вже двох ролей: SysAdnins і db_owners

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

Таблиця 362 Послідовності відновлення

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

Пошкоджений файл даних

Пошкоджений журнал транзакцій

Проста

1 Перезапуск сервера

Перезапуск сервера При цьому автомати

2 Відтворення повної резервної копії

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

тично створюється новий журнал транзакцій розміром в 1 Мбайт

Повна або з

1 Резервування поточного стану

1 Відтворення повної резервної ко

неповним про

журналу транзакцій з параметром

пии

токолірованіем

no_truncate

2 Відтворення з останньої дифферен

2 Відтворення повної резервної копії

ціальної резервної копії (якщо потрібно)

3 Відтворення з останньої дифференци

3 Відновлення з усіх резервних ко

рованной копії

пий журналу транзакцій, створених після

4 Відновлення з усіх резервних копій

останнього диференційованого резервування

журналу транзакцій, створених після по

следнего диференційованого резерви

Усі транзакції, виконані після по

вання Всі підтверджені транзакції будуть відновлені

следнего резервування, будуть втрачені

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

Відтворення бази даних в Management Studio

Як і у випадку резервування, існує кілька способів запуску відновлення в утиліті Management Studio

■ Виділіть базу даних, яку будете відтворювати У контекстному або головному меню Action виберіть пункт All Tasks ^ Backup Restore

■ Виберіть у меню пункт Tasks ^ Restore ^ Database

■ Клацніть правою кнопкою миші на вузлі Databases дерева консолі і виберіть у контекстному меню пункт Restore Database

У будь-якому випадку відкриється форма Restore Database (рис 366), яка проведе вас крізь потенційний хаос послідовностей відновлення вона завжди пропонує тільки допустимі варіанти відтворення

Рис 366 У формі Restore Database утиліти SQL Sender Management Studio доступні тільки коректні послідовності відтворення бази даних

У верхній частині вікна виберіть імя бази даних після її відтворення

Діалогове вікно Restore Database дозволяє відтворити базу або файли з резервних копій, що знаходяться у файлах на диску або на інших пристроях (наприклад, на стрічкових) Майстер Restore Wizard для баз даних представить вам ієрархічне дерево резервних копій, тоді як для файлів і файлових груп будуть перераховані файли, які повинні бути відновлені вручну в коректному порядку

Параметр Show backups of database використовується для вибору першої резервної копії з послідовності, яка підлягає відтворенню Грунтуючись на обраної

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

■ Повні резервні копії бази даних відображаються з золотим значком жорсткого диска на верхньому рівні дерева

■ Диференційовані резервні копії відображаються з синім значком жорсткого диска на другому рівні дерева

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

Залежно від обраних повних і диференційованих резервних копій далі можуть бути обрані тільки певні диференційовані і транзакційні архіви

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

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

Вкладка Options діалогового вікна Restore Database дозволяє встановити ряд важливих параметрів

■ Параметр Overwrite the existing database відключає перевірку безпеки, що виключає можливість випадкового заміщення бази даних А резервною копією бази даних Б У більшості випадків цей параметр встановлювати не потрібно

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

■ Параметр Recovery State дозволяє доставити протокол на сервер, що знаходиться в режимі очікування У звичайних умовах цей параметр слід залишити робітникам

■ Якщо відтворювати слід тільки певні файли та файлові групи, то параметр Restore: Files or File Groups дозволить вибрати ці обєкти

■ Якщо журнал створення резервних копій, бережене в базі даних msdb, недоступний (з причини того, що сервер був переустановлений або база даних відновлюється на іншому сервері), то параметр Restore: From Device можна використовувати для ручного вибору конкретного файлу або пристрої з резервною копією, а також примірника резервної копії у файлі

SQL Server здатний частково відтворювати сторінки даних Ця можли-Новинка ність може виявитися особливо корисною, коли в базі даних обємом в НЕ-

2005 скільки терабайт пошкоджена всього одна сторінка даних Незважаючи на те що

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

Відтворення бази даних програмним шляхом

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

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

Інструкція RESTORE може виконувати відтворення бази з повної, диференційованої і транзакционной резервної копії Її загальний синтаксис наведено нижче

RESTORE DATABASE | LOG імя_бази_данних [файл \ файловая_группа PARTIAL]

FROM устройство_резервірованія WITH

FILE = номер_файла,

PASSWORD = пароль,

NORECOVERY | RECOVERY | STANDBY = імя_файла_отмени,

REPLACE,

STOPAT дата_і_время,

STOPATMARK = 1імя_меткі

STOРВЕFOREMARK = імя_меткі

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

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

1 Повна резервна копія

2 Диференційована резервна копія

3-6 Резервні копії журналу транзакцій

7 Диференційована резервна копія

8, 9 Резервні копії журналу транзакцій

Параметр WITH FILE дозволяє задати номер відновлюваної резервної копії у файлі або на пристрої резервування

Параметри RECOVERY / NORECOVERY є життєво важливими в інструкції відтворення При кожному запуску SQL Server автоматично перевіряється журнал транзакцій При цьому відкочуються усі непідтверджені транзакції і доводяться до кінця всі підтверджені Цей процес одержав назву відтворення (recovery) він є складовою частиною властивостей Асю бази даних

Таким чином, якщо в інструкції відтворення вказаний параметр NORECOVERY, SQL Server відтворить журнал, що не обробивши при цьому ні однієї транзакції якщо ж в інструкції буде вказаний параметр RECOVERY, транзакції будуть оброблені У послідовності операцій відновлення всі інструкції, крім останньої, повинні мати параметр NORECOVERY в останній інструкції повинен бути заданий параметр RECOVERY

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

Якщо в операції відтворення бази даних бере участь резервна копія журналу транзакцій, то процес може зупинитися, не досягнувши кінця цього журналу Параметри STOP АТ і STOPATMARK дозволяють не відтворювати транзакції, наступні за певним моментом часу або міткою При використанні параметра STOPBEFOREMARK відтворення транзакцій зупиняється перед початком транзакції, на якій встановлена ​​задана мітка

Додаткова Про особливості транзакцій в SQL Server і способах створення маркованих інформація транзакцій см в главі 23

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

– Приклад резервування і відновлення бази даних CREATE DATABASE Plan2Recover

Отримаємо наступний результат:

The CREATE DATABASE process

is allocating 063 MB on disk 1Plan2Recover1

The CREATE DATABASE process

is allocating 049 MB on disk 1Plan2Recover_log1

Продовжуємо операції:

USE Plan2Recover

CREATE TABLE T1 (

PK INT Identity PRIMARY KEY,

Name VARCHAR(15)

)

Go

INSERT T1 VALUES (Full) go

BACKUP DATABASE Plan2Recover TO DISK = e:\P2Rbak

WITH

NAME = 1P2R_Full1,

INIT

Отримуємо наступний результат:

Processed 80 pages for database 1Plan2Recover1, file 1Plan2Recover1 on file 1

Processed 1 pages for database 1Plan2Recover1, file 1Plan2Recover_log1 on file 1

BACKUP DATABASE successfully processed 81 pages in 0254 seconds (2590 MB/sec)

Продовжуємо операції:

INSERT T1 VALUES (Log 1) go

BACKUP Log Plan2Recover TO DISK = e:\P2Rbak

WITH

NAME = 1P2R_Log1

Отримуємо наступний результат:

Processed 1 pages for database Plan2Recover1, file 1Plan2Recover_log1 on file 2

BACKUP LOG successfully processed 1 pages in 0083 seconds (0055 MB/sec)

Продовжуємо операції:

INSERT T1 VALUES (Log 21) go

BACKUP Log Plan2Recover TO DISK = e:\P2Rbak

WITH

NAME = P2R_Log1

Отримуємо наступний результат:

Processed 1 pages for database 1Plan2Recover1, file 1Plan2Recover_log1 on file 3

BACKUP LOG successfully processed 1 pages in 0083 seconds (0065 MB/sec)

Продовжуємо операції:

SELECT * FROM T1

Поточний стан таблиці Tl:

PK Name

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Full

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Log 1

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Log 2

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

– Тепер виконуємо відтворення бази даних Use Master

RESTORE DATABASE Plan2Recover FROM DISK = e:\P2Rbak

WITH FILE = 1, NORECOVERY

Отримуємо наступний результат:

Processed 8 0 pages for database 1Plan2Recover1, file 1Plan2Recover1 on file 1

Processed 1 pages for database 1Plan2Recover, file 1Plan2Recover_log1 on file 1

RESTORE DATABASE successfully processed 81 pages in 0089 seconds (7392 MB/sec)

Продовжуємо відновлення:

RESTORE LOG Plan2Recover FROM DISK = e:\P2Rbak

WITH FILE = 2, NORECOVERY

Отримуємо наступний результат:

Processed 1 pages for database 1Plan2Recover1, file 1Plan2Recover_log on file 2

RESTORE LOG successfully processed 1 pages in 0009 seconds (0512 MB/sec)

Продовжуємо відновлення:

RESTORE LOG Plan2Recover FROM DISK = e:\P2Rbak

WITH FILE = 3, RECOVERY

Отримуємо наступний результат:

Processed 1 pages for database Plan2Recover, file 1Plan2Recover_log on file 3

RESTORE LOG successfully processed 1 pages in 0044 seconds (0011 MB/sec)

Тепер ми можемо перевірити результат операції відтворення бази даних:

USE Plan2Recover

SELECT * from Tl

PK Name

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Full

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Log 1

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Log 2

Як було показано в наведеному вище прикладі, бази даних можна відтворити і за допомогою програмного коду Т-SQL, однак в цьому випадку використання утиліти Management Studio забезпечить більш ефективну роботу

Джерело: Нільсен, Пол 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>

*

*