0. 3.2. Параллелизм операций над бд

        Термин параллелизм означает возможность одновременной обработки в СУБД многих транзакций с доступом к одним и тем же данным, причём в одно и то же время. В такой системе для корректной обработки параллельных транзакций без возникновения конфликтных ситуаций необходимо использовать некоторый метод управления параллелизмом.      В системе продажи авиабилетов, например, продавать билеты и изменять, списки пассажиров и число свободных мест могут одновременно несколько агентов. Главная проблема состоит в том, что если не позаботиться о правилах, регулирующих доступ к базе данных двух или более программ, то не исключается возможность продажи билетов на одно и то же место двум пассажирам. Интуиция подсказывает нам, что не следует допускать параллельное исполнение двух процессов, которые читают и изменяют значение одного и того же объекта.

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

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

           Существуют различные модели параллельных процессов применительно к операциям над базой данных. Эти модели различаются, в основном, степенью подробности описания доступа к её элементам. Как правило, чем в большей степени детализировать модель, тем большей параллелизм можно надёжно обеспечить.

0. 3.3. Проблемы параллельных процессов

       

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

1 – проблема потери результатов обновления, 2 – проблема незафиксированной зависимости,

3 - чтение «грязных» данных, 4 – проблема несовместимого анализа.

1).    Проблема потери результатов обновления

Рис.3.4. Потеря результатов обновления.

А – элемент БД; Т1, Т2 – транзакции; t-время

Транзакция  Т1 извлекает кортеж А в t1; Транзакция Т2 извлекает кортеж А в t2; Транзакция Т1 обновляет кортеж А (на основе значений, полученных в момент времени t1) в t3; Транзакция Т2 обновляет тот же кортеж А (на основе значений, полученных в момент t2, которые имеют те же значения, что и в t1) в момент t4. Однако результат операции обновления, выполняемой транзакцией Т1 будет утерян, поскольку в момент времени t4 она не будет учтена и потому будет «отменена» операцией обновления, выполненной транзакции Т2.

Пример 3.1. Пусть имеем две транзакции Т1 и Т2, обе эти транзакции представляют собой прогон программы Р.

 P:    А =5;     READ A;     A=A+1;     WRITE A;

Выполнение программы представлено на рис.3.5.

Рис.3.5. Выполнение программы Р.

Легко заметить (см.рис.3.5.), что хотя каждая транзакция добавляла к А единицу, его значение возросло лишь на 1. Это представляет серьёзную проблему, если, например А – число мест, проданных на определённый авиарейс.

2). Незафиксированная зависимость. Возникает, если с помощью некоторой транзакции осуществляется извлечение (или обновление) некоторого кортежа, который в данный момент обновляется другой транзакцией, но это обновление ещё не закончено.

Рис.3.6. Незафиксированная зависимость

Транзакция Т1 выполняется на основе фальшивого предположения, что кортеж А имеет некоторое значение в момент времени t2, тогда как на самом деле он имеет некоторое значение, существовавшее ещё в момент времени t1. В итоге после выполнения Т1 будет получен неверный результат.        Надо иметь ввиду, что отмена выполнения Т2 может произойти не по вине Т2, а, например, в результате краха системы.

3). Чтение «грязных» данных (фиктивные элементы - фантомы):

Рис.3.7. Чтение «грязных» данных

В промежутке между транзакциями была вставлена запись. При этом над частью данными были произведены действия.

Транзакция Т1 дважды выполняет выборку строк с одним и тем же условием. Между выборками вклинивается транзакция Т2, которая добавляет строку, удовлетворяющую условию отбора α. Т1 ничего не знает о существовании Т2, и так как сама она ничего не меняет в базе данных, то ожидает, что после повторного отбора будут отобраны те же самые строки. Результат: Транзакция Т1 в двух одинаковых выборках строк получит разные результаты.

4).    Проблема несовместимого анализа

Транзакция Т1 выполняет анализ по всей таблице, например, подсчитывает общую сумму денег на счетах клиентов банка для главного бухгалтера. Пусть на всех счетах находятся одинаковые суммы, например, по 1000у.е. Пусть имеются три счёта S1, S2, S3 и везде по 1000у.е.. Транзакция Т2 в этот момент выполняет перевод 500у.е. c счёта S3 на S1. Общая сумма по всем счетам не меняется.

Рис.3.8. Несовместимый анализ

Т1 – подводит баланс. Т2 – переводит суммы с одного счета на другой. Результат: Sum=2500, а должно быть Sum=3000. Это произошло из-за параллельной работы.

Конфликт транзакций

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

Различают конфликты: ·    W-W (Запись-Запись). Первая транзакция изменила объект и не закончилась. Вторая пытается изменить этот объект. Результат – потеря обновления. ·    R-W (Чтение-Запись) Первая транзакция прочитала объект и не закончилась. Вторая транзакция пытается изменить этот объект. Результат – несовместный анализ. ·    W-R (Запись-Чтение). 1-я транзакция изменила объект и не закончилась. 2-я пытается прочитать этот объект. Результат – чтение двух «грязных» файлов. Конфликты типа R-R (Чтение-чтение) отсутствуют, т.к. данные при чтении не изменяются.

Графики запуска транзакций могут быть:

1.    Последовательные – если транзакции выполняются строго по очереди. 2.    Чередующиеся – если график содержит чередующиеся элементарные операции транзакций. В первом случае процесс замедляется, но зато выполняется правило. Два графика называются эквивалентными, если при их выполнении будет получен один и тот же результат.     График запроса транзакции называется верным (сериализуемым), если он эквивалентен какому-либо последовательному запросу.

Замечание:         При выполнении двух различных последовательных (а, следовательно, верных) графиков, содержащих один и тот же набор транзакций, могут быть получены различные результаты. Пусть Т1 выполняет действие «сложить X с 1», а транзакция Т2 – «Удвоить X». Тогда последовательный график {Т1,Т2} даст результат 2(Х+1), а последовательный график {Т2,Т1} даст результат 2Х+1. Таким образом, может существовать несколько верных графиков запуска транзакций, приводящих к разным результатам при одном и том же начальном состоянии базы данных. Существуют два способа разрешить конкуренции между транзакциями.

1.    «Притормаживать» некоторые транзакции (таким образом обеспечить, чтобы конкурирующие транзакции выполнялись в разное время).

2.    Предоставить конкурирующим транзакциям «разные» экземпляры данных

1-ый реализуется путём использования блокировок

2-ой реализуется путём использования данных из журнала транзакций.