Использование Edition Based Redefinition для обновления...
-
Upload
custis -
Category
Technology
-
view
409 -
download
4
description
Transcript of Использование Edition Based Redefinition для обновления...
Использование
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
Спасибо за внимание!
Петр Марголис
+7 (495) 772-97-02
27/27