Oracle *

Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов.

Причина миграции — импортозамещение.

Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям.

Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей.

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

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

Из всего многообразия оборудования, которое встречается в ЦОДе, ленточные библиотеки — единственный вид, работу которого можно увидеть. Ленточные библиотеки ворочают петабайты данных на магнитных лентах в картриджах, которые отдают лёгкой ностальгией по VHS, и делают это с помощью роботов. А роботы — это (почти) всегда круто. И в одной библиотеке их может быть несколько!

Ленточные библиотеки стыкуются из модулей, как огромные орбитальные станции, а их производители в погоне за максимальной плотностью хранения картриджей находят очень изобретательные решения — от хранения картриджей в несколько слоёв в одном слоте до револьверных механизмов высотой с холодильник и шаттлов, которые передают ленты между разными библиотеками. Это ли не круто?

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

СУБД PostgreSQL давно закрепилась в топе благодаря открытости, надёжности и расширяемости, однако ее архитектурный консерватизм порождает ряд нерешённых проблем: отсутствие горизонтального масштабирования, деградация при тысячах соединений, узкое место WAL при высоком commit rate, невозможность полноценной HTAP-обработки и другие.

В статье рассказываем как в новом, третьем поколении машин баз данных Tantor XData Gen3 эти ограничения преодолеваются через глубокую переработку архитектуры — от полного разделения Compute и Storage с протоколом RDMA и распределённой файловой системой PFS до внедрения механизмов CSN для MVCC без блокировок, конвейерной обработки WAL и встроенного MPP‑движка, превращающего PostgreSQL в систему, способную конкурировать с Oracle Exadata уже по‑настоящему. И все это — со 100% сохранением совместимости с «обычным» PostgreSQL.

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



Привет! Мы – Дмитрий Харлан и Антон Ляшедько, представители команды развития системы бизнес-планирования ВТБ.

Наша история о том, как мигрировать монолитную систему с более чем 300 отчетами и объемом данных свыше 100 гигабайт за минимальное время простоя.

Существует опасное заблуждение, что «ванильный» Open Source — это серебряная пуля для энтерпрайза. Однако жесткий краш-тест последних лет показал: когда уходят привычные гиганты вроде Oracle, чистый Postgres превращается в тыкву под нагрузками крупного бизнеса. Руководитель отдела технического консалтинга Postgres Professional Марк Ривкин делится своим авторским видением того, почему нам приходится заново изобретать велосипеды, дописывая миллионы строк кода в ядро, и почему будущее за конвергентными системами. Дисклеймер: это частный взгляд эксперта.

Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного.

Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.

Слышали о ГИС ГМП? Скорее всего, мало кто слышал. Зато точно видели, если:

— вам на Госуслуги приходила пошлина на оплату нового загранпаспорта

— вы получали уведомление о штрафе ГИБДД в банковском приложении

— вы узнавали состояние своего единого налогового счёта (ЕНС)

Чтобы всё это стало возможным, Федеральное Казначейство создало Государственную информационную систему о государственных и муниципальных платежах (ГИС ГМП). Именно она аккумулирует все назначенные людям и компаниям платежи и контролирует их оплату, сверяя платёжные поручения банков с начислениями.

Как вы думаете, много ли там начислений? А платежей? Сотни миллиардов.

В рамках импортозамещения нам в РТЛабс поставили задачу — мигрировать ГИС ГМП с базы данных Oracle на другую подходящую. Да-да, нам предстояло мигрировать систему, которая хранит сотни терабайт данных — кому и что было начислено, как и когда это оплатили.

Как нам это удалось? Именно об этом я и хочу рассказать. На связи Михаил Денисов — технический директор блока развития казначейских проектов.

В интернете есть много статей на тему «как перевести старую систему с Oracle на PostgreSQL». Как мигрировать схему данных, сами данные и логику. Не буду повторять это, просто сравню две СУБД на небольшом вымышленном учебном примере. Я расскажу про то, как организовать процесс написания и проверки кода системы для PostgreSQL, чтобы на выходе получился продукт даже более качественный, чем он мог быть без смены СУБД.

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

Oracle снова в центре внимания. Компания, долгое время считавшаяся инфраструктурным элементом корпоративных ИТ-систем, внезапно оказалась в центре внимания ИИ.

Это история Oracle Ларри Эллисона, её многолетней трансформации и создания облака, идеально подходящего для эпохи искусственного интеллекта.

JOIN vs коррелированный подзапрос: мой разбор мифа «JOIN всегда быстрее»

Я проверил оба подхода (JOIN + GROUP BY и коррелированный подзапрос) на маленьком датасете и в ряде СУБД. Иногда подзапрос быстрее. Всё зависит от плана (Nested Loop vs Hash) и индексов. Слепо верить «JOIN всегда быстрее» не стоит. Смотрите EXPLAIN.

Всем привет! Меня зовут Алексей Кременьков, я старший разработчик в Яндекс Почте. В этой статье расскажу, как мы работаем с большим количеством шардов PostgreSQL: как создавали собственный сервис динамического шардирования Sharpei, как развивали инфраструктуру под него и как проходил переезд на облачное решение. В конце разберёмся, какие плюсы и минусы мы смогли найти в этом решении.

В статье я расскажу о практических кейсах и сложностях, возникающих (и возникавших) в процессе миграции данных между СУБД (Oracle -> Postgres), а также о собственном инструменте миграции данных, который вы также можете попробовать.

Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.

Всем привет! Меня зовут Андрей Бобронников, я занимаюсь обеспечением надежности ИТ систем в банке Уралсиб. В этой статье я вам расскажу о методах оптимизации для разработчиков на платформе ЦФТ в БД Oracle.

Ввиду роста бизнеса, наши системы стали обрабатывать все больше транзакций и возникла необходимость собрать материалы, которые помогут разработчикам ЦФТ писать оптимальный и быстрый код под Oracle на языке PL+, PL/SQL и SQL.

В данной статье постарался собрать минимум необходимых знаний и методов для написания оптимального кода без ошибок. Можно использовать для обучения новых сотрудников и как справочный материал.

Механизм реализации транзакций - основная часть реляционных баз данных. Он упрощает разработку приложений, в которых гарантируется целостность данных. Стандарт SQL регламентирует, часть свойств по поддержке транзакций, но многие детали не стандартизованы. Как следствие, реализация поддержки транзакций в разных базах данных может существенно различаться. В настоящее время, многие пытаются перейти с Oracle на PostgreSQL. Для миграции приложений важно понимать различия в реализации работы транзакций, иначе можно столкнуться с неприятными сюрпризами, которые могут поставить под угрозу производительность и целостность данных. Поэтому Лоренс Альбе решил, что полезно сравнить реализацию работы транзакций в Oracle и PostgreSQL и свести различия в одной статье.

Достаточно большой период времени занимался технической поддержкой СУБД Oracle. Накопилось некоторое количество историй и заметок на полях по этому поводу, не могу не поделиться ими с вами. В общем — садимся по удобнее, берем попкорн, чашку горячего чая или кофе.. Дело было так.

Привет, Хабр! Меня зовут Павел, я ведущий архитектор в «Инфосистемы Джет», и это мой дебют на этой площадке.

Работая с Oracle Data Integrator (ODI), мы ценим его графический интерфейс за автоматизацию рутины и удобство разработки. Однако, когда проект масштабируется до десятков пакетов и сотен сущностей, GUI перестает быть оптимальным инструментом для отслеживания потоков данных, глубокого анализа и аудита зависимостей.

В таких случаях ключом к эффективности становится прямое взаимодействие с метаданными ODI через SQL‑запросы к его репозиториям. Эта статья посвящена именно этому — практической работе со структурой репозиториев ODI и детальному разбору SQL‑запроса для построения потоков данных.

Привет, Хабр!

На связи сервисная команда «Инфосистемы Джет». Сегодня хотим рассказать про один из технических кейсов. На его решение должна была уйти пара часов. Вместо этого он съел четыре дня нашей жизни. Спустя почти десяток лет он регулярно вспоминается в обсуждениях за обедом как один из непростых в диагностике. На днях обсуждали его — почему бы теперь не рассказать о нем вам? :) Приступим.