7.4. Блокировки
Блокировка – это временное ограничение доступа к данным, участвующим в транзакции, со стороны других транзакций.
Различают следующие типы блокировок:
по степени доступности данных: разделяемые и исключающие;
по множеству блокируемых данных: строчные, страничные, табличные;
по способу установки: автоматические и явные.
Строчные, страничные и табличные блокировки накладываются соответственно на строку таблицы, страницу (блок) памяти и на всю таблицу целиком. Табличная блокировка приводит к неоправданным задержкам исполнения запросов и сводит на нет параллельность работы. Другие виды блокировки увеличивают параллелизм работы, но требуют накладных расходов на поддержание блокировок.
Разделяемая блокировка, установленная на определённый ресурс, предоставляет транзакциям право коллективного доступа к этому ресурсу. Обычно этот вид блокировок используется для того, чтобы запретить другим транзакциям производить необратимые изменения. Например, если на таблицу целиком наложена разделяемая блокировка, то ни одна транзакция не сможет удалить эту таблицу или изменить её структуру до тех пор, пока эта блокировка не будет снята. (При выполнении запросов на чтение обычно накладывается разделяемая блокировка на таблицу.)
Исключающая блокировка предоставляет право на монопольный доступ к ресурсу. Такие блокировки накладываются, обычно, на отдельные записи (блоки), которые подвергаются модификации в процессе выполнения транзакции. Но в том случае, если модификация затрагивает большую часть записей таблицы (более 1000 записей или более 20% от объёма таблицы), целесообразнее заблокировать всё отношение, а не тратить время на построчную блокировку таблицы, при которой увеличивается количество требуемых системных ресурсов и время выполнения. Кроме того, при большом количестве построчных блокировок транзакция может не завершиться (из-за истечения тайм-аута, например), и тогда все сделанные изменения придётся откатить, что снизит производительность системы.
Блокировка может быть автоматической и явной. Если запускается новая транзакция, СУБД сначала проверяет, не заблокирована ли другой транзакцией строка, требуемая этой транзакции: если нет, то строка автоматически блокируется и выполняется операция над данными; если строка заблокирована, транзакция ожидает снятия блокировки. Явная блокировка, накладываемая командой LOCK (SQL), обычно используется тогда, когда транзакция затрагивает существенную часть отношения.
Блокировки могут стать причиной бесконечного ожидания и тупиковых ситуаций. Бесконечное ожидание возможно в том случае, если не соблюдается очередность обслуживания транзакций и транзакция, поступившая раньше других, всё время отодвигается в конец очереди. Решение этой проблемы основывается на выполнении правила FIFO: "первый пришел – первый ушел".
Тупиковые ситуации (deadlocks) возникают при взаимных блокировках транзакций, выполняющихся на пересекающихся множествах данных. На рис. 7.2 приведён пример взаимной блокировки трех транзакций Ti на отношениях Rj.
Рис. 7.2. Взаимная блокировка трех транзакций
Транзакция T1 заблокировала данные B1 в отношении R1 и ждёт освобождения данных B2 в отношении R2, которые заблокированы транзакцией T2, ожидающей освобождения данных B3 в отношении R3, заблокированных транзакцией T3, которая не может продолжить выполнение из-за транзакции T1.
Существует много стратегий разрешения проблемы взаимной блокировки, в частности:
1. Транзакция запрашивает сразу все требуемые блокировки. Такой метод снижает степень параллелизма в работе системы. Кроме того, он не может применяться в тех случаях, когда заранее неизвестно, какие данные потребуются, например, если выборка данных из одной таблицы осуществляется на основании данных из другой таблицы, которые выбираются в том же запросе.
2. СУБД отслеживает возникающие тупики и отменяет одну из транзакций. Этот метод требует дополнительных накладных расходов.
3. Вводится таймаут (time-out) – максимальное время, в течение которого транзакция может находиться в состоянии ожидания. Если транзакция находится в состоянии ожидания дольше таймаута, считается, что она находится в состоянии тупика, и СУБД инициирует её откат с последующим рестартом через случайный промежуток времени.