Обработка ошибок в удаленных процедурах.

При работе возникают следующие исключения:

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

2) предопределенные исключения PL/SQL такого типа как no_data_found, …;

3) ошибки SQL типа ORA-00900;

4) исключения приложения, которые генерируются посредством вызова процедуры RAISE_APPLICATION_ERROR.

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

 

Разрешение проблем распределенных транзакций

 

Проблемы таковы:

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

· продолжительный отказ

 

В первом случае речь идет о том, что не все машины подтвердили транзакцию, а во втором – о блокировках. Первую проблему решает сам Oracle с помощью процесса RECO и администратор может помочь пользователю информацией при откате или завершении транзакции.

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

 

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

 

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

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

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

 

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$_ <имя снимка>.