Дифференцированное резервное копирование предназначено для записи всех изменений, произошедших в базе данных после выполнения последнего полного резервного копирования. Таким образом, если в понедельник вы выполняете полное резервное копирование, а во вторник выполняете дифференцированное копирование, то во вторник будут записаны все изменения базы данных, сделанные начиная с понедельника. При дифференцированном резервном копировании в среду опять будут записаны все изменения, сделанные после полного резервирования в понедельник. Каждое следующее дифференцированное резервное копирование занимает чуть больше времени, чем предыдущее, но это ничто по сравнению со временем выполнения полного резервного копирования.
SQL Server определяет, какие страницы резервной копии были изменены, путем считывания последних записей журнала транзакций из последней полной резервной копии и сравнения их со страницами данных в базе. Если SQL Server находит какие-либо обновленные страницы данных, то программа резервирует все расширение (восемь последовательных страниц), а не только измененную страницу.
Выполнение дифференцированного резервного копирования практически не отличается от полного. Мы выполним дифференцированное резервное копирование базы данных AdventureWorks на постоянном устройстве резервного копирования, созданном нами ранее.
1. Откройте SQL Server Management Studio и разверните элемент Databases своего сервера баз данных.
2. Щелкните правой кнопкой мыши на базе данных Sales и выберите в контекстном меню пункт Tasks=> Back Up.
3. В диалоговом окне Back Up убедитесь, что для создания резервной копии выбрана база данных Sales, после чего в списке Backup Type выберите значение Differential.
4. В поле Name оставьте имя по умолчанию, а в поле Description введите описание Differential Backup of Sales.
5. В разделе Destination убедитесь, что выбрано устройство SalesFull (рис. 7).
6. На странице Options установите переключатель в положение Append To Тhe Existing Backup Set, чтобы случайно не записать новую информацию по верх уже существующей полной резервной копии (рис. 8).
Рис.7. Установка дифференцированного резервного копирования
8. Чтобы приступить к резервному копированию, щелкните на кнопке ОК.
Теперь удостоверимся в том, что и дифференцированная, и полная резервные копии находятся на устройстве SalesFull.
1. Откройте SQL Server Management Studio и на панели Object Browser в группе Server Objects разверните элемент Backup Devices.
2. Щелкните правой кнопкой мыши на устройстве SalesFull и в контекстном меню выберите пункт Properties.
3. На странице Media Contents вы должны увидеть полную и дифференцированную резервные копии базы данных Sales.
4. Чтобы вернуться в SQL Server Management Studio, щелкните на кнопке ОК.
Выполнения лишь полного и дифференцированного резервного копирования недостаточно. Если вы не будете создавать резервные копии журналов транзакций, то ваша база данных может перестать функционировать.
Резервное копирование журнала транзакций
Несмотря на то что резервное копирование журнала транзакций основывается на полной резервной копии, оно не архивирует базу данных как таковую. Этот тип резервного копирования архивирует только фрагменты журнала транзакций, содержащие записи, созданные после последнего резервирования журнала транзакций.
Если база данных сконфигурирована для использования полной, а не простой модели восстановления, то лишь с помощью резервного копирования журнала транзакций вы сможете очистить журнал от старых транзакций.
Когда журнал транзакций заполняется на 100%, пользователи не могут получать доступ к базе данных до тех пор, пока администратор не очистит этот журнал.
В этой работе мы выполним резервное копирование журнала транзакций базы данных Sales, используя созданное ранее устройство резервного копирования.
1.Откройте SQL Server Management Studioи разверните элемент Databasesсвоего сервера баз данных.
2. Щелкните правой кнопкой мыши на базе данных Sales и выберите в контекстном меню пункт Tasks=> Back Up.
3.Вдиалоговом окне Back Up убедитесь, что для создания резервной копии выбрана база данных Sales, после чего в списке Backup Typeвыберите значение Transaction Log.
4. В поле Nameоставьте имя по умолчанию, а вполе Descriptionвведите описание Transaction Log Backup of Sales.
5. Убедитесь, что в качестве устройства резервного копирования выбрано SalesFull.
6. На странице Optionsустановите переключатель в положение Append To The Existing Backup Set,чтобы случайно не стереть ранее созданные на нем резервные копии (рис.11).
7. Установите флажок Verify Backup When Finished.
8. Щелкните на кнопке OK, чтобы начать резервное копирование.
Убедитесь в том, что вы случайно не переписали полную и дифференцированную резервные копии, хранящиеся на устройстве резервного копирования.
1. Откройте SQL Server Management Studioи на панели Object Browserв группе Server Objectsразверните элемент Backup Devices.
2. Щелкните правой кнопкой мыши на устройстве SalesFull и в контекстном меню выберите пункт Properties.
3. На странице Media Contents вы должны увидеть резервную копию журнала транзакций базы данных Sales (рис. 12).
4. Чтобы вернуться в окно SQL Server Management Studio, щелкните на кнопке ОК.
Рис.11. Параметры резервного копирования журнала транзакций
Рис. 12. Теперь в списке резервных копий присутствует и копия журнала транзакций
Восстановление баз данных
Самая ужасная вещь для администратора — это нефункционирующая база данных. Такую базу данных легко заметить в SQL Server Management Studio, поскольку рядом с ееименем отображается в круглых скобках слово Shutdown. Это означает, что с этой базой данных что-то не так; возможно, причина в поврежденном диске.
Повреждения баз данных являются не единственной причиной восстановления. Например, вам может потребоваться отправить копию одной из баз данных в домашний или дочерний офис, чтобы обеспечить синхронизацию. Вам также может потребоваться восстановить данные после ошибочных обновлений или выполненных злоумышленником в корыстных целях.
Стандартное восстановление
Восстановление баз данных не требует особых усилий, но является одной из самых важных концепций, которую вам следует понимать для выполнения задач администрирования. Опция RECOVERY, заданная некорректно, может свести на нет все попытки восстановления базы данных. Эта опция указывает SQL Server, что вы закончили восстановление базы данных, и пользователям нужно вновь предоставить к ней доступ. Данную опцию следует использовать только для последнего файла, участвующего в процессе восстановления.
К примеру, если вы выполняете полное резервное копирование, затем дифференцированное копирование, а затем создаете резервную копию журнала транзакций, то дляприведения базы данных в устойчивое состояние вам понадобится восстановить всетри копии. Если вы задаете опцию RECOVERY при восстановлении дифференцированной резервной копии, то SQL Server не позволит вам выполнять другие типы восстановления. Этот параметр сообщает серверу, что вы закончили восстановление, и базой данных можно пользоваться вновь. Если вам нужно восстановить несколько файлов, то лучше задавать явно параметр NORECOVERY для всех восстановлений, за исключением последнего.
При восстановлении SQL Server также "помнит" местонахождение исходных файлов. Таким образом, если вы резервировали данные с диска D, то SQL Server и восстановит их на диске D. Однако что делать, если диск D поврежден, и нужно переместить базу данных на диск Е? С такой же проблемой вы столкнетесь, когда будете резервировать базы данных на сервере в главном офисе, а восстанавливать их придется на сервере в дочернем офисе. В данном случае вам потребуется использовать мастер копирования баз данных - Copy Database Wizard.
Перед тем как SQL Server позволит вам восстановить базу данных, он выполнит проверку совместимости, чтобы вы случайно не восстановили неисправную базу данных. Вначале SQL Server сверяет имя восстанавливаемой базы данных с именем базы данных, записанным в устройстве резервного копирования. Если они различны, то SQL Server не будет выполнять восстановление. Таким образом, при попытке восстановления базы данных Accounting из устройства, в котором содержится резервная копия базы данных Acctg, SQL Server не выполнит восстановление. Это ваша страховка, если, конечно, вы не пытаетесь записать базу данных из резервной копии поверх существующей базы данных. В этом случае вам следует задать параметр REPLACE, который предназначен для отмены проверки совместимости.
Итак, мы уже подготовились к восстановлению базы данных. Для начала сотворим с базой данных какую-нибудь пакость, чтобы вы видели, как SQL Server будет ее восстанавливать. Для примера мы удалим базу данных Sales.
Перед удалением все службы SQL Server нужно отключить по причине того, что во время их работы файлы всех баз данных рассматриваются как открытые, и вы не сможете работать с ними вне SQL Server.
1. Запустите утилиту SQL Server Management Studio.
2. Щелкните правой кнопкой мыши на элементе SQL Server и выберите в контекстном меню пункт Stop. Вы получите запрос на подтверждение остановки службы SQL Server. Щелкните на кнопке Yes.
3. Щелкните правой кнопкой мыши на элементе SQL ServerAgen правой панели и выберите в контекстном меню пункт Stop. Вы получите запрос на подтверждение остановки службы SQL ServerAgent. Щелкните на кнопке Yes.
4. Найдите файл Sales_Data.mdf (обычно он находится в папке С :\
Program Files\Microsoft SQL Server\MSSQL.1\ MSSQL\Data\).
5. Измените его имя на Sales_Data.old.
6. Найдите файл Sales_Log.ldf и переименуйте его в Sales_Log.old.
7. Перезапустите службы SQL Agentи SQL Server.
8. Посмотрите базы данных. Папка БД Sales будет пустой (БД не подключена).
Теперь мы располагаем неисправной базой данных и можем ее восстановить.
1. Щелкните правой кнопкой на элементе Databases и выберите в контекстном меню пункт Restore Database.
2. В открывшемся диалоговом окне из раскрывающегося списка То Database выберите базу данных Sales.
3. Установите переключатель Source For Restore в положение From Device. Чтобы выбрать устройство, щелкните на кнопке с троеточием возле текстового блока.
4. В диалоговом окне Specify Backup из раскрывающегося списка Backup Media выберите элемент Backup Device и щелкните на кнопке Add.
5. В диалоговом окне Select Backup Device выберите устройство SalesFull и щелкните на кнопке ОК (рис. 14).
Рис. 14. Выбор устройства резервирования для восстановления базы данных
6. Чтобы закрыть диалоговое окно Specify Backup, щелкните на кнопке ОК.
7. В блоке Select The Backup Sets To Restore установите флажки во всех трех типах восстановления (полное, дифференцированное и восстановление журнала транзакций) — это поможет вернуть базу данных в самое последнее состояние (рис. 15).
8. На странице Options убедитесь, что переключатель установлен в положение RESTORE WITH RECOVERY, поскольку у вас нет больше резервных копий восстановления (рис. 16).
Рис. 15. Выбор восстанавливаемых резервных копий
Рис. 16. Установка параметров восстановления
9. Чтобы начать процесс восстановления, щелкните на кнопке ОК.
10. В окне SQL Server Management Studio щелкните правой кнопкой на элемента Database и выберите в контекстном меню пункт Refresh.
11. Разверните группу Databases. Вы должны увидеть базу данных Sales в нормальном состоянии.
Этот тип восстановления удобно применять в тех случаях, когда повреждена вся база данных, и вам нужно восстановить ее как единое целое. А что делать, если повреждены только несколько записей, и нужно вернуть базу данных в состояние, существовавшее несколько часов назад?
Восстановление базы данных в состояние определенного момента времени
Когда закрываются месячные отчеты, обычно администратор базы данных получает задание вернуть ее в состояние, существовавшее в определенный момент прошлого. Чаще всего такая задача формулируется следующим образом: "У нас тут что-то не сходится. Можете вернуть данные в состояние на 2:00 вторника?". Вы вспоминаете, что от бухгалтерии зависит ваша будущая премия, и решаете любыми способами решить проблему. Если вы создавали резервные копии журнала транзакций, то можете восстановить базу данных к состоянию на определенные дату и время.
Помимо маркировки каждой транзакции в журнале номером LSN, SQL Server отмечает и время их выполнения. Это время, комбинированное с предложением STOPAT инструкции RESTORE, позволяет возвращать данные в предыдущее состояние. При использовании этого процесса вам следует помнить о двух вещах. Первое: этот процесс не работает с полной или дифференцированной резервной копией, а только с журналом транзакций. Второе: вы потеряете все изменения, которые были сделаны во всей базе данных после точки STOPAT. Например, если вы восстанавливаете базу данных в состояние на 14:00 вчерашнего дня, то все изменения, сделанные с этого момента, будут утеряны. В остальном восстановление до определенного момента времени представляет собой мощное и удобное средство. Сейчас мы используем его для восстановления базы данных Sales.
1. Для начала добавим запись, которая по нашему сценарию должна находиться после точки восстановления. В окне SQL Server Management Studio создайте новый запрос, щелкнув на кнопке New Query панели инструментов.
2. Для создания новой записи введите и выполните следующий код:
Теперь мы располагаем неисправной базой данных и можем ее восстановить.
