Попытка блокируется (процесс висит).

После фиксирования транзакции в Соединении 1 (COMMIT TRAN) будет выдан то же результат, без строк-фантомов.

После фиксирования транзакции читающего процесса в Соединении 1совместная блокировка с диапазона строк снята, модифицирующий процесс в окне Соединения 2 получит монопольную блокировку, которой он дожидается, и вставит строку.

Результат:

Рассмотрим этот процесс с уровнем изоляции REPEATABLE READ.

В Соединении 2 выполнена вставка, несмотря на незавершенную транзакцию в Соединении 1. После завершения транзакции в Соединении 1 выдается результат с добавленной строкой (фантомом).

Уровень изоляции SNAPSHOT

Нa уровне изоляции snapshot при чтении читающему процессу гарантируется получение последней зафиксированной версии строки, которая имеется в наличии в момент запуска транзакции.

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

Для разрешения работы на уровне изоляции snapshot необходимо установить параметр на уровне базы данных (ALTER DATABASE имя_базы SET ALLOW_SNAPSHOT_ISOLATION ON;)

Уровень изоляции snapshot предотвращает конфликты обновления, но в отличие от уровней изоляции repeatable read и serializable, делающих это генерацией взаимоблокировки, он аварийно завершает транзакцию, указывая, что обнаружен конфликт обновления.

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

Уровень изоляции READ COMMITTED SNAPSHOT

Уровень изоляции read committed snapshot также основан на версиях строк. Он отличается от уровня изоляции snapshot тем, что вместо последней зафиксированной версии строки, имевшейся в наличии при старте транзакции, читающий процесс получает последнюю зафиксированную версию строки, имевшуюся в момент старта инструкции.

Кроме того, уровень изоляции не обнаруживает конфликты обновления.

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

Для разрешения работы на уровне изоляции read committed snapshot необходимо установить параметр на уровне базы данных.

Сводные данные об уровнях изоляции.

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

Журнал транзакций

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

Database Engine сохраняет все записанные записи, их значения до и после изменения, в одном или более файлах, называемых протоколом транзакций.

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

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

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

Однако назначение журнала транзакций гораздо шире. Он предназначен для обеспечения надежного хранения данных в БД.

А это требование предполагает, в частности, возможность восстановления согласованного состояния базы данных после любого рода аппаратных и программных сбоев. Очевидно, что для выполнения восстановлений необходима некоторая дополнительная информация. В подавляющем большинстве современных реляционных СУБД такая избыточная дополнительная информация поддерживается в виде журнала изменений базы данных, чаще всего называемого Журналом транзакций.

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

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

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

Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.

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

· Индивидуальный откат транзакции.

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

o стандартной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK;

o аварийное завершение работы прикладной программы, которое логически эквивалентно выполнению оператора ROLLBACK, но физически имеет иной механизм выполнения;

o принудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. В подобном случае для выхода из тупика данная транзакция может быть выбрана в качестве "жертвы" и принудительно прекращено ее выполнение ядром СУБД.

· Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть в следующих случаях:

o при аварийном выключении электрического питания;

o при возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т. д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти.

· Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.

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

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

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