Данная статья является продолжением этой статьи: Инструкция: как перейти в сферу 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.
Быстрое развитие проекта несет в себе множество сложностей: большая вероятность сломать старый функционал или привнести новые баги. Одним из способов поддержания качества кода в хорошем состоянии – это покрытие кода 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.
Слабые уровни изоляции могут быть причиной очень труднонаходимых багов. Причём эти баги могут вызвать уязвимости в безопасности.
Из-за подобных багов уже были украдены миллионы долларов, в частности с биткоин-бирж. Мы расскажем о подобных случаях более детально в следующих разделах.
