9.2. Надежное хранение данных

Транзакции применяются для надёжного хранения данных.

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

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

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

Т. е. восстанавливается последнее по времени согласованное состояние БД.

Случаи, при которых следует производить восстановление состояния БД:

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

• Rollback

• Авария

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

Восстановление после внезапной потери ОЗУ (мягкий сбой) – теряются данные, содержащиеся в буферах ОЗУ – восстановление данных по ЖТ на дисках

• Выключение электропитания

• Неустранимый сбой процессора

Восстановление после сбоя дисков (жесткий сбой) – архивная копия и журнал транзакций –

Копирование БД из архивной копии

По ЖТ в прямом направлении все операции выполняются

Для транзакций, не закончившихся к моменту сбоя - откат

Локальные ЖТ – для индивидуальных откатов (виртуальная память), общий ЖТ – мягкие и жесткие сбои.

Но может быть только общий ЖТ.

ЖТ – последовательный файл – каждое изменение БД

№ Транз, знач. атрибутов

Протокол с отложенными изменениями begin, (T, ID, attr, Value), …Commit – сначала протокол, потом все изменения

Протокол с немедленными изменениями begin, (T, ID, attr, Old, New), …Commit – сначала запись в ЖТ, после в БД.

При Commit – больше ничего не надо, при Rollback – UNDO – начиная с begin.

9.3. Параллельное выполнение транзакций

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

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

9.3.1. Коллизия “пропавшие изменения” - lost update problem

Э та проблема проявляется, когда две транзакции изменяют одну запись одновременно.

Это возможно, когда приложение, в котором выполняется транзакция 1, изменяет запись, уже измененную приложением, в котором выполняется транзакция 2.

9.3.2. Коллизия “промежуточные данные” - dirty read

Одна транзакция “видит” промежуточные, незафиксированные результаты работы другой транзакции. Приложение, в котором выполняется транзакция 2, “видит” изменения в записи, уже измененной приложением, в котором выполняется транзакция 1.