Восстановление базы данных реферат
Обновлено: 08.07.2024
Аннотация: В прошлой лекции вы познакомились с методами резервного копирования базы данных. Теперь пришло время рассказать о восстановлении данных до состояния нормальной работы системы. Рассматривается восстановление из полной резервной копии, разностной резервной копии, резервных копий журналов транзакций, режиме воспроизведения BULK_LOGGED. Уделено внимание операторам RESTORE DATABASE и RESTORE LOG. Описание параметров этих операторов, примеры использования. Эти две лекции помогут эффективно выполнять резервное копирование и восстановление системы и понять как выполняется воспроизведение в SQL Server.
В "Резервное копирование Microsoft SQL Server" вы узнали о том, насколько важно выполнять резервное копирование вашей системы и как создавать резервные копии. В этой лекции мы продолжим тему защиты базы данных , исходя из материала предыдущей лекции. Вы узнаете, как восстанавливать базу данных, как планировать восстановление на случай аварии; мы рассмотрим более подробно, как происходит воспроизведение базы данных . Как вы увидите, тип выполненного резервного копирования влияет на то, как выполняется восстановление. Кроме изучения методов восстановления и воспроизведения базы данных , вы ознакомитесь с понятием доставки журнала транзакций (log shipping). Это новое средство, введенное в Microsoft SQL Server 2000, позволяющее создавать резервную копию вашей базы данных на другом сервере путем использования журнала транзакций исходного сервера.
Примечание. Некоторые администраторы баз данных ( DBA ) называют процесс восстановления (restoring) и последующее воспроизведение ( recovering ) базы данных просто "воспроизведением базы данных". Однако это совершенно различные процедуры. В "Резервное копирование Microsoft SQL Server" разъясняются отличия между восстановлением базы данных из резервной копии и процессом воспроизведения SQL Server. В любом случае главной целью выполнения операций резервного копирования, восстановления и воспроизведения является возврат базы данных к состоянию, в котором она находилась на момент отказа системы.
Методы восстановления
Как уже говорилось, тип выполненного резервного копирования влияет на характер операции восстановления. В этом разделе вы узнаете, как выполнять восстановление из полной резервной копии, из разностной резервной копии, а также из резервных копий журнала транзакций.
Восстановление из полной резервной копии
Восстановление из полной резервной копии – это довольно простой процесс: вы просто восстанавливаете файлы резервной копии с помощью SQL Server Enterprise Manager или операторов Transact-SQL (T-SQL). Инструкции по восстановлению данных с помощью этих двух методов приводятся далее в данной лекции. Если вы планируете восстановление из разностных резервных копий после восстановления из полной резервной копии, то не забывайте создавать резервную копию текущего журнала транзакций (см. раздел "Восстановление из резервных копий журнала транзакций" далее в этой лекции), и задавать параметр NORECOVERY , когда выполняете восстановление.
Примечание. Важной особенностью операции восстановления является использование параметра RECOVERY . Параметр RECOVERY указывает SQL Server, что после окончания операции восстановления нужно попытаться воспроизвести базу данных с помощью оперативного журнала транзакций. Если вы планируете использовать файлы разностных резервных копий или файлы резервных копий журнала транзакций, то не забудьте указать параметр NORECOVERY .
Восстановление из разностной резервной копии
Для восстановления из разностной резервной копии вы должны сначала выполнить восстановление из полной резервной копии и затем – из всех разностных резервных копий, созданных вслед за последней полной резервной копией. Напомним, что разностная резервная копия используется для резервного копирования информации, которая изменилась с момента последнего полного или разностного резервного копирования. Не забудьте использовать параметр NORECOVERY (за исключением случая восстановления самого последнего файла резервной копии, для которого вы будете использовать параметр RECOVERY ). Если у вас выполняется восстановление из резервных копий журналов транзакций в дополнение к разностной резервной копии, то вы должны также выполнить резервное копирование текущего журнала и применять все измененные файлы журнала, как это описано в следующем разделе.
Восстановление из резервных копий журнала транзакций
Чтобы выполнить воспроизведение для возврата базы данных к состоянию, в котором она находилась непосредственно перед отказом системы, вы должны сначала восстановить файлы данных из последней полной резервной копии и затем восстановить изменения, внесенные в базу данных после этого резервного копирования. Чтобы восстановить эти изменения, вам нужно восстановить все резервные копии журнала транзакций, созданные до момента отказа.
Чтобы вы не потеряли ни одной из самых последних транзакций, вы должны сначала сохранить текущий журнал. Если вы забудете сохранить текущий журнал, то потеряете последние изменения, записанные в журнал транзакций, поскольку операции восстановления перезаписывают журнал транзакций.
Чтобы использовать журналы транзакций для восстановления базы данных к состоянию, в котором она находилась непосредственно перед моментом отказа, выполните следующие основные шаги, используя методы, которые вы изучили в "Резервное копирование Microsoft SQL Server" .
- Выполните резервное копирование текущего активного журнала транзакций, используя параметр NO_TRUNCATE .
- Восстановите последнюю полную резервную копию.
- Восстановите все разностные резервные копии для возврата базы данных к состоянию, в котором она находилась при создании последней резервной копии.
- Восстановите все резервные копии журнала транзакций, созданные после записи последней разностной резервной копии, для воспроизведения всех транзакций, выполненных с момента создания этой последней резервной копии.
- Восстановите резервную копию журнала транзакций, которую вы создали на шаге 1, чтобы вернуть базу данных к состоянию, в котором она находилась непосредственно перед отказом системы.
Восстановление базы данных в режиме воспроизведения BULK_LOGGED
Если ваша база данных работает в режиме воспроизведения BULK_LOGGED , то вы должны повторно выполнить любые минимально протоколированные в журнале операции, если это восстановление необходимо. К этим операциям относятся SELECT. INTO, BULK COPY, BCP и некоторые операции CREATE INDEX , а также текстовые операции, о которых говорилось в предыдущей лекции. Если это налагает на вас непосильную нагрузку, не задавайте для вашей базы данных режим BULK_LOGGED .
- Для учеников 1-11 классов и дошкольников
- Бесплатные сертификаты учителям и участникам
Кахнович Герман Вячеславович
Научный руководитель Немченко Ольга Аркадьевна
ГБПОУ РМ «Саранский техникум энергетики и электронной техники
Актуальность исследования. Необходимость восстановления утраченных данных возникает у большинства пользователей ПК, поэтому утилиты восстановления занимают важное место в системном программном обеспечении. Данное исследование имеет важный прикладной характер.
Цель работы – освещение проблемы восстановления утерянных данных с различных носителей: жесткие диски, USB-накопители, SSD-накопители и др.
Практическая значимость. Значимость проведенного исследования заключается в оптимизации работы пользователей ПК. Изучение практических случаев восстановления данных влияет на потенциальную возможность дальнейшей разработки инновационного программного обеспечения. Повышение грамотности пользователей при работе с данными.
При удалении любого файла с данными Windows не уничтожает файл. Операционная система просто создает запись в файловой системе о том, что это место на носителе свободно для использования в других приложениях.
Во время того кода файл помечен как удаленный, но перезапись на это место ещё не произошла, восстановить файл не составит труда. На таком свойстве работы операционных систем базируются все алгоритмы восстановления данных.
Одним из минусов такого принципа восстановления является возникновение перекрестных ссылок. В некоторых случаях файловая система создавала записи для различных файлов, которые указывают на один и тот же сегмент жесткого диска. Это создавало проблемы для самой системы.
Современные программы восстановления используют усовершенствованные алгоритмы поиска и восстановления утерянных файлов. Для восстановления они уже не используют пространство тех секторов диска, на которые ссылается запись файловой системы, а копируют содержание удаленных файлов в другой документ (сохранять восстанавливаемые данные следует на другой носитель). Но и эти алгоритмы очень ограничены, их работа полностью зависит от функционирования файловой системы. При форматировании, перераспределении диска, повреждении файловой системы они не помогут. В таких случаях могут помочь кардинально новые средства восстановления данных.
Расположение файлов на диске
Знания принципов расположения файлов на диске позволяет лучше понимать алгоритмы восстановления данных.
Структура логического диска
Служебная информация о диске — это информация о размере раздела, типе файловой системы и т.п. Компьютер должен верно найти нужные данные на разделе.
Информация о файлах и папках — это файловые записи, которые содержат имена файлов, размер, отметки даты/времени, различную техническую информацию. Эта информация включает в себя точное физическое расположение файла, а именно адреса файлов на диске, а так же резервную копию информации, содержащаяся в файлах.
В разных файловых системах служебная информация о диске и информация о файлах и папках хранится по-разному. К примеру, в файловой системе FAT она хранится в Таблице Размещения Файлов (File Allocation Table), в системе NTFS — в Главной Файловой Таблице (Master File Table (MFT)).
Когда возникает необходимость прочесть тот или иной файл компьютер находит информацию о файлах и папках, ищет запись о данном файле, ищет адрес файла. Исходя из полученных данных, компьютер находит конкретное место на диске и осуществляет чтение файла.
Для файлов расположенных в одном месте, всё происходит быстро и просто. Иначе обстоит дело для фрагментированных файлов. Фрагментированный файл занимает несколько несмежных областей. Фрагментация файлов происходит довольно часто, однако пользователи о ней даже не догадываются. Если посмотреть на файл в Проводнике Windows то мы не увидим части файла, только его целиком. Это происходит из-за того, что операции по сбору частей файла происходят внутри самой ОС. ОС сразу находит адреса всех частей файлов при попытке чтения файла. При восстановлении файла крайне важны принципы извлечения информации.
При удалении файла не происходит мгновенного разрушения информации. Изменения вносятся лишь в информацию о файлах и папках показывающие, что файл был удален, при этом сохраняются метаданные файла, пока они не заменятся на метаданные нового файла. Такой процесс удаления свойствен для ОС семейства Windows. В некоторых операционных системах целиком разрушается файловая запись. Однако, во всех ОС независимо от разрушения файловых записей данные на диске остаются нетронутыми до их перезаписи.
Методы восстановления данных
Перед рассмотрением методов восстановления требуется отметить важное положение: файлы, которые были перезаписаны, невозможно восстановить ни одной программой, ни одним известным методом.
По этой причине крайне важно, что бы на восстанавливаемый носитель не были записаны какие либо данные.
Существует два метода восстановления не перезаписанных данных. Все утилиты восстановления используют либо один из них, либо оба.
Метод 1: Восстановление файлов посредством анализа информации о файлах и папках
Такой метод используется первым в утилитах восстановления. При его успешном завершении фалы восстанавливаются с подлинными именами, в точности восстанавливается файловая структура, восстанавливаются верные отметки времени и даты.
Первое что предпринимает утилита восстановления, это попытки прочитать и обработать первую копию информации о файлах и папках . Такой метод помогает при случайном удалении и ежеминутном восстановлении данных.
В случае повреждения первой копии, информации о файлах и папках, утилита начинает сканирование диска и поиск второй копии информации о файлах и папках. Дополнительно производится тщательный поиск дополнительной информации о структуре файлов и папок. После сбора всей доступной информации утилита её обрабатывает и воссоздает утерянную структуру файлов и папок.
В точности файловая структура может быть восстановлена лишь при не серьезных повреждениях файловой системы носителя.
При сильном повреждении файловой системы восстановленные файлы будут находится в папках с присвоенными виртуальными именами.
Метод 2: Восстановление файлов при помощи сканирования файлов известных типов ( поиска файлов по сигнатурам )
В случае плохих результатов проведения первого метода следует воспользоваться поиском файлов по сигнатурам . Такой метод позволяет восстановить большее количество данных, однако будут утеряна файловая структура, оригинальные названия файлов, отметки времени и даты.
Этот метод так же носит название сканирование файлов известных типов, анализируется содержимое диска и производится поиск по файловым сигнатурам .
Файловая сигнатура — некий общий шаблон данных (уникальный для определенного типа файлов), находящийся в конце или в начале файла.
Ограничения способа восстановления поиск файлов по сигнатурам
Так же этому методу может помешать фрагментация файлов. Файлы, имеющие сигнатуру только в начале, могут быть восстановлены с куском данных не относящимися к ним.
Восстановление Фрагментированных Файлов
Нет сигнатуры в конце файла, однако файл заканчивается в том месте, где начинается сигнатура в начале файла 2.
Файл успешно восстановлен.
Фрагментированный файл. Файл 3 пересекается с Файлом 2.
Файл не восстановлен. Утилита посчитает что файл заканчивается в месте начала файла 3. Вторая часть файла 2 будет утрачена
Смежный файл с сигнатурой в начале и в конце.
Файл успешно восстановлен.
Нет сигнатуры в конце файла, за файлом следует нераспределенное пространство.
Файл не восстановлен. Утилита посчитает что файл заканчивается в месте начала файла N, и нераспределенное пространство будет добавлено в конец файла 4.
Дополнительные параметры при восстановлении файлов
Кроме описанных методов восстановления некоторые программы предоставляют дополнительные возможности. К примеру, профессиональные программы восстановления данных позволяют пользователю добавить свои сигнатуры, по которым будет выполнен поиск.
На практике описанные методы применяются в паре. Это позволяет добиться наилучших результатов. Некоторая часть данных восстанавливается первым методом, остальная – вторым.
Рекомендуется выполнять восстановление с образов дисков. Такой шаг позволяет выполнять несколько попыток восстановления без риска того, что на исходном носителе будет что-то изменено.
Практические случаи восстановления данных
Случай 1: Восстановление файлов с жесткого диска с поврежденной служебной информацией.
При неправильном монтировании или аварийном извлечении метаданные диска могут быть повреждены или уничтожены. Утилиты восстановления анализируют информацию о файлах и папках сохраненную на самом диске. Поиск файлов по сигнатурам не понадобится. Как правило, все данные будут восстановлены.
Случай 2: Восстановление файлов с разбитого заново на разделы жесткого диска (физический диск).
Этот случай во многом схож с первым. Основное отличие в том, что при добавлении раздела на диск запишутся новые данные. Однако перезапишется только служебная информация. Восстановление возможно как в первом случае. Восстановятся всё файлы, которые не затронуты данными новых разделов.
Случай 3: Восстановление файлов с переформатированного раздела (логический диск).
Восстановление данных зависит от примененного к диску форматирования.
Если применено полное форматирование все данные перезапишутся определенными шаблонами (обычно 00 или FF), восстановление станет не возможным.
При быстром форматировании изменяются только данные о файлах и папках. Данные на самом диске не перезаписываются. Утилиты восстановления найдут то, что осталось от предыдущей файловой системы и попытаются восстановить файлы и папки. Результаты не однозначны, многое зависит от начальной и конечной файловой системы. Хорошим подспорьем может оказаться поиск файлов по сигнатурам.
Случай 4 : Восстановление файлов с диска с поврежденной файловой системой.
В этом случае многое зависит от степени повреждения файловой системы. Если повреждена только одна копия информации о файлах и папках, то утилиты смогут восстановить данные по второй копии. Если повреждены обе копии информации о файлах и папках, то может помочь поиск по сигнатурам. Результаты могут сильно отличаться.
Случай 5 : Восстановление файлов, утраченных при их переносе на диске.
При зависании компьютера или другого сбоя во время выполнения дефрагментации диска или операции разделения на разделы данные могут быть утеряны. Утилиты в этом случае не смогут порадовать результатом восстановления данных утерянных таким образом. Информация о файлах и папках обычно не повреждена, однако метаданные указывают на не правильные физические адреса файлов. При такой ситуации даже поиск по сигнатурам может не дать хороших результатов, данные, скорее всего, будут фрагментированы.
Восстановление данных с USB – накопителя
Для исследования возьмем USB – накопитель объёмом 4 Гбайт, файловая система NTFS.
Запишем файлы на флэшку (Рисунок 1)
Удалим все файлы (Рисунок 2)
Рисунок 2
Попробуем восстановить файлы с помощью программы R.saver.
R.saver — бесплатная утилита для программного восстановления данных с различных носителей информации (жёсткий диск, компакт-диск, флеш-карта, дискета и т. д.), а также для копирования файлов с не поддерживаемых в ОС Windows файловых систем.
Нажимаем "Сканировать" (Рисунок 3)
Выделяем всё и копируем в папку на жестком диске (Рисунок 4)
Получаем восстановленные файлы без повреждений (Рисунок 5)
Восстановление после форматирования.
Форматируем накопитель (быстрое форматирование) (Рисунок6)
Пытаемся восстановить данные в папку на жестком диске (Рисунок 7)
Форматируем накопитель в другую файловую систему из NTFS в FAT 32 (быстрое форматирование) (Рисунок10)
Восстанавливаем данные (Рисунок 11)
В итоге MP3 файл поврежден (Рисунок 12-13)
Файл Microsoft Word поврежден (Рисунок 14)
Видео не восстановлено.
Восстановление данных интересная и часто используемая на практике область информационно-коммуникативных знаний и значительно актуальная для любого пользователя ПК. Утилиты восстановления часто используют пользователи всего мира.
Восстановление утерянных данных очень полезная возможность для пользователей компьютера. Никто не защищен от случайного удаления, сбоя системы, повреждения файловой системы. Утерянная информация может быть единственной копией и иметь высокую ценность для пользователя.
Восстановить утерянные данные помогут утилиты восстановления. Однако их возможности не безграничны. Восстановить перезаписанную информацию программным методом не возможно. Утилиты лучше всего подойдут в случаях случайного удаления, форматирования носителя.
Повреждения файловой системы слишком индивидуальны, могут привести к непредсказуемым последствиям. Во многих случаях таких повреждений утилиты не смогут восстановить информацию.
Для поиска по сигнатурам критически важна фрагментация диска, с которого производится восстановление утерянных данных. Пользователям можно посоветовать использовать утилиты дефрагментации носителей.
Исходя из проведенного исследования, можно сказать, что программный метод восстановления данных не дает хороших результатов в некоторых практических случаях.
Пользователям можно порекомендовать делать резервные копии важных для них данных на разных носителях. Для копирования важных данных очень удобно использовать набирающие популярность облачные хранилища данных.
Название работы: Восстановление базы данных
Предметная область: Информатика, кибернетика и программирование
Описание: При этом надо устранить последствия операторов модификации базы данных которые выполнялись в этой транзакции. Ситуация характеризуется потерей той части базы данных которая к моменту сбоя содержалась в буферах оперативной памяти. Восстановление после поломки основного внешнего носителя базы данных жесткий сбой.
Дата добавления: 2013-09-21
Размер файла: 28 KB
Работу скачали: 4 чел.
Существует 3 типа сбоя (см. ответ на вопрос 3):
- Индивидуальный откат транзакции . Типичной ситуацией отката транзакции является ее завершением оператором ROLLBACK ; откат транзакции может быть инициирован системой. При этом надо устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.
- Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Возникает при выключении электрического питания и при неустранимом сбое процессора. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти.
- Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой).
Индивидуальный откат транзакции .
Для того чтобы можно было выполнить по общему журналу индивидуальный откат транзакции, все записи в журнале о данной транзакции связываются в обратный список. Началом списка для незакончившихся является запись о последнем изменении базы данных, произведенном данной транзакцией. Концом списка всегда служит запись об изменении базы данных, произведенном данной транзакцией. Обычно в каждой записи проставляется идентификационный номер транзакции, чтобы можно было восстановить прямой список записей об изменениях базы данных определенной транзакции.
Индивидуальный откат транзакции выполняется следующим образом:
выбирается очередная запись из списка данной транзакции;
выполняется противоположная по смыслу операция (например, вставка вместо удаления); тем самым восстанавливается предыдущее состояние объекта базы данных;
обратные операции журнализируются;
при успешном завершении отката в журнал заносится запись о конце транзакции; с точки зрения механизма журнализации такая транзакция является зафиксированной.
Восстановление после мягкого сбоя .
К числу проблем, возникающих при мягком сбое, относится тот факт, что одна логическая операция модификации базы данных может изменить несколько физических блоков базы данных. Несмотря на применение протокола WAL , после мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, т.е. часть страниц внешней памяти соответствует измененному состоянию объекта, а часть - нет. К такому состоянию не применима операция восстановления логического уровня. Если состояние объекта соответствует состоянию объекта до/после его изменения, то состояние внешней памяти базы данных называют физически согласованным.
Восстановление после жесткого сбоя, механизм резервного копирования.
Любая СУБД должна предоставлять механизм, позволяющий создавать резервные копии базы данных и ее журнала через установленные промежутки времени и без необходимости останавливать систему.
Для этого типа восстановления недостаточно только восстановление последнего состояния базы данных, поэтому основным инструментом является в этом случае журнал и архивная копия базы данных.
Восстановления начинается с обратного копирования базы данных из архивной копии; затем для всех закончившихся транзакций операции выполняются повторно в прямом смысле. По журналу (в прямом направлении) выполняются все операции, для незакончившихся к моменту сбоя операциям применяется откат. Поскольку жесткий сбой не сопровождается утратой буферов оперативной памяти, можно восстановить базу данных до такого уровня, чтобы можно было продолжить даже выполнение незакончившихся транзакций. Восстановление после жесткого сбоя - процедура достаточно длительная. К сожалению, возможна утрата и журнала изменений, тогда единственным источником данных является архивная копия; недостатком в данном случае является восстановление не к последнему согласованному состоянию базы данных.
Производство архивных копий возможно несколькими путями: при переполнении журнала изменений и архивирование самого журнала изменений.
Установлено, что большинство предприятий, переживших крупную необратимую потерю корпоративных данных, прекращают свое существование в течение трех лет после такого инцидента. Мысль о возможной катастрофе неприятна для ИТ- и бизнес-менеджеров, поэтому они часто не принимают серьезных предупредительных мер. К сожалению, это грубая правда жизни. И здесь под "предупредительными мерами" ни в коем случае нельзя понимать "покупку техники 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. Сбои памяти могут привести к достаточно тяжелым последствиям. Сервер не только "пропускает" страницы базы данных через память, но и кэширует их в памяти. Контрольные суммы страниц, даже если бы они и были, не помогут когда сервер будет записывать страницу на диск через сбойный участок памяти. В противном случае данные пришлось бы перечитывать, что весьма серьезно ухудшило бы производительность. Сбои памяти еще плохи тем, что в этом случае поврежденными как правило оказываются и база данных и ее копия, если копия используется в качестве "быстрой резервной копии" (т.к. запись на диск идет из одних и тех же участков памяти).
Контроллеры. Здесь можно отметить только то, что при сбое в работе контроллера некорректная информация может быть записана на все носители, которые подключены к этому контроллеру. Именно поэтому при организации создания копии рекомендуется располагать ее на винчестере, подключенном к другому контроллеру.
Другие программы. Приложения в основном не работают с операционной системой на "внутреннем" уровне. Такие приложения никогда не смогут вызвать сбой типа известного "синего экрана" в Windows. Поэтому если подобный сбой ОС произошел, в этом скорее виноваты некорректно работающие драйверы или само оборудование (очень часто в "синем экране" виноваты драйвера видео).
ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
Восстановление базы данных — это процесс возвращения базы данных в рабочее состояние, утраченное в результате сбоя или отказа.
Для хранения данных используютсяносители четырёх различных типов, которые определим в порядке возрастания:
• оперативная память — временное хранилище информации, содержимое которого в случае отказа системы обычно разрушается;• магнитные диски — оперативное постоянное хранилище информации, которое надежнее в значительно дешевле, чем оперативная память, однако обеспечивающее меньшую на три-четыре порядка скорость доступак информации;
• магнитная лепта — автономный постоянным носитель информации, надежность которого существенно выше, чем надежность магнитного диска, а стоимость намного ниже, однако при этом онпредоставляет только последовательный доступ к информация, причем с относительно небольшой скоростью:
• оптическое диски — хранилище информации более надежное, чем магнитные ленты, идостаточно недорогое при этом более быстродействующее к тому же дотекающее произвольный доступ к информации
Оперативную память часто называют первичной памятью, а магнитные ленты и оптические диски — вторичной иливнешней памятью
Устойчивые хранилища обеспечивают надежное сохранение информации, размещая несколько ее копий на различных постоянных носителях (обычно на дисках), одновременный отказ которыхмаловероятен. В частности, устойчивое хранение информации может быть организовано с помощью технологии RAID, гарантирующей, что отказ отдельного дискового устройства даже в процессе передачи данных невызовет потери этих данных.
Существует множество различных типов отказов, способных повлиять на функционирование базы данных, для каждого из которых требуется особый способ устранения. При этом одни отказывлияют только на содержимое оперативной памяти, а другие — могут воздействовать и на постоянную (вторичную) память системы.
Приведем некоторые причины отказов:
•.
Чтобы читать весь документ, зарегистрируйся.
Связанные рефераты
Восстановление данных
. дефект-менеджмента). При позиционировании головок, записи и считывании данных применяются.
24 Стр. 2 Просмотры
Курсовая по предмету "БЕЗОПАСНОСТЬ БАЗ ДАННЫХ" н
. работа По дисциплине БЕЗОПАСНОСТЬ БАЗ ДАННЫХ На тему.
Восстановление данных
29 Стр. 24 Просмотры
Базы данных. Объекты базы данных.
. понятия базы данных 4 1.1 Свойства полей базы.
Читайте также: