Прозрачность транзакций.

Все транзакции в Oracle завершаются предложением COMMIT или ROLLBACK. Если она является распределенной, то COMMIT автоматически запускает механизм двухфазного подтверждения. Он гарантирует, что все узлы, участвующие в распределенной транзакции, будут гарантированно подтверждены либо “откатаны” даже при сбое сети.

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

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

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

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

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

Д

Division1

Division1

Division1

SALES

HQ

SALES

SALES

SALES

SALES

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

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

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

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

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

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

Hq.division1.acme_tools.com

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

human_resource.emp@hq.us.americas.acme_auto.com

human_resource.emp@hq.division1.acme_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);

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