Главная страница
Библиотека (скачать книги)
Скачать софт
Введение в программирование
Стандарты для C++
Уроки по C#
Уроки по Python
HTML
Веб-дизайн
Ассемблер в среде Windows
ActiveX
Javascript
Общее о Линукс
Линукс - подробно
Линукс - новое
Delphi
Паскаль для начинающих
Турбопаскаль
Новости
Партнеры
Наши предложения
Архив новостей





Параллельная обработка транзакций
Когда несколько транзакций в одно и то же время работают с базой данных, такие транзакции называются параллельными транзакциями. За работой транзакций следит объект сервера БД, который условно можно назвать «менеджер обработки транзакций». Схематично он изображен на рис. 1.11. Несколько транзакций отправляют свои запросы данному менеджеру. Он в определенной последовательности, зависящей от сервера, выбирает транзакцию из списка и обрабатывает ее.
При параллельной обработке часто возникает ситуация, когда несколько транзакций обращаются к одной записи или к одному блоку записей и вносят в них изменения, не дождавшись освобождения ресурсов. Таким образом, получается, что транзакция, часть которой была выполнена, изменила блок данных и была «временно приостановлена», а другая транзакция, стоящая следующей в очереди менеджера обработки транзакций, также обратилась к этому блоку записей и также изменила его. Когда первая транзакция снова обратилась к данному блоку записей, он уже был изменен, и она продолжила работать уже с измененными данными. Одно из средств борьбы, против несогласованностей, вызванных параллельной обработкой транзакций, называется блокировкой ресурсов.

Блокировка ресурсов
Один из способов предотвратить проблемы при параллельной обработке —запретить совместное использование ресурсов путем блокировки данных, которые считываются для обновления. В этом случае, если блок записей или одна запись «заняты» какой-либо транзакцией, то другая транзакция не сможет их изменить.
Блокировки могут налагаться либо автоматически, по требованию СУБД, либо по запросу пользователя. Некоторые СУБД предусматривают блокировку ресурсов на уровне строк, другие — на уровне страницы, третьи — на уровне таблицы, четвертые — на уровне всей базы данных. Размер блокируемого ресурса называется глубиной детализации. В данном случае действует простое правило — чем глубже детализация, тем медленнее идет работа. При блокировке на уровне строк и большой «пользовательской нагрузке» СУБД может работать очень медленно, так как на блокировку будут производиться очень Понятие транзакции большие затраты ресурсов и времени. Наиболее часто применяется постраничная блокировка данных. При блокировке на уровне таблицы базы данных будут неизбежно возникать простои, особенно в тех случаях, когда пользователь запрашивает большие объемы данных.
Блокировки различаются также по типу. При монопольной блокировке полностью блокируется доступ к блоку данных. Коллективная блокировка блокирует блок данных от изменения, но не от чтения.
Сериализуемые транзакции и виды блокировок
Когда две или более транзакции обрабатываются параллельно, их результаты, сохраняемые в базе данных, должны быть логически согласованы с результатами, которые получились бы, если бы данные транзакции обрабатывались каким-нибудь последовательным способом. Такая схема обработки параллельных транзакций называется сериализуемой (serializable). Существует теорема, что сериализуемость транзакций заведомо гарантируется, если блокировки, относящиеся к одновременно выполняемым транзакциям, удовлетворяют правилу: «Ни одна блокировка от имени какой-либо транзакции не должна устанавливаться, пока не будет снята ранее установленная блокировка». Это правило известно под названием двухфазового блокирования. Транзакция сначала устанавливает блокировки, а потом сама же блокировки снимает.

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

Каждой транзакции приписывается некоторый уровень изоляции: READUNCOMMITTED (незавершенное чтение), READCOMMITTED (завершенное чтение), REPEATABLEREAD (воспроизводимое чтение) или SERIALIZABLE (сериализуемость). Уровень изоляции транзакции определяет степень, в которой на операции этой транзакции влияют операции параллельно выполняющихся транзакций и в которой операции данной транзакции влияют на операции других транзакций. Уровень изоляции может быть явно установлен оператором SETTRANSACTION. По умолчанию устанавливается уровень изоляции SERIALIZABLE. При выполнении конкурирующих транзакций на этом уровне изоляции гарантируется их сериализуемость. На рис. 1.12 показаны уровни изоляции транзакции и ошибки, которые могут на них возникать. Отсутствие на уровне SERIALIZABLE (сериализуемость) ошибок является следствием того, что такие транзакции являются сериализуемыми. Чем выше уровень транзакции, тем больше ресурсов требуется для ее обработки. Программист должен найти компромисс «производительность-достоверность». Например, уровень READUNCOMMITTED является наиболее быстродействующим, но в то же время на этом уровне возможны искажения данных. Вряд ли имеет смысл ставить уровень SERIALIZABLE на сервер, с которым работают 2-3 клиента, и вероятность того, что они обратятся к одной записи, весьма мала.



   
 

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru