Oracle *

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

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

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

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

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

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

В рамках импортозамещения нам в РТЛабс поставили задачу — мигрировать ГИС ГМП с базы данных 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‑запроса для построения потоков данных.

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

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

На статью данный текст точно не тянет, скорее это маленькая заметка. Как известно свои дети и свои идеи они всегда самые лучшие. Я давно работаю с реляционными базами и очень люблю язык SQL за его формализм, скорее всего из-за этой моей профдеформации и родилась эта мысль. На работе ко мне иногда обращались сделать выгрузку в CSV файл из базы для обучения моделей или анализа данных, и я подумал, а зачем выгружать данные, а потом иногда загружать обратно результат в базу. Почему не сделать так что бы результат запроса сразу отправлялся на обработку в AI и затем выдавался ответ на запрос. Нам всего лишь нужна SQL функция которая берет результат запроса, заворочает его в вызов к модели, а потом выдает результат. Понятно, что серебряной пули нет и данный подход не везде будет работать, например, такой подход не подразумевает асинхронность, а значит если нужна высокая производительность, то данный подход не очень подходит, с другой стороны сейчас запросы к AI не дёшевы и если вы пошлете 100 запросов в секунду, не дождавшись ответа на предыдущие то скорее всего получите ошибку. Я думаю в будущем это будет стандартная функции в базах данных.

Теперь рассмотрим простейшую реализацию данной функции. Под рукой был PostgreSQL, но можно реализовать это и для ORACLEили других баз. Для этого нам понадобится расширение. В качестве AI будем использовать Groq. Первое что нам надо это получить API ключ. Сама функция очень простая.

Слой приложения persistence layer является в определённом смысле уникальным в смысле узкой направленности его функционала по сравнению с другими слоями приложения. Если рассматривать его только для работы с реляционными базами данных, то реализацию функционала слоя можно разбить на два основных варианта - с использованием ORM фреймворка и без использования ORM фреймворка. Каждый из этих вариантов можно реализовать достаточно универсальным образом.

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

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

Каждая компания стремится к тому, чтобы данные были не только доступны в нужный момент, но и надежно защищены (спасибо, КЭП!). Более того, необходимость обеспечения безопасности ЗОКИИ и требований по импортозамещению ставит новые задачи в области интеграции систем и миграции данных. Один из способов разобраться с этими вызовами — репликация данных. Она помогает компаниям справляться с растущими нагрузками, обеспечивает защиту данных и облегчает миграцию между различными платформами. Однако ее успешное внедрение требует тщательной подготовки, внимательного выбора стратегии и регулярного мониторинга. Хватит слов – за дело!  В этой статье мы покажем сразу несколько технических решений.

В статье рассматривается использование теста TPC-H с PostgreSQL и проблемы, связанные с запросами Q17-Q20 теста.

Введение

Вместе с PostgreSQL поставляется утилит pg_bench с "TPC-B like" тестом. Кроме этого теста были созданы тесты TPC-R для отчётов, TPC-D для OLAP, TPC-W для заказов в веб-магазине, которые не получили распространения. На основе TPC-D был создан более удачный тест TPC-H для хранилищ данных и аналитических запросов ("OLAP нагрузка"). В тесте используется 8 таблиц и 17 ограничений целостности. В TPC-H выделены номинации по размерам обрабатываемых данных от "до 100Гб" до  30-100Тб. Тест TPC-H предназначен для хранилищ данных, включает в себя 22 запроса, которые называют Q1 ... Q22.

Запросы теста TPC-H не меняют данные в таблицах, а значит, для повторных тестирований не нужно пересоздавать или вакуумировать таблицы. В тестах TPC-B, TPC-C, TPC-E запросы довольно простые. В реальных приложениях запросы более сложные, чем в этих тестах. Поэтому для тестирования того, как СУБД выполняет запросы, которые могут встретиться в реальных приложениях, можно использовать все или отдельные запросы из теста TPC-H. Для быстрого аудита производительности различных СУБД используют вариант с 1Гб данных. В этом варианте запросы выполняются быстро, не нужно много памяти под экземпляр СУБД и много места на диске. Можно найти программы или скрипты для большинства СУБД, например, для PostgreSQL, Oracle Database, MySQL. После теста TPC-H появился тест TPC-DS с 99 запросами, но он менее популярен.

Всем привет!

Меня зовут Алексей, я старший аналитик команды «Цифровая карта магазина». Сегодня я хочу рассказать про различные варианты интеграции с внешними системами, какие подходы и технологии мы использовали при их реализации и что из этого вышло.

О продукте «Цифровая карта магазина»

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

В этой статье я хотел бы поделиться с вами моим опытом написания юнит-тестов для базы данных (БД) в рамках легаси-проекта. Я выбрал формат ретроспективы, чтобы показать, как все начиналось, к чему мы пришли и какой путь был пройден в разработке юнит-тестов для проекта «Цифровая карта магазина». Возможно, статья будет полезна начинающим разработчикам баз данных или тем, кто хочет начать писать юнит-тесты для Oracle, но не знает, с чего начать.

Привет, Хабр! Сегодня расскажем вам историю о том, как за 7 месяцев перевести крупное химическое предприятие с Oracle на 1С и не сойти с ума. Вы не ослышались — за 7 месяцев мы внедрили комплекс решений 1С:Корпорация в ПАО «КуйбышевАзот», автоматизировав 9 подсистем и 284 бизнес-процесса.

Многие сейчас подумали: «Наверняка там куча костылей и недоделок». Спешим заверить — это реальный кейс, и система работает в штатном режиме в условиях промышленной эксплуатации без дублирования информации в исторической системе. Более того, мы сделали это без остановки непрерывного производства и критичных бизнес-процессов.