Одним из самых значительных усовершенствований Oracle11g Release 2 является оперативная замена — новый элемент технологий высокой доступности Oracle. Эта функция позволяет заменять компоненты баз данных во время использования приложения; иначе говоря, Oracle позволяет изменять приложения PL/SQL на ходу. Оперативная замена сводит к минимуму (а то и полностью устраняет) простои в работе приложения.
Когда возникает необходимость в обновлении используемого приложения, Oracle создает копию соответствующих объектов базы данных, используемых приложением, и переопределяет скопированные объекты в изоляции от работающего приложения. Вносимые изменения никак не проявляются и не оказывают воздействия на пользователей. Пользователь продолжает работать с приложением в том виде, в котором оно существовало до внесения изменений (то есть до перехода на новую версию). Когда вы будете убеждены в том, что все изменения верны, доступ к обновленному приложению открывается всем пользователям.
Как нетрудно предположить, добавление этой возможности оказало колоссальное влияние на Oracle. Например, если вы хотите получить список всех определенных вами объектов, вместо запроса к ALL_OBJECTS
следует запросить содержимое ALL_OBJECTS_AE
(AE=«All Editions»). Теперь уникальный спецификатор объекта образуется из значений OWNER, OBJECT_NAME
и EDITI0N_NAME
(если предположить, что для владельца включена поддержка переопределения). Этот аспект дает всего лишь отдаленное представление об изменениях, которые оперативное переопределение породило в Oracle.
Другие возможности Oracle, относящиеся к области высокой доступности, могут применяться таким образом, что установка приложения не требует никакой специальной подготовки, а разработчики даже не знают, какие средства высокой доступности используются на текущей площадке.
С оперативной заменой дело обстоит иначе. Ее использование возможно лишь при соблюдении следующих условий:
- Подготовка приложения к оперативной замене требует изменения схем, которым принадлежат объекты базы данных. Эта работа выполняется архитектором приложения, а ее результаты отражаются в новой (или самой первой) версии приложения. Для реализации этого подготовительного шага пишутся специальные сценарии, которые должны запускаться «традиционно» (то есть в автономном режиме).
- Когда приложение будет готово к оперативной замене, группа разработчиков, ответственных за написание сценариев обновлений, должна изучить особенности оперативной замены и написать свои сценарии по-новому.
Учитывая сложность механизма оперативной замены и того факта, что он, строго говоря, выходит за рамки языка PL/SQL
, мы ограничимся очень простой демонстрацией, которая дает представление о работе оперативной замены.
Начнем с создания новой версии. Каждая новая версия должна определяться как потомок существующей версии. Кроме того, все базы данных, обновленные или созданные в Oracle11g Release 2, в исходном виде существуют в виде версии с именем ora$base. Эта версия всегда должна быть родителем первой версии, создаваемой командой CREATE EDITION
.
Допустим, в приложении, написанном для отдела кадров, изменяется формат вывода полного имени работника. Традиционно имена выводились в формате «имя пробел фамилия»:
FUNCTION full_name (first_in IN employees.first_name%TYPE
, last_in IN employees.first_name%TYPE
)
RETURN VARCHAR2
IS
BEGIN
RETURN (first_in || ' ' || last_in);
END full_name;
Эта функция определяется в версии ora$base
. Вызывая ее, мы получаем следующий результат:
SQL> BEGIN DBMS_OUTPUT.put_line (full_name ('Steven', 'Feuerstein'));END;/
Steven Feuerstein
К сожалению, теперь пользователи желают, чтобы имена выводились в формате «фамилия запятая имя». Функция часто вызывается в приложении, и мы не хотим заставлять пользователей отключаться от базы данных. К счастью, в системе недавно было выполнено обновление до версии Oracle11g Release 2
, позволяющее использовать механизм оперативной замены. Сначала мы создаем новую версию базы данных для нового формата функции:
CREATE_EDITION_HR_PATCH_NAMEFORMAT
/
Затем эта версия назначается текущей:
ALTER SESSION SET edition = HR_PATCH_NAMEFORMAT
/
Так как новая версия создана на базе ora$base
, она наследует все объекты, определенные в родительской версии. Соответственно, при вызове функции мы получаем такой же ответ, как и прежде:
SQL> BEGIN DBMS_OUTPUT.put_line (full_name ('Steven', 'Feuerstein'));END;/
Steven Feuerstein
Теперь реализация функции изменяется в соответствии с новым правилом:
CREATE OR REPLACE FUNCTION full_name (first_in IN employees.first_name%TYPE
, last_in IN employees.first_name%TYPE
)
RETURN VARCHAR2
IS
BEGIN
RETURN (last_in || ', ' || first_in);
END full_name;
/
При выполнении функции мы получаем новый результат:
SQL> BEGIN DBMS_OUTPUT.put_line (full_name ('Steven', 'Feuerstein'));END;/
Feuerstein, Steven
Но если вернуться к базовой версии, имя снова выводится в старом формате:
SQL> ALTER SESSION SET edition = ora$base/
2 BEGIN DBMS_OUTPUT.put_line (full_name ('Steven', 'Feuerstein'));END;/
Steven Feuerstein
Конечно, мы рассмотрели простейший пример использования оперативной замены. Проектировщик архитектуры приложения и группа разработки должны подробно разобраться во многих аспектах этого механизма, особенно в триггерах и представлениях, необходимых при изменении структуры таблицы (которая не поддерживает переопределение напрямую).
Оперативная замена подробно документирована в документации Oraclellg Release 2 Advanced Application Developer’s Guide
.