Прозрачность в РБД. Прозрачность местоположения.

Прозрачность местоположения можно обеспечить тремя способами:

1) с помощью видов (обзоров)

CREATE VIEW company AS SELECT * from Scott.Emp@…;

где company – имя вида

После выполнения этой команды можно выполнить: SELECT * from company;

2) с помощью синонимов (скрывает идентификатор объекта)

CREATE PUBLIC SYNONIM emp for Scott.Emp@…;

где PUBLIC означает, что синоним Emp будет доступен в специальной схеме.

3) с помощью встроенных процедур.

 

Ограничения:

§ внутри одного предложения SQL все адресуемые столбцы Long и LongRaw, последовательности, обновляемые таблицы и блокируемые таблицы должны быть расположены на одном и том же узле;

§ Oracle не допускает выполнение удаленных предложений Data Definition Language:

- CREATE

- ALTER

- DROP

 

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

 

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

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

 

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

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 – это экземпляр БД, а не домен)

 

[e-mail]_auto.com

[e-mail]_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);

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

 

Разрешение имен в РБД

 

При разрешении ссылок на имена глобальных объектов выполняются следующие действия:

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

2. Поиск указанного объекта в удаленной БД (сначала происходит поиск личных связей БД в схеме пользователя, выдавшего предложение SQL, а потом – сетевые связи БД при наличии службы сетевого домена; если Oracle не находит связей, то выводится сообщение об ошибке).

 

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

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

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

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

Примеры.

CREATE VIEW emp1 AS

SELECT ename FROM scott.emp@hq;

CREATE SYNONYM emp1 FOR scott.emp@hq;

 

 

Снимки.

 

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

 

 

 

Схема дублирования таблиц посредством снимков.

 

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

Простые и сложные снимки. Каждая строка в простом снимке базируется на одной строке в единственной удаленной таблице. Следовательно, определяющий запрос простого снимка не содержит фраз GROUP BY или CONNECT BY, подзапросов, соединений или операторов множеств. В противном случае снимок называется сложным.

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

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

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

 

Двухфазный COMMIT.

 

По определению все предложения SQL либо принимаются, либо отменяются. Для этого и применяется двухфазный COMMIT.

Фазы двухфазного COMMIT:

1. Фаза подготовки. В этой фазе глобальный координатор (инициализирующий узел) просит «участников» подготовится к завершению транзакции.

2. Фаза подтверждения. При положительном ответе всех участников координатор просит подтвердить транзакцию; если кто-то не готов, то координатор просит остальных выполнить откат транзакции.

 

Фаза подготовки.

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

При получении узлом команды подготовится можно ответить тремя способами:

1) «готов» - данные на узле были модифицированы предложением в распределенной транзакции, и узел подготовился к завершению;

2) «только чтение» данные на узле не модифицировались, а лишь читались; в этом случае нет необходимости в завершении;

3) «снять завершение транзакции» узел не может успешно подготовится.

 

Операции на фазе подготовки:

· узел просит подготовиться своих потомков

· узел распределяет все ресурсы, необходимые для завершения транзакции

· узел сбрасывает записи повторения, соответствующие изменениям, сделанным этой транзакцией, в свой локальный журнал повторений

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

· узел должен ответить узлу, от которого получил транзакцию

 

Узел, к которому обращаются за подтверждением, называется сомнительным.

Если узел не может подготовиться к завершению транзакции, то он выполняет следующие действия:

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

· отвечает узел сообщением «снять»

 

Эти действия стают поводом для отката транзакции в целом.

Невозможность подготовки возникает из-за блокировок пользователей и нарушений целостности системы.

Итак, подведем итог: после запуска на выполнение команды COMMIT в командном окне локальная БД просит все узлы, участвующие в транзакции, подготовиться к предстоящему завершению; все опрошенные узлы отвечают на вопрос о подготовке и, если какой-нибудь из них отвечает предложением «снять», то вся транзакция глобально откатывается, а в случае подготовки всех узлов начинается следующая фаза подтверждения.

 

Фаза подтверждения

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

2) Oracle на каждом узле подтверждает локальную порцию распределенной транзакции, освобождающую блокировки;

3) после завершения фазы подтверждения данные являются согласованными.

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

· клиента (не путать с клиентом-приложением)

· сервера БД

· глобального координатора

· локального координатора

· стороны точки подтверждения

Роль, которую играет узел, определяется факторами:

- откуда исходит транзакция (кто инициатор)

- самой точки подтверждения данного узла, которая определяется параметром инициализации при запуске инстанции

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

- является ли данный узел «только читаемым» для данной транзакции

Клиенты – это серверы БД, выступающие как клиентский узел и запрашивающие информацию у другого узла в распределенной транзакции.

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

Глобальный координатор – это узел, из которого проистекает распределенная транзакция, т.е. это узел, с которым непосредственно связано приложение. Это родитель – корень дерева сессии.

Глобальный координатор взаимодействует со всеми узлами (непосредственно адресуемыми), отличными от стороны точки подтверждения, чтобы иметь возможность повторить транзакцию. Если все узлы подготовились, то глобальный координатор будет просить подтверждения от точки подтверждения.

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

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

Характерные особенности стороны точки подтверждения:

- она никогда не входит в фазу подготовки во время двухфазного подтверждения

- результат распределенной транзакции на стороне точки подтверждения определяет результат транзакции на каждом узле дерева сессии

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