Производительность базы данных Oracle в Azure NetApp Files с несколькими томами

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

Производительность Oracle для масштабирования предприятия

При изучении верхних пределов производительности важно распознать и уменьшить все ограничения, которые могут ложно исказить результаты. Например, если цель заключается в том, чтобы доказать производительность системы хранения, клиент должен в идеале быть настроен таким образом, чтобы ЦП не стал фактором снижения производительности до достижения ограничений производительности хранилища. Для этого тестирование началось с типа экземпляра E104ids_v5, так как эта виртуальная машина поставляется не только с сетевым интерфейсом размером 100 Гбит/с, но и с равным большим (100 Гбит/с) пределом исходящего трафика.

Тестирование произошло на двух этапах:

1. Первый этап посвящен тестированию с помощью стандартного инструмента SLOB2 (Silly Little Oracle Benchmark) Кевина Клоссона (2.5.4). Цель заключается в том, чтобы максимально увеличить объем операций ввода-вывода Oracle с одной виртуальной машины на несколько томов Azure NetApp Files, а затем масштабировать с помощью дополнительных баз данных для демонстрации линейного масштабирования.
2. После тестирования ограничений масштабирования наше тестирование сводилось к менее дорогим, но почти как способным E96ds_v5 для этапа тестирования клиента с помощью рабочей нагрузки приложения цепочки поставок и реальных данных.

Производительность масштабирования SLOB2

На следующих диаграммах показан профиль производительности одной виртуальной машины Azure E104ids_v5 с одной базой данных Oracle 19c с восемью томами Azure NetApp Files с восемью конечными точками хранения. Тома распределяются по трем группам дисков ASM: данным, журналам и архивам. Пять томов были выделены группе дисков данных, двум томам для группы дисков журнала и одному тому для архивной группы дисков. Все результаты, собранные в этой статье, были собраны с помощью рабочих регионов Azure и активных рабочих служб Azure.

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

Архитектура с одним узлом

На следующей схеме показана архитектура, на которую было выполнено тестирование; обратите внимание на базу данных Oracle, распределенную по нескольким томам и конечным точкам Azure NetApp Files.

Операций ввода-вывода в хранилище с одним узлом

На следующей схеме показана 100% случайно выбранная рабочая нагрузка с коэффициентом попадания буфера базы данных около 8 %. SLOB2 смог выполнять около 850 000 запросов ввода-вывода в секунду при сохранении последовательной задержки событий чтения в субмиллисекундах. Размер блока базы данных составляет 8 КБ, который составляет около 6800 МиБ/с пропускной способности хранилища.

Пропускная способность одного узла

На следующей схеме показано, что для рабочих нагрузок с интенсивным выполнением пропускной способности, таких как полная проверка таблиц или действия RMAN, Azure NetApp Files может обеспечить полную пропускную способность самой виртуальной машины E104ids_v5.

Примечание.

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

Производительность горизонтального масштабирования SLOB2

На следующих диаграммах описывается профиль производительности трех виртуальных машин Azure E104ids_v5 каждой из которых выполняется одна база данных Oracle 19c, каждая из которых содержит собственный набор томов Azure NetApp Files и идентичный макет группы дисков ASM, как описано в разделе "Масштабирование производительности". На рисунке показано, что с помощью Azure NetApp Files с несколькими томами и несколькими конечными точками производительность легко масштабируется с согласованностью и прогнозируемостью.

Архитектура с несколькими узлами

На следующей схеме показана архитектура, на которую было выполнено тестирование; обратите внимание на три базы данных Oracle, распределенные по нескольким томам и конечным точкам Azure NetApp Files. Конечные точки могут быть выделены одному узлу, как показано с виртуальной машиной Oracle 1 или общим доступом между узлами, как показано в Oracle VM2 и Oracle VM 3.

Операции ввода-вывода в хранилище с несколькими узлами

На следующей схеме показана 100% случайно выбранная рабочая нагрузка с коэффициентом попадания буфера базы данных около 8 %. SLOB2 смог выполнять около 850 000 запросов ввода-вывода в секунду на всех трех узлах по отдельности. SLOB2 удалось выполнить это при выполнении параллельно с коллективным числом около 2500 000 запросов ввода-вывода в секунду с каждым узлом, сохраняя задержку событий последовательного чтения в субмиллисекундах. Размер блока базы данных составляет 8 КБ, это составляет около 20 000 МиБ/с между тремя узлами.

Пропускная способность с несколькими узлами

На следующей схеме показано, что для последовательных рабочих нагрузок Azure NetApp Files по-прежнему может обеспечить полную пропускную способность самой виртуальной машины E104ids_v5 даже при горизонтальном масштабировании. SLOB2 смог управлять вводом-выводом более 30 000 МиБ/с на трех узлах во время параллельной работы.

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

После тестирования ограничений масштабирования с помощью SLOB2 тесты были проведены с набором приложений цепочки поставок реального слова в Oracle в Azure NetApp с отличными результатами. Следующие данные из отчета Репозитория автоматических рабочих нагрузок Oracle (AWR) — это выделенный взгляд на то, как выполняется одно конкретное критическое задание.

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

-	Чтение и запись в секунду	Чтение в секунду	Запись в секунду
Всего (МБ)	4,988.1	1,395.2	3,592.9

Несмотря на то, что событие ожидания ожидания чтения базы данных с более высокой задержкой в 2,2 мс, чем в тестировании SLOB2, этот клиент увидел пятнадцатиминутное сокращение времени выполнения задания из базы данных RAC в Exadata в одну базу данных экземпляра в Azure.

Ограничения ресурсов Azure

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

Виртуальные машины

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

Наборы микросхем

Первая тема интереса — выбор наборов микросхем. Убедитесь, что любой номер SKU виртуальной машины, который вы выбираете, основан на одном наборе микросхем по соображениям согласованности. Вариант Intel E_v5 виртуальных машин выполняется в конфигурации Intel Xeon Platinum 8370C (Ice Lake). Все виртуальные машины в этой семье оснащены одним сетевым интерфейсом 100 Гбит/с. В отличие от этого, серия E_v3, упоминание, основанная на четырех отдельных наборах микросхем с различными физическими пропускной способностью сети. Четыре микросхемы, используемые в семействе E_v3 (Broadwell, Skylake, Cascade Lake, Haswell), имеют разные скорости процессора, которые влияют на производительность компьютера.

Ознакомьтесь с документацией по вычислениям Azure, внимательно уделяя внимание параметрам набора микросхем. Также ознакомьтесь с рекомендациями по SKU виртуальных машин Azure для Azure NetApp Files. Выбор виртуальной машины с одним набором микросхем предпочтительнее для оптимальной согласованности.

Доступная пропускная способность сети

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

Так как тома Azure NetApp Files подключены к сети, ограничение исходящего трафика можно понять как применяемое к записи, в то время как входящий трафик определяется как рабочие нагрузки чтения и чтения. Хотя ограничение исходящего трафика большинства компьютеров больше пропускной способности сетевой карты, то же самое нельзя сказать для E104_v5, используемого в тестировании для этой статьи. E104_v5 имеет сетевой адаптер 100 Гбит/с ограничением исходящего трафика, установленным на 100 Гбит/с, а также. По сравнению с E96_v5, с его сетевым адаптером 100 Гбит/с имеет предел исходящего трафика в 35 Гбит/с входящего трафика без входящего трафика на 100 Гбит/с. По мере уменьшения размера виртуальных машин ограничение исходящего трафика уменьшается, но входящий трафик остается неуправляемым логическим ограничением.

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

Параллелизм сети

Виртуальные машины Azure и тома Azure NetApp Files оснащены определенным объемом пропускной способности. Как показано ранее, до тех пор, пока виртуальная машина имеет достаточно головного места ЦП, рабочая нагрузка может использовать пропускную способность, доступную для нее, что находится в пределах сетевого карта и или ограничения исходящего трафика. Однако на практике количество достижимых пропускной способности зависит от параллелизма рабочей нагрузки в сети, то есть количества сетевых потоков и сетевых конечных точек.

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

Oracle поддерживает два отдельных клиента NFS, ядро NFS и Direct NFS (dNFS). Ядро NFS до конца поддерживает один сетевой поток между двумя конечными точками (вычислительными — хранилищем). Direct NFS, чем больше производительности двух, поддерживает переменное количество сетевых потоков— тесты показали сотни уникальных подключений на конечную точку — увеличение или уменьшение по мере необходимости загрузки. Из-за масштабирования сетевых потоков между двумя конечными точками Direct NFS гораздо предпочтительнее, чем ядро NFS, и, как это, рекомендуемая конфигурация. Группа продуктов Azure NetApp Files не рекомендует использовать ядро NFS с рабочими нагрузками Oracle. Дополнительные сведения см. в статье "Преимущества использования Azure NetApp Files с базой данных Oracle".

Параллелизм выполнения

Использование Direct NFS, одного набора микросхем для согласованности и понимание ограничений пропускной способности сети занимает вас до сих пор. В конце концов, производительность приложения обеспечивает производительность. Доказательства концепции использования SLOB2 и доказательства концепции с использованием набора приложений цепочки поставок в реальном мире для реальных данных клиентов смогли обеспечить значительные объемы пропускной способности, так как приложения выполнялись на высокой степени параллелизма; первый использует значительное количество потоков на схему, последний использует несколько подключений с нескольких серверов приложений. Короче говоря, рабочая нагрузка на диски параллелизма, низкая пропускная способность с низкой пропускной способностью, высокая пропускная способность— высокая пропускная способность, если инфраструктура находится на месте для поддержки того же.

Ускорение работы в сети

Функция ускорения сети позволяет использовать виртуализацию ввода-вывода с единым корнем (SR-IOV), повышая тем самым производительность сети виртуальной машины. Этот высокопроизводительный метод обеспечивает обход узла на пути к данным, что уменьшает задержку, дрожание и нагрузку ЦП. Он предназначен для ресурсоемких рабочих нагрузок сети на виртуальных машинах поддерживаемых типов. При развертывании виртуальных машин с помощью служебных программ управления конфигурацией, таких как terraform или командная строка, следует учитывать, что ускорение сети не включено по умолчанию. Для оптимальной производительности включите ускоренную сеть. Обратите внимание, что ускоренная сеть включена или отключена на сетевом интерфейсе по сетевому интерфейсу. Функция ускорения сети — это функция, которая может быть включена или отключена динамически.

Примечание.

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

Авторитетный подход к последующей ускоренной сети включен для сетевого адаптера через терминал Linux. Если для сетевого адаптера включена ускорение сети, второй виртуальный сетевой адаптер связан с первой сетевой картой. Этот второй сетевой адаптер настраивается системой с включенным флагом SLAVE . Если сетевой адаптер отсутствует с флагом SLAVE , ускорение сети не включено для этого интерфейса.

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

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

1. ip a Выполните команду:
2. /sys/class/net/ Список каталогов проверяемого идентификатора сетевого адаптера (eth0в примере) и grep для слова ниже:

   ls /sys/class/net/eth0 | grep lower lower_eth1
   

3. ethtool Выполните команду для устройства Ethernet, определяемого как нижнее устройство на предыдущем шаге.

Виртуальная машина Azure: ограничения пропускной способности сети и диска

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

• Пропускная способность и номера временных операций ввода-вывода в секунду относятся к возможностям производительности временного хранилища, подключенного к виртуальной машине.
• Пропускная способность диска без кэширования и номера ввода-вывода относятся специально к диску Azure (премиум, премиум версии 2 и ультра) и не имеют никакого отношения к подключенному к сети хранилищу, например Azure NetApp Files.
• Присоединение дополнительных сетевых адаптеров к виртуальной машине не влияет на ограничения производительности или возможности производительности виртуальной машины (задокументированные и протестированные, чтобы быть верными).
• Максимальная пропускная способность сети относится к ограничениям исходящего трафика (т. е. записывается при использовании Azure NetApp Files) к пропускной способности виртуальной машины. Ограничения входящего трафика (т. е. считываются при применении Azure NetApp Files). Учитывая достаточно ЦП, достаточное число сетевых параллелизмов и достаточно богатых конечных точек, виртуальная машина теоретически может привести к ограничениям сетевого адаптера. Как упоминание в разделе "Доступная пропускная способность сети", используйте такие ethtool средства для просмотра пропускной способности сетевой карты.

Пример диаграммы показан для справки:

Azure NetApp Files

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

Так как ограничения производительности хранилища масштабирования в базе данных Oracle хорошо понятны, эта статья намеренно фокусируется на производительности масштабируемого хранилища. Масштабирование производительности хранилища подразумевает предоставление одному экземпляру Oracle доступа ко многим томам Azure NetApp Files, в которых эти тома распределяются по нескольким конечным точкам хранилища.

Масштабируя рабочую нагрузку базы данных в нескольких томах таким образом, производительность базы данных не связана с верхними ограничениями тома и конечной точки. Благодаря тому, что хранилище больше не накладывает ограничения производительности, архитектура виртуальных машин (ограничения ЦП, сетевого адаптера и исходящего трафика виртуальных машин) становится хозяйкой для того чтобы бороться. Как отмечалось в разделе виртуальной машины, выбор E104ids_v5 и E96ds_v5 экземпляров учитывал это.

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

Внимание

Чтобы развернуть azure NetApp Files в multiple volume:multiple endpoint конфигурации, обратитесь к специалисту по Azure NetApp Files или архитектору облачных решений.

База данных

База данных Oracle версии 19c — это текущая долгосрочная версия Oracle, которая используется для создания всех результатов теста, рассмотренных в этом документе.

Для обеспечения оптимальной производительности все тома базы данных были подключены с помощью Direct NFS, ядро NFS рекомендуется использовать из-за ограничений производительности. Сравнение производительности между двумя клиентами см. в статье о производительности базы данных Oracle в отдельных томах Azure NetApp Files. Обратите внимание, что были применены все соответствующие исправления dNFS (идентификатор поддержки Oracle 1495104), как и рекомендации, описанные в отчете Oracle Database в Microsoft Azure с помощью отчета Azure NetApp Files .

Хотя Oracle и Azure NetApp Files поддерживают как NFSv3, так и NFSv4.1, так как NFSv3 является более зрелым протоколом, который обычно считается наиболее стабильным и является более надежным вариантом для сред, которые очень чувствительны к нарушениям. Тестирование, описанное в этой статье, было завершено по сравнению с NFSv3.

Внимание

Некоторые рекомендуемые исправления, которые документы Oracle в идентификаторе поддержки 1495104 критически важны для обеспечения целостности данных при использовании dNFS. Применение таких исправлений настоятельно рекомендуется для рабочих сред.

Автоматическое управление служба хранилища (ASM) поддерживается для томов NFS. Хотя обычно связано с хранилищем на основе блоков, где ASM заменяет управление логическими томами (LVM) и файловой системой как, ASM играет ценную роль в сценариях с несколькими томами NFS и заслуживает серьезного рассмотрения. Одно из таких преимуществ ASM, динамическое добавление и перебалансация между недавно добавленными томами и конечными точками NFS, упрощает управление, что позволяет расширить производительность и емкость при необходимости. Хотя ASM не в самом деле повышает производительность базы данных, его использование позволяет избежать горячих файлов и необходимости вручную поддерживать распределение файлов— преимущество, удобное для просмотра.

Конфигурация ASM по dNFS использовалась для создания всех результатов теста, рассмотренных в этой статье. На следующей схеме показан макет файла ASM в томах Azure NetApp Files и выделении файлов группам дисков ASM.

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

Искусственные средства тестирования и настраиваемые средства

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

Автоматизированное развертывание

• Виртуальные машины базы данных развертываются с помощью скриптов bash, доступных на сайте GitHub.
• Макет и выделение нескольких томов и конечных точек Azure NetApp Files выполняются вручную. Чтобы помочь вам, обратитесь к специалисту по Azure NetApp Files или архитектору облачных решений.
• Установка сетки, конфигурация ASM, создание базы данных и настройка среды SLOB2 на каждом компьютере настраиваются с помощью Ansible для согласованности.
• Параллельное выполнение тестов SLOB2 на нескольких узлах также выполняется с помощью Ansible для согласованности и одновременного выполнения.

Конфигурация виртуальной машины

Настройка	Значение
Регион Azure	Западная Европа
SKU виртуальной машины	E104ids_v5
Число сетевых карт	1 ПРИМЕЧАНИЕ. Добавление виртуальных НИС не влияет на количество систем
Максимальная пропускная способность исходящего трафика (Мбит/с)	100,000
Временное хранилище (SSD): ГиБ	3,800

Конфигурация системы

Все необходимые параметры конфигурации системы Oracle для версии 19c были реализованы в соответствии с документацией Oracle.

В системный /etc/sysctl.conf файл Linux добавлены следующие параметры:

• sunrpc.max_tcp_slot_table_entries: 128
• sunrpc.tcp_slot_table_entries = 128

Azure NetApp Files

Все тома Azure NetApp Files были подключены со следующими параметрами подключения NFS.

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

Параметры базы данных

Параметры	Значение
db_cache_size	2 ГБ
large_pool_size	2 ГБ
pga_aggregate_target	3g
pga_aggregate_limit	3g
sga_target	25g
shared_io_pool_size	500 м
shared_pool_size	5g
db_files	500
filesystemio_options	SETALL
job_queue_processes	0
db_flash_cache_size	0
_cursor_obsolete_threshold	130
_db_block_prefetch_limit	0
_db_block_prefetch_quota	0
_db_file_noncontig_mblock_read_count	0

Конфигурация SLOB2

Все создание рабочей нагрузки для тестирования было завершено с помощью средства SLOB2 версии 2.5.4.

Четырнадцать схем SLOB2 были загружены в стандартное табличное пространство Oracle и выполнялись в них, в сочетании с указанными параметрами файла конфигурации slOB2 поместите набор данных SLOB2 в 7 ТиБ. Следующие параметры отражают случайное выполнение чтения для SLOB2. Параметр SCAN_PCT=0 конфигурации был изменен SCAN_PCT=100 на во время последовательного тестирования.

• UPDATE_PCT=0
• SCAN_PCT=0
• RUN_TIME=600
• SCALE=450G
• SCAN_TABLE_SZ=50G
• WORK_UNIT=32
• REDO_STRESS=LITE
• THREADS_PER_SCHEMA=1
• DATABASE_STATISTICS_TYPE=awr

Для случайного тестирования чтения были выполнены девять выполнений SLOB2. Число потоков увеличилось на шесть с каждой итерацией теста, начиная с одного.

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

Метрики AWR

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

• Пропускная способность: сумма средней пропускной способности чтения и пропускной способности записи из раздела "Профиль загрузки AWR"
• Средние запросы на чтение операций ввода-вывода из раздела "Профиль загрузки AWR"
• Db file sequential read wait event average wait time from the AWR Foreground Wait Events section

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

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

Когда речь идет о запуске Oracle в Exadata, есть некоторые распространенные причины, по которым выбирается Exadata:

• 1–2 рабочих нагрузок с высоким уровнем ввода-вывода, которые являются естественными для функций Exadata, и так как эти рабочие нагрузки требуют значительных встроенных функций Exadata, остальные базы данных, выполняемые вместе с ними, были консолидированы в Exadata.
• Сложные или сложные рабочие нагрузки OLTP, которые требуют масштабирования RAC и сложно разработать с собственным оборудованием без глубокой оптимизации Oracle или может быть техническим долгом, который не может быть оптимизирован.
• Неиспользуемый существующий Exadata с различными рабочими нагрузками: это существует либо из-за предыдущих миграций, окончания срока действия в предыдущем exadata, либо из-за желания работать или тестировать exadata в локальной среде.

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

Внимание

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

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

• Репозиторий автоматической рабочей нагрузки (AWR):
  • Все базы данных Exadata лицензированы для использования отчетов AWR и подключенных функций производительности и диагностики.
  • Всегда включен и собирает данные, которые можно использовать для просмотра сведений об исторической рабочей нагрузке и оценки использования. Пиковые значения могут оценить высокий уровень использования в системе.
  • Более крупные отчеты AWR могут оценивать общую рабочую нагрузку, предоставляя ценные сведения об использовании функций и способах переноса рабочей нагрузки в не exadata эффективно. Пиковые отчеты AWR, напротив, лучше всего подходит для оптимизации производительности и устранения неполадок.
• Глобальный отчет AWR для Exadata также включает в себя конкретный раздел Exadata, который детализирует конкретные сведения об использовании функций Exadata и предоставляет ценные сведения о кэше флэш-памяти, ведения журнала флэш-памяти, операций ввода-вывода и других функциях по базам данных и узлу ячейки.

Развязка из Exadata

При определении рабочих нагрузок Oracle Exadata для миграции в облако рассмотрите следующие вопросы и точки данных:

• Использует ли рабочая нагрузка несколько функций Exadata за пределами аппаратных преимуществ?
  • Интеллектуальные проверки
  • индексы служба хранилища
  • Кэш флэш-памяти
  • Ведение журнала флэш-памяти
  • Гибридное сжатие столбцов
• Эффективно ли загрузка рабочей нагрузки с использованием Exadata? В первое время событий переднего плана, что такое соотношение (более 10 % времени базы данных) рабочей нагрузки с помощью:
  • Проверка смарт-таблицы ячеек (оптимальная)
  • Многоблоковый физический считывания ячейки (менее оптимальный)
  • Физическое чтение одного блока ячейки (наименее оптимальное)
• Гибридное сжатие columnar (HCC/EHCC): что такое сжатые и несжатые соотношения:
  • Тратит ли база данных более 10% времени на сжатие и распаковку данных?
  • Проверьте производительность предикатов с помощью сжатия в запросах: является ли значение, полученное в сравнении с объемом, сохраненным с сжатием?
• Физические операции ввода-вывода ячейки: проверьте экономию, предоставленную в следующих элементах:
  • сумма, направленная на узел базы данных для балансировки ЦП.
  • определение количества байтов, возвращаемых интеллектуальной проверкой. Эти значения можно вычитать в операции ввода-вывода в процентах физических операций одноблочного блока чтения после миграции exadata.
• Обратите внимание на количество логических операций чтения из кэша. Определите, требуется ли кэш флэш-памяти в облачном решении IaaS для рабочей нагрузки.
• Сравните объем физического чтения и записи байтов с суммой, выполняемой в кэше. Можно ли вызвать память, чтобы устранить требования к физическому чтению (это обычно для некоторых для сжатия SGA для принудительной разгрузки для Exadata)?
• В системной статистике определите, какие объекты влияют на статистику. Если настроить SQL, дальнейшее индексирование, секционирование или другую физическую настройку может значительно оптимизировать рабочую нагрузку.
• Проверьте параметры инициализации для параметров подчеркивания (_) или устаревших параметров, которые должны быть оправданы из-за влияния на уровень базы данных, которые могут привести к производительности.

Конфигурация сервера Exadata

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

• Сведения о версии и системе Exadata

• Подробные сведения об оповещениях узла ячейки

• Диски exadata nononline

• Выклюжение данных для любой статистики ОС Exadata

  • Желтый/розовый: Озабоченность. Exadata не работает оптимально.

  • Red: производительность Exadata значительно влияет.

  • Статистика ЦП ОС Exadata: верхние ячейки

    • Эти статистические данные собираются ОС на ячейках и не ограничиваются этой базой данных или экземплярами.
    • А v и темно-желтый фон указывают значение выскольза под низким диапазоном
    • А ^ и светло-желтый фон указывают значение выскольза над высоким диапазоном
    • Верхние ячейки по проценту ЦП отображаются и находятся в порядке убывания процентной загрузки ЦП
    • Среднее: 39,34% ЦП, 28,57% пользователя, 10,77% sys

    

• Физический блок одной ячейки считывается

• Использование кэша флэш-памяти

• Временный ввод в секунду

• Эффективность кэша columnar

Верхняя база данных по пропускной способности ввода-вывода

Хотя оценки размера можно выполнить, есть некоторые вопросы о средних и имитированных пиках, встроенных в эти значения для больших рабочих нагрузок. Этот раздел, найденный в конце отчета AWR, является исключительно ценным, так как он показывает среднее использование флэш-памяти и диска лучших 10 баз данных в Exadata. Хотя многие могут предположить, что они хотят размер баз данных для пиковой производительности в облаке, это не имеет смысла для большинства развертываний (более 95% находится в среднем диапазоне; с имитацией пиковой нагрузки, вычисляемой в, средний диапазон будет больше 98%). Важно платить за то, что необходимо, даже для самых высоких рабочих нагрузок Oracle и проверки основных баз данных по пропускной способности ввода-вывода может быть просвещено для понимания потребностей ресурсов в базе данных.

Правый размер Oracle с помощью AWR в Exadata

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

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

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

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

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

• Выполнение самых требовательных рабочих нагрузок Oracle в Azure без снижения производительности или масштабируемости
• Архитектуры решений с помощью Azure NetApp Files — Oracle
• Проектирование и реализация базы данных Oracle в Azure
• Средство оценки размера рабочих нагрузок Oracle в виртуальные машины IaaS Azure
• Эталонные архитектуры для выпуск Enterprise Базы данных Oracle в Azure
• Общие сведения о группах томов приложений Azure NetApp Files для SAP HANA