Lab6_SQL (Лабораторная №6), страница 2

Если база данных сконфигурирована для использования полной, а не простой модели восстановления, то лишь с помощью резервного копирования журнала транзак­ций вы сможете очистить журнал от старых транзакций.

Когда журнал транзакций заполняется на 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.

1. Убедитесь, что в качестве устройства резервного копирования выбрано SalesFull.

1. На странице Options установите переключатель в положение Append To The Existing Backup Set, чтобы случайно не стереть ранее созданные на нем резервные копии (рис.11).

1. Установите флажок Verify Backup When Finished.

2. Щелкните на кнопке OK, чтобы начать резервное копирование.

Убедитесь в том, что вы случайно не переписали полную и дифференцированную резервные копии, хранящиеся на устройстве резервного копирования.

1. Откройте SQL Server Management Studio и на панели Object Browser в группе Server Objects разверните элемент Backup Devices.

2. Щелкните правой кнопкой мыши на устройстве SalesFull и в контекст­ном меню выберите пункт Properties.

1. На странице Media Contents вы должны увидеть резервную копию журнала транзакций базы данных Sales (рис. 12).

2. Чтобы вернуться в окно 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\).

1. Измените его имя на Sales_Data.old.

2. Найдите файл Sales_Log.ldf и переименуйте его в Sales_Log.old.

3. Перезапустите службы SQL Agent и SQL Server.

4. Посмотрите базы данных. Папка БД 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. Выбор устройства резервирования для восстановления базы данных

1. Чтобы закрыть диалоговое окно 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. Для создания новой записи введите и выполните следующий код:

USE Sales

INSERT Products(Description,InStock)