Гранулированные синхронизационные блокировки
Лекция 8
Сериализация транзакций
Для того, чтобы добиться изолированности транзакций, в СУБД должны использоваться какие-либо методы регулирования совместного выполнения транзакций.
План (способ) выполнения набора транзакций называется сериальным, если результат совместного выполнения транзакций эквивалентен результату некоторого последовательного выполнения этих же транзакций.
Сериализация транзакций - это механизм их выполнения по некоторому сериальному плану.
Обеспечение такого механизма является основной функцией компонента СУБД, ответственного за управление транзакциями. Система, в которой поддерживается сериализация транзакций, обеспечивает реальную изолированность пользователей.
Основная реализационная проблема состоит в выборе метода сериализации набора транзакций, который не слишком ограничивал бы их параллельность. Тривиальным решением является действительно последовательное выполнение транзакций.
Но существуют ситуации, в которых можно выполнять операторы разных транзакций в любом порядке с сохранением сериальности. Примерами могут служить только читающие транзакции, а также транзакции, не конфликтующие по доступу к объектам базы данных.
Между транзакциями могут существовать следующие виды конфликтов:
W-W - транзакция 2 пытается изменять объект, измененный не закончившейся транзакцией 1;
R-W - транзакция 2 пытается изменять объект, прочитанный не закончившейся транзакцией 1;
|
|
|
W-R - транзакция 2 пытается читать объект, измененный не закончившейся транзакцией 1.
Практические методы сериализации транзакций основывается на учете этих конфликтов.
Методы сериализации транзакций
Существуют два базовых подхода к сериализации транзакций: подход, основанный на синхронизационных захватах объектов базы данных, и подход, основанный на использовании временных меток.
Суть обоих подходов состоит в обнаружении конфликтов транзакций и их устранении.
Синхронизационные блокировки(захвата)
Наиболее распространенным в централизованных СУБД (включающих системы, основанные на архитектуре клиент-сервер) является подход, основанный на соблюдении двухфазного протокола синхронизационных блокировок объектов БД (иногда вместо термина "блокировка" используется эквивалентный по смыслу термин "захват"). В общих чертах протокол состоит том, что перед выполнением любой операции в транзакции T над объектом базы данных r от имени транзакции T запрашивается синхронизационный захват объекта r в соответствующем режиме (в зависимости от вида операции).
Основными режимами синхронизационных захватов являются:
|
|
|
совместный режим - S (Shared), означающий разделяемый захват объекта и требуемый для выполнения операции чтения объекта (по-другому мы будем называть S-захват объекта БД захватом по чтению);
монопольный режим - X (eXclusive), означающий монопольный захват объекта и требуемый для выполнения операций занесения, удаления и модификации (по-другому мы будем называть X-захват объекта БД захватом по записи).
Захваты объектов несколькими транзакциями по чтению совместимы, т.е. нескольким транзакциям допускается читать один и тот же объект. Захват объекта одной транзакцией по чтению не совместим с захватом другой транзакцией того же объекта по записи, и захваты одного объекта разными транзакциями по записи не совместимы. Правила совместимости захватов одного объекта разными транзакциями изображены на следующей таблице:
| X | S | |
| - | да | да |
| X | нет | нет |
| S | нет | да |
В первом столбце приведены возможные состояния объекта с точки зрения синхронизационных захватов. При этом "-" соответствует состоянию объекта, для которого не установлен никакой захват. Транзакция, запросившая синхронизационный захват объекта БД, уже захваченный другой транзакцией в несовместимом режиме, блокируется до тех пор, пока захват этого объекта не будет снят.
|
|
|
Слово "нет" в таблице соответствует описанным ранее возможным случаям конфликтов транзакций по доступу к объектам базы данных (WW, RW, WR). Совместимость S-захватов соответствует тому, что конфликт RR не существует.
Для обеспечения сериализации транзакций (третьего уровня изолированности) синхронизационные захваты объектов, произведенные по инициативе транзакции, можно снимать только при ее завершении. Это требование порождает двухфазный протокол синхронизационных захватов - 2PL (Two-PhaseLocks).
В соответствии с этим протоколом выполнение транзакции разбивается на две фазы:
первая фаза транзакции - накопление захватов;
вторая фаза (фиксация или откат) - освобождение захватов.
При соблюдении двухфазного протокола синхронизационных захватов действительно обеспечивается сериализация транзакций на третьем уровне изолированности. Основная проблема состоит в том, что следует считать объектом для синхронизационного захвата.
В контексте реляционных баз данных возможны следующие альтернативы:
файл - физический (с точки зрения базы данных) объект, область хранения нескольких отношений и, возможно, индексов;
|
|
|
отношение - логический объект, соответствующий множеству кортежей данного отношения;
страница данных - физический объект, хранящий кортежи одного или нескольких отношений, индексную или служебную информацию;
кортеж - элементарный физический объект базы данных.
На самом деле, любая операция над кортежем, фактически, является и операцией над страницей, в которой этот кортеж хранится, и над соответствующим отношением, и над файлом, содержащим отношение. Поэтому действительно имеется выбор уровня объекта захвата.
Понятно, что чем крупнее объект синхронизационного захвата (неважно, какой природы этот объект - логический или физический), тем меньше синхронизационных захватов будет поддерживаться в системе, и на это, соответственно, будут тратиться меньшие накладные расходы. Более того, если выбрать в качестве уровня объектов для захватов файл или отношение, то будет решена даже проблема фантомов.
Но вся беда в том, что при использовании для захватов крупных объектов возрастает вероятность конфликтов транзакций и тем самым уменьшается допускаемая степень их параллельного выполнения. Фактически, при укрупнении объекта синхронизационного захвата мы умышленно огрубляем ситуацию и видим конфликты в тех ситуациях, когда на самом деле конфликтов нет.
Разработчики многих систем начинали с использования страничных захватов, полагая это некоторым компромиссом между стремлениями сократить накладные расходы и сохранить достаточно высокий уровень параллельности транзакций. Но это не очень хороший выбор. Использование страничных захватов в двухфазном протоколе иногда вызывает очень неприятные синхронизационные проблемы, усложняющие организацию СУБД. В большинстве современных систем применяются покортежные синхронизационные захваты.
Но при этом возникает очередной вопрос. Если единицей захвата является кортеж, то какие синхронизационные захваты потребуются при выполнении таких операций, как уничтожение отношения? Было бы довольно нелепо перед выполнением такой операции потребовать захвата всех существующих кортежей отношения. Кроме того, это не предотвратило бы возможности параллельной вставки в другой транзакции нового кортежа в уничтожаемое отношение.
Гранулированные синхронизационные блокировки
Подобные рассуждения привели к разработке аппарата гранулированных синхронизационных захватов. При применении этого подхода синхронизационные захваты могут запрашиваться по отношению к объектам разного уровня: файлам, отношениям и кортежам.
Требуемый уровень объекта определяется тем, какая операция выполняется (например, для выполнения операции уничтожения отношения объектом синхронизационного захвата должно быть все отношение, а для выполнения операции удаления кортежа - этот кортеж). Объект любого уровня может быть захвачен в режиме S или X.
Наиболее важное отличие, на котором держится соответствие захватов разного уровня, состоит в следующем. Вводятся специальный протокол гранулированных захватов и новые типы захватов: перед захватом объекта в режиме S или X соответствующий объект более верхнего уровня должен быть захвачен в режиме IS, IX или SIX. Что же представляют собой эти режимы захватов?
IS (IntentedforSharedlock)по отношению к некоторому составному объекту O означает намерение захватить некоторый входящий в O объект в совместном режиме. Например, при намерении читать кортежи из отношения R это отношение должно быть захвачено в режиме IS (а до этого в таком же режиме должен быть захвачен файл).
IX (IntentedforeXclusivelock) по отношению к некоторому составному объекту O означает намерение захватить некоторый входящий в O объект в монопольном режиме. Например, при намерении удалять кортежи из отношения R это отношение должно быть захвачено в режиме IX (а до этого в таком же режиме должен быть захвачен файл).
SIX (Shared, IntentedforeXclusivelock) по отношению к некоторому составному объекту O означает совместный захват всего этого объекта с намерением впоследствии захватывать какие-либо входящие в него объекты в монопольном режиме. Например, если выполняется длинная операция просмотра отношения с возможностью удаления некоторых просматриваемых кортежей, то экономичнее всего захватить это отношение в режиме SIX (а до этого захватить файл в режиме IS).
Довольно трудно описать словами все возможные ситуации. Ограничимся приведением полной таблицы совместимости блокировок, анализируя которую, можно выявить все случаи:
Дата добавления: 2018-05-09; просмотров: 475; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!