Oracle *

Привет! В этом релизном цикле некоторые улучшения появились ещё в минорных обновлениях. Но, так как о них на Хабре мы не пишем, я расскажу в этом посте обо всём новом с момента предыдущего релиза.

Мы продолжаем цикл статей разработчиков приложений для баз данных — Часть 1. Условная компиляция PL/SQL. Эта статья затронет тему использования Tibero в Java приложениях использующих JDBC и Hibernate, а также фреймворк Spring Roo.

tl;dr В этой статье мы рассмотрим случай, когда лучше переместить самый селективный атрибут из префикса составного индекса в суффикс.

А также рассмотрим, что такое pipeline и как с его помощью select-ить данные уже отсортированными.

В этой статье мы посмотрим, как в двух системах создавать пользовательские агрегатные и оконные (в терминологии Oracle — аналитические) функции. Несмотря на различия в синтаксисе и в целом в подходе к расширяемости, механизм этих функций очень похож. Но и различия тоже имеются.

Надо признать, что собственные агрегатные и оконные функции встречается довольно редко. Оконные функции вообще по каким-то причинам традиционно относят к разряду «продвинутого» SQL и считают сложными для понимания и освоения. Тут бы разобраться с теми функциями, которые уже имеются в СУБД!

Зачем тогда вообще вникать в этот вопрос? Могу назвать несколько причин:

• Хотя оконные функции объективно сложнее обычных агрегатных, но ничего запредельного в них нет; это абсолютно необходимый инструмент для SQL-разработчика. А создание собственной оконной функции, даже совсем простой, позволяет лучше разобраться с тем, как работают стандартные.
  
• Оконные и агрегатные функции — прекрасный способ совместить процедурную обработку с декларативной логикой. В некоторых ситуациях получается выполнить сложные действия, оставаясь в рамках парадигмы решения задачи одним SQL-запросом.
  
• Да и просто интересная тема, а уж тем более интересно сравнить две системы.
  

Пример, на котором будем тренироваться — подсчет среднего, аналог стандартной функции avg для типа numeric (number в Oracle). Мы напишем такую функцию и посмотрим, как она работает в агрегатном и оконном режимах и может ли она вычисляться несколькими параллельными процессами. А в заключение поглядим на пример из реальной жизни.

Продолжаю рассказ о том, как мы делали олимпиаду по SQL. Это продолжение предыдущей статьи, в которую всё просто не уместилось.

Краткое содержание предыдущей серии: прошло два заочных тура олимпиады в декабре 2016 и марте 2017 соответственно, где претенденты на победу прошли жёсткий отбор как с теорией, так и с практикой применения SQL в базах данных Oracle. Далее про третий тур — очный финал олимпиады в Сочи в начале июня 2017 г.

Условная компиляция PL/SQL позволяет избирательно компилировать участки исходного кода в зависимости от условия, как правило связанного со значением пакетной константы. Часто это используется для обеспечения совместимости приложений с разными версиями СУБД.
В декабре 2017 года такая возможность появилась и в Tibero, что позволило обеспечить ещё большую совместимость приложений между Tibero и Oracle.

В самом начале осени 2016 года руководство поставило мне задачу подготовить техническую часть олимпиады по SQL. Обсудив ситуацию с коллегами, в том числе с бывшими, я был ткнут (ткнён?) в статью, где в декларативном стиле на SQL решалась задача по построению кратчайшего выхода из лабиринта. Собрав в одну кучку части запроса и запустив его на настоящей базе, я прошептал "магия!.." и понял, что олимпиаде быть.

Думаю, что типичный читатель Хабра на олимпиадах хоть раз да бывал, но скорее в роли участника, а не организатора. Я тоже бывал на разных, и мне всегда было удивительно, почему на одних олимпиадах интересно, а на других тоска смертная. Могу показать, как выглядит этот театр с другой стороны занавеса, и как я старался, чтобы эта олимпиада оказалась из тех, которые интересные. Интриги, скандалы, расследования — ничего этого не будет. Зато расскажу как готовились задания, что от них ожидали и что получалось в результате.

В Apache Ignite можно определить именованный кеш данных для постоянного хранилища, загрузить в него данные и далее выполнять различные манипуляции с ними.

Можно выполнять операции get/put как c Map, например в java, эти операции имеют название сквозного чтения, записи в постоянное хранилище (write-through and read-through). Т.е. после того как кеш загружен при выполнении операции get объект будет взят их него, а не из базы, а при записи он изменится в кеше и будет записан в хранилище данных. Если при попытке взятия объекта его не будет в кеше он будет вначале в него записан. Понятно что операции чтения уже будут из памяти кеша и очень быстро. Все это актуально для операций get/put. Для других операций поиска, например для поиска объекта не по ключу есть — Query, как быстрее находить данные в кеше?, работа с транзакциями, все это ниже в статье…

Apache Ignite – распределенная база данных в памяти, подобные БД получают распространение и хочется сравнить с тем что уже есть и зарекомендовало себя, например реляционная СУБД Oracle. Ignite имеет широкие возможности распределенных вычислений, также есть поддержка SQL на уровне ANSI-99, в производительности SQL и хочется сделать некоторое сравнение. Настройка БД будет в обоих случаях во многом по умолчанию, в случае Oracle это XE, а в случае Ignite это два узла(node) на одном компьютере. Компьютер i5 7400 (4-ядра) 3.5Ггц, 8Гб ОЗУ, SSD диск.
В качестве тестовых данных буду использовать данные КЛАДР (~223 тыс. записей) в качестве среды выполнения запросов DBeaver в котором настроены два подключения к Ignite и Oracle. И первое что сделаю импортирую данные в таблицы, Данные КЛАДР из DBF переведу в CSV, а затем средствами DBeaver выполню импорт в таблицы.

Всех приветствую. Я представитель отдела по развитию биллинговых систем, в региональном операторе связи. Хочу поделиться опытом обновления Oracle до версии 12c (12.2.0.1)
(Почему-то многие путают процесс апгрейда с миграцией, вот здесь доходчиво расписано когда и в каких случаях употреблять то или иное значение). Все мероприятия происходили в прошлом году.

Организационные мероприятия

С начала года начали организационные подготовительные работы, в первую очередь необходимо было развернуть тестовую зону. Нет, тестовая зона у нас имелась, только Oracle в ней развернут под SUSE. А в промышленной среде Oracle у нас установлен на серверах с платформой IA-64, и HP-UX в качестве ОС, развертывание же HP-UX в виртуальной среде оказалось тем еще квестом — HP-UX в качестве гостевой ОС поддерживает только одна VM — Integrity Virtual Machines, которая должна быть установлена на сервере с той же архитектурой. В итоге решили проводить работы на production standby-db-сервере.

В промышленных системах часто требуется выполнить преобразования данных с использованием pl/sql кода с возможностью обращения к этим данным в sql запросе. Для этого в oracle используются табличные функции.

Мы уже рассказывали о том, почему секционирование баз данных очень важно для производительности DLP-системы и как мы реализовывали его в PostgreSQL. В этой статье речь пойдет об Oracle.

Специфика использования СУБД в DLP-решениях состоит в том, что объем данных прирастает очень быстро. Их невозможно держать в оперативном архиве, и долговременное хранение – это необходимость в компании численностью свыше хотя бы 50 человек. При этом оперативный архив наполняется так быстро, что отдавать информацию в долгосрочный архив приходится раз в 2 недели или чаще. Использование только встроенных средств СУБД требует знаний и опыта. Это главная сложность, и она, в общем-то, очевидна «на берегу».

Кроме того, возникают проблемы, не очевидные сразу. Как вернуть из долгосрочного архива партицию с данными более старой версии приложения и прицепить к более свежей? Что делать, если у них разных формат хранения данных? Что делать, если подключение секции было прервано, и она «зависла» между долговременным и оперативным архивом?

Oracle Executive Chairman и CTO Ларри Эллисон (Larry Ellison) хочет, чтобы глобальную конференцию Oracle Open World 2017, которая прошла в октябре в Сан-Франциско, запомнили именно по этим анонсам. Oracle сегодня выдвигает на первый план обучение машин (machine learning, ML) и искусственный интеллект (artificial intelligence, AI) для облачных сервисов, а также поставку «умных приложений» (smart applications) и решений, управляемых данными (data-driven decisions).

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

Представляю вашему вниманию перевод статьи How SAP Has Quietly Changed Strategy on HANA and Oracle автора Шена Снаппа (Shaun Snapp).

Что в этой статье

• Первоначальный план для HANA
• Последние изменения в политике в отношении Oracle
• Захлебываемся слащавым елеем от SAP маркетинга
• Проблема в отсутствии смущения
• Как SAP это недооценивает
• Будущее HANA ?
• Кто был неправ и кто прав?
• Кто понял это превратно?
• Кто с этим разобрался?
• Deloitte, Accenture, IBM, CapGemini, Infosys — все неправы по поводу HANA

ANTLR — это генератор парсеров, который позволяет создавать парсер по описанию грамматики на одном из основных языков программирования. Он сам написан на java и прекрасно работает с Java.

Пошаговое руководство:

1) Поставить Oracle Java JDK и Intellij Idea, (можно пропустить этот шаг, если они уже поставлены), и запустить Intellij Idea

2) File-Setting-Plugins

В ходе работы DLP-система ежедневно перехватывает огромные массивы информации – это и письма сотрудников, и информация о действиях пользователей на рабочих станциях, и сведения о хранящихся в сети организации файловых ресурсах, и оповещения о несанкционированном выводе данных за пределы организации. Но полезной эта информация будет только в случае, если в DLP реализован качественный механизм поиска по всему массиву перехваченных коммуникаций. С тех пор, как в 2000 году увидела свет первая версия нашего DLP-решения, мы несколько раз меняли механизм поиска по архиву. Сегодня мы хотим рассказать о том, какие технологии мы использовали, какие видели в них преимущества и недостатки, и почему мы от них в итоге отказывались. Возможно, кому-то наш опыт окажется полезен.

Во время миграции из Oracle в PostgreSQL с помощью ora2pg встал вопрос с несоответствием типов данных между разными базами. По умолчанию не все колонки конвертируется правильно, а отсутствие в Oracle Boolean и вовсе порождает неоднозначность – часть колонок нужно перенести как числа, часть как логические значения. В тоже время hibernate знает все о типах данных и может создать эталонную схему.

Итоговый процесс переноса выглядел следующим образом: создание структуры таблиц через ora2pg, исправление структуры по эталонной схеме, перенос данных, конвертация blob и Boolean, добавление отсутствующих в PostgreSQL функций (nvl, nvl2, regexp_substr), создания оставшейся структуры — индексов, view и прочего.

Под катом накопившиеся за время конвертации sql скрипты для полуавтоматической миграции.

Проблематика и назначение:

Периодически Oracle разработчики сталкиваются с проблемой отладки PL/SQL кода, когда код вызывается из веба или среднего слоя(т.е. когда сессия разработчика не совпадает с сессией в которой возникает проблема).

Особенно актуально, если какие-либо проблемы возникают на стороне Web при двухзвенных и трехзвенная схемах взаимодействия БД и Web(ниже пример трехзвенной архитектуры взаимодействия):

Рисунок 1 — Трехзвенная архитектура взаимодействия БД и Web.

Метод решения проблем:

В решение проблем с отладкой PL/SQL кода нам помогут пакеты:

• DBMS_PIPE — Пакет который позволяет отпавлять сообщения(пайпы) между 2мя сессиями БД Oracle.
• DBMS_ALERT — Пакет, который обеспечивает поддержку асинхронных оповещений для различных событий БД Oracle.

Проблематика и назначение:

Периодически Oracle разработчики сталкиваются с проблемой производительности PL/SQL кода. Возникают проблемы с тем, чтобы найти место pl/sql кода, в котором возникают проблемы.

Обычно профилирование pl/sql кода используется, когда необходимо определить проблему производительности в очень большом методе, либо когда у метода много внутренних зависимостей с большим количеством логики, а также нет понимание в каком месте метод код тормозит.

Методы решения проблемы:

В решение проблем с производительность в БД Oracle нам помогут:

• PL/SQL Developer — Популярное IDE для Oracle разработчиков.
• DBMS_PROFILE — Oracle пакет для профилирования (не будет рассматриваться в рамках данной статьи, т.к. информации достаточно на просторах интернета).