Привет! Меня зовут Антонина, я Oracle-разработчик IT-подразделения «Спортмастер Лаборатория».
Я работаю здесь всего два года, но благодаря дружному коллективу, сплоченному коллективу, системе наставничества и корпоративному обучению я накопил ту критическую массу, когда хочется не только потреблять знания, но и делиться ими.
мой опыт. 
Итак, переопределение на основе выпуска.
Почему у нас вообще есть такая потребность в изучении этой технологии, какое отношение к ней имеет термин «высокая доступность» и как Edition-Based Redefinition поможет нам, разработчикам Oracle, сэкономить время? Какое решение предлагает корпорация Oracle? Что происходит на заднем плане при использовании этой технологии, с какими проблемами мы столкнулись.
В общем, вопросов много.
Я постараюсь ответить на них двумя постами по теме, и первый из них уже под катом.
Каждая команда разработчиков при создании своего приложения стремится сделать максимально доступный, максимально отказоустойчивый и максимально надежный алгоритм.
Почему мы все к этому стремимся? Наверное, не потому, что мы такие хорошие и хотим выпустить крутой продукт. Точнее, не только потому, что нам с тобой так хорошо.
Это также важно для бизнеса.
Несмотря на то, что мы можем написать крутой алгоритм, покрыть его модульными тестами и увидеть, что он отказоустойчив, у нас (разработчиков Oracle) всё равно есть проблема — мы столкнулись с необходимостью апгрейда наших приложений.
Например, наши коллеги по системе лояльности вынуждены делать это по ночам.
Если бы это произошло на лету, пользователи увидели бы картинку: «Извините, пожалуйста!», «Не грустите!», «Подождите, у нас обновления и технические работы».
Почему это так важно для бизнеса? А все очень просто – бизнес уже давно включил в свои убытки не только потери каких-то реальных товаров, материальных ценностей, но и потери от простоя инфраструктуры.
Например, по данным журнала Forbes, еще в 13 году одна минута простоя сервиса Amazon стоила $66 тысяч.
То есть за полчаса ребята проиграли почти 2 миллиона долларов.
Понятно, что для среднего и малого бизнеса, а не для такого гиганта, как Amazon, эти количественные характеристики будут гораздо меньше, но тем не менее в относительном выражении это все равно остается значимой оценочной характеристикой.
Итак, нам необходимо обеспечить высокую доступность нашего приложения.
Какие потенциально опасные места есть у разработчиков Oracle для такой доступности? Прежде всего, наше оборудование может выйти из строя.
Мы как разработчики не несем за это ответственности.
Сетевые администраторы должны обеспечить работоспособность сервера и структурных объектов.
Мы ведем вас к обновлению программного обеспечения.
Опять же, плановые обновления программного обеспечения можно разделить на два класса.
Или у нас происходит изменение какой-то инфраструктуры, например, обновляется операционная система, на которой работает сервер.
Либо мы решили перейти на новый релиз Oracle (было бы хорошо, если бы успешно перешли на него :)).
Либо второй класс, это то, что нас больше всего волнует - это обновление объектов приложение, которое мы разрабатываем.
Опять же, это обновление можно разделить еще на два класса.
Либо меняем какие-то физические характеристики этого объекта (думаю, что каждый разработчик Oracle иногда сталкивался с тем, что у него падал индекс, и ему приходилось перестраивать индекс на лету).
Или, допустим, мы ввели в наши таблицы новые разделы, то есть никакой остановки не произойдет. И самое проблемное место — изменение логики приложения.
Так какое же отношение к этому имеет переопределение на основе выпуска? И эта технология как раз о том, как обновлять приложение онлайн, на лету, не влияя на пользовательский опыт. 
Какие требования выдвигаются к этому самому онлайн-обновлению? Мы должны сделать это незаметно для пользователя, то есть все должно оставаться в рабочем состоянии, все приложения.
При условии, что у нас может возникнуть ситуация, когда пользователь сел, начал работать и вдруг вспомнил, что у него срочная встреча или ему нужно отвезти машину в сервисный центр.
Он встал и выбежал из-за своего рабочего места.
А в это время мы как-то обновили наше приложение, изменилась логика работы, к нам уже подключились новые пользователи, и данные стали обрабатываться по-новому.
Итак, нам необходимо в конечном итоге обеспечить обмен данными между исходной версией приложения и новой версией приложения.
Это два требования, которые выдвигаются к онлайн-обновлениям.
Что предлагается в качестве решения? Начиная с версии 11.2 Release Oracle появляется технология переопределения на основе выпуска и вводятся такие понятия, как издание, редактируемые объекты, представление редактирования, триггер между редакциями.
Мы позволили себе такой перевод как «версионирование».
В целом технологию EBR с некоторой натяжкой можно было бы назвать версионированием объектов СУБД внутри самой СУБД.
Так что же такое Edition как сущность? Это своего рода контейнер, внутри которого можно изменять и устанавливать код. Внутри своей сферы, внутри своей версии.
В этом случае данные будут изменены и записаны только в те структуры, которые видны в текущей редакции.
За это будут отвечать представления управления версиями, и их работу мы рассмотрим далее.
Примерно так технология выглядит снаружи.
Как это работает? Для начала на уровне кода.
У нас будет исходное приложение версии 1, в котором есть некоторые алгоритмы обработки наших данных.
Когда мы понимаем, что нам нужно обновиться, при создании новой редакции происходит следующее: все объекты, обрабатывающие код, наследуются в новую редакцию.
Причем в этой вновь созданной песочнице мы можем развлекаться как захотим, незаметно для пользователя: мы можем изменить работу каких-либо функций, процедур; изменить способ работы пакета; мы можем даже отказаться использовать объект. Что случится? Исходная версия остается неизменной, она остается доступной пользователю и доступен весь функционал.
В той версии, которую мы создали, в новой редакции те объекты, которые не были изменены, остались неизменными, то есть унаследованными от исходной версии приложения.
В блоке, который мы затронули, в новой версии обновляются объекты.
И естественно, когда мы удаляем объект, он нам недоступен в новой версии нашего приложения, но при этом остается работоспособным в исходной версии.
Вот как просто это работает на уровне кода.
Что происходит со структурами данных и при чем тут версионирование? 
Поскольку под структурами данных мы подразумеваем таблицу, а версионное представление — это, по сути, оболочка (я назвал ее этологическим «смотрящим» за нашей таблицей), представляющая собой проекцию на исходные столбцы.
Когда мы с вами понимаем, что нам нужно изменить способ работы нашего приложения, и, скажем, как-то добавить столбцы в таблицу или даже запретить их использование, мы создаем новое представление управления версиями в нашей новой версии.
Соответственно, в нем мы будем использовать только тот набор столбцов, который нам нужен, который и будем обрабатывать.
Итак, в исходной версии приложения данные записываются в набор, определенный в этой области.
Новое приложение будет выполнять запись в набор столбцов, определенный в его области действия.
Структуры понятны, но что происходит с данными? И как все это связано между собой, у нас были данные, хранящиеся в исходных структурах.
Когда мы понимаем, что у нас есть некий алгоритм, позволяющий преобразовать данные из исходной структуры и разложить эти данные в новую структуру, этот алгоритм можно поставить в так называемые триггеры кросс-версий.
Они как раз и направлены на то, чтобы увидеть структуры из разных версий приложения.
То есть, если такой алгоритм существует, мы можем повесить его на стол.
В этом случае данные будут преобразованы из исходных структур в новые, и за это будут отвечать прогрессивные форвардные триггеры.
При условии, что нам необходимо обеспечить перенос данных в старую версию, опять же, на основе какого-то алгоритма, за это будут отвечать обратные триггеры.
Что произойдет, когда мы решим, что наша структура данных изменилась и мы готовы работать в параллельном режиме как для старой версии приложения, так и для новой версии приложения? Мы можем просто инициализировать заполнение новых структур каким-нибудь холостым обновлением.
После этого обе наши версии приложения становятся доступны для использования пользователем.
Функционал остаётся для старых пользователей от старой версии приложения, для новых пользователей функционал будет от новой версии приложения.
Когда мы поняли, что все пользователи старого приложения отключились, эту версию можно было скрыть от использования.
Структура данных могла даже измениться.
Мы помним, что наше представление управления версиями в новой созданной версии будет просматривать только набор столбцов 1, 3,4,5. Ну и соответственно, если эта структура нам не нужна, мы можем ее удалить.
Вот примерно как это работает. 
Какие ограничения наложены? То есть молодец Оракул, отличный Оракул, отличный Оракул: классную вещь придумали.
Первое ограничение на данный момент — это объекты версионного типа, это объекты PL/SQL, то есть процедуры, пакеты, функции, триггеры и так далее.
Синонимы версионируются, а представления версионируются.
Что не версионируется и никогда не будет версионироваться, так это таблицы и индексы, материализованные представления.
То есть в первом варианте мы меняем только метаданные и можем хранить столько их копий, сколько захотим.
по сути, ограниченное количество копий этих метаданных, но об этом позже.
Второе касается пользовательских данных, и их репликация потребует большого дискового пространства, что не логично и очень дорого.
Следующее ограничение заключается в том, что объекты схемы будут иметь полное управление версиями тогда и только тогда, когда они принадлежат авторизованному пользователю, имеющему версию.
По сути, эти разрешения для пользователя — всего лишь какая-то заметка в базе данных.
Вы можете предоставить эти разрешения с помощью обычной команды.
Но учтите, что это действие необратимо.
Поэтому давайте не будем сразу засучить рукава и набирать всё это на продакшен-сервере, а сначала протестируем.
Следующее ограничение заключается в том, что неверсионные объекты не могут зависеть от версионных.
Что ж, это вполне логично.
Как минимум, мы не будем понимать, какую редакцию, какую версию объекта смотреть.
Я хотел бы акцентировать внимание на этом моменте, потому что нам пришлось побороться с этим моментом.
Дальше.
Представления управления версиями принадлежат владельцу схемы, владельцу таблицы и являются уникальными в каждой версии.
По своей сути представление управления версиями представляет собой обертку таблицы, поэтому понятно, что оно должно быть единственным в каждой версии приложения.
Еще важно то, что количество версий в иерархии может быть 2000. Скорее всего, это связано с тем, что словарь не перегружается.
Я изначально сказал, что объекты наследуются при создании новой редакции.
Сейчас эта иерархия выстроена исключительно линейно – один родитель, один дочерний элемент. Возможно, будет какая-то древовидная структура, некоторые предпосылки к этому я вижу в том, что можно задать команду создания версии как наследницы от конкретной редакции.
На данный момент это строго линейная иерархия, а количество звеньев в этой созданной цепочке — 2000. Понятно, что при частых обновлениях нашего приложения это число может быть исчерпано или превышено, но начиная с 12-го релиза Oracle крайние редакции, созданные в этой цепочке, могут быть сокращены при условии, что они больше не будут использоваться.
Надеюсь, теперь вы имеете примерное представление о том, как это работает. Если вы решите – «Да, мы хотим это прикоснуться» – что нужно сделать, чтобы перейти на использование этой технологии?
Прежде всего, вам необходимо определить стратегию использования.
О чем это? Поймите, как часто меняются структуры наших таблиц, нужно ли нам использовать представления управления версиями, особенно нужны ли нам триггеры кросс-версий для обеспечения изменения данных.
Или мы будем версионировать только наш код PL/SQL. В нашем случае при тестировании мы увидели, что наши таблицы все еще меняются, поэтому, вероятно, мы также будем использовать представления управления версиями.
Далее, конечно же, выбранной схеме предоставляются права управления версиями.
После этого переименовываем таблицу.
Почему это делается? Просто чтобы защитить наши объекты кода PL/SQL от изменений таблиц.
Мы решили добавить в конец наших таблиц острый символ, учитывая ограничение в 30 символов.
После этого создаются представления управления версиями с исходными именами таблиц.
И они уже будут использоваться внутри кода.
Важно, чтобы в первой версии, к которой мы переходим, представление управления версиями представляло полный набор столбцов исходной таблицы, поскольку объекты кода PL/SQL могут обращаться ровно ко всем этим столбцам.
После этого переносим DML-триггеры из таблиц в версионные представления (да, версионные представления позволяют нам прикреплять к ним триггеры).
Возможно, мы отзовем гранты у таблиц и выдадим их вновь созданным представлениям.
По идее, всех этих пунктов достаточно, осталось только перекомпилировать PL/SQL-код и зависимые представления.
И-и-и-и.
Естественно, тесты, тесты и еще раз тесты.
Почему тесты? Это не могло быть так просто.
О чем мы споткнулись? Речь пойдет именно об этом мой второй пост .
Теги: #Администрирование баз данных #Высокая производительность #oracle #проектирование и рефакторинг #Sportmaster #sportmaster lab #Переопределение на основе редакций #EBR #EBR
-
Как На Самом Деле Работают Z-Индексы
19 Oct, 24
