· создатели SQL Server 2005 активно рекламируют новую возможность — восстановление на открытой базе данных. На самом деле такое восстановление можно производить только тогда, когда в базе данных несколько файловых групп, и восстанавливаемая файловая группа находится в автономном режиме (offline). Поэтому на самом деле пользователи работать с восстанавливаемыми данными, конечно, не смогут;
· в SQL Server 2005 восстановление полнотекстовых индексов производится вместе с базами данных;
· информация о восстановлении, как и информация о резервном копировании, записывается в служебные таблицы базы данных msdb. Используются таблицы restorehistory, restorefile и restorefilegroup.
Перед восстановлением потребуется произвести некоторые подготовительные действия.
Первое, что нужно сделать, — это запретить пользователям доступ к базе данных, подлежащей восстановлению. Это можно сделать разными способами:
· для большинства баз данных достаточно установить для параметра RestrictAccess (Ограничить доступ) свойств базы данных значение Restricted. Если же пользователи вашей базы данных могут подключаться с правами dbo, то для этого параметра можно установить значение Single;
· если на сервере имеется только одна рабочая база данных, то лучше просто на время восстановления отключить сетевой доступ к SQLServer. Для этого можно, например, на время восстановления отключить протокол TCP/IP в контейнере SQLServer 2005 NetworkConfiguration в SQLServerConfigurationManager.
Если к базе данных в настоящий момент подключены пользователи, то их соединения придется закрыть.
Может случиться так, что база данных повреждена настолько сильно, что изменить ее свойства не удается. Она при этом может находиться в состоянии suspect (подозрительное) или в автономном режиме offline (информацию о состоянии можно просмотреть, например, из контейнера Datаbases в ManagementStudio). Если база данных находится в автономном режиме, то запустить ее восстановление вам не удастся. В этой ситуации самый простой выход — отсоединить (detach) поврежденную базу данных и произвести восстановление с резервной копии так, как будто эта база данных отсутствует на сервере вообще. Отметим, что для того, чтобы отсоединить базу данных, помеченную как подозрительная (suspect), ее необходимо вначале перевести в состояние "экстренной необходимости" (emergency) - ALTERDATABASEdb1 SETemergency.
Если база данных находится в рабочем режиме, а время у вас есть, то лучше, конечно, подстраховаться, создав еще одну, самую свежую резервную копию этой базы данных и журнала транзакций (или только журнала транзакций в зависимости от ситуации).
После того, как доступ пользователей к базе данных закрыт, рекомендуется проверить заголовки ваших резервных копий. Для этого можно использовать следующие команды:
· RESTOREFILELISTONLY — возвращает информацию о списке файлов и журналов транзакций, которые помещены в данную резервную копию. Эта информация берется из таблицы backupfile базы данных msdb;
· RESTOREHEADERONLY — возвращает информацию об имени резервной копии, ее типе, описании, времени создания и времени устаревания и т. п.. Эта информация берется из таблицы backupset базы данных msdb;
· RESTORELABELONLY — выводит служебную информацию о метке носителя. В основном метка нужна для картриджей стриммеров, но может применяться и для файлов. Информация берется, в том числе, и из таблицы backupmediaset базы данных msdb.
Пример выполнения команды на просмотр информации о резервной копии может выглядеть так:
· RESTOREFILELISTONLYFROMbackupdevice1;
· Конечно, вы можете обратиться к таблицам с историей резервного копирования в базе данных msdb и напрямую.
После того, как подготовка завершена, можно приступать к самому восстановлению. Запустить восстановление можно при помощи графического интерфейса ManagementStudio (контекстное меню RestoreDatabase для контейнера Databases или контекстное меню Tasks | Restore для контейнера базы данных) или при помощи команды RESTORE. Как обычно, опишем возможности, которые представляет графический интерфейс, и приведем информацию о тех параметрах команды RESTORE, которым они соответствуют.
Destinationtorestore ... Todatabase (Назначение восстановления ... в базу данных) — это, конечно, имя восстанавливаемой базы данных. Обратите внимание, что вместо выбора базы данных из списка вы можете ввести свое имя. В этом случае из резервной копии на сервере будет создана новая база данных. В некоторых случаях может быть удобно восстановить копию существующей базы данных под другим именем, а затем при необходимости старую базу данных удалить, а восстановленную переименовать, присвоив ей старое название.
Команда на восстановление базы данных в самом простом варианте может выглядеть так:
RESTORE DATABASE db2 FROM DISK = 'D:\SQLBackups\BackupFile1.bak'
При этом резервная копия вполне могла быть создана для базы данных db1, а не db2;
Toapointoftime (На момент времени) — позволяет задать восстановление на определенный момент времени. Обычно используется только в ситуации, когда пользователь совершил ошибку (например, удалил важные данные) и вы знаете примерно, когда это произошло. Используется только при восстановлении журналов транзакций. Этот переключатель соответствует параметру STOPAT команды RESTORE, например, WITHSTOPAT = '01/06/2006 12:14:24'. Для команды RESTORE можно указать еще два параметра:
1. восстановление на метку транзакции. Обычно метка транзакции применяется перед выполнением рискованных операций (применение исправлений от разработчиков, очистка или массовая загрузка данных и т. п.). Создать метку транзакции можно очень просто:
BEGINTRANmark1 WITHMARK;
COMMITTRAN;
Для восстановления потребуется использовать параметр WITHSTOPATMARK = 'mark1', чтобы остановиться точно на этой метке или WITHSTOPBEFOREMARK = 'mark1' для остановки точно перед этой меткой;
2. восстановление на номер последовательности в журнале транзакций (logsequencenumber, LSN). Номер LSN есть у каждой операции, которая зафиксирована в журнале транзакций. К сожалению, стандартными средствами просмотреть журнал транзакций и найти LSN для транзакции, с которой начались проблемы, невозможно. Для этой цели придется использовать утилиты третьих фирм, например, LumigentLogExplorer. После того, как номер LSN найден, можно использовать те же параметры STOPATMARK и STOPBEFOREMARK, но синтаксис будет немного другим, например:
RESTORE LOG db1 FROM DISK = 'D:\SQLBackups\BackupFile1.bak' WITH STOPATMARK = 'lsn:120';
Fromdatabase(Из базы данных) — для обнаружения резервных копий будет использоваться история резервного копирования из таблиц базы данных msdb. В списке можно выбрать не только текущую базу данных, но и другие базы данных, которые есть на этом сервере;
Fromdevice(Из устройства) — вам потребуется указать местонахождение резервной копии явно. Эта возможность используется в тех ситуациях, когда вам нужно восстановить базу данных на другой сервер или местонахождение резервной копии изменилось. В любом случае вам потребуется выбрать логическое устройство резервного копирования, картридж стриммера или файл на диске. Еще одна возможность (доступная только в EnterpriseEdition и только при полном восстановлении базы данных) — использовать в качестве источника снимок базы данных (databasesnapshot);
Selectthebackupsetstorestore (Выбрать резервную копию для восстановления) — в этом списке вам потребуется установить флажки напротив тех резервных копий, которые вы планируете восстановить. Обратите внимание, что флажки можно поставить напротив нескольких резервных копий. В этом случае для каждой выбранной резервной копии будет выполнена отдельная команда RESTORE.
При помощи этого же списка можно получить множество дополнительной информации о восстанавливаемых резервных копиях (если прокрутить список вправо): о времени резервного копирования, о размере резервной копии, о пользователе, которые производил это копирование, и т.п.
Дополнительные и очень важные параметры восстановления представлены на вкладке Options окна восстановления базы данных ManagementStudio:
Overwritetheexistingdatabase (Перезаписывать существующую базу данных) — установленный флажок позволяет перезаписать существующую базу данных. Фактически он отменяет проверки, которые призваны не допустить потери данных в случае ошибочного восстановления. Таких проверок предусмотрено три:
· запрещено восстанавливать резервную копию чужой базы данных на сервер, если под этим именем на сервере есть своя база данных;
· запрещено перезаписывать файлы, которые относятся к базам данных, находящимся в автономном режиме (offline), и, кроме этого, вообще любые файлы, которые не относятся к SQLServer;
· запрещено производить восстановление базы данных, если на ней осталась часть журнала транзакций, резервное копирование которой еще не производилось (tail-log). Это новая проверка, которая появилась только в SQLServer 2005.
Чтобы эти проверки отменить, нужно установить указанный флажок или использовать параметр WITHREPLACE в команде RESTORE;
Preservethereplicationsettings (Сохранить настройки репликации) — сохранить настройки репликации при восстановлении. Соответствует параметру KEEP_REPLICATION команды RESTORE. Обычно используется только тогда, когда база данных одновременно участвует и в репликации, и в автоматической доставке журналов (logshipping).
Promptbeforerestoringeachbackup (Выводить приглашение перед каждым восстановлением) — выводить приглашение перед восстановлением каждой следующей резервной копии из выбранного вами списка. Обычно этот параметр используется только тогда, когда каждая копия лежит на своем картридже стриммера, и вам нужно их менять. Этот параметр можно настроить только на графическом экране ManagementStudio, поскольку в коде Transact-SQL для восстановления каждой резервной копии вам придется использовать свою собственную команду RESTORE;
Restrictaccesstotherestoreddatabase (Ограничить доступ к восстанавливаемой базе данных) — после восстановления доступ будет открыт только членам роли базы данных db_owner и членам серверных ролей dbcreator и sysadmin. Этот параметр обычно применяется в тех случаях, когда после восстановления базы данных вам необходимо произвести дополнительные проверки или внести исправления. Ему соответствует параметр команды RESTOREWITHRESTRICTED_USER;