Лекции по АБД. Лекция 4. Резервное копирование и восстановление
 Скачать 0.64 Mb.
|
|
РЕЗЕРВНОЕ КОПИРОВАНИЕ И ВОССТАНОВЛЕНИЕ В данной лекции рассматриваются две из наиболее важных задач, связан- ные с системой администрирования: резервное копирование и восстановление. Резервное копирование (backup) означает процесс создания копии базы данных и протоколов транзакций на резервных устройствах, которые в дальнейшем при необходимости могут быть использованы для восстановления данных. Восста- новление (recovery) - это процесс использования устройства резервной копии для замены неподтвержденных, несогласованных или потерянных данных. Выполнение резервного копирования - это мера предосторожности, кото- рую необходимо осуществлять для предотвращения потери данных. Несмотря на то, что компьютерная индустрия уже на протяжении десятилетий знает о необ- ходимости надежных стратегий резервного копирования, трагические истории потери данных по-прежнему остаются обычным явлением. Причины потери дан- ных можно разделить на следующие группы: ♦ программные ошибки; ♦ ошибки администратора или конечных пользователей; ♦ технические или программные системные сбои; ♦ отказ дискового накопителя; ♦ форс-мажорных обстоятельств (пожар, наводнение, кража и др). В процессе выполнения программы могут возникать условия, при которых программа аварийно завершается. Подобные программные ошибки связаны только с приложениями баз данных и обычно не оказывают влияния на всю си- стему базы данных. Поскольку такие ошибки основываются на дефектах про- граммной логики, система базы данных не может выполнить восстановления в подобных ситуациях. Поэтому восстановление должен выполнить сам програм- мист, который обязан выполнить обработку таких исключений с использованием операторов commit и rollback. Человеческий фактор – следующая причина потери данных. Пользователь с большими полномочиями может неумышленно потерять или разрушить дан- ные (удалить таблицы, некорректно изменить или удалить данные и т. д.). В иде- але этого никогда не должно происходить, и администратор может создать такой режим работы, который сделает маловероятным разрушение данных. Однако следует помнить, что люди достаточно часто совершают ошибки. Выход из строя системы может произойти в результате различных ошибок в оборудовании и программном обеспечении. В этих случаях содержимое основ- ной памяти компьютера может быть потеряно. Отказ дискового накопителя по- является, когда ломается головка чтения/записи дискового накопителя или, ко- гда система ввода/вывода обнаруживает разрушение дисковых секторов при вы- полнении операций ввода/вывода. В случае форс-мажорных обстоятельств система должна иметь достаточно доступной информации для восстановления данных. Это можно нормально вы- полнить, если устройство, содержащее необходимую для восстановления дан- ных информацию, будет храниться отдельно от другого оборудования и поэтому не будет разрушено или потеряно в результате катастроф или краж. Для большинства описанных выше ситуаций резервное копирование мо- жет быть лучшим решением по восстановлению данных. Методы резервного копирования. Резервное копирование базы данных яв- ляется процессом выгрузки данных (из базы данных, протокола транзакций или из файла) на устройства резервной копии, которые создаются и поддерживаются системой. Устройство резервной копии может быть дисковым файлом или маг- нитной лентой. Database Engine обеспечивает статические и динамические резервные ко- пии. Статическая резервная копия означает, что в процессе копирования только одна активная сессия, поддерживаемая системой, является той сессией, которая создает резервную копию. Иными словами, недопустимы пользовательские про- цессы во время выполнения копирования. Динамическое резервное копирование означает, что копирование базы данных может выполняться без останова сервера базы данных, удаления пользо- вателей или даже закрытия файлов. Пользователи даже не будут знать, что вы- полняется процесс резервного копирования. Database Engine предоставляет четыре различных метода резервного копи- рования, а именно: ♦ полное копирование базы данных; ♦ дифференцированное резервное копирование; ♦ резервное копирование протокола транзакций; ♦ резервное копирование файла или файловой группы. Полное копирование базы данных. Полное копирование базы данных за- хватывает то состояние базы данных, которое она имеет на момент начала копи- рования. В процессе полного копирования базы данных система копирует дан- ные, а также схему всех таблиц базы данных и соответствующие файловые структуры. Если полное копирование базы данных выполняется динамически, то система базы данных записывает любые действия, которые имеют место в про- цессе выполнения резервного копирования. Поэтому даже все неподтвержден- ные транзакции в протоколе транзакции будут записаны на устройство резерв- ной копии. Дифференцированное резервное копирование. Дифференцированное ре- зервное копирование создает копию только частей базы данных, которые изме- нялись с момента последнего полного копирования базы данных. (Как и в случае полного копирования базы данных любые действия, имеющие место в процессе дифференцированного резервного копирования, также копируются.) Преимуще- ством дифференцированного резервного копирования является скорость. Этот тип резервного копирования минимизирует время, требуемое для копирования, потому что количество копируемых данных значительно меньше, чем в случае полного резервного копирования. Полное копирование базы данных включает копии всех страниц базы данных. Резервное копирование протокола транзакций. Резервное копирование протокола транзакций учитывает только изменения, записанные в протокол. По- этому такая форма резервного копирования не основывается на физических ча- стях (страницах) базы данных, а только на логических операциях, т. е. на изме- нениях, выполненных операторами DML: insert, update и delete. Поскольку объем данных достаточно мал, этот процесс может быть выполнен значительно быст- рее, чем полное или дифференцированное резервное копирование. Нет смысла выполнять копирование протокола транзакций без полного ко- пирования базы данных, выполненного хотя бы однажды. Существуют две основные причины, по которым следует выполнять копи- рование протокола транзакций: во-первых, это сохранение данных, которые были изменены с момента последнего копирования протокола транзакций или базы данных на защищенное устройство; во-вторых, это правильное закрытие протокола транзакций перед началом новой порции действий с этим протоколом. (Активная часть протокола транзакций содержит все неподтвержденные тран- закции.) Используя результаты полного резервного копирования базы данных и надежную цепочку всех закрытых протоколов транзакций, можно распростра- нять копию базы данных на другие компьютеры. Эта копия базы данных затем может быть использована для замещения оригинальной базы данных в случае сбоев. Такой же сценарий может быть применен и при использовании полной копии базы данных и последней копии дифференциального копирования. Database Engine не дает возможности сохранять протокол транзакций в том же файле, в котором сохраняется сама база данных. Одной из причин этого является то, что при разрушении этого единственного файла использование про- токола транзакций для восстановления всех изменений с момента последнего ко- пирования не будет возможным. Использование протокола транзакций для записи изменений в базе данных является общим приемом почти для всех существующих реляционных СУБД. Несмотря на это, могут быть ситуации, когда становится полезным отключение такой возможности. Например, выполнение тяжелой загрузки данных в базу дан- ных может занять несколько часов. Такая программа будет выполняться много быстрее, если отключить протоколирование. С другой стороны, отключение про- цесса создания протокола может быть опасным, т. к. это разрушает существую- щие цепочки в протоколе транзакций. Чтобы обеспечить надежность базы дан- ных, строго рекомендуется выполнить полное резервное копирование базы дан- ных после успешного завершения такой загрузки данных. Одна из наиболее общих ошибок системы возникает, когда переполняется протокол транзакций. Подобная проблема может привести к полному останову системы. Если память, используемая для протокола транзакций, заполняется на 100%, то система должна остановить все выполняющиеся транзакции, пока па- мять для протокола транзакции не будет освобождена. Эта проблема может быть устранена только при частом выполнении резервного копирования протокола. Дифференцированное резервное копирование и копирование протокола транзакций минимизируют время, требуемое для резервного копирования базы данных. Однако между ними существует значительное различие: копирование протокола транзакций содержит все изменения строки, которые выполнялись не- сколько раз с момента последнего копирования, в то время как дифференциро- ванное резервное копирование содержит только последнюю выполненную мо- дификацию такой строки. Некоторые различия между копированием протокола и дифференцирован- ным копированием не имеют особого значения. Преимуществом дифференциро- ванного копирования является то, что вы экономите время в процессе восстанов- ления, потому что для полного восстановления базы данных вам нужна полная копия базы данных и только лишь последняя дифференцированная копия. Если вы используете копию протокола в таком сценарии, вы должны использовать полную копию базы данных и все существующие копии протоколов транзакций для приведения базы данных в согласованное состояние. Недостатком диффе- ренцированного копирования является то, что вы не можете использовать такую копию для восстановления базы данных на конкретный момент времени, потому что не существует истории промежуточных изменений базы данных. Резервное копирование файла или файловой группы. Резервное копирова- ние файла (или файловой группы) дает возможность копировать указанные файлы базы данных (или файловые группы) вместо копирования всей базы дан- ных. В этом случае Database Engine копирует только заданные вами файлы. От- дельные файлы (или файловые группы) могут быть восстановлены из копии базы данных, позволяя выполнить восстановление после сбоя, который повлиял лишь на небольшое подмножество файлов базы данных. Для восстановления отдель- ных файлов или файловых групп можно использовать или копию базы данных, или копию файловой группы. Это означает, что вы можете использовать копии базы данных и протокола транзакций в качестве вашей процедуры резервного копирования и в то же время иметь возможность восстанавливать отдельные файлы (и файловые группы) из копий базы данных. Копирование файла базы данных рекомендуется выполнять только когда база данных, которая должна быть скопирована, является очень большой, и нет достаточно времени для полного копирования базы данных. Выполнение резервного копирования. Выполнить резервное копирование можно, используя следующие средства: ♦ операторы Transact-SQL; ♦ SQL Server Management Studio. Все типы операций резервного копирования могут быть выполнены при использовании двух операторов Transact-SQL: ♦ backup database; ♦ backup log. Database Engine позволяет вам копировать базы данных, протоколы тран- закций и файлы на такие устройства резервного копирования, как диск и магнит- ная лента. Дисковое устройство копии может размещаться на локальном жест- ком диске, на сервере, на удаленном диске или на общем сетевом ресурсе. Database Engine позволяет добавлять новые копии в файл, который уже содер- жит копии той же самой или другой базы данных. При добавлении нового набора копий на существующий носитель предыдущее содержимое носителя остается нетронутым, а новая копия записывается после последней копии на этом носи- теле. Не выполняйте резервное копирование файлов на тот же физический диск, на котором хранится база данных или протокол транзакций! Если диск с базой данных будет разрушен, то резервная копия, которая хранится на том же самом диске, также будет неработоспособной. Магнитная лента в качестве устройства для хранения резервной копии обычно используется таким же образом, что и дисковое устройство. Преимуществом ленточных устройств по сравнению с дис- ковыми устройствами является простота их администрирования и операций над ними. Оператор backup database используется для полного копирования базы данных или дифференцированного резервного копирования. Этот оператор имеет следующий синтаксис. BACKUP DATABASE {db_name | @variable} ТО device_list [MIRROR ТО device_list2] [WITH | option_list] Здесь db_name является именем базы данных, для которой должно быть выполнено резервное копирование. Имя базы данных также может быть задано переменной invariable. Параметр device_list задает одно или более имен устройств, где будет сохраняться копия базы данных. Параметр device_list может быть списком имен дисковых файлов или магнитных лент. Синтаксис для этих устройств таков: {logical_device_name | @logical_device_name_var } | { DISK | ТАРЕ } = { ‘physical_device_name' | @physiсаl_device_name_var } Здесь имя устройства может быть либо логическим именем (или переменной), либо физическим именем, начинающимся с ключевых слов DISK или ТАРЕ. Опция mirror то указывает, что сопровождающий набор устройств явля- ется отображением зеркального набора устройств. Такие устройства копии должны быть идентичными по типу и по количеству устройствам, заданным в предложении то. В отзеркалированном наборе устройств все устройства резерв- ной копии должны иметь одни и те же свойства. Параметр option_list содержит ряд опций, которые могут быть заданы для различных типов резервных копий. Наиболее важными опциями являются сле- дующие: differential; noskip/skip; noinit/init; noformat/format; unload/nounload; me- dianame, mediadescription и mediapassword; blocksize; compression. Первая опция, differential, задает дифференцированное резервное копиро- вание. Все другие предложения в этом списке относятся к полному копированию базы данных. Опция skip отменяет проверку завершения и имени набора копии, которая обычно выполняется в backup database для предотвращения перезаписи наборов резервных копий. Опция noskip, которая является опцией по умолчанию, указы- вает оператору backup, что должна быть выполнена проверка дат завершения и имен всех наборов резервных копий до их перезаписи. Опция init используется для перезаписи любых существующих данных на устройстве резервной копии. Эта опция не перезаписывает заголовок устройства, если он существует. Если существует резервная копия, которая еще не закончена, то операция копирования отменяется. В этом случае используйте комбинацию опций skip и init для перезаписи устройства резервной копии. Опция noinit, кото- рая задается по умолчанию, добавляет резервную копию к существующим ко- пиям на устройстве. Опция format служит для записи заголовков для всех файлов (или ленточ- ных томов), которые используются для резервного копирования. По этой при- чине применяйте эту опцию для инициализации устройства копирования. Когда вы используете опцию format для выполнения копирования на устройство маг- нитной ленты, то предполагается присутствие опций init и skip. Аналогично предполагается опция init, если для файла устройства задана опция format. Опция noformat, являющаяся опцией по умолчанию, указывает, что операция копирова- ния обрабатывает существующий заголовок устройства и набор копий на томах устройства. Опции unload и noun load выполняются, только если устройством копиро- вания является магнитная лента. Опция unload, которая является опцией по умол- чанию, указывает, что магнитная лента автоматически перематывается и данные выгружаются с ленточного устройства после завершения резервного копирова- ния. Используйте опцию nounload, если система базы данных не должна перема- тывать (и разгружать) магнитную ленту автоматически. Medianame, mediadescription и mediapassword задают описание, имя и па- роль для набора внешних устройств соответственно. Опция blocksize задает фи- зический размер блока в байтах. Поддерживаемыми размерами являются 512, 1024, 2048, 4096, 8192, 16384, 32 768 и 65 536 (64 Кбайт) байтов. Значением по умолчанию для ленточных устройств является 65 536 байтов и 512 байтов для всех других устройств. SQL Server 2008 поддерживает сжатый вариант резервной копии. Для за- дания копирования в сжатом формате используйте опцию compression в опера- торе backup database. В примере выполняется резервное копирование базы дан- ных sample и сжатие файла резервного копирования. USE Моя_БД2; BACKUP DATABASE Моя_БД2 TO DISK = 'E:\Моя_БД2.bak' WITH INIT, COMPRESSION; Если получено сообщение об ошибке "Access Denied" ("Доступ запрещен") для каталога на устройстве С:, измените размещение хранения для файла Моя_БД2.bak на другой каталог (BACKUP DATABASE WITH COMPRESSION не поддерживается в Express Edition with Advanced Services). Если вы хотите узнать, сжимается ли конкретный файл копии, используйте вывод оператора restore headeronly, который описан ниже. Оператор backup log применяется для создания резервной копии протокола транзакций. Этот оператор имеет следующий синтаксис: BACKUP LOG {db_name | @variable} ТО device_list [MIRROR ТО device_list2] [WITH option_list] Здесь db_name, @variable, device_list, device_list2 имеют те же самые значения, что и параметры с теми же именами в операторе backup database. Па- раметр option_list имеет те же опции, что и в операторе backup database, кроме того, он поддерживает специфические опции протокола no_truncate, norecovery и standby. Используют опцию no_truncate, если требуется выполнять копирование протокола без его усечения, т. е, эта опция не очищает подтвержденные транзак- ции в протоколе. После выполнения этой опции система записывает все послед- ние действия с базой данных в протокол транзакций. Поэтому опция no_truncate позволяет восстанавливать данные прямо до той точки, когда произошел сбой базы данных. Опция norecovery копирует остаток протокола и оставляет базу данных в состоянии восстановления. Значение norecovery будет полезным, когда сбой про- исходит во вторичной базе данных (базе данных - получателе) и при сохранении остатка протокола перед операцией восстановления. Опция standby копирует остаток протокола и оставляет базу данных в режиме только для чтения и в со- стоянии standby. (восстановление и состояние standby описываются ниже). Резервное копирование с помощью Management Studio. В начале резерв- ного копирования базы данных или протокола транзакции необходимо указать (или создать) устройства копирования. SQL Server Management Studio позволяет создавать дисковые и ленточные устройства одним и тем же образом. В обоих случаях разверните сервер, разверните узел Объекты сервера, щелкните правой кнопкой мыши по узлу Устройства резервного копирования и выберите пункт Создать устройство резервного копирования. В диалоговом окне Устройства резервного копирования (рис. 1) введите имя дискового устройства (если вы установили переключатель Файл) или ленточного устрой- ства (если вы установили переключатель Лента). В первом случае можно щелк- нуть по кнопке многоточия ... в правой части поля для отображения размещения существующих устройств для резервных копий. Во втором случае, если устрой- ство Лента не может быть активировано, то это означает, что не существует ни- каких ленточных устройств на локальном компьютере. Рис. 1. Диалоговое окно Устройство резервного копирования После задания устройства для резервного копирования, можно выполнять резервное копирование базы данных. Разверните сервер, разверните узел Базы данных, щелкните правой кнопкой мыши по нужной базе данных. После выде- ления Задачи выберите Создать резервную копию. Появится диалоговое окно ре- зервного копирования (рис. 2). На странице Общие этого диалогового окна из раскрывающегося списка Тип резервной копии выберают тип резервной копии: Полная, Дифференцированная или Протокол транзакции, в поле Имя введите имя набора резервных копий и, при желании, в поле Описание - описание этого набора копий. В данном диалоговом окне можно выбрать срок хранения для этой резервной копии. В области Назначение выберите существующее устройство, щелкнув по кнопке Добавить. Кнопка Удалить позволяет удалить одно или более устройств резервных копий из списка используемых устройств. Рис. 2. Диалоговое окно резервного копирования страница Общие Чтобы на странице Параметры (рис. .3) добавить копию к существую- щему набору копий на выбранном устройстве, отметьте переключатель Доба- вить в существующий резервный набор данных. Выбор переключателя Переза- писать все существующие резервные наборы данных в том же поле перезаписы- вает все существующие резервные копии на выбранном устройстве резервных копий. Для создания и верификации дифференцированной копии базы данных или протокола транзакции выполняйте те же действия, только выберите соответ- ствующий тип резервной копии в поле Тип резервной копии на странице Общие. Рис. 3. Диалоговое окно резервного копирования страница Параметры После того как все опции будут выбраны, щелкните по кнопке ОК. Будет создана резервная копия базы данных или протокола транзакции. Имя, физиче- ское размещение и тип устройств резервного копирования могут быть показаны, если вы выберете сервер, развернете папку Объекты сервера и затем развернете папку Устройства резервного копирования. Хорошо спланированный график по срокам операций резервного копиро- вания позволит избежать недостатков в работе системы в процессе деятельности пользователей. SQL Server Management Studio поддерживает такое планирова- ние, предоставляя простой в использовании графический интерфейс для созда- ния расписания резервного копирования. Какие базы данных копировать? Рекомендуется копировать регулярно базу данных master и все производственные базы данных. База данных master является наиболее важной базой данных системы, по- тому что она содержит информацию обо всех базах данных в системе. По этой причине следует выполнять ее резервное копирование на регулярной основе. По- мимо этого, рекомендуется копировать базу данных master каждый раз, когда выполняются операторы или хранимые процедуры, потому что Database Engine автоматически изменяет базу данных master. Выполняют только полное резервное копирование базы данных master. Система не поддерживает дифференцированное резервное копирование, копиро- вание протокола транзакций или копирование файлов для этой базы данных. Многие действия приводят к модификации базы данных master, например, создание, изменение и удаление базы данных; изменения протокола транзакций. Если не выполнять резервного копирования базы данных master, то придется полностью пересоздавать системные базы данных, потому что при разрушении базы данных master будут потеряны все существующие созданные пользовате- лем базы данных, на которые она ссылается. Также рекомендуется выполнять резервное копирование производствен- ных баз данных на регулярной основе. Дополнительно, следует выполнять ре- зервное копирование любых производственных баз данных, после того как с ба- зами данных были выполнены следующие действия: после их создания; после создания индексов; после создания протокола транзакций; после выполнения не- протоколируемых операций. Восстановление баз данных. Database Engine поддерживает автоматиче- ское и ручное восстановление баз данных. Автоматическое восстановление яв- ляется средством, позволяющим сохранить работоспособность системы при воз- никновении ошибок. Database Engine выполняет автоматическое восстановле- ние каждый раз после его перезапуска после возникновения ошибки или после его останова. Процесс автоматического восстановления проверяет, требуется ли восстановление базы данных. Если да, то каждая база данных возвращается в ее последнее согласованное состояние при использовании протокола транзакций. В процессе автоматического восстановления Database Engine проверяет протокол транзакций от последней контрольной точки до точки, в которой про- изошел отказ системы или был выполнен останов Database Engine. Контрольная точка - это самая последняя точка, при которой все изменения данных были за- писаны в базу данных из оперативной памяти. По этой причине контрольная точка обеспечивает физическую согласованность данных. Протокол транзакций содержит подтвержденные транзакции (транзакции, которые были успешно выполнены, но их изменения пока еще не записаны в базу данных) и неподтвержденные транзакции (транзакции, которые не были успешно выполнены до появления сбоя или останова системы). Database Engine повторяет все подтвержденные транзакции, следовательно, делает изменения в базе данных постоянными и отменяет часть неподтвержденных транзакций, ко- торые выполнялись до контрольной точки. Database Engine вначале выполняет автоматическое восстановление базы данных master, после этого восстанавливаются все другие системные базы дан- ных. Затем восстанавливаются базы данных, созданные пользователями. Ручное восстановление базы данных задает приложение полного копиро- вания базы данных и приложение для всех протоколов транзакций в последова- тельности их создания. После этого база приводится в то же (согласованное) со- стояние, которое она имела в тот момент времени, когда в последний раз выпол- нялось резервное копирование протокола транзакций. Когда восстанавливается база данных с использованием полной резервной копии базы данных, Database Engine вначале пересоздает все файлы базы данных и размещает их на соответствующих физических устройствах. После этого си- стема пересоздает все объекты базы данных. Database Engine может выполнять некоторые формы восстановления ди- намически (пока выполняется экземпляр системы базы данных). Динамическое восстановление улучшает доступность системы, потому что в этом случае недо- ступны только данные, подлежащие восстановлению. Динамическое восстанов- ление позволяет восстановить либо целый файл базы данных, либо файловую группу ("восстановлением в режиме онлайн"). Сохраненные данные называются набором резервной копии. Прежде чем запускать на выполнение процесс восстановления, нужно быть уверенным, что: набор резервной копии содержит те данные, которые нужно восстанавливать; набор резервной копии является пригодным к восстановлению. Database Engine поддерживает множество операторов Transact-SQL, кото- рые позволяют определить, что набор резервной копии является пригодным к восстановлению и содержит нужные данные. Следующие четыре опции, помимо других, принадлежат этому множеству. ♦ RESTORE LABELONLY. Этот оператор используется для отображе- ния информации заголовка внешнего устройства (диска или магнитной ленты), применяется в процессе резервного копирования. Выводом этого оператора яв- ляется единственная строка, которая содержит итоговую информацию о заго- ловке (имя внешнего устройства, описание процесса резервного копирования и дату этого процесса). ♦ RESTORE HEADERONLY. В то время как оператор restore labelonly дает краткую информацию о заголовке файла устройства резервной копии, дан- ный оператор дает информацию о резервных копиях, которые хранятся на устройстве резервных копий. Этот оператор отображает в одной строке итоговые данные по каждой резервной копии на устройстве резервных копий. ♦ RESTORE FILELISTONLY. Данный оператор возвращает результиру- ющий набор, который отображает базу данных и протоколы транзакций, содер- жащиеся в наборе резервной копии. Можно отображать информацию только об одном наборе резервной копии за один раз. По этой причине, если указанное устройство резервной копии содержит несколько резервных копий, нужно зада- вать обрабатываемую позицию набора резервной копии. Используйте restore filelistonly, если точно не знаете, существуют ли наборы резервных копий, или где располагаются файлы конкретного набора ре- зервной копии. В обоих случаях можно проверить все или только часть устройств для создания общей картины существующих резервных копий. ♦ RESTORE VERIFYONLY. Проверяет резервную копию без ее исполь- зования в процессе восстановления, а также проверяет существование всех устройств резервного копирования (магнитных лент или дисков) и может ли быть прочитана существующая информация. По сравнению с тремя предыдущими операторами оператор restore verifyonly поддерживает две особые опции, а именно: loadhistory выполняет до- бавление информации резервного копирования к таблице историй резервных ко- пирований; stats отображает каждый раз сообщение, когда считывается новая порция информации. Используется в качестве масштаба процесса (значением по умолчанию является 10). Восстановление с использованием операторов T-SQL. Все операции вос- становления могут быть выполнены с помощью двух операторов T-SQL: RESTORE database; RESTORE LOG. Первый используется для выполнения процесса восстановления базы дан- ных и имеет следующий синтаксис. RESTORE DATABASE {db_name | @variable} [FROM device_list] [WITH option_list] Здесь db_name - имя базы данных, которая будет восстанавливаться. Имя базы данных может задаваться и с использованием переменной @variable . Пара- метр device_list задает одно или более имен устройств, на которых располага- ется резервная копия базы данных. Если не задавать предложение FROM , то будет иметь место только процесс автоматического восстановления, а не процесс вос- становления с резервной копии, и в этом случае необходимо задать одну из оп- ций recovery, norecovery или standby. Это действие возможно, если вы хотите пе- реключиться на резервный сервер. Параметр device_list может быть списком имен дисковых файлов или магнитных лент. Параметр option_list содержит не- сколько опций, которые могут быть заданы для различных форм резервных ко- пий. Наиболее важными опциями являются: ♦ recovery/norecovery/standby; ♦ checksum/no_checksum; ♦ replace; ♦ partial; ♦ stopat; ♦ stopatmark; ♦ stopbeforemark. Опция recovery инструктирует Database Engine о том, что необходимо про- пускать любые подтвержденные транзакции и отменять неподтвержденные транзакции. После применения опции recovery база данных будет находиться в согласованном состоянии и будет готовой для использования. Эта опция явля- ется опцией по умолчанию. Рекомендуется использовать опцию recovery при восстановлении с исполь- зованием последнего протокола транзакций или при восстановлении с полной резервной копии базы данных без последующей резервной копии протокола транзакций. При опции norecovery Database Engine не выполняет откат непод- твержденных транзакций, потому что планируется применять следующие ре- зервные копии. После применения опции norecovery база данных будет недо- ступной для использования. Используйте опцию norecovery при восстановлении с последним протоколом транзакций. Опция standby является альтернативой для опций recovery и norecovery, она используется с резервным сервером. При доступе к данным, хранящимся на резервном сервере, обычно восстанавливают базу данных после восстановления протокола транзакций. С другой стороны, если восстанавливают базу данных на резервном сервере, то нельзя для процесса восстановления применять дополни- тельные журналы с производственного сервера. В этом случае использют опцию standby для того, чтобы разрешить пользователям обращаться к резервному сер- веру. Дополнительно позволяют системе выполнять восстановление с дополни- тельных протоколов транзакций. Опция standby предполагает существование файлов отмены, которые служат для отката изменений при восстановлении до- полнительных протоколов. Опция checksum инициирует верификацию контрольных сумм резервной копии и контрольных сумм страниц, если они присутствуют. Если контрольные суммы отсутствуют, операция restore выполняется без верификации. Опция nochecksum явно отменяет проверку контрольных сумм в операции восстановле- ния. Опция replace заменяет существующую базу данных данными из резерв- ной копии другой базы данных. В этом случае сначала удаляется существующая база данных, а различия между именами файлов базы данных и именем базы дан- ных игнорируются. Если не используют опцию replace, то система базы данных выполняет безопасную проверку, которая гарантирует, что существующая база данных не будет заменяться, если имена файлов базы данных или имя самой базы данных отличаются от соответствующих имен в наборе резервной копии. Опция partial задает операцию частичного восстановления. С этой опцией можно восстанавливать часть базы данных, присутствующую в ее первичной файловой группе и в одной или более вторичных файловых групп, которые зада- ются в дополнительной опции под названием filegroup. Опцию partial нельзя применять в операторе restore log. Опция stopat позволяет восстанавливать базу данных в том состоянии, ко- торое она имела на конкретный момент времени до возникновения сбоя, при по- мощи задания точного времени. Database Engine восстанавливает все подтвер- жденные транзакции, которые были записаны в протокол транзакций до задан- ного момента времени. Если вы хотите восстанавливать базу данных, указывая момент времени, выполните оператор restore database с использованием предло- жения norecovery. После этого выполните оператор restore log для применения всех резервных копий протокола транзакций, указав имя базы данных, устрой- ство резервной копии, с которой будет восстанавливаться резервная копия про- токола транзакций, и задав предложение stopat. Опции stopatmark и stopbeforemark задают восстановление до отметки. Оператор restore database также используется для восстановления базы данных с дифференцированной резервной копии. Синтаксис и опции для восста- новления базы данных с дифференцированной резервной копии такие же, как и для восстановления с полной резервной копии базы данных. В процессе восста- новления с дифференцированной резервной копии Database Engine восстанавли- вает только часть базы данных, которая была изменена с момента последнего полного резервного копирования базы данных. Поэтому восстанавливайте пол- ную резервную копию базы данных до того, как вы будете восстанавливать диф- ференцированную резервную копию. Оператор restore log используется для выполнения процесса восстановле- ния протокола транзакций. Этот оператор имеет ту же самую синтаксическую форму и те же самые опции, что и оператор restore database. Восстановление с использованием Management Studio Для восстановления базы данных с полной резервной копии базы данных разверните сервер, выберите узел Базы данных и щелкните правой кнопкой мыши по нужной базе данных. Затем щелкните по Задачи, выберите Восстано- вить, а затем База данных. Появится диалоговое окно Восстановление базы дан- ных (рис. 4). На странице Общие выберите базы данных, в которые и из которых вы хотите выполнять восстановление. Затем отметьте тип резервной копии, ко- торую вы собираетесь обрабатывать (в данном случае Полное восстановление). Рис. 4. Диалоговое окно Восстановление базы данных, страница Общие Если вы выполняете восстановление из резервной копии протокола тран- закций, не забывайте, что последовательность в восстановлении отличается от резервного копирования. Сначала восстановите полную резервную копию базы данных. Затем восстанавливайте все соответствующие протоколы транзакций в последовательности их создания. Для задания подходящих опций восстановления выберите страницу Пара- метры (рис. 5) в диалоговом окне Восстановление базы данных. В верхней части этого окна выберите один или несколько типов восстановления. В нижней части этого окна можно выбрать одну из трех существующих опций. Выбор первой опции, указывает Database Engine, что нужно пройти по всем подтвержденным транзакциям и отменить все неподтвержденные транзакции. После применения этой опции база данных будет находиться в согласованном состоянии. Эта опция эквивалентна опции recovery в операторе restore database. Если вы щелкнете по второй опции, то Database Engine не выполнит откат неподтвержденных транзакций, потому что вы будете использовать последую- щие резервные копии. После того как вы примените эту опцию, база данных не будет доступной для использования, нужно будет восстановить дополнительные протоколы транзакций. Эта опция эквивалентна опции norecovery в операторе restore database. Используйте эту опцию с восстановлением всех самых послед- них протоколов транзакций или с восстановлением дифференцированной ре- зервной копии. Рис. 5. Диалоговое окно Восстановление базы данных, страница Параметры Выбор третьей опции, задает файл, который впоследствии будет использо- ван для отмены эффектов восстановления. Эта опция эквивалентна опции standby в операторе restore database. Процесс восстановления базы данных из дифференцированной резервной копии базы данных эквивалентен процессу восстановления из полной резервной копии базы данных. Если вы выполняете восстановление из дифференцирован- ной резервной копии, вначале выполните восстановление из полной резервной копии базы данных, прежде чем осуществлять восстановление соответствующей дифференцированной резервной копии. В отличие от резервной копии протокола транзакций, применяется только лишь последняя дифференцированная резерв- ная копия, потому что она включает в себя все изменения, выполненные после полного резервного копирования. Особенности копирования и восстановления системных баз данных Модели восстановления Модель восстановления позволяет управлять тем объемом данных, кото- рые есть риск потерять в подтвержденных транзакциях при разрушении базы данных. Модель также определяет скорость использования и размер резервной копии протокола транзакций. В дополнение к этому, выбор модели восстановле- ния оказывает влияние на размер протокола транзакций и на период времени, необходимый для выполнения резервного копирования протокола. Database Engine поддерживает три модели восстановления: • полную; • с неполным протоколированием; • простую. Все модели сохраняют данные в случае аварии, но существуют важные различия, которые необходимо знать при выборе модели восстановления для базы данных. Описание моделей восстановления приведено ниже. У каждой базы данных может быть своя модель восстановления. Выбор модели осуществ- ляется в окне Свойства БД на странице Параметры. Модель полного восстановления. В процессе полного восстановления все операции записываются в протокол транзакций. Поэтому эта модель предостав- ляет полную защиту против сбоев внешних устройств. Это означает, что можно восстанавливать базу данных с последней подтвержденной транзакции, которая была сохранена в файле протокола. В дополнение к этому можно восстанавли- вать данные на любой момент времени (предшествующий моменту сбоя). Чтобы обеспечить это, также полностью протоколируются такие операции, как select into, и выполнение утилиты bср. Помимо возможности восстановления на момент времени, модель полного восстановления позволяет также выполнять восстановление на отметку в прото- коле. Отметки в протоколе соответствуют заданной транзакции и добавляются в протокол, только если эта транзакция подтверждается. Модель полного восстановления также протоколирует все операции, свя- занные с оператором create index, подразумевая, что процесс восстановления данных теперь включает и создание индекса. В этом случае пересоздание индек- сов выполняется быстрее, потому что не нужно отдельно создавать их заново. Недостатком этой модели восстановления является то, что соответствую- щий протокол транзакций может быть очень большим по объему, и файлы на диске, содержащие этот протокол, могут быть заполнены очень быстро. Кроме того, для такого объемного протокола потребуется значительно больше времени на резервное копирование. Если используется модель полного восстановления, протокол транзакций должен быть защищен от сбоев внешних устройств. По этой причине обяза- тельно использование RAID 1 для защиты протокола транзакций. Модель восстановления с неполным протоколированием. Восстановление с неполным протоколированием поддерживает протоколы резервных копий при использовании минимального пространства в протоколе транзакции для некото- рых крупномасштабных или объемных операций. Протоколирование следую- щих операций является минимальным и не может управляться по принципу "опе- рация за операцией": • SELECT INТО; • CREATE INDEX; • утилита bср и BULK INSERT. Хотя объемные операции и не являются полностью запротоколирован- ными, не нужно выполнять полное резервное копирование базы данных после завершения подобной операции. В процессе восстановления с неполным прото- колированием резервные копии протокола транзакций содержат и протокол, и результат объемной операции. Это упрощает переход между полной моделью и моделью восстановления с неполным протоколированием. Модель восстановления с неполным протоколированием позволяет восста- навливать базу данных до конца резервной копии протокола транзакций (т. е. до самой последней подтвержденной транзакции). Дополнительно можно восста- навливать базу данных на любой момент времени, если не выполнялись объем- ные операции. То же самое верно и для операции восстановления до именован- ной отметки в протоколе. Преимуществом модели восстановления с неполным протоколированием является то, что объемные операции выполняются много быстрее, чем под моде- лью полного восстановления, потому что они не протоколируются полностью. С другой стороны, Database Engine выполняет резервное копирование всех экстен- тов вместе с собственно протоколом. Поэтому для резервной копии протокола требуется гораздо меньше памяти, чем в случае полного восстановления. Время восстановления с резервной копии протокола также значительно увеличивается. Простая модель восстановления. В простой модели восстановления про- токол транзакций усекается, если появляется точка сохранения. Поэтому можно выполнять восстановление разрушенной базы данных только при использовании полной резервной копии базы данных или дифференцированной резервной ко- пии, потому что они не требуют резервной копии протокола. Стратегия резерв- ного копирования для этой модели является очень простой: выполнение восста- новления базы данных с существующей резервной копии базы данных и, если существуют дифференцированные резервные копии, применение самой послед- ней ее версии. Простая модель восстановления не означает, что вообще не существует протоколирования. Содержимое протокола не будет использовано для целей ре- зервного копирования, однако оно используется во время создания контрольной точки, где все транзакции протокола подтверждены или для них выполнен откат. Преимуществом простой модели восстановления является то, что произво- дительность всех объемных операций очень высокая, а требования к объему па- мяти протокола очень невысокие. С другой стороны, эта модель требует больше ручной работы, поскольку все изменения с момента самого последнего резерв- ного копирования базы данных (или получения дифференцированной резервной копии) должны быть восстановлены. В этой модели восстановления не допу- стимы восстановления на конкретный момент времени или восстановление стра- ниц. Кроме того, восстановление файлов допустимо только для вторичных фай- ловых групп только для чтения. Не рекомендуется использовать простую модель восстановления для про- изводственных баз данных. Изменение и редактирование модели восстановления. Можно изменить модель восстановления, используя опцию RECOVERY оператора ALTER DATABASE. Частью синтаксиса оператора ALTER DATABASE, связанного с мо- делями восстановления, является: SET RECOVERY [FULL | BULK_LOGGED | SIMPLE] Существуют два способа, с помощью которых можно редактировать теку- щую модель восстановления базы данных: • функция свойств databasepropertyex; • представление просмотра каталогов sys.databases. Если необходимо отобразить текущую модель восстановления базы дан- ных, используйте предложение recovery функции databaseproperty. В примере ниже показан запрос, который отображает модель восстановления базы данных sample. Эта функция отображает одно из значений FULL, BULK_LOGGED или SIMPLE. SELECT databasepropertyex('sample', 'recovery') Столбец recovery_modei_desc в представлении просмотра каталогов sys.databases отображает ту же информацию, что и функция databasepropertyex. SELECT name, database_id, recovery_model_desc AS model FROM sys.databases WHERE паше = 'sample' |