Учебное пособие Для студентов университетов Специальностей «Информатика», «Прикладная математика»

 
стояния  базы  будет  нарушаться  в  ходе  выполнения  транзакции.  Любая 
транзакция  завершается  одним  из  двух  возможных  способов.  В  случае 
успешного завершения результаты транзакции фиксируются (COMMIT) 
в БД, и последняя переходит в новое согласованное состояние. Если вы-
полнение  транзакции  не  увенчалось  успехом,  она  отменяется.  В  этом 
случае  в  базе  данных  должно  быть  восстановлено  то  согласованное  со-
стояние,  в  котором  она  находилась  до  начала  данной  транзакции.  Этот 
процесс  называется  откатом (ROLLBACK) транзакции.  Реализация  в 
СУБД принципа сохранения промежуточных состояний, подтверждения 
или  отката  транзакций  обеспечивается  специальным  механизмом,  для 
поддержки которого создается некоторая системная структура, называе-
мая журналом транзакций. Зафиксированная транзакция не может быть 
отменена.  
В  большинстве  языков  манипулирования  данными  для  указания  гра-
ниц 
отдельных 
транзакций 
используются 
операторы BEGIN 
TRANSACTION, COMMIT и ROLLBACK (или  их  эквиваленты).  Если 
эти  ограничители  не  были  использованы,  вся  выполняемая  программа 
расценивается  как  единая  транзакция.  СУБД  автоматически  выполнит 
команду COMMIT при нормальном завершении этой программы. Анало-
гично, в случае ее аварийного завершения в БД автоматически будет вы-
полнена команда ROLLBACK. 
Существуют  некоторые  свойства,  которыми  должна  обладать  любая 
из транзакций.  
1.  Атомарность.  Это  свойство  типа  «все  или  ничего».  Любая  тран-
закция  представляет  собой  неделимую  единицу  работы,  которая  может 
быть либо выполнена вся целиком, либо не выполнена вовсе. 
2. Согласованность. Каждая транзакция должна переводить базу дан-
ных из одного согласованного состояния в другое согласованное состоя-
ние. 
3. Изолированность. Все транзакции выполняются независимо одна от 
другой. Иначе говоря, промежуточные результаты незавершенной тран-
закции не должны быть доступны другим транзакциям. 
4.  Долговечность.  Результаты  успешно  завершенной  (зафиксирован-
ной)  транзакции  должны  сохраняться  в  базе  данных  постоянно  и  не 
должны быть утеряны в результате последующих сбоев. 
Важнейшей  целью  создания  баз  данных  является  организация  парал-
лельного доступа многих пользователей к общим данным, используемым 
ими совместно. Обеспечить параллельный доступ относительно неслож-
но, если все пользователи только читают данные, помещенные в базу. В 
этом случае работа каждого из них не оказывает никакого влияния на ра-
 
66

 
боту остальных пользователей. Однако если два или больше пользовате-
ля одновременно обращаются к БД и хотя бы один из них имеет целью 
обновить  хранимую  в  базе  информацию,  возможно  взаимное  влияние 
процессов  друг  на  друга,  способное  привести  к  несогласованности  дан-
ных. 
Рассмотрим  три  потенциальные  проблемы,  которые  могут  иметь  ме-
сто  при  параллельном  выполнении  транзакций:  проблему  потерянного 
обновления,  проблему  зависимости  от  нефиксированных  результатов  и 
проблему  несогласованной  обработки.  Если  обозначить  операции  чте-
ния,  записи  новых  значений  и  откат  транзакции  над  БД  соответственно 
как  R, W, O, то для первой транзакции это могут быть операции R
1
, W
1
, 
O
1
,  а  для  параллельно  выполняющейся  второй  транзакции  операции  R
2
, 
W
2
, O
2
. 
Проблема потерянного обновления возникает, когда результаты впол-
не успешно завершенной операции обновления одной транзакции могут 
быть перекрыты результатами выполнения другой транзакции. Эта про-
блема  может  возникнуть  в  результате  выполнения  последовательности 
операций R
1
, R
2
, W
2
, W
1
. 
Проблема  зависимости  от  нефиксированных  результатов  возникает 
в том случае, если одна из транзакций получит доступ к промежуточным 
результатам  выполнения  другой  транзакции  до  того,  как  они  будут  за-
фиксированы в базе данных. Может возникнуть в результате последова-
тельности операций R
1
, W
1
, R
2
, О
1
, W
2
. 
В  обоих  приведенных  выше  примерах  речь  шла  о  транзакциях,  вы-
полняющих  обновление  данных  в  базе,  наличие  взаимовлияния  между 
которыми  и  вызывало  разрушение  базы.  Однако  транзакции,  которые 
только считывают информацию из БД, также могут давать неверные ре-
зультаты, если им будут доступны для чтения промежуточные результа-
ты  одновременно  выполняющихся  и  еще  не  завершенных  транзакций, 
обновляющих информацию в базе. Возникает проблема несогласованной 
обработки. В некоторых случаях ее называют чтением мусора или непо-
вторяемостью  чтения.  Проблема  может  возникнуть  в  результате  вы-
полнения последовательности операторов R
1
, R
2
, W
1
, R
2
. В данном случае 
второе R
2
 означает считывание следующей порции данных. 
С управлением параллельностью или транзакциями в многопользова-
тельской СУБД связаны важные понятия сериализации транзакций и се-
риального  плана  выполнения  смеси  транзакций.  Под  сериализацией  па-
раллельно  выполняющихся  транзакций  понимается  такой  порядок  пла-
нирования их работы, при котором суммарный эффект смеси транзакций 
эквивалентен  эффекту  их  некоторого  последовательного  выполнения. 
 
67

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

жүктеу/скачать 2,58 Mb.

Достарыңызбен бөлісу: