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

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

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

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

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

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

Несет ли заведующий складом персональную ответственность за точность этих данных?

Теряли ли когда-нибудь складские работники файлы на своих ПК?

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

Статус стороннего консультанта часто помогает реализовать качественно спроектированное приложения - в этом случае гораздо лепге задавать такие острые вопросы!

Удаленное обновление

Неспособность Oracle версий 5 и 6 поддерживать удаленное обновление, конечно, можно очень просто преодолеть при помощи языков третьего поколения путем создания явных соединений с несколькими экземплярами базы данных. Установив эти соединения, программа может обновлять данные где угодно. Однако она также должна выдать явную команду фиксации в каждый из экземпляров, в который она выдала DML-команды. Этот подход можно использовать и в текущих версиях Oracle, однако разработчики редко пользовались им по двум веским причинам: ни на каких курсах (по крайней мере, на тех, о которых нам известно) множественные соединения не преподают, и никакие средства УРП эти соединения непосредственно не поддерживают. Как результат, их можно получить только при помощи языков третьего поколения.* Необходимые операции показаны ниже (в них используются поддерживаемые Рго*С конструкции SQL).

EXEC SQL CONNECT :user and passwd AT :local db; EXEC SQL CONNECT :user and passwd AT ;remote db;

EXEC SQL DELETE FROM dept AT :remote db WHERE deptno = :dept; EXEC SQL DELETE FROM emp AT :local db WHERE deptno = rdept;

EXEC SQL AT :remotedb COMMIT WORK; EXEC SQL AT ;local db COMMIT WORK;

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

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

Действительно, средства УРП не поддерживают множественные соединения, однако отметим, что команда COPY в SQL*Plus реализуется именно с помощью множественных соединений.

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

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

так:

EXEC SQL CONNECT :user and passwd;

EXEC SQL DELETE FROM dept@remote db WHERE deptno = :dept; EXEC SQL DELETE FROM emp WHERE deptno = :dept;

EXEC SQL COMMIT WORK;

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

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

Если я попрошу вас выполнить фиксацию, вы сможете это сделать?

Это - первая фаза.

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

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

Средства распределения данных Oracle?

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

удаленный DML (7.0);