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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И  НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

МОСКОВСКИЙ ФИНАНСОВО-ПРОМЫШЛЕННЫЙ УНИВЕРСИТЕТ «СИНЕРГИЯ»

 

 

КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ

 

 

 

КУРСОВОЙ ПРОЕКТ

по дисциплине «Безопасность баз данных»

 

На тему

 

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

 

 

Выполнен студентом  группы
	Калуцкий Дмитрий Алексеевич
Руководитель

 

 

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

 

 

Выставлена оценка (баллов 0 – 100)
Дата

 

 

 

Москва. 2012

 

Содержание

Введение

1.Описание и структура организации.

1.1Характериска  предприятия и его деятельности .

1.2 Структурно-функциональная диаграмма организации бизнеса.

2. Проектная часть.

2.1 Разработка и описание проекта СУБД, информационной безопасности и защиты информации в СУБД.

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

2.1.2 Характеристика результатной информации

 

Заключение 

Список литературы

 

 

 

 

Введение

 

Установлено, что большинство предприятий, переживших крупную необратимую  потерю корпоративных данных, прекращают свое существование в течение  трех лет после такого инцидента. Мысль о возможной катастрофе неприятна для ИТ- и бизнес-менеджеров, поэтому они часто не принимают серьезных предупредительных мер. К сожалению, это грубая правда жизни. И здесь под "предупредительными мерами" ни в коем случае нельзя понимать "покупку техники brand-name", так как "брэнды" тоже ломаются, иногда даже чаще чем "самосборные машины". Поэтому "предупредительные меры" - это не только качественное "железо", но и планирование резервного копирования данных.

Актуальность моего исследования определила цель и задачи работы:

Цель исследования – рассмотреть методы восстановления баз данных

Для достижения цели необходимо решить следующие задачи:

1. На основе анализа зарубежной и отечественной литературы, монографических источников изучить методы восстановления баз данных
2. Выявить причины при которых базу данных нужно восстанавливать
3. Провести анализ основных возможностей восстановления
4. Рассмотреть на примере SQL Server 2008 восстановление базы данных
5. На основе проведенного исследования сделать выводы и дать рекомендации по работе

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

 

1. Описание и структура организации.

1.1Характериска предприятия и его деятельности.

 

ОАО «ВымпелКом» -российская телекоммуникационная компания, с 2009 года входящая в международную группу VimpelCom. Предоставляет услуги сотовой (GSM и UMTS) и фиксированной связи, проводного (FTTB) и беспроводного (Wi-Fi) высокоскоростного доступа в Интернет, IP-телевидения физическим и юридическим лицам под торговой маркой «Билайн». Штаб-квартира — в Москве.

Компания осуществляет деятельность во всех субъектах России, 6 странах СНГ (Киргизии, Казахстане, Украине, Таджикистане, Узбекистане, Армении), Грузии, Камбодже, Лаосеи во Вьетнаме. Лицензии группы компаний «ВымпелКом» охватывают территории с общим населением около 340 млн человек. По данным J’son & Partners «Вымпелком» является мировым лидером по числу роуминговых партнёров и по числу роуминговых стран.

Являясь лидером московского сотового рынка (а значит крупнейшим оператором России), в 1996 году «ВымпелКом» стал первой российской компанией, включённой в листинг Нью-Йоркской фондовой биржи, — под международным названием VimpelCom и символом «VIP» (в 2010 перерегистрирован на VimpelCom Ltd.). До апреля 2010 года — второй (после «МТС») оператор сотовой связи в России по числу абонентов. В течение 2010 года «ВымпелКом» уступил 2-ю позицию по числу абонентов и по выручке с мобильного бизнеса «МегаФону». С 2008 года «ВымпелКом» контролирует 49,9 % лидера российского рынка сотового ритейла — компании «Евросеть».

 

 

 

 

 

1.2 Структурно-функциональная диаграмма организации бизнеса

Рассмотрим одну из технических  служб ОАО «ВымелКом».

 

 

 

Схема 1. Структура службы.

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

В качестве мониторинга сети используется сервер на базе «Windows Server 2008» с установленным ПО Cacti и SQL Server 2008. Cacti опрашивает оборудование по протоколу SNMP в реальном времени и получает от него необходимые данные (доступность узла, трафик на интерфейсах и пр.). Сервер имеет источник бесперебойного питания «APC BK650EI Back-UPS 650VA/400W» согласно ГОСТ 13109-97. При долгосрочном отключении основного питания, ИБП может обеспечить функционирование сервера в течение 14мин.

 

2. Проектная часть

2.1 Разработка и описание проекта СУБД, информационной безопасности и защиты информации в СУБД.

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

Самый частый случай повреждения базы данных это отключение питания на сервере. Существует два режима записи страниц - синхронный и асинхронный. Синхронная запись означает, что измененные страницы базы данных не будут кэшироваться операционной системой, а будут записываться непосредственно на диск при выталкивании страниц из кэша на запись (на Windows это в буквальном смысле отсутствие флага lazy write при открытии файла БД). Это ухудшает производительность, поэтому большинство людей выключают forced writes. В этом случае измененные страницы находятся в кэше операционной системы до тех пор, пока операционная система не решит записать их на диск.

В некоторых случаях при непрерывной  работе с БД операционная система  не сбрасывает измененные страницы на диск до тех пор, пока все пользователи не отсоединятся от базы данных. При выключении питания в этом случае повреждения базы данных могут быть максимальными. Причем, повреждения в данном случае происходят от "недозаписи" информации. Это куда менее печальный случай, чем "перезапись" информации случайными данными. Однако, на Windows было обнаружено, что если у базы данных установлено Forced Write = Off, то при определенных условиях измененные страницы БД могли неделями не попадать в БД, и оставаться в кэше операционной системы. При этом, в случае сбоя сервера (или отключения питания), пропадало огромное количество изменений в БД (а база могла выглядеть вообще неповрежденной). То есть, БД как бы оказывалась "неизменяемой" в течение длительного времени.

Восстановление может произвести ответственный сотрудник за базу или его помощники, в данном случае ответственность несет Ведущий специалист по развитию инфо-систем и бизнеса.

	Доступ к ПК	Доступ к базе
Руководитель службы	Администратор	Администратор
Ведущий специалист по анализу качества	Пользователь	Администратор
Менеджер по развитию	Пользователь	Пользователь
Ведущий специалист по развитию инфо-систем и бизнеса	Администратор	Администратор
Инженер	Пользователь	Нет

 

 

Restore. С точки зрения SQL Server, этот термин можно перевести как "восстановление с носителя". Чаще всего восстановлением с носителя приходится заниматься в ситуациях, когда база данных повреждена физически или нужно исправить большую ошибку пользователя. Нередко ею пользуются для создания тестовой базы для проверки критических обновлений или учебы. Во время этого процесса производится перенос данных из резервной копии на сервер базы данных.

Recovery. Его можно перевести как "восстановление работоспособности". Во время процедуры recovery устраняются все проблемы, которые могут быть с базой данных (например, возникшие из-за незавершенных транзакций), и база данных открывается для доступа пользователей. Процедура recovery должна быть произведена после восстановления с носителя — restore, однако она запускается и в других ситуациях. Например, если работа сервера был завершена некорректно (например, пропало питание), то эта процедура вернет все базы данных в работоспособное состояние.

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

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

 

Во всех предыдущих версиях  SQL Server можно было выполнять восстановление базы данных, только отключив от нее всех пользователей. В SQL Server 2008 появилась новая возможность — восстановление на работающей базе данных. Другое название такого типа восстановления — оперативное восстановление (online restore).

Конечно, на практике обойтись совсем без ограничения доступа пользователей  не удастся. При восстановлении на работающей базе данных вам в любом случае придется перевести в автономный режим (offline) тот файл или файловую группу, восстановление которого вы производите в данный момент. Остальные файлы или файловые группы могут оставаться в рабочем режиме.

Для восстановления на открытой базе данных предусмотрены и другие ограничения:

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

Если это возможно, SQL Server автоматически применяет режим оперативного восстановления при восстановлении отдельных файлов, файловых групп и страничном восстановлении (но не при обычном восстановлении всей базы данных). Если вы хотите запретить применение оперативного восстановления и производить восстановление файлов, файловых групп и отдельных страниц в обычном автономном режиме, то можно перед восстановлением выполнить команду BACKUP LOG WITH NORECOVERY. Эта команда, которая обычно применяется только при использовании автоматической доставки журналов (log shipping), позволяет создать резервную копию журнала транзакций и перевести базу данных в специальное состояние RESTORING. В этом состоянии доступ к базе данных пользователей будет закрыт, а восстановление будет производиться только в автономном режиме.

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

RESTORE DATABASE db1 FILE = 'db1file2' FROM DISK = 'D:\SQLBackups\BackupFile1.bak' WITH NORECOVERY;

RESTORE LOG db1 FROM DISK = 'D:\SQLBackups\BackupLogFile1.bak';

Еще одна новая возможность SQL Server 2008, связанная с восстановлением, — восстановление отдельных страниц данных (page restore). Теперь в некоторых ситуациях можно вместо восстановления всей базы данных или каких-то файлов, ограничиться восстановлением лишь отдельных страниц. Это позволит:

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

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

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

• вы используете редакцию 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, но синтаксис будет немного другим, например: