Oracle *

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

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

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

Быстрое развитие проекта несет в себе множество сложностей: большая вероятность сломать старый функционал или привнести новые баги. Одним из способов поддержания качества кода в хорошем состоянии – это покрытие кода Unit тестами. Но следствием увеличения количества Unit тестов, является увеличение времени исполнения. Попробуем достигнуть максимума – скомбинируем параллельно выполняющиеся UnitTest’ы таким образом, чтобы достигнуть наибольшего быстродействия.

Миграция 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.

Привет, Хабр! Меня зовут Юрий Мишин, я технический директор в департаменте банковского ПО компании R‑Style Softlab. В этой статье я расскажу о масштабном проекте по переводу одного из ключевых продуктов компании 一 автоматизированной банковской системы (АБС) 一 на импортозамещенный стек.

Есть несколько вариантов захвата изменений из СУБД Oracle Database, самыми распространенными являются API LogMiner и API XStream. В данной статье рассмотрим API LogMiner.

Каждый разработчик, кто серьезно работал с типом DateTime, сталкивался с ошибкой високосного года. На этом пути не спасали ни многочисленные методы языка программирования, ни гуглопоиск - обязательно, раз в четыре года, баг високосного года напоминал о себе. В этом году насчитали 36 случаев.

В сфере страхования ошибка високосного года показывает новые грани в силу специфики многолетнего страхования. В статье расскажу об одном неочевидном случае и поделюсь подходом к решению проблемы. Примеры даны для Oracle PL/SQL, которые достаточно легко портируются на другие языки программирования.

В базах данных транзакции обладают свойствами ACID, где «I» означает изоляцию транзакций при одновременном (concurrent) выполнении.

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

Сериализация выполнения транзакций не бесплатна с точки зрения производительности.

Многие СУБД поддерживают более слабые уровни изоляции, оставляя за разработчиком выбор подходящего. В монолитных СУБД более слабый уровень изоляции часто используется по умолчанию. Так, в PostgreSQL и MySQL это «read committed». В распределённых СУБД чаще по умолчанию более строгие уровни: «repeatable read» в YugabyteDB и TiDB, «serializable» в CockroachDB и YDB.

Слабые уровни изоляции могут быть причиной очень труднонаходимых багов. Причём эти баги могут вызвать уязвимости в безопасности.

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

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

Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству эксперт Учебного центра IBS. В этой статье расскажу, чем PL/SQL похож и чем отличается от PL/pgSQL, на что обратить внимание при переходе и какие инструменты могут вам с этим помочь.

Привет, Хабр! Я Владимир Хаймин, эксперт по системам управления базами данных PostgreSQL в ВТБ. В последнее время одним из наиболее распространенных способов миграции стала миграция при помощи свободного инструмента ora2pg. Однако многие отмечают его крайне низкую производительность, особенно если речь идет о базах Oracle размером под 1Тб и выше. Как ускорить миграцию и сократить время простоя при переносе проектов при помощи только oracle_fdw, либо в сочетании с ora2pg расскажу далее.

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

Сегодня мы поговорим об актуальной задаче — миграции баз данных с Oracle на PostgreSQL с использованием Ora2Pg. Сейчас популярность PostgreSQL обоснована его мощностями и экономически выгодной альтернативы коммерческим решениям.

Всем привет! Я Сергей, работаю в B2B-команде Яндекс Маркета последние 3,5 года. Как уже понятно из заголовка, сейчас я вам расскажу про yet-another-миграцию с базы на базу, которая началась в середине 2021 года и заняла почти год. Получается, мемуары.

Вас ждёт рассказ о том, как мы:

- несколько месяцев чинили тесты и делали трансформер;

- десятки раз переливали данные;

- чинили баги незаметно для пользователей;

- заставили сервис работать на PostgreSQL быстрее, чем он работал на Oracle.

Вступление

File system level backup  в Postgres это первое чему нужно научится при использовании Postgres . Никакие pg_dump \ pg_restore не заменят Полный бэкап на уровне файлов. File system level backup это первая ступень для подготовки к Continuous archiving. Понимание архитектуры хранения – это фундамент, по которому можно понять сможете ли Вы жить с Postgres на больших объемах или у Вас другой путь?

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер), до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя  было сделать проще как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей то лабораторной работы? Статья адресована прежде всего специалистам 1С избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.