Размещено на http://www.allbest.ru/

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

ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

МУРМАНСКОЙ ОБЛАСТИ

«МУРМАНСКИЙ ТЕХНОЛОГИЧЕСКИЙ КОЛЛЕДЖ СЕРВИСА»

РЕФЕРАТ

Защита информации базы данных

Дисциплина: Информатика

Студент: Степанова А.А Группа ГС-14

Руководитель Селиванов С.И

Преподаватель ГАПОУ МО «МТКС»

Мурманск 2017

Содержание

защита база данные файл

Введение

1. Различные виды неисправностей

1.1 Авария системы и сервера

2. Обзор алгоритмов защиты базы данных

2.1 Пример резервного копирования и восстановления

2.2 Введение в менеджер восстановления

3. Защита управляющего файла базы данных

4. Резервное копирование базы данных

4.1 Полные резервные копии

4.2 Открытые резервные копии базы данных

4.3 Закрытые резервные копии баз данных

5. Защита групп регистрации и управляющего файла

Заключение

Список источников информации

Введение

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

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

Ошибкой многих баз данных является то, что устанавливается, во-первых, достаточно простой пароль в системе, а во-вторых, он всем известен. Конечно, не стоит говорить о таких простых вещах, что пароль следует устанавливать, об этом должны знать все. Кроме того, данное правило относится абсолютно ко всем ИТ-областям.

Практика показывает, что при разработке нескольких корпоративных программ используется одна учетная запись для всех пользователей, которые используют базу данных. Кроме того, параметры ее прописываются в самой программе, а доступ к отдельным модулям, например, бухгалтерии или складу, реализуется программно. Если посмотреть с одной стороны, стоит заметить, что это достаточно удобно, поскольку есть возможность подключаться к базе на администраторских правах, что избавляет от хлопот с распределением прав и ролей. Однако если взглянуть с другой стороны, то это совсем не безопасно, так как большинство пользователей становятся все более «продвинутыми» в области интернета, да и родственники с друзьями вполне могут неплохо разбираться в безопасности. Достаточно узнать такую информацию, как пароль и имя, чтобы соединиться с базой данных для получения всей необходимой информации, а это далеко не всегда безопасно.

1. Различные виды неисправностей

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

1.1 Авария системы и сервера

Возможно, наиболее частой причиной нерабочего состояния компьютерной системы являются аварии. Авария (crash) - это неожиданный выход системы из строя. Внезапные перебои с электропитанием, ошибки программных средств и сбои в работе операционной системы неизбежно приводят к авариям. Например, ошибка операционной системы компьютера может вывести из строя фоновый процесс Oracle, что, в свою очередь приводит к аварии сервера баз данных Oracle. Обычно это называется аварией экземпляра (instance crash).

Авария экземпляра Oracle не повреждает физические структуры базы данных. Основная проблема заключается в том, что при аварии экземпляра работа оказывается напрасной и все данные, которые в момент аварии находились в памяти экземпляра с момента последней записи на диск, теряются. Например, теряется не записанная в файлы данных информация, содержащиеся в буферном кэше экземпляра.

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

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

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

Алгоритмы резервного копирования и восстановление Oracle обеспечивают абсолютную защиту и восстановление базы данных после потери файла в результате любого сбоя.

2. Обзор алгоритмов защиты базы данных

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

Регулярное и частое резервное копирование базы данных (database backup) позволяет восстанавливать файлы, потерянные в результате ошибки пользователя, повреждения файлов или сбоев диска.

Журнал транзакций (transaction log) базы данных - это группа файлов, в которые записываются изменения, внесенные завершенными транзакциями. Во время завершения транзакции Oracle записывает в журнал транзакций информацию, достаточную для повторного выполнения транзакций, если необходимо восстановить базу данных.

2.1 Пример резервного копирования и восстановления

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

- Каждый вечер выполняется резервное копирование базы данных. Помимо других файлов, в состав каждой резервной копии базы данных входит резервная копия всех файлов базы данных.

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

- Сначала выясняется причина аварии. К сожалению, произошел серьезный сбой диска, и надо заменить поврежденный дисковод на новый.

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

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

- После восстановления базы данных открывается и становится доступна для приложений.

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

2.2 Введение в менеджер восстановления

Алгоритмы резервного копирования и восстановления, применявшиеся в прежних версиях Oracle, работают и в Orac1e8. Однако менеджер восстановлений намного упрощает и автоматизирует этот процесс, автоматически отслеживая информацию о резервном копировании в каталоге восстановления. Каталог восстановления (recovery catalog) - это группа таблиц и представлений базы данных, используемая менеджером восстановлений для записи информации о каждой резервной копии. Менеджер восстановлений использует информацию, хранящуюся в этом каталоге, для восстановления поврежденной базы данных с имеющихся в наличии резервных копий.

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

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

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

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

3. Защита управляющего файла базы данных

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

Для защиты управляющего файла и всей базы данных от неприятностей, связанных со сбоями дисков, следует всегда зеркально отображать управляющей файл точно так же, как это делается с группами регистрации оперативного журнала транзакций базы данных. При зеркальном отображении управляющего файла Oracle одновременно обновляет каждую копию этого файла. Если неприятности с дисковым вводом/выводом приводят к тому, что одна копия управляющего файла стала недоступной, другие копии останутся в рабочем состоянии и позволяет без перерыва продолжить обработку информации базы данных.

4. Резервное копирование базы данных

Резервные копии являются важным элементом всеобъемлющей стратегии защиты базы данных. Резервная копия базы данных (database backup) - это резервная копия всех файлов, составляющих базу данных. Если повреждается или теряется файл, являющийся частью базы данных, из резервной копии можно извлечь копию этого файла и восстановить его в базе данных.

Чтобы выполнить резервное копирование базы данных Orac1e8, можно использовать менеджер восстановлений или графический пользовательский интерфейс для менеджера восстановлений, например менеджер управления серверами/менеджер копирования. Менеджер восстановлений содержит множество различных опций, используемых для резервного копирования базы данных Oracle.

4.1 Полные резервные копии

Резервная копия базы данных (database backup), или полная резервная копия базы данных (whole database backup) содержит копии всех файлов данных и управляющего файла базы данных. Резервные копии баз данных - самый распространенный тип резервных копий, который применяется для защиты баз данных Oracle. В Oracle можно создавать два вида резервных копий баз данных: открытые и закрытые.

4.2 Открытые резервные копии базы данных

Открытая резервная копия базы данных (open database backup), называемая также «горячей» резервной копией (hot database backup), - это резервная копия, которая выполняется в тот момент, когда база данных открыта и работает. Открытые резервные копии полезны в системах, где оно или несколько приложений требует высокой степени доступности базы данных. Открытое резервное копирование можно выполнять только в том случае, когда работа с базой данных происходит в режиме разрешенного восстановления носителей.

Информация, содержащаяся в файлах данных открытой резервной копии базы данных, модифицируется транзакциями на протяжении всего процесса резервного копирования, поэтому говорят, что резервная копия является несогласованной, или нечеткой. Другими словами, не существует какого-то момента согласованности транзакций, с которым соотносятся все блоки данных. После восстановления файла данных из несогласованной резервной копии базы данных алгоритм восстановления Oracle воссоздает неучтенные транзакции так, что все блоки данных в этом файле устанавливаются в состояние согласования транзакций и соответствуют всем другим блокам базы данных.

4.3 Закрытые резервные копии баз данных

Закрытая резервная копия базы данных (closed database backup) - это резервная копия, которая выполняется после запланированной остановки базы данных. Закрытые резервные копии годятся для систем, в которых высокая степень доступности базы данных не является решающем условием. Закрытая резервная копия является единственным вариантом для баз данных, которые работают без разрешенного восстановления носителей.

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

5. Защита групп регистрации и управляющего файла

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

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

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

Заключение

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

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

Список источников информации

1. Дейт, К., Дж. Введение в системы баз данных. 6-е изд. К.; М., СПб.: «Вильямс», 2000. 848 с.

2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений/Под ред. проф. А.Д. Хомоненко. СПб.: КОРОНА принт, 2002. 672 с.

3. В.В. Корнеев, А.Ф. Гареев, С.В. Васютин, В.В. Райх Базы данных. Интеллектуальная обработка информации. М.: Нолидж, 2001. 496 с.

Размещено на Allbest.ru