Транзакции. 3

     Основные данные о работе

 
Версия  шаблона 2.1
Филиал  
Вид работы Курсовая работа
Название  дисциплины Базы данных
Тема Транзакции
Фамилия студента  
Имя студента  
Отчество  студента  
№ контракта  

 

     Содержание

     Введение

 

     Понятие транзакции не входит в реляционную  модель данных, т.к. транзакции рассматриваются  не только в реляционных СУБД, но и в СУБД других типов, а также  и в других типах информационных систем.

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

     Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол фиксации транзакции). Также, в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.

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

     В этой курсовой работе обсуждаются тенденции  и перспективы обработки транзакций в применении к системам информационного  управления в целом. Рассматриваются, в частности, следующие вопросы:

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

     Концепция транзакций – неотъемлемая часть  любой клиент-серверной базы данных.

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

     Поддержание механизма транзакций – показатель уровня развитости СУБД. Корректное поддержание  транзакций одновременно является основой  обеспечения целостности БД. Транзакции также составляют основу изолированности в многопользовательских системах, где с одной БД параллельно могут работать несколько пользователей или прикладных программ. Одна из основных задач СУБД – обеспечение изолированности, т.е. создание такого режима функционирования, при котором каждому пользователю казалось бы, что БД доступна только ему. Такую задачу СУБД принято называть параллелизмом транзакций.

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

     Основная  часть

  1. Основы  обработки транзакций

     1.1 Свойства транзакций

 

     Транзакция – это неделимая с точки зрения воздействия на БД последовательность операторов манипулирования данными (чтения, удаления, вставки, модификации).

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

     Если  эта последовательность работ будет  прервана, то БД не будет соответствовать реальному объекту.

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

     Транзакция  переводит БД из одного устойчивого  состояния в другое.

     Транзакция  может быть представлена отдельной программой некоторого приложения или ее частью. Для транзакции возможны два варианта завершения:

     - если все операторы выполнены  успешно, транзакция фиксируется;  до фиксации транзакции допустимо  аннулирование произведенных ее  изменений, после фиксации результатов транзакции ее изменения становятся видимыми пользователю;

     - если нормальное завершение транзакции невозможно, осуществляется откат транзакции – ее результаты аннулируются.

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

     Свойства  транзакции:

     - атомарность – требует, чтобы транзакция (все операции (части) транзакции) выполнялась полностью либо не выполнялась совсем.

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

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

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

     Характеристики  транзакций описываются в терминах ACID (Atomicity, Consistency, Isolation, Durability – неделимость, согласованность, изолированность, устойчивость).

     Транзакция  неделима в том смысле, что представляет собой единое целое. Все ее компоненты либо имеют место, либо нет. Не бывает частичной транзакции. Если может  быть выполнена лишь часть транзакции, она отклоняется.

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

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

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

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

     1.2 Управление транзакциями

 

     выполняются внутри реляционной СУБД. Прежде всего, имеется в виду выполнение операторов INSERT, UPDATE и DELETE. Например, после создания таблицы (выполнения оператора CREATE TABLE) не нужно фиксировать результат: создание таблицы фиксируется в базе данных автоматически. Точно так же с помощью отмены транзакции не удастся восстановить только что удаленную оператором DROP TABLE таблицу.

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

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

     COMMIT – для сохранения изменений;

     ROLLBACK – для отмены изменений;

     SAVEPOINT – для установки особых точек возврата.

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

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

     Команда ROLLBACK предназначена для отмены транзакций, еще не сохраненных в базе данных. Она отменяет только те транзакции, которые были выполнены с момента выдачи последней команды COMMIT или ROLLBACK. 2

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

     SAVEPOINT имя_точки_сохранения

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

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

     ROLLBACK TO имя_точки_сохранения

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

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

     SQL Server поддерживает три вида определения  транзакций:

     - явное;

     - автоматическое;

     - подразумеваемое.

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

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

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

     1.3 Параллельное выполнение транзакций

 

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

     Основные  проблемы, которые возникают при  параллельном выполнении транзакций, делятся условно на 4 типа:

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

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

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

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

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

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

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

     Рассмотрим  существующие типы конфликтов между  двумя параллельными транзакциями. Можно выделить следующие типы:

  • W-W – транзакция 2 пытается изменять объект, измененный незакончившейся транзакцией 1;
  • R-W – транзакция 2 пытается изменять объект, прочитанный незакончившейся транзакцией 1;
  • W-R – транзакция 2 пытается читать объект, измененный незакончившейся транзакцией 1.

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

       
 
 
 
 

     2  Принципы и модели  обработки транзакций

     2.1  Плоские транзакции

 

     Транзакция  обладает четырьмя важными свойствами, известными как свойства ACID:

  • (Atomicity) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется. Требование атомарности транзакций утверждает, что не законченные или откатившиеся транзакции не должны оставлять следов в базе данных. Это означает, что данные должны храниться в базе данных с избыточностью, позволяющей иметь информацию, по которой восстанавливается состояние базы данных на момент начала неудачной транзакции. Такую избыточность обычно обеспечивает журнал транзакций3 (см. приложение 2).
  • (Consistency) Согласованность. Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции согласованность базы данных может нарушаться.
  • (Isolation) Изоляция. Транзакции разных пользователей не должны мешать друг другу (например, как если бы они выполнялись строго по очереди).
  • (Durability) Долговечность. Если транзакция выполнена, то результаты ее работы должны сохраниться в базе данных, даже если в следующий момент произойдет сбой системы.

     Транзакция  обычно начинается автоматически с  момента присоединения пользователя к СУБД и продолжается до тех пор, пока не произойдет одно из следующих  событий:

  • Подана команда COMMIT WORK (зафиксировать транзакцию).
  • Подана команда ROLLBACK WORK (откатить транзакцию).
  • Произошло отсоединение пользователя от СУБД.
  • Произошел сбой системы.

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

     При сбое системы происходят более сложные  процессы. Кратко суть их сводится к  тому, что при последующем запуске  системы происходит анализ выполнявшихся  до момента сбоя транзакций. Те транзакции, для которых была подана команда COMMIT WORK, но результаты работы которых не были занесены в базу данных выполняются снова (накатываются). Те транзакции, для которых не была подана команда COMMIT WORK, откатываются4.

     При отсоединении пользователя от СУБД происходит автоматическая фиксация транзакций.

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

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

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

     2.2 Режим блокировки

 

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

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

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

     блокировка  записи – транзакция блокирует строки в таблицах таким образом, что  запрос другой транзакции к этим строкам  будет отменен;

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

     В СУБД используют протокол доступа к  данным, позволяющий избежать проблемы параллелизма. Его суть заключается  в следующем:

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

     - транзакция, предназначенная для  модификации строки данных, накладывает  на нее блокировку записи;

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

     - блокировка записи сохраняется  вплоть до конца выполнения  транзакции.

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

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

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

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

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

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

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