Выступление Петра Марголиса, нашего архитектора, на Oracle Database Forum (19 февраля 2014 года, Москва).

1. Использование
Edition Based Redefinition
для обновления приложений,
доступных 24/7
Петр Марголис
Архитектор
Oracle Database Forum, Москва
19 февраля 2014

2. План







О компании CUSTIS
Приложение
Цели и требования
Варианты архитектуры решения
Основные принципы Oracle EBR
Перевод приложения на EBR
Результат
2/27

3. О компании CUSTIS

Специализация – заказная разработка,
бережное внедрение и сопровождение
на полном жизненном цикле масштабных
учетно-аналитических систем



Год основания – 1996
Количество сотрудников > 200
Ключевые клиенты: Банк России,
Газпромбанк, ГК «Спортмастер»,
ЕИРКЦ г. Астрахани, ЕРКЦ г. Саратова
3/27

4. Приложение



Банковская учетная система
Двухзвенная архитектура


Сервер – Oracle DB 11gR2, бизнес-логика на PL/SQL
«Тонкий клиент» – отображение и ввод данных
Интеграция с другими системами
4/27

5. Цели и задачи

Централизация учета в многофилиальном
банке
 Филиалы располагаются в различных часовых
поясах, поэтому приложение используется
в режиме 24/7

Снижение операционных рисков
при обновлении системы во время
эксплуатации
 Поэтапное внедрение изменений в различных
филиалах с возможностью их отмены
5/27

6. Технические требования

Возможность установки обновлений ПО
без остановки работы системы

Параллельная эксплуатация нескольких
версий ПО, работающих с одними данными

Возможность перевода пользователей
на новую версию ПО или «отката»
к предыдущей версии
6/27

7. Варианты архитектуры решения
Распределенная
Централизованная
7/27

8. Распределенная архитектура
 Повышение надежности: отказ




одного узла не приводит
к остановке системы
В каждой временной зоне есть
возможность выделить
технологическое окно
для установки обновлений
Необходимость
администрировать множество
экземпляров ПО
Необходимость синхронизации
изменений и разрешения
конфликтов
Нет механизма «отката»
обновлений
8/27

9. Централизованная архитектура
 Уменьшение количества
экземпляров системы,
которые необходимо
администрировать
 Гарантированная
согласованность данных
 Отсутствие технологических
окон для установки
обновлений
 Нет механизма поэтапного
обновления ПО и «отката»
обновлений
9/27

10. Edition-based redefinition (EBR)


Входит в Enterprise Edition, начиная с 11gR2

Позволяет управляемо переключать
пользователей на различные версии ПО
Позволяет выполнять изменения
(redefinition) объектов, не затрагивая
существующие версии (editions) объектов
10/27

11. Версионируемость объектов
Версионируемые
Неверсионируемые
















Function
Procedure
Package
(спецификация и тело)
Type (спецификация
и тело)
Trigger
Non-public synonym
View
Editioning Views
Cross-edition triggers

Tables
Constraints
Indexes
Database links
Materialized views
Sequences
Public synonyms
(версионируемые в 12с)
….
11/27

12. Перевод приложения на EBR







Подготовительные шаги
Инструментарий администратора
Доработка приложения
Обновление неверсионных объектов
Обеспечение совместимости версий
Изменения в модели безопасности
Влияние на разработку и эксплуатацию
12/27

13. Подготовительные шаги
1. Включение версионирования
для набора схем
13/27

14. Подготовительные шаги
1. Включение версионирования
для набора схем
2. Создание версионирующих
представлений для всех таблиц
14/27

15. Подготовительные шаги
1. Включение версионирования
для набора схем
2. Создание версионирующих
представлений для всех таблиц
3. Перевод кода PL/SQL
и клиентских приложений
на использование
версионирующих представлений
15/27

16. Подготовительные шаги
1. Включение версионирования
для набора схем
2. Создание версионирующих
представлений для всех таблиц
3. Перевод кода PL/SQL
и клиентских приложений
на использование
версионирующих представлений
4. «Перевешивание» триггеров
на версионирующие представления
5. Выдача прав другим схемам
на версионирующие представления
16/27

17. Инструментарий администратора

Доработка инструментария
установки обновлений

Создание нового edition перед
изменением объектов
17/27

18. Инструментарий администратора

Доработка инструментария
установки обновлений

Создание нового edition перед
изменением объектов
18/27

19. Инструментарий администратора

Доработка инструментария
установки обновлений

Создание нового edition перед
изменением объектов
19/27

20. Инструментарий администратора

Доработка инструментария
установки обновлений


Создание нового edition перед
изменением объектов
Разработка инструментария
управления версиями

Задание версии по умолчанию
ALTER DATABASE DEFAULT EDITION = edition_name;

Переключение пользователей между
версиями
CREATE OR REPLACE TRIGGER tr_set_edition
AFTER LOGON ON DATABASE
…
ALTER SESSION SET EDITION = edition_name;
…
20/27

21. Доработка приложения



Неверсионные объекты
не могут ссылаться
на версионные
Появляются новые типы
объектов
и изменяются структуры
Расширяется набор
атрибутов, задающих
уникальность объектов
Отказ
от использования
публичных
синонимов
Изменение работы
со словарем данных
Oracle
(owner, object_name,
edition_name)
21/27

22. Обновление неверсионируемых
объектов

Блокировка
неверсионируемых объектов
(таблиц, индексов)
при выполнении DDL операций
 Использование EBR совместно
с Online Redefinition
(DBMS_REDEFINITION)

Изменение индексов
(создание, удаление)
затрагивает все editions
 Workaround при помощи
invisible индексов
22/27

23. Обеспечение совместимости версий

Внесение изменений в структуру
или логику использования данных может
нарушить работу предыдущей версии
 Дублирование данных и их синхронизация
при помощи кросс-версионных триггеров
(Cross-edition triggers)
Пример 1
Разделение одной таблицы на «мастер»
и «деталь» (связь один ко многим):



Существующие столбцы таблицы не удаляются
Когда «старая» версия изменяет данные
в основной таблице, то Forward-триггер
заполняет новую таблицу
Когда «новая» версия меняет данные
в подчиненной таблице, то Reverse-триггер
заполняет «старые» столбцы основной
таблицы
23/27

24. Обеспечение совместимости версий

Внесение изменений в структуру или
логику использования данных может
нарушить работу предыдущей версии
 Дублирование данных и их синхронизация
при помощи кросс-версионных триггеров
(Cross-edition triggers)
Пример 2
Изменение набора значений атрибута,
с которым связана логика приложения:



Создается новый столбец, дублирующий
существующий
Каждая версия «видит» свой экземпляр
столбца
Логика преобразования значений атрибута
реализуется в кросс-версионных триггерах
24/27

25. Влияние на разработку и эксплуатацию

Необходимо обеспечивать совместимость нескольких
версий при разработке и тестировании



Если есть изменения в модели данных, несовместимые
с текущей версией
Если есть изменения в логике использования атрибутов
и структур данных
Наличие кросс-версионных триггеров может
замедлять операции изменения данных, в том числе
в уже эксплуатируемой версии


В примере 1 при разделении основной таблицы на две –
вставка в подчиненную таблицу замедляется в два раза
Одновременная эксплуатация нескольких версий
может усложнить процедуры разбора и разрешения
инцидентов
25/27

26. Преимущества решения с EBR

Установка обновлений ПО без остановки
системы
 за счет создания нового edition для обновления

Одновременная работа пользователей
с разными версиями ПО в рамках одного
экземпляра БД и с одним набором
данных
 за счет использования разных editions
и cross-edition triggers

Контролируемое переключение
пользователей между версиями,
в том числе «откат» обновлений
 за счет использования версии по умолчанию
и/или задания версии для отдельного
пользователя
26/27

27. Спасибо за внимание!
Петр Марголис
pmargolis@custis.ru
+7 (495) 772-97-02
27/27