Мониторы транзакций

Технологии реплицирования данных.

Технологии объектного связывания данных.

Мониторы транзакций.

РАСПРЕДЕЛЕННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ (часть 2)

Лекция № 9

Вопросы:

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

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

• потерянные изменения;

• «грязные» данные;

• неповторяющиеся чтения.

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

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

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

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

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

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

□ синхронизационные захваты (блокировки) объектов базы данных;

□ временные метки объектов базы данных.

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

Наиболее распространенным вариантом первого подхода является реализация двухфазного протокола синхронизаци­онных захватов (блокировок) объектов базы данных — 2PL (Two-Phase Locks). В соответствии сданным протоколом выполнение транзакции происходит в два этапа. На первом этапе {первая фаза) перед выполнением любой операции транзакция запрашивает и накапливает захваты необходимых объектов в со­ответствующем режиме. После получения и накопления необхо­димых захватов (блокировок) осуществляется вторая фаза — фиксация изменений (или откат по соображениям целостности данных) и освобождение захватов.

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

Существенным недостатком синхронизационных захва­тов является возможность возникновения тупиковых ситуа­ций (Deadlock). Предположим, одна транзакция на первой фазе установила монопольный захват одного объекта, а другая тран­закция монопольный захват второго объекта. Для осуществле­ния полного набора своих операций первой транзакции еще тре­буется совместный захват второго объекта, а второй транзак­ции, соответственно, совместный захват первого объекта. Ни одна из транзакций не может закончить первую фазу, т. е. пол­ностью накопить все необходимые захваты, так как требуемые объекты уже монопольно захвачены, хотя были свободны к мо­менту начала осуществления транзакций.

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

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

Более простой альтернативой технике синхронизационных захватов является техника временных меток. Суть этого ме­тода заключается в том, что каждой транзакции приписывает­ся временная метка, соответствующая моменту начала вы­полнения транзакции. При выполнении операции над объектом транзакция «помечает» его своей меткой и типом операции (чтение или изменение). Если при этом другой транзакции тре­буется операция над уже «помеченным» объектом, то выполня­ются действия по следующему алгоритму:

• проверяется, не закончилась ли транзакция, первой «по­метившая» объект;

• если первая транзакция закончилась, то вторая транзак­ция помечает его своей меткой и выполняет необходимые опе­рации;

• если первая транзакция не закончилась, то проверяется конфликтность операций (напомним, что конфликтно любое сочетание, кроме «чтение-чтение»);

• если операции неконфликтны, то они выполняются для обеих транзакций, а объект до завершения операций помечает­ся меткой более поздней, т. е. более молодой транзакции;

• если операции конфликтны, то далее происходит откат более поздней транзакции и выполняется операция более ран­ней (старшей) транзакции, а после ее завершения объект поме­чается меткой более молодой транзакции и цикл действий по­вторяется.

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

СУБД идеологии «Клиент-сервер», называемые иногда в противовес однопользовательским («настольным») «тяжелыми» системами (Oracle, SyBase, Informix, Ingres и др.), составляют одно из наиболее интенсивно развивающихся направлений цен­трализованных многопользовательских систем, охватывая сво­им управлением сотни тысяч гигабайтов фактографических дан­ных, и в этом отношении еще долгое время будут играть роль фактического стандарта корпоративных информационных си­стем.

Дата добавления: 2014-01-03