Уровень обслуживания гипермасштабирования

Применимо к:База данных SQL Azure

База данных SQL Azure Hyperscale — это экономичная высокопроизводительная облачная база данных.

База данных SQL Azure основана на механизме базы данных SQL. Уровень Hyperscale отличается от других уровней обслуживания База данных SQL Azure:

  • В отличие от других уровней служб, уровень Hyperscale не предусматривает лицензионной платы за ПО SQL, что обеспечивает ему существенное ценовое преимущество перед другими уровнями служб База данных SQL Azure для высокопроизводительных баз данных.
  • Архитектура гипермасштабирования отличается: она обеспечивает почти мгновенное резервное копирование, быстрое восстановление и высокую пропускную способность для операций чтения и записи.
  • Гипермасштабирование обеспечивает быстрое масштабирование вычислений по требованию без перемещения данных.
  • Стратегии горизонтального масштабирования чтения реализуются легко: доступно до 30 именованных реплик с независимо настраиваемыми вычислительными ресурсами, а также встроенные реплики высокой доступности и настраиваемые геореплики по всему миру.

Уровень служб "Гипермасштабирование" подходит для всех типов рабочих нагрузок. Вычислительные ресурсы и ресурсы хранилища в уровне "Гипермасштабирование" значительно превосходят ресурсы, доступные в База данных SQL Azure на уровнях "Общее назначение" и "Критически важный для бизнеса".

Можно легко преобразовать существующую базу данных в База данных SQL Azure в гипермасштабирование или перенести из любой базы данных SQL Server в гипермасштабирование. Сведения о переносе других баз данных в База данных SQL Azure см. в Azure руководствах по миграции баз данных.

Уровень служб Гипермасштабирования в настоящее время доступен только для База данных SQL Azure, а не для Управляемый экземпляр SQL Azure.

Каковы гипермасштабные возможности?

Уровень служб гипермасштабирования в База данных SQL Azure предоставляет следующие дополнительные возможности:

  • Быстрое масштабирование — увеличивайте вычислительные ресурсы для обработки высоких нагрузок при необходимости, а когда они не нужны, уменьшайте их.
  • Быстрое масштабирование— подготовка одной или нескольких реплик только для чтения для разгрузки рабочей нагрузки чтения и использования в качестве горячих резервных.
  • Автоматическое увеличение, уменьшение масштаба и выставление счетов для вычислений на основе использования технологии бессерверных вычислений.
  • Оптимизированная цена и производительность для группы баз данных гипермасштабирования с различными требованиями к ресурсам с эластичными пулами.
  • Автоматическое масштабирование хранилища с поддержкой до 128 ТБ базы данных или размером 100 ТБ эластичного пула.
  • Более высокая общая производительность благодаря высокой пропускной способности ведения журнала транзакций и ускоренной фиксации транзакций независимо от объемов данных.
  • Быстрое резервное копирование базы данных (на основе моментальных снимков файлов) независимо от размера без влияния ввода-вывода на вычислительные ресурсы.
  • Восстановление или копирование базы данных (на основе моментальных снимков файлов) занимает минуты, а не часы или дни.

Уровень служб "Гипермасштабирование" устраняет многие практические ограничения, традиционно наблюдаемые в облачных базах данных. В то время как большинство других баз данных ограничены ресурсами, доступными на одном узле, базы данных на уровне служб "Гипермасштабирование" не имеют таких ограничений. Благодаря гибкой архитектуре хранилища его объем растет по мере необходимости. На самом деле гипермасштабируемые базы данных не создаются с определенным максимальным размером. База данных гипермасштабирования растет по мере необходимости, и плата взимается только за выделенную емкость хранилища. Для рабочих нагрузок интенсивного чтения уровень обслуживания "Гипермасштабирование" обеспечивает быстрое горизонтальное увеличение масштаба за счёт подготовки дополнительных реплик при необходимости разгрузки задач чтения.

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

Дополнительные сведения о размерах вычислительных ресурсов для уровня служб "Гипермасштабирование" см. в разделе Характеристики уровней служб.

См. подробности об уровнях служб Общего назначения и Критически важного для бизнеса в рамках модели приобретения на основе виртуальных ядер. Чтобы сравнить модель приобретения на основе виртуальных ядер с моделью приобретения на основе DTU, см. раздел Сравнение моделей приобретения vCore и DTU в базе данных Azure SQL.

Кому рекомендуется использовать уровень служб "Гипермасштабирование"

Уровень служб "Гипермасштабирование" предназначен для всех клиентов, которым требуется более высокая производительность и доступность, быстрое резервное копирование и восстановление, а также быстрое хранилище и масштабируемость вычислений. Гипермасштабирование идеально подходит для клиентов, которые перемещаются в облако для модернизации своих приложений или для клиентов, которые уже используют другие уровни служб в База данных SQL Azure. Уровень обслуживания "Гипермасштабирование" поддерживает широкий спектр рабочих нагрузок баз данных — от исключительно OLTP до исключительно аналитических задач. Он оптимизирован для рабочих нагрузок OLTP и гибридной транзакции и аналитической обработки (HTAP).

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

Для баз данных с высокой производительностью гипермасштабирование обеспечивает значительное преимущество по сравнению с другими уровнями служб База данных SQL Azure. Дополнительные сведения см. в блоге: объявление о тарифах База данных SQL Azure Hyperscale на Ignite 2023. Подробные сведения об изменении цен см. в блоге: База данных SQL Azure Hyperscale — сниженные и упрощенные цены!

Уровень служб "Гипермасштабирование" доступен только в модели виртуальных ядер и поставляется на двух уровнях вычислений. Выставление счетов для гипермасштабирования основано на подготовленном или бессерверном уровне вычислений:

  • Подготовленный уровень вычислений :

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

  • Бессерверный уровень вычислений:

    Выставление счетов за бессерверные вычисления основано на использовании. Дополнительные сведения см. в разделе Безсерверный тарифный план для базы данных Azure SQL.

Максимальный размер данных не указывается при настройке базы данных гипермасштабирования. На уровне Hyperscale вы платите за хранилище в зависимости от фактически выделенного объема. Хранилище автоматически выделяется в диапазоне от 10 ГБ до 128 ТБ и увеличивается по мере необходимости. Для получения дополнительной информации смотрите раздел «С какими шагами увеличивается размер моей базы данных?»

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

Гипермасштабирование отделяет основной ядро СУБД от компонентов, которые обеспечивают долгосрочное хранение и устойчивость данных. Эта архитектура позволяет быстро масштабировать вычислительные ресурсы без перемещения данных и масштабировать хранилище (до 128 ТБ) независимо от вычислительных ресурсов. Дополнительные сведения, включая схему архитектуры, см. в разделе "Архитектура гипермасштабирования".

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

Основная база данных База данных SQL Azure уровня Hyperscale обрабатывает как нагрузки чтения, так и записи, но вы можете легко создавать реплики, доступные только для чтения, как часть стратегии вашего приложения:

  • Общее количество вторичных реплик высокой доступности можно настроить от 0 до 4 в зависимости от требований к доступности и масштабируемости.
  • Можно создать до 30 именованных реплик для поддержки рабочих нагрузок с горизонтальным масштабированием чтения.
  • Вы можете обеспечить масштабирование чтения в глобальных центрах обработки данных Azure с помощью геореплик.

Высокий уровень доступности базы данных в варианте развертывания "Гипермасштабирование"

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

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

Сведения об уровне обслуживания с гипермасштабированием см. в разделе SLA для База данных SQL Azure.

Буферный пул и расширение отказоустойчивого буферного пула

В Azure Database Hyperscale существует четкое разделение между вычислением и хранением. Хранилище содержит все страницы базы данных в одной базе данных и может быть выделено на нескольких компьютерах по мере роста базы данных. Однако вычислительный узел кэширует только то, что используется в последнее время. Наиболее горячие страницы вычислений хранятся в памяти в структуре, называемой буферным пулом (BP). Он также хранится в локальном SSD, расширении отказоустойчивого буферного пула (RBPEX), поэтому данные можно получить быстрее при перезапуске вычислительного процесса.

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

Непрерывное прайминг

Непрерывное праймирование — это процесс сбора информации о том, к каким страницам чаще всего обращаются (то есть какие из них являются наиболее «горячими») на всех вычислительных репликах. Процесс агрегирует эти сведения, а вторичные реплики высокой доступности используют список самых горячих страниц, соответствующих типичной рабочей нагрузке клиента. Этот процесс непрерывно заполняет как BP, так и RBPEX самыми горячими страницами, чтобы следить за изменениями в рабочей нагрузке клиента.

Без непрерывного праймирования ни BP, так и RBPEX не наследуются новыми высокодоступными репликами и восстанавливаются только во время пользовательской нагрузки. Непрерывное предварительное выполнение экономит время и предотвращает нестабильную производительность, так как нет задержки, прежде чем кэши снова полностью загружаются. При непрерывной подготовке новые вторичные реплики высокого уровня доступности сразу же начнут приступать к подготовке данных BP и RBPEX. Это поможет более стабильно поддерживать производительность, по мере того как происходят переключения на резервные системы.

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

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

Резервное копирование и восстановление

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

Восстановление после аварии для гипермасштабируемых баз данных

Чтобы восстановить базу данных гипермасштабирования в База данных SQL Azure в регион, отличный от региона, в котором он размещен в настоящее время, выполните геовосстановление. Этот метод подходит для аварийного восстановления, учений, переноса или по любой другой причине. Геовосстановление доступно только при выборе георезервируемого хранилища (RA-GRS) в качестве параметра избыточности хранилища.

Дополнительные сведения см. в статье о восстановлении базы данных Hyperscale в другой регион.

Сравнение ограничений по ресурсам

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

ㅤ Общего назначения Критически важный для бизнеса Гипермасштабирование
Оптимально для Бюджетные сбалансированные варианты вычислений и хранилища. Приложения OLTP с высокой скоростью транзакций и низкой задержкой ввода-вывода. Высокая устойчивость к сбоям и быстрое переключение при отказе благодаря использованию нескольких горячих резервных реплик. Рекомендуемый уровень обслуживания, используемый по умолчанию, для всех новых и модернизируемых рабочих нагрузок OLTP и HTAP. Лучше всего подходит для самого широкого спектра рабочих нагрузок, в том числе требующих высокомасштабируемого хранилища и масштабирования операций чтения. Обеспечивает более высокую устойчивость к сбоям, разрешая настройку нескольких вторичных реплик высокого уровня доступности.
Объем вычислительных ресурсов 2–128 виртуальных ядер 2–128 виртуальных ядер 2–192 виртуальных ядер3
Тип хранилища Удаленное хранилище класса Premium (для каждого экземпляра) Сверхбыстрое локальное хранилище SSD (для каждого экземпляра) Отсоединяемое хранилище с локальным кэшем SSD (на реплику вычислений)
Размер хранилища 1 ГБ — 4 ТБ 1 ГБ — 4 ТБ 10 ГБ — 128 ТБ
Макс. IOPS 320 операций ввода-вывода в секунду на виртуальное ядро с максимальной скоростью 16 000 операций ввода-вывода в секунду 4000 операций ввода-вывода в секунду на виртуальное ядро с максимальным числом 327 680 операций ввода-вывода в секунду 5500 операций ввода-вывода в секунду на одно виртуальное ядро при максимальной скорости 544 000 операций ввода-вывода в секунду на локальные SSD.
Гиперскейл — это многоуровневая архитектура с кэшированием на нескольких уровнях. Эффективные IOPS зависят от рабочей нагрузки.
Память/виртуальное ядро 5.1 ГБ 5.1 ГБ 5,1 ГБ или 10,2 ГБ
Резервные копии Выбор локально-избыточного хранилища (LRS), межзонального избыточного хранилища (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения — от 1 до 35 дней (по умолчанию — 7 дней), с возможностью долгосрочного хранения до 10 лет		 Выбор локально-избыточного хранилища (LRS), межзонального избыточного хранилища (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения — от 1 до 35 дней (по умолчанию — 7 дней), с возможностью долгосрочного хранения до 10 лет		 Выбор локально-избыточного хранилища (LRS), межзонального избыточного хранилища (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения — от 1 до 35 дней (по умолчанию — 7 дней), с возможностью долгосрочного хранения до 10 лет
Доступность Одна реплика, не считывает реплики горизонтального масштабирования. Зональная избыточность HA Три реплики, одна реплика для горизонтального масштабирования чтения. Зональная избыточность HA Несколько реплик, до 4 реплик для масштабирования чтения. Зональная избыточность HA
Цены и выставление счетов Оплачивается виртуальное ядро, резервное хранилище и хранилище резервных копий.
Плата за IOPS не взимается.		 Оплачивается виртуальное ядро, резервное хранилище и хранилище резервных копий.
Плата за IOPS не взимается.		 Взимается плата за виртуальные ядра для каждой реплики, выделенное хранилище данных и хранилище резервных копий.
Плата за IOPS не взимается.
Модели скидок1 Azure Reservations (Резервирование в Azure)
Преимущество гибридного использования Azure2
Корпоративные и подписки на предложение для разработки и тестирования с оплатой по мере использования		 Azure Reservations (Резервирование в Azure)
Преимущество гибридного использования Azure2
Корпоративные и подписки на предложение для разработки и тестирования с оплатой по мере использования		 Поскольку Hyperscale не предусматривает платы за лицензию на программное обеспечение SQL1, Преимущество гибридного использования Azure недоступна для новых баз данных Hyperscale2.
Таблицы в памяти нет Yes Нет

1 Упрощенные условия ценообразования для гипермасштабируемой базы данных SQL вступили в действие в декабре 2023 года. Ознакомьтесь с блогом о ценах на гипермасштабируемые решения для получения более подробной информации.

2 с декабря 2023 г. Преимущество гибридного использования Azure недоступен для новых Hyperscale баз данных или в подписках для разработки и тестирования. Существующие гипермасштабируемые базы данных с выделенными вычислительными ресурсами могут продолжать использовать Преимущество гибридного использования Azure для экономии затрат на вычислительные ресурсы до декабря 2026 года. Дополнительные сведения см. в блоге о ценах на гипермасштаб.

3 В настоящее время параметры виртуальных ядер 160 и 192 являются предварительной версией.

Вычислительные ресурсы

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

Настройка оборудования ЦП Память
Серия Standard (5-е поколение) Выделенные вычислительные ресурсы
- Intel® E5-2673 v4 (Broadwell) 2,3 ГГц, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 ГГц*, Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Милан)*, AMD EPYC 9004 (Genoa)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* процессоры
— Предоставление до 128 виртуальных ядер (с поддержкой технологии Hyper-Threading)

Бессерверные вычисления
- Intel® E5-2673 v4 (Broadwell) 2,3 ГГц, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 ГГц*, Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Милан)*, AMD EPYC 9004 (Genoa)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* процессоры
— автомасштабирование до 80 виртуальных ядер (с поддержкой гиперпоточности)
— Соотношение памяти к виртуальным ядрам динамически адаптируется к использованию памяти и процессора по требованию рабочей нагрузки и может достигать 24 ГБ на виртуальное ядро. Например, в определенный момент времени рабочей нагрузке может потребоваться 240 ГБ памяти, за которую выставляется счет, в то время как используется только 10 виртуальных ядер.		 Выделенные вычислительные ресурсы
5,1 ГБ на виртуальное ядро.
— предоставление до 625 ГБ

Бессерверные вычисления
— автоматическое масштабирование до 24 ГБ на виртуальный процессор
— автомасштабирование до 240 ГБ макс.
Серия Premium Выделенные вычислительные ресурсы
- Intel® Xeon Platinum 8370C (Ice Lake)*, AMD EPYC 7763v (Милан)*, AMD EPYC™ 9004 (Genoa)*, Intel®® Xeon® Platinum 8573C (Изумрудные Рапидс)* процессоры*
— Развернуть до 192 виртуальных ядер с поддержкой гиперпоточности.		 5,2 ГБ на виртуальное ядро
Память, оптимизированная для серии "Премиум" Выделенные вычислительные ресурсы
- Intel® Xeon Platinum 8370C (Ice Lake)*, AMD EPYC 7763v (Милан)*, AMD EPYC™ 9004 (Genoa)*, Intel®® Xeon® Platinum 8573C (Изумрудные Рапидс)* процессоры*
— подготовка до 80 виртуальных ядер (гиперпотоков).		 10,2 ГБ на виртуальное ядро

* Для заданного размера вычислительной среды и аппаратной конфигурации лимиты ресурсов одинаковы независимо от типа ЦП (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Emerald Rapid или AMD Milan, Genoa). В динамическом представлении управления sys.dm_user_db_resource_governance создание оборудования для баз данных с помощью:

  • Процессоры Intel® SP-8160 (Skylake) отображаются в качестве 6-го поколения
  • Intel® 8272CL (Cascade Lake) отображается как Gen7
  • Intel® Xeon® Platinum 8370C (Ice Lake) или AMD EPYC™ 7763v (Милан) появляются как Gen8
  • AMD EPYC™ 9004 (Genoa) появляются как 9-го поколения или Intel® Xeon® Platinum 8573C (Изумрудные рапидс) появляются как 10-го поколения

Дополнительные сведения см. в разделе об ограничениях ресурсов для отдельных баз данных и эластичных пулов.

Создание и администрирование баз данных с Гипермасштабированием

Вы можете создавать базы данных гипермасштабирования и управлять ими с помощью портала Azure, Transact-SQL, PowerShell и Azure CLI. Для получения дополнительной информации см. краткое руководство: создание гипермасштабируемой базы данных.

Операция Сведения Подробнее
Создание базы данных гипермасштабирования Базы данных гипермасштабирования доступны только с помощью модели приобретения на основе виртуальных ядер. Примеры создания базы данных гипермасштабирования в Quickstart: создание базы данных гипермасштабирования в База данных SQL Azure.
перевод существующей базы данных на Hyperscale Можно преобразовать существующую базу данных в уровень гипермасштабирования База данных SQL Azure. Длительность преобразования зависит от размера данных. Дополнительные сведения см. в статье Преобразование существующей базы данных в гипермасштабирование.
Обратная миграция базы данных Hyperscale в уровень сервиса 'Общее Назначение' Если вы ранее перенесли существующую базу данных База данных SQL Azure в Hyperscale, вы можете выполнить обратную миграцию базы данных на уровень General Purpose в течение 45 дней после первоначальной миграции на Hyperscale.

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

Ограничения

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

Проблема Описание
Сжатие блокируется при отключении TDE В настоящее время База данных SQL Azure уровня Hyperscale не поддерживает операции уменьшения размера базы данных и файлов, когда прозрачное шифрование данных (TDE) отключено.
Восстановление базы данных из других уровней служб Невозможно восстановить базу данных, отличную от Hyperscale, как базу данных Hyperscale. Вы также не можете восстановить базу данных Hyperscale как базу данных не уровня Hyperscale.

Для баз данных, перенесенных на гипермасштабирование из других уровней служб База данных SQL Azure, резервные копии перед миграцией хранятся в течение периода хранения резервных копий исходной базы данных, включая долгосрочные политики хранения. Резервное копирование перед миграцией можно восстановить в течение периода хранения резервной копии базы данных с помощью командной строки. Эти резервные копии можно восстановить с любым уровнем служб, кроме уровня "Гипермасштабирование".
Миграция баз данных с помощью объектов In-Memory OLTP Поддержка HyperScale охватывает подмножество объектов OLTP In-Memory, включая типы таблиц, оптимизированные для памяти, табличные переменные и модули, скомпилированные в собственном формате. Тем не менее, если в базе данных присутствуют объекты OLTP в оперативной памяти, миграция с уровней служб Premium и Критически важный для бизнеса на Hyperscale не поддерживается. Чтобы мигрировать такую базу данных на уровень Hyperscale, необходимо удалить все объекты In-Memory OLTP и их зависимости. После миграции базы данных можно повторно создать эти объекты. Устойчивые и нестойкие таблицы, оптимизированные для использования памяти, в настоящее время не поддерживаются в Гипермасштабе и необходимо изменить на табличные данные на диске.
Проверка целостности базы данных DBCC CHECKDB и DBCC CHECKFILEGROUP в настоящее время не поддерживаются в базах данных База данных SQL Azure Hyperscale. В качестве обходного пути используйте DBCC CHECKTABLE ('TableName') WITH TABLOCK. Дополнительные сведения об управлении целостностью данных в База данных SQL Azure см. в статье Целостность данных в База данных SQL Azure.
Эластичные задания Использование базы данных гипермасштабирования в качестве базы данных задания не поддерживается. Однако эластичные задания могут нацеливаться на гипермасштабные базы данных точно так же, как любую другую базу данных в База данных SQL Azure.
Синхронизация данных Использование базы данных Hyperscale в качестве концентратора или базы метаданных синхронизации не поддерживается. Однако база данных Hyperscale может быть членом в топологии Синхронизация данных.
Оборудование гипермасштабируемой серии уровня обслуживания "Премиум" Оборудование серии "Премиум" и оборудование, оптимизированное для памяти, не поддерживает бессерверный уровень вычислений. Бессерверные технологии поддерживаются только на оборудовании Standard-series (Gen5).
Доступность в регионах Высокомасштабируемое оборудование "Премиум-серии" и "Премиум-серии", оптимизированное для памяти, доступно в ограниченном числе регионов Azure. Для получения списка см. раздел Доступность серии Hyperscale premium.

Связанный контент

  • Last updated on