Валерий Юринский Директор отделения технологического консалтинга

1. Oracle Database 11g R2 (11.2)Edition-Based Redefinition – набор новых функциональных возможностейдля модернизации приложенийбез остановки работы пользователей Валерий Юринский Директор отделения технологического консалтинга

2. Высокая доступность(High Availability) Современный бизнес неразрывно связан с информационными системами и технологиями, поэтому непрерывность функционирования ИТ- инфраструктуры критически важна для любого предприятия Вынужденный простой информационной системы может привести к сбоям в производстве и реализации продукции, потерям доходов и т.д. Высокая доступность - это та цель, достижение которой гарантирует непрерывность функционирования информационных систем, а значит непрерывность бизнес-процессов в целом

3. Высокая доступность Вынужденный простой Неплановый простой БД Сбой оборудования Сбой данных Плановый простой БД Системные изменения базы данных Модернизация объектов базы данных

4. Высокая доступность Вынужденный простой и защита от него Неплановый простой БД Сбой оборудования Real Application cluster (RAC) Сбой данных Physical Standby Плановый простой БД Системные изменения базы данных Logical Standby, Streams Модернизация объектов базы данных Нет защиты(до Oracle 11g R2)

5. Высокая доступность Вынужденный простой и защита от него Неплановый простой БД Сбой оборудования Real Application cluster (RAC) Сбой данных Physical Standby Плановый простой БД Системные изменения базы данных Logical Standby, Streams Модернизация объектов базы данных Edition-based Redefinition (Oracle 11g R2)

6. Edition-based Redefinition Версионное переопределение позволяет выполнить модернизацию прикладной системы без остановки работы её пользователей. Edition-based Redefinitiongives an ability for Online Application Upgrade.

7. Edition-based Redefinition “Edition-based Redefinitionis the killerfeatureof Oracle Database11gRelease 2”. Tom Kyte

8. Edition-based Redefinition "Edition-based Redefinitionis the killer featureof Oracle Database 11g Release 2.It is worth 2 features".Tom Kyte (24-feb-2010, Moscow, Russia) "Версионное переопределение – это революционная новинка Oracle Database 11g Release 2(«захватчик рынка»).Она достойна того, чтобы считать её не одной, а сразу несколькими новыми функциями".Том Кайт (24-фев-2010, Москва, Россия)

9. До обновления (pre-upgrade) Пользователи работаютс существующим ("старым") приложением Старая версия

10. Требования безостановочногообновления приложений Установка обновлений структур данных и нового программного кода не должна оказывать влияния на работу пользователей существующей («старой») системы Транзакции пользователей «старой» системы должны отражаться в «новой» системе Транзакции пользователей «новой» системы должны отражаться в «старой» системе

11. Обычный сценарий обновления «Инвалидация» объектов - Dependency Tracking. EMP_PR_SAL DEPT EMP EMP_V_DEPT DEPT_PR EMP_V_SAL DEPT_PR_PR EMP_PR CREATE PROCEDURE emp_pr_sal IS BEGIN FOR r IN (SELECT * FROM emp_v_sal) LOOPNULL;END LOOP; END emp_pr_sal; CREATE VIEW emp_v_dept AS SELECT D.deptno, D.dname, D.loc , E.empno, E.ename, E.job , E.sal, E.comm FROM dept D, emp E WHERE D.deptno = E.deptno (+); INVALID INVALID CREATE VIEW emp_v_sal AS SELECT D.dname, SUM(E.sal) AS sum_sal FROM dept D, emp E WHERE D.deptno = E.deptno (+) GROUP BY D.dname; INVALID CREATE PROCEDURE emp_pr IS BEGIN FOR r IN (SELECT * FROM emp) LOOP NULL; END LOOP; END emp_pr; INVALID Oracle10g

12. Обычный сценарий обновления «Инвалидация» объектов - Fine Grained Dependency Tracking EMP_PR_SAL DEPT EMP EMP_V_DEPT DEPT_PR EMP_V_SAL DEPT_PR_PR EMP_PR CREATE PROCEDURE emp_pr IS BEGIN FOR r IN (SELECT * FROM emp) LOOP NULL; END LOOP; END emp_pr; INVALID Oracle11g

13. Обычный сценарий обновления Вывод Даже используя Oracle 11g не удастся применить обычный сценарий для безостановочного обновления прикладной системы (online application upgrade), поскольку неизбежна «инвалидация» некоторых объектов – это может привести к сбоям в работе пользователей

14. Глоссарий Edition– версия Edition-based– версионный, на основе версий Editioned – версионируемый, версионированный, гл. версионирован(а), версионируем(ы/а) Noneditioned – неверсионируемый, неверсионированный Editionable – версионируемый Noneditionable – неверсионируемый Editioning view –версионирующее представление Editions-enabled – версионно-полномочный Crossedition – кросс-версионный Forward crossedition trigger – прогрессивный кросс-версионный триггер Reverse crossedition trigger – регрессивный кросс-версионный триггер

15. Версионное переопределение(Edition-based Redefinition) Oracle11g Release 2вводит новый «несхемный» объект базы данных – версию (Edition) В каждый момент времени каждая сессия БД связывается с единственной версией Новая версия создается, как потомок предыдущей версии, и наследует все версионируемые объекты родительской

16. Версионное переопределение(Edition-based Redefinition) По-прежнему ссылку на объекты можно осуществлять сиспользованием имени схемы - schema.object, однако появляется новое измерение – версия объекта. Оно соответствует версии, установленной для сессии БД Использование версионности позволяет выполнять безостановочное обновление приложений

17. Обновление (upgrade) Установка «нового» приложения Старая версия Новая версия

18. Использование обеих версий (hot-rollover period) Старая версия Новая версия Hot-rollover

19. После обновления (post-upgrade) «Старая» версия скрывается (retired). После этого работает уже только «новая»версия Старая версия Новая версия

20. Подробности

21. Введение Версия (edition) – это «несхемный» объект БД (non-schema object), то есть он не принадлежит никакой конкретной схеме, а принадлежит всей базе данных Каждая БД имеет, как минимум, одну версию Новая версия создается, как потомок существующей версии. У версии может быть только один потомок (ограничение текущей реализации).

22. Введение Каждая сессия БД использует версию Версия уникально идентифицируется своим именем Версию, как часть имени объекта, Oracle подставляетавтоматически Начальная (initial) версия ORA$BASE, порождается при генерации новой БД Oracle11.2 или при обновлении БД до Oracle 11.2

23. Текущая версия Версия, которую использует сессия в конкретный момент времени называется текущей версией (currentedition) Текущей может быть любая версия, для которой пользователю предоставлена привилегия USE Пользователь версии – это пользователь, для сессии которого в данный момент установлена эта версия

24. Как посмотреть версию SQL*Plus v11.2.0.x Версия сессии: SQL> SHOW EDITIONEDITION------------------------------ORA$BASE

25. Как посмотреть версию С помощью SQL-функцииSYS_CONTEXT('USERENV', 'параметр') …_EDITION_ID = {DBA|ALL}_OBJECTS.OBJECT_ID

26. Изменение текущей версии Изменение версии сессии можно выполнить командой ALTER SESSION SET EDITION = my_ver_2; Для установки версии по умолчанию на уровне БД можно использовать команду ALTER DATABASE DEFAULT EDITION = my_ver_2;

27. Изменение текущей версии В Oracle Database 11.2.0.2можно устанавливать версию по умолчанию для каждого сервиса БД Для одиночного экземпляра: DBMS_SERVICE.CREATE_SERVICE(… , edition => edition_name); DBMS_SERVICE.MODIFY_SERVICE (… , edition => edition_name); Для конфигурации Real Application Clusters следует использовать утилиту SRVCTL (Server Control utility) : srvctl add service . . . –t edition_name srvctl modify service . . . –t edition_name

28. Унаследованные и реальные объекты Новая версия создается, как потомок существующей родительской версии В этой дочерней версии объекты базы данных могут быть либо унаследованными (inherited)объектами родительской версии, либо реальными (actual) объектами дочерней версии Если имеется только одна используемая версия, то всё объекты – это реальные (actual) объекты этой версии

29. Актуализация унаследованных объектов(Actualization of Inherited Objects) Когда пользователь дочерней версии изменяет унаследованный объект командой DDL, то этот объект копируется из родительской версии в дочернюю и команда DDL применяется уже к этой копии Таким образом происходит актуализация (actualization), и в дочерней версии появляется реальный (actual) объектс тем же именем В родительской версии объект остается неизменным и становится невидимым (is no longer visible) в дочерней версии

30. Актуализация унаследованных объектов(Actualization of Inherited Objects) PRE_UPG edition VIEW FUNCTION TRIGGER PROCEDURE POST_UPG edition VIEW (inherited) FUNCTION (inherited) TRIGGER (inherited) PROCEDURE (inherited) GRANT EXECUTE…; POST_UPG – это потомокPRE_UPG

31. Актуализация унаследованных объектов(Actualization of Inherited Objects) PRE_UPG edition VIEW FUNCTION TRIGGER PROCEDURE POST_UPG edition VIEW (inherited) FUNCTION (actual) TRIGGER (inherited) PROCEDURE (inherited) POST_UPG – это потомокPRE_UPG

32. Удаление унаследованного объекта(Dropping an Inherited Object) Когда пользователь дочерней версии удаляет (drops) унаследованный объект, то этот объект перестает быть видимым (is no longer visible) в дочерней версии В родительской версии объект остается неизменным и продолжает быть видимым

33. Удаление унаследованного объекта(Dropping an Inherited Object) PRE_UPG edition VIEW FUNCTION TRIGGER PROCEDURE POST_UPG edition VIEW (inherited) FUNCTION (actual) TRIGGER (inherited) PROCEDURE (inherited) DROP TRIGGER…; POST_UPG – это потомокPRE_UPG

34. Удаление унаследованного объекта(Dropping an Inherited Object) PRE_UPG edition VIEW FUNCTION TRIGGER PROCEDURE POST_UPG edition VIEW (inherited) FUNCTION (actual) TRIGGER (inherited) PROCEDURE (inherited) DROP TRIGGER…; POST_UPG – это потомокPRE_UPG

35. Версионируемые объекты(Editioned Objects) Не все объекты версионируемы (editioned) Чтобы объект схемы был версионируемым должно быть соблюдено два условия: 1. Объект должен быть объектом версионируемого(editionable) типа: Function, Procedure, Package (спецификация и тело), Type (спецификация и тело), Trigger, Library, Synonym (личный, не публичный), View. 2. Объект должен принадлежать версионно-полномочному пользователю(has an editions-enabled owner)

36. Версионируемые объекты (Editioned Objects) Если объект имеет версионируемый тип, но принадлежит не версионно-полномочному пользователю, то такой объект называется потенциально версионируемым (potentially editioned) В версии может быть своя копия версионируемого объекта - в этом случае только эта копия видна в рамках данной версии

37. Версионируемые объекты. Пример PRE_UPG edition FUNCTIONmy_func POST_UPG edition FUNCTION my_func • Пример: • В версиях PRE_UPGи POST_UPGесть функция MY_FUNC • Пользователь версииPOST_UPGвыполняет: SELECT my_func FROM dual; • Происходит вызов функции из версии POST_UPG • Функция из PRE_UPGпользователю версии POST_UPGне видна POST_UPG edition SELECT my_func FROM dual; POST_UPG – это потомокPRE_UPG

38. Неверсионируемые объекты (Noneditioned Objects) Неверсионируемый объект (Noneditioned Object)– объект схемы, имеющий неверсионируемый тип: Clusters, Constraints, Database links, Dimensions, Indexes, Indextypes, Java (all), Materialized (views, view logs), Mining models, Object (tables, types, views), Operators, Sequences, Tables В версии не может быть своей копии неверсионируемого объекта – такие объекты идентичны для всех версий и видны во всех версиях

39. Неверсионируемые объекты (Noneditioned Objects) Версионируемый объект уникально идентифицируется схемой (owner), именем объекта (object_name) и версией (edition_name). Неверсионируемый объект уникально идентифицируется схемой (owner) и именем объекта (object_name).

40. Правила для версионируемых объектов(Rules for Editioned Objects) Неверсионируемый объект не может зависеть от версионируемого объекта, например: Публичный синоним не может ссылаться на версионируемый объект Функциональный индекс не может зависеть от версионируемой функции Материализованное представление не может зависеть от версионирующего представления Таблица не может иметь столбец пользовательского типа данных, чей владелец является версионно-полномочным Абстрактный тип данных не может быть одновременно версионируемым и эволюционируемым (evolved)

41. Предоставление версионных полномочий Для предоставления пользователю версионных полномочий (to enable editions for a user) используется фраза ENABLE EDITIONS команды CREATEUSERилиALTER USER: ALTER USER scott ENABLE EDITIONS; Предоставленныеверсионные полномочия: имеют обратную силу (retroactive), не могут быть отменены (irreversible). После того, как пользователь стал версионно-полномочным (editions-enabled), каждый объект версионируемого типа, уже принадлежащий ему или создаваемый им, – это версионируемый объект (editioned object).

42. Создание версии Для создания версий пользователю должна быть предоставлена привилегия CREATE ANY EDITION Создание версий критично для системы, поэтому привилегию следует предоставлять осторожно Версия создается командой CREATE EDITION CREATE EDITION post_upg AS CHILD OF ORA$BASE;

43. Право использования версии Пользователь, создавший версию, получает на неё привилегию USE WITH GRANT OPTION Право использования версии другими пользователями предоставляется с помощью привилегии USE: GRANT USE ON post_upg TO vrashpil;

44. Простейший пример CREATE PROCEDURE my_proc IS BEGIN dbms_output.put_line('Ку! Я MY_PROC. Версии-1.0'); END; / EXEC my_proc; Ку! Я MY_PROC. Версии - 1.0 CREATE EDITION POST_UPG AS CHILD OF ORA$BASE; ALTER SESSION SET EDITION = POST_UPG; CREATE OR REPLACE PROCEDURE my_proc IS BEGIN dbms_output.put_line(‘Ку! И я MY_PROC. Но версии-2.0'); END; / EXEC my_proc; Ку! И я MY_PROC. Но версии-2.0

45. Таблицы и индексы Таблицы и индексы – это неверсионируемые объекты (noneditionable objects) Таблицы и индексы содержат огромный объем данных, следовательно, хранение их копий для разных версий потребовало бы слишком много дисковой памяти

46. Версионирующие представления (Editioning Views) Версионирующие представления (editioning views): Новый класс представлений, появившийся в Oracle11g R2 Логически представляют собой копии таблицы в разных версиях - это логические проекции неверсионируемых физических таблиц

47. Отличия версионирующих представлений от обычных При создании указывается фраза EDITIONING CREATE EDITIONING VIEW emp ASSELECT empno, …, deptno FROM emp_rt; Поскольку логически они представляют собой версию таблицы, то Могут иметь DML-триггеры всех обычных типов: CREATE TRIGGER trigger_name{BEFORE | AFTER}{INSERT | UPDATE | DELETE} ON editioning_view_name[FOR EACH ROW] Не могут иметь триггеров типа INSTEAD OF

48. Версионирующее представление. Ограничения В каждой версии может быть одно единственное версионирующее представление (ВП) для каждой базовой таблицы Во фразе FROM команды SELECT, задающей представление, должна быть только одна таблица ВП может только отображать (project) и переименовывать столбцы В списке выборки могут быть только реальные данные – столбцы базовой таблицы (не выражения, не функции… )и необязательные псевдонимы столбцов (aliases) Запрещается использование WHERE, GROUP BY и т.п.

49. Версионирующее представление. Ограничения Версионирующие представления нельзя использовать в ограничениях типа FOREIGN KEY Версионирующее представление гарантированно не искажает планы запросов и не приводит к снижению их производительности!!!

50. Версионирующее представление и удаление базовой таблицы При удалении таблицы, на которой базируется ВП, само ВП и принадлежащие ему триггеры не удаляются При удалении базовой таблицы ВП и все зависимые от него объекты получают статус INVALID («инвалидируются»)