Сериалиация транзакций
Для того чтобы избежать подобных конфликтов, требуется выработать некоторую процедуру согласованного выполнения параллельных транзакций. Эта процедуру должна удовлетворять следующим правилам:
В ходе выполнения транзакции пользователь видит только согласованные данные. Пользователь не должен видеть несогласованные промежуточные данные.
Когда в БД 2 транзакции выполняются параллельно, результаты выполнения транзакций должны быть такими же, как если бы выполнялась транзакция 1, а затем транзакция 2 или наоборот.
Процедура, обеспечивающая реализацию этих принципов, называется сериализацией транзакций. Она гарантирует, что каждый пользователь, обращаясь к БД, работает с ней так, как будто не существует других пользователей, одновременно обращающихся к тем же данным. Результат совместного выполнения транзакции эквивалентен результату некоторого последовательного выполнения этих же транзакций.
Самым простым выходом было бы последовательное выполнение транзакций, но такой выход неоптимален по времени, существуют более гибкие методы управления параллельным доступом к БД. Наиболее распространенный механизм решения этих проблем блокировка объекта (например, таблицы) на все время действия транзакции. Если транзакция обращается к заблокированному объекту, то она остается в состоянии ожидания до момента разблокировки этого объекта, после чего она может начать его обработку. Однако блокировка создает новые проблемы - задержку выполнения транзакций из-за блокировок.
Итак, блокировки, называемые также синхронизационными захватами объектов, могут быть применены к разному типу объектов. Наибольшим объектом блокировки может быть вся БД, однако этот вид блокировки сделает БД недоступной для всех других приложений, которые работают с данной БД. Следующий тип объекта блокировки – таблицы. Транзакция, которая работает с таблицей, блокирует ее на все время выполнения транзакции. Этот вид блокировки предпочтительнее предыдущего, потому что позволяет параллельно выполнять транзакции, которые работают с другими таблицами.
В ряде СУБД реализована блокировка на уровне страниц. В этом случае СУБД блокирует только отдельные страницы на диске, когда транзакция обращается к ним. Этот вид блокировки еще более мягок, и позволяет разным транзакциям работать с одной и той же таблице, если они обращаются к разным страницам данных.
В некоторых СУБД возможна блокировка на уровне строк, однако такой механизм блокировки требует дополнительных затрат, на свою поддержку. SQL Server стремится установить блокировку на уровне записей, чтобы обеспечить максимальную параллельность в работе. С увеличением количества блокировок строк сервер может перейти к блокировке страниц, если количество записей превышает пороговое значения.
Переопределение блокировок на уровне запроса. Типы блокировок
Если после имени таблицы в предложении FROM следует одно из перечисленных ключевых слов, запрос вмешивается в работу диспетчера блокировок и применяется заданный тип блокировки:
NOLOCK- разрешает грязное чтение;
PAGLOCK- блокировка на уровне страниц;
ROWLOCK- блокировка на уровне записей;
TABLOCK-разделяемая блокировка таблицы;
TABLOCKX- монопольная блокировка таблицы
В настоящее время проблема блокировок является предметом большого числа исследований.
Различают два базовых типа блокировок (синхронизационных захватов):
Разделяемые (нежесткие) блокировки – это режим означает разделяемый захват объекта и используется для выполнения операции чтения объекта. Объекты, заблокированные таким образом, не изменяются в ходе выполнения транзакции и доступны другим транзакциям, но только в режиме чтения;
Монопольные (жесткие) блокировки – не позволяют вообще никому, кроме владельца этой блокировки, обращаться к данным. Эти блокировки используются для команд, которые изменяют содержание или структуру таблицы и действуют до конца транзакции.
Захваты объектов несколькими транзакциями по чтению совместимы, то есть нескольким транзакциям допускается читать один и тот же объект. Захват объекта одной транзакцией по чтению не совместим с захватом другой транзакцией того же объекта по записи. Захваты одного объекта разными транзакциями по записи не совместимы.
Однако применение разных типов блокировок приводит к проблеме тупиков. Проблема тупиков возникла при рассмотрении выполнения параллельных процессов в операционных средах и также была связана с управлением разделяемыми (совместно используемыми) объектами. Пример тупика: Пусть транзакция А жестко блокирует таблицу 1, а затем жестко блокирует таблицу 2. Транзакция В, наоборот жестко блокирует таблицу 2, а затем жестко блокирует таблицу 1.
Рисунок 9
Если обе эти транзакции начали работу одновременно, то после выполнения операций модификации первой таблицы они обе окажутся в бесконечном ожидании: транзакция А будет ждать завершения работы транзакции В и разблокировки таблицы 2, а транзакция В будет безрезультатно ждать завершения работы транзакции А и разблокировки таблицы 1.
Ситуации могут быть гораздо более сложными. Количество взаимно заблокированных транзакций может оказаться гораздо больше. Эту ситуацию каждая транзакция обнаружить самостоятельно не может. Ее должна разрешить СУБД. В большинстве коммерческих СУБД существует механизм обнаружения таких тупиковых ситуаций.
Основой обнаружения тупиковых ситуаций является построение (или постоянное поддержание) графа ожидания транзакций. Граф ожидания может представлять собой направленный граф, в вершинах которого расположены имена транзакций. Если транзакция Т1 ждет окончания транзакции Т2, то из вершины Т1 в вершину Т2 идет стрелка. Дополнительно стрелки могут быть помечены именами заблокированных объектов и типом блокировки.
В механизме реализации блокировок используется понятие уровня изоляции блокировки, определяющее, сколько таблиц будет блокировано. Традиционно используется три уровня изоляции:
Уровень изоляции, называемый повторное чтение, реализует такую стратегию, что внутри данной транзакции все записи, извлеченные с помощью запросов, не могут быть изменены. Эти записи не могут быть изменены до тех пор, пока транзакция не завершиться.
Уровень изоляции, который называют указатель стабильности, предохраняет каждую запись от изменений на время, когда она считывается, или от чтения на время ее изменения.
Третий уровень стабильности, называется только чтение. Только чтение блокирует всю таблицу, а, следовательно, не может использоваться с командами модификации. Таким образом, только чтение гарантирует, что вывод запроса будет внутренне согласован с данными таблицы.
Итак, средство управления параллелизмом в СУБД определяет, то в какой степени, одновременно поданные команды будут мешать друг другу. В современных СУБД оно является адаптируемым средством, автоматически находящим оптимальное решение с учетом обеспечения максимальной производительности БД и доступности данных для действующих команд.