Реплици laHHbie спраеочч1 данные

Локапьн шь

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

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

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

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

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

iiii

pt рованные справочные данные

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

i !сж&льная а

Рис 12 I Типичная сетевая топология

Эволюция средств поддержки распределения данных Oracle

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

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-запрос выберет необходимые данные из таблиц ЕМР и DEFT так, будто эти таблицы находятся в базе данных, к которой подключен пользователь. Расположение этих таблиц (т.е. базы данных, в которой они находятся) прозрачно для автора запроса, хотя оно должно быть

известно администратору, создавшему элементы словаря данных. Кроме того, необходимые элементы были созданы независимо от целевой базы данных и таблиц.

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

AND d.deptno = e.deptno;

Каналы связи базы данных

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

SELECT ename FROM emp@elsewhere WHERE empno = 7319;

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

SELECT c.cust name - выбрать покупателя, название и количество

, p.prod name - товара для случая, когда куплено и оплачено , SUM(l.qty) - более 100 единиц

FROM custs@hq с , ordrs@sales о , lines@sales 1 , prods@mktg р WHERE o.cust id = c.cust id AND l.ord id = o.ord id AND p.prod id = l.prod id AND l.qty id >= 100 AND o.status = PAID;

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

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

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

Распределенные соединения

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

Примечание

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

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

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

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