Прозрачность дублирования

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

q такое средство, как снимки таблиц, обеспечивают асинхронное дублирование, т.е. изменения в обновляемой таблице дублируются в снимки ReadOnly через определенные интервалы времени

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

Пример архитектуры.

SALES

SALES

SALES

SALES

HQ

SALES

Division1

Division1

Division1

Для обращения к удаленной БД необходимо использовать глобальные имена объектов. Глобальные имена объектов состоят из двух компонентов:

· имени БД длиной до 8 символов

· сетевого домена, в котором находится эта БД (эти имена удовлетворяют стандартным соглашениям Internet)

Уровни разделяются точками.

На рисунке изображена некоторая структура распределенной БД. Домены Internet без рамок, а БД в рамках, двойной прямоугольник – это схема РБД, например, HUMAN_RESOURCE.EMP.

Примеры глобальных имен:

Hq.division1.acme_tools.com

(отличие от интернетовского имени в том, что hq – это экземпляр БД, а не домен)

[email protected]_auto.com

[email protected]_tools.com

(это все разные таблицы)

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

Существует три варианта связи:

· личная связь БД (пользователь сам создает связь в БД от имени конкретного пользователя; она может использоваться только тогда, когда владелец этой связи указывает имя глобального объекта в предложениях SQL или в своих собственных видах и процедурах)

· общая связь БД (создается для специальной группы пользователей под именем PUBLIC; эту связь может использовать любой пользователь, который указывает глобальное имя объекта)

· сетевая связь БД (создается службой сетевого домена)

Преимущества использования связей:

1) позволяет обеспечить более высокую защиту по сравнению с другими;

2) общая связь упрощает доступ к БД.

Для создания связи используются команды:

CREATE DATABASE LINK

CREATE PUBLIC DATABASE LINK (создание общей связи)

В начале работы вы себя локально идентифицируете, а при работе с удаленными объектами и глобально, т.е. создаете сеанс, например:

CREATE [PUBLIC] DATABASE LINK sales.division3.acme.com

CONNECT TO guest

IDENTIFIED BY password

USING ‘dbstring’;

Создаем связь к sales…, при этом на удаленной БД вы будете регистрироваться под именем guest и паролем password. При отсутствии CONNECT для создания сессии используется имя и пароль локальной сессии, USING определяет способ соединения с БД. Dbstring – определяет псевдоним к БД для пользователя (псевдоним создается в файле config). В нем задается имя, протокол подключения к удаленной БД и способ поиска сервера, который зависит от протокола:

- IP-протокол – адрес сервера задается интернетовским адресом, например, 194.44.180.81

- SPX-протокол – надо указывать имя процесса прослушивания в случае интомирования сервера: К108_LSNR.

Централизованные учетные имена предоставляют основное преимущество: привилегии и роли требуется назначить один раз централизованному пользователю.

Однако, недостатки всплывают в вопросах защиты:

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

2) общая связь БД, использующая такое имя, позволяет обращаться к удаленной БД любому пользователю.

Преимущества использования централизованных учетных имен:

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

· меньше риска вскрытия защиты, потому что учетное имя и пароль не задаются в определении личной связи БД (задание связи без опции CONNECT);

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