Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Аппаратные сбои обычно подразделяются на два вида:
мягкие сбои связаны с внезапной остановкой работы компьютера. Обычно являются следствием внезапного выключения питания или "зависания" операционной системы (что особенно характерно для операционных систем Windows);
жесткие сбои характеризуются потерей информации на носителях внешней памяти.
Программные сбои обычно возникают вследствие ошибок в программах. Причем эти ошибки могут быть как в самой СУБД, что может привести к аварийному завершению ее работы, так и в пользовательской программе. Первый случай можно рассматривать как разновидность мягкого аппаратного сбоя. Во втором случае незавершенной остается только одна транзакция.
В любом случае для восстановления информации в базе данных необходимо иметь некоторую дополнительную информацию. Таким образом, для поддержания надежности хранения данных требуется избыточность данных. Причем та часть информации, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений базы данных. Журнал представляет собой особую часть базы данных, недоступную пользователям СУБД и поддерживаемую с особой тщательностью (иногда используются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части базы данных. В разных СУБД изменения базы данных журнализируются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения базы данных, иногда — минимальной внутренней операции модификации страницы внешней памяти. Могут также использоваться одновременно оба подхода. Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log — WAL). Несколько утрированно можно сказать, что эта стратегия заключается в том, что запись об изменении любого объекта базы данных должна быть занесена в журнал до того, как будет выполнено и зафиксировано изменение этого объекта. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления базы данных после любого сбоя.
Самая простая ситуация восстановления — индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений базы данных. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации базы данных, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя' от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи, относящиеся к одной транзакции, связывают обратным списком (от конца к началу). При мягком сбое во внешней памяти основной части базы данных могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является приведение внешней памяти основной части базы данных в такое состояние, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того чтобы этого добиться, сначала производят откат незавершенных транзакций, а потом повторно воспроизводят те операции завершенных транзакций, результаты которых не отображены во внешней памяти.
Для восстановления базы данных после жесткого сбоя используют журнал и архивную копию базы данных. Архивная копия — это полная копия базы данных к моменту начала заполнения журнала (хотя имеется много вариантов трактовки смысла архивной копии). Для нормального восстановления базы данных после жесткого сбоя, естественно, необходимо, чтобы журнал не пропал. Тогда восстановление базы данных состоит в том, что, исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
- «Челябинский государственный педагогический университет»
- Рыжикова а.М.
- Информационные технологии содержание
- Предисловие
- Средства компьютерной и информационной техники в системе образования:
- Эволюция информационных технологий
- Вопросы
- Этапы развития информационных систем
- Области применения и примеры реализации информационных систем
- Основные компоненты автоматизированных информационных систем
- Лекция 3
- Ключевые слова
- Вопросы:
- Лекция 4
- Информационная технология как аналог технологии переработки материальных ресурсов
- Новая информационная технология
- Инструментарий информационных технологий
- Соотношения между информационной технологией и информационными системами
- Компоненты информационных технологий
- Лекция 5
- Характеристика и назначение
- Основные компоненты информационных технологий управления
- Структура управления организацией
- Персонал организации
- Прочие элементы организации
- Лекция 6
- Характеристика и назначение информационной технологии автоматизированного офиса
- Основные компоненты автоматизированного офиса
- Компьютерные конференции и телеконференции.
- Лекция 7
- Определение и понятие базы данных
- Понятие банка данных
- Преимущества банковской организации
- Компоненты банка данных
- Основные функции субд
- Управление транзакциями
- Журнализация
- Поддержка языков баз данных
- Лекция 8
- Общие сведения об интеллектуальных системах.
- Характеристика и назначение эс
- Модели представления знаний
- Логические модели
- Лекция 9
- Сетевые семантические модели
- Фреймовые модели
- Продукционные модели
- Основные компоненты эс
- Интерфейс пользователя
- База знаний
- Интерпретатор
- Модуль создания системы
- Лекция 10
- Характеристика и назначение систем поддержки решений
- Основные компоненты систем принятия решений
- База данных
- Система управления интерфейсом
- Лекция 11
- Характеристика и назначение биллинговых систем
- Структура и функции биллинговой системы
- Основные подсистемы, характерные для биллинга Подсистема предварительной обработки данных
- Подсистема оперативного управления биллингом
- Подсистема оповещения клиентов
- Стандарты биллинговых систем
- Лекция 12
- Концепции внутреннего и внешнего маркетинга - erp и crm
- Crм - управление отношениями с клиентами
- Что такое crm-система, ее функции
- Эффективность внедрения erp системы
- Основные движущие силы для начала внедрения erp системы
- Преимущества, которые дает компании erp система
- Лекция 13
- Лекция 14
- Организация взаимодействия устройств в сети
- Методы передачи данных в сетях эвм
- Протоколы в лвс
- Средства коммутации в компьютерных сетях
- Лекция 15
- Web-дизайн и браузеры
- Web-серверы
- Основные правила и этапы создания сайта
- Выбор структуры Web-страницы Создание фиксированных и гибких Web-страниц
- Лекция 16
- Роль методического обеспечения
- Содержание методического комплекса
- Общие сведения об электронных учебниках
- Лекция 17
- Появление internet
- Компоненты internet
- 8. Системы общения в реальном времени
- Узлы и клиенты
- Адрес компьютера в интернет
- Подключение к internet
- Список учебных и методических пособий Основной
- Дополнительный
- Материалы Интернет