Файл: Причины повреждений баз данных.pdf

Failure (сбой) обычно значит сбой в работе базы данных, к примеру, появились ошибки на диске, на котором была размещена база данных. Операционная система и программные файлы сервера при всем этом остались в рабочем состоянии, и для вас необходимо произвести восстановление только базы данных.^[3]

Disaster (трагедия) значит трагический отказ сервера, к примеру, из-за скачка напряжения, пожара, затопления и т. п. При восстановлении в случае такового чертовского отказа для вас придется сначала установить операционную систему и программное обеспечение SQL Server, а позже уже создавать восстановление рабочих баз данных.^[4]

Общий план восстановления обычно смотрится последующим образом:

1. Сначала делается процедура restore - нужная информация восстанавливается с носителя. Вы сможете вернуть только полную запасную копию, а уже после чего произвести восстановление разностной запасной копии и запасных копий журналов транзакций. Официальное заглавие этого шага - фаза копирования данных (data copy phase).

2. Если делается также восстановление журналов транзакций, то последующим действием SQL Server записывает в базу данных всю информацию о завершенных транзакциях из журнальчика транзакций. Данная операция называется roll forward (окончание). Сам шаг называется фазой повтора (redo phase), а оба первых шага совместно - шаг окончания (roll forward step).

3. Исключительно в редакции SQL Server 2014 Enterprise Edition юзерам раскрывается доступ к базе данных. Открытие доступа на этом шаге - это новенькая возможность SQL Server 2014. Она имеет свое заглавие - fast recovery (резвое восстановление). Если же юзер попробует обратиться к данным, модифицированным незавершенными транзакциями, то доступ ему будет закрыт за счёт механизма блокировок.

4. Потом SQL Server обнаруживает в журнальчике все незавершенные транзакции и отменяет их. Данная операция называется rollback - откат транзакций, а сам шаг называется шагом отката (rollback phase).

5. После чего к базе данных раскрывается доступ в обыкновенном режиме во всех версиях SQL Server.

Отметим еще несколько моментов, связанных с процессом восстановления SQL Server 2014:

· для восстановления вы сможете использовать не только лишь запасные копии, которые были сделаны в версии SQL Server 2014, да и те, которые были сделаны на версиях 7.0 и 2000. Обновление до версии 2014 произойдет автоматом. Естественно, такую возможность следует рассматривать как очередной вариант обновления баз данных;

· создатели SQL Server 2014 интенсивно рекламируют новейшую возможность - восстановление на открытой базе данных. По сути такое восстановление можно создавать только тогда, когда в базе данных несколько файловых групп, и восстанавливаемая файловая группа находится в автономном режиме (offline). Потому по сути юзеры работать с восстанавливаемыми данными, естественно, не сумеют;

· в SQL Server 2014 восстановление полнотекстовых индексов делается совместно с базами данных;

· информация о восстановлении, как и информация о запасном копировании, записывается в служебные таблицы базы данных msdb. Употребляются таблицы restorehistory, restorefile и restorefilegroup.^[5]

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

Перед восстановлением будет необходимо произвести некие предварительные деяния.

1-ое, что необходимо сделать, - это запретить пользователям доступ к информационной базе, подлежащей возобновлению. Это возможно устроить разными способами:

· для основной массы баз данных очень установить для параметра Restrict Access (Ограничить доступ) характеристик информационной базы значение Restricted. В случае если пользователи вашей информационной базы имеют все шансы подключаться с правами dbo, то чтобы достичь желаемого результата параметра возможно установить значение Single;

· коль скоро на сервере наличествует лишь 1 рабочая информационная база, то гораздо лучше просто на время восстановления отключитьсетевой доступ к SQL Server. Для этого можно, к примкеру, на время восстановления отключить протокол TCP/IP в контейнере SQL Server 2014 Network Configuration в SQL Server Configuration Manager.^[6]

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

Может случиться так, что база данных повреждена так очень, что поменять её характеристики не удается. Она при всем этом может находиться в состоянии suspect (подозрительное) либо в автономном режиме offline (информацию о состоянии можно просмотреть, к примеру, из контейнера Datаbases в Management Studio). Если база данных находится в автономном режиме, то запустить её восстановление для вас не получится. В этой ситуации самый обычный выход - отсоединить (detach) покоробленную базу данных и произвести восстановление с запасной копии так, будто бы эта база данных отсутствует на сервере вообщем. Отметим, что для того, чтоб отсоединить базу данных, помеченную как подозрительная (suspect), её необходимо сначала перевести в состояние "критической необходимости" (emergency) - ALTER DATABASE db1 SET emergency.

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

Пример выполнения команды на просмотр инфы о запасной копии может смотреться так:

· RESTORE FILELISTONLY FROM backupdevice1;

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

2.3 Проведение восстановления

После того, как подготовка завершена, можно приступать к самому восстановлению. Запустить восстановление можно с помощью графического интерфейса Management Studio (контекстное меню Restore Database для контейнера Databases либо контекстное меню Tasks | Restore для контейнера базы данных) либо с помощью команды RESTORE. Как обычно, опишем способности, которые представляет графический интерфейс, и приведем информацию о тех параметрах команды RESTORE, которым они соответствуют.

Destination to restore ... To database (Предназначение восстановления ... в базу данных) - это, естественно, имя восстанавливаемой базы данных. Направьте внимание, что заместо выбора базы данных из перечня вы сможете ввести свое имя. В данном случае из запасной копии на сервере будет сотворена новенькая база данных. В неких случаях может быть комфортно вернуть копию имеющейся базы данных под другим именованием, а потом по мере надобности старенькую базу данных удалить, а восстановленную переименовать, присвоив ей старенькое заглавие.^[7]

Команда на восстановление базы данных в самом ординарном варианте может смотреться так:

RESTORE DATABASE db2 FROM DISK = "D:\SQLBackups\BackupFile1.bak"

При всем этом запасная копия полностью могла быть предназначена для базы данных db1, а не db2;

To a point of time (На момент времени) - позволяет задать восстановление на определенный момент времени. Обычно употребляется исключительно в ситуации, когда юзер сделал ошибку (к примеру, удалил принципиальные данные) и вы понимаете приблизительно, когда это вышло. Употребляется только при восстановлении журналов транзакций.

2. восстановление на номер последовательности в журнальчике транзакций (log sequence number, LSN). Номер LSN есть у каждой операции, которая зафиксирована в журнальчике транзакций. К огорчению, стандартными средствами просмотреть журнальчик транзакций и отыскать LSN для транзакции, с которой начались трудности, нереально. Для этой цели придется использовать утилиты третьих компаний, к примеру, Lumigent Log Explorer. После того, как номер LSN найден, можно использовать те же характеристики STOPATMARK и STOPBEFOREMARK, но синтаксис будет малость другим, к примеру:

RESTORE LOG db1 FROM DISK = "D:\SQLBackups\BackupFile1.bak" WITH STOPATMARK = "lsn:120";

From database (Из базы данных) - для обнаружения запасных копий будет употребляться история запасного копирования из таблиц базы данных msdb. В перечне можно избрать не только лишь текущую базу данных, да и другие базы данных, которые есть на этом сервере;

From device (Из устройства) - для вас будет необходимо указать местопребывание запасной копии очевидно. Данная возможность употребляется в тех ситуациях, когда для вас необходимо вернуть базу данных на другой сервер либо местопребывание запасной копии поменялось. В любом случае для вас будет необходимо избрать логическое устройство запасного копирования, картридж стриммера либо файл на диске. Еще одна возможность (доступная исключительно в Enterprise Edition и только при полном восстановлении базы данных) - использовать в качестве источника снимок базы данных (database snapshot);

Select the backup sets to restore (Избрать запасную копию для восстановления) - в этом перечне для вас будет необходимо установить флажки напротив тех запасных копий, которые вы планируете вернуть. Направьте внимание, что флажки можно поставить напротив нескольких запасных копий. В данном случае для каждой избранной запасной копии будет выполнена отдельная команда RESTORE.

С помощью этого же перечня можно получить огромное количество дополнительной инфы о восстанавливаемых запасных копиях (если прокрутить перечень на право): о времени запасного копирования, о размере запасной копии, о юзере, которые создавал это копирование, и т.п.

Дополнительные и очень принципиальные характеристики восстановления представлены на вкладке Options окна восстановления базы данных Management Studio:

Overwrite the existing database (Перезаписывать существующую базу данных) - установленный флаг позволяет перезаписать существующую базу данных. Практически он отменяет проверки, которые призваны не допустить утраты данных в случае неверного восстановления. Таких проверок предвидено три:

· запрещено восстанавливать запасную копию чужой базы данных на сервер, если под этим именованием на сервере есть своя база данных;

· запрещено перезаписывать файлы, которые относятся к базам данных, находящимся в автономном режиме (offline), и, не считая этого, вообщем любые файлы, которые не относятся к SQL Server;

· запрещено создавать восстановление базы данных, если на ней осталась часть журнальчика транзакций, запасное копирование которой еще не выполнялось (tail-log). Это новенькая проверка, которая появилась исключительно в SQL Server 2014.

Чтоб эти проверки отменить, необходимо установить обозначенный флаг либо использовать параметр WITH REPLACE в команде RESTORE;

Preserve the replication settings (Сохранить опции репликации) - сохранить опции репликации при восстановлении. Соответствует параметру KEEP_REPLICATION команды RESTORE. Обычно употребляется только тогда, когда база данных сразу участвует и в репликации, и в автоматической доставке журналов (log shipping).

Prompt before restoring each backup (Выводить приглашение перед каждым восстановлением) - выводить приглашение перед восстановлением каждой последующей запасной копии из избранного вами перечня. Обычно данный параметр употребляется только тогда, когда любая копия лежит на собственном картридже стриммера, и для вас необходимо их поменять.

Recovery state (Состояние восстановления) - очередной важный параметр, который определяет, будет ли база данных открыта для юзеров после окончания восстановления с носителя. В вашем распоряжении три варианта:

1. WITH RECOVERY - восстановление в обыкновенном режиме. После окончания восстановления начнется процедура RECOVERY, все незавершенные транзакции будут отменены, и в конечном итоге база данных будет открыта для юзеров. Данный параметр употребляется по дефлоту;

2. WITH NORECOVERY - после окончания процесса восстановления с носителя процедура RECOVERY не начнется. Базы данных остается в нерабочем состоянии восстановления. Данный параметр употребляется тогда, когда после восстановления запасной копии вы желаете вернуть дополнительные копии, к примеру, после восстановления полной запасной копии вернуть запасную копию журнальчика транзакций;

3. WITH STANDBY - процедура RECOVERY начнется, но вся информация о всех отмененных незавершенных транзакциях будет записана в файл отмены (его необходимо будет указать). В итоге юзеры сумеют обращаться к восстановленной базе данных для чтения (к примеру, для сотворения отчетов), но в то же время сохраняется возможность внедрения последующих запасных копий журналов транзакций. Такое решение употребляется обычно только при применении автоматической доставки журналов на запасный сервер (log shipping).

Как и в случае с командой BACKUP, некие способности команды RESTORE доступны только из кода Transact-SQL. Про некие из их (к примеру, про возможность восстановления до метки транзакции либо LSN) уже поведано. Дальше представлено еще несколько характеристик, которые нельзя избрать с помощью графического интерфейса:

PAGE - данный параметр позволяет указать определенные страницы в базе данных, которые будут восстанавливаться. Данная новенькая возможность SQL Server 2014, в прошлых версиях её не было.