🐘 Говоря об инструменте резервного копирования в составе Digital Q.DataBase, важно отметить, что он обеспечивает не просто сохранность данных, а полноценный комплекс возможностей для администратора.

🟣Поддерживаются полные, дифференциальные и инкрементные бэкапы

🟣Достигается высокая скорость за счёт многопоточности и сжатия

🟣Возможен Point-in-Time Recovery благодаря журналам WAL

🟣Реализована проверка целостности и управление сроками хранения

🟣Встроено шифрование копий для повышения безопасности

В основе инструмента лежит pgBackRest, но мы интегрировали его в платформу Q.DataBase, обеспечили поддержку российских ОС (Astra Linux, РЕД ОС, Альт) и добавили управление через консоль «Центра управления».

Это не отдельный сторонний сервис, а часть экосистемы Q.DataBase — с единым администрированием и технической поддержкой.

🐘 Сегодня хочу рассказать про один из модулей нашей платформы — Систему управления пулом соединений Digital Q.DataBase.

Что это даёт:

🟣Повышает производительность высоконагруженных приложений за счёт сокращения времени установления соединений.
🟣Снижает нагрузку на сервер Digital Q.DataBase, уменьшая количество открытых подключений.
🟣Основана на полностью открытом и импортонезависимом ПО, совместима с российскими дистрибутивами Linux и включена в Единый реестр отечественного ПО.
🟣Построена на базе проверенного инструмента PgBouncer, при этом глубоко интегрирована в нашу платформу.

Функционал:

🟣Создание пула соединений и распределение их между клиентами.
🟣Поддержка трёх режимов работы: транзакционный, сессионный и операторный.
🟣Возможность изменять конфигурацию «на лету» без перезапуска.
🟣Администрирование пользователей и настройка ограничений подключений.

Это решение позволяет стабилизировать работу приложений, ускорить доступ к данным и обеспечить готовность Digital Q.DataBase к задачам цифровой трансформации.

🐘 Обычно статьи про PostgreSQL рассказывают, как сделать его быстрее.

🔥Но автор Jacob Jackson пошёл навстречу другим целям: шаг за шагом настроил Postgres так, чтобы он работал максимально медленно, но всё ещё выполнял хотя бы одну транзакцию.

➡️Технические условия эксперимента:

PostgreSQL 19-devel на Linux
Ryzen 7950X, 32 ГБ RAM, SSD
Бенчмарк TPC-C (128 складов, 100 соединений)
Базовая производительность: ~7082 TPS (транзакций в секунду)

➡️Что именно «сломало» производительность:

🟣Минимальный кэш
Postgres хранит считанные блоки в памяти для ускорения запросов. В нормальной конфигурации с 10 ГБ кэша он выдавал ~7082 TPS. Но при сжатии буфера до 2 МБ производительность рухнула ниже 500 TPS.

🟣Автовакуум на максималках
Обычно autovacuum запускается периодически. Здесь его настроили так, что даже один INSERT сразу вызывал уборку. В комбинации с маленьким кэшем это дало постоянные обращения к диску и падение до ~293 TPS.

🟣WAL в жёстком режиме
Все изменения начали записываться в журнал (WAL) до внесения в базу максимально агрессивно. Результат — TPS упал ниже 100.

🟣Отключение пользы от индексов
Параметры random_page_cost и cpu_index_tuple_cost завысили настолько, что планировщик перестал использовать индексы и перешёл на последовательное сканирование.
Даже при увеличении кэша до 8 МБ TPS стал меньше единицы.

🟣Один поток на всё
Параметры io_method = worker и io_workers = 1 перевели систему в однопоточный режим. Итог — TPS около 0,1.

➡️Итог: ~42 000× медленнее!
На 100 соединениях за 120 секунд завершились всего 11 транзакций — остальные упали с OOM или по таймауту.

➡️Зачем это нужно?
Не ради практической пользы, а чтобы лучше понять, как работает Postgres изнутри.
Иногда изучение пределов системы даёт больше понимания, чем обычная оптимизация.

➡️Оригинал статьи:
byteofdev.com/posts/making-postgres-slow

🐘 Сегодня хочу рассказать о нашем решении — Адаптер к Oracle Database, который входит в платформу Digital Q.DataBase.

➡️Что это даёт бизнесу?

🟣Прозрачный доступ к данным Oracle прямо из Digital Q.DataBase — без ручного экспорта и сложной интеграции.

🟣Возможность выполнять запросы, которые обращаются одновременно к данным в Oracle и в Digital Q.DataBase.

🟣Согласованность транзакций — данные остаются целостными даже при работе сразу с двумя СУБД.

🟣Постепенный переход: Oracle-компоненты можно выносить из инфраструктуры поэтапно, без остановки бизнес-процессов.

Адаптер разработан на базе проверенной технологии oracle_fdw, работает на импортонезависимом стеке и полностью соответствует требованиям цифровой трансформации.

➡️ По сути, это инструмент, который позволяет не делать «большой прыжок» сразу, а разделить его на управляемые шаги: бизнес получает возможность продолжать работу и одновременно постепенно переходить с Oracle на отечественное решение.

🐘 Утилита ora2pg для миграции с Oracle в PostgreSQL существует уже много лет, и многие успели её попробовать ещё в первой половине 2010-х.

С тех пор она стала лишь немного «умнее» и обросла новыми настройками, но архитектурно осталась прежней. Поэтому, несмотря на длительную историю, интерес к ней не угасает — её регулярно упоминают в статьях и обсуждениях.

Что ж, давайте разберёмся, какие у неё сильные и слабые стороны.

🟣Плюсы ora2pg
➕Бесплатна — это open source.
➕Довольно резво переносит структуру таблиц и данные — с bulk-миграцией справляется достойно.
➕Поддерживает выгрузку схем, индексов, последовательностей, представлений и прав.
➕Умеет делать отчёты о сложности миграции, что помогает при планировании.

🟣Минусы ora2pg
➖Perl в основе
Код «олдскульный», поддержка и расширение требуют знаний Perl.
➖Неполная поддержка возможностей Oracle
➖Современные фичи обрабатываются частично или совсем не поддерживаются.
➖Nested tables
Таблицы с NESTED TABLES не конвертируются вообще.
➖Автономные транзакции
Поддерживаются только «костыльно», логика часто ломается.
➖Packages (пакеты)
В Oracle их более 760.
В PostgreSQL есть расширение orafce, где реализованы лишь отдельные функции из самых популярных пакетов (например, dbms_output).
Но это капля в море — реальных поддержанных пакетов меньше десяти.
В итоге после конвертации процедуры, использующие пакеты, содержат вызовы к тому, чего в ванильном PostgreSQL просто нет.
Значит, либо переписывать вручную, либо логика ломается полностью.
➖Ассоциативные массивы, коллекции, VARRAY
Частично конвертируются, часто с потерями или предупреждениями.
➖Динамический SQL
Конвертируется плохо, требует ручной переписки.
➖Хранимая логика (PL/SQL → PL/pgSQL)
Почти никогда не работает «из коробки».
Если процедура заработала без ручной правки — это вам просто очень повезло.
Реалистично воспринимать результат только как «подстрочник» для переписывания.
➖Производительность и оптимизация
Код, сгенерированный утилитой, может быть рабочим, но неоптимальным для PostgreSQL.
➖Сложность освоения
Конфигурационный файл громоздкий и не всегда очевидный.
Без опыта миграции легко запутаться.

➡️Есть и другие инструменты для решения задачи переноса, многие из которых дают результаты лучше, чем ora2pg. О них расскажем в будущих сообщениях. #субд

🐘 В прошлом выпуске говорили про ora2pg — бесплатный, но не всегда полезный инструмент.

Существует и доработанная версия — ora2pgpro.

➡️Форк ora2pg, созданный для использования совместно с Postgres Pro.
➡️ Упор на миграцию из Oracle с учётом «расширенных» фич (автономные транзакции, пакеты, коллекции).
➡️ Более умный парсинг PL/SQL → PL/pgSQL (AST вместо регулярок).

🟣Плюсы ora2pgpro

➕ Лучше понимает сложный PL/SQL, меньше ручных правок.
➕ Конвертирует вызовы, которые обычная ora2pg оставляет TODO.
➕ Поддерживает ассоциативные массивы, пакеты и init-функции.
➕ Даёт более чистый и предсказуемый результат миграции.

🟣Минусы ora2pgpro

➖ Работает только с Postgres Pro — на «ванильном» или облачном PostgreSQL просто бесполезен.
➖ Код открыт (это по-прежнему Perl), но лицензия запрещает самостоятельные доработки, чтобы никто не адаптировал под другие форки PostgreSQL.
➖ Пользу от этого инструмента могут получить только те, кто приобрёл лицензию на Postgres Pro.

➡️ В следующем посте я расскажу про Конвертум - еще один популярный инструмент для миграции БД на PostgreSQL.

🐘 После ora2pg и ora2pgpro самое время взглянуть на Конвертум
Ещё один претендент на звание «спасителя миграций».
Разберём, что он делает хорошо, а где придётся вздохнуть и править руками.

Плюсы
➕ Конвертация процедур быстрая и точная — используется синтаксический анализ на уровне AST, а не простые регулярки.
Тут они реально лучше ora2pg и даже ora2pgpro.
➕ Есть бесплатный сканер — можно хотя бы понять масштаб бедствия перед тем, как достать кошелёк.
➕ Обещают офлайн-режим и работу только с правами на чтение — базу не испортят.
➕ Гибкость: заявляют, что могут быстро добавить правила под конкретный проект — звучит неплохо.

Минусы (и тут интереснее)
➖ Инструмент полностью коммерческий — без лицензии не запустится, без поддержки далеко не уедешь.
➖ Не учитывает расширенные возможности российских форков PostgreSQL (кроме Postgres Pro) — нативные пакеты Oracle, реализованные dbms_-пакеты и прочие фишки останутся за кадром.
➖ Красивые слова про поддержку PL/SQL на сайте — это здорово, но что реально конвертируется без ручных правок, узнаешь только в бою.
➖ Почти всегда придётся подключать их команду - иначе риск получить полуфабрикат.
➖ Ну и всё это удовольствие стоит денег.

➡️ Несмотря на всё это, Конвертум показал лучшие результаты среди уже рассмотренных инструментов, особенно в части конвертации процедур.

🔥 В следующий раз я расскажу вам, как перенести данные из Oracle или Microsoft SQL Server в Digital Q.DataBase, используя инструменты Диасофт.

🐘 В предыдущих статьях мы рассмотрели ряд инструментов для миграции баз с Oracle на PostgreSQL и его форки.

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

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

Если в СУБД нет аналогов для используемых в оригинальном PL/SQL-коде функций dbms-пакетов, нет понятия пакетов, нет ряда механизмов — ничего работоспособного почти наверняка не получится.

🟣Лучшее, на что можно рассчитывать, — это перенос данных (и то не факт — привет от nested tables, несовпадающих типов и пр.) и какая-то конвертация текста хранимых процедур и функций к синтаксису PostgreSQL, в общем случае представляющая собой «подстрочник» или «черновик» для последующих ручных исправлений.

Продолжение ⬇️

➡️ Работая над Digital Q.DataBase, мы опирались на свой предыдущий опыт создания автоматизированных инструментов миграции хранимой бизнес-логики и сделали по-настоящему революционный шаг.

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

Это значит, что СУБД должна уметь исполнять не только PL/pgSQL, но и PL/SQL, и даже T-SQL — напрямую, без промежуточных преобразований и ручных миграций.

В ней должны быть:

🟣все встроенные функции, привычные разработчикам Oracle и SQL Server,
🟣поддержка создания пакетов «как в Oracle»,
🟣системные таблицы и представления или их эмуляция,
🟣dbms_- и utl_-пакеты Oracle,
🟣аналоги востребованных sp_-процедур из MS SQL и многое другое.

Когда в СУБД есть всё это, миграция с зарубежной платформы проходит просто, быстро и без боли.

Продолжение ⬇️⬇️

➡️ Главный принцип диасофтовского «Мастера переноса БД в Digital Q.DataBase» — выгрузка и перенос всего содержимого базы данных как есть, без каких-либо преобразований.

🔥 Это первая в России миграция без конвертации.
Конвертация к синтаксису PostgreSQL для Q.DataBase просто не нужна - она прекрасно понимает и непреобразованные скрипты от MS SQL и Oracle.
Никто не вмешивается в текст ваших хранимых процедур или функций, которые успешно работали в зарубежной СУБД.
Они загружаются в Q.DataBase без изменений и работают максимально близко к оригиналу.

➡️ Мы также учли, что не все DBA любят командную строку, и снабдили инструмент графическим фронтендом в стиле «нажми кнопку — дальше, дальше, дальше — и готово».

➡️ Инструмент работает как на Linux-системах, так и под Windows. Он может создать копию имеющейся БД из Oracle или Microsoft SQL Server как напрямую в Digital Q.DataBase, так и «сдампить» её в набор SQL-файлов, которые при желании можно загрузить даже обратно в исходную зарубежную СУБД.

Продолжение ⬇️⬇️⬇️

➡️ Забавно, но с задачей скриптования больших баз Мастер переноса справляется лучше оригинальных средств.

Когда Generate SQL Scripts в Microsoft SSMS падает с ошибкой «Out of memory», Мастер всё равно генерирует скрипты до конца.

Поэтому им пользуются даже те, кто ещё не перешёл на Digital Q.DataBase.

А те, кто уже перешёл, активно запускают PL/SQL и T-SQL наравне с родным #PostgreSQL

И мы продолжаем нашу историю ⬇️⬇️⬇️

➕ Так какие же плюсы использования нашего Мастера переноса БД?

1️⃣Есть GUI и CLI — на выбор, новичкам удобно, профи довольны.

2️⃣Кроссплатформенность — работает на Linux и Windows.

3️⃣Высокая скорость миграции — 10-террабайтная база переносится меньше чем за сутки.

4️⃣Сохранение в неприкосновенности всей хранимой логики и прав пользователей, никаких трансформаций — код хранимок переносится "как есть". После завершения миграции система сразу готова к работе.

5️⃣Многопоточность — при запуске инструмент автоматически определяет конфигурацию оборудования и использует имеющиеся аппаратные ресурсы максимально эффективным образом.

6️⃣При возникновении в процессе переноса БД нештатных ситуаций информация о них автоматически заносится в файл журнала, который можно легко отправить в поддержку.

7️⃣Проблемы с различными кодировками кириллицы решаются на лету — миграция БД проходит без сюрпризов, в отличие от оригинальных инструментов Oracle.

8️⃣Инструмент имеет ценность даже в отрыве от СУБД Digital Q.DataBase - его можно использовать как бесплатное средство для создания полного SQL-дампа Вашей БД.

В заключение отмечу и один минус — он тут всего лишь один.

Наш инструмент «Мастер переноса БД» предполагает, что целевая СУБД умеет выполнять все то, что работало в исходной.

➡️ На текущий момент только одна российская СУБД умеет исполнять PL/SQL и T-SQL без из преобразования.

Поэтому полные возможности инструмента доступны лишь в его связке с нашей СУБД - Digital Q.DataBase.

Использовать его для миграции на «ванильный» PostgreSQL или его коммерческие форки с "недоразвитыми" по сравнению с MS SQL и Oracle функциональными возможностями нет никакого практического смысла.

➡️ Вывод
Мастер переноса БД в Digital Q.DataBase — это не просто утилита, а мост между популярными зарубежными и российской СУБД.

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

Если вы всё ещё думаете, стоит ли пробовать Digital Q.DataBase, — начните с знакомство с ней с этого инструмента. Вы удивитесь тому, как просто может выглядеть миграция Вашей БД.

🐘 Мы исправили ошибку в крупном банке, которая в определённых случаях приводила к полному падению сервера.

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

🧬 Ошибка затрагивает «ванильный» PostgreSQL 17-й версии и, с высокой вероятностью, может встречаться и в других форках.

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

Страшно представить, что было бы, если бы банк остался с этой нетривиальной проблемой один на один.

🧰 Само исправление в итоге заняло всего один день.

👾 А вот и моя статья на Хабре!

🟣Можно ли перейти с Oracle или MS SQL на СУБД из Реестра российского ПО без переписывания всей хранимой логики?

🟣Один из возможных подходов к решению этой задачи.

#dqdb #cубд

🔄https://habr.com/ru/articles/949980/

🐘 Пилотные показы / СКАЧАТЬ

🔄Скачать дистрибутив
Мы поддерживаем Alt Linux 11, Astra Linux 1.8, Red OS 8.0 и Ubuntu 22.04 LTS

🟣Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.

🎥 Запись на Rutube
Разбираю ключевые возможности платформы и показываю живые примеры в действии.

📩 Написать нам можно:

— в личку 👉 @zavrius
— на почту 👉 azhuykov@diasoft.ru
— через форму 👉
https://database.diasoft.ru/?utm_source=tgdqdatabase#contacts

➡️ Хотите увидеть в деле российскую СУБД-полиглот на базе PostgreSQL, которая исполняет T-SQL и PL/SQL без переписывания?
Это ваш шанс.

➡️ Мы уже перевели систему с 92 000 таблиц и 6,5 млн строк
T-SQL-кода с MS SQL Server на российскую СУБД из Реестра.
Да, это реально.

➡️ Замена Oracle или MS SQL Server?
✓ dbms-пакеты работают
✓ плавный переход
✓ экономия времени и денег

Подписывайтесь, чтобы узнать подробности и записаться на показ демо!

🔥 Вчера мы провели вебинар — знаю, что на него подписались многие участники.

Спасибо, что читаете и следите за новостями! 🙌

Хотел бы зафиналить общие вопросы по итогам встречи.

🔄 Миграции с Oracle и MS SQL
Реализованы собственные стеки исполнения PL/SQL и T-SQL, включая поддержку системных таблиц и представлений, а также режима «грязного чтения» для MS SQL.
Код переносится без переписывания: SQL, загруженный в Digital Q.DataBase, можно вернуть обратно в Oracle или MS SQL, получив идентичное наполнение базы данных.

🔄 Скорость миграции
Реальный кейс: 10 ТБ данных было перенесено за двое суток.
Синтетические тесты показывают применимость Мастера миграции на базах объёмом вплоть до петабайта.

🔄 Реальные российские внедрения
1С, крупная система управления персоналом, банковские и депозитарные решения — всё успешно переведено на Digital Q.DataBase.
Oracle-пилоты также проходят; там результаты пока скромнее — всё упирается в недостаток DBMS-пакетов, однако недостающие модули сейчас активно реализуются.

🔄 Кластеризация
Поддерживается горизонтальное масштабирование через HAProxy для всех режимов эксплуатации: замена MS SQL, Oracle, PostgreSQL.

🔄 Демоверсия
Скоро появится на сайте. Это полноценная версия с ограничением до 8 ядер — разрешена даже для коммерческого использования.

🔄 Обновления ядра
Переход на PostgreSQL 18 находится в активной фазе.
Для разработчиков — очередной плановый апгрейд без боли.

🔄 Совместное применение различных диалектов
Можно подключаться к одной базе в режиме совместимости с PostgreSQL, MS SQL или Oracle — при этом видны все данные, независимо от того, каким образом они были внесены в БД.
Можно также вызывать хранимые процедуры на PL/SQL или T-SQL из режима совместимости с PostgreSQL — и они будут корректно исполнены соответствующим интерпретатором.

🔄 Производительность
В договорах мы гарантируем просадку не более 15 %.
На практике всё работает иногда даже быстрее оригинала.
Например, в нашей АБС 87 % операций выполняются на том же уровне или быстрее, чем в MS SQL.

🔄 Резервное копирование
Совместимо со всеми системами, работающими с PostgreSQL.
Используются стандартный pg_basebackup и продвинутый pgBackRest — с инкрементальными копиями, сжатием, шифрованием и хранением в облаках.

🟣Главная мысль:
У российских компаний появилась достойная замена MS SQL и Oracle — решение, не требующее изменения кода существующих приложений.
Вместо переписывания прикладной логики используется СУБД из реестра российского ПО, максимально точно воспроизводящая диалекты зарубежных СУБД.