Прямые и косвенные соединения

Распределенная база данных

 

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

Логическая единица взаимодействия БД – это транзакция (после нее происходит фиксация информации в БД). Транзакция – это или модификация, или удаление, или добавление информации в БД.

 

Пример транзакции

 

INSERT into EMP@Sales …

DELETE from DEPT…

SELECT from EMP@Sales…

COMMIT

 

Commit – фиксирует информацию в БД, после ее выполнения нельзя совершать откат сделанных действий.

 

Пример РБД

 

Сервер БД – это программное обеспечение, управляющее БД.

Клиент – это приложение, которое запрашивает информацию от сервера.

Каждый ПК (персональный компьютер) называется узлом. Узел в системе РБД может быть как клиентом, так и сервером (либо чем-то другим).

Сервер БД1 является сервером при выполнении операции Delete и клиентом – при выполнении других операций.

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

Данная операция осуществляется через настройку параметра NLS_LANGUAGE. Он может храниться в файле Config.ora, в БД непосредственно или в системах Windows NT в реестре.

 

Прямые и косвенные соединения

Когда клиент выдает 1-е и 3-е предложение в транзакции (см. предыдущий пример), то он прямо соединен с БД HQ и косвенно – с БД Sales, содержащей удаленные записи.

Автономность узлов означает в РБД то, что БД администрируются отдельно и независимо от остальных БД. Каждая БД сопровождается независимо от остальных. Это свойство дает следующие преимущества:

· узлы системы отражают логическую компаний;

· локальные данные контролируются администратором локальной БД и соответственно область ответственности каждого администратора БД локальна и более управляема;

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

· восстановление после сбоев обычно выполняется индивидуально для каждого отказавшего узла;

· словарь данных существует для каждой локальной БД;

· узлы могут переходить независимо на новые версии программного обеспечения.

 

Объекты: схемы и именования в РБД

 

Объектами считаются: таблицы, индексы, функции, триггеры, синонимы, процедуры, блоки, библиотеки. Эти объекты принадлежат какой-либо схеме. Схема полностью совпадает с именем пользователя.

При использовании РБД можно иметь на различных серверах одну и ту же схему и таблицу, при этом указывается имя сервера. Необходимо обеспечить уникальность имен, что и делается в РБД.

 

Прозрачность в системе РБД

 

Цели прозрачности:

1) прозрачность должна предоставлять методы, позволяющие скрыть физическое местоположение объектов во всей системе от приложений и пользователей;

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

 

Преимущества прозрачности:

1) доступ к удаленным БД упрощается, т.к. не нужно знать, где находятся конкретные БД;

2) объекты можно перемещать, не оказывая влияния на конечных пользователей или приложений БД.

 

РБД должна обеспечивать прозрачность запросов, обновлений и транзакций.

Прозрачность транзакций имеет место при использовании СУБД стандартных команд SQL: ROLLBACK, COMMIT, SAVE POINT (установка промежуточной транзакции до определенной точки). Этим обеспечиваются возможности:

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

§ СУБД должна гарантировать, что все узлы вовлеченные в распределенную транзакцию, будут делать одно и тоже (они либо подтверждают, либо отвергают транзакцию в зависимости от того каким предложением заканчивается транзакция COMMIT – подтверждает, ROLLBACK - отменяет.).Если во время подтверждения распределенной транзакции происходит сбой сети или системы, то разрешение транзакции в глобальном масштабе осуществляется автоматически или прозрачно: либо подтверждает при положительном опросе всех узлов системы, либо отменяет в обратном случае.

 

Архитектура распределенной СУБД должна предоставлять возможности прозрачного дублирования данных среди узлов системы. Это означает, что поддерживание копий таблиц среди БД в РБД желательно по следующим причинам:

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

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

 

Архитектура РБД Oracle

 

Схема именования объектов и доступ к данным:

 

SELECT * from [e-mail]

где

Scott – схема, Emp – таблица, Sales.division3.acme.com - физическое местоположение.

 

РБД работают только в сети TCP/IP. После @ следует обычный доменный адрес узла, т.е. на ПК должна быть настроена система DNS.

Замечание: Oracle не проверяет уникальность глобального имени и не сохраняет его в распределенных словарях объектов, данных; однако, Oracle гарантирует, что имя объекта уникально в его собственной локальной БД.

 

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

Все транзакции в 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 всегда выбирает один из узлов сессии, как сторону точки подтверждения. Задача этого узла: выполнение атомарного действия, которое возможность подтверждения или отката распределенной транзакции.

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

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

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

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

 

Уникальность имен.

Oracle гарантирует, что внутри схемы имя объекта всегда уникально. Имя схемы внутри локальной сети тоже будет уникальным. Необходимо обеспечить уникальность имен и глобальных имен БД вручную.

Эта проблема решается вместе с администраторами БД и сети. Необходимо решить следующие вопросы:

· вопрос о непосредственном имени БД и домена

· вопрос об удаленной сессии (определить имя, под которым пользователь будет регистрироваться на удаленной станции; соединение – сессия в обычной ситуации сохраняется на все время локальной сессии пользователя, а при первом обращении к удаленной таблице открывается удаленная сессия, которая будет сохраняться, пока есть локальная сессия; но это бывает невыгодным при связи по телефонной линии, в таких случаях можно делать разрыв соединения, когда связь больше не нужна; разрыв соединения выполняется с помощью команды ALTER SESSION <close database link> <имя удаленной связи>)

 

Замечание. Вы должны обладать системной привилегией ALTER SESSION; нельзя выдавать описанную команду с параметром <close database link> из распределенной транзакции, которая выдала перед этим предложение, использующее эту связь. Ее можно выполнять только при откате или подтверждении транзакции. То же самое относится и к открытым курсорам, которые используют данную связь.

 

Снимки. Управление ими.

 

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

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

Снимок создается следующим образом:

 

CREATE SNAPSHOT emr_sf

PCTFREE 5

PCTUSED 60

TABLESPACE users

STORAGE (

INITIAL 50K

NEXT PCTINCREASE 50)

REFRESH FAST

START sysdate

NEXT sysdate+7

AS SELECT * FROM emp@ny;

 

STORAGE определяет дисковое пространство, необходимое для вашего снимка в экстентах.

TABLESPACE – табличное пространство, указание которого необязательно.

REFRESH задает параметры обновления снимка (в данном примере снимок будет обновляться каждые 7 секунд). Sysdate – псевдопеременная, содержащая текущее время и дату.

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

 

Спецификация определяющего запроса снимка (AS...).

Определяющий запрос снимка может быть любым запросом по таблицам, обзорам или другим снимкам, не находящимся в схеме пользователя SYS. Запрос снимка не может содержать опций ORDER BY или FOR UPDATE. Кроме того, необходимо различать простые и сложные снимки:

· простые снимки – это снимки, которые определяются через обзоры, у которых определяющий запрос не содержит опций GROUP BY И CONNECT BY, соединений, подзапросов и операторов множеств;

· кластеризованные снимки – это снимки, которые представляют собой кэшированную область памяти по индексам; обращение к ним быстрее (кластер – это область памяти уже проиндексированная и в них можно размещать снимки).

Привилегии, которые необходимы для создания снимков в своей схеме:

· CREATE SNAPSHOT

· CREATE TABLE

· SELECT по главным таблицам (те таблицы, по которым создается снимок)

· CREATE VIEW

· CREATE INDEX

 

Чтобы создать снимок в схеме другого пользователя необходимо иметь привилегии: CREATE ANY TABLE, CREATE ANY VIEW, CREATE ANY SNAPSHOT,CREATE ANY INDEX.

Как для создания простого снимка, так и для создания кластеризованного, вы должны иметь достаточно дискового и табличного пространства.

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

 

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

Выход из этого положения представлен на следующем рисунке:

 

 

 

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

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

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

2) журнал снимков необходимо создавать в одной БД с главной таблицей; если вы не создаете журнал снимков явно, то он создастся автоматически в схеме главной таблицы (проблем с именем журнала не будет, т.к. параметр <имя журнала> в соответствующей команде отсутствует, а при автоматическом создании вы это имя вообще не знаете).

 

CREATE SNAPSHOT LOG ON emp

TABLESPACE users

STORAGE (initial 10K next PCTINCREASE 50);

 

Привилегии, необходимые для создания снимков:

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

· CREATE TABLE

· CREATE TRIGGER

- если же журнал создается для главной таблицы в другой схеме, то:

· CREATE ANY TABLE

· CREATE ANY TRIGGER

 

Владелец журнала должен иметь достаточную квоту.

 

Порядок создания снимков и их журналов:

1. Создание главной таблицы.

2. Создание снимка.

3. Создание журнала.

4. Первое освежение.

5. Второе освежение.

 

Двойная черта обозначает полное освежение, а одинарная – быстрое.

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

Можно применить и другой порядок создания снимка и журнала:

1. Создание главной таблицы.

2. Создание журнала.

3. Создание снимка.

4. Первое освежение.

5. Второе освежение.

Снимки используются точно также как и таблицы, обзоры, но к ним нельзя применять операции INSERT,UPDATE. На их основе можно создавать виды и синонимы.

Индексация снимков возможна для таблицы, в которой был создан индекс для хранения снимков.

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

Привилегии, необходимые для выполнения удаления:

· вы должны быть владельцем снимка (т.е. он лежит в вашей схеме)

· DROP ANY SNAPSHOT

· DROP ANY VIEW

· DROP ANY TABLE

 

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

DROP SNAPSHOT emp_log.

 

Журналы можно удалять без каких-либо связей, т.е. независимо. Причиной удаления может выступить:

1) все простые снимки таблицы удалены;

2) все простые снимки таблицы должны быть полностью обновлены.

 

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

· являться владельцем главной таблицы

· DROP ANY TABLE

 

Альтернативы снимкам.

В том случае, если снимки не отвечают необходимым требованиям, то Oracle дает две возможные им замены:

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

· Ручное дублирование таблиц с использованием утилит экспорта/импорта и SQL; в этом случае копия таблицы будет содержать записи исходной таблицы на момент копирования.

 

Триггеры увеличивают трафик, а наличие ручного копирования усложняет работу с БД.

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

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

 

Проблемы работы с триггерами и снимками:

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

2) Использование триггеров приводит к более низкой производительности, чем при использовании снимков; это связано с тем, что каждое обновление вызывает значительный сетевой трафик. Обновление снимка вызывает меньший сетевой трафик.

3) Снимки обеспечивают декларативное ограничение целостности.

 

Дублирование таблиц с помощью триггеров:

· Каждая копия может, как опрашиваться, так и обновляться, причем все изменения распространяются автоматически на каждую копию.

· Удаленное обновление осуществляется триггерами, подтверждается транзакциями пользователя, содержащими UPDATE, посредством обычного двухфазного COMMIT.

· Необходимо помнить, что при выключении дублирующих триггеров (во время загрузки информации) получим неэквивалентные таблицы.

· При сбое удаленные копии таблиц нельзя устранять, пока не будет устранен сбой.

 

Создание триггера

· Копируемая таблица обязательно должна иметь Primary Key;

· Необходимо создать специальный флажковый столбец с типом данных Char(1), он необходим для предотвращения зацикливания каскадов триггеров;

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

· Требуется создать необходимые связи БД в каждой БД для этой таблицы.

 

Примеры написания триггера.

1) Триггер на INSERT

CREATE TRIGGER emp_ins

AFTER INSERT ON emp_base

FOR EACH ROW

WHEN (new.flags is null)

BEGIN

INSERT INTO fred.emp.base@sf VALUES(:new.empno, new.deptno, ‘T’)

END;

2) Триггер на DELETE

CREATE TRIGGER emp_del

AFTER DELETE ON emp_base

FOR EACH ROW

DECLARE

Mutating EXCEPTION;

PRAGMA exception_init (mutating, -4091)

BEGIN

DELETE fred.emp.base@sf

WHERE empno=:old.empno;

EXCEPTION WHEN mutating THEN NULL;

 

END;

 

3) Триггер на UPDATE

CREATE TRIGGER emp_upd

AFTER UPDATE ON emp_base

FOR EACH ROW

BEGIN

IF NOT updating(‘flag’) THEN

UPDATE fred.emp_base@sf SET

Empno=:new.empno;

Deptno=:new.deptno;

Flag=’T’

WHERE empno=:old.empno;

ENDIF

END;

 

Управление снимками

Необходимо выполнить программу (script - файл) CATSNAP.sql на БД, содержащей главную таблицу и на БД, содержащей ее снимки. Данный script нужно выполнять в схеме пользователя SYS (он расположен в каталоге ADMIN). Скрипт нужно выполнять, если Oracle был установлен без процедурной опции.

Выполнение скрипта обеспечивает создание структур, необходимых для создания снимков. Для хранения снимков нужно выполнить скрипт dbmssnap.sql (выполнение производить перед началом администрирования снимков). Он создает пакет процедур, необходимый для обновления снимков. Его нужно исполнить на основной БД и на БД, содержащих снимки в схеме пользователя SYS.

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

Администратор ОС должен создать программу, запускающую скрипт для работы Oracle. Эта программа должна подключаться к БД, содержащей снимки, и запустить процедуру DBMS_SNAPSHOT.REFRESH_ALL(). ОС Novell раз в три - четыре дня должна запускать файл REFR.ncf, содержащий всего одну команду LOAD SVRMGR Refr.sql. Эта программа обеспечит подключение к Oracle.

Файл Refr.sql содержит:

CONNECT scott/Tiger@K108; (определяет подсоединение к серверу)

EXECUTE DBMS_SNAPSHOT.REFRESH_ALL();

DISCONNECT;

EXIT;

 

Создание снимков

Снимки лежат в схеме пользователя, который их создает. Длина имени снимка не должна превышать 23 символа. Когда создается снимок, Oracle выполняет несколько внутренних операций:

1) На узле снимка создается таблица для хранения строк, извлекаемых определяющим запросом снимка. Эта таблица называется базовой таблицей снимка и имеет специальное название SNAP$_<имя снимка>. Эту таблицу нельзя изменять никаким образом. Oracle создает только читаемый обзор этой таблицы для запросов, выдаваемых по снимку. Этот вид имеет имя, определяемое в предложении CREATE SNAPSHOT (т.е. при обращении к снимку мы обращаемся к обзору).

2) Oracle создает второй локальный обзор по удаленной главной таблице и использует этот обзор при освежении снимка. Имя этого обзора MVIEW_<имя снимка>. Дополнительно, если снимок является простым, Oracle создает индекс по таблице SNAP$_<имя снимка>, который имеет имя PK$_ <имя снимка>.

 

Ручное обновление снимков.

Необходимо вызвать процедуру REFRESH из DBMS_SNAPSHOT:

DBMS_SNAPSHOT.REFRESH(‘[схема:] имя’ [,’опция освежения’]);

Где dbms_snapshot – пакет; refresh – сама процедура; схема – схема пользователя (по умолчанию - текущая); имя – имя снимка; опция освежения – может иметь значение:

· F – быстрое освежение;

· C – полное освежение;

·? – опция освежения по умолчанию (которая указана в параметре Refresh).

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

Привилегии, необходимые для ручного обновления снимков:

· ALTER ANY SNAPSHOT

· SELECT к журналу по главной таблице.

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

 

Удаление журнала снимков.

Его можно удалить независимо от главной таблицы и существующих снимков. Удаление осуществляется командой:

DROP SNAPSHOT <имя главной таблицы>;

 

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

· Все простые снимки главной таблицы были удалены.

· Все простые снимки должны быть обновлены полностью.

Копирование таблицы вручную выполняет команда:

CREATE TABLE <имя локальной копии таблицы> AS SELECT * FROM <удаленная копия>;

Замечания:

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