Возможны следующие способы ведения журнальной информации

Содержание

Возможны следующие способы ведения журнальной информации
Возможны следующие способы ведения журнальной информации
Журнализация изменений БД
9 Транзакции и блокировки
Рекомендуемые файлы

Возможны следующие способы ведения журнальной информации

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

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

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

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

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

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

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

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

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

Источник

Возможны следующие способы ведения журнальной информации

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

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

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

Источник

Журнализация изменений БД

Метод временных меток

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

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

Для этого каждой транзакции T предписывается временная метка t, соответствующая времени начала T. При выполнении операции над объектом r транзакция T помечает его своей временной меткой и типом операции (чтение или изменение).

Перед выполнением операции над объектом r транзакция T1 выполняет следующие действия:

Проверяет, не закончилась ли транзакция T, пометившая этот объект. Если T закончилась, T1 помечает объект r и выполняет свою операцию.
Если транзакция T не завершилась, то T1 проверяет конфликтность операций. Если операции неконфликтны, при объекте r остается или проставляется временная метка с меньшим значением, и транзакция T1 выполняет свою операцию.
Если операции T1 и T конфликтуют, то если t(T) > t(T1) (т. е. транзакция T является более «молодой», чем T), производится откат T и T1 продолжает работу.
Если же t(T)

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

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

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

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

Источник

9 Транзакции и блокировки

2. Понятие транзакции

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

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

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

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

Определим транзакцию по вводу данных о вновь поступивших в библиотеку книгах. Эту операцию можно разбить на 2 последовательные: сначала ввод данных о книге – это новая строка в таблице Книги. Затем необходимо ввести данные обо всех экземплярах книги — это ввод набора новых строк в таблицу Экземпляры. Если эта последовательность действий будет прервана, то база данных не будет соответствовать реальному объекту, поэтому желательно выполнять ее как единую работу над базой данных.

3. Свойства транзакций. Способы завершения транзакций

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

Рекомендуемые файлы

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

Плоские транзакции характеризуются классическими свойствами: атомарности, согласованности, изолированности и долговечности.

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

· Свойство согласованности гарантирует, что по мере выполнения транзакции данные переходят из одного согласованного состояния в другое согласованное состояние — транзакция не разрушает взаимной согласованности данных.

· Свойство изолированности означает, что конкурирующие за доступ к БД транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.

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

Возможны 2 варианта завершения транзакции:

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

· Если в процессе выполнения транзакции произошел сбой, БД должна быть возвращена в исходное состояние. Откат транзакции – это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами SQL в теле текущей незавершенной транзакции.

4. Операторы Transact SQL для работы с транзакциями

В стандарте ANSI / ISO определены операторы СOMMIT и ROLLBACK, в стандарте начало транзакции неявно задается первым оператором модификации данных; Оператор COMMIT означает успешное завершение транзакции, результаты транзакции фиксируются во внешней памяти; при завершении транзакции оператором ROLLBACK результаты транзакции отменяются. Успешное завершение программы, в которой была инициирована транзакция, означает успешное завершение транзакции (как если бы был использован оператор COMMIT ), неуспешное завершение – прерывает транзакцию (как будто был использован оператор ROLLBACK ). В этой модели каждый оператор, изменяющий состояние данных, рассматривается как транзакция. Такая модель была реализована в первых версиях коммерческих СУБД. В дальнейшем в СУБД SYBASE была реализована расширенная модель транзакций.

В расширенной модели транзакций (например, в СУБД SQL SERVER) предусмотрен ряд дополнительных операций:

· оператор BEGIN TRANSACTION сообщает о начале транзакции;

· оператор COMMIT TRANSACTION сообщает об успешном завершении транзакции. Этот оператор, также как и COMMIT в модели стандарта ANSI/ISO, фиксирует все изменения, которые производились в БД в процессе выполнения транзакции;

· оператор SAVE TRANSACTION создает внутри транзакции точку сохранения, которая соответствует промежуточному состоянию БД, сохраненному на момент выполнения этого оператора. В операторе SAVE TRANSACTION может стоять имя точки сохранения, поэтому в ходе выполнения транзакции может быть запомнено несколько точек сохранения соответствующих нескольким промежуточным состояниям;

· оператор ROLLBACK имеет 2 модификации. Если он используется без дополнительного параметра, то он интерпретируется как оператор отката всей транзакции, если же он имеет параметр ROLLBACK n, то он интерпретируется как оператор частичного отката транзакции в точку сохранения n.

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

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

а возврат к обычной диалоговой обработке запросов:

Кроме того, имеется возможность установки AUTOCOMMIT, которую СУБД выполнит автоматически при регистрации, Если сеанс пользователя завершился аварийно, – например, произошел сбой системы, то текущая транзакция выполнит автоматический откат изменений. Не рекомендуется организовывать работу так, чтобы одиночные транзакции содержали много команд, тем более не связанных между собой. Это может привести к тому, что при отмене изменений будет выполнено слишком много действий, в том числе и тех, которые являются нужными и ошибки не вызвали. Лучший вариант, когда транзакция состоит из одной команды или нескольких тесно связанных команд.

Триггер выполняется как неявно определенная транзакция, поэтому внутри триггера допускается применение команд управления транзакциями. В частности, при обнаружении нарушения ограничений целостности для прерывания выполнения триггера и отмены всех изменений, которые пытался выполнить пользователь, необходимо использовать команду ROLLBACK TRANSACTION. В случае успешного завершения триггера можно использовать команду COMMIT TRANSACTION.
Выполнение команды ROLLBACK TRANSACTION или COMMIT TRANSACTION не прерывает работу триггера, поэтому следует внимательно отслеживать попытки многократного отката транзакции при выполнении разных условий.

SET balance= balance- 100

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

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

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

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

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

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

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

· Восстановление после поломки основного внешнего носителя БД (жесткий сбой).

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

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

Возможны два основных варианта ведения журнальной информации. В 1-м варианте для каждой транзакции поддерживается отдельный локальный журнал изменений БД этой транзакцией. Такие журналы называют локальными журналами. Они используются для локальных откатов транзакций. Кроме того, поддерживается общий журнал изменений БД, используемый для восстановления БД после мягких и жестких сбоев.

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

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

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

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

Имеется 2 варианта ведения журнала транзакций: протокол с отложенными обновлениями и протокол с немедленными обновлениями.

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

1. Когда транзакция Т1 начинается, в протокол заносится запись

2. На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение

3. Если все действия, из которых состоит транзакция, успешно выполнены, то транзакции частично фиксируется и в протокол заносится:

4. После того, как транзакция зафиксирована, записи протокола, относящиеся к Т1, используются для внесения изменений в БД.

5. Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Транзакцию Т1 необходимо переделать, если протокол содержит обе записи Т1 Begin Transaction и T 1 COMMT . БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется системная процедура REDO (), которая заменяет все значения элементов данных на новые, просматривая протокол в прямом порядке.

6. Если в протоколе не содержится команда фиксации транзакции С OMMIT , то никаких действий проводить не требуется, а транзакция запускается заново.

Альтернативный механизм с немедленным выполнением предусматривает внесение изменений сразу в БД, а в протокол заносятся не только новые, но и все старые значения изменяемых атрибутов, поэтому каждая запись выглядит так:

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

При откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу, начиная с команды BEGIN TRANSACTION.

Для восстановления при сбое используется следующий механизм:

· Если транзакция содержит команду начала транзакции, но не содержит команду фиксации с подтверждением ее выполнения, то выполняется последовательность действий как при откате транзакции, то есть восстанавливаются старые значения.

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

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

При параллельной обработке базы данных возникает три основных проблемы:

§ Пропавшие изменения . Эта ситуация возникает в тех случаях, когда 2 транзакции одновременно изменяют одну и ту же запись в БД. Например, работают 2 оператора на приеме заказов, первый оператор принял заказ на 30 мониторов. Когда он обращался на склад, то там числилось 40 мониторов, и он, получив подтверждение от клиента, оформил продажу 30 мониторов из 40. Параллельно с ним работает второй оператор, который принимает заказ на 20 таких же мониторов, и в свою очередь, обратившись на склад, он получает то же значение 40, и оформляет заказ для своего клиента. Заканчивая работу с данными, он выполняет команду Обновить, которая заносит 20 как остаток мониторов на складе. После этого первый оператор заканчивает работу со своим заказчиком и тоже выполняет команду Обновить, которая заносит остаток 10 как число мониторов, имеющихся на складе. В общей сложности они продали 50 мониторов при имеющихся 40, и при этом на складе будет числиться 10 мониторов.

§ Проблемы промежуточных данных . Связано с возможностью доступа к промежуточным данным. Допустим первый оператор, ведя переговоры со своим заказчиком, ввел заказанные 30 мониторов, но перед окончательным оформлением заказа клиент захотел выяснить еще некоторые характеристики товара. Приложение, с которым работает 1-й оператор, уже изменило остаток мониторов на складе, и там сейчас хранится информация о 10 оставшихся мониторах. В это время второй оператор пытается принять заказ от своего заказчика заказ на 20 мониторов, но его приложение показывает, что на складе осталось всего 10 мониторов и оператор вынужден отказать своему заказчику. В это время заказчик первого оператора принимает решение не покупать мониторы, оператор делает откат транзакции и на складе снова оказывается 40 мониторов. Такая ситуация стала возможной потому, что приложение второго оператора имело доступ к промежуточным данным, которые сформировало первое приложение.

§ Проблемы несогласованных данных. Связана с возможностью изменения данны x , уже прочитаны x другим приложением. Оба оператора начинают работать практически одновременно, получают начальное состояние склада 40 мониторов, а затем первый оператор продает своему заказчику 30 мониторов. Он завершает работу своего приложения, и оно выполняет команду фиксации транзакции COMMIT. Состояние БД непротиворечивое. В этот момент заказчик второго оператора решает сделать заказ и второй оператор, обращаясь повторно к данным, видит, что количество мониторов изменилось. Второй оператор считает, что нарушена целостность транзакции, т.к. в течение выполнения одной работы он получил 2 различных состояния склада. Эта ситуация возникла потому, что приложение 1-го оператора смогло изменить кортеж с данными, который уже прочитало приложение второго оператора.

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

· W-W – транзакция 2 пытается изменить объект, измененный не закончившейся транзакцией 1;

· R-W – транзакция 2 пытается изменить объект, прочитанный не закончившейся транзакцией 1;

· W-R транзакция 2 пытается читать объект, измененный не закончившейся транзакцией 1;

7. Сериалиация транзакций

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

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

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

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

Самым простым выходом было бы последовательное выполнение транзакций, но такой выход неоптимален по времени, существуют более гибкие методы управления параллельным доступом к БД. Наиболее распространенный механизм решения этих проблем блокировка объекта (например, таблицы) на все время действия транзакции. Если транзакция обращается к заблокированному объекту, то она остается в состоянии ожидания до момента разблокировки этого объекта, после чего она может начать его обработку. Однако блокировка создает новые проблемы — задержку выполнения транзакций из-за блокировок.

Итак, блокировки, называемые также синхронизационными захватами объектов, могут быть применены к разному типу объектов. Наибольшим объектом блокировки может быть вся БД, однако этот вид блокировки сделает БД недоступной для всех других приложений, которые работают с данной БД. Следующий тип объекта блокировки – таблицы. Транзакция, которая работает с таблицей, блокирует ее на все время выполнения транзакции. Этот вид блокировки предпочтительнее предыдущего, потому что позволяет параллельно выполнять транзакции, которые работают с другими таблицами.

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

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

8. Переопределение блокировок на уровне запроса. Типы блокировок

Если после имени таблицы в предложении FROM следует одно из перечисленных ключевых слов, запрос вмешивается в работу диспетчера блокировок и применяется заданный тип блокировки:

· NOLOCK- разрешает грязное чтение;

· PAGLOCK- блокировка на уровне страниц;

· ROWLOCK- блокировка на уровне записей;

· TABLOCK-разделяемая блокировка таблицы;

· TABLOCKX- монопольная блокировка таблицы

В настоящее время проблема блокировок является предметом большого числа исследований.

Различают два базовых типа блокировок (синхронизационных захватов):

Разделяемые (нежесткие) блокировки – это режим означает разделяемый захват объекта и используется для выполнения операции чтения объекта. Объекты, заблокированные таким образом, не изменяются в ходе выполнения транзакции и доступны другим транзакциям, но только в режиме чтения;

Монопольные (жесткие) блокировки – не позволяют вообще никому, кроме владельца этой блокировки, обращаться к данным. Эти блокировки используются для команд, которые изменяют содержание или структуру таблицы и действуют до конца транзакции.

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

Однако применение разных типов блокировок приводит к проблеме тупиков. Проблема тупиков возникла при рассмотрении выполнения параллельных процессов в операционных средах и также была связана с управлением разделяемыми (совместно используемыми) объектами. Пример тупика: Пусть транзакция А жестко блокирует таблицу 1, а затем жестко блокирует таблицу 2. Транзакция В, наоборот жестко блокирует таблицу 2, а затем жестко блокирует таблицу 1.

Если обе эти транзакции начали работу одновременно, то после выполнения операций модификации первой таблицы они обе окажутся в бесконечном ожидании: транзакция А будет ждать завершения работы транзакции В и разблокировки таблицы 2, а транзакция В будет безрезультатно ждать завершения работы транзакции А и разблокировки таблицы 1.

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

Основой обнаружения тупиковых ситуаций является построение (или постоянное поддержание) графа ожидания транзакций. Граф ожидания может представлять собой направленный граф, в вершинах которого расположены имена транзакций. Если транзакция Т1 ждет окончания транзакции Т2, то из вершины Т1 в вершину Т2 идет стрелка. Дополнительно стрелки могут быть помечены именами заблокированных объектов и типом блокировки.

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

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

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

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

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

9. КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Дайте определение транзакции. Приведите примеры транзакций.

2. Перечислите и охарактеризуйте свойства транзакций.

3. Какие возможны варианты завершения транзакций.

4. Какие операторы языка SQL служат для работы с транзакциями в расширенной модели транзакций?

5. Можно ли в триггерах использовать команды управления транзакциями?

6. Для чего предназначен журнал транзакций?

7. В каких случаях выполняется восстановление БД по журналу транзакций?

8. Какие варианты ведения журналов транзакций существуют?

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

10. Какие проблемы возникают при параллельной работе пользователей с БД?

Люди также интересуются этой лекцией: 30. Денатурация белка.

11. Какие объекты БД могут быть заблокированы для реализации принципа изолированности пользователей?

12. Возможно ли задание вида блокировки в запросах?

13. Какие виды захвата объектов несколькими транзакциями существуют? Какие из них являются совместимыми?

Источник