Транзакции и целостность базы данных, параллелизм
Защита данных от возможных угрожающих ситуаций как предметных так и случайных.
Риск потери данных:
- Система разрушается во время выполнения некоторой проги, оставив БД в непредсказуемом состоянии;
- При выполнении 2х конкурирующих за данные программ;
- Данные могут быть испорчены преднамеренно;
- Обновления меняют БД недопустимым образом.
Система должна иметь функции защиты данных от подобных проблем: восстановление, параллелизм, защиту и целостность.
Восстановление – восстановление самой базы данных, т.е. возвращение базы данных в правильное состояние.
Принцип - избыточность на физическом уровне и скрыта от пользователя. Если любая часть информации, содержащаяся в базе данных, может быть реконструирована из другой хранимой в системе избыточной информации, значит, база данных восстанавливаема.
Транзакции
Принцип восстановления не зависит от того, является ли базовая система реляционной. Он связан с процессом транзакции.
Транзакция – это логическая единица работы.
Транзакция – не просто одиночная операция системы баз данных, а скорее согласование нескольких таких операций. В общем, это преобразование одного согласованного состояния базы данных в другое.
Система, поддерживающая процесс транзакции, обеспечивает гарантию, что если во время выполнения неких обновлений произошла ошибка (по любой причине), то все эти обновления будут аннулированы.
Системный компонент, обеспечивающий атомарность, называется администратором транзакций (или диспетчером транзакций), а ключами к его выполнению служат операторы COMMIT TRANSACTION и ROLLBACK TRANSACTION.
Оператор COMMIT сигнализирует об успешном окончании транзакции. Он сообщает, что логическая единица работы завершена успешно, база данных вновь находится в согласованном состоянии, и все обновления теперь могут быть зафиксированы.
Оператор ROLLBACK сигнализирует о неудачном окончании транзакции. Он, что произошла какая-то ошибка, база данных находится в несогласованном состоянии и все обновления могут быть отменены, т.е. аннулированы.
Оператор COMMIT устанавливает так называемую точку фиксации – конец логической единицы работы. Термин "база данных" означает доступную для транзакции часть базы данных.
Аннулирование возможно благодаря журналу транзакций. Он содержит все детали операций обновления, в частности, старое и новое значения модифицируемого объекта.
СУБД выполняет операцию ROLLBACK неявно для любой программы, которая по какой-либо причине не достигла запланированного завершения операций. Однако в ряде случаев можно явно задать подтверждение и отмену транзакции (при создании триггеров).
Транзакция – это не только логическая единица работы, но также и единица восстановления при неудачном выполнении операций. При успешном выполнении система гарантирует, что обновления зафиксированы, даже если система рухнет в следующий момент времени.
Обновление произойдёт после COMMIT, но до того, как обновления будут физически записаны в БД (они могут оставаться в ОЗУ).
Даже если произошло обрушение системы, процедура перезагрузки должна установить эти обновления в БД, исследуя журнал транзакций. Из этого следует, что файлы регистрации транзакций должны быть физически записаны перед завершением операции COMMIT.
Это правило регистрации известно как протокол предварительной записи в журнал. З апись об операции осуществляется перед ее выполнением. Процедура перезагрузки сможет восстановить любые успешно завершенные транзакции, хотя их обновления не были записаны физически до аварийного отказа системы. => Транзакция действительно является единицей восстановления.
4 свойства транзакций:
Атомарность. Транзакции атомарны (выполняется все или ничего).
Согласованность. Транзакции защищают базу данных согласованно. Это означает, что транзакции переводят одно согласованное состояние базы данных в другое без обязательной поддержки согласованности во всех промежуточных точках.
Изоляция. Транзакции отделены одна от другой. Это означает, что, если даже будет запущено множество конкурирующих друг с другом транзакций, любое обновление определенной транзакции будет скрыто от остальных до тех пор, пока эта транзакция выполняется.
Долговечность. Когда транзакция выполнена, ее обновления сохраняются, даже если в следующий момент произойдет сбой системы.
Восстановление
Система должна быть готова к восстановлению не только после небольших локальных нарушений, таких как невыполнение операции в пределах определенной транзакции, но также и после глобальных нарушений типа сбоев в питании центрального процессорного устройства. Местное нарушение по определению поражает только транзакцию, в которой оно собственно и произошло. Глобальное нарушение поражает сразу все транзакции и, следовательно, приводит к значительным для системы последствиям.
Существует два вида глобальных нарушений.
- Отказы системы ( поражают все выполняющиеся в данный момент транзакции, но физически не нарушают базу данных в целом) – аварийным отказом программного обеспечения.
- Отказы носителей (поломка головок дискового накопителя) – аварийный отказ аппаратуры.
Следствие содержимого ОЗУ. Поскольку точное состояние выполняющейся транзакции неизвестно, то транзакция может не завершиться успешно и будет отменена при перезагрузке. Может потребоваться повторное выполнение транзакции, если нет физических обновлений этой транзакции.
В некотором предписанном интервале (когда в журнале накапливается определенное число записей) система автоматически принимает контрольную точку. Принятие контрольной точки включает физическую запись содержимого рабочих буферов базы данных непосредственно в базу данных и специальную физическую запись контрольной точки (список всех осуществляемых в данный момент транзакций).
Очевидно, что до перезагрузки системы Т3 и Т5 должны быть отменены. А Т2 и Т4 выполнены повторно. Т1 не включается в момент перезагрузки, т.к была выполнена до tc. Так же не включаются транзакции неудачные и отменённые перед tf. Во время перезагрузки система идентифицирует все транзакции от Т2 до Т5.
Шаги восстановления:
- Создается два списка транзакций: UNDO и REDO. В список UNDO заносятся все транзакции, предоставленные из записи контрольной точки, т.е. все транзакции, выполняющиеся в момент времени tc. Список REDO остается пустым;
- Осуществляется поиск в файле регистрации (журнале), начиная с записи контрольной точки;
- Если в файле регистрации обнаружена запись BEGIN TRANSACTION о начале транзакции, то эта транзакция также добавляется в список UNDO;
- Если в файле регистрации обнаружена запись COMMIT об окончании транзакции, то эта транзакция добавляется в список REDO;
- Когда достигается конец файла регистрации, списки UNDO и REDO анализируются для идентификации транзакций типа Т2 и Т4, появившихся в списке REDO, и транзакций типа ТЗ и Т5, оставшихся в списке UNDO;
- Транзакции в REDO удаляются из списка UNDO.
- После этого система просматривает назад файл регистрации, отменяя транзакции из UNDO, а затем просматривает снова вперед, повторно выполняя транзакции из REDO.
Обратное восстановление – восстановление базы данных в правильное состояние путем отмены выполненных операций.
Прямое восстановление – восстановление ее в правильное состояние повторным выполнением.
Параллелизм.
Параллелизм означает возможность одновременной обработки СУБД нескольких транзакций с доступом к одним и тем же данным в один и тот же момент времени.
В этом случае при обработке правильно составленных транзакций может возникнуть ситуации, которые могут привести к неправильным результатам из-за взаимных помех.
Основные проблемы при параллельной обработке транзакции:
Проблема результатов обновления транзакции
Транзакция A извлекает некий кортеж P в момент времени t1. Транзакция B извлекает некий кортеж P в момент времени t2.
Транзакция A обновляет некий кортеж P (на основе значений полученных в момент времени t1) в момент времени t3. Транзакция B обновляет тот же кортеж P (на основе значений полученных в момент времени t2) в момент времени t4.
Результат операции обновления A будет утерян, поскольку в момент времени t4, она не будет учтена, и потому будет отменена операцией обновления выполнения транзакции B.
Проблема незафиксированной зависимости
Эта проблема появляется, если с транзакцией B осуществляется извлечение (a) или что еще хуже обновление (b) некоторого кортежа, который в данный момент обрабатывает A, но это обновление еще не закончено.
Таким образом, если обновление не завершено, существует некоторая вероятность того, что оно не будет завершено никогда. В таком случае в первой транзакции будут принимать участие данные, которые не существуют.
Рис. a. Транзакция B в t2 встречается с невыполненным обновлением кортежа P, предположим, что это обновление меняется в момент времени t3. В результате B выполняется на основании фальшивого предположения, что кортеж P имеет значение в t2, хотя на самом деле значение в t1. В итоге выполнения транзакции B был получен неверный результат.
Рис. b. Транзакция B выполняет невыполнимое изменение, и результат обновления утрачивается в момент времени t3, поскольку результат отмены A в t3 приводит восстановление P к исходному значению в момент t1.