Oracle *

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

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

В статье рассматривается использование теста 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 бизнес-процесса.

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

Данная статья является продолжением этой статьи: Инструкция: как перейти в сферу it, но с перечнем курсов, которые я закончил (это тоже часто спрашивают). Можете считать это рекламой пройденных мною курсов, а можете и не считать.

Привет! Меня зовут Зураб Диаконашвили, я разработчик в компании SM Lab. Сегодня поговорим об использовании полиморфных табличных функций в Oracle и рассмотрим их работу на примерах.

При работе с Oracle используются SQL-запросы – они помогают управлять базами данных, представленными в виде таблиц. Мы получили задачу на динамическое добавление полей в стационарный набор полей сущности. Для этого мы решили попробовать PTF-функцию (пользовательскую табличную функцию, которая вызывается в предложении FROM) и сравнить результат её работы с обычным SQL PIVOT и JavaScript.

Полиморфные табличные функции (PTF) являются частью стандарта SQL: 2016. В Oracle они представлены в версии 18c.

Что необходимо знать при работе с PTF:

На основе статьи Arpendu Kumar Garai "Demystifying Transactions and Exceptions with Spring", от 31 января 2023 года.

Spring Framework обеспечивает обширную поддержку транзакций. Но прежде чем мы углубимся в концепции управления транзакциями, давайте разберемся с основной концепцией транзакции.

Транзакция базы данных (СУБД) — это серия из одной или нескольких операций, выполняемых как единая атомарная единица работы. Это означает, что либо все операции в транзакции завершаются успешно, либо ни одна из них не применяется к базе данных. Транзакция может состоять из одной команды, группы команд или любых других действий с базой данных. Любая СУБД, поддерживающая транзакции, должна гарантировать качество ACID для сохранения целостности данных.

ACID (от англ. atomicity, consistency, isolation, durability) — набор требований к транзакционной системе, обеспечивающий наиболее надёжную и предсказуемую её работу.

Основные требования:

В статье рассматривается пошаговое создание образов «с нуля» для контейнерного движка Podman. Внутрь контейнера «упакована» база данных Oracle Database 21c Express Edition. И всё это отечественной операционной системе РЕД ОС.

*2 контейнера

Введение

В первой части статьи была рассмотрена основная проблема при миграции СУБД Oracle с RISC-платформ на Linux x86 - различие в форматах хранения (Endian) и необходимость конвертации блоков в файлах данных при миграции. Также кратко была описана технология миграции с помощью транспортируемых табличных пространств, включая вариант с инкрементальными резервными копиями, который позволяет снизить время простоя (downtime) при миграции.

В второй части статьи был описан алгорим миграции с помощью технология Full Transportable Export/Import (FTEX) с использованием скриптов M5, поставляемых компанией Oracle.

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

Для меня PL/SQL есть логичное продолжение изучения SQL, но по нему много и статей, и курсов, причем даже на русском языке. С другой стороны, PL/SQL раскрывается достаточно редко, особенно среди бесплатных ресурсов, так что… Начинаем :)

Всем привет! Я Тимур, инженер в команде Databases Т-Банка. Занимаюсь решением проблем и настройкой производительности СУБД Oracle и PostgreSQL Oracle — это СУБД для наших критичных  нагруженных legacy систем, системы построенные на новой архитектуре используют PostgreSQL.

Расскажу о случае конкуренции на одной критичной БД. В какой-то момент перестали проходить транзакции из-за конкуренции за ITL-слоты на вставке в таблицу. Проблема, конечно, была решена, но хочу порассуждать о том, как можно расследовать такие инциденты хорошо известными способами. А еще рассмотрим, как можно подсмотреть за некоторыми аспектами внутреннего устройства СУБД.

Уверен многие тру-программисты и без меня знают их, но я решил собрать во едино все реализации циклов через while, которыми я активно пользуюсь, как автоматизатор, тестировщик и разработчик ETL.

Привет, Хабр! Меня зовут Михаил Герасимов. Это продолжение статьи «Как в РСХБ разработали средство генерации SQL-запроса для упрощения задач по тестированию», где описывались принципы работы QueryBuilder. 

В условиях растущего тренда на импортозамещение в ИТ-компаниях, переход с коммерческих СУБД на Open Source решения стал одной из ключевых задач для многих организаций. В частности, в проекте по автоматизации тестирования специалисты РСХБ успешно адаптировали свой инструмент генерации SQL-запросов QueryBuilder к переходу на PostgreSQL.

Миграция ZABBIX с Oracle в PostgreSQL с помощью Ora2pg

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

Исходные данные: Zabbix 6.0.26, OL8, single instance Oracle 19.12, размер БД - 3 TB.

Конечный результат: Zabbix 6.0.26, OL8, ванильный СУБД PostgreSQL 14.10,смигрированная БД со всеми данными (допускалось отсутствие детализированной информации за время перелива основной пачки данных таблиц history,history_log,history_str,history_text,history_uint,trends,trends_uint).

Инструмент миграции данных - Ora2pg.

Введение

В первой части статьи была рассмотрена основная проблема при миграции СУБД Oracle с RISC-платформ на Linux x86 - различие в форматах хранения (Endian) и необходимость конвертации блоков в файлах данных при миграции. Также кратко была описана технология миграции с помощью транспортируемых табличных пространств, включая вариант с инкрементальными резервными копиями, который позволяет снизить время простоя (downtime) при миграции.

В второй части статьи был описан алгорим миграции с помощью технология Full Transportable Export/Import (FTEX) с использованием скриптов M5, поставляемых компанией Oracle.

Несмотря на значительное упрощение миграции с помощью технологии Full Transportable Export/Import и скриптов M5, опыт автора показывает, что при миграции реальных производственных баз Oracle, возникает ряд проблем.

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

Подготовка исходной БД для миграции Перед тем как начинать финальный этап миграции (перевод на исходной БД табличных пространств в read only и снятие финального инкрементального бэкапа) рекомендуется выполнить следующие действия:

Привет, Хабр! Меня зовут Семен Попов, я отвечаю за разработку хранилища клиентских данных в Сбере. Расскажу, как мы в эксплуатации перешли с одной базы данных на другую — а именно, с Oracle на Platform V Pangolin, разработку СберТеха на основе PostgreSQL, доработанного в области безопасности, надёжности и производительности.

Введение

В первой части статьи была рассмотрена основная проблема при миграции СУБД Oracle с RISC-платформ на Linux x86 - различие в форматах хранения (Endian) и необходимость конвертации блоков в файлах данных при миграции. Также кратко была описана технология миграции с помощью транспортируемых табличных пространств, включая вариант с инкрементальными резервными копиями, который позволяет снизить время простоя (downtime) при миграции.

Было отмечено, что для упрощения межплатформенной миграции с помощью транспортируемых табличных пространств с инкрементальными резервными копиями, компания Oracle предоставляет набор готовых perl-скриптов - в документе "V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)”.

В заключении, была описана технология миграции с помощью Full Transportable Export/Import (FTEX), которая, начиная с Oracle Database 19c, поддерживает автоматическую конвертацию блоков при смене Endian.

Переход с RISC-платформ на Linux x86 c помощью скриптов миграции M5

Для упрощения миграции БД с сменой Endian, компания Oracle предоставляет новый набор скриптов M5:M5 Cross Endian Platform Migration using Full Transportable Data Pump Export/Import and RMAN Incremental Backups (Doc ID 2999157.1)

Данные скрипты включают в себя все последние улучшения в технологии Oracle FTEX.

Стоит отметить, что скрипты M5 реализованы на языке программирования bash schell, без использования скриптов на perl. Объем M5-скриптов (в строках кода) в несколько раз меньше, чем вариант perl-скриптов для V4.

В последнее время наблюдается рост интереса заказчиков к миграции СУБД Oracle Database с RISC-платформ (прежде всего это платформы Oracle SPARC и IBM Power) на Linux x86.

Этому способствует много причин. Oracle прекратил развитие SPARC-архитектуры, RISC-сервера в несколько раз дороже x86-серверов, комплектующие к ним стоят в несколько раз дороже, чем для x86-серверов. В то же время, платформа x86, благодаря стараниям компании AMD, за последние годы получила бурное развитие: на рынке стали доступны относительно недорогие 2-х сокетные системы с 128 процессорными ядрами, что суммарно дает 256 ядер на сервер (512 потоков с включенной технологией AMD SMT).

Также унификация аппаратного обеспечения инфраструктуры ПО (баз данных и серверов приложений) с помощью широко распространенной платформы Linux x86, значительно упрощает ее сопровождение и стоимость. Также устраняется зависимость от одного вендора, то есть от производителя RISC-серверов.

В данной статье будет подробна описана миграция СУБД Oracle Database с
RISC-платформ на Linux x86 с минимальным временем простоя с помощью
кроссплатформенных переносимых табличных пространств (Crossplatform
Transportable Tablespaces).

Различие в форматах хранения на x86 и на RISC-платформах

Проблема миграции баз данных с RISC-платформ на Linux x86 состоит в том, что эти платформы имеют разный формат хранения данных в памяти и на диске. На RISC-платформах байты упорядочены от старшего к младшему (Big Endian), а в Linux x86 — наоборот, от младшего к старшему (Little Endian).

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

Возникла довольно естественная идея использовать этот метод для сопоставления CPU интенсивных задач в БД Oracle. Например, если мы встраиваем такую прожорливую CPU-функцию в наш пайплайн исполнения SQL-запроса так, чтобы она выполнилась более миллиарда раз, то получаем возможность сравнить затраты на CPU в разных случаях.

В данном случае мы будем сравнивать по производительности различные функции хеширования в Oracle: ORA_HASH и различные варианты STANDARD_HASH.