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

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

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

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

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

CREATE PUBLIC DATABASE LINK elsewhere
   CONNECT TO system IDENTIFIED BY manager
   USING 'T:hp34:appdev';

CREATE PUBLIC SYNONYM dept FOR scott.dept@elsewhere;
CREATE PUBLIC SYNONYM emp FOR scott.emp@elsewhere;

Что это означает? При наличии этих элементов в словаре данных приведенный ниже SQL-запрос выберет необходимые данные из таблиц EMP и DEPT так, будто эти таблицы находятся в базе данных, к которой подключен пользователь. Расположение этих таблиц (т.е. базы данных, в которой они находятся) прозрачно для автора запроса, хотя оно должно быть известно администратору, создавшему элементы словаря данных. Кроме того, необходимые элементы были созданы независимо от целевой базы данных и таблиц.

SELECT d.dname
     , e.ename
  FROM emp  e
     , dept d
 WHERE d.deptno = 10
   AND d.deptno = e.deptno;

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

SELECT ename FROM emp@elsewhere WHERE empno = 7319;

SELECT c.cust_name — выбрать покупателя, название и количество
     , р.prod_name — товара для случая, когда куплено и оплачено
     , SUM(l.qty)  - более 100 единиц
  FROM custs@hq    с
     , ordrs@sales о
     , lines@sales l
     , prods@mktg  p
 WHERE o.cust_id = c.cust_id
   AND l.ord_id = о.ord_id
   AND p.prod_id = l.prod_id
   AND l.qty_id >= 100
   AND o.status = 'PAID'

ALTER SESSION CLOSE DATABASE LINK hq;
ALTER SESSION CLOSE DATABASE LINK sales;
ALTER SESSION CLOSE DATABASE LINK mktg;

Мы не рекомендуем использовать какие-либо распределенные соединения без предварительного тестирования их с реальными объемами данных. Если производительность неудовлетворительна, можно рассмотреть следующие варианты:

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

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

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

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

Используя двухфазную фиксацию, мы можем переписать наш пример так;

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

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

Ниже мы рассмотрим каждое из этих средств. Для всех них, за исключением четвертого в списке, требуется покупка лицензии и инсталляция средства Distributed Option от Oracle, а для последних трех средств также необходима инсталляция Data Replication Support. И Distributed Option, и Data Replication Support обычно поставляются за дополнительную плату. Информацию о существующих в данный момент правилах Oracle относительно цен и комплектования этих компонентов можно получить у своего администратора, отвечающего за учет.

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

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

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

Рис. 12.2. Распределение справочных данных

Пример: данные о служащих

Теперь рассмотрим другой случай, когда нам нужно иметь данные о служащих, при запросах к которым должны возвращаться только актуальные значения. Эти данные используются только при расчете месячной заработной платы и руководителями подразделений в нерегламентированных запросах. Руководители подразделений могут получать доступ к записям только о своих подчиненных, а изменять эти данные могут только бухгалтеры подразделений. Сущности, на основе которых строятся такие данные, имеют следующие свойства:

• среднюю готовность;

• максимальную достоверность;

• минимальную видимость (потому что доступ ограничен конкретным подразделением);

• среднюю доступность;

• низкую мутируемость;

• низкую изменчивость.

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

Рис. 12.3. Горизонтально секционированные данные

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

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

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

Рис. 12.4. Использование обновляемых снимков для распространения итоговых данных

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

Пример: обновление через глобальную сеть

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

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

Обновлять запись о клиенте после того, как она выбрана, труднее, потому что программа (или, по крайней мере, PL/SQL, неявно или явно вызванный ею) должна направить обновление на соответствующий сервер — вот почему в представлении присутствуют данные о местоположении.

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

Однако все эти проблемы меркнут перед тем, какое влияние оказывает представление на производительность и готовность. Даже если используется Parallel Query Option (см. главу 14), запросы параллельно не выполняются. Каждый запрос производится только после того, как разрешен предыдущий, и вы можете получить сообщение об ошибке, если какая-либо база данных к запросу не готова.

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

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

Если в отделе 26, зарегистрированном в чикагской версии таблицы, служащих нет, то, когда координатор спросит у чикагского экземпляра, вносил ли он изменения, экземпляр ответит отрицательно. В результате этого, если транзакция вносит изменения только в один (даже удаленный) экземпляр базы данных, двухфазная фиксация не требуется. "Уловка-22" состоит в том, что в Oracle необходимо иметь компонент Distributed Option (включающий двухфазную фиксацию), чтобы определить, что двухфазная фиксация не требуется. Другими словами, если двухфазная фиксация не инсталлирована, то нельзя обновить данные через канал связи БД даже в тех случаях, когда двухфазная фиксация не требуется.

Вторая проблема состоит в том, что в промежутке времени между подготовкой и фиксацией данные считаются сомнительными. Когда база данных, в которой выполнено обновление, получает команду подготовки, то до тех пор, пока координатор не просигнализирует о второй фазе фиксацией или откатом, никак нельзя определить, зафиксированы данные или нет. По этой причине Oracle с помощью блокировки на уровне блока предотвращает доступ к этим данным, поскольку не может определить, следует ли применять согласованность по чтению. Обычно в среде локальной сети эти блокировки существуют всего несколько миллисекунд, а в глобальной сети — несколько сот миллисекунд. Тем не менее, если какая-то проблема (например, сбой в сети) не дает завершить вторую фазу, то сомнительные данные остаются недоступными до тех пор, пока проблема не будет решена. Решить ее можно либо с помощью встроенного в Oracle механизма восстановления, либо путем вмешательства администратора БД, который должен выдать SQL-предложение COMMIT FORCE или ROLLBACK FORCE.

Экземпляр, выполняющий традиционную фиксацию, называется точкой фиксации. Он не обязан переводить блоки в категорию сомнительных. Естественно, чем важнее база данных, тем меньше должен быть риск появления в ней сомнительных данных. Поэтому в файле init.ora Oracle предусмотрен специальный параметр — COMMIT_POINT_STRENGTH, и в любой распределенной транзакции точкой фиксации будет экземпляр с наибольшим значением этого параметра. Однако мы рекомендуем тщательно проверить документацию на предмет важного исключения из этого правила — когда сами удаленные операции включают удаленные операции.

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

Мы уже несколько раз использовали термин "удаленные DML-операции". Под DML-операциями (Data Manipulation Language — язык манипулирования данными) мы подразумеваем только те операции, которые задаются следующими SQL-предложениями:

Имеющиеся в Oracle средства поддержки распределенных баз данных не обеспечивают непосредственную поддержку удаленных DCL-операций (Data Control Language — язык управления данными), таких как GRANT и REVOKE, и удаленных DDL-операций (Data Definition Language — язык определения данных), например CREATE, ALTER, DROP. Однако средства поддержки симметричной репликации включают PL/SQL-пакет под названием DMBS_REPCAT, который способен выполнять удаленные DDL-операции, необходимые для настройки схемы распределенной репликации.

Однако несмотря на это, если прикладная логика потребует, чтобы процесс мог создавать таблицы, выдавать разрешения, усекать таблицы — короче, выполнять все, помимо запросов и пяти вышеупомянутых DML-операций, вы не сможете выполнить соответствующие операции на удаленном узле. Мы, конечно, можем ответить вопросом: а почему вы думаете, что вам понадобится выполнять такие операторы в рамках обычных транзакций? Мы бы напомнили также, что в Oracle DDL-операции имеют две неявные фиксации:

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

Учтите, что и вызывающие, и вызываемые базы данных должны поддерживать Distributed Option, следовательно, функция alloc сама может производить удаленные запросы, DML-операции и вызовы процедур. Отметим также, что этот процесс может быть многоуровневым, что серьезно влияет как на время реакции, так и на готовность.

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

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

Рис. 12.5. Снимок, который является и вертикальным, и горизонтальным подмножеством таблицы

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

Предупреждение

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

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

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

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

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

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

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

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

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

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

Приоритет узлов также таит в себе опасность, если в сети больше двух узлов. Рассмотрим пример на рис. 12.6. При определенном стечении обстоятельств синхронность узлов нарушается, и узел С не согласуется с узлами А и В. Поскольку А определен как приоритетный узел, это предполагает, что данные узла С неверны.

Рис. 12.6. Потенциальная проблема при разрешении конфликта по приоритету узлов

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

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

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

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

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

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

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

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

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

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

Рис. 12.7. Простая топология сети

Рис. 12.8. Простая модель данных

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

Этот сценарий также относительно прост, потому что обновление удаленных данных осуществляется отдельными транзакциями, в которых задействуется мало узлов. Используя канал связи БД, созданный для сценария 1, вице-президент может для удаленного сопровождения подключиться к удаленной системе, указав в конце строки соединения @hong_kong или @london.

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

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

Рис. 12.9. Модель данных для более сложных распределенных сценариев

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

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

Таблицы CUSTOMERS и TRADES могут оставаться в той же форме, что и в предыдущем примере, но поскольку цены товаров всегда должны быть полностью синхронизированы, у нас есть только один выбор: использовать для них синхронную симметричную репликацию. Однако если часть сети откажет, мы не сможем обновить цены ни в одной системе. Чтобы ослабить влияние этого фактора, придется либо покупать дополнительное оборудование, либо создать свою собственную форму синхронной симметричной репликации, которая при определенных управляемых условиях способна выдерживать системные отказы и откладывать синхронизацию. Еще один вариант — иметь всего одну копию данных, а деньги вложить в быстродействующую сеть!

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

В этом разделе описывается еще несколько факторов, влияющих на проектирование распределенных баз данных.

Столбцы, определенные как LONG, вызывают при проектировании распределенных баз данных ряд проблем. Таблицы, которые содержат длинные столбцы, не могут реплицироваться и участвовать в двухфазной фиксации. Снимки также не могут включать столбцы типа LONG. Если разобраться, то это имеет большой смысл: разве мы хотим, чтобы сеть была забита огромными растровыми изображениями или графическими объектами, которые реплицируются по узлам? Однако следует иметь в виду, что это ограничение может повлиять на структуру таблиц. Например, вы можете хранить BLOB-данные на внешнем сервере и разработать свою программу для "вытягивания" этих данных по требованию.

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

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

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