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

Хроники представляют собой попытку решения этой проблемы. Хроника (saga) - это последовательность коротких транзакций (в обычном понимании этого термина), для которых со стороны системы гарантируется, что либо все транзакции данной последовательности будут выполнены успешно, либо будут выполнены некоторые компенсационные транзакции, предназначенные для отмены результатов успешно выполненных транзакций в случае незавершенного выполнения всей хроники в целом (таким образом, система будет приведена в состояние, существовавшее до начала выполнения хроники). Например, в банковских системах для транзакции Добавить $100 на счет А компенсационной транзакцией, очевидно, будет Снять $100 со счета А . Расширение оператора COMMIT позволяет пользователю информировать систему о том, что в случае отмены только что завершенной транзакции должна быть запущена определенная компенсационная транзакция. Обратите внимание, что в идеале компенсационная транзакция никогда не должна завершаться откатом. 14.10.Gray J. Notes on Data Base Operating System Operating Systems: An Advanced Course. -- New York, N.Y.: Springer-Verlag, 1978.

Это один из первых источников литературы о транзакциях, содержащий первое общедоступное описание протокола двухфазной фиксации. Очевидно, оно не столь всеобъемлюще, как более новые работы [14.12], но мы все еще рекомендуем с ним ознакомиться.

14.1 I.Gray J. The Transaction Concept: Virtues and Limitations Proc. 7th Intern. Conf. on Very Large Data Bases. - Cannes, France, 1981.

В этой работе приводится краткое описание проблем, связанных с транзакциями, включая вопросы их реализации. Одна из таких проблем формулируется следующим образом. Обычно предполагается, что транзакции не могут вкладываться одна в другую (в упражнениях к данной главе рассматривается вопрос, почему этого не может быть). Возникает вопрос: А может, все-таки можно сделать так, чтобы транзакция состояла из нескольких малых подчиненных транзакций ? . Краткий ответ таков: Да! . Это допустимо для транзакций, которые в определенные моменты свЬего выполнения будут устанавливать промежуточные точки сохранения (savepoints) и соответственно в случае необходимости откатываться в такую предыдущую точку вместо того, чтобы откатиться полностью к началу транзакции. Действительно, подобные точки сохранения использовались в нескольких системах, включая систему Ingres (коммерческий продукт, а не прототип) и систему R (но не DB2). Данная концепция представляется наиболее близкой к реальному понятию транзакции. Обратите внимание, что создание точки сохранения - это не то же самое, что выполнение операции COMMIT, поскольку обновления, осуществленные трант закцией, все еще не видны для других транзакций до тех пор, пока не будет успешно завершена вся транзакция. 14.12.Gray J., Reuter А. Transaction Processing: Concepts and Techniques. - San Mateo, Calif.: Morgan Kauftnann, 1993.

Если какая-либо публикация в области информатики и заслуживает эпитета классическая , то это, наверное, именно эта книга. Ее размер может показаться просто устрашающим, однако авторам удалось пролить свет даже на самые сложные аспекты обсуждаемой темы и одновременно сделать чтение предлагаемого материала достаточно легким. В предисловии авторы заявляют о своем намерении помочь... в решении реальных проблем ; книга прагматична и очень подробно освещает основные проблемы обработки транзакций ; в ней представлены фрагменты программ, демонстрирующие... основные алгоритмы и структуры данных ; однако она не является энциклопедией . Вопреки последнему утверждению, эта книга представляет собой достаточно полное руководство по данной теме и ей, очевидно, суждено стать стандартным пособием в данной области. Настоятельно рекомендуем вам ее прочесть. 14.13.Gray J. et al. The Recovery Manager of the System R Data Manager ACM Сотр. Surv. -June, 1981. - 13, №2.

Работы [14.13], [14.18] связаны с особенностями средств восстановления системы System R (одной из первых систем в данной области). В [14.13] дается краткий обзор всей подсистемы восстановления, а в [14.18] подробно описывается механизм теневой страницы (см. ниже). 14.14.Harder Т., Reuter А. Principles of Transaction-Oriented Database Recovery Ibid.- 1983.- 15, №4.

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

14.15.Evolving System Concept (invited talk) Proc. 21st Int. Conf On Very Large Data Bases. - Zurich, Switzerland, September, 1995.

Прекрасный краткий обзор вариантов эволюции понятия транзакция , которые удовлетворяли бы новым требованиям со стороны приложений. 14.16.Korth H.F., Levy Е., Silberschatz А. А Formal Approach to Recovery by Compensating Transactions Proc. 16th Intern. Conf on Very Large Data Bases.- Brisbane, Australia, 1990.

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

14.17.Lomet D., Turtle M.R. Redo Recovery after System Crashes Proc. 21st Int. Conf. On Very Large Data Bases. - Zurich, Switzerland, September, 1995. В этой работе дан строгий и тщательный анализ процесса восстановления повторно выполняемых обновлений (т.е. процесса прямого восстановления). [Хотя] процесс восстановления повторно выполняемых обновлений является всего лишь одной из форм восстановления, он имеет... большое значение [поскольку является значительной частью всего процесса восстановления] и должен помочь в разрешении самых сложных проблем. (В этой связи отметим, что в отличие от алгоритма, описанного в разделе 14.4, в методе ARIES [14.19] предполагается понимание восстановления... как восстановления повторно выполняемых обновлений и восстановления отмененных обновлений .) Авторы заявляют, что их анализ приводит к лучшему пониманию существующих реализаций и может значительно усовершенствовать системы восстановления.

14.18.Lorie R. А. Physical Integrity in а Large Segmented Database ACM TODS.- 1977.-2, № 1.

Как уже объяснялось в комментариях к [14.13], в этой статье описывается механизм теневой страницы - один из наиболее важных аспектов восстановления системы System R. (Отметим, что термин целостность {Integrity) в заглавии статьи имеет значение, несколько отличное от описанного в главе 8.) Идея механизма теневой страницы очень проста. Когда незафиксированное обновление впервые записывается в базу данных, система не переписывает существующую страницу, а сохраняет новую где-нибудь на диске. Старая страница - это тень новой. Фиксация обновления предусматривает установку различных указателей на новую страницу и удаление теневой страницы. И наоборот, откат обновления - это переустановка указателей на теневую страницу и отбрасывание новой. Несмотря на кажущуюся простоту механизм теневой страницы имеет один серьезный недостаток, заключающийся в разрушении любой физической кластеризации, ранее установленной для данных, и потому этот механизм не был перенесен из системы System R в систему DB2 [14.5], хотя и применялся в системе SQL/DS [4.13]. 14.19.Mohan С, Haderle D., Lindsay В. et al. ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging ACM TODS. - 1992. - 17, № i.

Название алгоритма ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) расшифровывается как алгоритм восстановления и использующей изоляцию семантики . Он применяется ( в некоторой степени ) в некоторых коммерческих и экспериментальных системах, в частности в системе DB2. Вот несколько перефразированная цитата из этой статьи: Решения [проблемы обработки транзакций] можно оценить с помощью нескольких критериев: степени параллельности в пределах одной страницы и нескольких страниц; сложности полученной логики; накладных расходов, связанных с использованием пространства для хранения журнала регистрации транзакций и данных на долговременном устройстве хранения и в оперативной памяти; накладных расходов, связанных с многочисленными синхронными и асинхронными операциями ввода-вывода, которые необходимо выполнить во время перезагрузки/восстановления и нормальной обработки; типов поддерживаемых функций (частичного отката