Основные подходы к обеспечению параллельного выполнения транзакций. Проблемы параллельного выполнения транзакций

Проблемы, возникающие при параллельном выполнении транзакций:

1. пропавшие изменения. Такая проблема может возникнуть, если две транзакции одновременно изменяют одну и ту же запись в БД. Изменения, сделанные второй программой, игнорируются первой программой.

2. проблема промежуточных данных. Такая проблема может возникнуть, если второе приложение имеет доступ к промежуточным данным, которые сформировало первое приложение.

3. проблемы несогласованных данных. Проблема возникает в случае, когда первое приложение может изменять кортеж с данными, который уже прочитало второе приложение.

4. проблема строк-призраков. Проблема возникает, если приложение выполняет два одинаковых запроса и получает два разных результата. БД находится в согласованном состоянии, но приложение работает некорректно.

Избежать таких проблем позволяет процедура согласованного выполнения параллельных транзакций:

- В ходе выполнения транзакции пользователь видит только согласованные данные. Пользователь не должен видеть несогласованных промежуточных данных.

- Когда в БД две транзакции выполняются параллельно, то СУБД гарантированно поддерживает принцип независимого выполнения транзакций, который гласит, что результаты выполнения транзакций будут такими же, как если бы вначале выполнялась транзакция 1, а потом транзакция 2, или наоборот, сначала транзакция 2, а потом транзакция 1.

Проблема пропавших изменений.

Проблемы, возникающие при параллельном выполнении транзакций:

1. пропавшие изменения

2. проблема промежуточных данных

3. проблемы несогласованных данных

4. проблема строк-призраков

Эта ситуация может возникать, если две транзакции одновременно изменяют одну и ту же запись в БД. Например, работают два оператора на приеме заказов, первый оператор принял заказ на 30 мониторов. Когда он запрашивал склад, то там числилось 40 мониторов, и он, получив подтверждение от клиента, выставил счет и оформил продажу 30 мониторов из 40. Параллельно с ним работает второй оператор, который принимает заказ на 20 таких же мониторов (ну уж очень хорошая модель и дешево) и, в свою очередь запросив состояние склада и получив исходно ту же цифру 40, он успешно оформляет заказ для своего клиента. Заканчивая работу с данным заказом, он выполняет команду Обновить (UPDATE), которая заносит 20 как остаток любимых мониторов на складе. Но после этого, наконец, любезно попрощавшись со своим клиентом и заверив его в скорейшей доставке заказанных мониторов, заканчивает работу со своим заказом первый оператор и также выполняет команду Обновить и заносит 10 как остаток тех же мониторов на складе. Каждый из них доволен своей работой, но мы-то знаем, что произошло. Прежде всего, они продали 50 мониторов из наличествующих 40 штук, и далее на складе еще числится 10 подобных мониторов. БД теперь находится в несогласованном состоянии, а у фирмы возникли серьезные проблемы. Изменения, сделанные вторым оператором, были проигнорированы программой выполнения заказа, с которой работал первый оператор.

Проблема промежуточных данных.

Проблема промежуточных данных. Такая проблема может возникнуть, если второе приложение имеет доступ к промежуточным данным, которые сформировало первое приложение.

Первый оператор ведет переговоры с заказчиком и указывает в заказе 30 мониторов, однако перед окончательным выставлением счета он намеревается уточнить некоторые характеристики товара. На диске уже зафиксированы изменения в остатках товара на складе, произведенные первым оператором (остаток – 10 ед. товара). В это время второй оператор работает над формированием собственного заказа на 20 ед. товара, и последние данные по остаткам товара не позволяют ему этот заказ сформировать; приложение второго оператора оканчивает работу. После уточнения характеристик покупаемого товара, первый заказчик отказывается от покупки 30 мониторов, и приложение первого оператора выполняет откат транзакции, возвращая нас к исходному значению товара на складе в 40 ед. Такая ситуация сложилась по той причине, что в процессе выполнения второй транзакции был открыт доступ к данным, которые сформировала первая транзакция.

Проблема несогласованных данных.

Проблемы несогласованных данных. Проблема возникает в случае, когда первое приложение может изменять кортеж с данными, который уже прочитало второе приложение.

Представим себе, что, начиная работать почти одновременно, оба оператора получают информацию о наличие на складе 40 ед. товара. Первый оператор завершает переговоры со своим клиентом и продает ему 30 ед. товара; транзакция завершается оператором COMMIT. Состояние базы данных расценивается как непротиворечивое. Пока второй оператор согласовывал условия заказа, он получает новое состояние склада, которое уже успело измениться. База данных находится в непротиворечивом состоянии, однако второй оператор считает, что нарушена целостность выполнения его транзакции. Это состояние возникло по той причине, что транзакция первого оператора смогла изменить кортеж с данными, который уже был прочитан второй транзакцией.

Проблема данных–призраков.

Проблема строк-призраков. Проблема возникает, если приложение выполняет два одинаковых запроса и получает два разных результата. БД находится в согласованном состоянии, но приложение работает некорректно.

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