Тема 7

 

ОРГАНИЗАЦИЯ ПАРАЛЛЕЛЬНОГО ДОСТУПА К ДАННЫМ

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

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

7.1. Механизм транзакций

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

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

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

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

2. Согласованность: транзакция начинается на согласованном множестве данных и после её завершения множество данных также согласовано.

3. Изолированность, т.е. отсутствие влияния транзакций друг на друга. (На самом деле это влияние существует и регламентируется стандартом: см. раздел 7.2. "Взаимовлияние транзакций").

4. Продолжительность: результаты зафиксированной транзакции не могут быть потеряны. Возврат БД в предыдущее состояние может быть достигнут только путём запуска компенсирующей транзакции.

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

– фиксация транзакции:         COMMIT [WORK];

– откат транзакции:                ROLLBACK [WORK];

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

(Ключевое слово WORK необязательно). Предложение SAVEPOINT запоминает промежуточную "текущую копию" состояния базы данных для того, чтобы впоследствии, при необходимости, можно было вернуться к состоянию БД в точке сохранения: откатить работу от текущего момента до точки сохранения (rollback to <имя_точки>) или зафиксировать работу от начала транзакции до точки сохранения (commit to <имя_точки>).

Начало транзакции соответствует появлению первого исполняемого SQL-оператора. Транзакция завершается при наступлении одного из следующих событий:

• Поступила команда COMMIT или ROLLBACK (результаты транзакции соответственно зафиксируются или откатываются).
• Выдана и успешно проанализирована одна из команд языка описания данных (DDL, Data Definition Language), таких как CREATE, DROP или ALTER. При этом фиксируется предыдущая транзакция.
• Завершилась команда DDL. Таким образом, транзакция, содержащая оператор языка описания данных фиксируется автоматически.
• Пользователь завершил сеанс работы с системой (последняя транзакция фиксируется автоматически).
• Процесс пользователя аварийно завершен (последняя транзакция автоматически откатывается).

Фиксация транзакции заключается в следующем:

1. Изменения, внесённые транзакцией, делаются постоянными.

2. Уничтожаются все точки сохранения для данной транзакции.

3. Завершается транзакция (уничтожаются системные записи о транзакции в оперативной памяти).

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

Для организации отката СУБД во время выполнения транзакции производит запись в сегменты отката всех внесённых изменений. Все изменения выполняются в оперативной памяти (ОП), затем фиксируются в журнале транзакций и периодически (при выполнении контрольной точки) переписываются на диск. Процесс формирования контрольной точки заключается в синхронизации данных, находящихся на диске (т.е. во вторичной памяти) с теми данными, которые находятся в ОП: все модифицированные данные из ОП переписываются во вторичную память.

7.2. Взаимовлияние транзакций

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

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

• потери изменений;
• чернового чтения;
• неповторяемого чтения;
• фантомов.

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

Например, почти одновременно начали выполняться две транзакции:

транзакция 1 –     UPDATE    СОТРУДНИКИ    SET   Оклад = 9200

WHERE     Номер = 1123

транзакция 2 –     UPDATE    СОТРУДНИКИ

SET  Должность = "старший экономист", ЕТС = 14

WHERE     Номер = 1123

Обе транзакции считали одну и ту же запись (1123, "Рудин В.П.", "экономист", 12, 8300) и внесли каждая свои изменения: в бухгалтерии изменили оклад (транзакция 1), в отделе кадров – должность и ставку по ЕТС (транзакция 2). Результаты транзакции 1 будут потеряны (рис. 7.1).

Рис. 7.1. Взаимовлияние транзакций: потеря изменений

СУБД не допускает такого взаимовлияния транзакций, при котором возможна потеря изменений.

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

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

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

7.3. Уровни изоляции транзакций

С целью обеспечения предсказуемости работы приложений для многопользовательских БД стандарт ANSI/ISO для SQL устанавливает различные уровни изоляции для операций, выполняемых над базами данных. Уровень изоляции определяет, может ли транзакция "видеть" результаты работы других одновременно выполняемых завершённых и/или незавершённых транзакций (табл. 7.1).

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

Таблица 7.1. Уровни изоляции по стандарту ANSI / ISO        

Уровень изоляции	Черновое чтение	Неповторяемое чтение	Фантомы
Read Uncommited – чтение незавершённых транзакций	да	да	да
Read Commited – чтение завершённых транзакций	нет	да	да
Repeatable Read – повторяемое чтение	нет	нет	да
Serializable – последовательное чтение	нет	нет	нет

По умолчанию обычно используется уровень Read Commited.

Наиболее распространённый механизм разграничения транзакций – использование блокировок.

7.4. Блокировки

Блокировка – это временное ограничение доступа к данным, участвующим в транзакции, со стороны других транзакций.

Различают следующие типы блокировок:

• по степени доступности данных: разделяемые и исключающие;
• по множеству блокируемых данных: строчные, страничные, табличные;
• по способу установки: автоматические и явные.

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

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

Исключающая блокировка предоставляет право на монопольный доступ к ресурсу. Такие блокировки накладываются, обычно, на отдельные записи (блоки), которые подвергаются модификации в процессе выполнения транзакции. Но в том случае, если модификация затрагивает большую часть записей таблицы (более 1000 записей или более 20% от объёма таблицы), целесообразнее заблокировать всё отношение, а не тратить время на построчную блокировку таблицы, при которой увеличивается количество требуемых системных ресурсов и время выполнения. Кроме того, при большом количестве построчных блокировок транзакция может не завершиться (из-за истечения тайм-аута, например), и тогда все сделанные изменения придётся откатить, что снизит производительность системы.

Блокировка может быть автоматической и явной. Если запускается новая транзакция, СУБД сначала проверяет, не заблокирована ли другой транзакцией строка, требуемая этой транзакции: если нет, то строка автоматически блокируется и выполняется операция над данными; если строка заблокирована, транзакция ожидает снятия блокировки. Явная блокировка, накладываемая командой LOCK (SQL), обычно используется тогда, когда транзакция затрагивает существенную часть отношения.

Блокировки могут стать причиной бесконечного ожидания и тупиковых ситуаций. Бесконечное ожидание возможно в том случае, если не соблюдается очередность обслуживания транзакций и транзакция, поступившая раньше других, всё время отодвигается в конец очереди. Решение этой проблемы основывается на выполнении правила FIFO: "первый пришел – первый ушел".

Тупиковые ситуации (deadlocks) возникают при взаимных блокировках транзакций, выполняющихся на пересекающихся множествах данных. На рис. 7.2 приведён пример взаимной блокировки трех транзакций T_i на отношениях R_j.

Рис. 7.2. Взаимная блокировка трех транзакций

Транзакция T₁ заблокировала данные B₁ в отношении R₁ и ждёт освобождения данных B₂ в отношении R₂, которые заблокированы транзакцией T₂, ожидающей освобождения данных B₃ в отношении R₃, заблокированных транзакцией T₃, которая не может продолжить выполнение из-за транзакции T₁.

Существует много стратегий разрешения проблемы взаимной блокировки, в частности:

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

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

3. Вводится таймаут (time-out) – максимальное время, в течение которого транзакция может находиться в состоянии ожидания. Если транзакция находится в состоянии ожидания дольше таймаута, считается, что она находится в состоянии тупика, и СУБД инициирует её откат с последующим рестартом через случайный промежуток времени.