Механизмы управления транзакциями. Блокировки.

Для управления транзакциями БД должна быть разбита на элементы- блоки данных, доступ к которым контролируется блокировками. Элементами могут быть таблицы, блоки, записи, поля. В СУБД есть специальная подсистема называемая блокировщиком, который намечает текущее состояние элементов данных. Эта система запрещает транзакции доступ к элементу если он используется другой транзакцией. Ее выполнение может привести к конфликту. При выборе размера элемента возникает дилемма- если взять крупный элемент, то понадобится меньше блокировок, что сокращает необходимый объем памяти и снижает смежность алгоритма, но разбивка данных на мелкие элементы позволяет выполнить параллельно большее число транзакций. Блокировки предназначены для представления права доступа транзакции к определенному элементу данных. Блокировки хранятся в таблице блокировок, имеющие схему (I, L, T) I- item -лемент, L-lock-блокировка, T- транзакция Смысл этой записи- транзакция Т наложила блокировку L на элемент I Пример- выполняется транзакция во времени Пусть есть программа Р которая увеличивает значение элемента А на 1

Р: read (A)

A:= A+1

Write (A)

При работе этой программы в случае если к элементу А пытаются обратится несколько транзакций возникает конфликтё эту проблему можно решить заблокировав элемент А как показано в программе P^\

P^\ := lock (A)

Read (A);

A:=A+1

Write (A)

Unlock (A)

При выполнении программы P^\ если две транзакции пересекаются во времени, то первая заблокировавшая элемент А выполнит все действия, а вторая будет вынуждена подождать, т.о. конфликта данных не будет. Однако даже если при управлении транзакциями применять блокировки все равно придется столкнутся с рядом проблем: тупик эту проблему часто рассматривают на задаче Обедающие философы. Философы сидят за столом и едят спагетти. Они знаю что спагетти нужно есть двумя вилками. Каждый знает что сначала нужно взять вилку в левую руку, затем в правую и начать есть. Если каждый из них возьмет вилку в левую руку, то возникнет тупиковая ситуация.

Пусть есть программа P₁ которая уменьшает элемент А и увеличивает элемент В

P₁ lock (A) P₂ lock (В)

lock (В) lock (A)

A:=A-1 В:=В-1

В:=В+1 A:=A+1

Unlock (A) Unlock (В)

Unlock (A)

Unlock (В)

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

 

P₁ lock (A) ждет В

 

P₂ lock (В) ждет А

 

Программы P₁ и P₂ ведут себя как обедающие философы Множество транзакций S состоящая из элементов Т ₁ , Т₂… находятся в тупиковой ситуации, если каждая транзакция Т из S заблокировала какой то элемент и ждет пока какая то транзакция не разблокирует какой либо элемент. Возможные пути борьбы с тупиками 1. требуем чтобы все транзакции накладывали все необходимые блокировки одновременно2.устанавливаем линейный порядок на множестве блокированных элементов и требуем чтобы транзакции блокировали элементы не нарушая этого порядка. 3. бесконечное ожидание Все транзакции должны быть обязательно выполнены. Пусть несколько транзакций Т ₁ , Т₂…выполняются по программе Р использующий элемент А. пусть транзакция Т ₁ заблокировала элемент А, а транзакция Т₂ ждет пока он освободиться перед тем как транзакция Т ₁ освободит А появляется транзакция Т ₃ и после освобождения А блокирует его. Потом может появится транзакция Т ₄ которая поступает также как и Т _3, а ожидание транзакции Т ₂ может стать бесконечным. Способ борьбы с бесконечным ожиданием- организация очереди к каждому заблокированному элементу.

48.Одновременность в БД.

Рассмотрим следующий пример: предположим, компания вкладывающей системой магазинов металлических изделий: а) для отслеживания хранящихся в каждом магазине товаров использованные БД. По замыслу эта БД содержит таблицу товаров для каждого магазина металлических изделий в системе. Каждый раз, когда в определенном магазине получаются или продаются запасы соответствующим образом, обновляется таблица товаров для данного магазина. Предположим, что ящик молотков физически перемещается из одного магазина в другой, для того, чтобы отразить это перемещение товара. Значение числа молотков хранящихся в таблице «Товары» предающего магазина необходимо уменьшить, а значение числа молотков хранящихся в таблице «Товары» получаемого магазина необходимо увеличить. Если пользователь уменьшит значение числа молотков, таблица «Товары» предающего магазина, но не увеличивает их число в таблице «Товары» принимающие данные станут не согласованными. БД может стать не согласованной, если пользователь забудет сделать все необходимые изменения. Если система потерпит аварию в ходе производимых пользователем изменения (число молотков в таблице передающего магазина уменьшено, затем возникает авария системы до того, как число молотков будет увеличено в таблице принимаемого магазина) и если по какой-нибудь причине приложение БД преждевременно прекратит работу. Не согласованность может так же возникнуть когда несколько пользователей пытаются получить доступ к одним и тем же данным в одно и тоже время. Пример тот же: пример с магазином, один пользователь мог бы сделать запрос в БД и обнаружить: доступных молотков больше нет (в то же время они есть) поскольку запрос прочел изменение другого пользователя до того, как были должным образом обновлены все затрачиваемые этими изменениями таблицы. Чтобы гарантировать, что пользователь и приложение, получающие доступ к одним и тем же данным в одно и тоже время не приведут их в не согласованное состояние, используются 2 механизма: 1) уровни изоляции, 2) блокировки.

49. Уровни изоляции .

Как известно транзакция является последовательностью с возможностью восстановления, состоящей из одной или нескольких операций SQL сгруппированных в одну единицу обычно внутри прикладного процесса. Инициированием и завершение одной транзакции. Определение точки согласованности внутри БД, либо к БД применяются, и делаются постоянными результаты всех операций SQL предпринятых в рамках транзакции, либо результаты всех операций SQL полностью отличаются и откатываются. В однопользовательских средах с одним приложением каждая транзакция действует последовательно и не должна состязаться с явлениями других транзакций. Однако в многопользовательских средах транзакции могут выполняться одновременно и у каждой транзакции есть возможность влиять на любую другую транзакцию, которая была инициирована, но еще не завершилась. Транзакции, имеющие возможность мешать друг другу называется параллельными. Тогда как транзакции, работающие, не зависимо друг от друга называется ……., что означает, результаты их одновременной работы не будут отличаться от результатов запуска их одна за другой (последовательно). В идеале каждая транзакция должна быть последовательной. Рассмотрим пример: Предположим агент бюро путешествий вводит в систему БД информацию о резервированном отеле, в то же самое время, когда менеджер отеля проверяет доступность комнат для комитета планирования конференции. Теперь предположим, что агент бюро путешествий блокирует 200 комнат для большой туристкой группы (чтобы проверить доступность, получив расценки), но не принимает запрос. Пока агент бюро путешествий передает сведения о расценке координатору группы, менеджер отеля запрашивает в БД, сколько комнат доступно, видит, что зарезервированы все комнаты кроме 20 и сообщает комитету планирования конференции, что он не может обеспечить их потребность. Теперь предположим, что координатор путешествий решает не резервировать комнаты, поскольку комнаты цены выше, чем он ожидал. Агент бюро путешествий откатывает транзакции, поскольку места не были заблокированы и 200 полностью помечены как зарезервированные, теперь доступны. В результате отел лишился возможности обслужить конференцию, и у них теперь есть 200 комнат, которые нужно заполнить. Если бы транзакция агента бюро путешествий и транзакция менеджера отеля были изолированы друг от друга (выполнены последовательно), эта проблема не возникла бы. Либо транзакция агента бюро путешествий завершилась ба до начала транзакции менеджера отеля, либо транзакция менеджера отеля завершилась ба до начала транзакции агента. В этом случаи отель не лишился бы возможности разместить участников конференции. Когда транзакции в многопользовательской среде не изолированы друг от друга, могут возникнуть следующие типы событий: 1. Потерянные изменения – это событие возникает, когда две транзакции читают одни и те же данные, обе пытаются изменить эти данные и одно из измененных теряется. Н-р: транзакция А и транзакция В читают одну и ту же строку данных и вычисляют новые значения для этой строки на основе первоначально считанных данных. Если транзакция А изменяет значения в строке на новое, а затем транзакция В обновит ту же самую строку, операция изменения выполненная транзакцией А будет потеряна. 2. «Грязные чтения» - это событие возникает, когда транзакция читает данные, которые еще не были подтверждены. Н-р: транзакция А изменяет строку данных, а транзакция В читает измененную строку прежде, чем транзакция подтвердит изменение. Если транзакция А сделает откат изменения, транзакция В окажется прочитавшая данные, которые теоретически не когда не существовали. 3. Неповторяющиеся чтения – это событие возникает, когда транзакция читает одну и ту же строку данных дважды, но каждый раз получает различные результаты. Н-р: транзакция А читает строку даны, а затем транзакция В изменяет или удаляет эту строку и подтверждает изменение, когда транзакция А пытается повторно прочесть строку, она получит другие значения данных (если строка была изменена) или обнаружит, что строка больше не существует (если строка бала удалена). 4. Фантомы – это событие возникает, когда строка данных удовлетворяет некоторым условиям поиска, но первоначально не видна. Н-р: транзакция А получают набор строк, которые удовлетворяют некоторому критерию поиска, а затем транзакция В вставляет новую строку, которая удовлетворяет критерию поиска для запроса транзакции А. Если транзакция А повторно выполнит запрос создавший первоначальный набор строк, будет получен другой набор строк – теперь набор возвращенных строк будет включена строка добавленная в транзакцию В.