которая либо поддерживает Distributed Database Option, либо способна работать с этой опцией. Это очень важно, поскольку очень немногие разработчики умеют хорошо обращаться с несколькими одновременно открытыми соединениями с базой данных. Кроме того, насколько мы знаем, только немногие широко используемые средства ускоренной разработки приложений (УРП) обеспечивают полную поддержку открытия одновременно нескольких соединений с базой данных. Как правило, множественные соединения поддерживаются только из языков третьего поколения (и, как ни странно, с помощью редко используемой команды СОРУ из SQL*Plus).

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

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

Самый крайний случай, с которым мы встречались, - когда приложение Microsoft Access соединяло локальную таблицу Access с таблицей Oracle на удаленном сервере. Оказалось, что вся таблица Oracle пересылалась на клиент, где выполнялось соединение, несмотря на то, что SQL-предложение содержало условие, по которому сервер возвращал всего одну строку.

Примечание

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

Появление базы данных второго уровня

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

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

Регтицированные справочные данные

Локальный сервер А

Рв jnupoeaHHbie справочные данные

Локальный Л сервер В

Центральный сервер X

Центральный сервер Y

Реппицированные справочные данные

Локальный сервер С

Рис 11.5. Использование локальных серверов БД для справочных данных в сети

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

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

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

К сведению

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

Сокращение сетевого трафика с помощью представлений

Давайте рассмотрим проблему трафика сообщений. Допустим, у нас есть приложение, отображающее сетку (иногда называемую многострочным блоком) заказов. В таблице ORDERS есть столбец CUS ID, который содержит уникальный идентификатор покупателя, разместивщего заказ. Нашему приложению нужно отобразить имя покупателя, которое должно быть выбрано из таблицы CUSTOMERS. Предположим, что это приложение предстоит разрабатывать в Oracle Forms 4.0/4.5 и его окно выглядит приблизительно так, как на рис. 11.6.

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