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

В отнощений средств поддержки восстановления, определенных в стандарте языка SQL, следует отметить, что в языке SQL предусмотрены явные операции COMMIT и ROLLBACK, но нет явной операция BEGIN TRANSACTION. В нем также предусмотрена операция SET TRANSACTION, которая позволяет установить режим доступа и уровень изоляции для следующей выполняемой транзакции.

И еще один момент. По умолчанию считалось, что в данной главе речь идет о среде прикладного программирования. Тем не менее все описанные концепции применимы и к пользовательской среде (хотя на этом уровне они могут быть в определенной степени скрыты). Например, SQL-продукты обычно позволяют пользователю вводить SQL-операции интерактивно, с терминала. Обычно каждая такая интерактивная SQL-операция обрабатывается как отдельная транзакция - по умолчанию система будет автоматически выполнять операцию COMMIT от имени пользователя сразу после выполнения заданной им SQL-операции (или же операцию ROLLBACK, если произойдет сбой). Однако в некоторых системах пользователи могут запрещать такие автоматические операции COMMIT и вместо этого выполнять целую серию SQL-операций (за которыми последует явная операция COMMIT), как единую транзакцию. На практике делать это не рекомендуется, так как в подобном случае часть базы данных может быть заблокирована и на длительное время стать недоступной для других пользователей (глава 15). Более того, в такой операционной среде для конечных пользователей возможно возникновение ситуации взаимной блокировки, что является еще одним аргументом в пользу отказа от подобной практики (подробности приводятся в главе 15).

Упражнения

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

14.2. Транзакции не могут быть вложены одна в другую. Почему?

14.3. Дайте определение правила предварительной записи в журнал. Для чего оно нужно?

14.4. Каков смысл описанных ниже требований с точки зрения восстановления?

а) Принудительная запись буферов базы данных во время операции COMMIT.

б) Запрещение физической записи буферов в базу данных до выполнения операции COMMIT.

14.5. Изложите суть протокола двухфазной фиксации и опишите последствия отказа во время каждой из его двух фаз для координатора и участника в отдельности.

14.6. Используя базу данных поставщиков и деталей, создайте SQL-программу для выборки и распечатки сведений обо всех деталях в порядке их номеров детали, удаляя каждую десятую строку и начиная каждую новую транзакцию после каждой

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

Замечание. В данном случае предложено предоставить решение с помощью языка SQL, поэтому при подготовке ответа можно использовать механизм SQL-курсоров.

Список литературы

14Л. Bernstein Р.А. Transaction Processing Monitors САСМ. - November, 1990. - 33, № И.

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

14.2. Bernstein Р.А., Hadzilacos V., Goodman N. Concurrency Control and Recovery in Database Systems. - Reading, Mass.: Addison-Wesley, 1987.

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

14.3. Bilris А. et al. ASSET: А System for Supporting Extended Transactions Proc. 1994 ACM SIGMOD Int. Conf on Management of Data, Minneapolis, Minn., May, 1994.

Основные понятия в области обработки транзакций, изложенные в этой и следую-шей главах, считаются чрезмерно жесткими для некоторых типов приложений (особенно для высокоинтерактивных приложений), а потому для устранения данного недостатка было предложено несколько расширенных моделей обработки транзакций [14.15]. Но на время написания настоящей книги ни одно из этих предложений не продемонстрировало своего очевидного превосходства над другими. В результате разработчики баз данных [не спешили] с включением какой-либо одной модели в свои программные продукты .

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

14.4. Bjork L.A. Recovery Scenario for a DB/DC System Proc. ACM National Conference. - Atlanta, Ga, August, 1973.

Эта и аналогичная статья Дэвиса (Davies) [14.7] представляют собой, наверное, наиболее ранние теоретические работы в области восстановления.

14.5. Crus R.A. Data Recovery in IBM DATABASE 2 IBM Sys. J. - 1984. - 23, № 2.

Здесь подробно описан механизм восстановления, используемый в системе DB2 (тем самым дано очень хорошее общее описание механизма восстановления). В частности, объясняется, как система DB2 восстанавливается в процессе восстановления после сбоя в системе, в то время как сама транзакция находится посередине отката. При решении этой проблемы необходимо убедиться в том, что незафиксированные обновления транзакции, для которой выполнялся откат, будут действительно отменены.

14.6. Date C.J. Distributed Database: A Closer Look C.J. Date and Hugh Darwen. Relational Database Writings 1989-1991. - Reading, Mass.: Addison-Wesley, 1992.

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

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

14.7. Davies СТ., Recovery Jr Semantics for a DB/DC System Proc. ACM National Conf. - Atlanta, Ga, August, 1973.

Cm. комментарий к [14.4].

14.8. Davies СТ., Recovery Jr. Data Processing Spheres of Control IBM Sys. J.- 1978.- 17, №2.

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

14.9. Garcia-Molina Н., Salem К. Sagas Proc. 1987 ACM SIGMOD Intern. Conf. on Management of Data. - San Francisco, Calif, May, 1987.

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