Два года успешного использования Edition-Based Redefiniton в базах Oracle

    Хранимый код в базе? Не смешите, на дворе 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 пришлось придумать способ межверсионной трансформации как самих таблиц, так и данных в них.

    Сразу оговоримся, что наши разработчики используют EBR только для представлений (view) и PL/SQL кода, и не используют для таблиц. Предметная область хорошо изучена и структуры данных вполне стабильны. В течение года столбцы в горячих таблицах менялись или добавлялись от силы раз пять, при этом изменений кода было в десятки раз больше.

    Приложение


    Наше Java-приложение умеет само переключаться на использование новой версии PL/SQL кода. Текущий edition можно извлечь из базы таким нехитрым запросом:

    select property_value  
    from database_properties 			 
    where property_name = 'DEFAULT_EDITION'
    

    Приложение хранит это значение и регулярно опрашивает базу, не изменилось ли оно.

    Успешный релиз новой версии PL/SQL кода выполняет команду вида

    alter database default edition = ED_1180_23185307 

    а приложение, узнав, что edition изменился, в подходящий момент выполняет команду вида

    alter session set edition = ED_1180_23185307 
    и тем самым переключается на использование новой версии хранимого кода.

    Теоретически возможен и откат PL/SQL кода на предыдущую версию – для этого надо выполнить команду alter database с установкой предыдущего edition, а приложение должно на него переключиться.

    Баги


    СУБД Oracle внутри крайне сложна, в её оптимизацию и развитие вложено столько человеко-лет, что любые новые возможности в её ядре не проходят безболезненно для остального функционала. Речь конечно же идёт о багах и устраняющих их патчах. EBR был вовсе не исключением, а, наоборот, существенным возмутителем спокойствия. Скажем так: без техподдержки обойтись невозможно.

    К сожалению, отдельного списка патчей, устраняющих связанные с EBR баги, Oracle не ведёт. Однако Oracle активно использует EBR в одной из своих популярных ERP-систем – Oracle E-Business Suite (OEBS). Поэтому можно взять набор патчей, который Oracle рекомендует к установке на базу OEBS, и установить на вашу базу те из них, которые потенциально наиболее вероятны для вашего приложения. Найти его можно на сайте поддержки Oracle в Section 3 документа Oracle E-Business Suite Release 12.2: Consolidated List of Patches and Technology Bug Fixes (Doc ID 1594274.1)

    Подводные камни


    При работе с Oracle Edition-Based Redefinition мы нашли четыре недостатка:

    1. Ограничение на число editions, равное 2000. Со скоростью 2 релиза в неделю мы исчерпаем их за 20 лет. Надеемся, к тому времени Oracle сподобится-таки убрать это ограничение.
    2. Плоская, а не древовидная структура editions, 1 parent <–> 1 child. Нам это пока что никак не мешает.
    3. Не-версионируемые (non-editioned) объекты не могут ссылаться на версионируемые (например, в версии 11g такие объекты, как materialized view, являются non-editioned и не могут ссылаться на editioned view).
    4. Специфика в раздаче прав на версионируемый код.

    На последнем пункте хочется остановиться поподробнее, так как этот эффект описан крайне скудно.

    Дело в том, что выдача прав на версионируемый объект, последний раз изменявшийся в каком-либо предыдущем edition, копирует этот объект в текущий edition, со всеми уже знакомыми нам симптомами перекомпиляции и, если не повезет, зависаниями на словарной блокировке library cache pin. По всей видимости, это связано с внутренней реализацией editioned схем в БД.

    Поэтому процедуру раздачи прав пришлось слегка изменить: сначала мы находим edition, в котором искомый объект был изменен последний раз, устанавливаем этот edition в нашей сессии с помощью вышеописанной команды alter session, и лишь после этого выдаем нужные права.

    Как говорится, не баг 26654363, а expected behavior. Что ж, обходной путь не слишком трудозатратен и с ним в подавляющем большинстве случаев можно ужиться.

    Итог проекта: минус 16 часов планового простоя в год

    99.8% -> 99.98%

    P.S. Мы ищем DBA и разработчиков БД!

    • +11
    • 1,6k
    • 4
    QIWI 91,51
    Ведущий платёжный сервис нового поколения в России
    Поделиться публикацией
    Комментарии 4
    • 0
      В процентах все выглядит красиво!
      А вот что получилось в часах: с 17,52 часов до 1,752 часов в год. Или примерно 17,28 секунд простоя каждый день. Как по мне так это все равно много для такой большой компании.
      • 0
        Приведите пример у кого меньше простой, при сопоставимых масштабах бизнеса.
      • +2
        Цитата:
        «К сожалению, отдельного списка патчей, устраняющих связанные с EBR баги, Oracle не ведёт. „
        Т.е. патчи EBR для базы не включаются в ежеквартальные выпуски патчсетов или как это понимать?
        • 0
          Точный ответ на этот вопрос находится в компетенции Oracle, но мои наблюдения такие: если ваша политика установки патчей основана на PSU — на данный момент нет, не включаются. Если ваша политика патчей основана на Bundle Patch — какая-то часть, возможно, и включена, но достоверно проверить это можно лишь сравнивая списки багов в самом Bundle Patch и в указанном документе.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое