Целостность Параллелные запросы Блокировки

к.э.н., доцент Д.Г. Корнеев
2009 год

«Базы данных»
Лекция № 5
Ограничения целостности,

Параллельные запросы, Блокировки

программный код, который выполняется при наступлении определенных событий:
События Уровня 1:

ОN,
BEFORE,
AFTER
События Уровня 2:
DELETE
INSERT
UPDATE
Триггер срабатывает при одновременном наступлении
событий уровня 1 и 2.
Используется, в частности, для поддержания
целостности БД.

восстановление самой базы данных, т.е. возвращение базы данных в определенное

состояние, которое считается правильным, после некоторого сбоя, в результате которого текущее состояние становится неправильным или, по крайней мере, достаточно неопределенным (понятие правильного состояния базы данных будет точно сформулировано в следующем разделе). Основной принцип, на котором строится подобное восстановление, достаточно прост и может быть выражен одним словом — избыточность (на физическом уровне).

выполнения операции BEGIN TRANSACTION и заканчивается операцией COMMIT или ROLLBACK.

На рис. будет показан псевдокод транзакции, которая предназначена для перечисления суммы 100 долл. со счета 123 на счет 456. Вполне очевидно, что операция перевода денег с одного счета на другой, которая по самой своей сути является неразрывной, фактически требует выполнения в базе данных двух отдельных операций обновления.

такой ситуации, когда одно из обновлений будет выполнено, а другое

— нет, поскольку в результате база данных останется в недопустимом состоянии. Это достигается механизмом (системой) управления транзакциями. выполнены некоторые обновления, а затем возникнет отказ еще до того, как транзакция достигнет своего завершения, то все эти обновления будут отменены.

называется диспетчером транзакций (для его обозначения применяются также термины монитор

обработки транзакций или ТР-монитор), а в основе организации его работы лежат операции COMMIT и ROLLBACK, которые описаны ниже.

сообщает диспетчеру транзакций, что логическая единица работы успешно завершена, база

данных вновь находится (или будет находиться после выполнения этого оператора) в непротиворечивом состоянии, а все обновления, выполненные данной логической единицей работы, теперь могут быть зафиксированы, т.е. внесены в базу данных (запись содержимого регистров ОП на диск).

Он сообщает диспетчеру транзакций, что произошла какая-то ошибка, база данных

находится в противоречивом состоянии и следует осуществить откат всех проведенных при выполнении этой транзакции обновлений, т.е. они должны быть отменены.

выполнение проверок на наличие ошибок и явный вызов на выполнение

оператора ROLLBACK в случае обнаружения ошибки. Но не следует предполагать, что транзакции всегда включают явно заданные проверки на случай всех возможных ошибок. Поэтому система должна вызывать на выполнение неявно заданный оператор ROLLBACK для всех транзакций, которые по какой-то причине окончились неудачей и не достигли этапа планового завершения (здесь под плановым завершением подразумевается явно заданный оператор COMMIT ИЛИ ROLLBACK).

можно обеспечить отмену обновления. Ответ на этот вопрос состоит в

том, что в системе ведется журнал, в котором регистрируются подробные сведения обо всех обновлениях, в частности, значения обновляемых объектов, например, кортежей) до и после каждого обновления, иногда называемые образами данных до и после обновления. Поэтому, если возникает необходимость отменить некоторые конкретные обновления, система использует соответствующую запись журнала для восстановления предыдущего значения обновленного объекта.
Создается ROLLBACK SEGMENT;

— активной (или оперативной) части и архивной (или автономной) части.

Оперативной называется та часть журнала, которая используется в процессе текущей эксплуатации системы для регистрации подробных сведений об обновлениях по мере их выполнения, и обычно хранится на диске. После заполнения пространства памяти, отведенного для оперативной части журнала, ее содержимое передается в автономную часть, которая теперь может быть записана на диск.

на то, что операторы COMMIT и ROLLBACK завершают транзакцию, а

не прикладную программу. Как правило, процесс прогона отдельной программы состоит из ряда транзакций, которые следуют одна за другой, как показано на рис.

мере, в непротиворечивом состоянии. Под понятием непротиворечивости мы подразумеваем отсутствие

нарушений каких-либо известных ограничений целостности.
Следует также отметить, что непротиворечивость базы данных, рассматриваемая с точки зрения такого определения данного термина, обеспечивается средствами самой СУБД. Из этого следует (также по определению), что транзакции всегда переводят базу данных из одного непротиворечивого состояния в другое.

допустимости, а не только непротиворечивости! Например, в случае транзакции, показанной

на рис. 1, требуется, чтобы суммарное количество денег на счетах 123 и 456 в результате транзакции не изменилось. Но было бы неразумно ставить перед собой задачу по подготовке ограничения целостности, которое соответствовало бы такому требованию, и поэтому нельзя рассчитывать на то, что СУБД сможет следить за соблюдением данного требования.

обладают (или должны
обладать!) четырьмя важными свойствами: неразрывностью (atomicity), правильностью

(correctness), изолированностью (isolation) и устойчивостью (durability). Этот набор свойств принято называть свойствами ACID (по первым буквам их английских названий).
■ Неразрывность. Транзакции неразрывны (выполняются по принципу «все или ни одной»)

в другое; при этом правильность не обязательно должна обеспечиваться

на всех промежуточных этапах.


Изолированность. Транзакции изолированы одна от другой. Таким образом, даже если будет запущено множество транзакций, работающих параллельно, результаты любых операций обновления, выполняемых отдельной транзакцией, будут скрыты от всех остальных транзакций до тех пор, пока эта транзакция не будет зафиксирована.

В справедливо следующее утверждение: транзакция А сможет получить результаты выполненных

транзакцией В обновлений только после фиксации транзакции В, а транзакция В сможет получить результаты выполненных транзакцией А обновлений только после фиксации транзакции А.
Устойчивость. После того как транзакция зафиксирована, выполненные ею обновления сохраняются в базе данных на постоянной основе, даже если в дальнейшем произойдет аварийная остановка системы.

восстановление – ROLLBACK);
Глобальное нарушение воздействует сразу на все транзакции, выполнявшиеся

в момент его возникновения, и поэтому приводит к более значительным для системы последствиям.

сбои в питании) воздействуют на все выполняющиеся в данный момент

транзакции, но не приводят к физическому повреждению базы данных. Отказ системы иногда также называют мягким аварийным остановом.
Отказы носителей (например, поломка головки дискового накопителя), которые могут представлять угрозу для физического состояния всей базы данных или какой-либо ее части, способны воздействовать, по крайней мере, на те транзакции, которые используют поврежденную часть базы данных. Отказ носителя иногда называют также жестким аварийным остановом.

(оперативной) памяти (в частности, буферов базы данных). Поскольку точное состояние

любой выполнявшейся в момент отказа системы транзакции остается неизвестным, такая транзакция не может быть успешно завершена. Поэтому при перезапуске системы любая такая транзакция будет отменена (т.е. будет выполнен ее откат).
Более того, при перезапуске системы, возможно, потребуется повторно выполнить некоторые транзакции, которые были успешно завершены до аварийного останова, но выполненные ими обновления еще не были перенесены из буферов оперативной памяти в физическую базу данных во вторичной памяти.

какую транзакцию следует отменить, а какую выполнить повторно? Ответ заключается

в том,
что система автоматически создает контрольные точки (SAVE POINT) с некоторым наперед заданным интервалом (обычно, когда в журнале накапливается определенное число записей). Для создания контрольной точки требуется:
во-первых, выполнить принудительное сохранение содержимого буферов оперативной памяти в физической базе данных,
во-вторых, осуществить принудительное сохранение специальной записи контрольной точки в журнале на физическом носителе.
Запись контрольной точки содержит список всех транзакций, выполняемых в тот момент, когда создавалась контрольная точка.

моменту tf контрольная точка была создана в момент времени tc.
■

Транзакция типа Т1 успешно завершена до момента времени tc.
■ Транзакция типа Т2 начата до момента tc и успешно завершена после момента времени tc, но до момента времени tf.
■ Транзакция типа ТЗ также начата до момента времени tc, но не завершена к моменту времени tf.
■ Транзакция типа Т4 начата после момента времени tc и успешно завершена до момента времени tf.
■ Наконец, транзакция типа Т5 также начата после момента tc, но не завершена к моменту времени tf.
Очевидно, что при перезапуске системы транзакции типов ТЗ и Т5 должны быть отменены, а транзакции типа Т2 и Т4 — выполнены повторно. Отметим, что транзакции типа Т1 вообще не участвуют в процессе перезапуска, поскольку выполненные ими обновления были принудительно внесены в физическую базу данных к моменту времени tc как часть процедуры создания этой контрольной точки.

накопителя или отказа контроллера дисков, когда некоторая часть базы данных

разрушается физически. Восстановление после такого нарушения включает загрузку (или восстановление) базы данных с резервной копии (или из дампа) и последующее использование журнала (как его активной, так и архивной частей) для повторного выполнения всех транзакций, успешно завершенных в системе с момента создания данной резервной копии (прямое восстановление). При этом нет никакой необходимости отменять транзакции, которые выполнялись в момент отказа носителей, поскольку по определению все обновления, выполненные этими транзакциями, уже полностью отменены (фактически просто утрачены).

сохранения (ручной режим). Приведенный ниже оператор создает точку сохранения с

именем, указанным пользователем (которое известно только в пределах данной транзакции).
SAVEPOINT ;
Следующий оператор отменяет все обновления, внесенные в базу данных со времени создания указанной точки сохранения.
ROLLBACK TO ;
Ниже приведен оператор, который удаляет указанную точку сохранения, а это означает, что с этого времени нельзя будет выполнить оператор ROLLBACK для возврата к данной точке сохранения.
RELEASE ;
Все точки сохранения уничтожаются автоматически после завершения транзакции.

одновременно обращаться с помощью многих транзакций к одной и той

же базе данных. Очевидно, что в системе, обладающей таким свойством, требуется определенный механизм управления, который позволяет добиться того, чтобы параллельно выполняемые транзакции не нарушали работу друг друга.

нарушения работы. Это такие ситуации, что транзакция, будучи правильной сама

по себе в том смысле, который ранее был определен, может, тем не менее, выработать неправильный ответ, если в ее работу каким-то образом вмешиваются другие транзакции. При этом необходимо учитывать, что и сами транзакции, нарушающие ее работу, также рассматриваются как правильные, поэтому причиной получения общего неправильного результата становится неконтролируемое чередование операций двух транзакций, которые сами по себе являются правильными.

■ Проблема потерянного обновления.
■ Проблема зависимости от

незафиксированных результатов.
■ Проблема анализа несовместимости.

Рассмотрим каждую из этих проблем по очереди.

в момент времени tl, транзакция В выполняет выборку того же

кортежа t в момент времени t2, транзакция А обновляет кортеж в момент времени t3 (с учетом тех значений, которые он имел во время tl), а транзакция В обновляет тот же кортеж в момент времени t4 (с учетом тех значений, которые он имел во время t2, которые оставались такими же, как и во время tl). В момент времени t4 происходит потеря обновления, внесенного транзакцией А, поскольку транзакция в перезаписывает его, даже не проверяя.

одной транзакции разрешено выполнять выборку (или, что еще хуже, обновление)

кортежа, который был обновлен другой транзакцией, но это обновление еще не было зафиксировано другой транзакцией. А поскольку это обновление еще не зафиксировано, то всегда существует вероятность, что оно так и не будет зафиксировано, а вместо этого произойдет откат, и в этом случае первая транзакция будет работать с данными, которых больше не существует (и которые в определенном смысле и не существовали).

незафиксированному обновлению (называемому также незафиксированным изменением) в момент времени t2.

Затем в момент времени t3 происходит отмена этого обновления. Таким образом, транзакция А действует на основании ложной предпосылки, что кортеж t имеет значение, которое было ею получено во время t2, тогда как этот кортеж фактически имеет то значение, которое он имел к моменту времени tl. В связи с этим транзакция А вполне может выработать неправильные результаты.

незафиксированного изменения в момент времени t2, но и фактически теряет

свое обновление во время t3, поскольку откат в момент времени t3 вызывает восстановление кортежа t до того значения, которое он имел к моменту времени tl, т.е. это еще один вариант проблемы потерянного обновления.

сумму 10 со счета 3 на счет 1. Очевидно, что

результат, выработанный транзакцией А, — 110, является неправильным; если бы в ходе своего дальнейшего выполнения транзакция А снова записала этот результат в базу данных, то фактически оставила бы базу данных в противоречивом состоянии. Обратите внимание на различие между этим примером и предыдущим: в данном случае не возникает проблема зависимости транзакции А от незафиксированного изменения, поскольку В зафиксировала все свои обновления еще до того, как А прочитала значение АСС 3.

параллельным выполнением, называемого блокировкой. В его основе лежит простая идея

— если для некоторой транзакции А требуется гарантия, чтобы определенный объект, в котором она заинтересована (как правило, кортеж базы данных), не изменился каким-то образом без ее ведома (как описано выше), она приобретает блокировку на этот объект. Неформально выражаясь, следствием приобретения блокировки является то, что к рассматриваемому объекту, блокируется доступ других транзакций.

исключительные блокировки (блокировки X — exclusive)

разделяемые блокировки (блокировки S — shared).

Если транзакция А владеет исключительной блокировкой (X), то запрос от некоторой другой транзакции В на получение блокировки кортежа t любого типа не может быть немедленно удовлетворен.

от некоторой другой транзакции В на получение блокировки кортежа t

любого типа не может быть немедленно удовлетворен.
Если транзакция А владеет разделяемой блокировкой (S) кортежа t, то выполняются следующие условия:
■ запрос некоторой другой транзакции В на получение блокировки X кортежа t не может быть немедленно удовлетворен;
■ запрос некоторой другой транзакции в на получение блокировки S кортежа t может и должен быть немедленно удовлетворен (это означает, что с этого времени транзакция в также будет владеть блокировкой S кортежа).

Такая матрица интерпретируется следующим образом: рассмотрим некоторый кортеж t и

предположим, что транзакция А в настоящее время владеет блокировкой на t, которая обозначена одной из записей в заголовках столбцов (дефис обозначает, что блокировка отсутствует), а также предположим, что некоторая другая
транзакция в выдает запрос на получение блокировки t, которая обозначена одной из записей в заголовках строк (для полноты здесь также предусмотрен случай "отсутствия блокировки"). В этой матрице "N" указывает на конфликт (запрос транзакции В не может быть немедленно удовлетворен), a "Y" указывает на совместимость (запрос транзакции В может и должен быть немедленно удовлетворен).

блокировки,который позволяет использовать только что описанные блокировки X и S

для обеспечения того, чтобы никогда не возникали проблемы, описанные ранее по совместному доступу к данным.
1. Транзакция, в которой требуется выполнить выборку кортежа, должна вначале приобрести блокировку S на этот кортеж.
2. Транзакция, в которой требуется выполнить обновление кортежа, должна вначале приобрести X блокировку на этот кортеж. В ином случае, если она уже владеет блокировкой S на этом кортеже, как происходит в ситуации, когда выполняется последовательность операций выборки и обновления (SELECT и UPDATE), то эта транзакция должна, как принято называть такое действие, расширить, или повысить уровень блокировки S до уровня X.
Запросы на получение блокировок обычно бывают неявными.

может быть немедленно удовлетворен из-за того, что он конфликтует с

блокировкой, которой уже владеет транзакция А, то В переходит в состояние ожидания. Транзакция В ожидает до тех пор, пока не появится возможность удовлетворить ее запрос на блокировку, а это может произойти не раньше, чем транзакция А освободит блокировку.
Безусловно, система должна обеспечить, чтобы транзакция в не ожидала до бесконечности (такая ситуация называется активным тупиком — livelock, или истощением ресурсов — starvation). Один из простых предотвращения такой ситуации состоит в том, чтобы запросы на блокировку обслуживались в порядке простой очереди ("первым поступил—первым обслуживается").
4. Блокировки X освобождаются по завершении
транзакции (COMMIT или ROLLBACK). Блокировки S также обычно освобождаются в
это время

действия, поэтому проблема потери какого-либо обновления не возникает. Итак, проблема

потерянного обновления свелась к другой проблеме! Новая проблема называется взаимоблокировкой

разорвала. Для обнаружения взаимоблокировки необходимо определить наличие цикла в графе

ожидания (Wait-For Graph). Так называется граф, который, показывает "кто кого ожидает". Чтобы разорвать взаимоблокировку, необходимо выбрать одну из транзакций, участвующих во взаимоблокировке (т.е. одну из транзакций, которые входят в состав цикла в графе ожидания), в качестве "жертвы" и выполнить ее откат, что позволяет освободить ее блокировки и дать возможность другим транзакциям продолжить свою работу.