29. Журнал транзакций. Проблемы обработки параллельных транзакций.

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

Когда пользователь выполняет запрос на изменение базы данных, СУБД автоматически вносит в журнал транзакций одну запись для каждой строки, измененной в процессе выполнения запроса. Эта запись содержит две копии строки. Одна копия представляет собой строку до изменения, а другая – после изменения. Только когда в журнале будет сделана запись, СУБД изменит физическую строку на диске. Затем, если пользователь выполняет инструкцию COMMIT, в журнале отмечается конец транзакции. Если пользователь выполняет инструкцию ROLLBACK, СУБД обращается к журналу и извлекает из него “исходные” копии строк, измененных во время транзакции. Используя эти копии, СУБД возвращает строки в прежнее состояние и таким образом отменяет изменения, внесенные в базу данных в ходе транзакции.

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

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

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

1. Проблема пропавшего обновления.

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

2. Проблема промежуточных данных. Было 139 моб. Первый заказл 100, но не выполнил его=> осталось 39 в таблице. Второй хотел купить 120, но так как их там 39, то дал отказ. Клиент первого отказался и первый внес снова 100 штук. Т.о. в таблице 139 шт и никто ничего не купил

3. Проблема несогласованных данных

4. Проблема строк – призраков

Когда две транзакции, A и B, выполняются параллельно, СУБД гарантирует, что результаты их выполнения будут точно такими же, как если бы вначале выполнялась транзакция А, а затем транзакция B; или вначале выполнялась транзакция B, а затем транзакция А”.

Данная концепция называется сериализацией транзакций

30. Блокировки транзакций: уровни и виды, тупиковые ситуации.

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

уровни

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

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

3. блокировка на уровне страниц. В этом случае СУБД блокирует отдельные блоки данных на диске (“страницы”), когда транзакция обращается к ним. Остальным транзакциям запрещается доступ к заблокированным страницам, но они могут обращаться к другим страницам данных (и блокировать их для себя)

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

Жесткая и нежесткая блокировки

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

• Когда транзакция обновляет информацию в базе данных, СУБД применяет жесткую блокировку. Если транзакция жестко заблокировала какие-либо данные, другие транзакции не могут обращаться к ним ни для выборки, ни для записи.

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

К сожалению, применение любого механизма блокировки для поддержки параллельного выполнения транзакций приводит к возникновению проблемы, которая называется тупиковой ситуацией. Программа А обновляет таблицу ORDERS и поэтому блокирует часть этой таблицы. Тем временем программа B обновляет таблицу PRODUCTS и блокирует ее часть. Затем программа А пытается обновить таблицу PRODUCTS, а программа B пытается обновить таблицу ORDERS, причем каждая пытается обновить ту часть таблицы, которая заблокирована другой программой