13. Изолированность пользовате­лей.

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

уровни изолированности транзакций:

- отсутствие потерянных изменений. Т1 изменяет объект базы данных A. До завершения т1 т2 также изменяет объект A. Т2 завершается оператором ROLLBACK (например, по причине нарушения ограничений целостности). Тогда при повторном чтении объекта A т1 не видит изменений этого объекта, произведенных ранее. Такая ситуация называется ситуацией потерянных изменений. Чтобы избежать такой ситуации в т1 требуется, чтобы до завершения т1 никакая другая транзакция не могла изменять объект A. Отсутствие потерянных изменений является минимальным требованием к СУБД по части синхронизации параллельно выполняемых транзакций.

- отсутствие чтения "грязных данных". Т1 изменяет объект базы данных A. Параллельно с этим т2 читает объект A. Поскольку операция изменения еще не завершена, т2 видит несогласованные "грязные" данные. Это тоже не соответствует требованию изолированности пользователей. Чтобы избежать ситуации чтения "грязных" данных, до завершения т1, изменившей объект A, никакая другая транзакция не должна читать объект A.

- отсутствие неповторяющихся чтений. Т1 читает объект базы данных A. До завершения т1 т2 изменяет объект A и успешно завершается оператором COMMIT. Т1 повторно читает объект A и видит его измененное состояние. Чтобы избежать неповторяющихся чтений, до завершения т1 никакая другая транзакция не должна изменять объект A.

-проблема кортежей-"фантомов", Т1 выполняет оператор A выборки кортежей отношения R с условием выборки S (т.е. выбирается часть кортежей отношения R, удовлетворяющих условию S). До завершения т1 т2 вставляет в отношение R новый кортеж r, удовлетворяющий условию S, и успешно завершается. Т1 повторно выполняет оператор A, и в результате появляется кортеж, который отсутствовал при первом выполнении оператора. Чтобы избежать появления кортежей-фантомов, требуется более высокий "логический" уровень синхронизации транзакций.

15. Журнализация изменений бд. Журнализация и буферизация.

Одним из основных требований к развитым СУБД является надежность хранения баз данных. Для восстановления согласованного состояния БД после аппарат и програм сбоев поддерживается ЖИБД. В основе поддержания целостности состояния БД лежит механизм транзакции.

Общими принципами восстановления являются следующие:

-результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;

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

Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:

-Индивидуальный откат транзакции. 1)завершение оператором ROLLBACK. 2)откат транзакции инициируется системой. 3) исключительной ситуации в прикладной программе (например, деление на ноль) 4) выбор транзакции в качестве жертвы при обнаружении синхронизационного тупика.

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

-Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Основой восстановления является архивная копия и журнал изменений базы данных.

Возможны два основных варианта ведения журнальной информации.

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

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

Журнализация и буферизация

По причинам объективно существующей разницы в скорости работы процессоров и оперативной памяти и устройств внешней памяти буферизация страниц базы данных в оперативной памяти - единственный реальный способ достижения удовлетворительной эффективности СУБД.

Записть об изменении БД не записывается немедленно в ВЗУ. Записи буферизуются: при нормальной работе очередная страница выталкивается во внешнюю память журнала только при полном заполнении записями. Имеются два вида буферов - буфер журнала и буфер страниц ОП. И те, и другие буфера могут выталкиваться во внешнюю память. Проблема состоит в выработке некоторой общей политики выталкивания.

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

Основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) - "пиши сначала в журнал", и состоит в том, что если требуется вытолкнуть во внешнюю память измененный объект базы данных, то перед этим нужно гарантировать выталкивание во внешнюю память журнала записи о его изменении.