Регенерация
Подготовка к восстановлению
Оператор RESTORE
Параметры оператора RESTORE
Восстановление полной копии
Восстановление разностной копии
Восстановление журналов транзакций
Резервный сервер
Восстановление системных баз данных
Вопросы для повторения

Регенерация

Регенерация (recovery process) является первичным внутренним механизмом восстановления сервера баз данных, позволяющим обеспечить согласованность данных при перезагрузке сервера, по запросу пользователя или в следствии сбоя/аварии. Суть этого процесса в том, что сервер, путём анализа журналов транзакций и баз данных, определяет (естественно, после контрольной точки) какие транзакции записаны в журнале, какие из исполненных в действительности не были применены (тогда их применяют), а также какие транзакции ещё не завершены и могут быть откачены назад. При запуске SQL сервера регенерация всех баз данных запускается автоматически.
Если регенерация не в состоянии разрешить имеющиеся в базе данных проблемы, вы может приступить к восстановлению данных из резервных копий с помощью SQL SEM или оператора RESTORE DATABASE. При этом, сервер баз данных выполнит несколько обязательных проверок для резервных копий, дабы оградить Вас от случайной ошибки. Во первых, сообщение об ошибке будет Вам выведено, если имя базы данных в копии отличается от имени имеющейся на сервере и подлежащей восстановлению базы. Также, закончится всё ошибкой, если набор файлов в копии отличается от заменяемого на сервере. И наконец, если вы попытаетесь восстановить не все файлы, подлежащие замене, а это не допустимо из за их связанности, сервер также станет ругаться и укажет Вам полный перечень файлов, которые должны содержаться в резервной копии. Отключить эти проверки можно с помощью WITH REPLACE.

Подготовка к восстановлению

При восстановлении базы все её объекты будут созданы заново, так что если принято решение восстанавливаться из полной копии, можно уже не волноваться за состояние и содержание пострадавшей базы данных. Волноваться стоит о том, что именно Вы собираетесь восстанавливать, особенно, если копия у Вас не одна, а целый набор, за некоторый период времени. Кроме того, полезно учесть схему резервирования и принятые для этой схемы методы восстановления. Наиболее информативным инструментом, а главное наглядным, является SQL SEM. В нём можно визуально просмотреть имеющиеся наборы резервных копий и устройств резервирования, для того, что бы точно определить, какую из имеющихся копий базы данных (полную или разностную), а также набор отписанных по расписанию копий журнала транзакций нужно восстанавливать. Альтернативным методом можно считать использование специальных операторов T-SQL, о которых мы и поговорим ниже. Оператор RESTORE HEADERONLY представит на Ваш суд информацию: об имени и описании файла копии или резервного набора; тип устройства резервирования; метод (схема) резервирования; дата и время копирования; размер копии; порядковый номер файла копии в цепочке копий на устройстве резервирования. Оператор RESTORE FILELISTONLY выдаст: логические имена восстанавливаемых файлов и журналов; физические их имена; типы этих файлов (база или журнал); принадлежность их к группе файлов; размер резервного набора (Мб); максимально допустимый размер файла(Мб). Оператор RESTORE LABELONLY выдаст вам информацию о носителе копии, содержащуюся в заголовке носителя. Оператор RESTORE VERIFYONLY поможет проверить, цела ли Ваша копия, и можно ли её достоверно прочитать.
Процесс восстановления базы, штука весьма не тривиальная и чреватая всякими неожиданностями, поэтому постарайтесь ограничить доступ к серверу, на котором происходит восстановление данных. После этого, обязательно сделайте копию журнала транзакций, что бы зафиксировать то, что вы наработали до этого момента. При восстановлении базы данных, в качестве текущей базы должен быть задан master. Для того, что бы процессу восстановления никто не мог помешать, попросите любого члена ролей db_owner или sysadmin установить для восстанавливаемой базы параметр dbo use only в истину. Это можно сделать в SQL SEM или с помощью sp_dboption.

Оператор RESTORE

RESTORE DATABASE { database_name | @database_name_var }
[ FROM < backup_device > [,...n ] ]
[ WITH
    [RESTRICTED_USER ]
    [ [ , ] FILE = { file_number | @file_number } ]
    [ [ , ] PASSWORD = { password | @password_variable } ]
    [ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
    [ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
    [ [ , ] MOVE 'logical_file_name' TO 'operating_system_file_name' ]
            [,...n ]
    [ [ , ] KEEP_REPLICATION ]
    [ [ , ] { NORECOVERY | RECOVERY | STANDBY = undo_file_name } ]
    [ [ , ] { NOREWIND | REWIND } ]
    [ [ , ] { NOUNLOAD | UNLOAD } ]
    [ [ , ] REPLACE ]
    [ [ , ] RESTART ]
    [ [ , ] STATS [ = percentage ] ]
]

Где:
database_name – имя базы данных;
@database_name_var – переменная имени базы данных;
backup_device – устройство резервного копирования (резервирования);
file_number – номер файла;
и.т.д. и т.п.

Более подробно об устройстве резервирования:

< backup_device > ::=
    {
        {'logical_backup_device_name' | @logical_backup_device_name_var }
        | { DISK | TAPE } =
            { 'physical_backup_device_name' | @physical_backup_device_name_var }
    }
< file_or_filegroup > ::=
    {
        FILE = { logical_file_name | @logical_file_name_var }
        |
        FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
    }

Где:
logical_backup_device_name – логическое имя устройства резервирования;
physical_backup_device_name – физическое имя устройства резервирования, применяется при копирования во временное устройство резервного копирования.

Полный синтаксис и описание характеристик оператора RESTORE можно найти в Books Online.

В качестве примера, рассмотрим восстановление базы northwind, резервная копия которого была создана в постоянном файле.

USE master
RESTORE DATABASE northwind
FROM NorthwindBackupDevice

Как видите, всё очень просто и понятно. Теперь давайте рассмотрим применение разнообразных параметров оператора RESTORE DATABASE.

Поскольку мы уже говорили в предыдущем выпуске о процедуре регенерации, начнём с параметров: NORECOVERY | RECOVERY | STANDBY = undo_file_name.

По умолчанию, SQL сервер всегда пытается перед восстановлением базы запустить процесс регенерации WITH RECOVERY. На практике, этот параметр нужно использовать для полной копии или для последней резервной копии журнала транзакций. Это поможет восстановить согласованность данных. Если нужно восстанавливать и другие (не последнюю) копии журнала или разностные копии, следует использовать WITH NORECOVERY. Причина в том, что SQL сервер при регенерации данных отменяет все не завершённые транзакции и применяет все завершённые транзакции, что может привести к потере согласованности данных в процессе восстановления нескольких копий журнала, выполненных в разное время после полного или разностного резервного копирования (с целью очистить журнал). Для таких копий регенерация должна быть заблокирована, а разрешить её можно только при восстановлении последней копии журнала транзакций. Особенность параметра NORECOVERY ещё и в том, что без регенерации база не становится доступной для пользователей. Поэтому, если Вы по ошибке восстановите все копии с параметром WITH NORECOVERY, Вам придётся или инициировать регенерацию или перегрузить сервер, при старте которого всегда выполняется процедура регенерации для всех баз данных.

Параметры оператора RESTORE

Параметр FILE используется для указания на конкретную копию из возможного набора хранящихся на устройстве резервирования копий. Значением его должен являться порядковый номер копии в наборе.
Параметр MOVE … TO указывает место назначения копии, куда она должна восстанавливаться. Это может быть другой диск или сервер, а также резервный сервер.
Параметр REPLACE отключает проверки безопасности, призванные помешать записи резервной копии поверх существующей, другой базы, имеющей другое логическое имя или отличный от копии набор файлов.
Использовать перечисленные выше параметры можно не только для целей восстановления базы, но и для перемещения её в другое место. Однако, есть для этих целей и иной путь, например, использующий системные хранимые процедуры sp_attach_db или sp_attach_single_file_db. Эти процедуры позволяют прикрепить к новому master перемещённые в другое место базы или их файлы.
Синтаксис оператора RESTORE имеет целый ряд параметров, которые зависят от избранного Вами типа резервного копирования. Соответственно, перед началом процесса восстановления необходимо чётко для себя определить какая схема резервирования применялась в данном, конкретном случае, имеется ли полный набор файлов резервных копий, а также, что они являются доступными и не повреждены. Существенное влияние на план восстановления базы данных оказывают и причины, повлекшие за собой эту необходимость. В зависимости от того, стало ли причиной восстановления: повреждение физического диска, повреждение или порча файлов базы, необходимость переноса базы в другое место или необходимость отката введённой информации к состоянию на определённое время в прошлом; выбираются и разные способы применения параметров оператора RESTORE.
Далее мы рассмотрим параметры и способы их применения, которые определяются основными схемами резервного копирования: полной, разностной и копирование журнала, а также, восстановление избранных файлов.

Восстановление полной копии

Уж отмечалось, что при восстановлении полной копии все объекты базы автоматически создаются заново и в тех местах, где они располагались. Поэтому беспокоится о повреждённой базе не имеет смысла. Если будет восстанавливаться только полная копия, для восстановления согласованности данных применяют параметр RECOVERY. Если же кроме полной копии будут восстанавливаться разностные копии или копии журнала транзакций, для всех восстанавливаемых копий, кроме последней, необходимо отключить регенерацию данных параметром NORECOVERY, иначе, согласованность данных (как отмечалось в 26-м выпуске) будет нарушена. Ниже представлен пример скрипта по восстановлению полной копии базы данных Northwind из второй по счёту резервной копии устройства резервирования NorthwindBackupDevice.

USE master
RESTORE DATABASE Northwind
FROM NorthwindBackupDevice
WITH FILE = 2,
RECOVERY

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

Восстановление разностной копии по смыслу мало чем отличается от восстановления полной копии. Отличие в том, что предложение FROM указывает на файл разностной копии. Поскольку разностная копия включает в себя все изменения, которые произошли в базе на момент её создания с последнего полного/разностного копирования, восстанавливать создаваемые в этот же промежуток времени копии журнала транзакций (если таковые имеются) нет необходимости. Преимущество этого вида копирования/восстановления в том, что время, затраченное на восстановление разностной копии, как правило, меньше, чем время восстановления копий журнала транзакций за тот же период. Порядок восстановления следующий: восстанавливаем последнюю полную копию, потом последнюю разностную копию и копии журнала транзакций после последнего разностного копирования. Естественно, параметр RECOVERY должен использоваться только для самой последней из восстанавливаемых копий. Полную копию и все копии, которые будут восстанавливаться между ней и последней копией (например, журнала транзакций) нужно выполнять в режиме WITH NORECOVERY.

Восстановление журналов транзакций

Восстановление журналов транзакций имеет ряд особенностей, которые стоит отметить особо. Во первых, как и в случае с восстановлением полной и разностной копии, регенерация включается только для последней, восстанавливаемой копии журнала транзакций. Для копий журнала это особенно актуально, поскольку они отписываются, как правило, значительно чаще, чем остальные копии. Кроме того, можно восстановить данные практически до момента сбоя, повлекшего порчу базы. Без отписывания копий журнала транзакций это не возможно. Полный синтаксис оператора RESTORE LOG следующий:

RESTORE LOG { database_name | @database_name_var }
[ FROM < backup_device > [ ,...n ] ]
[ WITH
    [ RESTRICTED_USER ]
    [ [ , ] FILE = { file_number | @file_number } ]
    [ [ , ] PASSWORD = { password | @password_variable } ]
    [ [ , ] MOVE 'logical_file_name' TO 'operating_system_file_name' ]
            [ ,...n ]
    [ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
    [ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
    [ [ , ] KEEP_REPLICATION ]
    [ [ , ] { NORECOVERY | RECOVERY | STANDBY = undo_file_name } ]
    [ [ , ] { NOREWIND | REWIND } ]
    [ [ , ] { NOUNLOAD | UNLOAD } ]
    [ [ , ] RESTART]
    [ [ , ] STATS [= percentage ] ]
    [ [ , ] STOPAT = { date_time | @date_time_var }
        | [ , ] STOPATMARK = 'mark_name' [ AFTER datetime ]
        | [ , ] STOPBEFOREMARK = 'mark_name' [ AFTER datetime ]
    ]
]

Порядок восстановления следующий: вначале, восстанавливается полная копия и все последующие разностные (если таковые выполнялись), причём с включённым параметром WITH NORECOVERY; затем, по порядку, восстанавливаются копии журнала транзакций после последнего полного/разностного копирования, также с параметром WITH NORECOVERY. Регенерация применяется только к самой последней копии журнала транзакций. Если необходимо восстановить изменения базы до определённого времени, используется параметр STOPAT, время в котором устанавливается с точностью до минуты. Это ограничение не позволит восстановиться транзакциям, зарегистрированном в журнале после указанного для параметра STOPAT времени. Этот замечательный параметр нельзя использовать в сочетании с STANDBY или NORECOVERY. Согласованность данных будет восстановлена при восстановлении последнего журнала транзакций с параметром WITH RECOVERY. В прелагаемом ниже примере будет восстановлена полная копия и две копии журнала, причём копия второго журнала будет восстановлена до момента, на одну минуту опережающего событие краха базы данных, повлекшего за собой необходимость восстановления данных. База данных, как всегда, Northwind:

USE master
RESTORE DATABASE Northwind
FROM NorthwindBackupDevice
WITH NORECOVERY

Далее, восстанавливаем первый журнал (копии журнала отписывается в другой файл, хотя, можно и в NorthwindBackupDevice:

USE master
RESTORE LOG Northwind
FROM NorthwindLogBackupDevice
WITH FILE=1,
    NORECOVERY

Восстанавливаем второй файл. Сбой наступил в 0:01АМ, поэтому восстанавливаем на 0:00АМ. Заодно, делаем регенерацию, для согласованности данных:

USE master
RESTORE LOG Northwind
FROM NorthwindLogBackupDevice
WITH FILE=2,
    RECOVERY,
    STOPAT = ‘January 1, 2001 0:00 AM’

Для особо крупных баз данных, которые в простолюдье именуют VLDB (Very Large Database), может быть применена схема копирования отдельных файлов или групп файлов. Причиной восстановления файла может стать его повреждение или случайное удаление. Кроме восстановления непосредственно самого файла, нужно будет применить копии всех журналов транзакций, которые были после этого выполнены. Причём, SQL сервер применит только те транзакции, которые относятся к восстанавливаемому файлу или группе файлов. Если Вы собираетесь восстановить один файл, а часть таблицы из этого файла или её индексы размещаются в другом файле, Вам потребуется восстанавливать оба файла. Регенерация, как и во всех уже описанных случаях, выполняется при восстановлении последней копии, если их несколько или после копирования файла были выполнены копии журнала. Это позволит применить все завершённые транзакции, записи о которых сохранились в журнале транзакций, но сами они небыли ещё отражены в базе, а также будут отменены все не завершённые, но зарегистрированные в журнале транзакции. Перечисленные условия являются непременным условием согласованности данных после восстановления из резервной копии. В представленном ниже примере, база данных Northwind разбита на три файла, второй из которых был случайно удалён в новогоднюю ночь. После последнего резервного копирования файла NorthwindFile2 была выполнена одна копия журнала транзакций в NorthwindLogBackupDevice. Процедура восстановления тогда будет иметь следующий вид:

USE master
RESTORE DATABASE Northwind
FILE = NorthwindFile2
FROM NorthwindBackupDevice
WITH NORECOVERY

Поскольку существует ещё и копия журнала, восстанавливаем и её, а также делаем регенерацию:

USE master
RESTORE LOG Northwind
FROM NorthwindLogBackupDevice
WITH RECOVERY

Резервный сервер

Оператор RESTORE имеет ещё одно применение, отличное от задачи восстановления данных. Это перенос данных в специально сознанный для этого резервный сервер. Резервный сервер представляет собой специально выделенный для этих целей компьютер с установленным на нём SQL сервером, базы данных которого могут быть быстро приведены к точной копии основного сервера. Основное назначение такого сервера, это замена основного для снижения времени простоя. Однако возможно и другое его применение, способное снизить нагрузку на основной сервер. Если базы данных резервного сервера сделать доступными для чтения пользователей, то, таким образом, Вы сможете переключить нагрузку с основного на резервный сервер для приложений, которым не нужно вносить изменения в данные (например, для задач принятия решений). Также, наличие резервного сервера может облегчить DBA некоторые сервисные и профилактические функции, за счёт того, что их можно будет выполнять на резервном сервере или быстро переключить туда пользователей с основного, что бы провести необходимые работы. Например, таким образом можно производить разнообразные проверки данных утилитой DBCC (Database Consistency Checker), в целях выявления ошибок в их структуре или повреждений. Как правило, такие проверки занимают очень много времени и значительно увеличивают нагрузку на сервер, что мешает работать пользователям. С помощью резервного сервера выполнять проверку баз данных, а также проверку резервных копий после каждого их восстановления очень удобно.

Процесс создания резервного сервера не является сложной процедурой. Для этого Вы должны иметь необходимые актуальные копии системных и пользовательских баз данных и их журналов транзакций, которые потом восстанавливаются на резервный сервер. Т.к. местоположение баз меняется, в качестве одного из параметров оператора RESTORE нужно будет использовать MOVE…TO. Восстановление на резервный сервер происходит в режиме NORECOVERY или STANDBY. Регенерация данных не должна выполняться до тех пор, пока не возникнет необходимость замены основного сервера резервным. Если Вы выполнили регенерацию данных на резервном сервере, это позволит пользователям к нему подключаться, но не позволит Вам восстанавливать на нём следующие копии журнала транзакций.

Если же резервный сервер будет использоваться в режиме доступа только для чтения, выполнять регенерацию нет необходимости. Для обеспечения такого режима используют параметр STANDBY, который позволяет пользователям читать данные с резервного сервера, а также, восстанавливать на нём следующие копии журнала транзакций. При этом параметр базы данных dbo use only должен быть установлен в FALSE. Доступ к серверу в режиме чтения будет возможен только в промежутках между восстановлением резервных копий баз и журналов. При использовании оператора STANDBY создаётся файл отмены с расширением ldf, аналог журнала транзакций. В нём хранятся изменения, отменяемые при восстановлении следующих копий журнала. Если файл отмены не существует, он будет создан автоматически. В аргументе оператора STANDBY можно задавать один и тот же файл. Тогда сервер будет перезаписывать содержимое этого файла, при условии, что в существующем нет информации для отмены изменений в базе данных. Размер файла отмены изменяется автоматически и ограничен только объёмом свободного дискового пространства. Ещё одним замечательным свойством оператора STANDBY является то, что с его помощью можно определить момент возникновения сбоя, приведшего к повреждению базы или согласованности данных. Поскольку восстановление резервных копий с этим параметром делает базу данных доступной для доступа, можно запускать диагностические утилиты или запросы, с помощью которых определять наличие недопустимых данных. Процедура поиска момента сбоя сводится к следующему: Вы восстанавливаете резервную копию базы и начинаете поочерёдно восстанавливать копии журнала транзакций. После восстановления каждой копии журнала выполняется утилита DBCC или запускается скрипт, проверяющий корректность данных. На каком - то этапе Вы зафиксируете с помощью используемых диагностических средств наличие сбоя. После этого, Вы будете точно знать, что Вам нужно восстановить из резервных копий (а именно, набор копий базы и журнала) до того момента, когда произошёл сбой. Восстановив не содержащие деструктивные или не правильные действия копии, Вы сможете привести Вашу базу данных к тому состоянию, которое было до момента сбоя.

Рассмотрим пример использования оператора STANDBY для резервного сервера базы Northwind. Нам необходимо обеспечить доступ пользователей для чтения базы данных на резервном сервере. Имена файлов базы на обоих серверах одинаковы:

USE master
RESTORE DATABASE Northwind FROM NorthwindBackupDevice
WITH STANDBY = ‘E:\ NorthwindUNDO.ldf’

RESTORE LOG Northwind FROM NorthwindLogBackupDevice
WITH STANDBY = ‘E:\NorthwindUNDO.ldf’

Выполнение резервных копий основного сервера должно выполняться на регулярной основе и с той периодичностью, которая необходима для поддержания актуальности данных резервного сервера. После каждого копирования журнала транзакций эта копия должна восстанавливаться на резервный сервер. Использование параметра NORECOVERY позволяет сделать резервный сервер недоступным пользователям до момента замены им основного, когда будет выполнена регенерация баз данных.

Поддержание базы данных резервного сервера в актуальном состояние для меня представляется в виде следующей процедуры: Вначале, определив стратегию резервного копирования, Вы заводите расписание заданий на создание необходимых полных/разностных резервных копий и копий журнала транзакций. Запросы, содержащиеся в расписании заданий, можно дополнить заданием на восстановление только что резервированной базы или журнала на резервном сервер. Для передачи задания резервному серверу на восстановление только что сделанной копии можно использовать системные хранимые процедуры, обслуживающие MS Mail, описание которых было изложено в 18-м выпуске рассылки.

Для того, что бы заменить основной сервер резервным, необходимо кроме уже имеющихся резервных копий выполнить копирование журнала с параметров NO_TRUNCATE. После этого можно отключать основной сервер, переименовать резервный и восстановить на нём последние копии. Самую последнюю копию восстанавливают с параметром RECOVERY. С этого момента сервер готов к работе. Обратный процесс требует несколько больше времени. Вы должны сделать полную копию на резервном сервере и копию журнала, а потом отключить его. Эти копии восстанавливаются на основном сервере, после чего он активизируется. Далее, на основном сервере опять выполняется резервное копирование, копии восстанавливаются на резервный сервер, так, как это было описано выше.

Восстановление системных баз данных

Необходимость восстановления системных баз данных может быть вызвана их повреждением или повреждением носителей, где они располагаются. Существует два пути их восстановления, это восстановление с актуальной резервной копии (если сервер удаётся запустить) или перестройка этих баз с помощью запуска из командной строки утилиты rebuildm.exe, находящейся в каталоге BINN. Перестроенные базы будут записаны поверх существующих. Если сохранились их копии, то, после перестройки, можно восстановить копии системных баз данных (в случае, если сервер не запускался). Если у вас нет резервной копии базы данных master, необходимо заполнить её вручную, используя MS SQL SEM или, если таковые имеются, исходные сценарии заведения пользователей, создания файлов баз и журналов, устройств резервирования, а также учётных записей подключения и глобальных серверных ролей. После восстановления master Вы можете приступить к восстановлению базы msdb. Если вы использовали вариант с перестройкой системных баз, содержимое базы msdb будет утеряно и Вам потребуется (ели нет резервной копии) восстанавливать все расписания вручную.

Если Вам удалось восстановить базу master, то для обеспечения доступа к пользовательским базам больше ничего не требуется. Если master была восстановлена путём её перестройки, Вы можете подключить к ней пользовательские базы путём восстановления из резервной копии или присоединения с помощью системных хранимых процедур sp_attach_db и sp_attach_single_file_db. Этот вариант хорош тем, что не требует наличия резервных копий баз данных и не нужно тратить время на их восстановление. Вот пример присоединения к базе master базы Northwind

USE master
EXEC sp_attach_single_file_db @dbname = ‘Northwind’,
@physname = ‘E:\Northwind.mdf’

Вопросы для повторения

ВОПРОС
Что такое процесс автоматической регенерации и когда он запускается?
ОТВЕТ
Автоматическая регенерация выполняется при каждом повторном пуске сервера SQL Server. В ходе этого процесса происходит откат или завершение транзакций в целях сохранения целостности базы данных после сбоя системы.
ВОПРОС
Какие действия необходимо предпринять перед восстановлением базы данных?
ОТВЕТ
Разрешите доступ к базе данных только ее владельцу (параметр «dbo use only»). Затем сделайте резервную копию журнала транзакций с тем, чтобы применить ее после завершения операции восстановления.
ВОПРОС
У вас есть полная резервная копия базы данных и несколько резервных копий журнала транзакций. База данных размещена в четырех файлах. Диск, на котором находится третий файл, дает сбой. Что следует сделать для восстановления и регенерации базы данных?
ОТВЕТ
Разрешите доступ к базе данных только ее владельцу (параметр «dbo use only»). Сделайте резервную копию журнала транзакций с тем, чтобы применить ее после завершения операции восстановления. Замените или отремонтируйте диск. Восстановите третий файл базы данных, используя в качестве источника полную резервную копию. Восстановите все резервные копии журнала транзакций, задав параметр NORECOVERY. Восстановите последнюю резервную копию журнала транзакций с параметром RECOVERY.
ВОПРОС
У вас есть полная резервная копия базы данных и несколько резервных копий журнала транзакций. В 9:21 произошло недопустимое обновление базы данных. Сейчас 9:30. Что следует сделать для восстановления базы данных и приведения ее в согласованное состояние?
ОТВЕТ
Разрешите доступ к базе данных только ее владельцу (параметр «dbo use only»). Восстановите базу данных, задав параметр NORECOVERY. Примените все копии журнала транзакций, кроме последней, с параметром NORECOVERY. Примените последнюю копию журнала транзакций, задав параметры RECOVERY и STOPAT = 'месяц, число, год, время', где указано время 9:20.
ВОПРОС
В ситуации, описанной в вопросе 4, будут ли при восстановлении потеряны какие-либо изменения?
ОТВЕТ
Если между 9:20 и 9:30 были выполнены какие-либо действия, эти изменения будут утрачены.
ВОПРОС
Вы установили резервный сервер SQL Server, используемый только для чтения. Чтобы необходимо сделать для того, чтобы этот резервный сервер мог заменить основной сервер?
ОТВЕТ
Если удастся, выполните резервное копирование журнала транзакций основного сервера без усечения журнала. Отключите основной сервер и замените имя резервного сервера SQL Server на имя основного сервера. Восстановите все имеющиеся журналы транзакций на резервный сервер SQL Server и затем проведите регенерацию базы данных.