Мобильное

Выполняется транзакция на сумму – что это СМС значит. Что такое транзакция по банковской карте

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

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

Нужно иметь в виду, что мошенничеством является любая транзакция с Вашей карточкой, совершаемая не вами. Существует несколько видов мошенничества:

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

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

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

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

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 , который будет автоматически запоминать все выполняемые команды, причем действия, которые привели к ошибке, всегда будут автоматически отменены. Обычно этот режим устанавливается с помощью команды типа:

SET AUTOCOMMIT ON ;

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

SET AUTOCOMMIT OFF ;

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

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

Пример транзакции :

BEGIN TRAN

UPDATE account

SET balance= balance- 100

If @@ error=0

BEGIN

ROLLBACK TRAN

RETURN

END

UPDATE card_account

SET balance=balance+100

WHERE account_number=@s_account

If @@ error=0

BEGIN

ROLLBACK TRAN

RETURN

END

COMMIT TRAN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Т1 Begin Transaction

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

Т1. ID _ RECORD , атрибут, новое значение

(ID _ RECORD – уникальный номер записи)

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

T 1 COMMT

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

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

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

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

Т1. ID _ RECORD , атрибут, новое значение старое значение

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

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

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

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

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

6. Блокировки.

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

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

§ Пропавшие изменения . Эта ситуация возникает в тех случаях, когда 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. Какие проблемы возникают при параллельной работе пользователей с БД?

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

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

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

14. В чем заключается проблема тупиков?

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

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

Плоские, или традиционные, транзакции, характеризуются четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) - ACID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее:

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

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

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

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

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

Фиксация транзакции - это действие, обеспечивающее запись на диск изменений в базе данных, которые были сделаны в процессе выполнения транзакции.

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

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

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

В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов COMMIT и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем или содержащегося в программе, изменяющего текущее состояние базы данных. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных путей (рис. 11.1):

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

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

успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор COMMIT);

ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).

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

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

Оператор BEGIN TRANSACTION сообщает о начале транзакции. В отличие от модели в стандарте ANSI/ISO, где начало транзакции неявно задается первым оператором модификации данных, в модели SYBASE начало транзакции задается явно с помощью оператора начала транзакции.

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

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

Оператор ROLLBACK имеет две модификации. Если этот оператор используется без дополнительного параметра, то он интерпретируется как оператор отката всей транзакции, то есть в этом случае он эквивалентен оператору отката ROLLBACK в модели ANSI/ISO. Если же оператор отката имеет параметр и записан в виде ROLLBACK В, то он интерпретируется как оператор частичного отката транзакции в точку сохранения В.

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

Транзакция начинается явным оператором начала транзакции, который имеет в нашей схеме номер 1. Далее идет оператор 2, который является оператором поиска и не меняет текущее состояние БД, а следующие за ним операторы 3 и 4 переводят базу данных уже в новое состояние. Оператор 5 сохраняет это новое промежуточное состояние БД и помечает его как промежуточное состояние в точке А. Далее следуют операторы 6 и 7, которые переводят базу данных в новое состояние. А оператор 8 сохраняет это состояние как промежуточное состояние в точке В. Оператор 9 выполняет ввод новых данных, а оператор 10 проводит некоторую проверку условия 1; если условие 1 выполнено, то выполняется оператор 11, который проводит откат транзакции в промежуточное состояние В Это означает, что последствия действий оператора 9 как бы стираются и база данных снова возвращается в промежуточное состояние В, хотя после выполнения оператора 9 она уже находилась в новом состоянии И после отката транзакции вместо оператора 9, который выполнялся раньше из состояния В БД, выполняется оператор 13 ввода новых данных, и далее управление передается оператору 14 Оператор 14 снова проверяет условие, но уже некоторое новое условие 2, если условие выполнено, то управление передается оператору 15, который выполняет откат транзакции в промежуточное состояние А, то есть все операторы, которые изменяли БД, начиная с 6 и заканчивая 13, считаются невыполненными, то есть результаты их выполнения исчезли и мы снова находимся в состоянии А, как после выполнения оператора 4 Далее управление передается оператору 17, который обновляет содержимое БД, после этого управление передается оператору 18, который связан с проверкой условия 3 Проверка заканчивается либо передачей управления оператору 20, который фиксирует транзакцию, и БД переходит в новое устойчивое состояние, и изменить его в рамках текущей транзакции невозможно Либо, если управление передано оператору 19, то транзакция откатывается к началу и БД возвращается в свое начальное состояние, а все промежуточные состояния здесь уже проверены, и выполнить операцию отката в эти промежуточные состояния после выполнения оператора 19 невозможно

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

Модели транзакций классифицируются на основании различных свойств:

структура транзакции;

параллельность внутри транзакции;

продолжительность.

Типы транзакций:

1. Плоские (классические)

2. Цепочечные

3. Вложенные

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

атомарность;

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

изолированность;

долговечность (прочность).

Иногда данные транзакции называются ACID-транзакциями.

ACID – Atomicity, Consistency, Isolation, Durability.

Упомянутые выше свойства означают следующее:

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

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

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

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

Варианты завершения транзакций:

1. Если все операторы выполнены успешно и в процессе выполнения транзакции не произошло никаких сбоев программного или аппаратного обеспечения, то транзакция фиксируется.

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

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

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

В стандарте ANSI/ISO SQL транзакция завершается одним из 4-х возможных путей (рис. 1):

Рис. 1. Модель транзакций ANSI/ISO

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

2. оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в БД в рамках этой транзакции; новая транзакция начинается непосредственно после использования ROLLBACK;

3. успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор COMMIT);

4. ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).

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

Восстановление после жесткого сбоя

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

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

Параллельное выполнение транзакций

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

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

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

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

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

В выполнении операции задействованы три стороны:

банк-эквайер, обслуживающий выбранную торговую точку (именно его POS-терминал установлен в магазине);
банк-эмитент, обслуживающий платежную банковскую карту;
международная платежная система, являющаяся промежуточным звеном при проведении расчетных операций (Visa, MasterCard и т. д.).

Порядок онлайн-транзакций

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

Полученные данные передаются банком-эквайером в центр обработки данных (ЦОД) международной платежной системы, обслуживающей карту.

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

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

Ответ банка-эмитента направляется обратно, через ЦОД, к банку-эквайеру и магазину. Реквизиты платежа выводятся на чек, который передается покупателю.

Особенности онлайн и оффлайн-операций

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

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

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

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

Запрет и отмена транзакций

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

Самые распространенные из них:

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

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

Проще всего отменить операцию в тот день, в который она совершалась.