title

text

Alicja Kucharczyk
Alicja Kucharczyk Microsoft EMEA Global Blackbelt OSS Data Tech Specialist
Sushant Pandey
Sushant Pandey Microsoft Engineering Architect in the Microsoft India team specializing in relational databases.
13:00 03 марта
22 мин

История одной миграции

В данном рассказе мы хотим рассказать о том, как команда Microsoft, созданная из двух различных команд, работала над проектом, решала проблемы миграции, используя ora2pg, и смогла доказать, что Postgres Single Server может демонстрировать хорошую производительность наравне с Oracle Exadata. Мы расскажем о наших методах работы, а также о ряде основных проблем технического характера, с которыми мы столкнулись, включая миграцию выражений BULK COLLECT, иерархических запросов, курсорных выражений REF CURSOR и других, более сложных конструкций Oracle.

Наша история о практическом подтверждении гипотезы, которое доказало, что Postgres может демонстрировать такую же производительность, как Oracle Exadata. Схема мигрируемой БД была не самой простой. Скорее, наоборот. Код был нагружен динамическими запросами, выражениями BULK COLLECT, вложенными циклами, операторами CONNECT BY, глобальными переменными и множеством зависимостей. Инструмент Ora2pg очень помог нам с преобразованием схемы БД, но всё равно осталось много работы, которую можно было сделать только вручную. Оценки, которые мы получили благодаря инструменту, также оказались очень далеки от истины, поскольку требовалась не просто миграция кода, а изменение его архитектуры. В рамках нашего доклада мы рассмотрим следующие подтемы:

  • Как (не) работают оценки
  • Как мы справились с миграцией выражений BULK COLLECT
  • Почему мы избавились от выражений REF CURSOR
  • Как мы застряли на фазе тестирования одного из пакетов и как помощь друга помогла нам в решении этой проблемы.
  • Как мы справились с иерархическими запросами и детализацией иерархии

Видео

Другие доклады

  • Robert Bernier
    Robert Bernier Percona Старший консультант по PostgreSQL
    45 мин

    Продвинутые техники pg_upgrade

    На сегодняшний день утилита командной строки pg_upgrade является наиболее популярным инструментом для обновления между мажорными версиями Postgres. Однако помимо достоинств, у неё есть и известные проблемы. Одна из наиболее критичных: что делать, если произошёл сбой? Цель данного доклада - раскрыть те маленькие секреты, благодаря которым любой из слушателей сможет существенно улучшить процесс выполнения обновлений.

    Мы начнём с обсуждения базового режима фунционирования pg_upgrade. Потом мы изучим то, что позволяет обновить многотерабайтный кластер за считанные минуты. В конце мы обсудим те самые ситуации сбоя, которых все боятся, а также разберёмся, что делать в случае их возникновения, чтобы обрести уверенность и определённость.

    Список подтем доклада приведён ниже:

    • Как работает pg_upgrade? Общая картина
    • О pg_upgrade (вызов из командной строки)

      • аргументы и опции

    • Пошаговое выполнение обновления
    • О репликации на основе РОЛИ

      • с атрибутом REPLICATION
      • с атрибутом LOGIN

    • Опции для обновления: копирование или жёсткие ссылки?
    • Что делать после обновления?

      • о производительности
      • об анализе
      • о команде REPACK
      • о переиндексации

    • Когда что-то идёт не так, и точка невозврата уже пройдена (пройдена ли?)
    • Обновляем РЕПЛИКУ
      • Метод по умолчанию: pg_basebackup
      • Продвинутый метод:
        • - используем rsync
        • предупреждение: закольцовка vacuum
  • Christopher Travers
    Christopher Travers Adjust GmbH ИТ директор
    45 мин

    Когда всё идёт не так: как надо и как не стоит реагировать на инциденты при поддержке СУБД

    Однажды в Adjust мы столкнулись с проблемой скорого достижения предельного значения xid в очень централизованной базе данных из-за длительной остановки autovacuum. Поскольку мы заметили предупреждения за 5 часов до надвигающейся катастрофы, мы смогли минимизировать влияние проблемы на клиентов. Приходите на доклад, чтобы узнать, как мы использовали это время для подготовки и какие уроки это может преподать всем, кто сталкивается с необычными проблемами в больших базах данных.

  • Максим Орлов
    Максим Орлов Postgres Professional разработчик
    22 мин

    Горячее минорное обновление в Postgres Pro13

    Обновление минорных версий Postgres Pro без остановки сервера и остановки активных сессий.

  • Алексей Фадеев
    Алексей Фадеев Sibedge Старший разработчик .NET, евангелист Postgres
    22 мин

    Multicorn Foreign Data Wrapper против plpython

    Технология Multicorn позволяет разрабатывать FDW на языке Python, что гораздо проще и быстрее создания FDW на языке C. Однако есть и обратная сторона, Multicorn FDW хорошо работают с примитивными условиями WHERE, но на чуть более сложных случаях возникают трудности, про которые я расскажу. Случаи будут рассмотрены на примере моего Multicorn FDW для получения данных OpenStreetMap. Так же я покажу примеры использования одного и того же кода в Multicorn FDW и функции на plpython, в том числе сравнение производительности. В заключение поделюсь своими выводами, когда лучше использовать plpython, а когда Multicorn FDW.