Презентация на тему Эксплуатация БД. Технология оперативной обработки транзакций

воздействия на БД последовательность операторов манипулирования данными (чтения, удаления,

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

целостности и безопасности БД.

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

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

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

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

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

начинается с первого SQL -оператора;
последующие SQL -операторы составляют тело

транзакции;
оператор COMMIT выполняется в случае успешного завершения обработки информации, объединенной в транзакцию; его выполнение фиксирует изменения, внесенные в базу данных текущей транзакцией;
оператор ROLLBACK (откат транзакции) прерывает выполнение транзакции и осуществляет отмену изменений, проведенных в ходе выполнения транзакции.

свойствами:
атомарности — это свойство означает: либо транзакция

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

состояния базы данных, необходимые для отката транзакций.

Сохранение требуемых

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

Журнал транзакций — важнейшая часть СУБД — используется не только с целью обеспечения работы механизма транзакций. Он предназначен для поддержки одного из основных требований к СУБД: надежности хранения данных во внешней памяти.

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

храниться особо надежно.

Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.

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

быть в состоянии восстановить последнее согласованное состояние БД после

любого аппаратного или программного сбоя.

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

СУБД (по причине ошибки в программе или в результате

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

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

состояние журнала и базы данных во внешней памяти.

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

относящиеся к операциям модификации обоих видов объектов.
Целью процесса

восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций, и которое не содержало бы никаких следов незаконченных транзакций.

незавершенных транзакций;
повторно воспроизвести те операции завершенных транзакций,

результаты которых не отображены во внешней памяти.

Для восстановления БД после жесткого сбоя журнала изменений базы данных явно недостаточно.
Основой восстановления последнего согласованного состояния базы данных после жесткого сбоя является журнал и архивная копия БД.

Архивная копия — это полная копия БД к моменту начала заполнения журнала.

одновременно работающих пользователей инициируют параллельные транзакции.
При параллельной обработке

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

будет утерян, поскольку в момент времени t4 она не

будет учтена, и потому будет отменена операцией обновления, выполненной транзакцией А2.
Что бы исключить такую ситуацию требуется, чтобы до завершения транзакции А1 никакая другая транзакция не могла изменять объект P.
Отсутствие потерянных изменений является минимальным требованием к СУБД в области синхронизации параллельно выполняемых транзакций

если помощью некоторой транзакции осуществляется извлечение (обновление) некоторого объекта,

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

Р. Параллельно с этим транзакция А2, читая объект Р,

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

например, транзакция А1 осуществляет вычисление некоторой статистической величины, скажем,

среднего значения, а транзакция А2 выполняет обновление кортежа РЗ, который еще только будет использован транзакцией А1.
Причем транзакция А1 не зависит от транзакции А2, так как транзакция А2 выполнила все обновления до того, как транзакция А1 извлекла кортеж РЗ

в СУБД должны использоваться какие-либо методы регулирования совместного выполнения

транзакций.

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

многопользовательской СУБД опирается на такие важные понятия, как:

сериализация транзакций и
сериальный план выполнения смеси транзакций.

планирования их работы, при котором суммарный эффект смеси транзакций

эквивалентен эффекту их некоторого последовательного выполнения.

Сериальный план выполнения смеси транзакций — это такой план, который приводит к сериализации транзакций.

СУБД, является механизм блокировок, или, иначе, механизм синхронизационных захватов,

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

доступа (монопольная блокировка);

S-блокировка — с взаимным доступом.

транзакция А блокирует кортеж Р без возможности взаимного доступа

(Х-блокировка), то запрос другой транзакции В с блокировкой этого кортежа Р будет отменен.

Если транзакция А блокирует кортеж Р с возможностью взаимного доступа, то запрос со стороны некоторой транзакции В на Х-блокировку кортежа будет отвергнут, а запрос со стороны некоторой транзакции В на S-блокировку кортежа Р будет принят.

указанных выше проблем параллельной работы нескольких пользователей необходимо придерживаться

следующей стратегии:

транзакция, предназначенная для извлечения кортежа, должна наложить S-блокировку на этот кортеж;

транзакция, предназначенная для обновления кортежа, должна наложить Х-блокировку на этот кортеж.

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

А, то транзакция В переходит в состояние ожидания.
Транзакция В будет находиться в состоянии ожидания до тех пор, пока не будет снята блокировка, заданная транзакцией А.

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

работе с ними есть свои особенности.
Проблемы параллельного выполнения двух транзакций:
Проблема потери результатов обновления.
Проблема незафиксированной зависимости.
Проблема несовместимого анализа.

блокировки для чередующихся операций складывается следующая ситуация:

А1 вызывает наложение на этот объект S-блокировки.
Такую же

блокировку объекта Р устанавливает транзакция А2 в момент времени t2. Операция обновления для транзакции А1 в момент времени t3 не будет выполнена, поскольку она является неявным запросом с заданием Х-блокировки для объекта Р, а этот запрос вступает в конфликт с S-блокировкой, уже заданной транзакцией А2.
Таким образом, транзакция А1 переходит в состояние ожидания. Транзакция А2 переходит в состояние ожидания в момент времени t4. Возникает конфликтная ситуация, которая получила название тупик.

согласно описанному выше протоколу блокировки:

не будет выполнена.
Дело в том, что она является

неявным запросом с заданием S-блокировки для объекта Р, а этот запрос вступает в конфликт с Х-блокировкой, уже заданной транзакцией А1.
Таким образом, транзакция А2 переходит в состояние ожидания до тех пор, пока не будет прекращено выполнение транзакции А1. Тогда заданная транзакцией А1 блокировка будет снята и транзакция А2 может быть выполнена.
Ее результаты в любом случае не будут зависеть от незафиксированного обновления.

блокировок будет развиваться следующим образом:

момент времени t3 не будет выполнена, так как для

ее реализации необходимо задать S-блокировку для этого кортежа, которая не может быть установлена поскольку на этот кортеж транзакцией А2 уже наложена Х-блокировка.
Транзакция А1 переходит в состояние ожидания. После завершения транзакции А2 и снятия с кортежа РЗ Х-блокировки транзакция А1 продолжит свою работу, однако полученный в итоге транзакции А1 результат будет неверен, так как транзакция А2 внесла свои коррективы в работу транзакции А1. Иными словами, транзакция А1 встретилась с несовместимым состоянием, которое блокировка в таком виде не смогла разрешить.

более транзакции одновременно находятся в состоянии ожидания, причем для

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

его должна обнаружить и разрешить система.

Поиск выхода из тупиковой

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

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