Уважаемые читатели!

Я снова предлагаю Вашему вниманию перевод небольшой статьи из журнала ACM SIGMOD Record. В этой статье описывается стиль работы и выполняемые проекты небольшой исследовательской лаборатории компании Microsoft, ориентированной на тематику баз данных. Материал показался интересным по двум причинам. Во-первых, эти люди выполняют интересные, полезные и выполнимые исследовательские проекты, в которых, как полагается, создаются действующие прототипы программных систем. Честно говоря, мне захотелось самому присоединиться к этой группе. Во-вторых, мне было очень занимательно хоть немного увидеть Microsoft изнутри. По-моему, статья меняет сложившееся в России мнение о компании как о стремящейся только к одному - как можно быстрее выпускать дешевые (и не всегда надежные) программные продукты, все более завоевывая рынок. Теперь видно, что по крайней мере в области баз данных современные продукты Microsoft базируются на качественно проводимых исследованиях. Теперь мне понятно, почему Microsoft SQL Server казался мне лучшим продуктом компании. Рекомендую сходить на сайт лаборатории и познакомиться с ее сотрудниками получше.

С уважением, Сергей Кузнецов

---

ACM SIGMOD Record

Volume 27, Number 3, September 1998

The Microsoft Database Research Group

David Lomet, Roger Barga, Surajit Chaudhuri, Paul Larson, Vivek Narasayya
Оригинал статьи можно найти по адресу www.acm.org/sigmod/record/issues/9809/microsoft.ps.

Microsoft Research
One Microsoft Way, Bldg. 9
Redmont, WA 98052

1. Обзор

1.1. История

Стратегический интерес Microsoft в области данных существует начиная с 1993 г. и связан с усилиями Дэвида Васкевича (David Vaskevitch), который является теперь вице-президентом Microsoft, отвечающим за деятельность групп разработки продуктов баз данных и обработки транзакций. Дэвид предвидел, что в мире понадобятся миллионы серверов и что это предоставляет восхитительные возможности такой компании как Microsoft, продающей программное обеспечение в больших объемах и по низкой цене. В предвидении Дэвида важную роль играли системы баз данных, и то же самое относится к текущим планам производства продуктов Microsoft. В конце 1993 г. Дэвид начал искать первых людей для работы над базами данных и управлением транзакциями.

В область усилий Васкевича входило желание Microsoft образовать исследовательскую группу баз данных. Вице-призидент Microsoft по исследовательской работе Рик Рашид (Rick Rashid) сотрудничал с Васкевичем в переманивании Дэвида Ломета из Digital's Cambridge Research Lab, чтобы начать работу исследовательской группы баз данных. Ломет поступил на работу в Microsoft Research в январе 1995 г. Тем самым, к настоящему времени возраст исследовательской группы баз данных составляет немногим более трех с половиной лет.

Один человек не составляет группу. Продолжались усилия по переманиванию. Сараджит Чаудхари, исследователь из HP Labs, присоединился к группе баз данных в феврале 1996 г. Пол Ларсон, профессор университета Ватерлоо, - в мае этого года. Вивек Нарасайа, который летом 1996 г. проходил интернатуру как дипломник Вашингтонского университете, официально вошел в состав группы в апреле 1997 г. Новичек группы Роджер Барга, получивший степень Ph.D. в Oregon Graduate Institute, присоединился к группе в декабре 1997 г.

1.2. Исследовательская среда Microsoft

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

Окружение исследований: Люди из Microsoft Research и, в особенности, Рик Рашид полагают, что одной из существенных мер качества нашей исследовательской работы является публикация наших результатов на основных конференциях и журналах в этой области. Это стимулирует нас соизмерять свой успех с результатами лучших исследователей в каждой области. Другой важной мерой наших исследований является передача технологии производственным группам, что заставляет нас сосредотачивать внимание на индустриально значимых проблемных областях. Таким образом, профессиональное влияние и соответствие производственным потребностям обеспечивают высококвалифицированные индустриальные исследования.

География: По существу вся разработка продуктов сосредоточена в одном кампусе в Редмонде. Это означает, что располагающиеся в Редмонде исследователи компании находятся всего в пяти минутах ходьбы от любой группы разработчиков, с которыми они сотрудничают. Это исключительно облегчает как консультационные действия, так и передачу технологии, созданной исследователями.

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

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

1.3. Активности в области исследований баз данных

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

Исследовательские проекты

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

Самонастраивающиеся базы данных: Долговременной целью проекта AutoAdmin является превращение систем баз данных в самоадминистрирующиеся и самонастраивающиеся в полном объеме. Исходно в фокусе проекта находилась проблема физического проектирования баз данных (выбор индексов и материализованных представлений). В проекте AutoAdmin участвуют Сураджит Чаундхари, Пол Ларсон и Вивек Нарасайа.

Устойчивые приложения: Долговременной целью проекта Phoenix является улучшение доступности приложений и устойчивости к ошибочным ситуациям. Исходно в фокусе проекта находилась разработка таких методов восстановления баз данных, которые позволяют приложению пережить крах системы. Над проектом Phoenix работают Дэвид Ломет и Роджер Barga.

Наши исследовательские проекты более полно описываются в следующих двух разделах.

Консультационная деятельность

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

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

Наша консультационная работа оказала умеренное влияние на несколько продуктов Microsoft.

SQL Server: SQL Server 7.0 представляет собой существенное развитие SQL Server. Большие части компонентов обработки запросов и управления памятью были переписаны с достижением весьма улучшенных показателей функциональности, эффективности, расширяемости и модульности. Наши исследовательские консультации были особенно полезны для оптимизатора запросов в связи с использованием индексов, для компонента управления памятью в связи с поддержкой блокировок на уровне записи, для достижения улучшенной производительности работы сервера для выполнения запросов категории OLAP.

Windows NT: Windows NT - это современная и постоянно развивающаяся операционная система, ориентированная и на настольные компьютеры и на серверы. Наши консультации относительно кэширования и использования памяти помогли добиться важного улучшения производительности.

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

2. Проект AutoAdmin

2.1. Своевременность

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

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

2.2. Проект

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

2.1.1. Выбор индексов и материализованных представлений

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

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

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

Разработанная нами в проекте AutoAdmin технология выбора индексов требует установления и прототипирования интерфейсов нового сервера баз данных для разрешения создания гипотетических индексов. Для создания гипотетического индекса требуется эффективное получение статистик для столбцов этого индекса. На этом шаге мы используем методы образцов [CMN98]. Были реализованы два компонента, в которых применяются эти интерфейсы.

Утилита index analysis utility [CN98] создает набор гипотетических индексов и анализирует их влияние при различных рабочих нагрузках системы. Утилита анализа может быть использована в разных клиентских инструментальных средствах.

Мы использовали утилиту анализа индексов при разработке средства index tuning wizard, которое циклически эффективно обходит пространство гипотетических индексов с целью предложения набора индексов, подходящего для данной рабочей загрузки. Оценить рабочую загрузку можно на основе тестового набора заказчика или путем просмотра журнала сервера баз данных с помощью доступных утилит. При каждом выборе набора гипотетических индексов используются специальные интерфейсы сервера баз данных для создания гипотетических индексов и оценки их потенциала для повышения производительности при данной нагрузке. Мастер настройки индексов использует новый метод поиска, который отсеивает ложные индексы на ранней стадии и использует характеристики подсистемы обработки запросов для снижения стоимости выбранных индексов. Например, принимает во внимание возможность доступа только к индексам. Кроме того, мастер структурным способом генерирует сложные варианты (например, индексы на нескольких столбцах) из хороших простых вариантов (например, индексов на одном столбце). Технические детали этого мастера можно найти в [CN97].

Несмотря на молодость проекта AutoAdmin, мы успешно воздействуем на SQL Server. В следующем выпуске (SQL Server 7.0) будет присутствовать наш мастер настройки индексов, который можно будет пускать в ход разными способами для выбора подходящих индексов в соответствии c рабочей нагрузкой [CN98-wp]. Рабочая нагрузка может обеспечиваться внешним образом или создаваться с использованием профилировщика SQL Server. Мастер настройки индексов будет существенным вкладом в решение задачи упрощения администрирования SQL Server.

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

2.2.2. Обработка запросов с использованием материализованных представлений

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

• Преобразование запросов: Оптимизатор запросов должен быть в состоянии переформулировать запрос для использования материализованных представлений, когда это выгодною
• Поддержка представлений: Система должна автоматически обновлять все необходимые материализованные представления при каждом обновлении базовых таблиц.

До сих пор наша работа над материализованными представлениями фокусировалась на проблеме преобразования запросов. В большинстве предыдущих работ по поводу преобразования запросов делалось несколько упрощающих предположений: запросы и представления только категории "проекция-селекция-соединение" (Project-Select-Join - PSJ), семантика множеств (а не мультимножеств), никакого знания ограничений (таких как ключи и внешние ключи), вычисление запросов на одном представлении. В настоящее время мы имеем работающий прототип системы преобразования запросов, который справляется с более широким классом запросов и представлений (проекция-селекция-соединение-группирование) с обычной семантикой SQL, использует знания о ключах и внешних ключах, берется за преобразования запросов на нескольких представлениях. Мультимножественная семантика SQL добавляет новое измерение в проблему преобразования запросов, поскольку мы должны быть уверены не только в получении всех требуемых строк, но и в том, что будет правильно учтен фактор дубликации.

Принятие во внимание знаний о ключах и внешних ключах оказалось очень важным, но также и поразительно сложным. Рассмотрим две таблицы - Orders и Customers, где таблица Orders содержит внешний ключ CustomerNo, в котором запрещены неопределенные значения и который ссылается на первичный ключ таблицы Customers. Предположим, что имеется представление, получаемое (естественным) соединением Orders и Customers, и что задается запрос, адресуемый к таблице Orders. Без знаний о ключах и внешних ключах мы могли бы заключить, что запрос не может быть выполнен с применением представления. (Поскольку операция естественного соединения в языке SQL по определению отсекает строки с неопределенными значениями столбца соединения и устраняет в результате дубликаты. Прим. С.Кузнецова.) Принимая во внимание внешние ключи, мы можем заключить, что в представлении присутствуют все требуемые строки, но, возможно, без учета фактора дублирования. Для гарантирования того, что фактор дублирования учитывается корректно, мы должны принять во внимание, одним из столбцов соединения является первичный ключ.

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

Литература

1. CN97 Chaudhuri, S., Narasayya V. "An Efficient, Cost-Driven Index Selection Tool for Microsoft SQL Server". Proceedings of the 23^rd VLDB Conference. Athens, Greece, 1997, pages 146-155.
2. CMN98 Chaudhuri S., Motwani R., Narasayya V. "Random Sampling for Histogram Constraction: How much is enough?" Proceedings of the ACM SIGMOD International Conference on Management of Data, 1998.
3. CN98 Chaudhari S., Narasayya V. "AutoAdmin 'What-If' Index Analysis Utility". Proceedings of the ACM SIGMOD International Conference on Management of Data, 1998.
4. CN98-wp Chaudhari S., Narasayya V. "Index Tuning Wizard for Microsoft SQL Server". Microsoft White Paper.

3. Проект Phoenix

3.1. Своевременность

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

Системные крахи

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

Логические ошибки

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

3.2. Проект

В проекте Phoenix мы прежде всего сосредоточились на доступности и живучести приложений.

Технология восстановления Redo

Мы исследовали технологию, в которой используется новая технология восстановления баз данных redo [LD95] для обеспечения приложениям возможности пережить системные крахи, т.е. обеспечения восстановления состояния приложения наряду с восстановлением состояния базы данных [L97, L98]. Это позволяет приложениям благополучно поддерживать состояние между несколькими транзакциями. Хотя формы устойчивости программ не новы, требовались высокие расходы на журнализацию и установление контрольных точек для реализации устойчивости. Методы, разработанные в проекте Phoenix, существенно сокращают эти расходы на выполнение приложений за счет возможности логической журнализации, что уменьшает расходы на журнализацию. В этих методах применяются механизмы системы баз данных управления кэшированием и восстановления. Хотя остаются дополнительные системные расходы на поддержку устойчивости приложений, они гораздо меньше, чем раньше. Проект Phoenix продолжает развивать тенденцию к расширению системных ресурсов для сбережения более дорогих и более подверженных ошибкам человеческих ресурсов.

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

При дальнейшем расширении могут также обеспечиваться надежные клиент-серверные приложения баз данных [LW98]. Дальнейшее развитие этих методов должно сделать возможным сокрытие системных сбоев путем включения подкомпонентов приложения из компонентов более высокого уровня в более распределенную среду, такую как распределенная среда обработки транзакций или потоков работ.

Прототип устойчивых сессий ODBC

В работе над нашими начальными системами мы избежали трудностей, связанных с потребностями существенных изменений во внутренних частях системы восстановления баз данных, сосредоточившись на доступности сессий ODBC. Термин ODBC означает "open database connectivity" - технологию, основанную на стандарте ANSI/ISO, которая позволяет приложениям осуществлять доступ к нескольким базам данных сторонних поставщиков. В ODBC применяется интерфейс общего назначения CLI (call level interface), в котором SQL используется как стандарт для доступа к данным. Нашей целью является обеспечение устойчивых серверных сессий для клиентских систем, поддерживающих ODBC. Сессии могут переживать системный крах без потребности того, чтобы клиентские приложения не беспокоились об остановке работы, разве только из соображений времени выполнения.

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

Для обеспечения доступности сессий ODBC мы ввели обобщенный Phoenix ODBC драйвер, который будет работать с любой базой данных. Наш драйвер ODBC перехватывает каждое взаимодействие с системой баз данных средствами ODBC, поскольку только эти взаимодействия могут изменить состояние сессии ODBC. По существу, он обволакивает любой драйвер ODBC конкретной базы данных. Драйвер Phoenix перехватывает запросы приложения, направляемые серверу баз данных, журнализует операторы, изменяющие контекст сессии, и переписывает выбранные операторы SQL таким образом, чтобы вызвать создание долговременных таблиц базы данных, которые сохраняют состояние приложения. Затем запрос передается соответствующему "настоящему" драйверу ODBC. Ответы возвращаются из сервера "настоящему" драйверу ODBC. Драйвер Phoenix ODBC перехватывает ответы "настоящего" драйвера клиентского приложения, различным образом кэширует, фильтрует, переформировывает результирующий набор и синхронизуется с состоянием приложения, материализованным на сервере баз данных.

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

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

Литература

1. LT95 Lomet, D and Tuttle, M. Redo Recovery after System Crashes, VLDB Conference (Sept. 1995). Zurich, Switzerland, 457-468.

2. L97 Lomet, D.B. Application Recovery: Advances toward an Elisive Goal. Workshop on High Performance Transaction Systems (HPTS97). Asilomar, CA (September, 1997).
3. L98 Lomet, D.B. Persistent Applications Using Generalized Redo Recovery. International Conference on Data Engineering, Orlando, FL (Feb. 1998), 154-163.
4. LW98 Lomet, D.B. and Weikum, G. Efficient Transparent Application Recovery in Client-Server Information Systems. ACM SIGMOD Conference, Seattle, WA (June 1998) (best paper award).