Методи планування операцій резервного копіювання та відновлення відомі багатьом, то ж стосується і застосування команд BACKUP і RESTORE. Більшості адміністраторів баз даних знайомі часто використовувані параметри команд, але лише мало хто знає про користь менш відомих параметрів. Про застосування таких параметрів і піде мова в даній статті
ІТ-інфраструктура для вашого підприємства
Методи планування операцій резервного копіювання та відновлення відомі багатьом, то ж стосується і застосування команд BACKUP і RESTORE. Більшості адміністраторів баз даних знайомі часто використовувані параметри команд, але лише мало хто знає про користь менш відомих параметрів. Про застосування таких параметрів і піде мова в даній статті.
Перевірка цілісності резервної копії
Я згоден з твердженням, що повна резервна копія немає до тих пір, поки з неї не відновили. На жаль, адміністратори баз даних часто забувають про необхідність перевіряти цілісність резервних копій. Допомагаючи відвідувачам різних форумів впоратися з втратою даних, я часто дізнаюся, що резервні копії також виявляються зіпсованими.
Перевірка контрольної суми сторінки виконується при кожному зчитуванні сторінки файлу даних в пам'ять для обробки. Однак це не гарантує виявлення всіх спотворень. Багато робітників програми не виконують регулярного зчитування всіх розміщених сторінок в базі даних, роблячи це тільки в процесі перевірки цілісності та повного резервного копіювання. При перевірці цілісності обчислюються контрольні суми сторінок. Але за замовчуванням при повному і диференціальному резервне копіювання перевірка контрольних сум не виконується.
Екран 1. Повідомлення про помилку резервної копії через псування сторінки
Деякі адміністратори баз даних перевіряють цілісність резервної копії іншим способом: за допомогою команди RESTORE з параметром VERIFYONLY. На жаль, при цьому перевіряється тільки заголовок, але не дані резервної копії. Необхідно використовувати команду RESTORE з двома параметрами: CHECKSUM і VERIFYONLY. Тільки в цьому випадку процес відновлення повторно перевіряє всіх відбитків сторінок і всієї резервної копії. Зверніть увагу, що не можна перевірити контрольні суми сторінок резервної копії, створених без параметра CHECKSUM.
Зниження втрат даних у разі аварії
Нерідко перша реакція адміністратора база даних в разі аварії - переключитися на резервну систему або запустити відновлення з резервної копії. Як тільки запущена операція відновлення, можливість зберегти саму останню порцію в журналі транзакцій безповоротно втрачається. Це резервна копія заключного фрагмента журналу: частина журналу, не записане в резервну копію, відома як заключний фрагмент журналу (log tail).
Екран 2. Повідомлення про помилку резервної копії через відсутніх або пошкоджених файлів даних
Підвищення швидкості резервного копіювання
Більшість адміністраторів баз даних не підозрюють, що можна істотно підвищити швидкість резервного копіювання. При цьому досягається ряд переваг, у тому числі:
* Скорочується час присутності в системі додаткової робочої навантаження на систему введення-виведення (і потенційно - навантаження на процесор, пов'язаної із стисненням резервних копій);
* Зменшується небезпека розростання файлу журналу транзакцій за рахунок журналу транзакцій, сформованого в ході резервного копіювання, особливо при тривалому повному резервному копіюванні бази даних.
Скорочення часу простою після аварії
Одна із звичайних цілей операції відновлення - відновити якомога менше даних, щоб скоротити час простою. З появою методу поетапного відновлення ця задача стала набагато простіше. Додаткова перевага приносить поетапне відновлення в оперативному режимі. В ході поетапної операції відновлюється тільки частина бази даних, наприклад одна сторінка (з використанням параметра PAGE) або один файл (з параметром FILE). Поетапне відновлення в оперативному режимі реанімує частина бази даних, а інша частина бази даних залишається доступною. Це можливо завдяки частковій доступності бази даних.
Відновлення однієї сторінки використовують лише деякі адміністратори. За однією можна відновлювати будь-які сторінки за умови, що існує спосіб привести відновлену сторінку до поточного часу, за винятком бітових карт виділення, що діють в масштабах всієї бази даних, і унікальних сторінок, таких як завантажувальні і заголовки файлів (ті ж обмеження діють для автоматичного виправлення сторінок з дзеркалюванням бази даних). Таким чином, необхідно мати резервні копії журналу транзакцій. Деякі сторінки (наприклад, що містять метадані таблиці) не підлягають відновленню в оперативному режимі, але успішно відновлюються автономно.
Іноді потрібно відновити цілком дуже велику базу даних (VLDB), але навіть в цьому випадку можна скоротити час, що витрачається на переклад бази даних в оперативний режим, забезпечивши часткову доступність баз даних і використовуючи поетапне відновлення в оперативному режимі. У цьому випадку відновлюється і перекладається в оперативний режим тільки фрагмент бази даних. В результаті користувачам не доводиться чекати відновлення всієї бази даних.
Відновлення для точки в часі
Іноді потрібно відновити базу даних для певного, що не найостаннішого, моменту часу. Приклад: якісь дані були видалені і необхідно відновити базу даних за допомогою резервної копії журналу, створеного безпосередньо перед видаленням даних. Якщо відомо час видалення, можна просто використовувати параметр STOPAT, щоб відновлення журналу не виходило за певні часові рамки.
Альтернативний підхід - використання помічених транзакцій. При цьому в журналі транзакцій створюються особливі мітки. приклад:
Згодом цю відому точку можна використовувати для відновлення бази даних. Відновити базу даних «до», включаючи позначену транзакцію, можна за допомогою параметра STOPATMARK. Якщо потрібно відновити базу даних «до», але виключаючи позначену транзакцію, використовуйте параметр STOPBEFOREMARK.
Для застосування будь-якого з цих параметрів необхідно знати ім'я мітки журналу. Якщо вони не були записані вручну, їх можна знайти в таблиці logmarkhistory в msdb (ще одна причина для резервного копіювання бази даних msdb). Якщо інформація в таблиці logmarkhistory загублена, знайти імена міток журналу важко. Для цього потрібно використовувати сторонній інструмент або команди undocumented log і log backup.
Якщо одне ім'я мітки журналу застосовується неодноразово, необхідно вказати час зупинки за допомогою параметра AFTER. В іншому випадку зупинка відбудеться у першій мітки, що збігається з ім'ям, зазначеним в інструкції RESTORE.
Перезапуск перерваної операції відновлення
WITH RESTART - один з маловідомих параметрів команди RESTORE. З його допомогою можна перезапустити перервану операцію відновлення. Операція відновлення періодично записує файл контрольних точок, в якому вказується, до якого місця пройшло відновлення. Файли контрольних точок (які не мають ніякого відношення до звичайних контрольних точках бази даних) зберігаються в папці \ InstanceName \ MSSQL \ Backup.
Файл контрольних точок оновлюється за таких умов:
* Завершено створення і заповнення нулями файлу бази даних;
* Оброблені всі резервні набори даних;
* Завершена стадія повтору при відновленні.
Якщо файл контрольних точок існує і параметр WITH RESTART використовується, все вже виконані кроки будуть пропущені. Якщо параметр WITH RESTART застосований, а файл контрольних точок відсутня, буде видано повідомлення, показане на екрані 3.
Екран 3. Повідомлення про помилку: не розпізнається контрольна точка
Найкорисніший параметр
Мене часто запитують, який з маловідомих параметрів резервного копіювання та відновлення найбільш корисний. Величезний виграш у швидкодії можна отримати, налаштовуючи буфери введення-виведення за допомогою параметрів BUFFERCOUNT і MAXTRANSFERSIZE. Завдяки лише однієї сторінки і поетапного відновлення з використанням параметрів PAGE і PARTIAL істотно скорочується час простою після аварії. Але якби мені довелося вказати єдиний параметр, я б вибрав NO_TRUNCATE для резервного копіювання заключного фрагмента журналу. Це єдиний спосіб виконати відновлення точно до моменту аварії, якщо файли даних недоступні.
Поділіться матеріалом з колегами і друзями