Восстановление базы данных

Министерство Образования Российской Федерации

Название Вашего института (полное)

Название Вашей кафедры (полное)

 

Курсовая работа

по специальности ""

на тему:

"Восстановление базы данных"

Москва, 2010

Содержание

 

Введение

1. Причины повреждений баз данных

2. Восстановление баз данных на примере SQL Server 2005

2.1 Основные возможности восстановления баз данных SQL Server 2005

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

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

2.4 Специальные ситуации восстановления

Заключение

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

Введение

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

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

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

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

1.   На основе анализа зарубежной и отечественной литературы, монографических источников изучить методы восстановления баз данных

2.   Выявить причины при которых базу данных нужно восстанавливать

3.   Провести анализ основных возможностей восстановления

4.   Рассмотреть на примере SQL Server 2005 восстановление базы данных

5.   На основе проведенного исследования сделать выводы и дать рекомендации по работе

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

1. Причины повреждений баз данных

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

1.         Отключение питания сервера.

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

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

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

2.         Дефекты оборудования

Память. Самый частый дефект - сбои памяти (RAM). Очевидно, при использовании серверов "своей сборки" приобретается память подешевле, что приводит к соответствующим результатам. Желательно для сервера приобретать и материнскую плату и память с поддержкой ECC. Сбои памяти могут привести к достаточно тяжелым последствиям. Сервер не только "пропускает" страницы базы данных через память, но и кэширует их в памяти. Контрольные суммы страниц, даже если бы они и были, не помогут когда сервер будет записывать страницу на диск через сбойный участок памяти. В противном случае данные пришлось бы перечитывать, что весьма серьезно ухудшило бы производительность. Сбои памяти еще плохи тем, что в этом случае поврежденными как правило оказываются и база данных и ее копия, если копия используется в качестве "быстрой резервной копии" (т.к. запись на диск идет из одних и тех же участков памяти).

Диски. Раньше, лет 10-15 назад, bad-блоки появлялись часто, и существовали специальные утилиты для их исправления. Сейчас контроль ошибок не только может исправить данные на поврежденном блоке самостоятельно, но и прозрачно сохранит блок в рабочем месте диска, а плохой блок пометит к исключению из дальнейшего использования. Грубо говоря, нынешние диски либо работают, либо не работают целиком.

Контроллеры. Здесь можно отметить только то, что при сбое в работе контроллера некорректная информация может быть записана на все носители, которые подключены к этому контроллеру. Именно поэтому при организации создания копии рекомендуется располагать ее на винчестере, подключенном к другому контроллеру.

Другие программы. Приложения в основном не работают с операционной системой на "внутреннем" уровне. Такие приложения никогда не смогут вызвать сбой типа известного "синего экрана" в Windows. Поэтому если подобный сбой ОС произошел, в этом скорее виноваты некорректно работающие драйверы или само оборудование (очень часто в "синем экране" виноваты драйвера видео).