- •1. Режимы работы с базой данных
- •2. Технология com (Component Object Model)
- •3. Модели «клиент-сервер» в технологии баз данных.
- •4. Основные принципы функционирования com (Component Object Model)
- •5. Модель файлового сервера.
- •6. Параллельное выполнение транзакций. Основные проблемы.
- •7. Модель удаленного доступа к данным.
- •8. Уровни изолированности пользователей.
- •9. Гранулированные синхронизационные захваты.
- •10. Модель сервера приложений.
- •11. Создание объекта и работа с объектом в технологии com (Component Object Model)
- •12. Модель сервера баз данных.
- •13. Интерфейсы технологии com (Component Object Model)
- •14. Типы параллелизма (Пути распараллеливания запросов).
- •15. Сервер com (Component Object Model).
- •16. Модели транзакций.
- •17. Технология mts (Microsoft Transaction Server).
- •18. Локальные базы данных
- •19. Технология ado (Microsoft ActiveX Object).
- •20. Способы завершения транзакций.
- •21. Архитектура «клиент-сервер». Двухзвенная структура.
- •22. Технология midas (Multitier Distributed Applications Server).
- •23. Архитектура «файл-сервер».
- •24. Журнализация и буферизация.
- •25. Архитектура «клиент-сервер». Трехзвенная структура.
- •26. Индивидуальный откат транзакций.
- •27. Технология corba ( Common Object Request Broker Architecture).
- •28. Объект corba ( Common Object Request Broker Architecture).
- •29. Службы corba (Common Object Request Broker Architecture) и их взаимодействие.
- •30. Библиотека сом.
- •31. Фабрика класса сом.
24. Журнализация и буферизация.
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью, в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД, иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (WAL). Эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД.
Журнализация изменений тесно связана с буферизацией страниц базы данных в оперативной памяти. По причинам объективно существующей разницы в скорости работы процессоров и оперативной памяти и устройств внешней памяти буферизация страниц базы данных в оперативной памяти - единственный реальный способ достижения удовлетворительной эффективности СУБД. Записи в журнал буферизуются: при нормальной работе очередная страница выталкивается во внешнюю память журнала только при полном заполнении записями.
Имеются два вида буферов - буфер журнала и буфер страниц оперативной памяти, которые содержат связанную информацию. И те, и другие буфера могут выталкиваться во внешнюю память. Проблема состоит в выработке некоторой общей политики выталкивания, которая обеспечивала бы возможности восстановления состояния базы данных после сбоев.
Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных (WAL).
Дополнительное условие на выталкивание буферов накладывается тем требованием, что каждая успешно завершившаяся транзакция должна быть реально зафиксирована во внешней памяти. Какой бы сбой не произошел, система должна быть в состоянии восстановить состояние базы данных, содержащее результаты всех зафиксированных к моменту сбоя транзакций.
Минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является выталкивание при фиксации транзакции во внешнюю память журнала всех записей об изменении базы данных этой транзакцией. При этом последней записью в журнал, производимой от имени данной транзакции, является специальная запись о конце транзакции.