Умение выполнять аварийное восстановление базы данных SQL Server — одно из самых важных в работе системного администратора (Sa). Но нередко получается так, что, по сравнению с текущими производственными задачами, процедуре восстановления и выполнению резервного копирования уделяется меньше внимания. Большинство компетентных администраторов знают, что создавать резервные копии жизненно важных данных компании необходимо регулярно. А поскольку ничего сложного в создании резервных копий нет, эта задача чаще всего поручается новичкам. Если процедура резервного копирования отлажена, в этом нет ничего особенного.
Однако поручать недостаточно опытным администраторам заниматься восстановлением данных, пожалуй, не стоит. Поскольку восстановление базы данных производится не каждый день, администратор SQL Server может обслуживать систему годами, прежде чем однажды возникнет необходимость выполнить аварийное восстановление. День, когда потребуется это сделать, может принести множество сюрпризов — в процедуре восстановления немало тонкостей. Внезапные затруднения могут заставить администратора в поисках решения проблемы обратиться к SQL Server Books Online (BOL) и Microsoft Knowledge Base, а тем временем вся компания будет простаивать, ожидая, когда же наконец корпоративные данные станут доступными. Помимо необходимости предвидеть всякого рода неожиданности, нужно протестировать собственно план восстановительных работ. Если процедура восстановления по аварийному сценарию развития событий еще не протестирована, следует сделать это как можно скорее.
В настоящей статье рассматриваются различные типы резервирования, включая Full, Differential и Transaction Log Backup. Затем я расскажу об основных операциях восстановления данных и функционировании SQL Server во время проведения процедуры восстановления. В следующих статьях на эту тему речь пойдет о процессе переноса базы данных на новое место, где может оказаться свое множество пользователей, отличное от исходного. Кроме того, будут описаны специфические проблемы, с которыми может столкнуться администратор SQL Server при восстановлении не отдельно взятой базы данных, а всей системы целиком.
Резервирование и восстановление
Несмотря на то что процесс создания резервной копии обычно не вызывает особых затруднений, необходимо ясно себе представлять, что происходит при использовании того или иного способа резервирования. Это пригодится при планировании процедуры восстановления. Когда выполняется резервирование, копии данных и/или журнала транзакций переносятся в другое, предположительно надежное место. Таким местом может быть файл на локальном диске (который затем копируется на ленту или другой носитель) или лента. Хотя ничто не мешает напрямую скопировать данные в удаленный файл на диске, лучше записать их в локальный файл и затем использовать средства копирования операционной системы для переноса файла на другую машину. Насколько быстро и полно будет выполнено восстановление данных из резервной копии, зависит от типа резервирования и от того, насколько тщательно разработан план мероприятий аварийного восстановления. Например, нужно заранее обеспечить достаточный объем дискового пространства, об этом подробно рассказано во врезке «Планирование места для восстановления базы». SQL Server 2000 поддерживает три основных типа резервирования: Full, Differential и Log.Full Backup. При полном резервировании базы данных все страницы базы копируются на устройство резервирования, которым может быть локальный или сетевой файл, локальное ленточное устройство или именованный канал (named pipe). SQL Server также копирует ту часть журнала транзакций, которая на момент проведения резервирования была в активном состоянии.
Differential Backup. Разностное резервирование означает копирование только тех экстентов, которые были изменены со времени выполнения последнего полного резервирования. SQL Server 2000 позволяет быстро установить, какие экстенты нуждаются в резервировании. Для этого в каждом файле базы данных проверяется специальная страница под названием Differential Changed Map (DCM). Для каждого экстента в DCM имеется свой бит-флаг. Каждый раз, когда выполняется Full Backup, значение бита устанавливается в 0. При изменении любой страницы экстента соответствующий бит на странице DCM устанавливается равным 1. SQL Server копирует порцию журнала транзакций, которая была активной во время резервирования. Обычно между несколькими запусками Full Backup используется несколько сеансов Differential Backup, и в каждом Differential Backup собирает все изменения со времени последнего Full Backup.
Log Backup. Процедура резервирования журнала транзакций копирует все записи журнала, появившиеся с момента проведения последнего резервирования типа Log Backup. Даже если выполняется Full Backup, копия журнала транзакций содержит все записи (в соответствии с указанным алгоритмом) со времени выполнения последнего резервирования журнала. Таким образом, можно восстановить базу из любого набора Full Backup при условии, что имеется хронологическая последовательность копий журнала транзакций. Однако точное «поведение» команды BACKUP LOG зависит от установок модели восстановления базы данных. Если это Full Recovery Model, то команда BACKUP LOG скопирует все содержимое журнала транзакций. Если это Bulk_Logged Recovery Model, процедура Log Backup копирует содержимое всего журнала и все страничные экстенты, модифицированные массовыми операциями (bulk operation) со времени последнего Log Backup. Если в базе данных используется Simple Recovery Model, выполнить резервирование журнала транзакций невозможно, поскольку журнал регулярно очищается, и полезных данных для процедуры резервирования в нем нет. В типичном сценарии восстановления администратор организует серию сеансов Log Backup между двумя сеансами Full Backup, при этом каждый Log Backup собирает только те записи журнала транзакций, которые появились с последнего по времени резервирования типа Log Backup.
SQL Server поддерживает различные комбинации этих базовых типов резервного копирования, что особенно удобно в условиях, когда в организации используются очень большие базы данных — Very Large Databases (VLDB). Дополнительные сведения о резервировании и восстановлении файлов и файловых групп приведены во врезке «Создание резервных копий и восстановление файлов и файловых групп». Чем больше типов резервирования используется и чем чаще запускается резервное копирование, тем больше шансов быстро и в полном объеме восстановить базу данных. Однако при восстановлении данных от сервера SQL требуется больше усилий, чем при организации резервирования. Когда выполняется полное восстановление, SQL Server должен гарантировать, что данные базы согласуются с записями в журнале транзакций. Процедура верификации согласованности данных базы и журнала транзакций называется Database Recovery.
Restore или Recovery?
Значения терминов Database Recovery и Database Restore схожи между собой, однако это не одно и то же. Полное восстановление (Restore) данных почти всегда означает и проведение операций возврата в исходное состояние (recovery operation), но возврат в это состояние не означает необходимость организовать восстановление данных. Restore — это процесс загрузки данных из резервной копии вручную, он инициируется администратором системы. Recovery — это автоматическая процедура, которая может быть запущена в самом конце процесса восстановления (Restore) и вызывается каждый раз при перезапуске SQL Server. Хотя обычно Recovery — составная часть Restore, администратор может контролировать этот процесс, как — будет рассказано ниже. Дополнительная информация об особенностях Recovery в SQL Server 2000 и 7.0 содержится во врезке «Сравнение процесса Recovery в SQL Server 2000 и 7.0».В процессе Database Recovery (в конце процедуры восстановления базы или после перезапуска SQL Server) SQL Server сравнивает записи журнала транзакций с данными в базе. Процесс Recovery выполняет операции повторения транзакций (redo — roll-forward) и, если нужно, отменяет их (undo — rollback). При выполнении операций Redo SQL Server просматривает журнал транзакций и следит за тем, чтобы все изменения уже присутствовали в базе данных. Если выполненная транзакция записана в журнал, но отсутствует на страницах базы, SQL Server повторно совершает эту транзакцию, после чего можно быть уверенным, что каждое изменение, совершенное транзакцией, внесено в базу. Если часть транзакции появилась в базе, но полностью она так и не была завершена, SQL Server выполняет операцию Undo для удаления из базы связанных с незавершенной транзакцией изменений. После окончания процесса Recovery можно говорить о синхронизации базы данных и журнала транзакций. Все завершенные транзакции, записанные в журнал, отражены в базе, и ни одна незавершенная транзакция не появилась в базе данных.
Восстановление разрушенной базы данных
Если после сбоя физического носителя или из-за ошибки, приведшей к разрушению либо искажению данных, необходимо выполнить восстановление данных. Это можно проделать на исходном сервере SQL Server, запустив процедуру восстановления на основе самой последней копии Full Backup. Если разрушен носитель, нужно восстанавливать базу на новом диске. По умолчанию SQL Server при восстановлении создает базу данных, если ее еще нет, и располагает файлы данных и файлы журнала транзакций так же, как и раньше. Чтобы проверить адреса файлов, необходимо запустить для резервной копии (хранящейся на диске или на ленте) следующую команду:RESTORE FILELISTONLY FROM
Чтобы на том же самом сервере SQL Server, но в другом месте создать восстановленную базу данных, следует использовать команду RESTORE DATABASE с параметром MOVE (в BOL приводится исчерпывающий синтаксис для MOVE). Если физический носитель в порядке и администратор только устраняет последствия ошибки пользователя, возможно, есть смысл восстановить резервную копию базы на прежнем месте — поверх существующей базы данных.
Нужно иметь в виду, что во время восстановления базы ни один пользователь не должен быть к ней подключен. В SQL Server 2000 для перевода базы в статус Single-User Mode и отключения пользователей от базы используется команда ALTER DATABASE (BOL содержит полное описание ALTER DATABASE). Для SQL Server 7.0 не существует способа автоматически отключить пользователей от базы. Администратор может запустить сценарий, в котором будет проверяться таблица Sysprocesses, где перечислены подключенные пользователи, и выдаваться команда KILL для каждого из них. Затем предпринимается попытка перевести базу в состояние Single-User Mode. Однако таким способом не удается удержать пользователей от возможности повторной регистрации в базе данных. Для этого можно попробовать воспользоваться менеджером служб операционной системы и приостановить работу SQL Server (состояние pause), однако пауза в большей степени отразится на работе всех баз данных, а не только на той, которую требуется восстановить. Кроме того, нужно помнить, что при работе с Enterprise Manager — для инспекции состояния баз данных или для работы с подключенными пользователями — в режиме Single-User Mode невозможно одновременно задействовать Query Analyzer для подключения к базе данных.
Восстановление и переименование базы
Если нужно восстановить базу данных и присвоить ей новое имя (возможно, из-за того, что желательно иметь идентичную копию этой базы на том же сервере), администратору может потребоваться команда RESTORE DATABASE с параметром REPLACE. Этот параметр необходим тогда, когда имя базы в файлах резервной копии не соответствует имени базы, указанной в команде RESTORE, существующей на SQL Server. Параметр REPLACE помогает защититься от непреднамеренной перезаписи базы содержимым резервной копии другой базы. Например, если имеется файл резервной копии базы Northwind и администратор пытается восстановить копию в базу данных Pubs, SQL Server не позволит этого сделать без параметра REPLACE. Но уж если REPLACE указана, оригинальная база Pubs будет перезаписана содержимым резервной копии Northwind.Ввести REPLACE также следует при применении параметра MOVE и указании существующего файла. MOVE дает возможность использовать команду RESTORE для воссоздания базы данных на новом месте, возможно, на более быстром физическом диске. Вместе с тем, если файл указан как целевой в параметре MOVE, но он уже имеется в системе, SQL Server «полагает», что существующий файл принадлежит какой-то другой базе данных. Обычно RESTORE DATABASE не позволяет перезаписывать существующие файлы, но параметр REPLACE в команде RESTORE DATABASE дает возможность это сделать. Следует знать об одной тонкости в работе REPLACE: как правило, пользователю, запустившему команду RESTORE DATABASE, вполне достаточно быть просто владельцем (DBO) базы данных. Но когда используется REPLACE, SQL Server считает, что пользователь создает новую базу данных. Пользователь, который вместе с RESTORE DATABASE указывает REPLACE, должен иметь право создавать базу данных или же входить в состав группы, имеющей такие разрешения. В следующий раз мы обсудим приемы, с помощью которых пользователь, не имеющий административных полномочий DBO, может тем не менее восстановить данные с использованием параметра REPLACE.
Восстановление с WITH RECOVERY и WITH NORECOVERY
Команда RESTORE DATABASE выполняет две функции: копирует все данные, журнал транзакций и индексные страницы из резервной копии в файлы базы данных и повторяет все транзакции из резервной копии журнала. Нужно определиться, следует ли сообщать серверу SQL о необходимости отменить все незавершенные транзакции. Если требуется Rollback, можно воспользоваться параметром WITH RECOVERY в команде RESTORE DATABASE для запуска процедуры Recovery. Параметр WITH RECOVERY выполняет незавершенные транзакции в обратной последовательности, после чего база открывается для использования. Если планируется восстановить несколько журналов транзакций, не следует задействовать процедуру Recovery и отмену транзакций до тех пор, пока не будет восстановлена последняя резервная копия журнала транзакций, и, следовательно, не нужно использовать параметр WITH RECOVERY. Команда RESTORE LOG также позволяет указать параметр WITH RECOVERY или WITH NORECOVERY.Напомню, что в версиях SQL Server 2000 и 7.0 резервные копии журналов транзакций не перекрываются — очередной Log Backup начинается с того места, на котором закончился предыдущий. Рассмотрим транзакцию, которая вносит сотни изменений в одну таблицу. Если создать резервную копию журнала в процессе такого обновления и еще раз после завершения транзакции, то в первом случае Log Backup будет содержать самое начало транзакции и некоторые обновления, а во втором — копия журнала будет включать оставшиеся изменения и завершение транзакции. Предположим, что нужно восстановить эти журнальные копии после восстановления всей базы. Если запустить восстановление копии первого журнала с параметром WITH RECOVERY, SQL Server отменит незавершенную транзакцию в первой части журнала. Если после этого попытаться восстановить копию второго журнала, то процедура восстановления начнется где-то посредине транзакции, и SQL Server не будет знать, где ее начало. Восстановить транзакции, произошедшие после внесения очень большого числа изменений, не удастся, так как может оказаться, что все последующие операции напрямую зависели от ранее внесенных изменений, а они были утеряны. Как результат — SQL Server не позволит процедуре восстановления выполняться далее. В данном случае можно запустить восстановление с параметром WITH NORECOVERY, который оставит описываемую транзакцию незавершенной. SQL Server будет знать, что состояние базы данных противоречивое (inconsistent) и не позволит ни одному пользователю подключиться к ней до тех пор, пока администратор не запустит процедуру Recovery.
Итак, когда же следует выбирать WITH RECOVERY и когда — WITH NORECOVERY? Если используется команда RESTORE для восстановления базы данных или журнала транзакций, то параметр по умолчанию — WITH RECOVERY. Но в основном пользоваться следует параметром WITH NORECOVERY во всех случаях восстановления журнала, кроме самого последнего. Если администратор допустил ошибку и забыл указать WITH NORECOVERY, придется снова запустить процедуру восстановления, поскольку база данных окажется восстановленной, а незавершенные транзакции будут отсутствовать. Однако если администратор забудет указать WITH RECOVERY для самого последнего восстанавливаемого журнала транзакций, то исправить ошибку очень легко. Нужно просто воспользоваться командой, приведенной ниже, для запуска процедуры восстановления без указания устройства, с которого будет происходить восстановление:
RESTORE DATABASE WITH RECOVERY
Незавершенное восстановление
Незавершенное восстановление бывает полезно выполнить в том случае, когда произошло случайное разрушение важных данных с использованием команд UPDATE или DELETE. Нужно просто восстановить базу данных на момент, непосредственно предшествующий разрушению. Если следовать правилам обычной процедуры восстановления и полностью повторить самый последний журнал транзакций, то снова произойдет повторное исполнение транзакций, разрушивших базу. Но SQL Server 2000 и 7.0 позволяют восстановить базу данных на тот момент времени, который указал администратор.Параметр STOPAT в команде RESTORE дает возможность указать момент времени, в который нужно прервать восстановление журнала транзакций. Поскольку каждая запись журнала содержит значение даты и времени — Datetime — начала транзакции, SQL Server прекратит восстанавливать транзакции, как только встретит транзакцию, которая началась после указаного в параметре STOPAT времени. Если резервная копия журнала транзакций не содержит записей, удовлетворяющих указанному времени (т. е. администратор указал время, которое наступило после начала выполнения транзакций), SQL Server генерирует предупреждение, и база данных остается в состоянии, как если бы администратор воспользовался командой RESTORE WITH NORECOVERY.
В версии SQL Server 7.0 можно задействовать параметр STOPAT только в команде RESTORE LOG. Для версии SQL Server 2000 этот параметр дополнительно может быть задан для команды RESTORE DATABASE. Действие STOPAT охватывает набор записей журнала, выполненных после того, как все страницы базы данных были загружены. Однако нельзя использовать параметр STOPAT при работе с Differential Backup, поскольку основная работа при восстановлении дифференциальной копии состоит в замещении измененных данных, и не существует значения Datetime, связанного с измененными страницами. Кроме того, нельзя применять STOPAT при восстановлении отдельного файла или файловой группы, так как в этом случае записи всех журналов должны быть полностью обработаны, а восстановленный файл или файловая группа — соответствовать текущему состоянию всех остальных файлов базы данных на определенный момент времени.
Восстановление с WITH STANDBY
Но как ни полезен STOPAT, и он не решает всех проблем. Как быть, если администратор знает, что данные разрушены, но когда это случилось — точно неизвестно? Например, в 17 ч обнаружено, что критически важные данные из базы пропали, точно известно, что произошло это в течение дня, но когда именно? Ведь хотелось бы восстановить базу как можно ближе к тому моменту, когда данные были уничтожены.Как отмечалось ранее, обычный сценарий восстановления подразумевает, что существует возможность выбрать WITH RECOVERY для отмены незавершенных транзакций или же указать WITH NORECOVERY. Если используется WITH RECOVERY, то восстановить цепочку журналов транзакций не удастся, но зато сама база полностью готова к работе. Если выбрать WITH NORECOVERY, база может оказаться противоречивой, и тогда SQL Server не позволит работать с ней.
А что если попробовать скомбинировать эти два подхода — сначала восстановить копию одного журнала транзакций и проанализировать данные, прежде чем переходить к восстановлению копии следующего журнала? Такой подход особенно удобен, когда требуется провести восстановление базы на определенный момент времени, но заранее неизвестно — какой.
SQL Server располагает параметром STANDBY, с помощью которого можно запустить процедуру Recovery и продолжать восстанавливать содержимое базы, используя цепочку резервных копий журналов транзакций. Если администратор восстанавливает журнал транзакций и при этом указывает
WITH STANDBY = ??
SQL Server отменит незавершенные транзакции, но сохранит записи отмененной работы в специальном файле, который называется Undo File. По умолчанию расширение этого файла — .ldf, так как его структура в точности соответствует структуре файла транзакций, для которого также используется расширение .ldf.
Следующая операция RESTORE LOG читает содержимое Undo File, повторно исполняет отмененные операции и затем восстанавливает журнал транзакций, указанный в команде RESTORE LOG. Если эта команда RESTORE LOG также указана с параметром WITH STANDBY, то процедура восстановления вновь отменяет незавершенные транзакции, но сохраняет запись об отмененных транзакциях. После каждой такой операции RESTORE LOG ... WITH STANDBY данные являются согласованными, поскольку в базу данных не включаются частично завершенные транзакции, и поэтому пользователи имеют доступ к базе и могут читать ее содержимое. Итак, администратор после восстановления каждого журнала имеет возможность установить, произошло ли искомое изменение к указанному моменту времени. При этом нужно иметь в виду, что невозможно изменить какие бы то ни было данные, если восстановление выполнено с использованием параметра WITH STANDBY — SQL Server выдаст сообщение об ошибке, если пользователь попытается это сделать. Самый последний журнал транзакций восстанавливается с указанием WITH RECOVERY (а SQL Server не записывает Undo File) и обеспечивает готовность базы данных к работе.
Параметр RESTORE WITH STANDBY может быть использован для установления того момента времени, когда данные в базе были испорчены, но результат поиска оказывается неточным. После того как журнал восстановлен и обнаружено, что нежелательные действия имели место, можно попробовать еще больше сузить интервал времени, в течение которого они были выполнены. Нужно перейти к самому началу процесса восстановления и воспользоваться параметром STOPAT для остановки в определенное время внутри временного диапазона записей журнала транзакций. Если выяснится, что данные пока еще не искажены, очевидно, что разрушения произошли позднее; если же искажения налицо, ясно, что нежелательные операции выполнялись ранее заданного в STOPAT времени. Повторяя описанный поиск, время нежелательных действий можно установить с максимально возможной точностью при минимальной потере данных.
В качестве альтернативы можно воспользоваться продуктом Lumigent Technologies Log Explorer 2.5, с помощью которого администратор системы просмотрит время начала и содержимое каждой транзакции журнала. Можно использовать информацию из поля транзакции Datetime, чтобы установить нужное время в параметре STOPAT, или Log Explorer для отмены транзакции. Но необходимо соблюдать осторожность, используя Log Explorer для отмены изменений, ведь другие изменения могут зависеть от тех, которые администратор пытается отменить. Если это возможно, следует использовать Log Explorer только в качестве источника информации, а для реального возврата базы данных в определенное состояние задействовать функции SQL Server.
Частичное восстановление
SQL Server 2000 позволяет выполнить частичное восстановление базы данных. Описание и синтаксис процедуры частичного восстановления напоминают процедуру восстановления файла и файловой группы, но на самом деле эти процедуры совершенно разные. Для восстановления из резервных копий файла или файловой группы необходимо запустить целиком всю базу данных и заменить один или несколько файлов или файловых групп ранее сохраненными версиями. Дополнительная информация о создании и восстановлении резервных копий файлов и файловых групп приведена в одноименной врезке. Для частичного восстановления базы данных нет необходимости начинать с запуска всей базы данных. Восстановлению подлежат отдельные файловые группы (включая главную файловую группу — Primary Filegroup, в которой содержатся все системные таблицы). Любые не восстановленные файловые группы считаются более не существующими, и SQL Server при попытке ссылаться на хранящиеся в них данные обозначает их как группы в отключенном состоянии (offline).После завершения частичного восстановления можно восстановить журналы транзакций или данные Differential Backup для приведения базы данных в восстановленных файловых группах в более позднее по времени состояние. Частичное восстановление дает возможность извлечь данные из подмножества таблиц после случайного удаления или модификации содержащихся в них данных. Можно воспользоваться частично восстановленной базой данных для извлечения данных из утерянных таблиц, а затем скопировать данные обратно в исходную базу.
Для восстановления базы данных можно выбрать один из множества способов, при этом необходимо держать в голове огромное количество деталей. Если операции по восстановлению завершаются успешно, может показаться, что все очень просто. Однако если предстоит сделать что-то необычное, нетрадиционное или же процесс восстановления не работает так, как ожидается, то понимание проистекающих в SQL Server процессов поможет подготовить сценарий работы для любой, самой нетривиальной задачи. Рекомендую сегодня же начать разработку пошагового плана восстановления, не откладывая эту задачу «на потом», и протестировать запланированные мероприятия.
Планирование места для восстановления базы
Каждая страница в базе данных имеет номер файла (File Number) и номер страницы (Page Number), идентификаторы, с помощью которых страница адресуется. Когда происходит восстановление базы данных, каждая страница содержит свои исходные номера файла и страницы. Следовательно, необходимо заменить в восстановленной базе данных все номера файлов на исходные. Если исходная база данных содержит пять файлов данных, то новая база также должна состоять из пяти файлов. Если исходная база использует только два файла — один главный файл данных и 48 Гбайт в дополнительном файле, например, — необходимо использовать два файла данных для восстановления, и один из них по размеру должен быть не меньше 48 Гбайт.
Когда определяется, сколько файлов следует использовать для исходной базы, нужно помнить, что проще восстановить данные в меньшее число физических файлов, чем на исходном сервере, нежели восстанавливать базу в большее число файлов, поскольку можно разместить несколько логических файлов в одном физическом, но разместить один логический файл в нескольких физических нельзя. Если исходная база данных представляет собой единый файл, размер которого 48 Гбайт, его невозможно восстановить в большее число файлов. Однако если исходная база данных занимает шесть файлов по 8 Гбайт, то восстановление можно выполнить в шесть файлов на диске, емкость которого не менее 48 Гбайт, или же на двух дисках по 24 Гбайт, на каждом из которых разместятся три файла, или на трех 16 Гбайт дисках по два файла на каждом.
Создание резервных копий и восстановление файлов и файловых групп
Версии SQL Server 2000 и 7.0 позволяют создать резервную копию и восстановить индивидуальные файлы или файловые группы. Эта функция особенно полезна при работе с базами данных очень большого размера — VLDB. Можно создавать резервную копию одного файла или одной группы ежедневно, нет необходимости резервировать каждый раз всю базу целиком. Возможность в любой момент восстановить отдельные файлы или группы файлов может быть полезна, когда на изолированном резервном носителе обнаруживается сбой — скажем, на одном физическом диске, из-за чего восстановление всей базы данных займет слишком много времени. Имея SQL Server 2000, администратор просто организует задание на резервирование типа Differential Backup для отдельных файлов или групп. При резервировании и последующем восстановлении файлов или групп нужно иметь в виду следующее.- Отдельные файлы или файловые группы можно резервировать только тогда, когда для базы данных установлена модель Full- или Bulk_Logged Recovery Model, так как обязательно нужно повторять транзакции после восстановления собственно файлов или файловых групп; повторить транзакции в режиме Simple Model не удастся.
- В отличие от Full Backup и Differential Backup, создание резервной копии файла или группы не сопровождается резервированием какой бы то ни было порции журнала транзакций. Поэтому в восстановленных файлах или файловых группах данные журнала транзакций отсутствуют, журнал придется восстанавливать отдельно.
- Из полной резервной копии (Full Backup) можно восстановить отдельный файл или файловую группу.
- Непосредственно перед восстановлением отдельного файла или файловой группы необходимо создать резервную копию журнала транзакций. У вас должна быть неразорванная цепочка копий журнала транзакций, начиная с момента создания копий файла или файловой группы до того момента, когда файл или группа будут восстановлены.
- После восстановления файла или файловой группы необходимо восстановить все журналы транзакций в период между созданием резервной копии файла или файловой группы и временем их восстановления. Восстановление промежуточных журналов транзакций гарантирует, что восстановленные файлы синхронизируются с оставшейся в базе данных информацией.
Сравнение процесса Recovery SQL Server 2000 и 7.0
Если возникла необходимость в восстановлении базы данных из-за ошибки на диске, что привело к невозможности продолжать работу с базой, вероятно, потребуется восстановить как можно больше транзакций, совершенных непосредственно перед сбоем. SQL Server Books Online (BOL) сообщает, что, если журнал транзакций остается доступным на момент сбоя (т. е. база и журнал транзакций расположены на разных дисках), его резервирование следует продолжить в штатном режиме. Однако для версии SQL Server 7.0 требуется, чтобы главный файл данных (Primary Data File) при этом также был бы доступен. В этом файле содержится указание на местонахождение журнала транзакций, поэтому, если главный файл расположен на испорченном диске, он становится недоступным для резервирования. В SQL Server 2000 разработчики Microsoft данную проблему устранили. Информация о физическом местонахождении файла транзакций теперь дополнительно хранится в мастер-базе; поэтому, даже если главный файл недоступен, администратор в состоянии создать резервную копию журнала, и в ней будет информация о транзакциях непосредственно перед моментом сбоя в базе данных. Эта резервная копия журнала транзакций — самая последняя резервная копия, которую при восстановлении базы данных администратор будет использовать для возврата базы данных в состояние непосредственно перед сбоем.Кэлен Дилани - независимый консультант и инструктор по SQL Server. Имеет сертификаты MCT и MCSE. С ней можно связаться по адресу: kalen@sqlmag.com.