PGConf.Russia 2023

Предлагается вашему вниманию наш опыт по миграции данных и написанную на Java программу Ora2PgCopy для высокоскоростного переноса данных из Oracle в Postgres, которая применяется после создания таблиц и переноса программного кода прикладных систем. Высокая скорость переноса данных обеспечивается за счёт использования Postgres-команды “copy”, применения многопоточной технологии Java для обработки файлов, управления опцией таблиц nologged/ logged, поддержки типов данных LOB и CLOB. По результатам тестов Ora2PgCopy работает заметно быстрее таких аналогов как: Ispirer (convertum), oracle_fdw, ora2pg, Pentaho kettle. Ora2PgCopy может функционировать как модуль в составе системы автоматизации миграции (САМ) LUI4ORA2PG, так и независимо от неё. С историей развития инструмента разработки web-приложений Live Universal Interface (LUI) и инструмента миграции LUI4ORA2PG, можно ознакомится по предыдущим выступлениям на конференциях PgConf: https://pgconf.ru/2019/118109, https://pgconf.ru/201911/264095, https://pgconf.ru/2020/262456, https://pgconf.ru/2021/288310,
https://pgconf.ru/2022/316022.

Adaptive Query Optimization (AQO) - это механизм, использующий данные о предыдущем исполнении, которые могут быть использованы для корректировки последующих планов запросов. В докладе подробнее обсуждается, как данное расширение при совместной работе с оптимизатором может помочь решить некоторые проблемы в оптимизации запросов.

В этом докладе я расскажу сразу о нескольких новых возможностях наблюдения за нагрузкой в СУБД. Среди них будут: визуализация истории наблюдений расширений pg_profile/pgpro_pwr с использованием Grafana; активные отчеты pg_profile/pgpro_pwr, позволяющие выполнять подсветку исследуемых объектов в разных секциях отчета; дальнейшее развитие расширенных статистик вакуума в версиях PostgresPro; новый интересный механизм трассировки сессий и запросов в расширении pgpro_stats.

В процессе эксплуатации баз достаточно больших 1С на СУБД PostgreSQL часто возникают вопросы, ответы на которые не так просто найти даже в документации. Хотелось бы поделиться опытом решения таких вопросов на базе нескольких переводов 1С с MS SQL на PostgreSQL клиентов из рейтинга РБК500. В докладе будут освещены такие моменты как: Как регулировать уровень глубины расчёта статистики и чем это может быть опасно? Как создание явной и неявной временной таблицы может "положить" сервер СУБД и как с этим бороться? В каком случае процесс СУБД будет убит операционной системой из-за перерасхода оперативной памяти и что с этим делать? Чем хорошо когда на одном кластере СУБД одна база, чем плохо когда много баз на одном кластере СУБД? Как быть с ресурсами серверов для сред тестирования и разработки при подходе "1 кластер - 1 база"? Резервное копирование- тонкости разных вариантов снятия бэкапов на PostgreSQL.