14.8. Резюме
В этой главе кратко представлена необходимая информация об обработке транзак- ций. Транзакция — это логическая единица работы, а также единица восстановле- ния (кроме того, единица параллельности и целостности; подробности приводятся в гла- вах 15 и 8 соответственно). Транзакции обладают АСШ-свойствами — атомарностью, согласованностью, изолированностью и долговечностью. Управление транзакция- ми предусматривает решение задачи организации их выполнения таким образом, чтобы соблюдение всех этих важнейших свойств абсолютно гарантировалось. Проще говоря, общая цель функционирования всей системы может быть определена как надежное вы- полнение потока транзакции.
Транзакции инициируются операцией BEGIN TRANSACTION и завершаются опера- цией COMMIT (в случае успешного завершения) либо ROLLBACK (в случае неудачного завершения). Оператор COMMIT устанавливает точку фиксации (при этом обновле- ния становятся постоянными). Выполнение оператора ROLLBACK возвращает базу данных в предыдущую точку фиксации (все внесенные изменения отменяются). Ес- ли транзакция не достигает запланированного завершения, система принудительно выполняет для нее операцию ROLLBACK (восстановление транзакции). Для получе- ния возможности отмены (или повторного внесения) выполненных обновлений сис- тема поддерживает журнал регистрации транзакций. Важно отметить, что все за- писи регистрации хода выполнения некоторой транзакции должны быть физически занесены в журнал до выполнения для этой транзакции операции COMMIT (правило предварительной записи в журнал).
Кроме того, необходимо гарантировать сохранение ACID-свойств транзакций даже в случае сбоя системы. Для обеспечения такой гарантии система должна: а) повторно выполнить всю работу, выполненную транзакциями, которые успешно завершились до момента отказа; б) отменить всю работу, выполненную транзак- циями, которые начались, но не закончились до момента сбоя. Восстановление системы осуществляется как часть процедуры перезагрузки (которая иначе назы- вается процедурой перезагрузки/восстановления). Анализируя последнюю имею- щуюся в журнале запись контрольной точки, система определяет, какую работу необходимо выполнить повторно, а какую отменить. Записи контрольной точки за- носятся в журнал через установленное время.
Система также обеспечивает восстановление носителей, что реализуется путем вос- становления базы данных с заранее созданной резервной копии (дампа) с последующим использованием журнала для повторного выполнения всей работы, проведенной в базе данных после создания данной резервной копии. Для поддержки функции восстановле- ния носителей используются утилиты восстановления с резервной копии.
Системы, позволяющие транзакциям взаимодействовать с двумя (или более) раз- личными менеджерами ресурсов (например, с двумя разными СУБД или СУБД и менеджером передачи данных), должны использовать протокол, называемый прото- колом двухфазной фиксации, который обеспечивает обязательное соблюдение свойства атомарности транзакции. Две фазы этого протокола включают: а) подгото- вительную фазу, в которой координатор дает указание всем участникам быть го- товыми "действовать одним из возможных способов"; б) фазу фиксации, в которой координатор (после того как все участники дали ожидаемый от них ответ во время
предыдущей фазы) инструктирует участников, что можно выполнить окончательную фиксацию данной транзакции (или ее откат в случае получения хотя бы одного от- рицательного ответа).
В отношении средств поддержки восстановления, определенных в стандарте языка SQL, следует отметить, что в языке SQL предусмотрены явные операции COMMIT и ROLLBACK, но нет явной операция BEGIN TRANSACTION. В нем также предусмотрена опе- рация SET TRANSACTION, которая позволяет установить режим доступа и уровень изо- ляции для следующей выполняемой транзакции.
И еще один момент. По умолчанию считалось, что в данной главе речь идет о среде прикладного программирования. Тем не менее все описанные концепции при- менимы и к пользовательской среде (хотя на этом уровне они могут быть в опреде- ленной степени скрыты). Например, SQL-продукты обычно позволяют пользователю вводить SQL-операции интерактивно, с терминала. Обычно каждая такая интерак- тивная SQL-операция обрабатывается как отдельная транзакция — по умолчанию система будет автоматически выполнять операцию COMMIT от имени пользователя сразу после выполнения заданной им SQL-операции (или же операцию ROLLBACK, ес- ли произойдет сбой). Однако в некоторых системах пользователи могут запрещать такие автоматические операции COMMIT и вместо этого выполнять целую серию SQL- операций (за которыми последует явная операция COMMIT), как единую транзакцию. На практике делать это не рекомендуется, так как в подобном случае часть базы данных может быть заблокирована и на длительное время стать недоступной для других пользователей (глава 15). Более того, в такой операционной среде для конеч- ных пользователей возможно возникновение ситуации взаимной блокировки, что яв- ляется еще одним аргументом в пользу отказа от подобной практики (подробности приводятся в главе 15).
Упражнения
Системы баз данных не позволяют транзакции фиксировать изменения только в отдельных базах данных (или переменных-отношениях и т.д.), т.е. без одновремен- ного фиксирования этих изменений во всех других базах данных (или переменных- отношениях и т.д.). Почему?
Транзакции не могут быть вложены одна в другую. Почему?
Дайте определение правила предварительной записи в журнал. Для чего оно нужно?
Каков смысл описанных ниже требований с точки зрения восстановления?
а) Принудительная запись буферов базы данных во время операции COMMIT.
б) Запрещение физической записи буферов в базу данных до выполнения опера- ции COMMIT.
Изложите суть протокола двухфазной фиксации и опишите последствия отказа во время каждой из его двух фаз для координатора и участника в отдельности.
Используя базу данных поставщиков и деталей, создайте SQL-программу для вы- борки и распечатки сведений обо всех деталях в порядке их номеров детали, уда- ляя каждую десятую строку и начиная каждую новую транзакцию после каждой
десятой строки. Предположим, что для внешнего ключа таблицы деталей по отно- шению к данным о поставщиках для операции DELETE задано правило CASCADE (т.е. в рамках этого упражнения можно игнорировать поставки).
Замечание. В данном случае предложено предоставить решение с помощью языка SQL, поэтому при подготовке ответа можно использовать механизм SQL-курсоров.
Список литературы
14.1. Bernstein Р.А. Transaction Processing Monitors // САСМ. — November, 1990. — 33, № 11.
"TP-система является интегрированным набором продуктов, которые... вклю- чают аппаратное обеспечение, такое как процессоры, оперативная память, диски, контроллеры обмена данными, а также программное обеспечение, такое как опе- рационные системы, СУБД, компьютерные сети и TP-диспетчеры. Интеграция этих средств, в основном, достигается благодаря TP-диспетчерам." Эта статья является хорошим неформальным введением в структуру и функции диспетчеров обработки транзакций.
14.2. Bernstein Р.А., Hadzilacos V., Goodman N. Concurrency Control and Recovery in Database Systems. — Reading, Mass.: Addison-Wesley, 1987.
В этом учебнике намного шире, чем в представленной главе, описываются не только восстановление (как следует из ее названия), но и обработка транзакций в целом.
14.3. Bilris A. et al. ASSET: A 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. Cms 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.
См. комментарий к [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.
Большинство проблем, связанных с транзакциями, состоит в том, что по умол- чанию транзакции длятся очень короткое время (милли- или даже микросекун- ды). Но если транзакция длится долго (часы, дни, недели), то а) в случае ее от- ката будет отменена очень большая часть работы; б) даже если все пройдет ус- пешно, она все же будет удерживать ресурсы системы неопределенно долгое время, тем самым блокируя доступ к ним других пользователей (этот вопрос подробнее обсуждается в следующей главе). К сожалению, множество реаль-
ных транзакций стремится к увеличению времени своего действия, особенно в новейших сферах применения, таких как проектирование и разработка про- граммного и аппаратного обеспечения.
Хроники представляют собой попытку решения этой проблемы. Хроника (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.11.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 A. Transaction Processing: Concepts and Techniques. — San Mateo, Calif.: Morgan Kaufmann, 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 A. Principles of Transaction-Oriented Database Recovery // Ibid.— 1983.— 15, №4.
В этой статье впервые было представлено сокращение "ACID-свойства". В ней да- ется очень четкое и подробное представление о принципах восстановления. Здесь приведена продуманная терминология для описания схем восстановления и мето- дов регистрации входа в систему, даны классификация и описание множества су- ществующих систем в соответствии с этой терминологией. Также приведены инте- ресные эмпирические данные, показывающие частоту возникновения и типичное время восстановления для трех видов сбоев (локальных, системных и сбоев носи- телей) в больших системах.
|
Тип отказа |
Частота возникновения |
Время восстановления |
|
Локальный Системный Сбой носителей |
10—100 раз в минуту Несколько раз в неделю Один или два раза в год |
Равно времени выполнения транзакции Несколько минут 1—2 часа |
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 A. A 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. A. Physical Integrity in a 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, № 1.
Название алгоритма ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) расшифровывается как "алгоритм восстановления и использующей изоляцию семантики". Он применяется ("в некоторой степени") в некоторых коммерческих и экспериментальных системах, в частности в системе DB2. Вот несколько перефразированная цитата из этой статьи: "Решения [проблемы обра- ботки транзакций] можно оценить с помощью нескольких критериев: степени параллельности в пределах одной страницы и нескольких страниц; сложности полученной логики; накладных расходов, связанных с использованием простран- ства для хранения журнала регистрации транзакций и данных на долговремен- ном устройстве хранения и в оперативной памяти; накладных расходов, связан- ных с многочисленными синхронными и асинхронными операциями ввода- вывода, которые необходимо выполнить во время перезагрузки/восстановления и нормальной обработки; типов поддерживаемых функций (частичного отката
транзакций и т.д.); объема вычислений, выполняемых во время перезагруз- ки/восстановления; степени параллельности вычислений, выполняемых во время перезагрузки/восстановления; уровня откатов транзакций, вызванных ситуация- ми взаимной блокировки в системе; ограничений, накладываемых на хранимые данные (например, требований уникальности ключей для всех записей, ограни- чений максимального размера объектов до размера страницы и т.д.); способно- сти поддерживать новые режимы блокировки, в которых допускается параллель- ное выполнение (на основе коммутативности и других свойств) таких операций, как инкремент/декремент для тех же данных, но разными транзакциями и т.д. По этим критериям [ARIES] оценивается очень высоко".
Со времени создания метода ARIES появилось множество его усовершенствова- ний, разработано и описано в литературе несколько специализированных версий: ARIES/CS (для систем с архитектурой "клиент/сервер"), ARIES/IM (для обработки индексов) и ARIES/NT (для вложенных транзакций) и т.д.
Ответы к некоторым упражнениям
Подобные действия будут противоречить понятию "атомарность транзакции". Ес- ли бы транзакция зафиксировала некоторые, не все свои, обновления, то незафик- сированные обновления можно было бы впоследствии аннулировать, в то время как зафиксированные, конечно же, отменить было бы уже невозможно. Таким об- разом, для транзакции не будет выполнено условие атомарности, требующее "выполнить все или ничего".
Подобное решение будет противоречить понятию "атомарность транзакции". Предположим, что транзакция В была вложена в транзакцию А. Тогда последова- тельность событий будет такой (для простоты предположим, что имеет смысл го- ворить об "обновлении кортежа").
BEGIN TRANSACTION (транзакция А) ;
BEGIN TRANSACTION (транзакция В) ; транзакция В обновляет кортеж t ; COMMIT (транзакция В) ;
ROLLBACK (транзакция А) ;
Если кортеж b восстанавливается до своего предыдущего значения (назовем его pre-А), то фиксация (COMMIT) транзакции В, по сути, не происходит полностью. Однако если фиксация (COMMIT) транзакции В была истинной, то кортеж b не может быть восстановлен до своего значения pre-А и, следовательно, откат (ROLLBACK) транзакции А не может быть успешным.
Требование того, чтобы транзакции не могли вкладываться одна в другую, означа- ет возможность выполнения команды BEGIN TRANSACTION только в том случае, ес- ли не выполняются никакие транзакции.
Однако многие авторы (начиная с Дэвиса [14.7]) предложили реализовать воз- можность вложения транзакций за счет отмены требования долговечности (свойство "D" в ACID-свойствах) по отношению к части внутренней транзак-
14.4.
14.6.
ции. Это означает, что фиксация (COMMIT), выполняемая внутренней транзак- цией, приведет к фиксации обновлений этой транзакции, но только до сле- дующего внешнего уровня. Если же этот внешний уровень завершается откатом выполненных действий, внутренняя транзакция также завершается откатом. В данном примере операция COMMIT для транзакции В зафиксировала бы обнов- ления до окончания транзакции А, но не для внешнего мира и впоследствии действительно могла бы быть отменена.
Полезно будет детальнее рассмотреть упомянутые выше идеи. Вложенные транзакции можно рассматривать как обобщение понятия точек сохранения [14.11]. Точки сохранения позволяют организовать транзакции в виде последо- вательности действий (а потому откат можно выполнить в любой момент до начала любого другого предыдущего действия в этой последовательности), а вложенность, наоборот, позволяет организовать транзакции в виде иерархии таких действий (рис. 14.4). Иначе говоря:
■ команда BEGIN TRANSACTION расширяется для поддержки подчиненных транзак- ций (т.е. если команда BEGIN TRANSACTION стартует тогда, когда выполняется ка- кая-то транзакция, запускается дочерняя транзакция);
«
командаCOMMIT
фиксирует
выполне-
ние транзакции, но только в
пределах
родительской
области видимости
(если
транзакция является дочерней);
■ команда ROLLBACK отменяет выпол- ненную работу, но только до начала этой отдельной транзакции (включая дочерние транзакции, дочерние тран- закции этих дочерних транзакций и т.д., но не родительскую транзакцию).
Отметим, что вложенные транзакции в языках, подобных языку SQL, весьма не- удобны для воплощения (с синтаксиче- ской точки зрения), так как в них имеет- ся один серьезный недостаток— отсутствие явного оператора BEGIN TRANSACTION (необходим некоторый явный способ определения начала внутренней транзакции или точки фиксации для отката, если эта внутренняя транзакция потерпела неудачу).
а) В случае отказа системы никогда не потребуется выполнять операции REDO.
б) Физическая операция UNDO никогда не будет необходимой. Следовательно, поме- щать в журнал регистрации сведения об операциях UNDO также необязательно.
Это упражнение является типичным примером широкого класса приложений, для которых обычно применяется следующее решение.
EXEC SQL DECLARE CP CURSOR FOR
SELECT P.PI, P.NAME, P.COLOR, P.WEIGHT, P.CITY
FROM P
WHERE P.Pi > previous_P# ORDER BY Pi ; previous_Pi := ' ' ;
eof := false ; DO WHILE ( eof = false ) ; EXEC SQL OPEN CP ;
DO count := 1 TO 10 ;
EXEC SQL FETCH CP INTO :Pi, ... ; IF SQLSTATE = '02000' THEN DO ;
EXEC SQL CLOSE CP ; EXEC SQL COMMIT ; eof := true ; END DO ; ELSE print Pi, ... ; END IF ; END DO ;
EXEC SQL DELETE FROM P WHERE P.Pi = :P# ; EXEC SQL CLOSE CP ; EXEC SQL COMMIT ; previous_Pi := Pi ; END DO ;
Обратите внимание на то, что информация о позиционировании в таблице деталей Р утрачивается в конце каждой транзакции (даже если не закрывать явным образом курсор CP, оператор COMMIT закроет его автоматически). Поэтому приведенный код не будет особенно эффективным в связи с тем, что для каждой новой транзакции потребуется выполнить поиск в таблице деталей для возврата к прежней позиции. Ситуацию можно немного поправить, если использовать индекс по столбцу Pi (что обычно происходит на практике, так как {Pi} является первичным ключом) и оп- тимизатор выберет этот индекс в качестве пути доступа к данной таблице.
Глава
Параллельность