Слайд 1Уровни изоляции транзакций
Графеева Н.Г.
2015
Слайд 2Свойства транзакций (ACID)
Неделимость (Atomicity). Транзакция либо выполняется полностью, либо не
выполняется.
Согласованность (Consistency). Транзакция переводит базу данных из одного согласованного состояния
в другое.
Изолированность (Isolation). Результаты транзакции становятся доступны для других транзакций только после ее фиксации.
Продолжительность (Durability). После фиксации транзакции изменения становятся постоянными.
Примечание: однако за свойством изолированности в действительности стоят весьма различающиеся понятия. Различаются, так называемые, уровни изоляции транзакций.
Слайд 3 Понятия, используемые для определения уровней изолированности транзакций
• Грязное чтение
(dirty read). Допускается чтение незафиксированных, или "грязных", данных. При этом
нарушается как целостность данных, так и требования внешнего ключа, а требования уникальности игнорируются.
• Неповторяемость при чтении (non-repeatable read). Это означает, что если строка читается в момент времени T1, а затем перечитывается в момент времени T2, то за этот период она может измениться. Строка может исчезнуть, может быть обновлена и т.д.
• Чтение фантомов (phantom read). Это означает, что если выполнить запрос в момент времени T1, а затем выполнить его повторно в момент времени Т2, в базе данных могут появиться дополнительные строки. От неповторяемости при чтении это явление отличается тем, что прочитанные данные не изменились, но критериям запроса стало удовлетворять больше данных, чем прежде.
Слайд 4Уровни изолированности транзакций (стандарт SQL92)
Слайд 5
В большинстве промышленных СУБД по умолчанию поддерживается уровень READ
COMMITTED!!!!
Слайд 6Механизмы поддержки уровней изолированностей
Блокировка данных
Многоверсионность данных
Слайд 7Механизм блокировки данных
В основе механизма – использование двух видов
замков на уровне записей:
SHARE-LOCK
EXCLUSIVE-LOCK
Записям, которые программа читает, приписывается по умолчанию
замок SHARE-LOCK (при этом другие пользователи не могут изменить эту запись, но могут читать). Записям, которые программа изменяет, приписывается по умолчанию замок EXCLUSIVE-LOCK (другие не могут даже читать). Записи могут быть прочитаны и без замка (если явно указать NO-LOCK).
Замки снимаются по окончании транзакции.
Слайд 83 режима работы с данными
с замком EXCLUSIVE-LOCK — режим EXCLUSIVE-LOCK
с замком SHARE-LOCK — режим SHARE-LOCK
без
учета замков — режим NO-LOCK
Слайд 12Действия пользователей
Первый пользователь выполняет запрос:
select sum(account_balance) from accounts;
Второй
пользователь выполняет транзакцию, переводящую 400 $ со счета 123 на
счет 456 (в тот момент времени, когда первый пользователь прочитал строку 2, но еще не прочитал остальные).
Как будет получен очевидный результат результат – 1250?
Слайд 13Сценарий 1(исполнение транзакции с уровнем изоляции REPEATABLE READ на основе
блокировок)
Слайд 14Сценарий 2 (исполнение транзакции с уровнем изоляции REPEATABLE READ на
основе многоверсионности данных)
Слайд 15Взаимные блокировки пользователей
Разделяемые блокировки могут не только снижать возможности параллельного
доступа, но и приводить и к более трагическим последствиям –
взаимным блокировкам.
Слайд 16Действия пользователей
Первый пользователь выполняет запрос:
select sum(account_balance) from accounts;
Второй
пользователь выполняет транзакцию, переводящую 400 $ со счета 345 на
счет 234 (в тот момент времени, когда первый пользователь прочитал строку 2, но еще не прочитал остальные).
Слайд 17Сценарий 3(возникновение взаимной блокировки во время исполнения транзакции REPEATABLE READ
на основе блокировок)
Слайд 18Сценарий 4 (взаимная блокировка после чтения и попытки редактирования)
Слайд 19Как разрешается проблема взаимной блокировки?
В различных СУБД по разному.
Как правило ищется жертва…
Слайд 20Уровень изолированности SERIALIZABLE
Этот уровень изолированности транзакции обычно считают наиболее сильным,
именно он обеспечивает самую высокую степень изолированности. Транзакция с уровнем
изолированности SERIALIZABLE работает в среде, где как бы нет других пользователей, изменяющих данные в базе данных; база данных "замораживается" на момент начала транзакции. Побочные эффекты (изменения) от других транзакций для такой транзакции невидимы, независимо от того, как долго она выполняется. Такой уровень изолированности нужно задавать явным образом.
Слайд 21Пример (ORACLE. Cоздание транзакции уровня SERIALIZABLE )
create table a (x
int) ;
create table b (x int) ;
Слайд 23Пример (продолжение)
Результат – две таблицы с значениями 0 и 0.
Если бы не выполнялась команда
alter session
set isolation_level=serializable
результат
был бы – 0 и 1.
Слайд 24Внешние ключи и взаимные блокировки
В Oracle также
возникают взаимные блокировки. Основной причиной их возникновения являются неиндексированные внешние
ключи. При изменении главной таблицы сервер Oracle полностью блокирует подчиненную таблицу в двух случаях:
при изменении первичного ключа в главной таблице подчиненная таблица блокируется (при отсутствии индекса по внешнему ключу);
при удалении строки в главной таблице подчиненная таблица также полностью блокируется (при отсутствии индекса по внешнему ключу).
Слайд 28Когда индекс по внешнему ключу не нужен?
не удаляются строки из
главной таблицы;
не изменяется значение уникального/первичного ключа главной таблицы;
не выполняется соединение
главной и подчиненной таблиц
А так практически не бывает…..
Слайд 29Домашнее задание 16(10 баллов)
Создать конкурирующие jobs, провоцирующие неповторяемость при
чтении и чтение фантомов. Результаты (с подробными комментариями) фиксировать в
debug_log.
Результат отправьте по адресу N.Grafeeva@spbu.ru. Тема письма – DB_Applcation_2015_job16.
Примечание:задание должно быть отправлено в течение 2 недель. За более позднее отправление будут сниматься штрафные баллы ( по баллу за каждые 2 недели).
За сдачу 21 ноября – дополнительные 5 баллов.
