П. Г. Демидова А. В. Зафиевский А. А. Короткин А. Н. Лататуев Базы данных Учебное пособие

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

---

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

---

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