Відновлення файлів і резервне копіювання filegroup, Різне, Бази даних, статті

sql.ru

За матеріалами статті Microsoft Knowledge Base «INF Restore File and Filegroup Backups in SQL Server»
Інформація в цій статті ставиться до версій Microsoft SQL Server 7.0 і 2000

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

Перш за все, необхідно резервувати Transaction Log!
Ви повинні використовувати резервну копію файлу і файлгруппи, а також відновлювати їх спільно з резервними копіями transaction log. Після відновлення файлів, Ви повинні відновити резервні копії transaction log, які були створені так само, як резервні копії файлів, щоб забезпечити несуперечливе стан бази даних. Немає необхідності виконувати резервне копіювання transaction log, якщо файли або файлгруппи не були змінені після того, як була створена резервна копія файлу або файлгруппи.

– SQL SERVER 7.0 вимагає, щоб опція TruncateLogOnCheckpoint не була встановлена, і щоб резервні копії transaction log створювалися на додаток до резервної копії файлгруппи або файлу бази даних.
– SQL SERVER 2000 – для створення резервної копії transaction log, Ви повинні використовувати Full Recovery або Bulk-Logged Recovery модель відновлення. Для отримання більшої інформації про моделі відновлення, див. «SQL Server 2000 Books Online
"Selecting a Recovery Model».

ЗВЕРНІТЬ УВАГА: Ви повинні створювати повний набір резервних копій файлу, включаючи резервні копії журналу транзакцій. Відсутність коштів резервування може стати причиною втрати всієї бази даних, якщо немає актуальною резервної копії пошкодженого файлу.

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

Якщо повна копія бази даних втрачена:

– Ви повинні мати резервну копію кожного файлу або filegroup бази даних.
– Ви повинні мати не пошкоджену резервну копію transaction log, журналірующую весь ланцюжок операцій, починаючи з самого ранньої резервної копії файлу або filegroup, до кінця резервування самого останнього файлу або filegroup. Початок резервованій transaction log ланцюжка операцій повинно містити записи журналу для самої старої транзакції, не завершеною до того моменту, коли була створена найраніша резервна копія файла.

ЗВЕРНІТЬ УВАГА: Якщо будь-яка з перерахованих вище умов не буде виконана, базу даних відновити буде не можливо.

Резервні копії файлу і Filegroup повинні бути відновлені до відповідної базу даних:

Резервні копії файлу і Filegroup можуть бути відновлені тільки в базу даних, якої вони належать. Ви не можете створювати нову, порожню базу даних з тією ж самою структурою та іменами файлів і потім намагатися відновлювати окрему резервну копію файлу або filegroup; Ви повинні відновити їх в існуючу базу даних або виконати відновлення повної копії бази даних в іншому місці. (В SQL Server 2000 є нова можливість, дозволяє здійснювати операції відновлення бази даних RESTORE DATABASE по частинах).

ЗВЕРНІТЬ УВАГА: Не намагайтеся від’єднувати (detach) базу даних і потім знову прикріпити (attach) її, якщо файл бази даних, що складається з декількох файлів або filegroup, втрачений. Замість цього, відновіть необхідний файл або filegroup з резервної копії. Якщо база даних від’єднана, її перепрікрепленіе закінчиться збоєм, і Ви будете змушені відновити повну резервну копію бази даних. Це відбудеться тому, що файли бази даних узгоджені в базі даних, і цей механізм заснований на глобальному ідентифікаторі (GUID). Цей механізм повинен захистити цілісність бази даних так, щоб файли, які не належать базі даних, не були б змішані з файлами бази, що може стати причиною серйозних проблем з цілісністю даних. Навіть при тому, що Ви можете створити нову базу даних з тими ж самими іменами файлів, GUID не відповідатиме колишніх значень.

SQL Server не дозволяє Вам прикріплювати окремий файл бази даних, яка містить кілька таких файлів. При прикріпленні шукаються всі файли, які належать базі до якої файл прикріплюється і, якщо не вдається знайти файли з відповідними GUID, процедура прикріплення потерпить невдачу. Аналогічно, якщо Ви створюєте нову базу даних з тими ж самими іменами файлів і filegroups, як в джерельній базі даних, спробуйте замінити деякі з файлів, і потім намагайтеся ініціювати регенерацію бази даних, що виконує після запуску SQL сервера. Регенерація закінчиться збоєм, про що буде повідомлено в errorlog. Наприклад, так:

2000-11-28 13:14:52.88 spid9 Opening file C:\MSSQL7\data\f2_Data.NDF.
2000-11-28 13:14:53.01 spid9 Cannot associate files with different databases.
2000-11-28 13:14:53.14 spid9 Device activation error. The physical file name ‘C:\MSSQL7\data\f2_Data.NDF’ may be incorrect.

Операції часткового відновлення бази даних (Тільки для SQL Server 2000):

У SQL Server 2000 з’явилася нова опція PARTIAL інструкції T-SQL: RESTORE, яка забезпечує механізм відновлення частин бази даних в інше місце розташування, причому так, щоб пошкоджені або відсутні дані могли бути скопійовані назад, до первісної базу даних. Операції часткового відновлення працюють з базою даних має filegroups. Наприклад, Ви маєте базу даних, яка складається з первинної filegroup, filegroup-А і filegroup-B. Припустимо, що таблиця, яка постійно знаходиться в filegroup-B, була випадково видалена. Якщо Ви маєте filegroup і резервні копії transaction log доступні, щоб відновити віддалену таблицю, Ви можете відновити тільки filegroup-B спільно з первинної filegroup. Інструкція RESTORE з пропозицією PARTIAL дозволяє здійснювати відновлення в нову базу даних або навіть на інший сервер. Ви зможете витягти і перезавантажити вміст таблиці до первісної базу даних.
Первинна filegroup завжди відновлюється разом з іншими filegroup, які потрібно відновити. Filegroups, які не відновлені, відзначаються, як офлайнові і стають недоступними. Часткове відновлення резервної копій файлу бази даних не підтримується.
Для отримання більшої інформації про те, як правильно виконувати часткове відновлення бази даних, див SQL Server 2000 Books Online «Partial Restore Operations» і «RESTORE DATABASE».

Будь ласка, вивчіть наступні теми, пов’язані з файлів і filegroups:

SQL Server 7.0 Books Online topics:
«Physical Database Files and Filegroups»
«Using Files and Filegroups»
«Creating Filegroups»
«Creating File or Filegroup Backups»
«Using File or Filegroup Backups»
«Restoring File or Filegroup Backups»
«File and Filegroup Backup and Restore»

SQL Server 2000 Books Online topics:
«Physical Database Files and Filegroups»
«Using Files and Filegroups»
«Creating Filegroups»
«Using File Backups»
«Files and Filegroups»
«Backing up and Restoring Databases»
«Partial Database Restore Operations»
«Backing up Selected Portions of a Database»

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


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

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

Ваш отзыв

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

*

*