Проектирование и повышение производительности миграции из Oracle

Эта статья представляет собой первую из семи статей, посвященных рекомендациям по миграции данных из Oracle в Azure Synapse Analytics. В ней приведены рекомендации по проектированию и повышению производительности.

Обзор

Из-за затратности и сложности обслуживания и обновления устаревших локальных сред Oracle многие существующие пользователи Oracle хотят воспользоваться преимуществами инноваций, предоставляемых современными облачными средами. Облачные среды типа "инфраструктура как услуга" (IaaS) и "платформа как услуга" (PaaS) позволяют делегировать такие задачи, как обслуживание инфраструктуры и разработка платформы, поставщику облачных служб.

Совет

Среда Azure — это нечто большее, чем обычная база данных. Она включает полный набор возможностей и инструментов.

Хотя Oracle и Azure Synapse Analytics являются базами данных SQL, использующими методы массовой параллельной обработки (MPP) для обеспечения высокой производительности запросов к исключительно большим объемам данных, между ними есть некоторые базовые различия в подходах.

• Устаревшие системы Oracle часто устанавливаются локально и используют относительно дорогостоящее оборудование. Azure Synapse работает в облаке и использует хранилище, а также вычислительные ресурсы Azure.

• Обновление конфигурации Oracle — это сложная задача, требующая дополнительного физического оборудования и потенциально длительной перенастройки базы данных или создания дампа и перезагрузки. Поскольку хранилище и вычислительные ресурсы в среде Azure работают отдельно и поддерживают эластичное масштабирование, их масштаб можно независимо вертикально увеличивать или уменьшать.

• Вы можете приостанавливать работу Azure Synapse и изменять размер службы, чтобы сэкономить на используемых ресурсах и затратах.

Microsoft Azure — это глобально доступная, масштабируемая облачная среда с высоким уровнем безопасности, которая включает в себя Azure Synapse и экосистему вспомогательных средств и возможностей. На следующей схеме представлена экосистема Azure Synapse.

Azure Synapse обеспечивает более высокую производительность реляционной базы данных с помощью таких методов, как MPP и автоматическое кэширование в памяти. Результаты применения этих приемов описаны в отчетах о независимых тестах производительности, например от GigaOm, где Azure Synapse сравнивается с другими популярными облачными хранилищами данных. Клиенты, которые переносятся в среду Azure Synapse, получают целый ряд преимуществ, включая следующие:

• улучшение показателей производительности, а также соотношения цены и производительности;

• Увеличение гибкость и сокращение срока окупаемости.

• Увеличение скорости развертывания серверов и разработки приложений.

• эластичная масштабируемость — плата только за фактическое использование;

• улучшение показателей безопасности и соответствия требованиям;

• Снижение затрат на хранение и аварийное восстановление.

• уменьшение общей совокупной стоимости владения, улучшение контроля затрат и оптимизация эксплуатационных расходов (OPEX).

Чтобы в полной мере использовать эти преимущества, перенесите новые или существующие данные и приложения на платформу Azure Synapse. Во многих организациях миграция включает перенос существующего хранилища данных с устаревшей локальной платформы, например Oracle, в Azure Synapse. В целом процесс миграции включает следующие этапы:

    Подготовка 🡆

• Определите область (что именно нужно перенести).

• Составьте список данных и процессов для миграции.

• Определите изменения модели данных (при их наличии).

• Определите механизм извлечения исходных данных.

• Определите оптимальные средства и функции Azure и сторонних производителей.

• Сразу же проведите обучение персонала на новой платформе.

• Настройте целевую платформу Azure.

    Миграция 🡆

• Начните с малого.

• Автоматизируйте все, что возможно.

• Используйте встроенные средства и функции Azure, чтобы уменьшить трудоемкость переноса.

• Перенесите метаданные для таблиц и представлений.

• Перенесите исторические данные, которые требуется сохранить.

• Произведите миграцию или рефакторинг хранимых процедур и бизнес-процессов.

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

    После миграции

• Отслеживайте и документируйте все этапы процесса.

• На основе полученного опыта создайте шаблон для будущих миграций.

• При необходимости переработайте модель данных с учетом производительности и масштабируемости новой платформы.

• Протестируйте приложения и средства запросов.

• Протестируйте и оптимизируйте производительность запросов.

В этой статье приведены общие сведения и рекомендации по оптимизации производительности при переносе хранилища данных из существующей среды Oracle в Azure Synapse. Цель оптимизации производительности — достичь той же или более высокой производительности хранилища данных в Azure Synapse после миграции.

Рекомендации по проектированию

Область миграции

При подготовке к миграции из среды Oracle рассмотрите перечисленные ниже варианты миграции.

Выбор рабочей нагрузки для начальной миграции

Традиционные среды Oracle обычно развивались в динамике, охватывая новые предметные области и смешанные рабочие нагрузки. Если вы решаете, с чего начать проект начальной миграции, выберите область, которая обладает следующими особенностями:

• дает возможность подтвердить жизнеспособность перехода на Azure Synapse, быстро предоставив преимущества новой среды;

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

• позволяет создать шаблон для дальнейшей миграции, относящийся к исходной среде Oracle, а также к текущим средствам и процессам, которые уже существуют.

Хороший кандидат на начальную миграцию из среды Oracle соответствует указанным выше условиям, а также:

• реализует рабочую нагрузку бизнес-аналитики, а не рабочую нагрузку обработки транзакций (OLTP);

• использует модель данных, например типа "звезда" или "снежинка", которую можно перенести с минимальными изменениями.

Совет

Проведите инвентаризацию объектов для переноса и задокументируйте процесс миграции.

Объем данных миграции для начальной задачи должен быть достаточно большим, чтобы можно было показать возможности и преимущества среды Azure Synapse, но при этом быстро продемонстрировать ценность. Как правило, такой объем составляет от 1 до 10 терабайт.

При миграции в первую очередь необходимо минимизировать риски, усилия и время, необходимые для быстрой реализации преимуществ облачной среды Azure. Следующие подходы ограничивают область начальной миграции только киосками данных и не рассматривают более широкие аспекты, такие как миграция ETL и перенос исторических данных. Однако эти аспекты можно реализовать на последующих этапах проекта после того, как перенесенный уровень киоска данных будет заполнен данными и необходимыми процессами сборки.

Перенос по методу lift-and-shift и поэтапный подход

Как правило, независимо от цели и области применения плановой миграции существует два метода: lift-and-shift без изменений и поэтапный подход, включающий изменения.

Методика lift-and-shift

В рамках подхода lift-and-shift существующая модель данных, например схема "звезда", переносится на новую платформу Azure Synapse без изменений. Упор делается на минимизацию рисков и времени миграции путем уменьшения объема работ, необходимого для реализации преимуществ перехода на облачную среду Azure. Миграция lift-and-shift подходит для следующих сценариев:

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

Совет

Lift-and-shift является хорошей отправной точкой, даже если на последующих этапах в модель данных будут вноситься изменения.

Поэтапный подход, включающий изменения

Если устаревшее хранилище развивалось в течение длительного времени, возможно, его потребуется модернизировать для обеспечения необходимых уровней производительности. или поддержки новых данных, например потоков Интернета вещей. В рамках процесса модернизации вы можете перейти на Azure Synapse, чтобы получить преимущества масштабируемой облачной среды. Миграция может включать изменение базовой модели данных, например переход с модели Inmon на хранилище данных.

Корпорация Майкрософт рекомендует переместить существующую модель данных в Azure и использовать производительность и гибкость среды Azure, чтобы применить современные изменения. Так вы сможете задействовать возможности Azure для внесения изменений, не затрагивая существующую исходную систему.

Использование ресурсов Microsoft для выполнения миграции на основе метаданных

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

Помощник по миграции SQL Server (SSMA) для Oracle может автоматизировать многие части процесса миграции, в том числе в некоторых случаях функции и процедурный код. SSMA поддерживает Azure Synapse в качестве целевой среды.

SSMA для Oracle помогает перенести хранилище данных Oracle или киоск данных в Azure Synapse. SSMA предназначена для автоматизации миграции таблиц, представлений и данных из существующей среды Oracle.

Фабрика данных Azure — это облачная служба интеграции данных, которая позволяет создавать управляемые данными рабочие процессы в облаке для оркестрации и автоматизации перемещения и преобразования данных. С помощью Фабрики данных можно создавать и включать в расписание управляемые данными рабочие процессы (конвейеры), которые принимают данные из разнородных хранилищ. Фабрика данных может обрабатывать и преобразовывать эти данные с помощью таких служб вычислений, как Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics и машинное обучение Azure.

Фабрика данных может использоваться для переноса данных из источника в целевой объект Azure SQL. Подобное перемещение данных в автономном режиме помогает значительно сократить время простоя из-за миграции.

Для планирования и выполнения миграции из таких сред, как Oracle, также можно использовать службы миграции Azure Database Migration Service.

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

Различия между Oracle и Azure Synapse с точки зрения проектирования

Как упоминалось ранее, существуют некоторые базовые различия в подходе между базами данных Oracle и Azure Synapse Analytics. SSMA для Oracle не только помогает преодолеть эти пробелы, но и автоматизировать миграцию. Хотя SSMA не очень эффективна при обработке очень больших объемов данных, она удобна для небольших таблиц.

Несколько или одна база данных и схемы

Среда Oracle часто содержит несколько отдельных баз данных. Например, могут существовать отдельные базы для приема данных и промежуточных таблиц, основных таблиц хранилища и киосков данных (иногда это называется семантическим слоем). Обработка данных в конвейерах ETL (извлечение, преобразование и загрузка) и ELT (извлечение, загрузка и преобразование) может реализовывать соединения между отдельными базами данных и перемещать данные между ними.

В то же время среда Azure Synapse содержит единственную базу данных и использует схемы для разделения таблиц на логически изолированные группы. Мы рекомендуем использовать несколько схем в целевой базе данных Azure Synapse, чтобы смоделировать все отдельные базы данных, перенесенные из среды Oracle. Если в среде Oracle уже используются схемы, для перемещения существующих таблиц и представлений Oracle в новую среду может потребоваться новое соглашение об именовании. Например, можно сцепить имена существующих схем и таблиц Oracle с именем новой таблицы Azure Synapse, а затем использовать имена схем в новой среде для сохранения имен исходных отдельных баз данных. Для сохранения логических структур можно использовать представления SQL поверх базовых таблиц, однако у такого подхода есть ряд потенциальных недостатков.

• Представления в Azure Synapse доступны только для чтения, поэтому любые изменения данных должны вноситься в базовые таблицы.

• У вас уже может быть реализован один или несколько уровней представлений, и добавление еще одного уровня может повлиять на производительность.

Совет

Объедините несколько баз данных в отдельную базу данных в Azure Synapse и используйте имена схем для логического разделения таблиц.

Рекомендации по таблице

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

Механизмы оптимизации производительности в исходной среде, например индексы, помогают понять, как именно можно оптимизировать производительность в новой среде. Например, если индексы, сопоставленные с битами, часто используются в запросах в исходной среде Oracle, это предполагает необходимость создания некластеризованного индекса в Azure Synapse. Вместо прямого воссоздания индексов бывает целесообразно воспользоваться другими нативными методами оптимизации производительности, например репликацией таблиц. SSMA для Oracle может использоваться для предоставления рекомендаций по миграции для распределения таблиц и индексирования.

Совет

Существующие индексы помогают найти кандидатов на индексирование в перенесенном хранилище.

Неподдерживаемые типы объектов базы данных Oracle

Функции Oracle можно заменить функциями Azure Synapse. Однако Azure Synapse не поддерживает некоторые объекты базы данных Oracle напрямую. В следующем списке неподдерживаемых объектов базы данных Oracle описывается, как реализовать эквивалентные функциональные возможности в Azure Synapse.

• Различные параметры индексирования: в Oracle существует несколько вариантов индексирования, таких как индексы, сопоставленные с битами, индексы на основе функций и доменные индексы, которые не имеют прямого эквивалента в Azure Synapse.

  Узнать, какие столбцы индексируются и тип индекса можно следующим образом:

  • Отправив запросы к таблицам и представлениям системного каталога, таким как ALL_INDEXES, DBA_INDEXES, USER_INDEXES и DBA_IND_COL. Встроенные запросы можно использовать в Oracle SQL Developer, как показано на следующем снимке экрана.

    

    Или выполните следующий запрос, чтобы найти все индексы заданного типа:

    SELECT * FROM dba_indexes WHERE index_type LIKE 'FUNCTION-BASED%';
    

  • Отправив запросы представлениям dba_index_usage или v$object_usage, если включен мониторинг. В Oracle SQL Developer можно отправлять запросы этим представлениям, как показано на следующем снимке.

    

  Индексы на основе функций, где индекс содержит результат функции в базовых столбцах данных, не имеют прямого эквивалента в Azure Synapse. Рекомендуется сначала перенести данные, а затем в Azure Synapse выполнить запросы Oracle, использующие индексы на основе функций, для оценки производительности. Если производительность этих запросов в Azure Synapse неприемлема, рассмотрите возможность создания столбца, содержащего предварительно вычисляемое значение, а затем индексируйте этот столбец.

  При настройке среды Azure Synapse имеет смысл реализовать только используемые индексы. Azure Synapse в настоящее время поддерживает перечисленные ниже типы индексов:

  

  Функции Azure Synapse, такие как параллельная обработка запросов и кэширование в памяти данных и результатов, обуславливают вероятность того, что для достижения высокой производительности приложениям хранилища данных потребуется меньше индексов. В Azure Synapse рекомендуется использовать следующие типы индексов:

  • Кластеризованные индексы columnstore: если для таблицы не указаны параметры индекса, Azure Synapse по умолчанию создает кластеризованный индекс columnstore. Кластеризованные таблицы columnstore обеспечивают самый высокий уровень сжатия данных, оптимальную общую производительность запросов и, как правило, превосходят по производительности кластеризованный индекс или таблицы без кластеризованных индексов Кластеризованный индекс columnstore обычно лучше всего подходит для больших таблиц. При создании таблицы выберите кластеризованный индекс columnstore, если вы не знаете, как индексировать таблицу. Однако существуют некоторые сценарии, в которых кластеризованные индексы columnstore не являются лучшим вариантом.

    • Таблицы с данными предварительной сортировки для ключей сортировки могут воспользоваться ликвидацией сегмента, включенной с помощью упорядоченных кластеризованных индексов columnstore.
    • Таблицы с типами данных varchar(max), nvarchar(max) или varbinary(max), так как кластеризованный индекс columnstore не поддерживает эти типы данных. Вместо этого рекомендуется использовать кучу или кластеризованный индекс.
    • Таблицы с временными данными, так как таблицы columnstore могут быть менее эффективными, чем куча или временные таблицы.
    • При наличии небольших таблиц, содержащих меньше 100 млн строк. Вместо этого рассмотрите возможность использования таблиц без кластеризованных индексов.

  • Упорядоченные кластеризованные индексы columnstore. Благодаря включению эффективной ликвидации сегментов упорядоченные кластеризованные индексы columnstore в выделенных пулах SQL Azure Synapse обеспечивают гораздо быстрее производительность, пропуская большие объемы упорядоченных данных, которые не соответствуют предикату запроса. Загрузка данных в упорядоченную таблицу CCI может занять больше времени, чем в неупорядоченную таблицу CCI, из-за операции сортировки данных, однако запросы могут выполняться быстрее с упорядоченным CCI. Дополнительные сведения см. в статье Настройка производительности с помощью упорядоченного кластеризованного индекса columnstore.

  • Кластеризованные и некластеризованные индексы: если требуется быстро извлечь одну строку, кластеризованные индексы могут проявить себя лучше кластеризованных индексов columnstore. Для запросов, подразумевающих очень быстрый поиск одной или нескольких строк, рассмотрите возможность использования кластеризованного индекса или некластеризованного вторичного индекса. Недостаток использования кластеризованного индекса заключается в том, что эффективными будут только те запросы, в которых используется высокоизбирательный фильтр для столбца с кластеризованным индексом. Чтобы улучшить фильтрацию по другим столбцам, можно добавить некластеризованный индекс в другие столбцы. Однако каждый индекс, добавляемый в таблицу, использует больше места и увеличивает время обработки при загрузке.

  • Таблицы без кластеризованных индексов: при временном размещении данных в Azure Synapse может обнаружиться, что использование таблицы без кластеризованных индексов ускорит процесс в целом. Это связано с тем, что загрузка данных в таблицы без кластеризованных индексов выполняется быстрее, чем загрузка данных в таблицы с индексами, а в некоторых случаях последующие операции чтения можно выполнять из кэша. Если данные загружаются только на время, для подготовки к другим преобразованиям, гораздо быстрее загрузить их в таблицу без кластеризованных индексов, а затем в кластеризованную таблицу columnstore. Кроме того, загрузка данных во временную таблицу выполняется быстрее, чем загрузка таблицы в постоянное хранилище. Для небольших таблиц подстановки с менее 100 млн строк обычно рекомендуется выбирать таблицы без кластеризованных индексов. Сжатие в кластеризованных таблицах columnstore выполнятся оптимально при наличии более 100 миллионов строк.

• Кластеризованные таблицы: таблицы Oracle можно упорядочить так, чтобы строки таблиц, доступ к которым часто осуществляется совместно (на основе общего значения), хранились бы вместе физически, чтобы уменьшить количество дисковых операций ввода-вывода при извлечении данных. Oracle также предоставляет параметр хэш-кластера для отдельных таблиц, который применяет хэш-значение к ключу кластера и физически хранит строки с одинаковым хэш-значением. Чтобы получить список кластеров в базе данных Oracle, используйте запрос SELECT * FROM DBA_CLUSTERS;. Чтобы определить, находится ли таблица в кластере, используйте запрос SELECT * FROM TAB;, который показывает имя таблицы и идентификатор кластера для каждой таблицы.

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

• Материализованные представления. Oracle поддерживает материализованные представления и рекомендует использовать одно или несколько из них в больших таблицах с большим количеством столбцов, где в запросах регулярно используются только некоторые из этих столбцов. Материализованные представления автоматически обновляются системой при обновлении данных в базовой таблице.

  В 2019 году Microsoft объявила, что Azure Synapse будет поддерживать материализованные представления с теми же функциями, что и Oracle. Материализованные представления уже доступны в Azure Synapse в качестве предварительной версии функции.

• Триггеры в базе данных: в Oracle триггер можно настроить для автоматического запуска при возникновении события активации. Событиями активации могут быть следующие:

  • Инструкция языка обработки данных (DML), например INSERT, UPDATE или DELETE, выполняется в таблице. Если вы определили триггер, который срабатывает перед инструкцией INSERT в таблице клиента, триггер сработает один раз, прежде чем новая строка будет вставлена в таблицу клиента.

  • Выполняется инструкция DML, такая как CREATE или ALTER. Этот триггер часто используется в целях аудита для фиксации изменений в схеме.

  • Системное событие, например запуск или завершение работы базы данных Oracle.

  • Событие пользователя, например вход или выход.

  Можно получить список триггеров, определенных в базе данных Oracle, запросив представления ALL_TRIGGERS, DBA_TRIGGERS или USER_TRIGGERS. На следующем снимке экрана показан запрос DBA_TRIGGERS в Oracle SQL Developer.

  

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

• Синонимы: Oracle поддерживает определение синонимов в качестве альтернативных названий нескольких типов объектов баз данных. К этим типам объектов относятся таблицы, представления, последовательности, процедуры, хранимые функции, пакеты, материализованные представления, объекты схемы классов Java, определяемые пользователем объекты или другие синонимы.

  Azure Synapse в настоящее время не поддерживает определение синонимов, хотя если синоним в Oracle ссылается на таблицу или представление, можно определить представление в Azure Synapse, которое бы соответствовало альтернативному названию. Если синоним в Oracle ссылается на функцию или хранимую процедуру, можно создать в Azure Synapse другую функцию или хранимую процедуру с именем, соответствующим синониму, которая вызывает целевой объект.

• Пользовательские типы: Oracle поддерживает пользовательские объекты, которые могут содержать ряд отдельных полей, каждое из которых содержит собственное определение и значения по умолчанию. На эти объекты можно ссылаться в определении таблицы так же, как на встроенные типы данных, такие как NUMBER или VARCHAR. Можно получить список определяемых пользователем типов в базе данных Oracle, запросив представления ALL_TYPES, DBA_TYPES или USER_TYPES.

  Azure Synapse в настоящее время не поддерживает пользовательские типы. Если данные, необходимые для переноса, включают пользовательские типы данных, преобразуйте их в плоскую структуру (обычное определение таблицы), а если они представляют собой массивы данных — в отдельную таблицу.

Сопоставление типов данных Oracle

Большинство типов данных Oracle имеют прямой эквивалент в Azure Synapse. В таблице ниже представлены рекомендованные способы работы для сопоставления типов данных Oracle c Azure Synapse.

Тип данных Oracle	Тип данных Azure Synapse
BFILE	Не поддерживается. Сопоставление с VARBINARY (MAX).
BINARY_FLOAT	Не поддерживается. Сопоставление с FLOAT.
BINARY_DOUBLE	Не поддерживается. Сопоставление с DOUBLE.
BLOB-объект	Не поддерживается напрямую. Замена на VARBINARY(MAX).
CHAR	CHAR
CLOB	Не поддерживается напрямую. Замена на VARCHAR(MAX).
DATE	DATE в Oracle также может содержать сведения о времени. Сопоставление DATE или TIMESTAMP в зависимости от использования.
DECIMAL	DECIMAL
DOUBLE	PRECISION DOUBLE
FLOAT	FLOAT
INTEGER	INT
INTERVAL YEAR TO MONTH	Типы данных INTERVAL не поддерживаются. Используйте функции сравнения дат, такие как DATEDIFF или DATEADD, для вычисления дат.
INTERVAL DAY TO SECOND	Типы данных INTERVAL не поддерживаются. Используйте функции сравнения дат, такие как DATEDIFF или DATEADD, для вычисления дат.
LONG	Не поддерживается. Сопоставление с VARCHAR(MAX).
LONG RAW	Не поддерживается. Сопоставление с VARBINARY (MAX).
NCHAR	NCHAR
NVARCHAR2	NVARCHAR
NUMBER	FLOAT
NCLOB	Не поддерживается напрямую. Замена на NVARCHAR(MAX).
NUMERIC	NUMERIC
Типы данных мультимедиа ORD	Не поддерживается
НЕОБРАБОТАННЫЕ	Не поддерживается. Сопоставление с VARBINARY (MAX).
real	real
ROWID	Не поддерживается. Сопоставление с аналогичным GUID.
Геопространственные типы данных SDO	Не поддерживается
SMALLINT	SMALLINT
TIMESTAMP	DATETIME2 или функция CURRENT_TIMESTAMP()
TIMESTAMP WITH LOCAL TIME ZONE	Не поддерживается. Сопоставление с DATETIMEOFFSET.
TIMESTAMP WITH TIME ZONE	Не поддерживается, так как TIME хранится только с использованием времени "по часам" без смещения часового пояса.
URIType	Не поддерживается. Хранение в VARCHAR.
UROWID	Не поддерживается. Сопоставление с аналогичным GUID.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
XMLType	Не поддерживается. Хранение XML-данных в VARCHAR.

Oracle также поддерживает пользовательские объекты, которые могут содержать ряд отдельных полей, каждое из которых содержит собственное определение и значения по умолчанию. Затем на эти объекты можно ссылаться в определении таблицы так же, как на встроенные типы данных, такие как NUMBER или VARCHAR. Azure Synapse в настоящее время не поддерживает пользовательские типы. Если данные, необходимые для переноса, включают пользовательские типы данных, преобразуйте их в плоскую структуру (обычное определение таблицы), а если они представляют собой массивы данных — в отдельную таблицу.

Совет

Оцените количество и тип неподдерживаемых типов данных на этапе подготовки миграции.

Сторонние поставщики предлагают инструменты и сервисы для автоматизации миграции, в том числе для сопоставления типов данных. Если в среде Oracle уже используется сторонний инструмент для извлечения, преобразования и загрузки (ETL) данных, воспользуйтесь им для выполнения всех необходимых преобразований с данными.

Различия в синтаксисе SQL DML

Между Oracle SQL и Azure Synapse T-SQL существуют различия синтаксиса SQL DML. Эти различия подробно рассматриваются в разделе Минимизация проблем SQL для миграций Oracle. В некоторых случаях для автоматизации миграции DML можно использовать такие средства Microsoft, как SSMA для Oracle и Azure Database Migration Services, а также сторонние продукты и сервисы для миграции.

Функции, хранимые процедуры и последовательности

При переносе хранилища данных из развитой среды, например Oracle, часто приходится переносить не только простые таблицы и представления, но и другие элементы. Проверьте, могут ли средства среды Azure заменить функциональные возможности функций, хранимых процедур и последовательностей, так как обычно бывает эффективнее использовать встроенные средства Azure, чем переписывать их для Azure Synapse.

На этапе подготовки составьте каталог объектов, которые необходимо перенести, определите метод их обработки и выделите соответствующие ресурсы в плане миграции.

Для автоматизации переноса функций, хранимых процедур и последовательностей можно использовать средства Microsoft, такие как SSMA для Oracle и Azure Database Migration Services, а также сторонние продукты и сервисы для миграции.

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

Функции

Как и большинство СУБД, Oracle поддерживает системные и пользовательские функции в реализации SQL. При миграции с устаревшей платформы базы данных на Azure Synapse стандартные системные функции обычно переносятся без изменений. У некоторых системных функций может быть немного другой синтаксис, однако необходимые изменения можно автоматизировать. Список функций в базе данных Oracle можно получить, запросив представление ALL_OBJECTS с соответствующим предложением WHERE. Вы можете использовать Oracle SQL Developer для получения списка функций, как показано на следующем снимке экрана.

Системные функций Oracle и произвольные пользовательские функции, у которых нет эквивалента в Azure Synapse, можно переписать на языке целевой среды. Определяемые пользователем функции Oracle кодируются на языках PL/SQL, Java или C, а Azure Synapse использует для реализации определяемых пользователем функций язык Transact-SQL.

Хранимые процедуры

Большинство современных СУБД поддерживают хранимые процедуры в базе данных. Oracle предоставляет для этой цели язык PL/SQL. Как правило, хранимая процедура содержит инструкции SQL и процедурную логику, а также может возвращать данные или состояние. Список хранимых процедур в базе данных Oracle можно получить, запросив представление ALL_OBJECTS с соответствующим предложением WHERE. Вы можете использовать Oracle SQL Developer для получения списка хранимых процедур, как показано на следующем снимке экрана.

Azure Synapse реализует хранимые процедуры с помощью T-SQL, поэтому потребуется переписать все перенесенные хранимые процедуры на этом языке.

Последовательности

В Oracle последовательность — это именованный объект базы данных, созданный с помощью CREATE SEQUENCE. Последовательность предоставляет уникальные числовые значения с помощью методов CURRVAL и NEXTVAL. Созданные уникальные числа можно использовать как значения суррогатных ключей для первичных ключей.

Azure Synapse не реализует CREATE SEQUENCE, однако последовательности можно реализовать с помощью столбцов IDENTITY или кода SQL, который генерирует следующий порядковый номер в ряде.

Извлечение метаданных и данных из среды Oracle

Создание языка описания данных

Стандарт ANSI SQL определяет базовый синтаксис для команд языка описания данных (DDL). Некоторые команды DDL, такие как CREATE TABLE и CREATE VIEW, являются общими для Oracle и Azure Synapse, но также обладают характерными для своей реализации возможностями, такими как индексирование, распределение таблиц и параметры секционирования.

Для получения эквивалентных определений в Azure Synapse можно отредактировать существующие скрипты Oracle CREATE TABLE и CREATE VIEW. Для этого может потребоваться задействовать модифицированные типы данных и удалить или изменить характерные для Oracle предложения, например TABLESPACE.

В среде Oracle определение текущей таблицы и представления задают таблицы системного каталога. В отличие от пользовательской документации сведения из системного каталога всегда являются полными и в точности соответствуют текущим определениям таблиц. Доступ к сведениям о системных каталогах можно получить с помощью таких служебных программ, как Oracle SQL Developer. Oracle SQL Developer может генерировать инструкции CREATE TABLE, редактируя которые можно создавать эквивалентные таблицы в Azure Synapse.

Кроме того, с помощью SSMA для Oracle можно перенести таблицы из существующей среды Oracle в Azure Synapse. SSMA для Oracle применит соответствующие сопоставления типов данных и рекомендуемые типы таблиц и дистрибутивов, как показано на следующем снимке экрана.

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

Извлечение данных из Oracle

Необработанные табличные данные можно извлечь из таблиц Oracle в неструктурированные файлы с разделителями, например CSV-файлы, с помощью стандартных служебных программ Oracle, таких как Oracle SQL Developer, SQL*Plus и SCLcl. Затем можно сжать неструктурированные файлы с разделителями с помощью gzip и передать сжатые файлы в Хранилище BLOB-объектов Azure с помощью AzCopy или средств транспортировки данных Azure, таких как Azure Data Box.

Извлекайте табличные данные максимально эффективно, особенно если переносите крупные таблицы фактов. Для таблиц Oracle используйте параллелизм, чтобы обеспечить максимальную пропускную способность извлечения. Параллелизм можно обеспечить путем одновременного выполнения нескольких процессов, которые по отдельности извлекают дискретные сегменты данных, или с помощью средств, способных автоматизировать параллельное извлечение путем секционирования.

Совет

Используйте параллелизм для максимально эффективного извлечения данных.

Если доступна достаточная пропускная способность сети, вы можете извлекать данные из локальной системы Oracle непосредственно в таблицы Azure Synapse или хранилище данных BLOB-объектов Azure. Для этого используйте процессы фабрики данных, Azure Database Migration Service или сторонние продукты для переноса данных или ETL.

Извлеченные файлы данных должны содержать текст с разделителями в формате CSV, ORC или Parquet.

Дополнительные сведения о переносе данных и ETL в среде Oracle см. в статье Перенос данных и операции извлечения, преобразования и загрузки, а также особенности загрузки данных для миграции из Oracle.

Рекомендации по производительности для миграции из Oracle

Цель оптимизации производительности — достичь той же или более высокой производительности хранилища данных в Azure Synapse после миграции.

Сходства в понятиях подхода к настройке производительности

Многие концепции настройки производительности для баз данных Oracle имеют значение true для баз данных Azure Synapse. Например:

• использование распространения данных для совместного размещения соединяемых данных в одном узле обработки;

• использование типа данных наименьшего размера для определенного столбца, что позволит сэкономить дисковое пространство и ускорить обработку запросов;

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

• Обеспечение актуальности статистики поможет оптимизатору создать наилучший план выполнения.

• Отслеживайте производительность с помощью встроенных возможностей базы данных, чтобы обеспечить эффективное использование ресурсов.

Совет

Ознакомьтесь с параметрами настройки в Azure Synapse перед началом миграции.

Различия в подходе к настройке производительности

В этом разделе описаны различия более низкого уровня между Oracle и Azure Synapse, касающиеся настройки производительности.

Возможности распространения данных

Для повышения производительности в архитектуре Azure Synapse применяются несколько узлов и параллельная обработка. Чтобы оптимизировать производительность таблиц в Azure Synapse, можно задать параметр распределения данных в инструкциях CREATE TABLE с помощью инструкции DISTRIBUTION. Например, можно указать распределенную таблицу с хэш-распределением, которая распределяет строки таблицы между вычислительными узлами с помощью детерминированной хэш-функции. Многие реализации Oracle, особенно старые локальные системы, не поддерживают эту функцию.

В отличие от Oracle, Azure Synapse также поддерживает локальные соединения между небольшой и большой таблицами путем репликации небольшой таблицы. Например, рассмотрим небольшую таблицу измерения и большую таблицу фактов в схеме типа "звезда". Azure Synapse может реплицировать таблицу измерения меньшего размера по всем узлам, чтобы гарантировать, что у значения любого ключа соединения для большой таблицы есть соответствующая локальная строка измерения. Для небольшой таблицы измерения затраты на репликацию относительно низки. Для больших таблиц измерения целесообразнее применять хэш-распределение. Дополнительные сведения о параметрах распределения данных см. в руководстве по проектированию для реплицируемых таблиц и распределенных таблиц.

Совет

Хэш-распределение повышает производительность запросов в больших таблицах фактов. Распределение методом циклического перебора используется для ускорения загрузки.

Хэш-распределение можно применять к нескольким столбцам для более равномерного распределения базовой таблицы. Распределение по нескольким столбцам позволяет выбрать до восьми столбцов для распределения. Это не только снижает неравномерное распределение данных с течением времени, но и повышает производительность запросов.

Примечание.

Распределение по нескольким столбцам в настоящее время доступно для Azure Synapse Analytics в предварительной версии. Использовать распределение по нескольким столбцам можно с помощью инструкций CREATE MATERIALIZED VIEW, CREATE TABLE и CREATE TABLE AS SELECT.

Помощник по распространению

В Azure Synapse SQL можно настроить способ распределения каждой таблицы. Стратегия распределения таблиц существенно влияет на производительность запросов.

Функция помощника по распространению (DA) — это новая функция Synapse SQL, которая анализирует запросы и рекомендует лучшие стратегии распределения для таблиц в целях повышения производительности запросов. Запросы, которые будут рассматриваться консультантом, могут предоставляться вами или извлекаться из исторических запросов, доступных в динамическом административном представлении.

Дополнительные сведения и примеры использования помощника по распространению см. в статье Помощник по распределению в Azure Synapse SQL.

Индексирование данных

Azure Synapse поддерживает несколько определяемых пользователем параметров индексирования, работа и использование которых отличаются от управляемых системой карт зон в Oracle. Дополнительные сведения о различных вариантах индексирования в Azure Synapse см. в статье Индексы в таблицах выделенного пула SQL.

Определения индексов в исходной среде Oracle служат полезным индикатором того, как используются данные и какие столбцы подходят для индексирования в среде Azure Synapse. Как правило, не требуется переносить каждый индекс из устаревшей среды Oracle, так как Azure Synapse не слишком активно использует индексы, а реализует следующие функции для достижения высокой производительности:

• Параллельная обработка запросов

• Кэширование данных в памяти и набора результатов.

• Распределение данных, например репликация небольших таблиц измерений, для уменьшения количества операций ввода-вывода.

Секционирование данных

В хранилище данных предприятия таблицы фактов могут содержать миллиарды строк. Секционирование позволяет оптимизировать обслуживание этих таблиц и выполнения к ним запросов путем разделения их на отдельные части для уменьшения объема обработанных данных. В Azure Synapse спецификацию секционирования для таблицы определяет инструкция CREATE TABLE.

Для секционирования можно использовать только одно поле на таблицу. Часто это поле является полем даты, так как многие запросы фильтруются по дате или диапазону дат. Вы можете изменить секционирование таблицы после начальной загрузки с помощью инструкции CREATE TABLE AS (CTAS), повторно создав таблицу с новым распределением. Подробное описание секционирования в Azure Synapse см. в статье Секционирование таблиц в выделенном пуле SQL.

Использование PolyBase или COPY INTO для загрузки данных

PolyBase поддерживает эффективную загрузку больших объемов данных в хранилище с помощью параллельных потоков загрузки. Дополнительные сведения см. в статье Стратегия загрузки данных PolyBase.

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

• Получение данных из всех файлов в папке и вложенных папках.
• Получение данных из нескольких расположений в одной учетной записи хранения. Вы можете указать пути к нескольким расположениям через запятую.
• Azure Data Lake Storage (ADLS) и Хранилище BLOB-объектов Azure.
• Форматы файлов CSV, PARQUET и ORC.

Совет

Рекомендуемым способом загрузки данных является использование COPY INTO вместе с файловым форматом PARQUET.

Управление рабочей нагрузкой

Выполнение смешанных рабочих нагрузок может усложнять процесс распределения ресурсов на загруженных системах. Успешная схема управления рабочей нагрузкой позволяет эффективно управлять ресурсами, обеспечивает их высокоэффективное использование и максимально увеличивает рентабельность инвестиций. Классификация рабочей нагрузки, важность рабочей нагрузки и изоляция рабочей нагрузки позволяют лучше контролировать использование системных ресурсов рабочей нагрузкой.

В руководстве по управлению рабочими нагрузками описываются методы анализа рабочей нагрузки, управления и мониторинга важности рабочей нагрузки, а также шаги по преобразованию класса ресурсов в группу рабочей нагрузки. Используйте портал Azure и запросы T-SQL к DMV, чтобы отслеживать рабочую нагрузку и обеспечивать эффективное использование применимых ресурсов.

Следующие шаги

Дополнительные сведения см. в следующей статье из этой серии: Перенос данных и операций извлечения, преобразования и загрузки, а также особенности загрузки данных для миграции из Oracle.