Oracle *

Добрый день, всем любителям Oracle и пирогов из картофельных очистков!

Одна из самых часто встречающихся проблем при использовании баз данных - это поиск узких мест: нахождение долго выполняющихся запросов и их исправление.

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

Я написал open-source утилиту Optimus Oracle. Она получает тяжёлые SQL-запросы из ASH/AWR, собирает планы и через LLM (локальные или облачные) предлагает оптимизацию: создание индексов или изменение запроса. Дальше - реальные примеры «до/после», цифры, грабли и честный разговор о приватности.

ora2pg переносит схему с Oracle на PostgreSQL, и в целом переносит хорошо. Интересное начинается там, где он чего-то не осилил: он не падает и не ругается, а молча делает не то.

Процедура с AUTHID исчезает из вывода целиком, без ошибки и без строки в логе. TO_DATE с форматом RR молча возвращает 1 год до нашей эры. LONG RAW превращается в text, хотя сам ora2pg документирует bytea. Обработчик исключений после конвертации ловит SQLSTATE, которого PostgreSQL не возбуждает никогда.

Двадцать таких мест, все проверены на реальном ora2pg 25.0 и живом PostgreSQL 16, по каждому написано чем чинить.

Задача звучала как задача из учебника: перенести кредитный домен банка с Oracle на PostgreSQL. 70+ таблиц, чуть больше терабайта данных, 500–3000 RPS на чтение и 50–300 на запись в пике. Одно ограничение: система обслуживает клиентов и не может остановиться. Ни на ночь, ни на выходные, ни «на 15 минут на переключение».

Эта статья — не туториал «как мигрировать за 10 шагов». Таких на Хабре десятки, и половина из них сводится к «запустите ora2pg». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «об этом мы узнали за неделю до переключения».

Если вы планируете такую миграцию, читайте как чеклист. Если уже прошли — сверьте, сколько совпало.

Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин и сами проблемы — настоящие.

Меня зовут Герасимов Михаил, я главный инженер в Россельхозбанке (РСХБ), работаю в команде автоматизации тестирования. Наш основной фокус — регрессионные автотесты на Java.

Эта публикация — первая в серии статей про CheckMateDB. Здесь мы сделаем быстрый, но технически предметный обзор продукта: что уже работает, какие задачи он закрывает и куда мы его развиваем. В следующих статьях разберем отдельные части подробнее: архитектуру модулей, ML‑контур генерации кода, практику внедрения и метрики качества.

Если коротко, то наша ежедневная реальность выглядит так: ручные тестировщики пишут сценарии в TestIT, а автоматизаторы превращают их в код. Звучит просто, но на масштабе регресса очень быстро проявляется bottleneck: между тест‑кейсом и готовым автотестом лежит большой слой однотипной инженерной рутины. Где‑то нужно аккуратно собрать тестовые данные, где‑то написать Criteria, где‑то выстроить PageHelper‑цепочку, где‑то допилить проверки и стабилизировать прогон. И да, иногда кажется, что половина автотеста уже написана… просто в 17 разных местах и в разное время.

В этой статье расскажу, как мы в команде закрываем этот разрыв с помощью CheckMateDB и почему развиваем его как единую точку входа для автоматизированного тестирования: от данных и SQL‑аналитики до AI‑генерации кода и управляемого применения изменений.

Когда говорят о DuckDB, обычно вспоминают аналитику: локальные запросы к Parquet, быстрые агрегации, ноутбуки. Но у него есть свойство, к аналитике отношения не имеющее: он умеет соединять источник и приёмник данных внутри одного SQL-плана. С расширениями для Oracle и PostgreSQL перенос данных сводится к одному запросу — без Instant Client, без OCI, без Python и без промежуточных файлов. А если одной сессии Oracle мало, чтение разбивается на параллельные шарды, читающие один согласованный снимок по единому SCN.

На Хабре не так много информации об интеграции между различными СУБД, и я решил поделиться своим опытом построения информационной системы на базе Oracle, которая взаимодействует с PostgreSQL (PG). Статья состоит их двух частей: в первой описана конфигурация СУБД, а во второй описан кейс по получению и обработке данных. Надеюсь, этот материал сэкономит Вам время при решении подобных задач.

Работаю в конторе, которая обслуживает госзаказчиков, и последние месяцы у меня одна большая головная боль: перевод старой оракловой схемы на Postgres Pro. Контур закрытый, интернета нет, лицензии на Enterprise нет, проприетарной ora2pgpro тоже нет. То есть из автоматики только опенсорсный ora2pg, и всё.

Штука рабочая, кто пользовался, тот знает. По разным оценкам тянет процентов восемьдесят перевода PL/SQL в PL/pgSQL. Для инструмента, который пилят несколько человек в свободное время против СУБД с тридцатилетней историей, это вообще‑то дофига )

Схема не маленькая, под сотню пакетов и триггеров, плюс куча legacy, которое живёт ещё с нулевых. И когда я первый раз прогнал её через ora2pg и увидел зелёный SHOW_REPORT, я на секунду выдохнул. Рано выдохнул, как выяснилось;)

В итоге доканали меня не эти восемьдесят процентов, а оставшиеся двадцать. И не количеством. А тем, что они не падают в момент конвертации, а спокойно ждут, пока код доедет до прода.

Постоянно меняющиеся требования со стороны Центробанка и Росфинмониторинга заставляют финансовые организации уделять пристальное внимание своим клиентам с точки зрения их благонадежности. Каждый день производится ряд проверок, позволяющих оценить риски обслуживания организаций и физических лиц. В связи с этим появилась необходимость не просто автоматизировать данный процесс, но как-то его систематизировать и сделать удобным для сопровождения.

Эта статья предназначена для технических специалистов, работающих с Oracle: администраторов баз данных, инженеров производительности, разработчиков инструментов мониторинга и исследователей внутренних механизмов СУБД. Это готовый пример низкоуровневого исследования, который можно адаптировать под собственные задачи. Мы покажем, как связать привычные SQL‑данные из v$sesstat с их реальным расположением в памяти процесса, и на конкретном примере проиллюстрируем методику, применимую и к другим внутренним структурам Oracle. Это первая статья из серии, она посвящена Oracle 11g, довольно древней версии Oracle, далее мы увидим как изменялся подход корпорации Oracle к хранению внутренних структур статистики.

Сталкивались ли вы с кейсом, когда по заданному списку email или номеров телефонов необходимо проверить всех клиентов на совпадение с ними? Поиск через интерфейс в различных системах не всегда удобен или даже невозможен. В этой статье я расскажу, как организовать универсальное хранилище объектов различного типа под разные цели. Мы создадим единый справочник в базе данных и организуем поиск по нему.

Недавно я реализовывал задачу автоматизации выставления счетов за оказание логистических услуг на основании данных из WMS и ТСД. В процессе разработки я использовал параметризованные SQL-запросы к базе данных. Это создает определенную сложность: для описания новых услуг или изменения логики расчета требуется менеджер, владеющий SQL, что на практике маловероятно. Чтобы снизить нагрузку на разработчика по сопровождению системы, я принял решение использовать технологии искусственного интеллекта.

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

Мое погружение в работу проходило постепенно, не было задач из серии «бросаемся на амбразуру». Процесс онбординга шёл плавно, в том числе и на тестовых задачах.
В этой статье я хочу поделиться одним из таких тестовых заданий. Где мне удалось ускорить один простой запрос в 250 раз, а подход к решению задачи взят к применению на похожих кейсах.

Переход крупных корпоративных систем на отечественные СУБД остается одной из наиболее актуальных задач последних лет. Однако основная сложность подобных проектов заключается не столько в переносе данных, сколько в сохранении работоспособности существующих приложений, написанных под Microsoft SQL Server и Oracle Database.

Именно поэтому развитие Digital Q.DataBase сосредоточено сразу на нескольких направлениях: расширении совместимости с зарубежными СУБД, автоматизации миграции и создании инструментов, позволяющих минимизировать объем ручной доработки приложений.

Версия 18.2 стала одним из наиболее масштабных обновлений платформы. В релиз вошли изменения архитектуры продукта, значительное развитие совместимости с Microsoft SQL Server и Oracle Database, новые возможности мастера миграции, первая версия службы построения отчётов, совместимой с SQL Server Reporting Services, а также десятки других улучшений.

Подробнее об изменениях - в этой статье.

Безопасный AI-мониторинг Oracle в закрытом контуре с использованием Python, Ollama и V$WAITCLASSMETRIC

Введение

В существующей системе мониторинга Oracle уже использовалось разработанное мной решение, которое с интервалом в 1 минуту собирало метрики производительности из представления V$WAITCLASSMETRIC и отображало их в Grafana. Графики наглядно показывали изменения времени ожиданий в классах User I/O, Commit, Concurrency и других, однако они показывали лишь сам факт изменения нагрузки, не объясняя его причины.

Возникла идея: если метрики уже собираются для построения дашбордов, почему бы одновременно не отправлять их локальной языковой модели? Тогда вместе с графиком можем сразу отображать текстовое объяснение происходящего, список наиболее вероятных причин изменения показателей и рекомендации, с чего начать дальнейшую диагностику.

Так появился небольшой эксперимент — дополнить существующую систему мониторинга Oracle локальным AI-ассистентом.

Привет, Хабр! Пишет эту статью Александра Лысенко — вчера я была студенткой, а сегодня как инженер-программист Nexign спешу поделиться приобретенным опытом.

Мой первый проект для реального бизнеса был связан с миграцией с Oracle на PostgreSQL. Сегодня расскажу, как внедрение диапазонного типа данных при переходе между СУБД позволило не просто сохранить производительность, но и превзойти исходные показатели. Если вы тоже только начинаете свой карьерный путь — надеюсь, этот материал вам поможет.

ORM — Object-Relational Mapping — Объектно-реляционное отображение — это технология, позволяющая связывать SQL-ые БД с ООП кодом. Самая известная из них — Hibernate.

Hibernate — очень красивая технология. Она формирует ощущение магии.

Ты просто создаёшь объект, — хлабысь! — он уже в базе данных. Никакого SQL, никаких соединений, никаких ResultSet. Всё происходит как будто само собой. Прелесть.

Именно поэтому отказаться от Hibernate так тяжело.

Это напоминает Кольцо Всевластия из «Властелина колец». Оно не просто давало силу — оно меняло сознание своего владельца. Оно внушало мысль, что без него уже нельзя. Что именно оно даёт власть и контроль.

Hibernate действует очень похоже. Он формирует ощущение, что именно он управляет данными. Что именно он связывает код с базой. Что без него всё развалится.

И ты начинаешь бояться.

Бояться, что без Hibernate придётся писать бесконечный SQL. Бояться, что потеряешь контроль над данными. Бояться, что любая операция с базой превратится в мучение.

Ты уже не представляешь себе проект без этой магии. Ты настолько к ней привык, что мысль «выкинуть Hibernate» кажется почти кощунственной. Кажется, будто вместе с ним исчезнет и сама возможность нормально работать с базой данных.

Однажды я захотел узнать что-то новое по СУБД Postgres и структурировать уже имеющиеся знания. На помощь пришла программа сертификации. Рассказываю как подготовиться к прохождению теста от Posgres Professional и на что обратить внимание в первую очередь.

Мое имя Денис Непочитой, я уже несколько лет занимаюсь базами данных в ПСБ.

Администрировал разные системы, но в основном фокусе была АБС на Oracle (автоматизированная банковская система, «сердце» банка): от решения проблем с производительностью до обновлений на новую версию. В последнее время также сфокусирован на задачах по АБС, но уже на Postgres. 

Для кого эта статья: для тех, кто только начинает свой путь в ИТ, и для всех, кто задумывается о прохождении сертификации.

Как это было — читайте ниже.

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика — в другой, а между ними — разного рода ETL, CDC и прочие parquet‑файлы.

В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

Все, кто имел дело с базами данных, знают, что там можно хранить бинарные данные большого объема. Чаще всего, это загруженные в БД файлы. Достаточно давно меня стал посещать такой вопрос — а какие накладные расходы на хранения файлов в БД? Понятно, что они есть, но вот какие и от чего они зависят? Но каждый раз были вопросы и задачи поважнее. И вот недавно произошло то, что рано или поздно должно было произойти — одновременно у двух заказчиков возник вопрос, который, упрощая, выглядит так: «Почему мы загрузили такой‑то объем данных, а место на диске занято больше?». У одного из заказчиков был Oracle, у второго — Postgres. Конечно, можно было бы ответить уклончиво: «У каждой БД существую накладные расходы на хранение данных, вот у вас эти накладные расходы вот такие. Разработчикам СУБД виднее, как все должно быть.» И, может быть, заказчика такой ответ и устроил, но сам я понимал, что это просто отписка, так как у нас нет конкретного ответа. Несолидно как‑то. Поэтому, давайте разбираться.

В любой промышленной системе обработки данных есть пласт регулярной работы, которую нужно просто запускать раз в день или раз в час и не думать о ней: ночные ETL-загрузки, пересчёт витрин, выгрузки в смежные системы, всякая техническая обвязка вроде чистки служебных таблиц. Всё это должно где-то стартовать по расписанию, уметь учитывать зависимости между потоками и принимать во внимание тот факт, что задачи у нас разнородные. Ниже — рассказ про то, как устроен наш планировщик на Oracle Data Integrator и PL/SQL: из чего он собран, как задачи попадают в очередь, как они распределяются по серверам, и как мы закрываем сценарий с зависаниями.