КаталогИндекс раздела
НазадОглавлениеВперед

Глава 2. Технологии федеративных баз данных

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

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

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

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

12 целей

К. Дейт [10] формулирует 12 основных целей, к которым стремятся создатели распределенных баз данных. Все эти 12 целей являются теми или иными следствиями из основной цели - "прозрачности" распределения для конечных пользователей. Ниже мы перечисляем эти цели. Некоторые из них понятны без комментариев, к некоторым мы даем небольшие комментарии здесь же, некоторые - рассматриваем подробно в следующих разделах этой главы.

  1. Локальная независимость. Каждый узел должен полностью контролировать выполняемые им операции. На самом деле, полная локальная независимость возможна не всегда, что будет показано ниже.
  2. Отсутствие опоры на центральный узел. Это вытекает из предыдущей цели. В системе федеративной базы данных не должно быть какого-то центрального узла, который управлял бы, например, выполнением запросов, управлением транзакциями и т.д. Это делало бы систему более уязвимой. Отсутствие опоры на центральный узел реализуемо даже тогда, когда невозможна полная локальная независимость.
  3. Непрерывное функционирование. Надежность и доступность федеративной базы данных повышается за счет достижения предыдущих целей. Аварийное отключение какого-либо узла не должно приводить к отключению всей системы. Так же не должно требовать отключений плановое выполнение каких-либо задач на узлах.
  4. Независимость от физического расположения. Пользователи не обязаны знать, где хранятся их данные. Данные могут быть переписаны с одного узла на другой без изменения приложений, работающих с этими данными (вспомните про независимость логической структуры данных от физической).
  5. Независимость от фрагментации. Разбиение таблиц на части (фрагменты) должно быть прозрачным для конечного пользователя. Мы еще вернемся к рассмотрению фрагментации.
  6. Независимость от репликации. При существовании в федеративной базе данных дубликатов данных приведение копий в соответствие должно быть прозрачным для конечного пользователя. Некоторые проблемы репликации будут рассмотрены ниже.
  7. Обработка распределенных запросов. Некоторые особенности их обработки рассматриваются ниже.
  8. Управление распределенными транзакциями - ему мы посвятим отдельный раздел.
  9. Аппаратная независимость.
  10. Независимость от операционной системы.
  11. Независимость от сетевых средств.
  12. Независимость от типа СУБД. В основном мы рассматриваем федеративную базу данных так, как если бы все узлы работали под управлением разных экземпляров одного продукта СУБД. Некоторые вопросы объединения в федеративную базу данных СУБД разных типов мы рассмотрим в конце данной главы.

Фрагментация

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

Фрагментация может быть горизонтальной или/и вертикальной.

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

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

Независимость от фрагментации состоит в том, что ни один из фрагментов не является производным от других фрагментов. Восстановление полной таблицы из фрагментов производится операциями объединения (горизонтальная фрагментация) или/и естественного соединения (вертикальная фрагментация) таблиц-фрагментов. Полная таблица может быть описана как представление, определяемое через указанные операции. При обновлении представления полной таблицы могут возникать проблемы, типичные для обновления представлений: необходимость определения того физического фрагмента, к которому относится обновление. Так, в приведенном выше примере горизонтальной фрагментации перевод сотрудника из одного отдела в другой (изменение значения в столбце кода отдела) потребует перенесения записи из одного фрагмента в другой.

Репликация

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

Наиболее простая схема обеспечения репликации - схема первичной копии - описывается следующим образом:

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

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

Распределенные запросы

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

Например, если на узле А имеется таблица ТА, содержащая 100 строк, а на узле В имеется таблица ТВ, содержащая 106 строк, и запрос требует соединения этих таблиц, то очевидно, что выгоднее переслать таблицу ТА на узел В и выполнить соединение на узле В, а не наоборот.

Другой пример. Выше мы рассмотрели пример таблицы EMPLOYEE (список сотрудников), фрагментированной горизонтально по отделам. Если в описаниях ее фрагментов указано ограничение на код отдела для фрагмента, и оптимизатор "знает" об этом ограничении, то запрос:


    SELECT * FROM employee WHERE dep_id = 'DEP1'

оптимизатор может локализовать на единственном узле - на том, для которого ограничение ключа фрагмента совпадает с условием, заданном в запросе.

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

Каталог федеративной базы данных

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

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

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

Одно из таких сочетаний было предложено в IBM System R* и послужило прототипом для многих распределенных систем. В этой системе на каждом узле хранится информация о локальных объектах данного узла и часть информации общего каталога, а именно - информация об объектах, которые были созданы на этом узле (даже если впоследствии они были перемещены).

Полное (системное) имя объекта имеет вид:

    user@crtnode.localname@savenode
где user - идентификатор пользователя, создавшего объект;
  crtnode - идентификатор узла, с которого была выполнена операция CREATE;
  localname - локальное имя объекта;
  savenode - идентификатор узла, на котором объект был впервые сохранен (в общем случае он не совпадает с crtnode).

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

В каталоге каждого узла поддерживаются элементы двух видов:

Предположим, что мы имеем объект с системным именем UA@N0.O1@N1. Как видно из системного имени, объект был создан на узле N0, впервые сохранен на узле N1, но предположим, что в настоящее время он находится на узле N2. При обращении по такому системному имени потребуется обращение к двум узлам:

Если далее наш объект будет перемещен с узла N2, скажем, на узел N3, то такое перемещение потребует обновления каталогов на трех узлах:

Из приведенных выше алгоритмов поиска и обновления видно, что системное имя объекта, присвоенное ему при его создании, не изменяется в течении всего времени жизни объекта, даже, если он перемещается с узла на узел.

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

Распределенные транзакции

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

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

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

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

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

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

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

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

Неоднородные федеративные базы данных

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

Стандарт ISO Remote Data Access (RDA) определяет форматы и протоколы для взаимодействия в системе клиент/сервер. Стандарт требует, чтобы в запросах применялся стандартный SQL (SQL/92) и чтобы сервер поддерживал стандартный каталог. Стандарт RDA определяет конкретные форматы передаваемых сообщений, содержащих SQL-запросы, результаты, управляющую и диагностическую информацию. В силу значительных различий в архитектурах и диалектах SQL между СУБД разных производителей, стандарт RDA находит довольно ограниченное применение.

Стандарт IBM Distributed Relational Database Architecture (DRDA) определяет другой набор протоколов и форматов для тех же целей. В отличие от RDA, DRDA допускает использование специфических особенностей каталога конкретного сервера и диалектов языка SQL. С одной стороны, это нарушает принцип независимости от СУБД, так как получается, что конечный пользователь, использующий специфические возможности, знает о конкретной СУБД, но, с другой стороны, это позволяет значительно повысить производительность. DRDA не является официально принятым стандартом и, поскольку он в значительной степени ориентирован на архитектуры и внутренние стандарты IBM, его применение вне этой фирмы также ограничено.

Достаточно часто в неоднородных распределенных базах данных взаимодействие узлов обеспечивается через специализированное программное обеспечение, называемое "шлюзами". Шлюз является специализированным в том смысле, что каждый шлюз обеспечивает взаимодействие между двумя конкретными типами СУБД. Для данной пары СУБД шлюз обеспечивает такие возможности, как:

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

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

Технологии федеративных баз данных в IBM DB2

В IBM DB2 поддержка федеративных баз данных осуществляется на двух уровнях:

DB2 Information Integrator не рассматривается нами подробно, отметим только, что вошедший в его состав DataJoiner является именно таким шлюзовым сервером приложений, о каких мы говорили несколько выше. Он обеспечивает соединение с широчайшим спектром реляционных и нереляционных источников: DB2, Informix, Oracle, Microsoft SQL Server, Sybase, Teradata, любые источники ODBC, файлы данных Documentum, документо-ориентированные базы данных Lotus, таблицы Microsoft Excel, таблично структурированные файлы, файлы XML и т.д., и т.п.

Federated Database System

FDS, встроенная в основной комплект DB2, обеспечивает создание узлов распределенной базы данных на базе СУБД DB2, Informix и Oracle и выполнение распределенных запросов (то есть, запросов, содержащих обращения к двум и более узлам) для указанных выше СУБД. Говорят, что функции базы данных "полуавтономны", в том смысле, что данные, записанные в узлах, входящих в федеративную базу данных, доступны как через FDS, так и непосредственно через сервер СУБД узла.

FDS состоит из экземпляра DB2, который является федеративной базой данных и источников данных. Синонимом федеративной базы данных в этом смысле является федеративный сервер, а источника данных - сервер (в том смысле, что источник данных является сервером, выполняющим запросы клиента - федеративного сервера). Федеративная база данных содержит каталог, идентифицирующий источники данных и их характеристики; источники данных состоят из СУБД и данных в них. Можно считать, что модель, принятая в DB2, в чем-то централизованная: узлы неравноправны, только один из них является федеративной базой данных, остальные - источники. Только из федеративной базы данных возможен доступ к любым сконфигурированным для нее источникам, но не наоборот (рис.2.1.а). Но СУБД узла, в свою очередь может быть сконфигурирована как федеративный сервер, и этот федеративный сервер может играть роль источника данных для других федеративных серверов (рис.2.1.б).

а) федеративная база данных б) система федеративных баз данных
Рис.2.1 - DB2 Federated Database System

Федеративный сервер соединяется со своими источниками данных через протокол DRDA, если источникоми является СУБД семейств DB2 или Informix, и через протоколы sqlnet и net8, если источником является СУБД Oracle.

При конфигурировании экземпляра DB2 как федеративного сервера обязательно задаются:

Необязательными параметрами конфигурирования федеративного сервера являются:

Значения конфигурационных параметров федеративного сервера могут впоследствии изменяться.

SQL-запросы, которые федеративный сервер передает на источники данных, могут выполняться в транзитном режиме или в режиме компенсации. Режим устанавливается для каждого соединения с источником. В транзитном режиме федеративный сервер передает запрос на источник "как есть". Запрос, следовательно, может использовать особенности диалекта SQL источника. В режиме компенсации SQL-запрос формулируется на языке SQL федеративного сервера. Если источник "не понимает" каких-то диалектных особенностей этого запроса, федеративный сервер переформулирует запрос в диалект сервера, "компенсируя" при этом расхождения в диалектах.

Двухфазная фиксация

При распределенных транзакциях узлы федеративной базы данных выступают в трех ролях:

В каждой транзакции существует только один клиент и один менеджер транзакции, серверов же может быть много. Узел может совмещать роли клиента и сервера и/или менеджера.

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

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

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

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

Если сбивается менеджер транзакций, он будет повторно синхронизировать транзакции при своем перезапуске. Процесс повторной синхронизации будет пытаться завершить все "сомнительные" (indoubt) транзакции; то есть, те транзакции, которые завершили первую фазу фиксации, но не завершили вторую. При этом менеджер транзакций делает следующее:

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

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

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

Консорциумом X/Open установлена модель обработки распределенных транзакций Distributed Transaction Processing (DTP). Моделью вводится понятие глобальной транзакции или транзакции XA - логической единицы работы, которая включает в себя доступ не только к данным в СУБД, но и к каким-то другим ресурсам. Глобальная транзакция, как и транзакция СУБД, обладает свойствами атомарности, целостности, параллельности, долговременности. В выполнении глобальной транзакции участвуют: приложение, менеджер транзакций и менеджеры ресурсов.

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

Менеджер транзакций назначает транзакции идентификатор, следит за ее выполнением и отвечает за фиксацию транзакции и восстановление после сбоя. Протокол двухфазной фиксации, описанный нами выше для DB2, полностью совпадает с протоколом, определенный стандартом XA-транзакций. Менеджер транзакций взаимодействует с менеджерами ресурсов - участниками транзакции через стандартные обращения.

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

DB2 полностью выполняет спецификации для менеджера ресурсов в XA-транзакциях, что дает возможность использовать СУБД в работе с такими менеджерами транзакций DTP. Хотя программные продукты - менеджеры транзакций поддерживают стандартный интерфейс для XA-транзакций, каждый из таких продуктов может иметь дополнительные специфические особенности взаимодействия с менеджерами ресурсов. DB2 поддерживает специфику таких популярных менеджеров транзакций, как IBM TXSeries CICS, IBM TXSeries Encina, BEA Tuxedo, Microsoft Transaction Server.

Репликация

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

Логическими составляющими процесса репликации являются: управляющие таблицы, логические серверы, механизм "захвата-применения" и интерфейс репликации.

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

В процессе репликации участвуют следующие логические серверы. Исходный сервер - СУБД, на которой находятся таблицы (первичная копия), изменения которых должны распространяться. Целевой сервер - СУБД, содержащая таблицы с вторичными копиями данных (изменения, выполненные на одном исходном сервере, могут распространяться на много целевых серверов). Управляющий сервер - СУБД, содержащая управляющие таблицы для программы Apply (см. ниже).

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

"Применением" называется выполнение изменений на вторичной копии данных, оно выполняется программой Apply. Программа Apply читает захваченные данные, и записывает их в целевые таблицы. Обычно на каждом целевом сервере работает один или несколько экземпляров программы Apply. Если захват выполнялся программой Capture, то программа Apply читает значения данных непосредственно из источников, если же захват выполнялся триггерами, программа обращается к таблицам-заменителям. Программа Apply использует также и другие управляющие таблицы, например, для того, чтобы применять только зафиксированные изменения, отслеживать последние выполненные изменения и т.д.

В DB2 предусмотрены два интерфейсных средства администрирования репликации: DB2 Control Center и DataJoiner Replication Administration.

DB2 Control Center используется только для репликации между серверами DB2 и дает возможность:

DataJoiner Replication Administration используется репликации между любыми серверами и, кроме перечисленного для Control Center, дает возможность:

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

а). распределение данных б). консолидация данных
в). изменения, где угодно г). эпизодическое соединение
Рис.2.2 - Типовые сценарии репликации

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

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

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

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

Контрольные вопросы

  1. Вспомните ту базу данных, которую Вы проектировали в своем курсовом или бакалаврском проекте. При каких изменениях в условиях ее эксплуатации могла бы возникнуть необходимость сделать эту базу данных распределенной?
  2. Для Вашей базы данных приведите примеры возможной горизонтальной и вертикальной фрагментации.
  3. Для Вашей базы данных при условии ее фрагментации выбранным Вами способом приведите примеры запросов, которые будут выполняться как распределенные.
  4. В чем состоит суть схемы первичной копии при репликации? Почему при использовании этой схемы осуществление синхронной репликации затруднительно?
  5. Опишите сценарий поиска объекта в федеративной базе данных System R*.
  6. Сравните каталоги федеративной базы данных и именование объектов в System R* и в IBM DB2 Federated Database System. В чем их сходство и различие?
  7. В чем состоит двухфазный протокол фиксации распределенных транзакций? Каким образом можно уменьшить количество сообщений, передаваемых в обе стороны при двухфазной фиксации?
  8. Каковы функции шлюзов при взаимодействии узлов неоднородных федеративных баз данных? В чем преимущества и недостатки шлюзов по сравнению с применением стандартных протоколов взаимодействия?
  9. Сопоставьте схему фиксации распределенных транзакций в IBM DB2 с "классической" схемой двухфазной фиксации. Укажите соответствия и особенности реализации.
  10. Какие средства репликации имеются в IBM DB2? Какие ограничения накладываются на возможности репликации?

НазадОглавлениеВперед
КаталогИндекс раздела