1626434812-e667f6b6e7e69d3a0798830a58e9075b (844135), страница 7
Текст из файла (страница 7)
Откат в этом случае может производиться как к одной из точек промежуточной фиксации, так и к состоянию до начала выполнения транзакции. Точки промежуточной фиксации применяются в "длинных" транзакциях. Они позволяют разделить ее на нссколько отдельных фрагментов. 2 — 307 Базы данных. Интеллектуальная обработка ин4ормации Выполнение тела тренэекдии Исходное состояние БД БД со внесенными иаменениями Рис. 2.1. Возможные еарианты завершения транзакции Применение транзакций — эффективное механизм организации многопользовательского доступа к БД. Однако при реализации этого механизма СУБД приходится сталкиваться с целым рядом проблем. Во-первых, необходимо избежать потери изменений БД в ситуации, когда несколько программ читают одни и те же данные, изменяют их и пытаются записать результат на прежнее место.
В БД могут быть сохранены изменения, выполненные только одной программой, результаты работы всех остальных программ будут потеряны. Вовторых, требуется исключить возможность чтения незафиксированных изме- Глава 2. Системы обработки транзакций нений. Это может произойти в случае, когда одна транзакция вносит изменения в БД, они тут же считываются в другой транзакции, но затем другая транзакция прерывается оператором ВОБЛ.ВАСК %ОКК. Чтобы избежать этих проблем, должна быть использована специальная дисциплина совместной обработки (сериализации) транзакций. В ее основе лежат следующие принципы. 1) Транзакция не может получить доступ к незафиксированным данным, то есть к данным, в которых произведены изменения, но эти изменения еще не зафиксированы, 2) Результат совместного выполнения транзакций должен быть эквивалентен результату их последовательного выполнения.
То есть, если две транзакции выполняются параллельно, то полагается, что результат будет такой же, как если бы сначала выполнялась первая, а затем вторая транзакция, или сначала вторая. а потом первая. В современных СУБД сериализация транзакций реализуется через механизм блокировок. На время выполнения транзакции СУБД блокирует часть БД (отношение, строку или группу строк), к которой транзакция обращается.
Блокировка сохраняется до момента фиксации транзакции. Если в процессе параллельной обработки другой транзакции делается попытка обратиться к блокированным данным, обработка транзакции приостанавливается и возобновляется только после завершения транзакции, заблокировавшей данные и снятия блокировки. При выполнении транзакции современные СУБД могут блокировать всю БД, отношение, группу строк или отдельную строку. Очевидно, что чем больше блокируемый элемент данных, тем медленнее СУБД обрабатывает транзакции — велико время ожидания снятия блокировок. При работе в режиме оперативного доступа к БД, как правило, реализуется блокировка на уровне отдельных строк.
В этом случае можно добиться максимальной производительности за счет того, что блокируемый объект — минимальная структурная единица БД. Транзакции могут попасть в ситуацию взаимоблокировки. Проиллюстрируем это примером. Пусть транзакция Т, обновляет отношение О,, блокируя некоторые его строки. Далее эта транзакция пытается модифицировать данные отношения О„которые уже заблокированы транзакцией Т,.
Транзакция Т, переводится в состояния ожидания снятия блокировки с отношения О,. В этот же момент транзакция Т, пытается изменить данные отношения О„заблокированные транзакцией Т,. СУБД вынуждена перевести в состояние ожидания и транзакцию Т,. Налицо ситуация взаимоблокировки транзакций, которая может не разрешиться, если СУБД не предпримет специальные меры. Для предотвращения таких ситуаций СУБД периодически проверяет блокировки, ус- Зб Базы данных. Интеллектуальная обработка инфор нации тановленные выполняющимися транзакциями, Если обнаруживается ситуация взаимоблокировки.
то одна из транзакций, вызвавших эту ситуацию„прерывается. Это разрешает тупиковые ситуации. Программа, которая сгенерировала прерванную транзакцию, получает сообщение об ошибке. Для того чтобы избежать взаимоблокировок, стараются в каждой транзакции обновление отношений делать в одной и той же последовательности. Так, в приведенном примере следовало бы сначала изменить отношение О,, а потом О,. Современные информационные системы работают с распределенными БД, поэтому в одной транзакции могут модифицироваться отношения, физически хранящиеся на удаленных вычислительных системах.
Транзакция, обновляющая данные на нескольких узлах сети, называется распределенной. Если транзакция работает с БД, расположенной на одном узле, то ее называют локальной. Таким образом, логически распределенная транзакция состоит из нескольких локальных. С точки зрения пользователя, локальные и глобальные транзакции должны обрабатываться одинаково, то есть СУБД должна организовать процесс выполнения распределенной транзакции так, чтобы все локальные транзакции, входящие в нее, синхронно фиксировались на затрагиваемых ими узлах распределенной системы. Однако распределенная транзакция должна фиксироваться только в случае, когда зафиксированы все локальные транзакции, ее составляющие. Если прерывается хотя бы одна из локальных транзакций, должна быть прервана и распределенная транзакция.
Для практической реализации этих требований в СУБД используют механизм двухстадийной фиксации транзакций (Ью ржаве сопппй). При его использовании фиксация распределенных транзакций осуществляется в два этапа (стадии). На первой стадии сервер БД, фиксирующий распределенную транзакцию, посылает команду "приготовиться к фиксации" всем узлам сети (серверам БД), задействованным для выполнения локальных транзакций, инициированных распределенной транзакцией. Все серверы локальных БД должны в ответ сообщить, что они готовы к фиксации, Если хотя бы от одного из серверов ответ не получен, например, если имела место программная или аппаратная ошибка при выполнении локальной транзакции, то сервер распределенной БД производит откат локальных транзакций на всех узлах, включая те, которые прислали оповещение о готовности к фиксации. Вторая стадия начинается, когда все локальные СУБД готовы к фиксации.
Сервер, обрабатывающий распределенную транзакцию, заканчивает ее фиксацию, посылая команду "зафиксировать транзакцию" всем локальным серверам. Описанный механизм фиксации гарантирует синхронную фиксацию распределенной транзакции на всех узлах сети. Глава 2. Системы обработки транзакций 2.3. Тиражирование данных Описанный подход выполнения транзакций в распределенных системах— не единственно возможный. Альтернатива ему — технология тиражирования данных. Эта технология предполагает отказ от распределенности данных — во всех узлах вычислительной системы должна находится своя копия БД. Средства тиражирования автоматически поддерживают согласованное состояние информации в нескольких БД посредством копирования изменений, вносимых в любую из них.
Любая транзакция в такой системе выполняется локально, поэтому нет необходимости в сложной процедуре фиксации, Узкое место такого подхода — обеспечение тождественности данных в узлах сети. Процесс переноса изменений исходной БД в базы, принадлежащие различным узлам распределенной системы, принято называть тиражированием данных. Функции тиражирования данных выполняет специальный модуль СУБД вЂ” сервер тиражирования данных ~репликатор). При любых изменениях в тиражируемых данных репликатор копирует их на все остальные узлы системы.
Схема тиражирования может быть построена на полном обновлении содержимого таблицы на удаленных серверах (схема с полным обновлением) или же на обновлении только изменившихся записей (быстрое обновление). Если в системе нет необходимости поддерживать постоянную идентичности данных, и БД узлов должны согласовываться лишь периодически, репликатор накапливает изменения и в нужные моменты времени копирует их на другие узлы. Процесс тиражирования данных скрыт от прикладных программ пользователей, репликатор автоматически поддерживает БД в согласованном состоянии.
При использовании технологии тиражирования уменьшается трафик, так как все запросы обрабатываются локальной СУБД, а на другие узлы передаются только изменения в данных, увеличивается скорость доступа к данным. Кроме того, обрыв связи между узлами не останавливает обработку данных. Однако эта технология не лишена недостатков. Так, невозможно полностью исключить конфликты, возникающие при одновременном изменении одних и тех же данных на разных узлах. При переносе этих изменений в узлах вычислительной системы могут оказаться несогласованные копии БД, в результате чего пользователи различных узлов распределенной БД будут получать разные ответы на одни и те же запросы. 2.4.
Средства восстановления после сбоев Одно из основных требований к современным 01.ТР-системам — надежность хранения данных. СУБД должна уметь восстанавливать согласованное состояние базы данных после любых аппаратных и программных сбоев. Для восстановления после сбоев СУБД использует журнал транзакций, который содержит последовательность записей, описывающих изменения в БД.
Базы даииых. Иителлектуалъиая обработка иифорнации Общий принцип восстановления после сбоя таков — результаты выполнения транзакций, зафиксированных до сбоя, должны присутствовать в восстановленной БД, результаты незафиксированных транзакций в ней должны отсутствовать. То есть восстанавливается последнее до сбоя согласованное состояние базы данных. Процесс восстановления основан на механизме отката незавершенных транзакций, который описан ранее. Конечно, журнал транзакций не поможет, если содержимое внешней памяти системы физически уничтожено, то есть утеряна вся информация БД.
Для того чтобы избежать подобных ситуаций. реализуют дублированное хранение данных, например, зеркалирование дискового пространства — запись данных одновременно на несколько устройств. После сбоя копируется содержимое БД, а затем, как и в первом случае, на основе журнала откатываются все незавершенные транзакции.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
