Транзакции

1. Транзакции

2. Транзакция - это последовательность операций, производимых над базой данных и переводящих базу данных из одного непротиворечивого (согласованного) состояния в другое непротиворечивое (согласованное) состояние.

3. Транзакция • некоторое неделимое действие над базой данных, осмысленное с точки зрения пользователя • логическая единица работы системы

4. Свойства транзакций • Свойство атомарности (Atomicity) • Свойство согласованности (Consistency) • Свойство изолированности (Isolation) • Свойство долговечности (Durability)

5. Свойства транзакций • Свойство атомарности (Atomicity) выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе. • Свойство согласованности (Consistency) гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое — транзакция не разрушает взаимной согласованности данных. • Свойство изолированности (Isolation) означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно. • Свойство долговечности (Durability) трактуется следующим образом: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах (даже в случае последующих ошибок).

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

7. Consistency • Свойство согласованности гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое — транзакция не разрушает взаимной согласованности данных. • Для поддержания согласованности данных в процессе транзакции применяются все правила, проверки, ограничения и триггеры.

8. Isolation • Свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.

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

10. Пример T1 T2 Read (A); A:=A+1; Write (A). Read (A); A:=A+1; Write (A).

11. Решение T1 T2 Lock(A); Read (A); A:=A+1; Write (A); Unlock(A). Lock(A); Read (A); A:=A+1; Write (A); Unlock(A).

12. Проблемы: Решения: Установить очередь, возможно с приоритетами Две фазы: установка и снятие блокировок Установить порядок Периодически проверять на тупики и рестарт • Бесконечные ожидания • Тупики

13. Виды блокировок • Блокировка на чтениеRlock(A) • Блокировка на запись Wlock(A) • Снятие всех блокировок • Unlock (A)

14. Варианты завершения транзакции • Фиксация • Откат транзакции

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

16. Фиксация транзакции • До фиксации допустимо восстановление базы данных в то состояние, в котором она была на момент начала транзакции. • Фиксация транзакции означает, что все результаты выполнения транзакции становятся постоянными. • Они станут видимыми другим транзакциям только после того, как текущая транзакция будет зафиксирована. До этого момента все данные, затрагиваемые транзакцией, будут "видны" пользователю в состоянии на начало текущей транзакции.

17. Откат транзакции • Если в процессе выполнения транзакции случилось нечто такое, что делает невозможным ее нормальное завершение, база данных должна быть возвращена в исходное состояние. • Откат транзакции — это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны в теле текущей незавершенной транзакции.

18. Модель транзакций

19. Команды для управления транзакциями: • BEGIN – начало транзакции; • COMMIT – для сохранения изменений; • ROLLBACK – для отмены изменений; • SAVEPOINT – для установки особых точек возврата.

20. Модель транзакций • оператор COMMIT означает успешное завершение транзакции; его использование делает постоянными изменения, внесенные в базу данных в рамках текущей транзакции; • оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в базе данных в рамках этой транзакции; новая транзакция начинается непосредственно после использования ROLLBACK; • успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор COMMIT); • ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).

21. Журнал транзакций • сохранение промежуточных состояний, • подтверждение транзакции, • отката транзакции

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

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

24. Альтернативные варианты ведения журнала транзакций: • Протокол с отложенными обновлениями • Протокол с немедленными обновлениями.

25. Журнала по принципу отложенных изменений : • Когда транзакция Т1 начинается, в протокол заносится запись <Т1 Begintransaction> • Для каждой изменяемой записи записывается новое значение: <T1,ID_RECORD, атрибут, новое значение … >. ID_RECORD — уникальный номер записи. • Если все действия выполнены, то транзакция фиксируется и в протокол заносится <Т1 COMMIT>. • После того как транзакция фиксирована, записи протокола, относящиеся к T1, используются для внесения соответствующих изменений в БД.

26. Журнала по принципу отложенных изменений : • Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Транзакцию Т1 необходимо переделать, если протокол содержит обе записи <T1 BEGIN TRANSACTION> и <T1 COMMIT>. • Все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется системная процедура REDO(), которая заменяет все значения элементов данных на новые, просматривая протокол в прямом порядке. • Если в протоколе не содержится команда фиксации транзакции COMMIT, то никаких действий проводить не требуется, а транзакция запускается заново.

27. Журнала по принципу немедленных изменений : • Все изменения сразу заносятся в БД; • В протокол заносятся не только новые, но и все старые значения изменяемых атрибутов: <Т1, IDRECORD, атрибут, новое зн., старое зн. …>. • При этом запись в журнал предшествует непосредственному выполнению операции над БД. • Когда встречается команда <T1 COMMIT>, то все изменения оказываются уже внесенными в БД. • При откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции, начиная с команды BEGIN TRANSACTION.

28. Журнала по принципу немедленных изменений : • Если транзакция содержит команду начала транзакции, но не содержит команды фиксации с подтверждением ее выполнения, то выполняется последовательность действий как при откате транзакции, то есть восстанавливаются старые значения. • Если сбой произошел после выполнения последней команды изменения БД, но до выполнения команды фиксации, то команда фиксации выполняется, а с БД никаких изменений не происходит. Работа происходит только на уровне протокола.

29. Блокировка таблиц • LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} • [, tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} ...] • ... • UNLOCK TABLES

30. Блокировка таблиц • READ - только читаем – можно сразу нескольким • READ LOCAL – читаем и вставляем – также нескольким • WRITE - читаем, изменяем, вставляем, удаляем – только одному • LOW PRIORITY WRITE - читаем, изменяем, вставляем, удаляем – только одному, но пропускаем тех, кто только читает

31. Уровни изолированности SET TRANSACTION IZOLATION LEVEL [{SERIALIZABLE | REPEATABLE READ | READ COMMITED | READ UNCOMMITED}] [{READ WRITE | READ ONLY }] READ WRITE READ ONLY • SERIALIZABLE • REPEATABLE READ • READ COMMITED • READ UNCOMMITED

32. READ UNCOMMITTEDГрязное чтение • Не использует или не проверяет наличие блокировок при чтении данных. • Следовательно, на этом уровне изоляции возможно чтение незафиксированных данных. • Допустимы только операции чтения в транзакции, поэтому в этом случае нельзя установить операции READ WRITE

33. READ COMMITTEDчтение зафиксированных данных • Читает только зафиксированные данные и ожидает снятия монопольной блокировки другой транзакцией. • Разделяемые блокировки, используемые для чтения данных, снимаются сразу после завершения операции чтения. • Уровень изоляции по умолчанию. • Транзакция не может обновлять строку, обновленную другой транзакцией.

34. REPEATABLE READ повторяющееся чтение • Читает данные так же, как уровень READ COMMITTED, но удерживает разделяемую блокировку до окончания транзакции.

35. SERIALIZABLE упорядочиваемое чтение • аналогично уровню REPEATABLE READ. Этот уровень блокирует не только вовлеченные данные, но и весь диапазон данных. Это не допускает вставки новых данных в диапазон, используемый в запросе, что могло бы привести к фантомному чтению