Хранимый код в базе? Не смешите, на дворе 2017 год!

В этом году бренду QIWI исполнилось 10 лет. За это время в нашей основной транзакционной базе накопилось более чем 130 тысяч строк хранимого PL/SQL кода. На Хабре регулярно встречаются статьи о том, как различные команды разработчиков категорически не используют хранимый код в БД, стараясь убрать излишнюю нагрузку с БД и таким образом удешевить систему. По этой теме можно долго дискутировать, и такая точка зрения опровергается, например, вот в этом видео.

Что бесспорно — хранимый PL/SQL код традиционно имел один существенный минус: релиз PL/SQL программы требовал остановки сервиса, поскольку процесс компиляции этого кода должен был получить эксклюзивную блокировку в словаре БД (так называемый library cache pin). Не вовремя запущенная случайная рекомпиляция могла подвесить всю систему. Приходилось регулярно выделять технические окна для релиза PL/SQL кода. Заверенные скриншоты жалоб наших возмущённых клиентов, попавших в такие окна, бережно хранятся в наших архивах. Однако не прошло и 20 лет от создания PL/SQL, как Oracle этот недостаток если не устранил полностью, то существенно смягчил.

Welcome to Oracle Edition-Based Redefinition

Мы не будем приводить детальные примеры кода с использованием Edition-Based Redefinition, а опишем несколько ключевых пунктов проекта по его внедрению. С некоторой натяжкой этот механизм, который принято сокращать до EBR, можно считать системой контроля версий объектов БД внутри самой БД. Теперь приложения способны работать с разными версиями одних и тех же процедур, пакетов и представлений. Однако в БД, кроме кода, есть еще и структуры данных в виде таблиц, и Oracle пришлось придумать способ межверсионной трансформации как самих таблиц, так и данных в них.

Привет! Меня зовут Антонина, я Oracle-разработчик IT-подразделения «Sportmaster Lab». Работаю тут всего два года, но благодаря дружной команде, сплоченному коллективу, системе наставничества, корпоративному обучению, накопилась та самая критическая масса, когда хочется не просто потреблять знания, но и поделиться своим опытом.



Итак, Edition-Based Redefinition. Почему у нас вообще возникла такая необходимость в изучении данной технологии, причем здесь термин «высокая доступность» и как Edition-Based Redefinition поможет нам как Oracle-разработчикам экономить время?

Что предложено в качестве решения корпорацией Oracle? Что же творится на задворках при применении данной технологии, с какими проблемами мы столкнулись… В общем, вопросов много. Ответить на них я постараюсь в двух постах по теме, и первый из них — уже под катом.

Привет! Как и обещала в предыдущем посте про Edition-Based Redefinition — вот вторая часть.



Итак, с чем мы работаем? Наш основной production сервер — это Oracle 12С, Enterprise Edition. И, что важно отметить, на нем работает несколько десятков приложений одновременно. Почему мы заостряем на этом внимание? Технология относительно новая, она не совсем хорошо обкатана. И было бы нелогичным переводить на нее сразу какие-то критичные системы. Поэтому для себя решили, что будем потихоньку идти от менее критичных систем к более критичным. Соответственно, следующая проблема, которую нам необходимо было понять: как работать c технологией EBR и как организовать интеграцию в той ситуации, когда у нас одна схема версионирована, а другая — нет. В 12 версии Oracle, как оказалось, можно создавать неверсионные объекты, неверсионированные пакеты, неверсионированные представления в версионированной схеме для организации той самой интеграции.