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

В большинстве коммерческих СУБД для повышения степени параллетьности доступа нескольких пользователей к одной базе данных используются блокировки различных типов. Наиболее широко распространены два из них:

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

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

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

 

 

Рисунок 12.9 – правила применения жесткой и нежесткой блокировок

 

На рис. 12.10 изображены те же транзакции, что и на рис. 12.8, но в них на этот раз используются жесткая и нежесткая блокировки. Если сравнить два этих рисунка, то можно увидеть, что новый механизм блокировки повышает степень параллельности доступа к базе данных. В таких сложных СУБД, как DB2, существует более двух типов блокировок и на различных уровнях базы данных применяются различные механизмы блокировки. Несмотря на повышенную сложность, цель блокировки при этом остается той же: предотвращать конфликты между транзакциями, обеспечивая при этом максимальную параллельность доступа к базе данных и минимальные затраты на реализацию механизма блокировки.

 

Рисунок 12.10 – использование жесткой и нежесткой блокировок

 

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

К сожалению, применение любого механизма блокировки для поддержки параллельного выполнения транзакций приводит к возникновению проблемы, которая называется тупик. На рис. 12.11 изображена типичная тупиковая ситуация. Программа А обновляет таблицу orders и поэтому блокирует часть этой таблицы. Тем временем программа в обновляет таблицу products и блокирует ее часть. Затем про­грамма Апытается обновить таблицу products,а программа Впытается обновить таблицу orders,причем каждая пытается обновить ту часть таблицы, которая заблокирована другой программой. Без внешнего вмешательства обе программы будут бесконечно ожидать, пока другая программа завершит транзакцию и разблокирует данные. Но могут возникнуть и более сложные ситуации, когда три, четыре или даже больше программ попадают в «цикл» блокировок и каждая из них ожидает освобо­ждения данных, заблокированных другой программой.

 

Рисунок 12.11 – Тупик двух транзакций

 

Как правило, для устранения тупиковых ситуаций СУБД периодически (скажем, каждые пять секунд) проверяет блокировки, удерживаемые различными транзакциями. Если СУБД обнаруживает тупик, то произвольно выбирает одну транзакцию в качестве «проигравшей» и отменяет ее. Это освобождает блокировки, удерживаемые проигравшей транзакцией, позволяя «победителю» продолжить работу. Проигравшей программе посылается код ошибки, показывающий, что она проиграла в тупиковой ситуации и ее текущая транзакция была отменена.

Такая схема устранения тупиков означает, что любая инструкция SQL может вернуть код ошибки «проигрыша в тупиковой ситуации», хотя сама по себе инструкция будет правильной. Транзакция, пытающаяся выполнить эту инструкцию, отменяется не по вине последней, а из-за параллельной работы с базой данных многих Пользователей. Такая схема может показаться несправедливой, но на практике она лучше двух возможных альтернатив: «зависания» или нарушения целостности данных. Если ошибка «проигрыша в тупиковой ситуации» происходит в интерактивном режиме, пользователь может просто повторно ввести инструкции (одну или несколько). В программе SQL прикладная программа сама должна обрабатывать код пробной ошибки. Обычно в таких случаях программа либо выдает предупреждающее сообщение пользователю, либо пытается выполнить транзакцию повторно.

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

 

SQL и сети

Рост популярности компьютерных сетей оказал большое влияние на управление базами данных и придал SQL новые возможности. По мере распространения сетей приложения, которые раньше работали на центральном мини-компьютере или мэйн-фрейме, переводятся на серверы и рабочие станции ЛВС. В таких сетях SQL играет важнейшую роль и связывает приложение, выполняющееся на рабочей станции, и СУБД, управляющую совместно используемыми данными на сервере. Недавний взрыв популярности Internet и WWW еще больше усилил влияние SQL в сфере сетевых технологий. С появлением трехуровневой архитектуры Internet язык стал связующим звеном между управляющим приложением (второй уровень - сервер приложений или Web-сервер) и сервером баз данных(третий уровень). В следующих параграфах мы поговорим о развитии архитектур сетевого управления базами данных и о роли, которую SQL играет в каждой из них.