Восстановление базы данных после жесткого сбоя

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

Восстановление отдельных страниц  базы данных можно производить только при соблюдении следующих условий:

• вы используете редакцию Enterprise Edition;
• восстанавливаемые страницы не относятся к журналу транзакций, к служебным страницам базы данных и к полнотекстовым каталогам;
• база данных работает в режиме Full или Bulk-logged;
• файловые группы, к которым относятся восстанавливаемые страницы, доступны и на чтение, и на запись.

Порядок действий восстановления отдельных  страниц базы данных обычно такой:

1. Вначале вы обнаруживаете, что некоторые страницы в базе данных повреждены. Такую информацию можно получить при просмотре журналов событий SQL Server, при помощи команд DBCC (например, DBCC CHECKDB) и просто при помощи анализа сообщений, которые возвращаются клиентскому приложению. Сам SQL Server выявляет поврежденные страницы при помощи анализа контрольных сумм или контрольных бит.

2. Перед восстановлением вам нужно получить информацию о номерах поврежденных страниц и номерах файлов, в которых эти страницы находятся. Эта информация хранится в таблице suspect_pages базы данных msdb (она заносится в эту таблицу автоматически). Номера страниц находятся в столбце page_id, а номера файлов — в столбце file_id. Надо отметить, что в таблице suspect_pages не может быть более 1000 записей. По достижении этого предела запись в таблицу просто прекращается. Поэтому рекомендуется в случае физического повреждения баз данных после восстановления очистить эту таблицу.

3. Затем запускаете команду на восстановление базы данных, например:

RESTORE DATABASE db1 PAGE = '1:51, 1:52, 1:55' FROM DISK = 'D:\SQLBackups\BackupFile1.bak';

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

В некоторых ситуациях может  потребоваться произвести восстановление системной базы данных master, в которой хранится служебная информация всего сервера (например, информация о логинах, пользовательских базах данных, настройках сервера и т. п.).

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

Восстановление базы данных master отличается от восстановления обычных баз данных некоторыми особенностями:

• производить восстановление базы данных master можно только после перезапуска сервера в однопользовательском режиме. Проще всего сделать это, запустив SQL Server из командной строки. Для этого нужно перейти в каталог, в котором находится файл sqlservr.exe (по умолчанию это C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn), а затем выполнить команду: sqlservr.exe -m
• если база данных master повреждена, то сервер вполне может не запуститься. В этом случае, чтобы все-таки можно было запустить сервер и произвести процедуру восстановления, нужно перестроить базу данных master. При перестроении база данных master возвращается к своему исходному состоянию (когда сервер был только что установлен). В предыдущих версиях SQL Server для перестроения базы данных master использовалась специальная утилита rebuildm. В SQL Server 2008 для этой цели используется программа установки SQL Server;
• для базы данных master доступен только один тип резервного копирования — полное резервное копирование всей базы данных. Поэтому восстановить вы можете только всю базу данных master целиком. Резервное копирование и восстановление журналов транзакций, а также любые другие операции восстановления (файлов, файловых групп, отдельных страниц и т. п.) для этой базы данных не предусмотрены;
• после восстановления базы данных master сервер автоматически перезагрузится.

После того, как восстановление базы данных master завершится, очень рекомендуется проверить, не возникло ли каких-то проблем на SQL Server. Могут обнаружится проблемы:

• с логинами. Для проверки можно использовать хранимую процедуру sp_validatelogins;
• с пользователями баз данных. Проверку можно произвести при помощи команды: sp_change_users_login @Action = 'Report';
• со списком баз данных на сервере. Если какой-то базы данных в списке нет, но файлы ее остались на диске, эту базу данных можно заново присоединить к серверу.

Если вы произвели перестроение базы данных master, то после завершения восстановления этой базы данных обязательно нужно произвести восстановление баз данных model и msdb. В остальном, резервное копирование и восстановление этих баз производится так же, как и пользовательских.

Произвести резервное копирование  базы данных tempdb невозможно. Поскольку эта база данных создается заново при каждом запуске SQL Server, то восстанавливать ее не нужно.

2.2 Информационное обеспечение  задачи

2.2.1 Характеристика базы данных и средств информационной безопасности.

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

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

3. Только в редакции SQL Server 2008 Enterprise Edition пользователям открывается доступ к базе данных. Открытие доступа на этом этапе — это новая возможность SQL Server 2008. Она имеет свое название — fast recovery (быстрое восстановление). Если же пользователь попытается обратиться к данным, измененным незавершенными транзакциями, то доступ ему будет закрыт за счет механизма блокировок.

4. Затем SQL Server обнаруживает в журнале все незавершенные транзакции и отменяет их. Эта операция называется rollback — откат транзакций, а сам этап называется этапом отката (rollback phase).

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

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

• для восстановления вы можете использовать не только резервные копии, которые были созданы в версии SQL Server 2008, но и те, которые были созданы на версиях 7.0 и 2000. Обновление до версии 2005 произойдет автоматически. Конечно, такую возможность следует рассматривать как еще один вариант обновления баз данных;
• создатели SQL Server 2008 активно рекламируют новую возможность — восстановление на открытой базе данных. На самом деле такое восстановление можно производить только тогда, когда в базе данных несколько файловых групп, и восстанавливаемая файловая группа находится в автономном режиме (offline). Поэтому на самом деле пользователи работать с восстанавливаемыми данными, конечно, не смогут;
• в SQL Server 2008 восстановление полнотекстовых индексов производится вместе с базами данных;
• информация о восстановлении, как и информация о резервном копировании, записывается в служебные таблицы базы данных msdb. Используются таблицы restorehistory, restorefile и restorefilegroup.

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

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

• для большинства баз данных достаточно установить для параметра Restrict Access (Ограничить доступ) свойств базы данных значение Restricted. Если же пользователи вашей базы данных могут подключаться с правами dbo, то для этого параметра можно установить значение Single;
• если на сервере имеется только одна рабочая база данных, то лучше просто на время восстановления отключить сетевой доступ к SQL Server. Для этого можно, например, на время восстановления отключить протокол TCP/IP в контейнере SQL Server 2008 Network Configuration в SQL Server Configuration Manager.

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

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

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

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

• RESTORE FILELISTONLY — возвращает информацию о списке файлов и журналов транзакций, которые помещены в данную резервную копию. Эта информация берется из таблицы backupfile базы данных msdb;
• RESTORE HEADERONLY — возвращает информацию об имени резервной копии, ее типе, описании, времени создания и времени устаревания и т. п.. Эта информация берется из таблицы backupset базы данных msdb;
• RESTORE LABELONLY — выводит служебную информацию о метке носителя. В основном метка нужна для картриджей стриммеров, но может применяться и для файлов. Информация берется, в том числе, и из таблицы backupmediaset базы данных msdb.

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

• RESTORE FILELISTONLY FROM backupdevice1;
• Конечно, вы можете обратиться к таблицам с историей резервного копирования в базе данных msdb и напрямую.

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

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

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

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

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

To a point of time (На момент времени) — позволяет задать восстановление на определенный момент времени. Обычно используется только в ситуации, когда пользователь совершил ошибку (например, удалил важные данные) и вы знаете примерно, когда это произошло. Используется только при восстановлении журналов транзакций. Этот переключатель соответствует параметру STOPAT команды RESTORE, например, WITH STOPAT = '01/06/2006 12:14:24'. Для команды RESTORE можно указать еще два параметра:

1. восстановление на метку транзакции. Обычно метка транзакции применяется перед выполнением рискованных операций (применение исправлений от разработчиков, очистка или массовая загрузка данных и т. п.). Создать метку транзакции можно очень просто:

BEGIN TRAN mark1 WITH MARK;

COMMIT TRAN;

Для восстановления потребуется использовать параметр WITH STOPATMARK = 'mark1', чтобы остановиться точно на этой метке или WITH STOPBEFOREMARK = 'mark1' для остановки точно перед этой меткой;

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