Восстановление базы данных
Министерство Образования Российской ФедерацииНазвание Вашего института (полное)Название Вашей кафедры (полное) Курсовая работапо специальности ""на тему:"Восстановление базы данных"Москва, 2010СодержаниеВведение1. Причины повреждений баз данных2. Восстановление баз данных на примере SQL Server 20052.1 Основные возможности восстановления баз данных SQL Server 20052.2 Подготовка к восстановлению2.3 Проведение восстановления2.4 Специальные ситуации восстановленияЗаключениеСписок литературыВведениеУстановлено, что большинство предприятий, переживших крупную необратимую потерю корпоративных данных, прекращают свое существование в течение трех лет после такого инцидента. Мысль о возможной катастрофе неприятна для ИТ- и бизнес-менеджеров, поэтому они часто не принимают серьезных предупредительных мер. К сожалению, это грубая правда жизни. И здесь под "предупредительными мерами" ни в коем случае нельзя понимать "покупку техники brand-name", так как "брэнды" тоже ломаются, иногда даже чаще чем "самосборные машины". Поэтому "предупредительные меры" - это не только качественное "железо", но и планирование резервного копирования данных.Актуальность моего исследования определила цель и задачи работы:Цель исследования – рассмотреть методы восстановления баз данныхДля достижения цели необходимо решить следующие задачи:На основе анализа зарубежной и отечественной литературы, монографических источников изучить методы восстановления баз данныхВыявить причины при которых базу данных нужно восстанавливатьПровести анализ основных возможностей восстановленияРассмотреть на примере SQL Server 2005 восстановление базы данныхНа основе проведенного исследования сделать выводы и дать рекомендации по работеДля раскрытия поставленной цели и задач определена следующая структура исследования: работа состоит из введения, двух глав, заключения и списка использованной литературы. Названия глав отображают их содержание. 1. Причины повреждений баз данныхСуществует несколько причин, при которых база данных может оказаться поврежденной. Перечислим наиболее характерные.Отключение питания сервера.Самый частый случай повреждения базы данных это отключение питания на сервере. Такие ситуации нужно пытаться предотвращать, используя аппаратные средства (UPS, RAID-контроллеры с батарейками). Существует два режима записи страниц - синхронный и асинхронный. Синхронная запись означает, что измененные страницы базы данных не будут кэшироваться операционной системой, а будут записываться непосредственно на диск при выталкивании страниц из кэша на запись (на Windows это в буквальном смысле отсутствие флага lazy write при открытии файла БД). Это ухудшает производительность, поэтому большинство людей выключают forced writes. В этом случае измененные страницы находятся в кэше операционной системы до тех пор, пока операционная система не решит записать их на диск. В некоторых случаях при непрерывной работе с БД операционная система не сбрасывает измененные страницы на диск до тех пор, пока все пользователи не отсоединятся от базы данных. При выключении питания в этом случае повреждения базы данных могут быть максимальными. Причем, повреждения в данном случае происходят от "недозаписи" информации. Это куда менее печальный случай, чем "перезапись" информации случайными данными. Однако, на Windows было обнаружено, что если у базы данных установлено Forced Write = Off, то при определенных условиях измененные страницы БД могли неделями не попадать в БД, и оставаться в кэше операционной системы. При этом, в случае сбоя сервера (или отключения питания), пропадало огромное количество изменений в БД (а база могла выглядеть вообще неповрежденной). То есть, БД как бы оказывалась "неизменяемой" в течение длительного времени. Дефекты оборудованияПамять. Самый частый дефект - сбои памяти (RAM). Очевидно, при использовании серверов "своей сборки" приобретается память подешевле, что приводит к соответствующим результатам. Желательно для сервера приобретать и материнскую плату и память с поддержкой ECC. Сбои памяти могут привести к достаточно тяжелым последствиям. Сервер не только "пропускает" страницы базы данных через память, но и кэширует их в памяти. Контрольные суммы страниц, даже если бы они и были, не помогут когда сервер будет записывать страницу на диск через сбойный участок памяти. В противном случае данные пришлось бы перечитывать, что весьма серьезно ухудшило бы производительность. Сбои памяти еще плохи тем, что в этом случае поврежденными как правило оказываются и база данных и ее копия, если копия используется в качестве "быстрой резервной копии" (т.к. запись на диск идет из одних и тех же участков памяти).Диски. Раньше, лет 10-15 назад, bad-блоки появлялись часто, и существовали специальные утилиты для их исправления. Сейчас контроль ошибок не только может исправить данные на поврежденном блоке самостоятельно, но и прозрачно сохранит блок в рабочем месте диска, а плохой блок пометит к исключению из дальнейшего использования. Грубо говоря, нынешние диски либо работают, либо не работают целиком.Контроллеры. Здесь можно отметить только то, что при сбое в работе контроллера некорректная информация может быть записана на все носители, которые подключены к этому контроллеру. Именно поэтому при организации создания копии рекомендуется располагать ее на винчестере, подключенном к другому контроллеру.Другие программы. Приложения в основном не работают с операционной системой на "внутреннем" уровне. Такие приложения никогда не смогу