Журнализация изменений бд реферат

Обновлено: 03.07.2024

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее состояние БД после любого аппаратного или программного сбоя (аварийное выключение питания, аварийное завершение работы СУБД или аварийное завершение пользовательской программы). Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Наиболее распространенным методом поддержания надежности хранения является ведение журнала изменений БД.

Журнал – это особая часть БД, недоступная пользователям и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. Изменения БД журнализуются следующим образом: запись в журнале соответствует некоторой операции изменения БД (например, операции удаления строки из таблицы реляционной БД). С помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

6. Поддержка языков БД

СУБД включает язык определения данных, с помощью которого можно определить структуру базы, тип данных в ней, указать ограничения целостности (это язык, с помощью которого задаются различные имена, свойства объектов). Кроме того, СУБД позволяет вставлять, удалять, обновлять и извлекать информацию из базы данных посредством языка управления данными – языка запросов, который позволяет выполнять различные действия с данными, осуществлять их поиск и выборку. Он содержит набор различных операторов (заносить данные, удалять, модифицировать, выбирать и т.д.). Процесс извлечения данных и их обработка скрыты от пользователя.

Стандартным языком наиболее распространенных в настоящее время СУБД является язык SQL (Structured Query Language). Он имеет сразу два компонента: язык определения данных и язык управления данными. Кроме того, одним из языков управления данными является язык QBE – язык запросов по образцу. Подробно о реализаций функций СУБД с помощью языка SQL будет рассказано на отдельных лекциях, посвященных языку SQL.

1. По степени универсальности все СУБД делятся на СУБД общего назначения и специализированные СУБД. СУБД общего назначения не ориентируются на информационные потребности конкретной группы пользователей. Они могут быть использованы для создания и использования баз данных в любой предметной области (документоведение, образование, риэлтерская деятельность и т.д.). К ним относят MS Access, MS FoxPro. Однако в некоторых случаях доступные СУБД общего назначения не позволяют добиться требуемых результатов. С этой целью используют специализированные СУБД, которые позволяют осуществить работу с данными, описывающими информационные потребности узкого круга пользователе. К таким СУБД можно отнести Lotus.

2. По функциональности все СУБД делятся на полнофункциональные СУБД, серверы баз данных, клиенты баз данных.Полнофункциональные СУБД представляют собой традиционные СУБД, которые изначально создавались для больших ЭВМ, затем для ПЭВМ. Они являются наиболее многочисленными и мощными по своим возможностям. К ним относят MS Access, MS FoxPro, Paradox, dBase IV. Такие СУБД имеют развитый интерфейс, для создания отчетов и запросов используются мастера. Многие СУБД имеют встроенные языки программирования для профессиональных разработчиков. Серверы БД предназначены для организации центров обработки данных в локальной (или глобальной) сети. Они обладают скудным интерфейсом, однако их основное назначение – организация хранения баз данных удаленных пользователей, защита данных от несанкционированного доступа, ограничение доступа к данным, возможность одновременной работы с базой нескольким пользователям. Данная группа менее многочисленна, однако их количество постоянно растет за счет того, что сегодня практически в любой организации, на любом предприятии все компьютеры соединяются в локальную сеть. Следовательно возникает необходимость организации централизованного хранения базы и создания удаленного многопользовательского доступа к ней. Примером такой СУБД является СУБД MS SQL Server. В роли клиентов баз данных могут использоваться любые полнофункциональные СУБД. здесь их роль сводится к тому, чтобы обеспечить доступ к данным, их просмотр, поиск и выборку.

3. По характеру использования СУБД делят на персональные и многопользовательские.

Персональные СУБД обычно обеспечивают возможность создания персональных баз данных. Такие СУБД могут выступать в роли клиентов БД. К ним относят MS Access, MS FoxPro, Paradox, Clipper. Многопользовательские СУБД включают в себя сервер базы данных и клиентскую часть, могут работать в с различными операционными системами, с различными типами ЭВМ. К таким СУБд относят Oracle, Informix.

Компоненты среды СУБД

В СУБД можно выделить несколько основных компонентов: данные, пользователи, аппаратное обеспечение, программное обеспечение, процедуры.

Данные являются наиболее важным компонентом.

Для хранения данных и функционирования базы необходимо аппаратное обеспечение – набор физических устройств (ПК, сеть), на которых существует база и СУБД.

Для того, чтобы можно было работать с данными, кроме аппаратного обеспечения необходимо иметь операционную систему, сетевое программное обеспечение, программное обеспечение самой СУБД и прикладные программы-приложения. Прикладные программы пишутся программистами на одном из языков высокого уровня (Pascal, C, VB) для нужд конкретной организации. Такие программы используют средства СУБД для обращения к данным в базе и их обработки, создавая различные свойственные данной организации формы, отчеты.

Среди пользователей базой данной можно выделить 4 категории лиц: администраторы данных, администраторы баз данных, разработчики баз данных, непосредственно сами пользователи.

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

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

Разработчики баз данных – категория лиц, которые работают с ней только в процессе ее разработки по проекту, созданному администратором данных.

Пользователи – это конечные пользователи, ради которых база проектировалась, создавалась и будет работать. Их часто называют клиентами.

СУБД является достаточно сложным видом программного обеспечения, поэтому в составе СУБД можно выделить ряд программных компонентов:

– ядро СУБД, которое отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, транзакциями, журнализацию. Это главная часть СУБД. Ядро обладает собственным интерфейсом, недоступным пользователю напрямую.

– компилятор языка БД (обычно SQL), предназначенный для работы с данными.

Лекция 2. Модели данных

Основными информационными единицами являются сегмент, поле дерево. Поле данных – наименьшая неделимая поименованная информационная единица, сегмент (запись) образуется из конкретных значений полей данных, тип записи – набор взаимосвязанных сегментов одного уровня, дерево – набор записей данного типа (таблица).

Между типами записи поддерживаются связи.

База данных с такой схемой могла бы выглядеть следующим образом:

Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие:

· Найти указанное дерево БД (например, отдел 310);

· Перейти от одного дерева к другому;

· Перейти от одной записи к другой внутри дерева (например, от отдела - к первому сотруднику);

· Перейти от одной записи к другой в порядке обхода иерархии;

· Вставить новую запись в указанную позицию;

· Удалить текущую запись.

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

Целостность связи поддерживается между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя.

Кроме того, иерархическая модель обладает следующими свойствами:

Раздел: Информатика, программирование
Количество знаков с пробелами: 237727
Количество таблиц: 39
Количество изображений: 0

Название работы: Журнализация изменений БД, файл журнала, контрольные точки

Предметная область: Информатика, кибернетика и программирование

Описание: Это требование предполагает возможность восстановления согласованного состояния базы данных после любого программного или аппаратного сбоя. Типичная СУБД должна предоставлять такие функции восстановления как: механизм резервного копирования предназначенный для периодического создания копий базы данных; средства ведения журнала в котором фиксируются текущее состояние транзакций и вносимые в базы данных изменения; функция создания контрольных точек обеспечивающая перенос выполняемых в базе данных изменений во вторичную помять с целью.

Дата добавления: 2013-09-21

Размер файла: 31.5 KB

Работу скачали: 35 чел.

Журнализация изменений БД, файл журнала, контрольные точки

Журнализация изменений базы данных

Одним из основных требований к развитым СУБД является надежность хранения баз данных. Это требование предполагает возможность восстановления согласованного состояния базы данных после любого программного или аппаратного сбоя.

Типичная СУБД должна предоставлять такие функции восстановления, как:

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

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

Индивидуальный откат транзакции . Типичной ситуацией отката транзакции является ее завершением оператором ROLLBACK ; откат транзакции может быть инициирован системой. Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.
Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Возникновение ситуации в случае выключение электрического питания, при возникновении неустранимого сбоя процессора. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти.
Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация в современных условиях при высокой надежности устройств внешней памяти может встретиться крайне редко, но все-таки СУБД должна быть в состоянии восстановить базу данных и в этом случае. Основа восстановления - архивная копия и журнал изменений базы данных.

Для восстановления прои 1 и 2 типов сбоев используется файл журнала, при жестком сбое (тип 3) архивирование б/д.

Для выполнения восстановления необходима дополнительная информация. В современных реляционных СУБД такая информация поддерживается в виде журнала изменений базы данных.

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

результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;

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

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

Основой восстановления является избыточное хранение данных; эти данные хранятся в журнале, содержащем последовательность записей об изменении базы данных. Возможно два варианта ведения журнальной информации:

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

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

Контрольные точки организуются через установленный временной интервал и включают выполнение следующих действий:

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

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

Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.

Индивидуальный откат транзакции. Тривиальной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK. Возможны также ситуации, когда откат транзакции инициируется системой. Примерами могут быть возникновение исключительной ситуации в прикладной программе (например, деление на ноль) или выбор транзакции в качестве жертвы при обнаружении синхронизационного тупика. Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.
Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть при аварийном выключении электрического питания, при возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т.д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти.
Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее, СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.

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

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

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

Итак, общей целью журнализации изменений баз данных является обеспечение возможности восстановления согласованного состояния базы данных после любого сбоя. Поскольку основой поддержания целостного состояния базы данных является механизм транзакций, журнализация и восстановление тесно связаны с понятием транзакции. Общими принципами восстановления являются: Этот подход позволяет быстро выполнять… Читать ещё >

Журнализация изменений баз данных ( реферат , курсовая , диплом , контрольная )

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

• результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;
• результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.

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

Читайте также: