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

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

Удаленные фанзакции часто поддерживаются специальными шлюзовыми профаммами, связывающими СУБД разных типов. В частности, большинство поставщиков корпоративных СУБД (Sybase, Oracle, Informix) предоставляют шлюзы к DB2. Некоторые шлюзовые профаммы не только обеспечивают выполнение удаленных транзакций, но и дают пользователю возможность объединять в одном запросе таблицы из локальной базы данных с таблицами из удаленной базы данных, управляемой СУБД другого типа. Однако эти профаммы не обеспечивают (и не могут обеспечить) выполнение фанзакций, необходимых для реализации более высоких уровней доступа к распределенным данным. Шлюзовая профамма может поддерживать по отдельности целостность локальной и удаленной баз данных, но не может исключить ситуацию, когда в одной базе данных фанзакция будет завершена, а в другой - отменена.

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

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

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

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

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

Локальная система

Удаленная система

Рис. 22.11. Доступ к распределенные данным: распределенные транзакции

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

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

Локальная система

Удаленная система

Удаленная система

СУБД

Рис 22.12, Доступ к ррпределец тным: распрделенныё*запро<

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

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

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

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

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