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

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

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

 

 

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

 

 

 

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

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

 

На тему

 

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

 

 

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

 

 

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

 

 

Выставлена оценка (баллов 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). Теперь в некоторых ситуациях можно вместо восстановления всей базы данных или каких-то файлов, ограничиться восстановлением лишь отдельных страниц. Это позволит:

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