Oracle в архитектуре клиент-сервер
Распределенные БД в Oracle и Oracle в распределенных БД
Администрирование распределенных систем
Что дальше?

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

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

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

Oracle в архитектуре клиент-сервер

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

Особенности реализации

Организация связи

Классическая схема реализации режима клиент-сервер предполагает установление и поддержку сессии связи между клиентом и сервером. Поддержку такого режима взаимодействия в Oracle осуществляет программный продукт SQL*Net, представляющий собой в сущности стек протокола прикладного уровня, имеющий интерфейсы практически со всеми широко известными транспортными протоколами. Если сеть является гетерогенной, т. е. отдельные ее сегменты используют разные транспортные протоколы, SQL*Net тем не менее обеспечивает прозрачное взаимодействие клиента и сервера с помощью компонента, называемого Multi-protocol Interchange.

За свою историю SQL*Net прошел уже несколько стадий развития, превратившись по существу в средство обеспечения взаимодействия распределенных программных компонентов. Среди функциональных возможностей SQL*Net стоит отметить защиту передаваемой информации (хотя автор и клялся не обсуждать подробно тему защиты в данной статье). Собственно говоря, никаких иных средств защиты данных при передаче, кроме шифрования и контрольного суммирования, до сих пор не придумано. Так вот, SQL*Net всегда шифрует наиболее критичную информацию - пароли пользователей - при их передаче по сети. Поскольку ключ для шифрования генерируется случайным образом в каждой новой сессии, осуществить расшифровку пароля при его перехвате практически невозможно. Если же в системе установлена специальная опция (Advanced Networking Option), появляется возможность шифрования всей информации по одному из поддерживаемых алгоритмов (сейчас это DES и RSA с 48-разрядными ключами).

Как уже говорилось, SQL*Net давно уже представляет собой средство межпрограммного взаимодействия, выходящее по своим возможностям за рамки обеспечения связи клиента с сервером БД на уровне SQL-запросов. Неслучайно последние версии протокола SQL*Net (начиная с версии 2.3) стали открытыми, т. е. пользователи Oracle получили возможность использовать его для связи любых программ, функционирующих в гетерогенной сети, или - в случае необходимости - "внедряться" в стандартный протокол передачи данных.

Конфигурации сервера

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

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

Альтернативой выделенному серверу является сервер многопоточный. Строго говоря, многопоточным называется сервер, способный обслуживать более одной клиентской сессии, разделяя свои ресурсы между этими сессиями. Это теоретически, а практически реализация многопоточных серверов может иметь варианты - так у Oracle она различается в разных ОС. В целом схема, применяемая Oracle, такова. Жесткой привязки каких-либо сессий к многопоточным серверным процессам не производится. Вместо этого клиент, взаимодействующий с сервером по многопоточному варианту (а он по-прежнему может потребовать для себя и выделенный процесс), устанавливает связь с одним из процессов-диспетчеров, задачей которого является помещать все поступающие запросы в единую для всех сессий очередь. Любой из многопоточных серверных процессов "берет на обслуживание" первый запрос из этой очереди, а ответ помещает в очередь ответов того диспетчера, который поддерживает связь с данным клиентом. Описанный метод "обезличенного обслуживания" обеспечивает в режиме OLTP максимальную загрузку всех серверных процессов, что дает особенно заметный эффект при работе на компьютерах с параллельной архитектурой.

Как быть с толстыми клиентами?

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

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

Одной из проблем использования хранимых на сервере процедур при разработке приложений является то, что язык, применяемый при написании приложений на клиентском компьютере, и язык хранимых процедур часто не совпадают. Это приводит как к дополнительным трудностям для программистов, так и к невозможности простой "миграции" процедур между клиентом и сервером. Oracle - по крайней мере в случае разработки при помощи Developer/2000 - данную проблему решает, ибо в качестве базового языка при разработке выступает тот же PL/SQL, так что довольно часто перенос процедуры с клиентского компьютера на сервер может быть достигнут простой "буксировкой" соответствующей иконки с помощью мыши.

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

Радикальное средство от ожирения

Собственно говоря, механизм для борьбы с ожирением клиентов был придуман уже давно, но роль и значение его для коммерческих информационных систем по существу не оценены до сих пор. По-настоящему всерьез три магические буквы WWW, придуманные в свое время в Европейском Центре Ядерных Исследований (CERN) в Женеве, массовое сознание информационного мира стало рассматривать уже в сочетании с не менее магическими словами Java и Intranet. Влияние этих трех магических слов на информационные системы может быть (и почти наверняка будет) не менее революционным, чем распространение в 80-х годах архитектуры клиент-сервер, как таковой.

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

Чтобы получить представление о возможностях Oracle Web Server, рассмотрим кратко его архитектуру. Запрос пользователя (от любого WWW-навигатора) принимается процессом, называемым Web listener (это в сущности HTTP-сервер в стандартном понимании Internet), и передается другому процессу, называемому Web Request Broker (WRB).

Последний включает в себя диспетчер, способный передать запрос одному из так называемых картриджей. Такое название выбрано не случайно, ибо WRB можно наглядно представить себе в виде устройства, имеющего несколько разъемов для вставки картриджей - либо входящих в стандартную поставку, либо дополнительных или даже разработанных самим пользователем. Среди стандартных картриджей поставляются: PL/SQL-агент, интерпретатор Java, интерпретатор LiveHTML. Как видно, Oracle Web Server - это не просто интерфейс между HTTP и сервером БД, а средство, предоставляющее мощный интерфейс прикладного программиста (API) для создания Web-приложений.

Что же касается PL/SQL-агента, то он обеспечивает процедурный интерфейс для взаимодействия с БД и позволяет представлять пользователю динамически сформированные (управляемые данными) Web-страницы. Поскольку программирование на уровне процедурных вызовов - не самый эффективный способ создания Web-приложений, Oracle активно развивает средства их разработки. В настоящее время доступны Web-генератор в Designer/2000 (позволяющий, кстати, получать Web-версии уже имеющихся приложений клиент-сервер), Web Developer. Новые разработки изначально включают в себя Web-интерфейсы. Наконец, существуют средства для преобразования уже разработанных HTML-страниц в приложения для PL/SQL-агента (Web Alchemy).

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

Распределенные БД в Oracle и Oracle в распределенных БД

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

Концепция построения распределенных БД в Oracle основана на децентрализованной их организации. Серверы взаимодействуют друг с другом с помощью уже знакомого нам протокола SQL*Net. Ссылки друг на друга - так называемые каналы связи БД (database links) - серверы хранят в качестве объектов БД. В свою очередь полное имя объекта может включать в себя канал связи (т. е. вместо самого объекта в локальной базе данных может храниться как бы ссылка на него): это, безусловно, требует обеспечения уникальности имен серверов ("сервисов" в терминологии Oracle) в сети, что достигается с помощью иерархической организации доменов, подобной существующей в Internet.

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

Синхронная связь без тиражирования данных

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

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

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

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

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

Тиражирование данных

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

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

Отличие промышленных систем от игрушечных

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

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

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

Допустимо ли временное рассогласование тиражированных данных?

Если да, то в каких временных пределах должна осуществляться процедура их согласования, и каким образом она должна инициироваться?

Не могут ли привести сбои каких-либо элементов системы к безвозвратной потере целостности распределенной БД, всегда ли система будет корректно (и предсказуемо) вести себя в случае тех или иных сбоев?

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

Варианты тиражирования данных в Oracle

Самым простым (и исторически реализованным первым) вариантом тиражирования в Oracle является механизм так называемых неизменяемых снимков (read-only snapshots). Он подразумевает создание удаленной копии таблицы (или ее подмножества), которая доступна только на чтение и обновляется по заданному сценарию и расписанию. Точнее, снимок определяется так же, как представление - view, т. е. он может быть основан и на нескольких таблицах.

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

Последним "атомарным" вариантом тиражирования в Oracle (ибо возможны также любые комбинации) является тиражирование с множественными хозяевами (multi-master site replication). При данном варианте полностью тиражируются целые наборы объектов БД (в них помимо таблиц могут входить индексы, представления, триггеры, пакеты хранимых процедур, синонимы, генераторы последовательностей). При этом тиражируются все определения и атрибуты объектов, так что в результате все хозяева их копий становятся равноправными. Любые изменения тиражированных данных непосредственно передаются ("распространяются") всем хозяевам (в отличие от варианта изменяемых снимков, где несколько снимков одного объекта могут обменяться изменениями только через посредство хозяина этого объекта). Такое решение, в частности, приводит к тому, что в системе не будет ни одного сервера, единичный выход из строя которого означал бы невозможность продолжения работы с набором тиражированных объектов.

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

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

Без дисциплины работать трудно

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

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

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

Другой важный пример использования синхронного тиражирования - поддержка "зеркальной" БД на резервном сервере, причем оба сервера (основной и резервный) в этом случае могут работать параллельно.

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

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

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

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

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

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

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

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

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

Поддержка резервной копии БД

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

Свой среди чужих

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

Если это реляционные СУБД (MS SQL Server, Informix, Sybase, DB2, CA Ingres), можно использовать так называемые прозрачные шлюзы для объединения их с Oracle. Для пользователя такого шлюза полностью имитируется функциональная среда сервера Oracle при доступе к данным, хранящимся в "чужих" СУБД.

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

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

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

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

Администрирование распределенных систем

Тема администрирования по-хорошему достойна отдельной статьи. Здесь же мы немного поговорим лишь о тех средствах, которые Oracle предлагает в помощь администратору распределенной информационной системы.

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

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

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

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

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

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

Что дальше?

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

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

Виталий Витальевич Сиколенко, Oracle СНГ, тел.: (095) 258-41-80, e-mail: vsikolen@ru.oracle.com