от Mike Aubert

Добро пожаловать в десятую статью моей серии «Изучи сервер Window SQL 2000 за 15 минут в неделю». На прошлой неделе мы закончили создание плана аварийного восстановления. На этой неделе мы рассмотрим, как восстанавливать базы данных для того, чтобы протестировать наш план. Кроме того, мы коснемся еще некоторых вопросов резервного копирования/восстановления баз данных, которые мы пропустили в предыдущих статьях. В данную статью включены следующие темы:

• Восстановление при помощи резервной копии;
• Другие настройки резервного копирования.

Восстановление при помощи резервной копии

Восстановление базы данных при помощи файла или магнитной ленты, содержащей резервную копию, выполняется достаточно просто, но вам стоит принять во внимание несколько вещей, когда вы будете использовать модель регистрации групповых операций (bulk_logged). Заметьте, что мы не будем рассматривать восстановление базы данных, которая использует модель простого восстановления. Первая вещь, которую стоит понять, это то, что восстановление (restoring) резервной копии и полное восстановление (recovering; слова «полное» нет в самой статье, но оно точнее передает смысл сказанного (прим. перев.)) базы данных являются совершенно разными операциями. Восстановление – это процесс простого копирования данных с резервной копии в базу данных. Полное восстановление, с другой стороны, является процессом, использующим журналы транзакций, для того, чтобы вернуть данные в базе в согласованное состояние. Чтобы не давать вам только поверхностное представление об этих процессах, давайте подробнее остановимся на том, что представляет собой процесс полного восстановления базы данных.

Если вы помните, в одной из предыдущих статей (Понимание журнала транзакций), я рассказывал, как происходит процесс восстановления внесенных изменений, если сервер SQL был некорректно отключен (этот процесс называется восстановлением при перезапуске (recovery restart)). Очень похожий процесс используется сервером SQL в случае, если вы восстанавливаете базу данных – он называется восстановление исходного состояния (restore recovery; перевод достаточно спорный, но другого варианта я не нашел (прим.перев.)). Если сервер SQL отключен некорректно, у нас образуется некоторый набор данных, которые находятся в несогласованном состоянии, так как мы не знаем, какие изменения все же были сохранены, а какие нет, до того, как произошло незапланированное отключение. Кроме набора данных в несогласованном состоянии, у нас также имеется файл журнала транзакций, который содержит список всех изменений, которые были проделаны с данными – с этого журнала нам и придется начинать процесс восстановления.

Для того чтобы привести данные в согласованное состояние, все транзакции в журнале, которые были завершены, применяют снова – этот процесс известен как прокрутка вперед (rolling forward), в тоже время все транзакции в журнале, которые не были завершены во время внезапного отключения, будут отменены – этот процесс называется откат (rolling back). При помощи прокрутки вперед завершенных транзакций и отката незавершенных транзакций, вы возвратите данные в согласованное состояние… означающее, что мы избавились от незавершенных транзакций, результатом которых могло быть такое состояние, например, при котором деньги были бы сняты со счета А, но не были зачислены на счет В.

Все это замечательно, но что общего есть между восстановлением после внезапного отключения и полным восстановлением базы данных при помощи резервных копий? Да все – фактически, это одинаковые процессы. Если вы вспомните статью Резервное копирование баз данных, я тогда говорил, что сервер SQL выполняет «размытое» резервное копирование, потому что резервное копирование не выполняется в одно мгновение, а занимает некоторый отрезок времени, в течение которого база данных продолжает работать. В следствие того, что в базу данных продолжают вноситься изменения в процессе выполнения резервного копирования, резервная копия оказывается в несогласованном состоянии – мы можем получить часть данных в резервной копии, которые были внесены до большого изменения и часть, относящихся к периоду времени после большого изменения. Для того чтобы решить данную проблему, сервер SQL может использовать ту часть журнала транзакций, которая записывалась в ходе выполнения резервного копирования, для восстановления данных резервной копии. После того, как данные будут восстановлены с резервной копии, процесс полного восстановления может использовать прокрутку вперед всех транзакций, которые имели место в ходе выполнения резервного копирования – для приведения данных в согласованное состояние.

Есть одна важная вещь, которую вам необходимо знать о полном восстановлении – если вы выполняете полное восстановление базы данных, вы не можете использовать более одного файла журнала транзакций. Зная механизм записи файлов журналов, можно утверждать, что существует возможность того, что часть транзакций будет иметь свое начало в одном журнале, а окончание – в другом. Если мы запустим процесс полного восстановления, то после использования первого журнала, сервер SQL зафиксирует, что часть транзакций не завершена и, поэтому, применит к ним процедуру отката. Теперь, теоретически, если мы будем применять для восстановления следующий журнал, что может произойти? Так как мы запустили процесс полного восстановления после применения резервной копии первого журнала, у нас окажется только вторая половина транзакций, начавшихся в первом журнале, и у сервера SQL может не оказаться соображений, что с ними делать. Кроме того, мы не можем просто пропустить эти первые транзакции – более поздние транзакции могут оказаться зависимыми от этих первых изменений. Для того чтобы разрешить данную проблему и иметь возможность использования нескольких резервных копий журналов, сервер SQL дает нам возможность выбрать, запускать ли процесс полного восстановления или нет. Это предоставляет нам право восстановить сначала первую резервную копию журнала (которая содержит первую половину наших транзакций) и затем применить вторую резервную копию (которая содержит окончание транзакций) до того, как будет запущен процесс полного восстановления.

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

Достаточно технической болтовни, давайте примем следующий план полного восстановления базы данных:

1. Выполняйте резервное копирование текущего журнала транзакций, если это возможно – это позволит вам полностью восстановить базу данных на момент аварии;
2. Восстановите наиболее свежую полную резервную копию без полного восстановления базы данных;
3. Если у вас есть дифференциальная резервная копия, восстановите наиболее свежую без полного восстановления базы данных;
4. Восстановите все резервные копии журналов транзакций, по порядку, от последней полной резервной копии (или дифференциальной копии, если таковые имеются) без восстановления базы данных;
5. Восстановите резервную копию файла журнала, которую вы выполнили в шаге 1 и выполните полное восстановление базы данных.

Заметьте, что если вы не можете выполнять резервное копирование журнала (шаг 1), вам нужно будет выполнять полное восстановление базы данных после шага 4. При этом вы сможете восстановить базу данных только на состояние, совпадающее с окончанием последней резервной копии журнала транзакций.

Есть два пути, которыми вы можете осуществлять данный план: используя Диспетчер Предприятия (Enterprise Manager) (к сожалению, там нет соответствующего мастера) или при помощи команды RESTORE. Мы рассмотрим, как провести полное восстановление базы данных, используя Диспетчер Предприятия, но если вам захочется узнать больше об использовании T-SQL команды RESTORE, ищите информацию по ключевому слову “RESTORE” в справочной системе Book Online сервера SQL.

В дереве Диспетчера Предприятия нажмите правой кнопкой мыши на требуемой базе данных и в появившемся меню выберите опцию “All Tasks”, а затем “Restore Database…”

На вкладке General окна Restore Database вы найдете большое количество различных настроек:

Рассмотрим их подробнее, начиная сверху:

“Restore as database” (восстановить как базу данных) – позволяет вам определить имя базы данных, в которую вы хотите провести восстановление. Если имя базы данных уже существует, база данных будет перезаписана в ходе восстановления.

• “Restore” – позволяет вам выбрать, какой тип восстановления вы хотите осуществить. Сервер SQL сохраняет записи обо всех резервных копиях, которые вы делали и вы можете затем восстановить их, используя опции “Database” или “Filegroups or files”. Однако если вы будете производить восстановление резервной копии, сделанной на другом компьютере или информация об истории резервного копирования окажется удаленной с сервера, вы должны будете использовать опцию “From device” и выбрать каждую из резервных копий вручную.
• “Database” (база данных) – позволяет вам восстановить все файлы, образующие базу данных.
• “Filegroups or files” (группы файлов или файлы) – позволяет вам восстанавливать некоторые или все файлы, образующие базу данных.
• “From device” (с устройства) – позволяет вам восстановить резервную копию, которая не была обнаружена при использовании предыдущих двух опций.

Если мы используем для восстановления опцию “Database”, нам становятся доступны следующие параметры:

• “Show Backup Of Database” (показать резервные копии базы данных) – этот параметр позволяет вам выбрать базу данных, для которой вы хотите увидеть существующие доступные резервные копии.
• “First Backup to restore” (восстановить первую резервную копию) – позволяет вам выбрать старейшую резервную копию (копии), которую вы хотели бы отобразить.
• “Point in time restore” (восстановление в определенный момент времени) – позволяет вам выбрать момент времени и дату, на которую вы хотите восстановить вашу базу данных (например, как раз до того, как произошла ошибка или были удалены критические данные). Полное восстановление в определенной точке времени доступно только для баз данных, которые используют полную или Bulk_Logged (записи групповых операций) модели восстановления (до тех пор, пока не имели место групповые операции после последнего полного резервного копирования). Нажатие кнопки “…” вызовет появление следующего окна:

Расположенное внизу окно показывает список всех резервных копий, которые были сделаны. Переключатель в столбце “Restore” показывает, хотите ли вы восстанавливать данную резервную копию.

Теперь давайте рассмотрим настройки, доступные на вкладке “Options”:

Как всегда начнем сверху окна:

• Думаю, что первые три настройки говорят сами за себя.
• “Restore database files as” (восстановить файлы базы данных как)– позволяет вам переименовать или переместить любые файлы, которые вы восстанавливаете, из расположения, где они были сохранены в ходе резервного копирования.
• “Leave database operational…” (оставить базу данных работающей) – позволит запустить процесс полного восстановления после того, как резервные копии будут восстановлены. Если вы выберите несколько резервных копий на вкладке “General”, процесс полного восстановления не начнется до тех пор, пока все резервные копии не будут восстановлены.
• “Leave database nonoperational…” (оставить базу данных неработающей) – процесс полного восстановления не запускается, пользователи не имеют возможность получить доступ к базе данных.
• “Leave database read-only…” (оставить базу данных доступной только для чтения) – процесс полного восстановления не запускается, но пользователи имеют возможность получить доступ к базе данных с разрешением read (без права записи/редактирования данных).

После того, как вы выполните все необходимые вам настройки, нажмите кнопку ОК для полного восстановления базы данных. После того, как полное восстановление будет завершено, вы увидите следующее диалоговое окно:

Другие настройки резервного копирования

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

Прежде всего, сервер SQL позволяет выполнять резервное копирование сразу на несколько устройств одновременно, что может значительно уменьшить время на выполнение резервного копирования/восстановления с/на магнитную ленту. Рисунок, расположенный ниже показывает два файла (однако, также это могут быть два устройства для записи магнитной ленты), используемые для резервного копирования базы данных EXBackup. Заметьте, что вам потребуются оба файла, если вы захотите восстановить резервную копию.

(Также заметьте: для получения доступа к окну “SQL Server Backup” в Диспетчере Предприятия нажмите правой кнопкой мыши на иконке базы данных, резервное копирование которой хотите осуществить, затем выберите опцию “The Tasks…” из всплывающего меню и “Restore Database”).

Кроме того, есть еще несколько настроек на вкладке “Options”, которые, по моему убеждению, важно знать:

“Verifying backup upon completion” (проверка резервной копии по завершению) – дает уверенность, что у вас «хорошая» резервная копия, для чего «читает» магнитную ленту/файл и проверяет ее на наличие любых повреждений данных. Отрицательной стороной данной настройки является значительное увеличение времени проведения резервного копирования.

“Remove inactive entries from transaction log” (удалить неиспользуемые записи из журнала транзакций) – эквивалентна расширению NO TRUNCATE команды backup. Если этот переключатель включен, то записи в файле журнала, которые больше не требуются после проведения резервного копирования, становятся доступными для перезаписи. Если этот переключатель выключен, то записи в файле журнала, которые больше не требуются после проведения резервного копирования не удаляются (т.е. NO TRUNCATE (не усекаются)) из журнала транзакций.

Опция “Media set name” (установка имени носителя) – позволяет вам дать имя магнитной ленте, которое должно быть таким же для записи на эту ленту. Кроме того, вы можете установить дату, до истечения которой лента не может быть перезаписана (если только вы не выполняете перезапись вручную). Это позволяет вам защитить ленту от случайного перезаписывания при выполнении работ по расписанию.

Раз уж мы заговорили о выполнении работ по расписанию, вас может заинтересовать вопрос, как вы можете редактировать/удалять плановые работы по выполнению резервного копирования, которые вы создали. Вы можете найти их в оснастке Диспетчер Предприятия в дереве SQL под вашим сервером, развертывая узлы Management, затем SQL Server Agent и, в заключении – Jobs.

Нажав правой кнопкой мыши на иконке работы, вы можете делать с нею следующие вещи: просмотреть ее историю (View its history), т.е. запускалась она или нет, запустить ее вручную или открыть окно ее свойств для того, чтобы установить расписание. Не переживайте, что мы узнали о работе по расписанию не так много, когда мы будем изучать Агента сервера SQL (SQL Server Agent) мы рассмотрим эту тему более подробно.

И последняя тема, относящаяся к резервному копированию, о которой я хотел бы рассказать – это Устройства Резервного Копирования (Backup Devices). До сих пор я использовал имена физических устройств для выполнения резервного копирования (например: e:\backups\SAT.BAK), однако, вы можете также создавать и использовать логические устройства, когда создаете резервные копии. Главное достоинство использования логических устройств заключается в том, что они могут помочь вам управлять вашими резервными копиями. Давайте создадим Устройство Резервного Копирования для упомянутого выше файла.

Для того чтобы создать Устройство Резервного Копирования, раскройте папку Management вашего сервера SQL щелкните правой кнопкой мыши на значке Backup и выберите опцию New Backup Device в появившемся меню. Это действие приведет к появлению следующего окна:

Для нашего примера мы должны ввести SAT в текстовое окно Name и затем e:\backups\SAT.BAK в окно File Name.

Теперь, когда мы будем выполнять резервное копирование базы данных, мы можем выбрать опцию Backup device и выбрать логическое устройство, которое мы создали (SAT), соответствующее файлу e:\backups\SAT.BAK.

И самая, самая, пре-самая последняя заметка о резервном копировании… обязательно выполняйте резервное копирование системных баз данных! Такие объекты, как регистрации сервера (что это такое – мы узнаем чуть позже в нашей серии) и такая информация, как наличие других баз данных на этом сервере, хранится в базе данных master. В случае полного выхода из строя вашего сервера и имея на руках только резервные копии пользовательских баз данных не стоит рассчитывать на быстрое восстановление – возможно, вам придется выполнить большой объем работы по внесению потерянной информации о сервере. Поэтому выполняйте резервное копирование ваших баз данных master, model и msdb почаще, особенно если вы только что внесли большое количество управляющих или конфигурирующих изменений.

Итак, это все о процессах резервного копирования\восстановления. На следующей неделе мы свернем чуть в сторону от рассмотрения вопросов администрирования и будем изучать, как создавать таблицы и другие объекты баз данных. И как всегда…

если у вас возникнут какие-либо технические вопросы, пожалуйста, присылайте их на доску объявлений сайта 2000Trainers.com SQL message board. Нетехнические вопросы, комментарии и обратная связь – по адресу моей электронной почты. Я надеюсь, что вы найдете эти статьи полезными и был бы рад узнать ваше мнение о них.

Mike Aubert, MCSE, MCDBA, MCSD.