3_Обработка транзакций в реальном масштабе времени

(OLTP - технология)

OLTP - технологии

OLTP – Online Transaction Processing, системы оперативной обработки

транзакций. Понятие транзакции необходимо для поддержания логической целостности БД. Транзакция - совокупность действий, которая должна выполняться полностью. Если транзакция успешно выполняется, то СУБД

фиксирует изменения БД, иначе выполняется откат до состояния, предшествующего транзакции. Транзакция представляет собой последовательность операторов языка SQL, которая рассматривается как неделимое действие над БД. Традиционные транзакции характеризуются 4 свойствами (ACID - Atomicity, Consistency, Isolation, Durability):

–атомарности: транзакция должна быть выполнена в целом или не выполнена вовсе.

–согласованности: по мере выполнения транзакций данные переходят из одного согласованного состояния в другое, т.е. транзакция не разрушает взаимной согласованности данных.

–изолированности: конкурирующие за доступ к БД транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.

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

Итак, транзакция:

–последовательность согласованных изменений данных и схемы БД;

–каждое логическое действие включает одну или более физических операций над БД.

Транзакция - единица работы в БД

•Команда Begin Tran[action] начинает транзакцию, все последующие команды образуют блок команд транзакции . Заканчивается транзакция командой Commit Tran[saction] или Commit Work, которая предписывает серверу зафиксировать все изменения, выполненные командами транзакции. Второй вариант - завершение транзакции командой Rollback Tran[saction] или Rollback Work,

которая заставляет сервер отменить все изменения, сделанные транзакцией. Указание Work в командах означает завершение всех транзакций.

•Сервер работает по умолчанию в режиме автоматического начала транзакций, в котором каждая команда рассматривается как транзакция, если нет явных команд определения транзакции. Этот режим устанавливается командой SET IMPLICIT_TRANSACTION OFF. Другой режим неявного начала транзакций (устанавливается командой SET IMPLICIT_TRANSACTION ON) автоматически начинает новую транзакцию, если закончена предыдущая командой фиксации или отката.

•Откат и фиксация транзакций становятся возможными благодаря журналу транзакций. При выполнении любого оператора SQL, который вносит изменения в БД, СУБД автоматически заносит очередную запись в журнал транзакций и после этого вносит изменения в БД. Если после оператора SQL был выполнен оператор Commit, то в журнале транзакций делается отметка о завершении текущей транзакции. Если же после оператора SQL следовал оператор Rollback, то СУБД просматривает журнал транзакций и отыскивает записи, отражающие состояние измененных строк до внесения изменений и восстанавливает те строки в таблицах БД, которые были изменены текущей транзакцией. Таким образом, аннулируются все изменения в БД.

Управление транзакциями

•Поддержание механизма транзакций - показатель развитости СУБД. Транзакция может быть представлена отдельной программой, являться частью алгоритма программы или отдельной командой и включать произвольное количество операций, выполняемых в БД. Одной из проблем многопользовательских СУБД является организация одновременного доступа к одним и тем же данным множества пользователей с помощью механизма транзакций (потеря изменений, незафиксированные изменения и т.п.).

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

•Незафиксированные изменения - когда в процессе выполнения транзакции одной программой в данные были внесены изменения и тут же прочитаны другой программой, однако затем в первой программе транзакция была прервана оператором Rollback, т.е. вторая программа прочитала неверные, незафиксированные данные.

•Чтение грязных данных - когда транзакция читает данные, изменяемые параллельной транзакцией. В таком случае временные, неподтвержденные данные могут не удовлетворять ограничениям целостности или правилам. И, хотя к моменту фиксации транзакции они могут быть приведены в «порядок», другая транзакция уже может воспользоваться этими неверными данными, что приведет к нарушению ее работы.

•Неповторяющиеся чтение - повторное чтение данных, которые были измены другой транзакцией между первым и вторым чтением. Повторное чтение второй транзакцией считывает другие данные. Проблема повторного чтения состоит в том, что между операциями чтения в одной транзакции другие транзакции могут беспрепятственно вносить любые изменения, так что повторное чтение тех же данные приведет к другому результату.

•Появление данных-фантомов - когда одна транзакция читает данные, а другая добавляет. Добавленные данные являются невидимыми для первой транзакции, т.е. являются "фантомами". Проблема фантомов возникает, когда выборка данных, сделанная в одной транзакции, изменяется другой транзакцией. Например, мы устанавливаем для поля F1 значение 5000 для всех записей таблицы, затем накладываем constraint (ограничение) на поле F1 сверху числом 5001, а в промежуток между этими 2-мя операциями другая транзакция вносит в таблицу запись с F1 = 5500

•Для разрешения этих проблем необходимо изолировать транзакции друг от друга. Для реализации различных уровней изоляции в SQL сервере используются блокировки (LOCKs). Блокировки –важный механизм функционирования сервера. Они применяются для каждого запроса на чтение или обновление данных, а также во многих других случаях (например, при создании новой сессии). Работой с блокировками занимается специальный модуль SQL Server’а – менеджер блокировок (Lock Manager).

Подсистема обработка транзакций СУБД
	Менеджер	Планировщик
	транзакций
	Менеджер буферов
		Менеджер
		восстановления
Менеджер	Менеджер
доступа	файлов
Менеджер
системы	База данных и системный каталог

•Менеджер транзакций осуществляет координацию работы транзакций, выполняемых прикладными программами.

•Он взаимодействует с планировщиком (менеджер блокировок), отвечающим за реализацию выбранной стратегии управления параллельностью; второе название применимо в том случае, если выбран протокол управления на основе системы блокировок. Цель работы планировщика – достижение максимально возможного уровня параллельности, при условии исключения влияния параллельно выполняющихся транзакций друг на друга, поскольку это может послужить источником нарушения согласованности базы данных. Если в процессе выполнения транзакции происходит откат, то БД может находиться в несогласованном состоянии.

•Задачей менеджера восстановления является предоставление гарантий того, что в подобном случае БД будет автоматически восстановлена в то состояние, в котором она находилась на момент начала выполнения транзакции.

•Менеджер буферов отвечает за передачу данных основной памяти компьютера и вторичной дисковой памяти.

Транзакции и целостность БД

•Если все операторы выполнены успешно и в процессе выполнения транзакции не произошло никаких сбоев программного или аппаратного обеспечения, то транзакция фиксируется.

•Фиксация транзакции (commit)- это действие, обеспечивающее запись на диск изменений в БД, которые были сделаны в ходе выполнения транзакции. До тех пор, пока транзакция не зафиксирована, можно произвести отмену всех изменений и восстановить БД в исходное, на момент начала транзакции, состояние. Если же выполнение транзакции невозможно, БД возвращается в исходное состояние.

•Откат транзакции (rollback)- это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами SQL в теле текущей незавершенной транзакции.

•Различаются два вида ограничений целостности: немедленно проверяемые и откладываемые. К немедленно проверяемым относятся ограничения целостности, проверку которых бессмысленно или невозможно откладывать (например, ограничение на возрастные рамки - более 150 лет). Они соответствуют уровню отдельных операторов языка СУБД и при их нарушении производится не откат транзакции, а отвергается определенный оператор. Откладываемые ограничения - это ограничения на БД, а не на какие-либо отдельные операции. По умолчанию они проверяются в конце транзакции, и их нарушение вызывает автоматическую замену оператора COMMIT на оператор ROLLBACK. В некоторых системах поддерживается специальный оператор насильственной поддержки ограничений целостности внутри транзакций.

Сериализация транзакций

•Во избежание искажения данных в запросах к БД требуется разработать процедуру, обеспечивающую согласованность выполнения параллельных транзакций, т.е. изолированность транзакций. Эта процедура в СУБД носит название сериализации транзакций. Для поддержки параллельной работы транзакции строится специальный план. План выполнения набора транзакций называется сериальным, если результат параллельного выполнения транзакций эквивалентен результату последовательного выполнения этих же транзакций.

•Сериализация транзакций - механизм выполнения транзакций по некоторому сериальному плану, формируемому самой СУБД. При этом:

–в процессе выполнения транзакции программа «видит» только согласованные состояния БД; пользователь никогда не может получить доступ к незафиксированным изменениям в данных, достигнутым в результате действия другой программы;

–если две транзакции А и В выполняются параллельно, то СУБД полагает, что результат будет такой же, как если бы “транзакция А” выполнялась бы первой, а за ней выполнялась другая “транзакция В”, т.е. они выполняются последовательно.

•Существует два подхода к сериализации транзакций: основанный на

синхронизационных захватах (блокировках) объектов БД, и подход, основанный на использовании временных меток (если транзакция Т1 началась раньше транзакции Т2, то система обеспечивает такой режим выполнения, как если бы Т1 была целиком выполнена да начала Т2. К недостаткам этого метода можно отнести более частные откаты транзакций, чем в случае использования синхронизационных захватов).

•Для каждого из этих подходов могут существовать пессимистические и оптимистические варианты решения: первые отличаются тем, что применяются в тех ситуациях, когда конфликты возникают часто и распознаются и разрешаются немедленно при их возникновении; вторые - основываются на том, что результаты всех операций на объектами БД сохраняются в рабочей памяти транзакций.

•Рассмотрим некоторые методы сериализации транзакций с учетом их пессимистических разновидностей. Основным механизмом достижения изолированности операций является механизм блокировок. Транзакция запрашивает захват объекта в одном из режимов: совместный (S - Shared) для операции чтения объекта или монопольный (X - eXclusive) для операций занесения, удаления и модификации. Для реляционных БД объектами захвата могут быть

–файл: несколько отношений с индексами;

–отношение (таблица);

–страница данных: несколько кортежей (записей), индексная страница;

–запись;

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