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

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

Транзакция начинается неявно с первой команды SQL, выполняемой после команды COMMIT или ROLLBACK (или с начала сеанса) или же после команды ROLLBACK TO SAVEPOINT. Для управления транзакциями PL/SQL предоставляет набор команд:

COMMIT — сохраняет (фиксирует) все изменения, внесенные со времени выполнения последней команды COMMIT или ROLLBACK, и снимает все блокировки.
ROLLBACK — отменяет (откатывает) все изменения, внесенные со времени выполнения последней команды COMMIT или ROLLBACK, и снимает все блокировки.
ROLLBACK TO SAVEPOINT — отменяет все изменения со времени установки последней точки сохранения и снимает все блокировки, установленные в этой части кода.
SAVEPOINT — устанавливает точку сохранения, после чего становится возможным частичный откат транзакции.
SET TRANSACTION — позволяет начать сеанс чтения или чтения-записи, установить уровень изоляции или связать текущую транзакцию с заданным сегментом отката.
LOCK TABLE — позволяет заблокировать всю таблицу в указанном режиме. (По умолчанию к таблице обычно применяется блокировка на уровне строк.)

Эти команды более подробно рассматриваются в следующих разделах блога.

Команда COMMIT

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

COMMIT [WORK] [COMMENT текст];

Ключевое слово WORK не обязательно — оно только упрощает чтение кода.

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

Обратите внимание: команда COMMIT снимает все блокировки таблиц, установленные во время текущего сеанса (например, для команды SELECT FOR UPDATE). Кроме того, она удаляет все точки сохранения, установленные после выполнения последней команды COMMIT или ROLLBACK.

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

Все команды в следующем фрагменте являются допустимыми применениями COMMIT:

COMMIT;
COMMIT WORK;
COMMIT COMMENT 'maintaining account balance'.

Команда ROLLBACK

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

DELETE FROM orders;

«Нет, Нет! Я хотел удалить только те заказы, которые были сделаны до мая 2005 года!» Нет проблем — достаточно выполнить команду ROLLBACK. Что касается программирования приложений, в случае возникновения проблем откат позволяет вернуться к исходному состоянию.

Синтаксис команды ROLLBACK:

ROLLBACK [WORK] [TO [SAVEPOINT] имя_точки_сохранения];

Существует две основные разновидности ROLLBACK: без параметров и с секцией TO, указывающей, до какой точки сохранения следует произвести откат. Первая отменяет все изменения, выполненные в ходе текущей транзакции, а вторая отменяет все изменения и снимает все блокировки, установленные после заданной точки сохранения. (О том, как установить в приложении точку сохранения, рассказано в следующем разделе.) Имя точки сохранения представляет собой необъявленный идентификатор Oracle. Это не может быть литерал (заключенный в кавычки) или имя переменной.

Все команды ROLLBACK в следующем фрагменте действительны :

ROLLBACK;
ROLLBACK WORK;
ROLLBACK TO begin_cleanup;

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

Непосредственно перед выполнением команды INSERT, UPDATE, MERGE или DELETE PL/SQL автоматически устанавливает неявную точку сохранения, и если команда завершается ошибкой, выполняется автоматический откат до этой точки. Если в дальнейшем в ходе выполнения команды DML происходит сбой, выполняется автоматический откат до этой точки. Подобным образом отменяется только последняя команда DML.

Команда SAVEPOINT

Устанавливает в транзакции именованный маркер, позволяющий в случае необходимости выполнить откат до отмеченной точки сохранения. При таком откате отменяются все изменения и удаляются все блокировки после этой точки, но сохраняются изменения и блокировки, предшествовавшие ей. Синтаксис команды SAVEPOINT:

SAVEPOINT имя_точки_сохранения;

Здесь имя точки сохранения — необъявленный идентификатор. Он должен соответствовать общим правилам формирования идентификаторов Oracle (до 30 символов, начинается с буквы, состоит из букв, цифр и символов #, $ и _), но объявлять его не нужно (да и невозможно).

Область действия точки сохранения не ограничивается блоком PL/SQL, в котором она установлена. Если в ходе транзакции имя точки сохранения используется повторно, эта точка просто «перемещается» в новую позицию, причем независимо от процедуры, функции или анонимного блока, в котором выполняется команда SAVEPOINT. Если точка сохранения устанавливается в рекурсивной программе, на самом деле на каждом уровне рекурсии она задается заново, но откат может быть возможен только к одной точке — той, что установлена последней.

Команда SET TRANSACTION

Команда SET TRANSACTION позволяет начать сеанс чтения или чтения-записи, установить уровень изоляции или связать текущую транзакцию с заданным сегментом отката. Эта команда должна быть первой командой SQL транзакции и дважды использоваться в ходе одной транзакции не может. У нее имеются четыре разновидности.

SET TRANSACTION READ ONLY — определяет текущую транзакцию доступной «только для чтения». В транзакциях этого типа всем запросам доступны лишь те изменения, которые были зафиксированы до начала транзакции. Они применяются, в частности, в медленно формируемых отчетах со множеством запросов, благодаря чему в них часто используются строго согласованные данные.
SET TRANSACTION READ WRITE — определяет текущую транзакцию как операцию чтения и записи данных в таблицу.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE | READ COMMITTED — определяет способ выполнения транзакции, модифицирующей базу данных. С ее помощью можно задать один из двух уровней изоляции транзакции: SERIALIZABLE или READ COMMITTED. В первом случае команде DML, пытающейся модифицировать таблицу, которая уже изменена незафиксированной транзакцией, будет отказано в этой операции. Для выполнения этой команды в инициализационном параметре COMPATIBLE базы данных должна быть задана версия 7.3.0 и выше.При установке уровня READ COMMITED команда DML, которой требуется доступ к строке, заблокированной другой транзакцией, будет ждать снятия этой блокировки.
SET TRANSACTION USE ROLLBACK SEGMENT имя сегмента — назначает текущей транзакции заданный сегмент отката и определяет ей доступ «только для чтения». Не может использоваться совместно с командой SET TRANSACTION READ ONLY.

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

Команда LOCK TABLE

Команда блокирует всю таблицу базы данных в указанном режиме. Блокировка запрещает или разрешает модификацию данных таблицы со стороны других транзакций на то время, пока вы с ней работаете. Синтаксис команды LOCK TABLE:

LOCK TABLE список_таблиц IN режим_блокировки MODE [NOWAIT];

Здесь список таблиц — список из одной или нескольких таблиц (локальных таблиц/пред- ставлений или доступных через удаленное подключение), а режим блокировки — один из шести режимов: ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE.

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

Примеры допустимых команд LOCK TABLE:

LOCK TABLE emp IN ROW EXCLUSIVE MODE;
LOCK TABLE emp, dept IN SHARE MODE NOWAIT;
LOCK TABLE scott.emp@new_york IN SHARE UPDATE MODE;

Там, где это возможно, используйте стандартные средства блокировки Oracle. Команду LOCK TABLE в приложениях следует использовать только в крайних случаях и с величайшей осторожностью.

Вас заинтересует / Intresting for you:

Источник

20. Обработка транзакций

20.1. Что такое транзакция

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

Обработка транзакций обеспечивает сохранение целостности базы данных за счет того, что пакеты операций SQL полностью или не выполняются вовсе.

Рассмотрим процесс добавления нового заказа по этапам.

1. Проверка, содержится ли информация о клиенте в базе данных. Если нет, такая информация добавляется.

2. Выборка идентификатора клиента.

3. Добавление строки в таблицу Orders, связывающую строку с идентификатором клиента.

4. Выборка идентификатора нового заказа, присвоенного ему в таблице Orders.

Рекомендуемые материалы

5. Добавление одной строки в таблицу OrderItems для каждого заказанного предмета, соотнесение его с таблицей Orders посредством выбранного идентификатора и с таблицей Products посредством идентификатора продукта.

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

Что в этом случае случится с данными?

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

На что будет, если ошибка произойдет после того, как была добавлена строка в таблицу Orders, но до того, как будут добавлены строки в таблицу OrderItems? Теперь в базе данных будет присутствовать пустой заказ.

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

Как решается эта проблема? Необходимо применить транзактную организацию обработки данных, т.е. обработку транзакций.

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

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

1. Проверка, содержится ли информация о клиенте в базе данных. Если нет, такая информация добавляется.

2. Фиксация информации о клиенте.

3. Выборка идентификатора клиента.

4. Добавление строки в таблицу Orders, связывающую строку с идентификатором клиента.

5. Если во время добавления строки в таблицу Orders происходит ошибка, операция отменяется.

6. Выборка идентификатора нового заказа, присвоенного ему в таблице Orders.

7. Добавление одной строки в таблицу OrderItems для каждого заказанного предмета, соотнесение его с таблицей Orders посредством выбранного идентификатора и с таблицей Products посредством идентификатора продукта.

8. Если в процессе добавления строк в таблицу OrderItems происходит ошибка, добавление всех строк в таблицу OrderItems отменяется.

При работе с транзакциями определяются термины:

· Транзакция (Transaction). Блок операторов SQL.

· Отмена (Rollback). Процесс аннулирования указанных операторов SQL. (Другое название — откат).

· Фиксация (Commit). Запись несохраненных операторов SQL в таблицы базы данных.

· Точка сохранения (Savepoint). Временное состояние в ходе выполнения транзакции, в которое можно вернуться после отмены части операций пакета, в отличие от отмены всей транзакции. Иногда это состояние называют «точка отката».

Обработка транзакций используется в ходе управления действием операторов INSERT, UPDATE и DELETE, а также CREATE, DROP. Нет смысла отменять действие оператора SELECT.

20.2. Управляемые транзакции

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

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

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

BEGIN TRANSACTION

. . .

COMMIT TRANSACTION

Все операторы, заключенные между BEGIN TRANSACTION и COMMIT TRANSACTION, должны быть выполнены, или не выполнены.

В СУБД MySQL это выглядит так:

START TRANSACTION

. . .

20.3. Использование оператора ROLLBACK

Оператор ROLLBACK используется для отмены операторов SQL. Это записывается так:

DELETE FROM Orders;

ROLLBACK;

В примере выполняется и сразу же, посредством оператора ROLLBACK, аннулируется операция DELETE. Это не самый полезный пример, он показывает, что будучи включенными в блок транзакции, операции DELETE (INSERT и UPDATE) не являются окончательными.

20.4. Использование оператора COMMIT

Обычно после выполнения операторов SQL результаты записываются непосредственно в таблицы баз данных. Это называется неявная фиксация – операция фиксации (сохранения или записи) выполняется автоматически.

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

Для безусловного выполнения неявной фиксации используется оператор COMMIT. Пример для SQL Server:

BEGIN TRANSACTION

DELETE OrderItems WHERE order_num = 12345

DELETE Orders WHERE order_num = 12345

COMMIT TRANSACTION

В примере заказ номер 12345 полностью удаляется из системы. Поскольку это приводит к обновлению двух таблиц базы данных, Orders и OrderItems, блок транзакции применяется для того, чтобы заказ не мог быть удален лишь частично. Конечный оператор COMMIT записывает изменения только в случае, если не произошло ошибки. Если первый оператор будет выполнен, а второй, из=за ошибки, не выполнен, удаление не будет зафиксировано.

Чтобы выполнить то же самое в СУБД Oracle, нужно сделать следующее:

DELETE OrderItems WHERE order_num = 12345;

DELETE Orders WHERE order_num = 12345;

COMMIT;

20.5. Использование точек сохранения

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

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

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

В языке SQL эти метки называются точками сохранения (savepoints). Для создания такой точки в СУБД MySQL и Oracle применяется оператор SAVEPOINT:

SAVEPOINT deletel;

В SQL Server это будет так:

Лекция 11 — Разработка системы адаптивного управления — лекция, которая пользуется популярностью у тех, кто читал эту лекцию.

SAVE TRANSACTION deletel;

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

ROLLBACK TRANSACTIOM delete;

В MySQL и Oracle это так:

ROLLBACK TO delete;

Чем больше точек сохранения, тем лучше.

Источник

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

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

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

Поскольку большая часть, но не обязательно все, обработка транзакций сегодня является интерактивной, этот термин часто рассматривается как синоним онлайн-обработки транзакций.

Содержание

1 Описание
2 Методология
- 2.1 Откат
- 2.2 Откат
- 2.3 Тупики
- 2.4 Компенсация транзакции
3 Критерии ACID
- 3.1 Атомарность
- 3.2 Согласованность
- 3.3 Изоляция
- 3.4 Долговечность
4 Преимущества
5 Недостатки
6 Реализации
7 Ссылки
8 Дополнительная литература
9 Внешние ссылки

Описание

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

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

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

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

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

Методология

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

Откат

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

Повтор транзакций

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

Тупиковые ситуации

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

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

Компенсационная транзакция

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

Критерии ACID

Джим Грей в конце 1970-х определяли свойства надежной транзакционной системы под аббревиатурой ACID — атомарность, согласованность, изоляция и долговечность.

Атомарность

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

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

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

Изоляция

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

Долговечность

После успешного завершения (фиксации) транзакции ее изменения в базе данных сохраняются после сбоев и сохраняют свои изменения.

Преимущества

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

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

Недостатки

У них относительно высокая стоимость установки
Отсутствие стандартных форматов
Несовместимость аппаратного и программного обеспечения

Реализации

Стандарт программное обеспечение для обработки транзакций , такое как IBM Information Management System, было впервые разработано в 1960-х годах и часто было тесно связано с конкретной базой данных системы управления. В клиент-серверных вычислениях аналогичные принципы реализовывались в 1980-х годах с переменным успехом. Однако в последние годы поддерживать модель распределенного клиент-сервер значительно сложнее. Поскольку количество транзакций росло в ответ на различные онлайн-сервисы (особенно Web ), единая распределенная база данных не была практическим решением. Кроме того, большинство онлайн-систем состоят из целого набора программ, работающих вместе, в отличие от строгой модели клиент-сервер, в которой один сервер может обрабатывать транзакции. Сегодня доступен ряд систем обработки транзакций, которые работают на межпрограммном уровне и масштабируются до больших систем, включая мэйнфреймы.

. Одно усилие — X / Open Distributed Transaction Processing (DTP) (см. также Java Transaction API (JTA). Однако проприетарные среды обработки транзакций, такие как IBM CICS, по-прежнему очень популярны, хотя CICS эволюционировала и теперь включает открытые отраслевые стандарты..

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

Ссылки

Дополнительная литература

Герхард Вейкум, Готфрид Фоссен, Транзакционные информационные системы: теория, алгоритмы и практика управления параллельным выполнением и восстановления, Морган Кауфманн, 2002, ISBN 1-55860-508-8
Джим Грей, Андреас Рейтер, Обработка транзакций — концепции и методы, 1993, Морган Кауфманн, ISBN 1-55860-190-2
Филип А. Бернштейн, Эрик Ньюкомер, Принципы обработки транзакций, 1997, Морган Кауфманн, ISBN 1-55860-415- 4
Ахмед К. Эльмагармид (редактор), Модели транзакций для расширенных приложений баз данных, Морган-Кауфманн, 1992, ISBN 1-55860-214-3

Внешние ссылки

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

Источник

Приветствую всех посетителей сайта Info-Comp.ru! В этом материале мы с Вами подробно рассмотрим транзакции языка T-SQL, Вы узнаете, что это такое, для чего они нужны, а также какие команды управления транзакциями существуют в T-SQL.

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

Источник

Заметка! T-SQL – это расширение языка SQL, реализованное в Microsoft SQL Server. Более подробно об этом можете почитать в статье – Что такое T-SQL. Подробное описание для начинающих.

Содержание

Транзакции в T-SQL
Свойства транзакции
Команды управления транзакциями в T-SQL
Примеры транзакций в T-SQL
Исходные данные для примеров
Простой пример транзакции в T-SQL
Пример транзакции в T-SQL с обработкой ошибок
Уровни изоляции транзакций в T-SQL
READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE
SNAPSHOT и READ COMMITTED SNAPSHOT
Побочные эффекты параллелизма
Включение уровня изоляции в T-SQL

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

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

По сути каждая отдельная инструкция языка T-SQL является транзакцией, это называется «Автоматическое принятие транзакций» или «Неявные транзакции», но также есть и явные транзакции, это когда мы сами явно начинаем транзакцию и также явно заканчиваем ее, т.е. делаем все это с помощью специальных команд.

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

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

Заметка! Назначение хранимых процедур в языке T-SQL.

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

Чтобы этого не допустить, все SQL инструкции, которые логически что-то объединяет, в данном случае все операции, связанные с переводом средств, пишут внутри транзакции, и тогда, если наступит подобная ситуация, все изменения будут отменены, т.е. деньги вернутся обратно на счет.

Транзакции можно сочетать с обработкой и перехватом ошибок TRY…CATCH, иными словами, Вы отслеживаете ошибки в Вашем блоке инструкций и если они появляются, то в блоке CATCH Вы откатываете транзакцию, т.е. отменяете все изменения, которые были успешно выполнены до возникновения ошибки в транзакции.

Транзакции – это отличный механизм обеспечения целостности данных.

Свойства транзакции

У транзакции есть 4 очень важных свойства:

Атомарность – все команды в транзакции либо полностью выполняются, и соответственно, фиксируются все изменения данных, либо ничего не выполняется и ничего не фиксируется;
Согласованность – данные, в случае успешного выполнения транзакции, должны соблюдать все установленные правила в части различных ограничений, первичных и внешних ключей, определенных в базе данных;
Изоляция – механизм предоставления доступа к данным. Транзакция изолирует данные, с которыми она работает, для того чтобы другие транзакции получали только согласованные данные;
Надежность – все внесенные изменения фиксируются в журнале транзакций и данные считаются надежными, если транзакция была успешно завершена. В случае сбоя SQL Server сверяет данные, записанные в базе данных, с журналом транзакций, если есть успешно завершенные транзакции, которые не закончили процесс записи всех изменений в базу данных, они будут выполнены повторно. Все действия, выполненные не подтвержденными транзакциями, отменяются.

Заметка! Чем отличаются функции от хранимых процедур в T-SQL.

Команды управления транзакциями в T-SQL

В T-SQL для управления транзакциями существуют следующие основные команды:

BEGIN TRANSACTION (можно использовать сокращённую запись BEGIN TRAN) – команда служит для определения начала транзакции. В качестве параметра этой команде можно передать и название транзакции, полезно, если у Вас есть вложенные транзакции;
COMMIT TRANSACTION (можно использовать сокращённую запись COMMIT TRAN) – с помощью данной команды мы сообщаем SQL серверу об успешном завершении транзакции, и о том, что все изменения, которые были выполнены, необходимо сохранить на постоянной основе;
ROLLBACK TRANSACTION (можно использовать сокращённую запись ROLLBACK TRAN) – служит для отмены всех изменений, которые были внесены в процессе выполнения транзакции, например, в случае ошибки, мы откатываем все назад;
SAVE TRANSACTION (можно использовать сокращённую запись SAVE TRAN) – данная команда устанавливает промежуточную точку сохранения внутри транзакции, к которой можно откатиться, в случае возникновения необходимости.

Примеры транзакций в T-SQL

Давайте рассмотрим примеры транзакций, реализованные на языке T-SQL.

Исходные данные для примеров

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

Для этого выполните следующую инструкцию.

   
   --Создание таблицы
   CREATE TABLE Goods (
      ProductId INT IDENTITY(1,1) NOT NULL,
      ProductName VARCHAR(100) NOT NULL,
      Price MONEY NULL,
   );

   --Добавление данных в таблицу
   INSERT INTO Goods(ProductName, Price)
      VALUES ('Системный блок', 50),
             ('Клавиатура', 30),
             ('Монитор', 100);

   SELECT ProductId, ProductName, Price
   FROM Goods;

Заметка! Создание таблиц в Microsoft SQL Server (CREATE TABLE) – подробная инструкция.

Простой пример транзакции в T-SQL

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

Поэтому мы решили эти инструкции объединить в одну транзакцию.

Сначала мы открываем транзакцию командой BEGIN TRANSACTION, далее пишем все необходимые инструкции, которые мы хотим объединить в транзакцию.

После этого командой COMMIT TRANSACTION мы сохраняем все внесенные изменения.

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

   
   BEGIN TRANSACTION

   --Инструкция 1
   UPDATE Goods SET Price = 70
   WHERE ProductId = 1;

   --Инструкция 2
   UPDATE Goods SET Price = 40
   WHERE ProductId = 2;

   COMMIT TRANSACTION

   SELECT ProductId, ProductName, Price
   FROM Goods;

Однако, если в любой из инструкций возникнет ошибка, транзакция не завершится, и все изменения не сохранятся.

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

Например, если во второй инструкции мы попытаемся записать в столбец Price какое-нибудь текстовое значение, то у нас возникнет ошибка, и изменения, внесённые первой инструкцией, не зафиксируются на постоянной основе.

Пример транзакции в T-SQL с обработкой ошибок

В языке T-SQL существует механизм перехвата и обработки ошибок – конструкция TRY… CATCH.

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

Сначала мы открываем блок для обработки ошибок, затем открываем транзакцию командой BEGIN TRANSACTION, далее пишем наши инструкции, например, те же самые две инструкции UPDATE.

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

Если ошибок нет, то в блок CATCH мы, соответственно, не попадаем и у нас выполнится команда COMMIT TRANSACTION, которая сохранит все изменения.

В этом примере нет ошибок, поэтому транзакция завершена успешно.

Заметка! Обработка ошибок в языке T-SQL – конструкция TRY CATCH.

   
   BEGIN TRY
   --Начало транзакции
   BEGIN TRANSACTION

   --Инструкция 1
   UPDATE Goods SET Price = 70
   WHERE ProductId = 1;

   --Инструкция 2
   UPDATE Goods SET Price = 40
   WHERE ProductId = 2;

   END TRY
   BEGIN CATCH
      --В случае непредвиденной ошибки
      --Откат транзакции
      ROLLBACK TRANSACTION

      --Выводим сообщение об ошибке
      SELECT ERROR_NUMBER() AS [Номер ошибки],
             ERROR_MESSAGE() AS [Описание ошибки]

   --Прекращаем выполнение инструкции
   RETURN

   END CATCH

   --Если все хорошо. Сохраняем все изменения
   COMMIT TRANSACTION

   GO

   SELECT ProductId, ProductName, Price
   FROM Goods;

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

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

Заметка! Чем отличается инструкция THROW от RAISERROR в T-SQL.

Уровни изоляции транзакций в T-SQL

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

Давайте подробней рассмотрим уровни изоляции.

READ UNCOMMITTED

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

READ COMMITTED

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

REPEATABLE READ

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

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

SERIALIZABLE

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

SNAPSHOT и READ COMMITTED SNAPSHOT

Также существуют уровни изоляции, алгоритм которых основан на версиях строк, это

SNAPSHOT
READ COMMITTED SNAPSHOT

Иными словами, SQL Server делает снимок и хранит последние версии подтвержденных строк. В данном случае, клиенту не нужно ждать снятия блокировок, пока одна транзакция изменит данные, он сразу получает последнюю версию подтвержденных строк. Следует отметить, что уровни изоляции, основанные на версиях строк, замедляют операции обновления и удаления, так как перед этими операциями сервер делает и копирует снимок строк во временную базу данных.

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

READ COMMITTED SNAPSHOT – этот уровень изоляции работает практически так же, как уровень SNAPSHOT, с одним отличием, он хранит снимок строк, которые подтверждены на момент запуска команды, а не транзакции, как в SNAPSHOT.

Заметка! Обзор Azure Data Studio. Что это за инструмент и для чего он нужен.

Побочные эффекты параллелизма

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

Потерянное обновление (Lost Update) – при одновременном изменении данных разными транзакциями одно из изменений будет потеряно;
Грязное чтение (Dirty Read) – чтение неподтвержденных данных;
Неповторяющееся чтение (Non-Repeatable Read) – чтение измененных данных в рамках одной транзакции;
Фантомное чтение (Phantom Reads) – чтение записей, которые появились между началом и завершением транзакции.

Каждый из уровней изоляции устраняет определенные побочные эффекты. В таблице ниже приведены сводные данные.

Побочный эффект / Уровень изоляции	Потерянное обновление	Грязное чтение	Неповторяющееся чтение	Фантомные записи
READ UNCOMMITTED	Устраняет	Не устраняет	Не устраняет	Не устраняет
READ COMMITTED	Устраняет	Устраняет	Не устраняет	Не устраняет
REPEATABLE READ	Устраняет	Устраняет	Устраняет	Не устраняет
SERIALIZABLE	Устраняет	Устраняет	Устраняет	Устраняет
SNAPSHOT	Устраняет	Устраняет	Устраняет	Устраняет
READ COMMITTED SNAPSHOT	Устраняет	Устраняет	Устраняет	Устраняет

Включение уровня изоляции в T-SQL

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

   
   SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

Также для уровней SNAPSHOT и READ COMMITTED SNAPSHOT предварительно необходимо включить параметр базы данных ALLOW_SNAPSHOT_ISOLATION для уровня изоляции SNAPSHOT и READ_COMMITTED_SNAPSHOT для уровня READ COMMITTED SNAPSHOT.

Например

   
   ALTER DATABASE TestDB SET ALLOW_SNAPSHOT_ISOLATION ON;

Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней язык SQL рассматривается как стандарт, чтобы после прочтения данной книги можно было работать с языком SQL в любой системе управления базами данных.

На сегодня это все, надеюсь, материал был Вам полезен, до новых встреч!

Источник

Команда COMMIT

Команда ROLLBACK

Команда SAVEPOINT

Команда SET TRANSACTION

Команда LOCK TABLE

Вас заинтересует / Intresting for you:

Рекомендуемые материалы

Содержание

Описание

Методология

Откат

Повтор транзакций

Тупиковые ситуации

Компенсационная транзакция

Критерии ACID

Атомарность

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

Изоляция

Долговечность

Преимущества

Недостатки

Реализации

Ссылки

Дополнительная литература

Внешние ссылки

Свойства транзакции

Команды управления транзакциями в T-SQL

Примеры транзакций в T-SQL

Исходные данные для примеров

Простой пример транзакции в T-SQL

Пример транзакции в T-SQL с обработкой ошибок

Уровни изоляции транзакций в T-SQL

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ

SERIALIZABLE

SNAPSHOT и READ COMMITTED SNAPSHOT

Побочные эффекты параллелизма

Включение уровня изоляции в T-SQL

Новое и полезное: