в стандарте SQLl вопросы производительности не рассматривались, поэтому в большинстве СУБД были реализованы собственные схемы повышения производительности транзакций. В стандарте SQL2 описана новая инструкция set transaction, назначение которой заключается в том, чтобы указать СУБД, какую степень изоляции следует обеспечить при обработке транзакций Применять эту инструкцию нет необходимости, если для вашего приложения вопросы обработки транзакций не играют роли или сами транзакции достаточно просты

Чтобы понять особенности работы инструкции set transaction, жокно разобраться с методикой блокировки, применяемой в коммерческих СУБД д;!я обеспечения параллельного выполнения транзакций. В оставшейся части главы подробно рассматриваются тонкости механизма блокировки и способы повышения производительности транзакций, описанные в стандарте SQL2 и реализованные в различных СУБД.

Блокировка *

Прг1ктически во всех ведуших СУБД для обработки параллельных транзакций применяется довольно сложный механизм блокировки Однако принципы блокировки транзакций довольно просты. На рис. 12.10 изображена схема простой блокировки, устраняющей конфликты между двумя параллельными транзакциями.

Транзакция А

СУБД

Транзакция В

1201

I UPDATE ORDERS

12 03

SELECT. . . FROM OFFICES

12 05

COMMIT

ORDERS

OFFiCES

PRODUCTS

разблокирована разблокирована разблокирована

заблокирована для A

заблокирована для В

заблокирована для A

OK разблокирована

разблокирована

заблокирована для В +

разблокирована

разблокирована

12 02

1 UPDATE PRODUCTS

12 04

SELECT. . . FROM OFFICES

12 or

12 08 *

COMMIT

1. 12.10. Блокировка при -здноврвмвнном выполнении двух транзакций

Когда транзакция а обращается к базе данных, СУБД автоматически блокирует все части базы данных, в которых транзакция осуществляет выборку или изменение. Транзакция в выполняется параллельно, и СУБД также блокирует те части базы данных, к которым она обращается. Если транзакция в обращается к той части базы данных, которая заблокирована транзакцией а, то СУБД приостанавливает выполнение транзакции в, заставляя ее ждать до тех пор, пока данные не будут разблокированы. СУБД снимает блокировку, вызванную транзакцией а, только после того, как в этой транзакции встретится инструкция commit или rollback. Затем СУБД позволяет продолжить выполнение транзакции в. Теперь транзакция в блокирует эту же часть базы данных, защищая ее от других транзакций.

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

Уровни блокировки

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

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

Во многих СУБД реализована блокировка на уровне страниц. В этом случае СУБД блокирует отдельные блоки данных на диске ( страницы ), когда транзакция обращается к ним. Остальным транзакциям запрещается доступ к заблокированным страницам, но они могут обращаться к другим страницам данных (и блокировать их для себя). Обычно используются страницы размером 2, 4 и 16 Кб. Поскольку большая таблица состоит из сотен или даже тысяч страниц, две транзакции, обращающиеся к двум различным строкам таблицы, как правило, обращаются к различным страницам; в результате обе транзакции выполняются параллельно.

За последние несколько лет в большинстве ведущих СУБД была реализована блокировка на уровне строк. Она допускает параллельное выполнение транзакций, которые обращаются к двум рааличным строкам таблицы, даже если эти строки содержатся на одной странице. Хотя такая возможность кажется несущественной, в случае таблиц, содержащих небольшое число строк (например, таблица offices из учебной базы данных), она может играть важную роль.

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

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

Теоретически можно пойти еще дальше и осуществлять блокировку отдельных ячеек таблиц. В теории такая блокировка должна обеспечить еше большую степень параллелизма, чем блокировка строк, поскольку она разрешае-i параллельный доступ двух различных транзакций к одной и той же строке, если они обращаются к различным наборам столбцов. Однако затраты, связанные с блокировкой ячеек, значительно превышают потенциальную отдачу. Ни в одной коммерческой реляционной СУБД не используется блокировка такого типа.

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

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

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

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

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

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

Транзакция А

Транзакция В

Рис. 12.11. Правила приме, юния жесткой и нежесткой блокировок