Транзакции и параллелизм

целое.
Параллелизм (concurrency) относится к механизмам, с помощью которых СУБД предотвращает

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

пользователей, постоянно вводящих и изменяющих информацию. При этом система будет

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

обновления или на DROP TABLE), необязательно является необратимым.
После выполнения оператора

(или группы операторов) принимается решение станут ли произведенные изменения постоянными или будут прогнозируемыми;
С этой целью операторы объединяются в группы, называемые транзакциями.

как единое целое.
Инициируя сеанс работы в SQL, начинается транзакция;
Все вводимые

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

изменения Commit и Rollback, используется следующий синтаксис:

COMMIT WORK;

Синтаксис для отмены

изменений выглядит так:

ROLLBACK WORK;

ON
Что бы вернутся к обычной обработки транзакций нужно ввести:
SET AUTOCOMMIT

OFF

Система может автоматически включать AUTOCOMMIT при входе.

сбой или пользователь перезагружает компьютер – астматически выполняется откат текущей

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

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

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

имени Иванов. Прежде чем удалить ее саму оператором DELETE из

таблицы ПРОДАВЦЫ, необходимо что-то сделать с его заказами и покупателями.
Логично установить ID Продавца для этих заказов в NULL, чтобы никто из продавцов не получал по ним комиссионные, а покупателей передать продавцу Петрову.
После этого вы можете удалить его из таблицы Продавцы.

= 1004;
UPDATE Customers
SET snum
WHERE snum =

1004;
DELETE FROM Salespeople
WHERE snum = 1004;

эту группу операторов COMMIT или завершить оператором COMMIT или ROLLBACK

где в одно и то же время операции над БД

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

Salespeople
SET comm = comm * 2
WHERE sname

LIKE ‘R%’:

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

SELECT city, AVG (comm)
FROM Salespeople
GROUP BY city;

которые вносились в таблицу ранее?
Это может не иметь большого значения,

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

того как последний пользователь получил свои результаты.
Теперь его средние значения

основаны, на изменениях, которые утратили силу, но он не может об это узнать.

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

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

в приведенном выше примере, когда вы отменили ошибочный ввод после

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

значения существовали в некоторый момент и могла оставаться неизменными, если

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

его родительского ключа.

(DIRTY READ)
Неповторяющееся чтение (NON-REPETEABLE READ)
Фантомная вставка (PHANTOM INSERT)

Они объясняются в

следующих таблицах 

до . 10 не имело результата.
Это не обязательно является

ли это проблемой, например установка для comm значения . 14 на следующей неделе дала бы тот же самых эффект перекрытия.
Однако при изменении данных часто учитывается их предыдущее значение.
Пользователь, выполнявший Транзакцию №2 был введет в заблуждение: он думал, что текущие comm = . 12, тогда как они были = . 10
Если бы он намеревался увеличить комиссионные на . 02, то результат был бы ошибочным.
Если выполнить увеличение непосредственно, использую в операторе UPDATE предложение SET comm = comm + 0.02, то ошибки можно избежать, но это не всегда легко сделать при сложных вычислениях.

БД.

Отмена транзакции №1 эквивалентна тому, что значение comm никогда

не = . 10, но именно это значение было показано в транзакции №2.

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

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

№1 результаты одинаковых запросов будут отличатся.
Здесь показан особый случай неповторяющегося

чтения.
Если вклинивающемся операторам, является INSERT, a не UPDATE или DELETE, то новая строка не может быть одной из тех, что выведены предыдущим запросом.
Эта новая фантомная строка не существовавшая раньше.
На практике различие между фантомными вставками и другими случаями неповторяющегося чтения заключается в том, что фантомные вставки дают более ограниченный эффект.

SQL говорилось, что одновременное выполнение операторов должно быть организованно так,

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

изменять данные (хотя их чтение возможно для нескольких транзакций)
Механизмы, которые

SQL использует для управления параллельными операциями, называются блокировками (LOCKS)

Блокировки приостанавливают определенные операции над БД на то время, пока активны другие операции или транзакции.

доступ к данным для одновременных транзакций
Оптимистические блокировки (optimistic locks)
Отслеживают возникновение

конфликтов и при необходимости выполняют откат транзакции

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

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

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

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

и операции разрешенные на каждом уровне.

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

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

неповторяющегося чтения только фантомные вставки.
Этот уровень изоляции полезен на транзакции,

на которые не влияет возможная вставка данных.
Если добавление в таблицу новой строки не меняет результатов запросов данной транзакции.
REPEATABLE READ окажется предпочтительнее SERIALIZABLE, поскольку допускает оператор INSERT.

и того же запроса с разными результатами, но только при

условии, что результаты параллельных транзакций были зафиксированы.

одного и того же запроса с разными результатами независимо от

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

двух логических типов: разделяемые и исключительные
Разделяемы блокировки (SHARED LOCKS) или

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

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

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