Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Вопрос № 58
Транзакционная целостность. Основные свойства транзакций (ACID). Технологии протоколирования (режимы undo, redo, undo/redo). Управление параллельными заданиями - последовательные расписания и механизмы блокирования (пессимистические и оптимистические стратегии).
На доске:
1)
|
UNDO |
REDO |
|
|
протоколирование |
заносятся прежние значения элементов |
-//- новые значения |
|
процесс восстановления данных |
устраняются изменения, внесенные незавершенными транзакциями игнорируются результаты зафиксированных транзакций |
игнорируются незавершенные транзакции итоги выполнения зафиксированных транзакций воспроизводятся вновь |
|
сохранение изменений БД на диске |
до момента "сброса" в дисковую копию протокола записи <commit Т> |
<commit Т> появится на диске прежде, чем будут сохранены любые |
|
Недостатки |
увеличение количества требуемых операций дискового ввода-вывода |
увеличение количества буферов, используемых транзакциями в процессе работы |
2)
3)
4)
Устно:
Транзакция - группа последовательных операций, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще и тогда она не должна произвести никакого эффекта.
Atomicity — Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной.
Consistency — Согласованность
В соответствии с этим требованием, система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции.
Isolation — Изоляция
Во время выполнения транзакции другие процессы не должны видеть данные в промежуточном состоянии.
Durability — Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу.
1)Режим отмены (undo logging)
В протоколе сохраняются только прежние значения изменяемых элементов базы данных.
При восстановлении воссоздаются прежние значения элементов, измененных всеми незавершенными транзакциями.
Правила протоколирования в режиме "undo"
U1: Если транзакция Т модифицирует элемент X базы данных, запись обновления вида <Т, X, v> должна быть занесена в протокол до сохранения нового значения элемента X на диске.
U2: При фиксации результатов транзакции Т запись <commit Т> следует помещать в протокол только после "сбрасывания" всех измененных значений элементов базы данных на диск, а интервал между дисковыми операциями сохранения данных и записи <commit Т> должен быть настолько коротким, насколько это возможно.
Режим повтора (redo logging)
В протоколе сохраняются только новые значения изменяемых элементов базы данных.
Результат отображается на диске после сохранения соответствующих записей обновления и фиксации
Правила протоколирования в режиме «redo»
R1: (правило опережающего протоколирования (write-ahead logging rule).
Прежде чем транзакция Т сможет модифицировать элемент X бд на диске, необходимо внести в копию протокола на диске все записи, имеющие отношение к операции модификации X, включая запись обновления вида <Т, X, v> и запись фиксации <commit Т>.
до тех пор, пока в журнал не включена запись <commit Т> никакие изменения, внесенные транзакцией Т, не будут отображены в дисковой копии содержимого БД.
Режим отмены/повтора (undo/redo logging)
В протоколе фиксируются одновременно "старые" и "новые" значения элементов базы данных.
Запись протокола, подтверждающая изменение, должна сохраняться на диске прежде, чем порция измененных данных.
Правила протоколирования в режиме «undo/redo»
UR1: Прежде чем транзакция Т сможет модифицировать элемент X базы данных на диске, необходимо внести в копию протокола на диске соответствующую запись обновления <T, X, v, w>.
UR2: Запись <commit. . .> после внесения ее в протокол должна "сбрасываться" на диск незамедлительно
- Журнал увеличивается в размерах намного быстрее, чем база данных
2)Управление параллельными заданиями
Планировщик заданий (scheduler) – выполняет функции упорядочения операций транзакций
Управление параллельными заданиями (concurrency control) - сохранение свойства согласованности состояния базы данных при одновременном выполнении многих транзакций
Расписания (schedules) - описывают очередность действий транзакций
Расписание (schedule) — это упорядоченная во времени последовательность значимых действий, предпринимаемых в процессе выполнения одной или нескольких транзакций.
Последовательное упорядочение с учетом конфликтов (conflict-serializability) - гарантия, что некие транзакции действуют в условно-последовательной манере.
Конфликт (conflict): пара последовательных действий в некотором расписании считается конфликтной, если изменение взаимного порядка их выполнения оказывает влияние на поведение по меньшей мере одной из транзакций, к которым относятся эти действия.
Два расписания являются конфликтно-эквивалентными (conflict-equivalent), если они допускают возможность взаимного преобразования посредством выполнения ряда операций перестановки смежных неконфликтных действий.
Расписание называют условно-последовательным с учетом конфликтов (conflict-serializable), если оно конфликтно-эквивалентно некоторому последовательному расписанию.
3)Последовательные расписания и механизмы блокирования
Планировщик заданий
предотвращение возможности осуществления действий в таком порядке, который не отвечает условно-последовательному
Механизм блокирования (locking)
архитектура управления параллельными заданиями с целью препятствования непоследовательному выполнению действий транзакций
4)Блокирование
Цель - получения условно-последовательного расписаний ( с учетом конфликтов)
Наряду с операциями чтения/записи значений элементов данных нужно направлять запросы на захват и освобождение блокировок.
Блокировка элемента, удерживаемая одной транзакцией, препятствует возможности единовременного обращения к нему со стороны других транзакций.
Согласованность транзакций
1) транзакция имеет право осуществить чтение или запись содержимого элемента, если прежде она запросила блокировку этого элемента и блокировка еще не освобождена;
2) если транзакция выполняет блокирование элемента, позже блокировка должна быть непременно снята.
Корректность расписаний
Блокировки должны использоваться по прямому назначению и в соответствии с присущей им исходной семантикой: никакие две транзакции не имеют права блокировать один и тот же элемент без предварительного освобождения блокировки, установленной одной из транзакций.
планировщик заданий снабжает каждую транзакцию Т уникальным идентификатором — хронологическим признаком (timestamp), TS(T).
TS генерируются в возрастающем порядке в моменты времени, когда каждая транзакция впервые уведомляет о начале своей работы.
Методы получения значений:
с использованием системных часов;
с помощью ведения внутреннего счетчика транзакций
При использовании схем блокирования транзакции часто приостанавливаются, но редко откатываются — даже если степень взаимного влияния транзакций высока.
Механизмы хронометража и проверки достоверности, не приостанавливают работу транзакций, но способны провоцировать их откат (излишние расходы системных ресурсов).
Если уровень взаимодействия транзакций невысок, ни схема хронометража, ни механизм проверки достоверности действий транзакций не приводят к частым откатам транзакций
Схема хронометража позволяет выявить некоторые возможные проблемы на более ранней стадии (нежели механизм проверки)