Атомарность

Атомарная транзакция – это такая транзакция, в которой либо выполняются все содержащиеся в ней действия с базой данных, либо не выполняется ни одно из них.

Долговечность или устойчивость

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

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

Согласованность

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

Рассмотрим следующий обновля­ющий SQL-оператор:

Предположим, что в таблице КЛИЕНТ имеется 500 000 строк, и в 500 из них атрибут Индекс имеет значение «98050». Чтобы найти все эти 500 строк, СУБД потребуется некоторое время. Будет ли на протяжении этого времени разрешено другим транзакциям обновлять поля КодРегиона и Индекс таблицы КЛИЕНТ? Если SQL-оператор является согласованным, такие обновления будут запрещены. Об­новление будет применено к набору строк в том виде, в каком они существовали в момент запуска SQL-оператора. Такая согласованность называется согласованностью па уровне оператора (statement level consistency).

54. Свойства транзакций: изолированность транзакции, уровни изоляции.

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

Проблемы при параллельной обработке:

• «грязное» чтение,

• невоспроизводимое чтение,

• фантомное чтение.

«Грязное» чтение (dirty read) – чтение транз­акцией записи, которая изменена, но еще не записана в базу данных. Это может произойти, например, когда одна транзакция считывает строку, измененную другой незавершенной транзакцией, а эта другая транзакция впоследствии отменяется.

Невоспроизводимое чтение (nonrepeatable reads) – это ситуация, когда при повторном чтении данных, уже считанных ранее, транзакция обнаруживает мо­дификации или удаления, вызванные другой завершенной транзакцией.

Фантомное чтение (phantom reads) – это ситуация, когда при повторном чтении данных транзакция обнаруживает новые строки, вставленные другой за­вершенной транзакцией после предыдущего чтения.

В стандарте языка SQL 1992 г. определены 4 уровня изоляции транзакций, которые определяют допустимость перечисленных выше проблем:

1. незавершенное чтение,

2. завершенное чтение,

3. воспроизводимое чтение,

4. сериализуемость.

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

Как можно видеть из табл. 1, уровень изоляции под названием «незавершен­ное чтение» (read uncommitted) допускает «грязное» чтение, невоспроизводимое чтение и фантомное чтение. Уровень изоляции «завершенное чтение» (read committed) предотвращает «грязное» чтение. Уровень изоляции «воспроизводи­мое чтение» (repeatable reads) предотвращает «грязное» чтение и невоспроизво­димое чтение. Уровень изоляции «сериализуемость» (serializable) не допускает возникновения ни одной из этих трех проблем.

55. Курсор. Типы курсоров.

Транзакция может открывать несколько курсоров – как последовательно, так и одновременно. Кроме того, на одной и той же таблице или ее SQL-представле­нии можно открыть два и более курсора. Поскольку курсоры потребляют значи­тельное количество памяти, то открытие нескольких курсоров, к примеру, для тысячи параллельных транзакций может оказаться накладным в отношении па­мяти и процессорного времени. Один из способов снизить потребление ресурсов при работе с курсорами – использовать курсоры с ограниченными возможностями в случаях, когда полнофункциональный курсор не требуется.

В табл. 2 перечислены четыре типа курсоров, используемых в среде Win­dows (в других системах типы курсоров аналогичны.) Простейший тип курсо­ра – последовательный (forward only cursor). Он позволяет приложению пере­двигаться по набору строк только вперед. Изменения, произведенные другими курсорами в данной транзакции, а также другими транзакциями, будут видны только в том случае, если затронутые ими строки находятся впереди курсора.

Таблица 2. Типы курсоров

Тип курсора	Описание	Свойства
Последовательный	Приложение может перебирать набор записей только в одном направлении — вперед	Изменения, производимые другими курсорами в данной транзакции или другими транзакциями, будут видимы только в том случае, если они затрагивают строки, находящиеся перед курсором
Статический	Приложение видит данные в том состоянии, в каком они были на момент открытия курсора	Изменения, производимые данным курсором, являются видимыми. Изменения, инициированные другими источниками, не видны. Перемещение курсора возможно в обоих направлениях
Ключевой	При открытии курсора для каждой строки набора записей сохраняется значение первичного ключа. Обращаясь к строке, приложение использует этот ключ для получения текущего значения строки	Обновления, вызванные любым источником, являются видимыми. Вставки из других источников не видны (в наборе записей для них нет ключей). Строки, вставляемые данным курсором, добавляются в конец набора записей. Изменения в порядке строк не видны. Если выставлен уровень изоляции «незавершенное чтение» (то есть допускается «грязное» чтение), то несохраненные обновления и удаления являются видимыми; в противном случае видны только сохраненные обновления и удаления
Динамический	Приложение видит любые изменения, вызванные любым источником	Все вставки, обновления, удаления и изменения в порядке записей являются видимыми. Если выставлен уровень изоляции «незавершенное чтение» (то есть допускается «грязное» чтение), то несохраненные изменения являются видимыми. В противном случае видны только сохраненные изменения

Остальные три типа курсоров называются двунаправленными курсорами (scroll­able cursors), поскольку приложение может передвигаться по набору записей как вперед, так и назад. Статический курсор (static cursor) обрабатывает «снимок» отношения, сделанный в момент открытия курсора. Изменения, сделанные таким курсором, являются видимыми для самого курсора; изменения из любых других источников являются невидимыми.

Ключевые курсоры (keyset cursors) соединяют в себе некоторые свойства ста­тических и динамических курсоров. При открытии такого курсора для каждой строки в наборе записей сохраняется значение первичного ключа. Когда прило­жение устанавливает курсор на некоторую строку, СУБД по ключу считывает текущее значение этой строки. Если приложение собирается обновить строку, которая была удалена другим курсором в этой же транзакции либо другой транз­акцией, СУБД создает новую строку со старым значением ключа и помещает в нее обновленные значения (если, конечно, заполнены все требуемые поля). Новые строки, вставленные другими курсорами данной транзакции или другими транзакциями, невидимы для ключевого курсора. Данный курсор видит лишь сохраненные обновления и удаления, если только уровень изоляции транзакции не допускает «грязного» чтения.

Динамический курсор (dynamic cursor) — это полнофункциональный курсор. Все вставки, обновления, удаления и изменения в порядке строк являются види­мыми для динамического курсора. Как и в случае с ключевыми курсорами, если уровень изоляции транзакции не допускает «грязного» чтения, курсор может ви­деть только сохраненные изменения.

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