ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 31.03.2021
Просмотров: 1571
Скачиваний: 23
181
нужную
блокировку
.
Если
за
указанное
время
(
или
после
указанного
числа
попыток
)
блокировка
не
установилась
,
то
транзакция
откатывается
(
или
генерируется
ошибочная
ситуация
).
За
простоту
использования
этого
метода
приходиться
расплачиваться
тем
,
что
транзакции
-
жертвы
выбираются
,
вообще
говоря
,
случайным
образом
.
В
результате
–
из
-
за
одной
простой
транзакции
может
откатиться
более
дорогая
транзакция
,
на
выполнение
которой
уже
потрачено
много
времени
и
ресурсов
системы
.
Второй
способ
характерен
для
промышленных
СУБД
(Oracle, DB2, MS
SQL Server
и
т
.
п
.).
В
этом
случае
система
сама
следит
за
возникновением
ситуации
тупика
,
путем
построения
(
или
постоянного
поддержания
)
так
называемого
графа
ожидания
транзакций
.
Граф
ожидания
транзакций
–
это
ориентированный
граф
,
в
котором
существует
два
типа
вершин
–
вершины
,
соответствующие
транзакциям
,
и
вершины
,
соответствующие
объектам
блокировки
.
В
этом
графе
существует
дуга
,
ведущая
из
вершины
-
транзакции
к
вершине
-
объекту
,
если
даже
для
этой
транзакции
существует
удовлетворительная
блокировка
объекта
.
В
графе
существует
дуга
из
вершины
-
объекта
к
вершине
-
транзакции
,
если
транзакция
ожидает
удовлетворения
захвата
объекта
.
Нетрудно
показать
,
что
в
системе
существует
ситуация
тупика
,
если
в
графе
ожидания
транзакций
имеется
хотя
бы
один
цикл
.
Для
распознавания
тупика
системой
производиться
построение
графа
ожидания
транзакций
и
в
этом
графе
ищутся
циклы
.
Одним
из
методов
нахождения
циклов
в
ориентированном
графе
является
редукция
графа
.
Для
этого
из
графа
,
прежде
всего
,
удаляются
все
дуги
,
исходящие
из
вершин
-
транзакций
,
в
которые
входят
дуги
из
вершин
-
объектов
.
Это
как
бы
соответствует
той
ситуации
,
что
транзакции
,
не
ожидающие
удовлетворения
захватов
,
успешно
завершились
и
сняли
свои
блокировки
.
Далее
,
для
тех
вершин
-
объектов
,
для
которых
не
осталось
входящих
дух
,
но
существуют
исходящие
,
ориентация
исходящих
дуг
изменяется
на
противоположную
.
Это
моделирует
удовлетворение
захватов
.
После
этого
повторяют
первый
шаг
и
так
до
тех
пор
,
пока
на
первом
шаге
не
прекратиться
удаление
дуг
.
Если
после
этого
в
графе
остаются
не
удаленные
дуги
,
то
они
обязательно
образуют
цикл
.
Разрушение
тупика
начинается
с
выбора
транзакции
-
жертвы
,
которая
откатывается
для
обеспечения
возможности
продолжения
работы
других
транзакций
.
Критерий
выбора
транзакции
-
жертвы
обычно
основан
на
учете
стоимости
транзакции
,
определяемой
на
основе
многофакторной
оценки
,
в
которую
с
разными
весами
входят
время
выполнения
транзакции
,
число
накопленных
транзакцией
блокировок
,
приоритет
транзакции
и
другие
факторы
.
182
После
выбора
транзакции
-
жертвы
выполняется
ее
откат
,
при
котором
освобождаются
блокировки
,
установленные
этой
транзакцией
.
Эта
транзакция
затем
может
быть
запущена
снова
.
Следует
обратить
внимание
,
что
насильственное
устранение
тупиковых
ситуаций
,
вообще
говоря
,
является
нарушением
принципа
изолированности
пользователей
.
14.6.
Уровни
изоляции
.
Объекты
синхронизационных
блокировок
Одной
из
проблем
,
которые
существуют
при
реализации
двухфазного
протокола
синхронизационных
захватов
,
является
выбор
объекта
,
который
должен
быть
заблокирован
.
В
рассмотренных
выше
примерах
таким
объектом
был
кортеж
отношения
.
Такой
выбор
обеспечивает
решение
многих
проблем
распараллеливания
(
сериализации
)
транзакций
.
Решение
проблемы
тупиков
было
рассмотрено
выше
.
Не
решенной
,
тем
не
менее
,
оказалась
проблема
фиктивных
элементов
или
«
фантомов
».
Если
говорить
об
объектах
,
которые
в
общем
случае
могут
блокироваться
при
обеспечении
сериализации
транзакций
,
то
в
контексте
реляционных
баз
данных
возможны
следующие
альтернативы
выбора
блокируемого
логического
или
физического
объекта
.
1)
Блокировка
всей
базы
данных
(
логический
объект
).
2)
Блокировка
файлов
базы
данных
(
физические
объекты
для
хранения
отношений
и
,
возможно
,
индексов
).
3)
Блокировка
отношения
(
логический
объект
,
соответствующий
множеству
кортежей
данного
отношения
).
4)
Блокировка
страницы
(
физический
объект
,
являющийся
единицей
обмена
с
диском
,
хранящий
кортежи
одного
или
нескольких
отношений
,
индексную
или
служебную
информацию
).
5)
Блокировка
кортежа
(
элементарный
объект
базы
данных
,
который
может
рассматриваться
как
физический
,
так
и
как
логический
объект
).
На
самом
деле
,
когда
говорят
об
операциях
над
объектами
базы
данных
,
то
любая
операция
над
кортежем
,
фактически
является
и
операцией
над
страницей
,
в
которой
этот
кортеж
хранится
,
и
над
соответствующим
отношением
,
и
над
файлом
,
содержащим
отношение
.
6)
Иногда
рассматривают
блокировку
отдельных
полей
отношений
,
заголовков
отношений
,
индексов
и
других
объектов
баз
данных
.
Выбор
уровня
объекта
для
синхронизационного
захвата
(
неважно
,
какой
этот
объект
–
логический
или
физический
)
непосредственным
образом
связан
с
183
проблемой
оптимизации
распараллеливания
транзакций
.
Чем
крупнее
блокируемый
объект
,
тем
меньше
синхронизационных
захватов
будет
поддерживаться
в
системе
и
,
следовательно
,
тем
меньше
связанные
с
ними
накладные
расходы
системы
.
Более
того
,
если
в
качестве
уровня
объекта
блокировки
выбрать
файл
или
отношение
,
то
будет
решена
и
проблема
фантомов
.
Действительно
,
в
этом
случае
оказывается
невозможным
добавление
строки
-
фантома
никакой
другой
транзакцией
.
Однако
,
чем
крупнее
блокируемый
объект
,
тем
большей
становиться
вероятность
конфликтов
транзакций
и
тем
самым
уменьшается
допускаемая
степень
их
параллельного
выполнения
.
Фактически
,
при
укрупнении
объекта
блокировки
ситуация
умышленно
огрубляется
,
и
при
этом
конфликты
транзакций
возникают
в
тех
ситуациях
,
в
которых
их
на
самом
деле
нет
,
только
из
-
за
того
,
что
элементарные
не
конфликтующие
объекты
,
затрагиваемые
транзакциям
принадлежат
одному
крупному
блокируемому
целиком
объекту
.
Чем
мельче
блокируемые
объекты
,
тем
естественно
вероятность
возникновения
конфликтов
при
их
блокировках
будет
меньше
,
однако
при
этом
резко
возрастает
количество
блокировок
,
особенно
при
выполнении
транзакций
над
большим
числом
объектов
.
Современные
промышленные
СУБД
,
как
правило
,
поддерживают
минимальный
уровень
блокировки
на
уровне
кортежей
или
страниц
.
Хотя
можно
представить
себе
,
когда
,
например
,
в
качестве
минимального
объекта
блокировки
будет
выступать
отдельные
атрибуты
(
поля
)
кортежей
.
Необходимость
решения
проблемы
оптимизации
выбора
уровня
объекта
синхронизационных
захватов
привела
к
разработке
аппарата
так
называемых
гранулированных
синхронизационных
захватов
или
протокола
блокировок
по
намерению
(intent locking).
14.7.
Гранулированные
синхронизационные
блокировки
.
Блокировки
по
намерению
При
использовании
протокола
гранулированных
блокировок
(
блокировок
по
намерению
),
являющегося
расширением
рассмотренного
выше
протокола
блокировок
,
синхронизационные
захваты
или
блокировки
могут
применяться
к
объектам
разного
уровня
:
к
файлам
,
к
отношениям
,
к
страницам
и
к
кортежам
.
Требуемый
уровень
объекта
определяется
тем
,
какая
конкретная
операция
выполняется
.
Например
,
для
выполнения
операции
уничтожения
отношения
объектом
блокировки
должно
быть
все
отношение
,
а
для
удаления
кортежа
–
сам
этот
кортеж
.
Как
известно
объект
любого
уровня
может
быть
захвачен
в
режиме
S
(
разделяемом
)
или
режиме
X
(
монопольном
).
184
Наиболее
важным
отличием
рассматриваемого
протокола
гранулированных
захватов
является
введение
новых
типов
блокировок
–
так
называемых
блокировок
по
намерению
(
intent
locking
).
Перед
захватом
объекта
в
режиме
S
(
Shared lock
–
разделяемая
блокировка
)
или
X
(
eXlusive
lock
–
монопольная
блокировка
)
соответствующий
объект
более
верхнего
уровня
должен
быть
заблокирован
в
режимах
IS
,
IX
,
SIX
,
являющихся
блокировками
по
намерению
,
то
есть
блокировками
,
устанавливаемыми
при
намерении
установить
в
конечном
итоге
блокировку
S
или
X
.
•
IS
–
Intent Share lock
–
блокировка
по
намерению
совместного
доступа
.
Эта
блокировка
накладывается
на
некоторый
составной
объект
О
и
означает
намерение
блокировать
некоторый
входящий
в
О
более
мелкий
объект
в
режиме
S
-
блокировки
.
Например
,
при
намерении
читать
кортежи
из
отношения
О
,
это
отношение
должно
быть
заблокировано
в
режиме
IS
(
до
этого
в
таком
режиме
должен
быть
заблокирован
файл
).
•
IX
–
Intent eXclusive lock
–
блокировка
по
намерению
монопольного
доступа
.
Эта
блокировка
по
отношению
к
некоторому
составному
объекту
О
означает
намерение
захватить
некоторый
входящий
в
О
более
мелкий
объект
в
монопольном
(
X
)
режиме
.
Например
,
при
намерении
удалять
кортежи
из
отношения
R
,
это
отношение
должно
быть
заблокировано
в
режиме
IX
,
а
до
этого
в
таком
же
режиме
должен
быть
заблокирован
файл
.
•
SIX
– Shared Intent eXclusive lock –
блокировка
по
намерению
блокировки
с
совместным
доступом
или
с
монопольным
.
По
отношению
к
некоторому
составному
объекту
О
эта
блокировка
означает
совместную
блокировку
всего
этого
объекта
с
намерением
впоследствии
захватывать
какие
-
либо
входящие
в
него
объекты
в
режиме
монопольного
доступа
.
Например
,
если
выполняется
длинная
операция
просмотра
отношений
с
возможностью
удаления
некоторых
из
просматриваемых
кортежей
,
то
экономичнее
всего
заблокировать
это
отношение
в
режиме
SIX
,
а
до
этого
заблокировать
файл
в
режиме
IS
.
Блокировки
IS
,
IX
и
SIX
должны
накладываться
на
сложные
объекты
базы
данных
(
таблицы
,
файлы
,
страницы
).
Кроме
того
,
на
сложные
объекты
могут
накладываться
и
блокировки
типов
S
и
X
.
Для
сложных
объектов
(
например
,
для
таблицы
базы
данных
)
таблица
совместимости
блокировок
имеет
следующий
вид
.
185
Транзакция
В
пытается
наложить
блокировку
:
Транзакция
А
заблокировала
объект
блокировкой
:
IS S IX SIX X
IS
Да
Да
Да
Да
Нет
S
Да
Да
Нет
Нет
Нет
IX
Да
Нет
Да
Нет
Нет
SIX
Да
Нет
Нет
Нет
Нет
X
Нет
Нет
Нет
Нет
Нет
Более
точная
формулировка
протокола
блокировок
по
намерению
доступа
к
данным
выглядит
следующим
образом
:
1.
При
задании
Х
-
блокировки
для
сложного
объекта
неявным
образом
задается
Х
-
блокировка
для
всех
дочерних
объектов
этого
объекта
.
2.
При
задании
S-
или
SIX-
блокировки
для
сложного
объекта
неявным
образом
задается
S
блокировка
для
всех
дочерних
объектов
этого
объекта
.
3.
Прежде
чем
транзакция
наложит
S-
или
IS-
блокировку
на
заданный
объект
,
она
должна
задать
IS-
блокировку
(
или
более
сильную
)
по
крайней
мере
,
для
одного
родительского
объекта
этого
объекта
.
4.
Прежде
чем
транзакция
наложит
X
-,
IX
-
или
SIX-
блокировку
на
заданный
объект
,
она
должна
задать
IX-
блокировку
(
или
более
сильную
)
для
всех
родительских
объектов
этого
объекта
.
5.
Прежде
чем
для
данной
транзакции
будет
отменена
блокировка
для
данного
объекта
,
должны
быть
отменены
все
блокировки
для
дочерних
объектов
этого
объекта
.
Понятие
относительной
силы
блокировок
можно
описать
при
помощи
следующей
диаграммы
приоритета
(
сверху
–
более
сильные
блокировки
,
снизу
–
более
слабые
):
X
SIX
IX
IS
S
Рис
. 14.3.
Диаграмма
приоритета
блокировок
Можно
обратить
внимание
на
то
,
что
протокол
блокировок
по
намерению
не
определяет
однозначно
,
какие
блокировки
должны
быть
наложены
на