Oracle *

 
За основную часть перехода информационных систем с Oracle на PostgreSQL часто отвечают инструменты автоматической конвертации. Но среди гигантского объёма кода, покрываемого такими решениями, есть и исключительные истории, с которыми приходится импровизировать. В таких случаях первым делом, конечно, необходимо локализовать проблему, установить её причину и, чтобы подобрать правильное решение, подумать, нет ли аналогичных реальных или вымышленных ситуаций, которые могли бы иметь похожую природу. После этого обычно приходится рефакторить оригинальный код на Oracle, дорабатывать процессы конвертации и грамматику или реализовывать на PostgreSQL не имеющую аналогов функциональность Oracle. Однажды нам бросил вызов, на первый взгляд, примитивный запрос с ошибкой, для решения которой пришлось проводить целое расследование.

Этим небольшим постом хотелось бы развеять одно недоразумение, связанное с анализом AWR баз данных, работающих на Oracle Exadata. Почти 10 лет я постоянно сталкиваюсь с вопросом: каков вклад Exadata Software в производительность? Или с использованием новообразованных слов: насколько «экзадатится» работа той или иной базы данных?

Описание предметной области

Иногда возникает задача получения отчета на рабочем месте клиента без использования интерактивного средства взаимодействия в виде браузера.

Во времена Oracle Reports подобная задача решалась через применение утилиты rwclient. Что можно применить для подобного в Oracle BIEE? — используем предоставленный API REST-интерфейс для Oracle BI Publisher:

Хорошо известна шутливая истина, что любая действующая программа устарела. Действительно, имея дело с программным продуктом, всегда надо быть готовым к тому, что в каком-то обозримом будущем он станет историей, о которой будут помнить только страницы Википедии. По-видимому, вплотную к этому подошла довольно популярная в былые времена технология java-апплетов.

Действительно, основное, о чем предупреждалось в документе "Oracle Java SE Support Roadmap" уже свершилось: с релизом Java 8 завершилась поддержка технологии Java Plugin в составе среды Java Runtime Environment, и c апреля 2019 года корпорация Oracle прекратила активную поддержку технологии во всех новых релизах виртуальной машины. Существенным следствием завершения поддержки Java Plugin является завершение активной поддержки тесно взаимосвязанной с Java Plugin технологии апплетов. Все выпускаемые обновления JDK 8 будут иметь в своем составе компоненты Java Plugin и апплетов, для которых корпорацией будет обеспечиваться «остаточный» уровень поддержки Sustained Support (Note 2511148.1: "Java SE 8 End of Java Plugin Support").

Для чего вообще нужен глоссарий, если есть словари?

Всем, привет!

В статье я хотел бы рассказать об одном из подходов к логированию приложения, который сильно помогал мне и коллегам при отладке, поиске ошибок и анализе проблем производительности. Про необходимость логирования было написано множество хороших статей в том числе и на Хабре, поэтому здесь нет большого смысла повторяться. Я начинал карьеру в IT с Oracle и изучал эту БД по книгам главного эксперта — Тома Кайта. Мне запомнилась его фраза по поводу логирования из книги "Effective Oracle by Design":

Instrumentation is not overhead. Overhead is something you can remove without losing much benefit. Removing (or not having) instrumentation takes away considerable functionality. You wouldn’t need to do this if your systems never break, never need diagnostics, and never suffer from performance issues. If that is true, you don’t need to instrument your system (and send me your email address, because I have a job offer for you).

С работой над Oracle проектами всё и началось.

Зачем переносить данные

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

Я решил изучить процесс миграции данных, изучая то, как реализовать пожелания конкретного заказчика, а также из практического любопытства, теперь я пробую перенести небольшую схему около 15 Гбайт с Oracle 11.2.0.4 на Linux Redhat 6.8 в Postgres 9.4 на Windows. Немного погрузившись в тему, я решил написать эту статью и рассмотреть процесс подробно. В отрыве от нашей специфики пост будет полезен интеграторам и DBA при планировании переноса данных/CUT.