Сейчас бесшовные обновления – это одно из главных требований для многих систем, и системы, использующие базы данных Oracle, не являются исключением. В этой статье я расскажу о технологии Edition-based redefinition, которая создана для решения данной проблемы, а также о трудностях, с которыми мы столкнулись в процессе внедрения и использования этой технологии.
Данная статья может пригодиться тем, кто работает с высоконагруженными системами, использующими СУБД Oracle и хочет начать обновлять их, не отключая пользователей.
Начну с того, что мы используем Edition-based redefinition (далее EBR) в одной из банковских систем уже около двух лет и смогли заметить как достоинства, так и недостатки. Технология была внедрена в 2020 как средство процесса внесения изменений в схему данных, позволяющее изменять объекты в БД без вмешательства в работу текущих пользователей.
Целью внедрения EBR является ускорение выхода новых задач на прод, которое достигается тем, что, используя EBR, многие патчи можно устанавливать без Downtime, хотя раньше это было невозможно. Таким образом, мы можем делать установки на тестовые стенды и на прод чаще. Примером могут служить интеграционные пакеты базы данных, которые используются в большом количестве функционала системы. Если раньше установка таких пакетов требовала отключения всех пользователей и перекомпиляцию объектов, то, используя EBR, можно установить его без Downtime на «горячую» базу.
Что же такое EBR?
Edition-based redefinition – это технология баз данных Oracle, позволяющая использовать несколько версий объектов PL/SQL, представлений и синонимов в одной схеме, что позволяет выполнять обновления приложений базы данных без Downtime, при этом не затрагивая работу текущих пользователей.
Чтобы лучше понять как работает эта технология, обратимся к условному пакету CONTRACT, который агрегирует функции работы с договорами в какой-либо системе. В базе, где используется EBR, может одновременно хранится несколько различных пакетов CONTRACT, которые будут относиться к разным редакциям.
Редакция или Edition - это, по сути, метка версии, которую можно назначить всем редактируемым (Editionable) объектам в схеме. Начиная с версии 11.2 в Oracle можно заводить разные редакции (editions), каждую со своим набором хранимых объектов и возможностью переключаться между ними. Редакции зависят друг от друга, а именно находятся в отношениях родитель (предок)-потомок. Причём, каждая редакция может иметь только одного прямого потомка и одного прямого родителя. Все редакции являются потомками редакции «ORA$BASE», которая создается при включении EBR. На рис. 1. приведен пример редакций на базе. Как можно увидеть, изначально была редакция «ORA$BASE», от которой была создана редакция «RT20_1» в качестве потомка, а далее, уже от неё редакция «RT20_2» и т.д. То есть, последовательность редакций имеет линейную структуру. Одна из редакций является редакцией по умолчанию, т.е. это та редакция, к которой подключается пользователь, если он не указал редакцию специально.
При создании новой редакции на основе старой, она наследует все определенные в родителе объекты. На практике, в целях оптимизации, Oracle копирует объекты в новую редакцию только при их изменении, данная стратегия носит название copy-on-change. Процесс копирования объекта в наследуемую редакцию называется актуализацией, по факту - это пересоздание данного объекта в дочерней редакции. Если объект актуализирован в текущей редакции, при его вызове будет загружена текущая версия. Если объект не актуализирован в текущей редакции, при его вызове будет загружена версия из последней редакции, где он актуализирован. Актуализировать объект можно скомпилировав его с определенными опциями: ALTER ... COMPILE REUSE SETTINGS.
Рассмотрим пример на рис.2. Пакет CONTRACT определен в редакциях ORA$BASE, RT20_1 и RT20_3, а в редакции RT20_2 используется пакет CONTRACT из ближайшей родительской редакции, т.е. из редакции RT20_1. Для того чтобы актуализировать пакет CONTRACT в редакции RT20_2 нужно выполнить в данной редакции команду ALTER CONTRACT COMPILE REUSE SETTINGS.
Не все объекты баз данных Oracle можно создавать в разных редакциях и версионировать. Некоторые объекты существуют в единственном экземпляре и используются для всех редакций одновременно, такие объекты называются noneditionable. Примером такого объекта являются таблицы, поэтому при модификации таблиц некоторые объекты в некоторых редакциях могут инвалидироваться. Для решения этой проблемы обычно используются Editionable views, подробнее я расскажу во второй части этой статьи. Какие же объекты являются Editionable? Это все объекты PL/SQL, а также Views и Synonym, см. рис. 3.
Теперь рассмотрим пример установки патча с EBR. Представьте, что Петр, Инна и Иван работают в системе, использующей БД Oracle, в редакции T20_1_1, которая на данный момент является редакцией по умолчанию, а Семен и Полина на обеде, см. рис. 4. На рисунке CONTRACT, PERSON, CLIENT - примеры пакетов.
Начинается установка патча T20.1.2, и создается новая редакция T20_1_2, см. рис. 5.
В патче изменяется только один файл PERSON, для которого создается новая версия в редакции T20_1_2, а остальные объекты будут использоваться из родительской редакции, см. рис. 6.
После деплоя патча, редакция T20_1_2 устанавливается редакцией по умолчанию, и, когда Семен и Полина возвращаются с обеда, они подключаются уже к вновь созданной редакции, см. рис. 7.
У Ивана завершается формирование отчета, и он подключается к редакции T20_1_2, см. рис. 8.
Через некоторое время и остальные подключаются к новой редакции, и уже никто не работает в старой, см. рис. 9.
Таким образом, пользователь подключается к БД к определенной редакции и работает только с ее объектами, и, в то же самое время, другие пользователи могут менять объекты в других редакциях, никак не затрагивая первого. Обобщив информацию, можно сказать, что в общем плане установка происходит следующим образом:
1) пользователи работают в редакции E_OLD_EDITION;
2) создается новая редакция E_NEW_EDITION, в ней создаются/меняются/удаляются объекты, не влияя на существующих пользователей;
3) новая редакция E_NEW_EDITION становится общей редакцией БД по умолчанию;
4) все пользователи переключаются на новую редакцию.
Может сложиться мнение, что EBR - это чудесная технология, которая позволяет обновлять БД, не создавая никаких проблем и дает возможность для быстрого отката к предыдущей редакции, в случае сложных ошибок, но, к сожалению, это не соответствует действительности. Проблемы возникают на разных этапах. Об этом читайте в следующей части, мы скоро ее выложим:)
Начало отличное, ждем продолжения.
Здравствуйте.
А где продолжение статьи?
"Об этом читайте в следующей части, мы скоро ее выложим:)" - уже почти год прошел!
Обещание надо держать, не так ли?!