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

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

Overview

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

Хотя 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. В целом процесс миграции включает следующие этапы:

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

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

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

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

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

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

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

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

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

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

• выполняет бизнес-аналитическую нагрузку вместо нагрузки OLTP.

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

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

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

Перенос по методу "Лифт энд шифт" и поэтапный подход

Как правило, существует два метода миграции, независимо от цели и области её применения: перемещение "как есть" без изменений и поэтапный подход, предполагающий изменения.

Метод переноса и перемещения

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

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

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

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

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

Использование средств Майкрософт для реализации миграции на основе метаданных

Можно использовать возможности среды 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.

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

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

При планировании использования средств 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 доступны только для чтения, поэтому любые изменения данных должны вноситься в базовые таблицы.

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

Вопросы, касающиеся таблицы

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

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

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

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

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

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

  • Запрос таблиц и представлений системного каталога, таких как ALL_INDEXES, DBA_INDEXESи USER_INDEXESDBA_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 таблицы обеспечивают наивысший уровень сжатия данных, лучшую общую производительность запросов и, как правило, превосходят кластеризованные индексные или heap таблицы. Кластеризованный индекс columnstore обычно является лучшим выбором для больших таблиц. При создании таблицы выберите кластеризованный columnstore, если вы не уверены, как индексировать таблицу. Однако существуют некоторые сценарии, в которых кластеризованные индексы columnstore не являются лучшим вариантом:

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

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

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

  • Таблицы кучи: при временной посадке данных в Azure Synapse вы можете обнаружить, что использование таблицы кучи ускоряет общий процесс. Это связано с тем, что загрузка данных в таблицы кучи быстрее, чем загрузка данных в индексированные таблицы, а в некоторых случаях последующие операции чтения можно выполнять из кэша. Если вы загружаете данные только для того, чтобы подготовить их перед выполнением дополнительных преобразований, гораздо быстрее загрузить их в таблицу heap, чем в кластеризованную 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 с Azure Synapse.

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

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

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

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

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

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

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

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

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

Functions

Как и большинство СУБД, 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, поэтому вам потребуется перекодировать все перенесенные хранимые процедуры на этом языке.

Sequences

В 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. Разработчик SQL Oracle может создавать CREATE TABLE инструкции DDL, которые можно изменить для создания эквивалентных таблиц в Azure Synapse.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения и примеры использования помощника по распространению см. в помощнике по распространению в 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.

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

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

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

Дальнейшие действия

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