ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 31.03.2021
Просмотров: 1566
Скачиваний: 23
191
распознавания
тупиков
в
распределенных
системах
реализуется
гораздо
сложней
.
14.10.
Метод
выделения
версий
данных
Использование
блокировок
гарантирует
сериальность
планов
выполнения
смеси
транзакций
за
счет
общего
замедления
работы
–
конфликтующие
транзакции
ожидают
,
когда
транзакция
,
первой
заблокировавшая
некоторый
объект
,
не
освободит
его
.
Без
блокировок
не
обойтись
,
если
все
транзакции
изменяют
данные
.
Но
если
в
смеси
транзакций
присутствует
как
транзакции
,
изменяющие
данные
,
так
и
только
читающие
данные
,
можно
применить
альтернативный
механизм
обеспечения
сериальности
,
свободный
от
недостатков
метода
блокировок
.
Этот
метод
состоит
в
том
,
что
транзакциям
,
читающим
данные
,
предоставляется
как
бы
«
своя
»
версия
данных
,
имевшаяся
в
момент
начала
читающий
транзакции
.
При
этом
транзакция
не
накладывает
блокировок
на
читаемые
данные
,
и
,
поэтому
,
не
блокирует
другие
транзакции
,
изменяющие
данные
.
Такой
метод
называется
методом
выделения
версий
и
заключается
в
использовании
журнала
транзакций
для
генерации
разных
версий
данных
.
Как
известно
,
журнал
транзакций
предназначен
для
выполнения
операции
отката
при
неуспешном
выполнении
транзакции
или
для
восстановления
данных
после
сбоя
системы
.
При
использовании
механизма
выделения
версий
журнал
транзакций
содержит
старые
копии
данных
,
измененных
транзакциями
.
Кратко
суть
метода
состоит
в
следующем
:
•
Для
каждой
транзакции
(
или
запроса
)
запоминается
текущий
системный
номер
(SCN – System Current Number).
Чем
позже
начата
транзакция
,
тем
больше
ее
SCN.
•
При
записи
страниц
данных
на
диск
фиксируется
SCN
транзакции
,
производящей
эту
запись
.
Этот
SCN
становится
текущим
системным
номером
страницы
данных
.
•
Транзакции
,
только
читающие
данные
не
блокируют
ничего
в
базе
данных
.
•
Если
транзакция
А
читает
страницу
данных
,
то
SCN
транзакции
А
сравнивается
с
SCN
читаемой
страницы
данных
.
•
Если
SCN
страницы
данных
меньше
или
равен
SCN
транзакции
А
,
то
транзакция
А
читает
эту
страницу
.
•
Если
SCN
страницы
данных
больше
SCN
транзакции
А
,
то
это
означает
,
что
некоторая
транзакция
В
,
начавшаяся
позже
транзакции
А
,
успела
изменить
или
сейчас
меняет
данные
страницы
.
В
этом
случае
транзакция
А
просматривает
журнал
транзакция
назад
в
поиске
первой
записи
об
192
изменении
нужной
страницы
данных
с
SCN
меньшим
,
чем
SCN
транзакции
А
.
Найдя
такую
запись
,
транзакция
А
использует
старый
вариант
данных
страницы
.
Рассмотрим
,
как
решается
проблема
несовместимого
анализа
с
использованием
механизма
выделения
версий
.
Длинная
транзакция
выполняет
некоторый
анализ
по
всей
таблице
,
например
,
подсчитывает
общую
сумму
денег
на
счетах
клиентов
банка
для
главного
бухгалтера
.
Пусть
на
всех
счетах
находятся
одинаковые
суммы
,
например
,
по
100
руб
.
Короткая
транзакция
в
этот
момент
выполняет
перевод
50
руб
.
с
одного
счета
на
другой
так
,
что
общая
сумма
по
всем
счетам
не
меняется
.
Транзакция
А
Время
Транзакция
В
↓
Проверка
SCN
счета
Р
1
.
SCN
транзакции
больше
SCN
счета
.
Чтение
счета
Р
1
=100
без
наложения
блокировки
и
суммирование
.
SUM
=100
t
2
↓
↓
↓
↓
---
---
t
3
↓
Блокирует
счет
Р
3
X
-
блокировкой
(
разрешено
)
---
t
4
↓
Снятие
денег
со
счета
Р
3
.
(
на
счете
Р
3
вместо
100
уже
50)
---
t
5
↓
Блокирует
счет
Р
1
X
-
блокировкой
(
сейчас
разрешено
)
---
t
6
↓
Помещение
денег
на
счет
Р
1
.
Теперь
на
счете
Р
1
вместо
100
уже
150.
---
t
7
↓
Фиксация
транзакции
.
(
снятие
блокировок
)
Проверка
SCN
счета
Р
2
.
SCN
транзакции
больше
SCN
счета
.
Чтение
счета
Р
2
=100
без
наложения
блокировки
и
суммирование
.
SUM
=200
t
2
↓
↓
↓
---
Проверка
SCN
счета
Р
3
.
SCN
транзакции
меньше
SCN
счета
.
Чтение
старого
варианта
счета
Р
3
=100
и
суммирование
.
SUM
=300
t
2
↓
↓
↓
---
Фиксация
транзакции
.
t
10
---
↓
Сумма
на
счетах
подсчитана
правильно
193
Таким
образом
,
транзакция
А
,
начавшаяся
первой
не
задерживает
выполнения
конкурирующей
транзакции
В
.
При
обнаружении
конфликта
(
чтение
транзакцией
А
измененного
счета
P
3
),
транзакции
А
предоставляется
своя
версия
данных
,
которая
была
на
момент
начала
транзакции
А
.
14.11.
Реализация
изолированности
транзакций
средствами
SQL
Уровни
изоляции
.
Стандарт
языка
SQL
не
предусматривает
понятие
блокировок
для
реализации
сериализуемости
смеси
транзакций
.
Вместо
этого
вводится
понятие
уровней
изоляции
.
Этот
подход
обеспечивает
необходимые
требования
к
изолированности
транзакций
,
оставляя
возможность
производителям
различных
СУБД
реализовывать
эти
требования
своими
способами
(
в
частности
,
с
использованием
блокировок
или
выделением
версий
данных
).
Стандарт
SQL
предусматривает
4
уровня
изоляции
.
•
READ UNCOMMITTED
–
уровень
незавершенного
считывания
.
•
READ COMMITTED
–
уровень
завершенного
считывания
.
•
REPEATABLE READ
–
уровень
повторяемого
считывания
.
•
SERIALIZABLE
–
уровень
способности
к
упорядочению
.
Если
все
транзакции
выполняются
на
уровне
способности
к
упорядочению
(
принятом
по
умолчанию
),
то
чередующееся
выполнение
любого
множества
параллельных
транзакций
упорядочено
.
Если
некоторые
транзакции
выполняются
на
уровнях
,
то
имеется
множество
способов
нарушить
способность
.
В
стандарте
SQL
выделены
три
особых
случая
нарушения
к
упорядочению
,
фактически
именно
те
,
которые
были
описаны
блемы
параллелизма
.
7)
Неаккуратное
считывание
»
чтение
,
незафиксированная
зависимость
.
8)
Неповторяемое
считывание
случай
несовместимого
анализа
.
9)
Фиктивные
элементы
частный
случай
несовместимого
анализа
.
Потеря
результатов
обновления
SQL
не
допускается
,
т
.
е
.
На
самом
низком
уровне
изолированности
транзакции
должны
работать
так
,
чтобы
не
допустить
потери
результатов
обновления
.
может
быть
более
низких
к
упорядочению
способности
выше
как
про
– «
грязное
–
частный
(
фантомы
) –
стандартом
194
Различные
уровни
изоляции
определяются
по
возможности
или
исключению
перечисленных
особых
случаев
нарушения
способности
к
упорядочению
.
Эти
определения
описываются
следующей
таблицей
:
Уровень
изоляции
Потеря
результатов
обновления
Неаккуратное
считывание
Неповторяемое
считывание
Фантомы
READ UNCOMMITTED
Нет
Да
Да
Да
READ COMMITTED
Нет
Нет
Да
Да
REPEATABLE READ
Нет
Нет
Нет
Да
SERIALIZABLE
Нет
Нет
Нет
Нет
Синтаксис
операторов
SQL,
определяющих
уровни
изоляции
Уровень
изоляции
транзакции
задается
следующим
оператором
:
SET
TRANSACTION
{
ISOLATION
LEVEL
{
READ
UNCOMMITTED
|
READ
COMMITTED
|
REPEATABLE
READ
|
SERIALIZAABLE
}
| {
READ
ONLY
|
READ
WRITE
}}, ...
Этот
оператор
определяет
режим
выполнения
следующей
транзакции
,
т
.
е
.
этот
оператор
не
влияет
на
изменение
режима
той
транзакции
,
в
которой
он
подается
.
Обычно
,
выполнение
оператора
SET
TRANSACTION
выделяется
как
отдельная
транзакция
:
…(
предыдущая
транзакция
выполняется
со
своим
уровнем
изоляции
)
COMMIT
;
SET TRANSACTION LEVEL REPEATABLE READ
;
COMMIT
;
…
(
следующая
транзакция
выполняется
с
уровнем
изоляции
REPEATABLE
READ
)
Если
задано
предложение
ISOLATION
LEVEL
,
то
за
ним
должно
следовать
один
из
параметров
,
определяющих
уровень
изоляции
.
Кроме
того
,
можно
задать
признаки
READ
ONLY
или
READ
WRITE
.
Если
указан
признак
READ
ONLY
,
то
предполагается
,
что
транзакция
будет
только
читать
данные
.
При
попытке
записи
для
такой
транзакции
будет
сгенерирована
ошибка
.
Признак
READ
ONLY
введен
для
того
,
чтобы
дать
производителям
195
СУБД
возможность
уменьшать
количество
блокировок
путем
использования
других
методов
сериализации
(
например
,
метод
выделения
версий
).
Оператор
SET
TRANSACTION
должен
удовлетворять
следующим
условиям
:
1)
Если
предложение
ISOLATION
LEVEL
отсутствует
,
то
по
умолчанию
принимается
уровень
SERIALIZABLE
.
2)
Если
задан
признак
READ
WRITE
,
то
параметр
ISOLATION
LEVEL
не
может
принимать
значение
READ
UNCOMMITTED
.
3)
Если
параметр
ISOLATION
LEVEL
определен
как
READ
UNCOMMITTED
,
то
транзакция
становится
по
умолчанию
READ
ONLY
.
В
противном
случае
по
умолчанию
транзакция
считается
как
READ
WRITE
.