Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
baz_dan / Главы8-12.doc
Скачиваний:
64
Добавлен:
12.03.2015
Размер:
1.67 Mб
Скачать

10.4. Восстановление системы.

        Система должна быть готова к восстановлению не только после небольших (например, невыполнение операций какой-либо транзакции), но и после глобальных нарушений типа сбоев в питании ЦПУ.        Глобальные нарушения поражают сразу все транзакции. Существуют два вида глобальных нарушений.

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

Рис.10.3. Этапы выполнения транзакций.

Транзакция Т1 – полностью сохраняется; Т2, Т4 – перезапускаются;

Т3 и Т5 – отменяются.

    1. 10.5. Параллельные операции над бд

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

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

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

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

    1. 10.6. Проблемы параллелизма

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соседние файлы в папке baz_dan