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

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

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

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

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

Основные проблемы при параллельной обработке транзакции:

1. Проблема утраченных (потерянных) обновлений (Lost update).

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

2. Зависимость от незафиксированных обновлений.

Пользователь А может увидеть данные, которые уже были обновлены пользователем В, но эти обновления еще не были окончательно зафиксированы. Далее пользователь В может в силу различных причин (например, из-за выявленных ошибок ввода) провести откат базы данных в исходное состояние.

Таким образом, если обновление не завершено, существует некоторая вероятность того, что оно не будет завершено никогда. В таком случае Пользователь А будет предпринимать действия над данными, которых не существуют (над ошибочными данными). Иногда для такого рода проблем используется термин преждевременное чтение (Dirty read).

3. Проблема несовместимого анализа.

Транзакции A и B выполняются для кортежей N1, N2, N3. Транзакция A вычисляет итоговый баланс, транзакция B производит перевод суммы, равной 10, со счета N3 на счет N1. Из-за взаимных помех транзакций получен неверный результат. В этом случае A встретилась со несовместимым состоянием и на его основании был выполнен несовместимый анализ.

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

Блокировка.

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

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

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

Алгоритм блокировки:

1. Предположим, что в системе поддерживается два типа блокировок:

• Блокировка без взаимного доступа (монопольная или X - блокировка).

• Блокировка с взаимным доступом (S - блокировка).

1. Если транзакция A блокирует кортеж P X – блокировкой, то запрос другой транзакции B с блокировкой кортежа будет отменен.

2. Если транзакция A блокирует кортеж P S – блокировкой, то:

1. Запрос транзакции B на X – блокировку будет отвергнут.

2. Запрос транзакции B на S – блокировку будет принят.

Блокировки накладываются в соответствии с правилами совместимости блокировок, исключающими конфликты чтение-запись, запись-чтение и запись-запись. Сериализуемость [Сериализация — процесс перевода какой-либо структуры данных в последовательность битов] транзакций заведомо гарантируется, если блокировки, относящиеся к одновременно выполняемым транзакциям, удовлетворяют следующему правилу: «Ни одна блокировка от имени какой-либо транзакции не должна устанавливаться, пока не будет снята ранее установленная блокировка». Это правило известно под названием двухфазового блокирования, поскольку транзакция проходит при этом сначала фазу роста, когда она устанавливает блокировки, а затем фазу сжатия, когда блокировки снимаются.

В SQL-92 определены так называемые уровни изоляции (isolation level).

1. Уровень SERIALIZABLE (последовательное выполнение) -обеспечивает максимальную степень целостности и соответствует требованиям предыдущих стандартов. Обычно именно этот уровень устанавливается по умолчанию. При его выборе каждая транзакция выполняется изолированно.

2. Уровень REPEATABLE READ (повторяющееся чтение) - допускает вставку новой записи в таблицу, обрабатываемую транзакцией. При этом в принципе может возникать эффект так называемой фантомной вставки.

3. Уровень READ COMMITTED (чтение с фиксацией) - допускает выполнение запроса при условии, что результаты параллельных транзакций были зафиксированы.

4. Уровень READ UNCOMMITTED (чтение без фиксации) - допускает выполнение запроса независимо от того, были зафиксированы результаты параллельных транзакций или нет.