22)Реализация репликации данных в субд Oracle с помощью триггеров.

В СУБД Oracle для ор­ганизации репликации данных могут использоваться триггеры и материализованные представления. Триггеры обычно применяются в случае низкой интенсивности изменения данных в ведущей таблице, а также преимущественно при выполнении операций INSERT и DELETE. Это связано с тем, что для поддержки SQL,-оператора обновления данных UPDATE необходим более сложный код триггера. Триггеры ак­тивизируются при выполнении операций с каждой строкой ведущей таблицы и про­изводят соответствующие операции в удаленной таблице. Предварительно следует создать связь базы данных, которую он будет использовать.

Пример создания связи с именем trig link, в которой для организации соединения с уда ленной базой данных применяется имя службы usel, представляется следующим образом:

CREATE PUBLIC DATABASE LINK trig_link

CONNECT TO CURRENT_USER

USING 'usel';

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

CREATE TRIGGER tr_copy

AFTER INSERT ON sotr

FOR EACH ROW BEGIN

INSERT INTO sotr@trig_link

VALUES

(:new.cod, :new.name, :new.pod, :new.oklad, :new.date_birth, :new.inn);

END;

23)Реализация репликации данных в субд Oracle с помощью материализованных представлений.

Материализованное представление является объектом базы дан­ных, в котором физически содержится результат выполнения запроса. Они исполь­зуются для тиражирования данных, а также для повышения производительности выполнения тех запросов, в которых должны быть возвращены агрегируемые дан­ные. Таблица, данные из которой тиражируются, называется главной и указывается в предложении FROM запроса. В этом предложении могут быть также приведены имена стандартных представлений либо имена других материализованных пред­ставлений. Представления делятся на простые и сложные. Простые материа­лизованные представления характеризуются тем, что они содержат те же строки, что и главная таблица. Сложные материализованные представ­ления включают один или несколько агрегатов следующего назначения: SUM, COUNT, COUNT(*), AVG, VARIANCE, STDDEV, MIN и MAX, либо предполагают вы­полнение операций соединения главных таблиц. При создании материализованного

представления с помощью SQL-команды CREATE MATERIALIZED VIEW разработ­чик должен указать параметры, которые определяют:

-момент первоначального заполнения материализованного представления данными

-методы, режимы и время регенерации материализованно­го представления.

Пример. Необходимо создать материализованное представление, определяющее для каждого представления суммарную заработную плату. В качестве параметров управления представлением целесообразно указать следующие:

режим обновления - быстрый FAST.

момент обновления - после фиксации транзакции в главной таблице ON COMMIT;

использование процедуры переформирования запросов ENABLE QUERY REWRITE;

момент первоначального заполнения представления данными - непосредственно после его создания BUILD IMMEDIAТЕ.

CREA ТЕ MATERIALIZED VIEW pod_sal_mv

PCTFREE 0 TABLESPACE msalview

STORAGE (INITIAL 20K NEXT 20K PCTINCREASE 0)

PARALLEL

BUILD IMMEDIATE

REFRESH FAST ON COMMIT

ENABLE QUERY REWRITE

AS

SELECT u.podname, SUM (z.sal) AS INT_SUM

FROM pod u, sotr z

WHERE u.cod_pod=z.cod_p

GROUP BY u.podname;

Применение материализованных представлений приводит к нарушению ссылочной целостности данных. Суть проблемы состоит в том, что если между главными таблицами существует логическая связь, поддерживаемая парой ключей «родительский-внешний», то такая связь должна существовать между простыми материализованными представлениями, созданными на их основе. Однако различие в расписаниях обновления представлений приводит к нарушению целостности дан­ных. В частности, если в качестве главных таблиц выбраны таблица pod и таблица sotr, то между ними существует логическая связь, состоящая в том, что сотрудники приняты на работу только в те подразделения, коды которых содержатся в таблице pod. В то же время в соответствующих простых представлениях это ограничение может нарушаться. Для исключения такой ситуации эти представления должны включаться в одну и ту же группу обновлений, элементы которой модифицируются одновременно. В качестве материализованного представления может быть зарегист­рирована существующая таблица с помощью задания параметра ON PREBUILT TABLE.

Примером трансформации таблицы sotr в материализованное представление является следующий код:

CREATE MATERIALIZED VIEW "hr”.“sotr”

ON PREBUILT TABLE

REFRESH FORCE

START WITH TO_DATE('19-Aug-2005 04:45:45 PM',

'dd-Mon-YYYY HH:MI:SS AH')

NEXTSYSDATE + 1

ENABLE QUERY REWRITE

AS

SELECT SUM (sal)

FROM sotr

BEGIN

DBMS_STATS.GATHER_TABLE_STATS (

ownname =>'hr'

tabname => 'sotr');

END;