Использование Edition Based Redefinition для обновления приложений, доступных 24/7

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

Transcript

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. Доработка приложения  Неверсионные объекты не могут ссылаться на версионные  Появляются новые типы объектов и изменяются структуры  Расширяется набор атрибутов, задающих уникальность объектов (owner, object_name, edition_name) Отказ от использования публичных синонимов Изменение работы со словарем данных Oracle 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