Использование

Edition Based Redefinition

для обновления приложений,

доступных 24/7

Петр Марголис

Архитектор

Oracle Database Forum, Москва

19 февраля 2014

План

О компании CUSTIS

Приложение

Цели и требования

Варианты архитектуры решения

Основные принципы Oracle EBR

Перевод приложения на EBR

Результат

2/27

О компании CUSTIS

Специализация – заказная разработка,

бережное внедрение и сопровождение

на полном жизненном цикле масштабных

учетно-аналитических систем

Год основания – 1996

Количество сотрудников > 200

Ключевые клиенты: Банк России,

Газпромбанк, ГК «Спортмастер»,

ЕИРКЦ г. Астрахани, ЕРКЦ г. Саратова

3/27

Приложение

Банковская учетная система

Двухзвенная архитектура

Сервер – Oracle DB 11gR2, бизнес-логика на PL/SQL

«Тонкий клиент» – отображение и ввод данных

Интеграция с другими системами

4/27

Цели и задачи

Централизация учета в многофилиальном

банке

Филиалы располагаются в различных часовых

поясах, поэтому приложение используется

в режиме 24/7

Снижение операционных рисков

при обновлении системы во время

эксплуатации

Поэтапное внедрение изменений в различных

филиалах с возможностью их отмены

5/27

Технические требования

Возможность установки обновлений ПО

без остановки работы системы

Параллельная эксплуатация нескольких

версий ПО, работающих с одними данными

Возможность перевода пользователей

на новую версию ПО или «отката»

к предыдущей версии

6/27

Варианты архитектуры решения

Распределенная

Централизованная

7/27

Распределенная архитектура

Повышение надежности: отказ

одного узла не приводит

к остановке системы

В каждой временной зоне есть

возможность выделить

технологическое окно

для установки обновлений

Необходимость

администрировать множество

экземпляров ПО

Необходимость синхронизации

изменений и разрешения

конфликтов

Нет механизма «отката»

обновлений

8/27

Централизованная архитектура

Уменьшение количества

экземпляров системы,

которые необходимо

администрировать

Гарантированная

согласованность данных

Отсутствие технологических

окон для установки

обновлений

Нет механизма поэтапного

обновления ПО и «отката»

обновлений

9/27

Edition-based redefinition (EBR)

Входит в Enterprise Edition, начиная с 11gR2

Позволяет выполнять изменения

(redefinition) объектов, не затрагивая

существующие версии (editions) объектов

Позволяет управляемо переключать

пользователей на различные версии ПО

10/27

Версионируемость объектов

Версионируемые

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

Перевод приложения на EBR

Подготовительные шаги

Инструментарий администратора

Доработка приложения

Обновление неверсионных объектов

Обеспечение совместимости версий

Изменения в модели безопасности

Влияние на разработку и эксплуатацию

12/27

Подготовительные шаги

1. Включение версионирования

для набора схем

13/27

Подготовительные шаги

1. Включение версионирования

для набора схем

2. Создание версионирующих

представлений для всех таблиц

14/27

Подготовительные шаги

1. Включение версионирования

для набора схем

2. Создание версионирующих

представлений для всех таблиц

3. Перевод кода PL/SQL

и клиентских приложений

на использование

версионирующих представлений

15/27

Подготовительные шаги

1. Включение версионирования

для набора схем

2. Создание версионирующих

представлений для всех таблиц

3. Перевод кода PL/SQL

и клиентских приложений

на использование

версионирующих представлений

4. «Перевешивание» триггеров

на версионирующие представления

5. Выдача прав другим схемам

на версионирующие представления

16/27

Инструментарий администратора

Доработка инструментария

установки обновлений

Создание нового edition перед

изменением объектов

17/27

Инструментарий администратора

Доработка инструментария

установки обновлений

Создание нового edition перед

изменением объектов

18/27

Инструментарий администратора

Доработка инструментария

установки обновлений

Создание нового edition перед

изменением объектов

19/27

Инструментарий администратора

Доработка инструментария

установки обновлений

Создание нового 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

Доработка приложения

Неверсионные объекты

не могут ссылаться

на версионные

Появляются новые типы

объектов

и изменяются структуры

Расширяется набор

атрибутов, задающих

уникальность объектов

(owner, object_name,

edition_name)

Отказ

от использования

публичных

синонимов

Изменение работы

со словарем данных

Oracle

21/27

Обновление неверсионируемых

объектов

Блокировка

неверсионируемых объектов

(таблиц, индексов)

при выполнении DDL операций

Использование EBR совместно

с Online Redefinition

(DBMS_REDEFINITION)

Изменение индексов

(создание, удаление)

затрагивает все editions

Workaround при помощи

invisible индексов

22/27

Обеспечение совместимости версий

Внесение изменений в структуру

или логику использования данных может

нарушить работу предыдущей версии

Дублирование данных и их синхронизация

при помощи кросс-версионных триггеров

(Cross-edition triggers)

Пример 1

Разделение одной таблицы на «мастер»

и «деталь» (связь один ко многим):

Существующие столбцы таблицы не удаляются

Когда «старая» версия изменяет данные

в основной таблице, то Forward-триггер

заполняет новую таблицу

Когда «новая» версия меняет данные

в подчиненной таблице, то Reverse-триггер

заполняет «старые» столбцы основной

таблицы

23/27

Обеспечение совместимости версий

Внесение изменений в структуру или

логику использования данных может

нарушить работу предыдущей версии

Дублирование данных и их синхронизация

при помощи кросс-версионных триггеров

(Cross-edition triggers)

Пример 2

Изменение набора значений атрибута,

с которым связана логика приложения:

Создается новый столбец, дублирующий

существующий

Каждая версия «видит» свой экземпляр

столбца

Логика преобразования значений атрибута

реализуется в кросс-версионных триггерах

24/27

Влияние на разработку и эксплуатацию

Необходимо обеспечивать совместимость нескольких

версий при разработке и тестировании

Если есть изменения в модели данных, несовместимые

с текущей версией

Если есть изменения в логике использования атрибутов

и структур данных

Наличие кросс-версионных триггеров может

замедлять операции изменения данных, в том числе

в уже эксплуатируемой версии

В примере 1 при разделении основной таблицы на две –

вставка в подчиненную таблицу замедляется в два раза

Одновременная эксплуатация нескольких версий

может усложнить процедуры разбора и разрешения

инцидентов25/27

Преимущества решения с EBR

Установка обновлений ПО без остановки

системы

за счет создания нового edition для обновления

Одновременная работа пользователей

с разными версиями ПО в рамках одного

экземпляра БД и с одним набором

данных

за счет использования разных editions

и cross-edition triggers

Контролируемое переключение

пользователей между версиями,

в том числе «откат» обновлений

за счет использования версии по умолчанию

и/или задания версии для отдельного

пользователя26/27

Спасибо за внимание!

Петр Марголис

pmargolis@custis.ru

+7 (495) 772-97-02

27/27