vCore purchasing model - Azure SQL Database

Статья
2025-04-14

This article reviews the vCore purchasing model for Azure SQL Database.

Обзор

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

В модели приобретения на основе vCore ваши затраты зависят от выбора и использования:

Уровень служб
Конфигурация оборудования
Вычислительные ресурсы (количество виртуальных ядер и объем памяти)
Зарезервированное хранилище базы данных
Фактическое хранилище резервных копий

Important

Compute resources, I/O, and data and log storage are charged per database or elastic pool. Оплата за хранилище резервных копий взимается за каждую базу данных. Сведения о ценах см. на странице цен на базе данных SQL Azure.

Сравните модели покупки vCore и DTU

Модель приобретения виртуальных ядер, используемая базой данных SQL Azure, предоставляет несколько преимуществ по сравнению с моделью приобретения на основе DTU:

Более высокие пределы вычислительных ресурсов, памяти, операций ввода-вывода и хранилища.
Выбор конфигурации оборудования для лучшего соответствия требованиям к вычислительным ресурсам и памяти рабочей нагрузки.
Ценовые скидки для Azure Hybrid Benefit (AHB).
Большая прозрачность в деталях аппаратного обеспечения, питающего вычислительные ресурсы, облегчает планирование миграции с локальных развертываний.
Reserved instance pricing is only available for vCore purchasing model.
Более высокая степень детализации масштабирования с несколькими доступными размерами вычислительных ресурсов.

For help with choosing between the vCore and DTU purchasing models, see the differences between the vCore and DTU-based purchasing models.

Compute

The vCore-based purchasing model has a provisioned compute tier and a serverless compute tier. В подготовленном уровне вычислений затраты на вычисления отражают общую емкость вычислений, постоянно подготовленную для приложения независимо от действия рабочей нагрузки. Выберите выделение ресурсов, которое лучше всего подходит для вашего бизнеса в зависимости от требований к виртуальным ядрам и памяти, а затем масштабируйте ресурсы вверх и вниз по мере необходимости в рабочей нагрузке. На бессерверном уровне вычислений для базы данных SQL Azure вычислительные ресурсы автоматически масштабируются на основе емкости рабочей нагрузки и выставляются счета за объем используемых вычислений в секунду.

Чтобы свести итоги, выполните приведенные ниже действия.

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

Regardless of the compute tier, three additional high availability secondary replicas are automatically allocated in the Business Critical service tier to provide high resiliency to failures and fast failovers. These additional replicas make the cost approximately 2.7 times higher than it is in the General Purpose service tier. Аналогичным образом, более высокая стоимость хранения на ГБ в уровне служб "Критически важный для бизнеса" отражает более высокие ограничения операций ввода-вывода и низкую задержку локального хранилища SSD.

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

Дополнительные сведения о вычислениях в базе данных Azure SQL см. в разделе Вычислительные ресурсы (процессор и память).

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

For vCore resource limits, review the available Hardware configurations, then review the resource limits for:

Хранилище данных и журналов

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

Каждый размер вычислительных ресурсов поддерживает настраиваемый максимальный размер данных с размером по умолчанию 32 ГБ.
При настройке максимального размера данных для файла журнала автоматически добавляется дополнительное 30 процентов оплачиваемого хранилища.
На уровне служб общего назначения tempdb использует локальное хранилище SSD, и эта стоимость хранения включается в цену виртуальных ядер.
In the Business Critical service tier, tempdb shares local SSD storage with data and log files, and tempdb storage cost is included in the vCore price.
В категориях "Общего назначения" и "Критически важный для бизнеса" взимается плата за максимальный размер хранилища, настроенный для базы данных или эластичного пула.
Для базы данных SQL можно выбрать любой максимальный размер данных в диапазоне от 1 ГБ до максимального размера поддерживаемого хранилища в 1 ГБ.

Следующие соображения по хранению применяются к Hyperscale.

Максимальный размер хранилища данных имеет значение 128 ТБ и не настраивается.
Плата взимается только за выделенное хранилище данных, а не для максимального хранилища данных.
Плата за хранение журналов не взимается.
tempdb uses local SSD storage, and its cost is included in the vCore price. Чтобы отслеживать текущий выделенный и используемый размер хранилища данных в базе данных SQL, используйте метрики Azure Monitor allocated_data_storage и storage соответственно.

Чтобы отслеживать текущий выделенный и используемый размер хранилища отдельных данных и файлов журналов в базе данных с помощью T-SQL, используйте представление sys.database_files и функцию FILEPROPERTY(... , SpaceUsed).

Tip

В некоторых случаях может потребоваться уменьшить базу данных, чтобы освободить неиспользуемое пространство. Дополнительные сведения см. в статье Управление пространством файлов в базе данных SQL Azure.

Хранилище резервных копий

Хранилище для резервных копий базы данных выделяется для поддержки возможностей восстановления в определенный момент времени (PITR) и долгосрочного хранения (LTR) в базе данных SQL. Это хранилище отличается от хранилища данных и файлов журнала и оплачивается отдельно.

PITR. В уровнях "Общего назначения" и "Критически важный для бизнеса" резервные копии отдельных баз данных копируются в службы хранилища Azure автоматически. Размер хранилища увеличивается динамически по мере создания новых резервных копий. Хранилище используется для полного, разностного и резервного копирования журналов транзакций. Потребление хранилища зависит от скорости изменения базы данных и периода хранения, настроенного для резервного копирования. Можно настроить отдельный период хранения для каждой базы данных в диапазоне от 1 до 35 дней для базы данных SQL. Объем хранилища резервных копий, равный заданному максимальному размеру данных, предоставляется без дополнительной платы.
LTR. Вы также можете настроить долгосрочное хранение полных резервных копий до 10 лет. Если вы настроили политику LTR, эти резервные копии хранятся в хранилище BLOB-объектов Azure автоматически, но вы можете контролировать частоту копирования резервных копий. Для удовлетворения различных требований соответствия можно выбрать различные периоды хранения для еженедельных, ежемесячных и /или ежегодных резервных копий. Выбранная конфигурация определяет, сколько хранилища используется для резервных копий LTR. Дополнительные сведения см. в разделе долгосрочное хранение резервных копий.

For backup storage in Hyperscale, see Automated backups for Hyperscale databases.

Уровни служб

Service tier options in the vCore purchasing model include General Purpose, Business Critical, and Hyperscale. Уровень служб обычно определяет тип хранилища и производительность, высокий уровень доступности и аварийного восстановления, а также доступность некоторых функций, таких как In-Memory OLTP.

сценарий использования	Категория общего назначения	критически важные для бизнеса	гипермасштаб
лучше всего подходит для	Most business workloads. Предоставляет бюджетные, сбалансированные и масштабируемые параметры вычислений и хранилища.	Предлагает бизнес-приложениям максимальную устойчивость к сбоям с помощью нескольких вторичных реплик высокого уровня доступности и обеспечивает максимальную производительность ввода-вывода.	The widest variety of workloads, including those workloads with highly scalable storage and read-scale requirements. Offers higher resilience to failures by allowing configuration of more than one high availability secondary replica.
размер вычислительных ресурсов	2–128 виртуальных процессорных ядер	2–128 виртуальных процессорных ядер	2–128 виртуальных процессорных ядер
тип хранилища	Premium remote storage (per instance)	Super-fast local SSD storage (per instance)	Отсоединяемое хранилище с локальным кэшем SSD (на реплику вычислений)
размер хранилища	1 ГБ – 4 ТБ	1 ГБ – 4 ТБ	10 ГБ – 128 ТБ
IOPS	320 операций ввода-вывода в секунду на виртуальное ядро с максимальной скоростью 16 000 операций ввода-вывода в секунду	4,000 IOPS per vCore with 327,680 maximum IOPS	327 680 операций ввода-вывода в секунду при максимальной производительности локального SSD Гипермасштабная архитектура — это многоуровневое строение с кэшированием на нескольких ступенях. Эффективные IOPS зависят от объема рабочей нагрузки.
Memory/vCore	5,1 ГБ	5,1 ГБ	5,1 ГБ или 10,2 ГБ
Резервные копии	A choice of geo-redundant, zone-redundant, or locally redundant backup storage, 1-35 day retention (default 7 days) Долгосрочное хранение доступно до 10 лет	A choice of geo-redundant, zone-redundant, or locally redundant backup storage, 1-35 day retention (default 7 days) Долгосрочное хранение доступно до 10 лет	A choice of locally redundant (LRS), zone-redundant (ZRS), or geo-redundant (GRS) storage Срок хранения 1–35 дней (по умолчанию — 7 дней) с сроком хранения до 10 лет.
Доступность	One replica, no read-scale replicas, zone-redundant high availability (HA)	Three replicas, one read-scale replica, zone-redundant high availability (HA)	zone-redundant high availability (HA)
цены и выставление счетов	Плата взимается за vCore, зарезервированное хранилище и хранилище резервных копий. IOPS aren't charged.	Плата взимается за vCore, зарезервированное хранилище и хранилище резервных копий. IOPS aren't charged.	vCore for each replica and used storage are charged. IOPS aren't charged.
модели скидок	Azure Reservations (Резервирование в Azure) преимущество гибридного использования Azure (недоступно в подписках разработки и тестирования) Enterprise and Pay-As-You-Go Dev/Test offer subscriptions	Azure Reservations (Резервирование в Azure) преимущество гибридного использования Azure (недоступно в подписках разработки и тестирования) Enterprise and Pay-As-You-Go Dev/Test offer subscriptions	Azure Hybrid Benefit (not available on dev/test subscriptions) ¹ Enterprise and Pay-As-You-Go Dev/Test offer subscriptions
таблицы OLTP в памяти	Нет	Да	Нет

¹ Скоро упрощенное ценообразование для гипермасштабируемых баз данных SQL. Review the Hyperscale pricing blog for details.

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

Заметка

Для получения дополнительной информации о соглашении об уровне обслуживания (SLA) см. SLA для базы данных Azure SQL

Общее назначение

Архитектурная модель для уровня служб общего назначения основана на разделении вычислительных ресурсов и хранилища. Эта архитектурная модель зависит от высокой доступности и надежности хранилища BLOB-объектов Azure, который прозрачно реплицирует файлы базы данных и гарантирует отсутствие потери данных в случае сбоя базовой инфраструктуры.

На следующем рисунке показаны четыре узла в стандартной архитектурной модели с разделенными уровнями вычислений и хранилища.

схема, иллюстрирующая разделение вычислительных ресурсов и хранилища.

В архитектурной модели для уровня служб общего назначения существует два уровня:

Бездеятельностный вычислительный уровень, выполняющий процесс sqlservr.exe и содержащий только временные и кэшированные данные (например, кэш планов, буферный пул и столбцовый пул). This stateless node is operated by Azure Service Fabric that initializes process, controls health of the node, and performs failover to another place if necessary.
A stateful data layer with database files (.mdf/.ldf) that are stored in Azure Blob storage. Хранилище BLOB-объектов Azure гарантирует отсутствие потери данных любой записи, размещенной в любом файле базы данных. Служба хранилища Azure имеет встроенную доступность и избыточность данных, которая гарантирует сохранение каждой записи в файле журнала или странице в файле данных, даже если процесс завершается сбоем.

Whenever the database engine or operating system is upgraded, some part of underlying infrastructure fails, or if some critical issue is detected in the sqlservr.exe process, Azure Service Fabric moves the stateless process to another stateless compute node. Существует набор запасных узлов, которые готовы запускать новую вычислительную службу в случае сбоя первичного узла, чтобы свести к минимуму время простоя. Данные на уровне хранилища Azure не затрагиваются, а файлы данных и журналов присоединяются к только что инициализированному процессу. This process guarantees 99.99% availability by default and 99.995% availability when zone redundancy is enabled. There might be some performance impacts to heavy workloads that are in-flight due to transition time and the fact the new node starts with cold cache.

Когда выбрать уровень служб общего назначения

Уровень служб общего назначения — это уровень служб по умолчанию в Базе данных SQL Azure, предназначенный для большинства универсальных рабочих нагрузок. Если вам нужна полностью управляемая база данных с соглашением об уровне обслуживания по умолчанию и задержкой хранилища в диапазоне от 5 мс до 10 мс, уровень General Purpose — это ваш вариант.

Критически важный для бизнеса

Модель уровня служб "Критически важный для бизнеса" основана на кластере процессов ядра СУБД. Эта архитектурная модель использует кворум узлов ядра СУБД, чтобы свести к минимуму влияние производительности на рабочую нагрузку даже во время обслуживания. Обновления и исправления базовой операционной системы, драйверов и ядра СУБД выполняются прозрачно с минимальным временем простоя для конечных пользователей.

В бизнес-критической модели вычислительные ресурсы и хранилище интегрируются на каждом узле. Репликация данных между процессами ядра СУБД на каждом узле кластера с четырьмя узлами обеспечивает высокую доступность, при этом каждый узел использует локально подключенный SSD в качестве хранилища данных. На следующей схеме показано, как уровень служб "Критически важный для бизнеса" упорядочивает кластер узлов ядра СУБД в репликах группы доступности.

Процесс ядра СУБД и базовые файлы .mdf/.ldf размещаются на одном узле с локально подключенным хранилищем SSD, обеспечивая низкую задержку в рабочей нагрузке. Высокая доступность реализуется с помощью технологий, аналогичных SQL Server Always On группам доступности. Каждая база данных — это кластер узлов базы данных с одной первичной репликой, доступной для клиентских рабочих нагрузок, и тремя вторичными репликами, содержащими копии данных. Первичная реплика постоянно отправляет изменения во вторичные реплики, чтобы обеспечить доступность данных на вторичных репликах, если первичная реплика выходит из строя по какой-либо причине. Failover is handled by the Service Fabric and the database engine – one secondary replica becomes the primary, and a new secondary replica is created to ensure there are enough nodes in the cluster. Рабочая нагрузка автоматически перенаправляется на новую первичную реплику.

In addition, the Business Critical cluster has a built-in Read Scale-Out capability that provides a free-of charge read-only replica used to run read-only queries (such as reports) that won't affect the performance of the workload on your primary replica.

Когда выбирать уровень услуг "Критически важный для бизнеса"

Уровень обслуживания "Критически важный для бизнеса" предназначен для приложений, которые требуют низкой задержки ответов от базового хранилища SSD (в среднем 1–2 мс), быстрого восстановления в случае сбоя базовой инфраструктуры, или при необходимости разгрузки отчётов, аналитики и запросов только для чтения в бесплатную доступную для чтения вторичную реплику основной базы данных.

Основные причины, по которым следует выбрать уровень служб "Критически важный для бизнеса" вместо уровня "Общего назначения":

требования к низкой задержке ввода-вывода — рабочие нагрузки, которые нуждаются в постоянно быстром ответе слоя хранения (в среднем 1–2 миллисекунды), должны использовать уровень "Критически важный для бизнеса".
Workload with reporting and analytic queries where a single free-of-charge secondary read-only replica is sufficient.
Более высокая устойчивость и более быстрое восстановление после сбоев. В случае сбоя системы база данных на первичном экземпляре отключена, а одна из вторичных реплик сразу же становится новой базой данных-источником для чтения и записи, готовой к обработке запросов.
Расширенная защита от повреждения данных. Поскольку уровень "Критически важный для бизнеса" использует реплики баз данных в фоновом режиме, служба применяет автоматическое восстановление страниц, доступное благодаря технологии зеркального отображения и группам доступности, для устранения повреждения данных. Если реплика не может считывать страницу из-за проблемы целостности данных, новая копия страницы извлекается из другой реплики, заменив нечитаемую страницу без потери данных или простоя клиента. Эта функция доступна на уровне общего назначения, если у базы данных есть гео-вторичная реплика.
Более высокая доступность — уровень "Критически важный для бизнеса" в конфигурации многозонной доступности обеспечивает устойчивость к зональным сбоям и более высокий уровень доступности.
Быстрое геовосстановление - Если настроена активная георепликация, уровень "Критически важный для бизнеса" имеет гарантированную целевую точку восстановления (RPO) в 5 секунд и целевой момент времени восстановления (RTO) в течение 30 секунд в течение 100% развернутых часов.

Гипермасштаб

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

Дополнительные сведения см. в служебном уровне "Гипермасштаб" для Azure SQL Database.

Когда следует выбирать уровень обслуживания HyperScale

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

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

Achieve high resiliency and fast failure recovery while controlling cost, by choosing the number of high availability replicas from 0 to 4.
Улучшите высокую доступность, включив зональную избыточность для вычислений и хранилища.
Achieve low I/O latency (1-2 milliseconds on average) for the frequently accessed part of your database. Для небольших баз данных это может применяться ко всей базе данных.
Implement a large variety of read scale-out scenarios with named replicas.
Воспользуйтесь преимуществами быстрого масштабирования, не ожидая копирования данных в локальное хранилище на новых узлах.
Enjoy zero-impact continuous database backup and fast restore.
Поддерживайте требования непрерывности бизнес-процессов с помощью групп отказоустойчивости и георепликации.

Конфигурация оборудования

Common hardware configurations in the vCore model include standard-series (Gen5), premium-series, premium-series memory optimized, and DC-series. Hyperscale also provides an option for premium-series and premium-series memory optimized hardware. Конфигурация оборудования определяет ограничения вычислительных ресурсов и памяти и другие характеристики, влияющие на производительность рабочей нагрузки.

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

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

Цель службы изменена
Текущая инфраструктура в центре обработки данных приближается к ограничениям емкости
В настоящее время используемое оборудование удаляется из-за окончания срока жизни
Zone-redundant configuration is enabled, moving to a different hardware due to available capacity

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

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

Вычислительные ресурсы (ЦП и память)

В следующей таблице сравниваются вычислительные ресурсы в разных конфигурациях оборудования и уровнях вычислений:

Конфигурация оборудования	ЦПУ	Память
Стандартная серия (Gen5)	Provisioned compute - Процессоры 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 (Milan) - Provision up to 128 vCores (hyper-threaded) бессерверные вычисления* - Процессоры 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 (Milan) - Autoscale up to 80 vCores (hyper-threaded) — Соотношение памяти и виртуальных ядер динамически адаптируется на основе использования памяти и процессора в соответствии с рабочей нагрузкой и может достигать 24 ГБ на vCore. Например, в определенный момент времени рабочей нагрузке может потребоваться 240 ГБ памяти, за которую выставляется счет, в то время как используется только 10 виртуальных ядер.	Provisioned compute — 5,1 ГБ на виртуальное ядро — предоставление до 625 ГБ бессерверные вычисления - Autoscale up to 24 GB per vCore — автомасштабирование до 240 ГБ макс.
Серия Fsv2**	— Процессоры Intel® 8168 (Skylake) - С поддерживаемой турбочастотой всех ядер 3,4 ГГц и максимальной турбочастотой одного ядра 3,7 ГГц. - Provision up to 72 vCores (hyper-threaded)	— 1,9 ГБ на виртуальное ядро — предоставление до 136 ГБ
Серия DC	— процессоры Intel® Xeon® E-2288G — с расширением Intel Software Guard (Intel SGX) - Provision up to 8 vCores (physical)	4,5 ГБ на виртуальное ядро

* In the sys.dm_user_db_resource_governance dynamic management view, hardware generation for databases using Intel® SP-8160 (Skylake) processors appears as Gen6, hardware generation for databases using Intel® 8272CL (Cascade Lake) appears as Gen7, and hardware generation for databases using Intel® Xeon® Platinum 8370C (Ice Lake) or AMD® EPYC® 7763v (Milan) appear as Gen8. Для заданного размера вычислений и аппаратной конфигурации ограничения ресурсов одинаковы независимо от типа ЦП (Intel Broadwell, Skylake, Ice Lake, Cascade Lake или AMD Milan).

** Оборудование серии Fsv2 будет прекращено 1 октября 2026 г.

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

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

Стандартная серия (Gen5)

Оборудование серии "Стандартный" (5-го поколения) обеспечивает сбалансированные вычислительные ресурсы и ресурсы памяти и подходит для большинства рабочих нагрузок базы данных.

Оборудование серии Standard (Gen5) доступно во всех общедоступных регионах по всему миру.

Hyperscale premium-series

Варианты оборудования серии "Премиум" используют новейшие технологии ЦП и памяти intel и AMD. Серия "Премиум" обеспечивает повышение производительности вычислений относительно оборудования стандартной серии.

Вариант серии "Премиум" обеспечивает более высокую производительность ЦП по сравнению с серией "Стандартный" и более высоким числом виртуальных ядер.
Оптимизированный для памяти категории "Премиум" вариант обеспечивает двойной объем памяти относительно категории "Стандартный".

Standard-series, premium-series, and premium-series memory optimized are available for Hyperscale elastic pools.

For more information, see the Hyperscale premium series blog announcement.

For regions available, see Hyperscale premium-series availability.

Серия DC

Оборудование серии DC использует процессоры Intel с технологией Software Guard Extensions (Intel SGX).
DC-series is required for Always Encrypted with secure enclaves workloads that require stronger security protection of hardware enclaves, compared to Virtualization-based Security (VBS) enclaves.
Серия DC предназначена для рабочих нагрузок, обрабатывающих конфиденциальные данные и требующих возможности безопасной обработки запросов, которые обеспечиваются функцией Always Encrypted с безопасными анклавами.
Оборудование серии DC предоставляет сбалансированные вычислительные ресурсы и ресурсы памяти.

Серия DC поддерживается только для выделенных вычислительных ресурсов (бессерверные не поддерживаются) и не поддерживает зональную отказоустойчивость. For regions where DC-series is available, see DC-series availability.

Типы предложений Azure, поддерживаемые серией DC

Чтобы создать базы данных или эластичные пулы на оборудовании серии DC, подписка должна быть платным типом предложения, включая "Оплата по мере использования" (You-Go) или Корпоративное соглашение (EA). For a complete list of Azure offer types supported by DC-series, see current offers without spending limits.

Выбор конфигурации оборудования

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

Выбор конфигурации оборудования при создании базы данных SQL или пула

Подробные сведения см. в статье Созданиебазы данных SQL.

На вкладке Основные выберите ссылку "Настройка базы данных" в разделе Вычисление и хранилище, а затем щелкните ссылку Изменить конфигурацию:

Выберите нужную конфигурацию оборудования:

Изменение конфигурации оборудования существующей базы данных SQL или пула

Для базы данных на странице "Обзор" выберите ссылку ценовая категория.

For a pool, on the Overview page, select Configure.

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

Доступность оборудования

Сведения о доступности оборудования для текущего поколения см. в разделе "Доступность компонентов по регионам" для базы данных SQL Azure.

Оборудование предыдущего поколения

Серия Fsv2

Оборудование серии Fsv2 для Базы данных SQL Azure будет прекращено 1 октября 2026 г. Чтобы свести к минимуму сбои в работе службы и сохранить соотношение цена-производительность, переходите на оборудование серии Hyperscale премиум или Standard (Gen5). For more information, see Retirement Notice: Azure SQL Database FSV2-series offer. Для большинства баз данных и рабочих нагрузок оборудование Hyperscale серии "Премиум" или "Стандартная" (Gen5) обеспечивает аналогичную или лучшую ценовую производительность по сравнению с Fsv2. Чтобы убедиться, проверьте это с помощью конкретной базы данных и рабочих нагрузок.

Fsv2 provides less memory and tempdb per vCore than other hardware, so workloads sensitive to those limits might perform better on standard-series (Gen5).
Серия Fsv2 поддерживается только на уровне общего назначения.

Gen4

Gen4 hardware has been retired and isn't available for provisioning, upscaling, or downscaling. Перенос базы данных в поддерживаемое поколение оборудования для более широкого диапазона масштабируемости виртуальных ядер и хранилища, ускорения сети, оптимальной производительности операций ввода-вывода и минимальной задержки. Review hardware options for single databases and hardware options for elastic pools. Дополнительные сведения см. в статье Поддержка завершена для оборудования 4-го поколения в базе данных SQL Azure.

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

Краткое руководство: Создание единой базы данных — база данных SQL Azure

страница цен на базу данных SQL Azure
ограничения ресурсов для отдельных баз данных с помощью модели приобретения виртуальных ядер
Ограничения ресурсов для эластичных пулов при использовании модели покупки vCore