Camada de serviço de hiperescala

Aplica-se a: Base de Dados SQL do Azure

Base de Dados SQL do Azure Hyperscale é uma base de dados cloud de alto desempenho e eficiente em termos de custos.

O Base de Dados SQL do Azure baseia-se no SQL Database Engine. O Hyperscale difere de outros Base de Dados SQL do Azure service tiers:

Ao contrário de outros níveis de serviço, o Hyperscale não tem taxa de licença de software SQL, o que lhe confere uma vantagem de preço significativa em relação a outros níveis de serviço do Base de Dados SQL do Azure para bases de dados de alto desempenho.
A arquitetura de hiperescala distingue-se por proporcionar cópias de segurança quase instantâneas, restauros rápidos e elevado débito de leitura e escrita.
O Hyperscale proporciona uma escalabilidade rápida de computação sob demanda, sem movimentação de dados.
As estratégias de escalonamento da leitura são fáceis, com até 30 réplicas nomeadas com computação independente e configurável, além de réplicas de alta disponibilidade incorporadas e réplicas geoconfiguráveis em todo o mundo.

A camada de serviço Hyperscale é adequada para todos os tipos de carga de trabalho. Os recursos de computação e armazenamento no Hyperscale excedem substancialmente os recursos disponíveis nos níveis General Purpose e Business Critical do Base de Dados SQL do Azure.

Pode converter facilmente uma base de dados existente no Base de Dados SQL do Azure para Hyperscale, ou migrar de qualquer base de dados SQL Server para Hyperscale. Para migrar outras bases de dados para o Base de Dados SQL do Azure, consulte os Azure Database Migration Guides.

O nível de serviço Hyperscale está atualmente disponível apenas para Base de Dados SQL do Azure, e não para Azure SQL Managed Instance.

Quais são os recursos de hiperescala

O nível de serviço Hyperscale no Base de Dados SQL do Azure oferece as seguintes funcionalidades adicionais:

Escalar rapidamente – aumentar os seus recursos de computação para acomodar cargas de trabalho pesadas quando necessário, e depois reduzir novamente os recursos quando não for necessário.
Escalonamento rápido - provisionar uma ou mais réplicas apenas de leitura para descarregar a sua carga de trabalho de leitura e para uso como reservas ativas.
Escalonamento automático, redução e cobrança para computação com base no uso, utilizando computação sem servidor.
Preço/desempenho otimizado para um grupo de bancos de dados Hyperscale com demandas de recursos variáveis com pools elásticos .
Armazenamento de dimensionamento automático com suporte para até 128 TB de banco de dados ou pool elástico de 100 TB.
Maior desempenho geral devido à maior taxa de transferência do log de transações e tempos de confirmação de transações mais rápidos, independentemente dos volumes de dados.
Backups rápidos de banco de dados (com base em instantâneos de arquivos), independentemente do tamanho, sem impacto de E/S nos recursos de computação.
Restaurações ou cópias de bancos de dados rápidas (com base em instantâneos de arquivos) concluídas em minutos, em vez de horas ou dias.

A camada de serviço Hyperscale remove muitos dos limites práticos tradicionalmente vistos em bancos de dados em nuvem. Onde a maioria dos outros bancos de dados é limitada pelos recursos disponíveis em um único nó, os bancos de dados na camada de serviço Hyperscale não têm esses limites. Com sua arquitetura de armazenamento flexível, o armazenamento cresce conforme necessário. Na verdade, os bancos de dados Hyperscale não são criados com um tamanho máximo definido. Um banco de dados Hyperscale cresce conforme necessário - e você é cobrado apenas pela capacidade de armazenamento alocada. Para cargas de trabalho de leitura intensiva, a camada de serviço Hyperscale fornece escalabilidade horizontal rápida, provisionando réplicas adicionais, conforme necessário, para aliviar cargas de trabalho de leitura.

Além disso, o tempo necessário para criar backups de banco de dados ou para aumentar ou diminuir a escala não está mais vinculado ao volume de dados no banco de dados. O backup dos bancos de dados de hiperescala é praticamente instantâneo. Você também pode dimensionar um banco de dados em dezenas de terabytes para cima ou para baixo em poucos minutos na camada de computação provisionada ou usar sem servidor para dimensionar a computação automaticamente. Esta funcionalidade liberta-o de preocupações sobre ser limitado pelas suas escolhas iniciais de configuração.

Para obter mais informações sobre os tamanhos de computação para a camada de serviço Hyperscale, consulte Características da camada de serviço.

Para obter detalhes sobre as camadas de serviço "General Purpose" e "Business Critical" no modelo de compra baseado em vCore, consulte as camadas de serviço General Purpose e Business Critical. Para uma comparação do modelo de compra baseado em vCore com o modelo de compra baseado em DTU, veja Compare os modelos de compra baseados em vCore e DTU de Base de Dados SQL do Azure.

Quem deve considerar a camada de serviço Hyperscale

O nível de serviço Hyperscale destina-se a todos os clientes que necessitam de maior desempenho e disponibilidade, backup e restauro rápidos, e rápida escalabilidade de armazenamento e computação. O Hyperscale é ideal para clientes que migram para a cloud para modernizar as suas aplicações, ou para clientes que já utilizam outros níveis de serviço no Base de Dados SQL do Azure. A camada de serviço Hyperscale suporta uma ampla gama de cargas de trabalho de banco de dados, de OLTP puro a análise pura. Ele é otimizado para OLTP e cargas de trabalho de transação híbrida e processamento analítico (HTAP).

Modelo de preços de hiperescala

Para bases de dados de alto desempenho, o Hyperscale oferece uma vantagem de preço significativa em relação a outros níveis de serviço do Base de Dados SQL do Azure. Para mais informações, consulte Blogue: anúncio de preços do Base de Dados SQL do Azure Hyperscale na Ignite 2023. Para detalhes sobre alterações de preços, consulte o Blogue: Base de Dados SQL do Azure Hyperscale - preços mais baixos e simplificados!

O nível de serviço Hyperscale está disponível apenas no modelo vCore e está disponível em dois níveis de computação. A faturação do Hyperscale baseia-se no nível de computação provisionado ou serverless:

Nível de computação provisionado :

O custo de computação do vCore reflete a capacidade total de computação que é continuamente provisionada para a aplicação. O preço da unidade de computação Hyperscale é por réplica.
Nível de computação serverless:

A cobrança de computação sem servidor é baseada no uso. Para mais informações, consulte Serverless compute tier para Base de Dados SQL do Azure.

Não especificas o tamanho máximo dos dados ao configurar uma base de dados Hyperscale. No nível Hyperscale, pagas pelo armazenamento com base na alocação real. O armazenamento é automaticamente alocado entre 10 GB e 128 TB, e cresce conforme necessário. Para mais informações, veja Em que incrementos cresce o tamanho da minha base de dados?

Vantagens de escala e desempenho

O Hyperscale separa o mecanismo de banco de dados principal dos componentes que fornecem armazenamento de longo prazo e durabilidade para os dados. Esta arquitetura permite escalar recursos de computação rapidamente, sem movimentação de dados, e escalar o armazenamento (até 128 TB) independentemente do cálculo. Para mais detalhes, incluindo um diagrama de arquitetura, veja Arquitetura em hiperescala.

Com a capacidade de adicionar e remover rapidamente nós de computação adicionais apenas de leitura, a arquitetura Hyperscale permite uma grande capacidade de escalabilidade de leitura e pode também aliviar o nó de computação primário para processar mais pedidos.
Pode aprovisionar a capacidade de computação para nós secundários ou utilizar computação sem servidor. Em qualquer dos casos, pode escalá-los rapidamente para cima ou para baixo devido à arquitetura de armazenamento partilhado do Hyperscale.
- Réplicas secundárias de nós de computação de alta disponibilidade no Hyperscale seguem o nível de computação do primário, o que resulta em failovers de baixo impacto.
Quando usa serverless, os nós de computação primários ou secundários dimensionam-se automaticamente com base nas exigências da carga de trabalho.

A base de dados principal Base de Dados SQL do Azure Hyperscale gere tanto cargas de trabalho de leitura como de escrita, mas pode facilmente criar réplicas de apenas leitura como parte da sua estratégia de aplicação:

Pode ajustar o número total de réplicas secundárias de alta disponibilidade de 0 para 4, dependendo dos requisitos de disponibilidade e escalabilidade.
Pode criar até 30 réplicas nomeadas para suportar cargas de trabalho de leitura escalonadas.
Pode obter uma expansão da escala de leitura geograficamente distribuída nos centros de dados globais do Azure através da utilização de réplicas geográficas.

Alta disponibilidade do banco de dados em Hyperscale

Como em todas as outras camadas de serviço, o Hyperscale garante a durabilidade dos dados para transações confirmadas, independentemente da disponibilidade da réplica de computação. A extensão do tempo de inatividade devido à indisponibilidade da réplica principal depende do tipo de failover (planejado versus não planejado), se a redundância de zona está configuradae da presença de pelo menos uma réplica de alta disponibilidade. Num failover planeado (como um evento de manutenção), o sistema cria a nova réplica primária antes de iniciar um failover ou utiliza uma réplica de alta disponibilidade existente como alvo de failover. Em um failover não planejado (como uma falha de hardware na réplica primária), o sistema usa uma réplica de alta disponibilidade como destino de failover, se existir, ou cria uma nova réplica primária a partir do pool de capacidade de computação disponível. Neste último caso, a duração do tempo de inatividade é maior devido às etapas adicionais necessárias para criar a nova réplica primária.

Pode escolher uma janela de manutenção para tornar eventos de manutenção impactantes previsíveis e menos disruptivos para a sua carga de trabalho.

Para Hyperscale SLA, veja SLA para Base de Dados SQL do Azure.

Conjunto de memória intermédia e extensão resiliente do conjunto de memória intermédia

No Azure Database Hyperscale, existe uma separação distinta entre computação e armazenamento. O armazenamento contém todas as páginas do banco de dados em um banco de dados e pode ser alocado em várias máquinas à medida que o banco de dados cresce. O nó de computação, no entanto, armazena em cache apenas o que está sendo usado recentemente. As páginas mais quentes na computação são mantidas na memória em uma estrutura chamada buffer pool (BP). Ele também é armazenado no SSD local, a extensão resiliente do pool de buffers (RBPEX), para que os dados possam ser recuperados mais rapidamente caso o processo de computação seja reiniciado.

Em um sistema de nuvem, a computação pode ser movida para máquinas diferentes, conforme necessário. A camada de computação pode ter várias réplicas. Uma réplica é a principal e recebe todas as atualizações, enquanto as outras são réplicas secundárias. Se o primário falhar, o sistema promove uma das réplicas secundárias de alta disponibilidade para primária num processo chamado failover. A réplica secundária pode não ter uma memória cache na BP e no RBPEX otimizada para a carga de trabalho primária.

Escorvamento contínuo

O priming contínuo é um processo que recolhe informações sobre quais são as páginas acedidas com mais frequência ("mais quentes") em todas as réplicas de computação. O processo agrega esta informação, e as réplicas secundárias de alta disponibilidade utilizam a lista das páginas mais utilizadas, correspondente à carga de trabalho típica do cliente. Este processo preenche continuamente tanto o BP como o RBPEX com as páginas mais quentes para acompanhar as mudanças na carga de trabalho do cliente.

Sem preparação contínua, tanto o BP como o RBPEX não são herdados por novas réplicas de alta disponibilidade e só são reconstruídos no decurso da carga de trabalho do utilizador. A preparação contínua economiza tempo e evita desempenhos inconsistentes, visto que não há espera para que as caches sejam completamente recarregadas novamente. Com o processo contínuo de preparação, novas réplicas secundárias de alta disponibilidade começarão imediatamente a preparar o seu BP e RBPEX. Isso ajudará a manter o desempenho de forma mais consistente à medida que os failovers acontecem.

A preparação contínua funciona nos dois sentidos: as réplicas secundárias de alta disponibilidade armazenarão em cache as páginas que estão a ser usadas na réplica primária, e a réplica primária irá armazenar em cache páginas relacionadas com a carga de trabalho proveniente das réplicas secundárias.

A preparação contínua está atualmente disponível na camada de computação provisionada Hyperscale.

Backup e restauração

As operações de backup e restauração para bases de dados do Hyperscale são baseadas em instantâneos de ficheiros. Esta abordagem torna estas operações quase instantâneas. Como a arquitetura Hyperscale utiliza a camada de armazenamento para backup e restauro, reduz o impacto no processamento e no desempenho nas réplicas de computação. Para mais informações, consulte Cópias de segurança Hyperscale e redundância do armazenamento.

Recuperação de desastres para bancos de dados Hyperscale

Para restaurar uma base de dados Hyperscale no Base de Dados SQL do Azure para uma região diferente daquela onde está atualmente alojada, faça uma restauração geográfica. Este método funciona para operações de recuperação de desastres, simulações, relocalização ou qualquer outra razão. O restauro geográfico só está disponível quando escolher o armazenamento com redundância geográfica (RA-GRS) para a redundância do armazenamento.

Para mais informações, consulte restaurar uma base de dados Hyperscale para uma região diferente.

Comparar limites de recursos

Os níveis de serviço baseados em vCore diferem na disponibilidade da base de dados, tipo de armazenamento, desempenho e tamanho máximo de armazenamento. A tabela seguinte descreve estas diferenças:

ㅤ	Uso Geral	Essencial para os Negócios	Hiperescala
Melhor para	Opções de computação e armazenamento equilibradas orientadas para o orçamento.	Aplicações OLTP com alta taxa de transação e baixa latência de E/S. Alta resiliência a falhas e failovers rápidos através da utilização de múltiplas réplicas de espera quente.	O nível de serviço recomendado e padrão para todas as cargas de trabalho OLTP e HTAP novas e em modernização. Ideal para a maior variedade de cargas de trabalho, incluindo aquelas com requisitos de armazenamento e leitura altamente escaláveis. Oferece maior resiliência a falhas, permitindo a configuração de mais de uma réplica secundária de alta disponibilidade.
Tamanho de computação	2 a 128 vCores	2 a 128 vCores	2 a 192 vCores³
Tipo de armazenamento	Armazenamento remoto premium (por unidade)	Armazenamento SSD local muito rápido (por cada instância)	Armazenamento desacoplado com cache de SSD local (para cada réplica de computação)
Tamanho de armazenamento	1 GB - 4 TB	1 GB - 4 TB	10 GB - 128 TB
IOPS máxima	320 IOPS por vCore com 16.000 IOPS máximas	4.000 IOPS por vCore com 327.680 IOPS máximas	5.500 IOPS por vCore com 544.000 SSDs locais no máximo. A hiperescala é uma arquitetura multicamadas com cache em vários níveis. O IOPS eficaz depende da carga de trabalho.
Memória/vCore	5,1 GB	5,1 GB	5,1 GB ou 10,2 GB
Backups	Uma opção de armazenamento com redundância local (LRS), com redundância de zona (ZRS) ou com redundância geográfica (GRS) Retenção de 1 a 35 dias (7 dias por predefinição), com retenção de longo prazo disponível até 10 anos	Uma opção de armazenamento com redundância local (LRS), com redundância de zona (ZRS) ou com redundância geográfica (GRS) Retenção de 1 a 35 dias (7 dias por predefinição), com retenção de longo prazo disponível até 10 anos	Uma opção de armazenamento com redundância local (LRS), com redundância de zona (ZRS) ou com redundância geográfica (GRS) Retenção de 1 a 35 dias (7 dias por predefinição), com retenção de longo prazo disponível até 10 anos
Availability	Uma réplica, sem réplicas de escalabilidade de leitura. HA com redundância de zona	Três réplicas, uma réplica de expansão horizontal para leitura. HA com redundância de zona	Múltiplas réplicas, até 4 réplicas de expansão horizontal de leitura. HA com redundância de zona
Preços e Faturação	vCore, armazenamento reservado e armazenamento de backup são cobrados. As IOPS não são cobradas.	vCore, armazenamento reservado e armazenamento de backup são cobrados. As IOPS não são cobradas.	vCore para cada réplica, armazenamento de dados alocado e armazenamento de backup são cobrados. As IOPS não são cobradas.
Modelos com desconto¹	Azure Reservas Benefício Híbrido do Azure² Enterprise e oferta Pay-As-You-Go Dev/Test subscrições	Azure Reservas Benefício Híbrido do Azure² Enterprise e oferta Pay-As-You-Go Dev/Test subscrições	Como o Hyperscale não tem taxa de licença de software SQL¹, o Benefício Híbrido do Azure não está disponível para as novas bases de dados^{Hyperscale 2}.
Tabelas na memória	Não	Yes	No

¹ A estrutura de preços simplificada para o SQL Database Hyperscale chegou em dezembro de 2023. Consulte o blog de preços do Hyperscale para obter detalhes.

² Desde dezembro de 2023, Benefício Híbrido do Azure não está disponível para novas bases de dados Hyperscale, nem para subscrições de desenvolvimento/teste. As bases de dados Hyperscale existentes com computação provisionada podem continuar a usar o Benefício Híbrido do Azure para poupar nos custos de computação até dezembro de 2026. Para obter mais informações, consulte o blog de preços do Hyperscale.

³ Atualmente, as opções de 160 e 192 vCore são uma funcionalidade de pré-visualização.

Recursos computacionais

A tabela seguinte compara recursos de computação em diferentes configurações de hardware e níveis de computação para Base de Dados SQL do Azure Hyperscale. Para o Base de Dados SQL do Azure que não seja Hyperscale, consulte o modelo de compra vCore - Base de Dados SQL do Azure.

Configuração de hardware	CPU	Memória
Série Standard (Gen5)	Computação provisionada - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milão), AMD EPYC 9004 (Genoa), Intel® Xeon® Platinum 8573C (Emerald Rapids) - Configuração de até 128 vCores (hyper-threaded) Computação sem servidor - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milão), AMD EPYC 9004 (Genoa), Intel® Xeon® Platinum 8573C (Emerald Rapids) - Autoescalar até 80 vCores (hyper-threading) - A relação memória/vCore adapta-se dinamicamente à memória e ao uso da CPU com base na demanda de carga de trabalho e pode chegar a 24 GB por vCore. Por exemplo, em um determinado momento, uma carga de trabalho pode usar e ser cobrada por 240 GB de memória e apenas 10 vCores.	Computação provisionada - 5,1 GB por vCore - Provisionamento de até 625 GB Computação sem servidor - Dimensionamento automático de até 24 GB por vCore - Dimensionamento automático até 240 GB no máximo
Série Premium	Computação provisionada - Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milão), AMD EPYC 9004 (Génova), processadores Intel® Xeon® Platinum 8573C (Emerald Rapids) - Provisão até 192 vCores (hiper-threaded).	5,2 GB por vCore
Memória de série premium otimizada	Computação provisionada - Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milão), AMD EPYC 9004 (Génova), processadores Intel® Xeon® Platinum 8573C (Emerald Rapids) - Provisionar até 80 vCores (hiper-threaded).	10,2 GB por vCore

* Para um dado tamanho de computação e configuração de hardware, os limites de recursos são os mesmos independentemente do tipo de CPU (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Emerald Rapid, ou AMD Milan, Genoa). Na vista de gestão dinâmica sys.dm_user_db_resource_governance, a geração de hardware para bases de dados:

Os processadores Intel® SP-8160 (Skylake) aparecem como Gen6
Intel® 8272CL (Cascade Lake) aparece como Gen7
Intel® Xeon® Platinum 8370C (Ice Lake) ou AMD EPYC™ 7763v (Milão) aparecem como Gen8
AMD EPYC™ 9004 (Génova) aparecem como Gen9 ou Intel® Xeon® Platinum 8573C (Emerald Rapids) aparecem como Gen10

Para mais informações, consulte os limites de recursos para bancos de dados únicos e pools elásticos.

Criar e gerenciar bancos de dados Hyperscale

Pode criar e gerir bases de dados Hyperscale usando o portal Azure, Transact-SQL, PowerShell e a CLI do Azure. Para obter mais informações, consulte Guia de início rápido : criar um banco de dados de hiperescala.

Operation	Detalhes	Mais informações
Criar um banco de dados Hyperscale	As bases de dados em hiperescala só estão disponíveis utilizando o modelo de compras baseado em vCore.	Encontre exemplos para criar uma base de dados Hyperscale em Quickstart: Crie uma base de dados Hyperscale em Base de Dados SQL do Azure.
Converter um banco de dados existente em Hyperscale	Pode converter uma base de dados existente para o nível Base de Dados SQL do Azure Hyperscale. A duração da conversão depende do tamanho dos dados.	Para obter mais informações, consulte Converter um banco de dados existente em Hyperscale.
Reverter a migração de um banco de dados Hyperscale para a camada de serviço de uso geral	Se anteriormente migrou a sua Base de Dados SQL do Azure existente para o Hyperscale, pode reverter e migrar a base de dados para o nível de serviço de Propósito Geral num prazo de 45 dias após a migração original para o Hyperscale. Se quiser migrar a base de dados para outro nível de serviço, como Business Critical, primeiro migre de forma reversa para o nível de serviço de Uso Geral e depois altere o nível de serviço.	Saiba como reverter a migração do Hyperscale, incluindo as limitações de para migração reversa.

Limitações

Estas limitações aplicam-se atualmente ao nível de serviço Hyperscale. A equipa de produto está a trabalhar ativamente para remover o maior número possível destas limitações.

Questão	Descrição
A redução é bloqueada quando a TDE está desativada	Atualmente, o Base de Dados SQL do Azure Hyperscale não suporta operações de redução de bases de dados e ficheiros quando o Encriptação de Dados Transparente (TDE) está desativado.
Restaurar banco de dados de outras camadas de serviço	Não é possível restaurar uma base de dados não Hyperscale como uma base de dados Hyperscale. Também não podes restaurar uma base de dados Hyperscale como uma base de dados que não seja Hyperscale. Para bases de dados migradas para Hyperscale a partir de outros níveis de serviço do Base de Dados SQL do Azure, os backups pré-migração são mantidos durante o período de retenção de backup da base de dados de origem, incluindo políticas de retenção a longo prazo. Pode restaurar uma cópia de segurança anterior à migração dentro do período de retenção das cópias de segurança da base de dados pela linha de comandos. Você pode restaurar esses backups para qualquer camada de serviço que não seja de hiperescala.
Migração de bases de dados contendo objetos OLTP In-Memory	O Hyperscale suporta um subconjunto de In-Memory objetos OLTP, incluindo tipos de tabela com otimização de memória, variáveis de tabela e módulos compilados nativamente. No entanto, quando quaisquer objetos OLTP In-Memory estão presentes no banco de dados que está a ser migrado, a migração das camadas de serviço Premium e Business Critical para Hyperscale não é suportada. Para migrar uma base de dados deste tipo para o Hyperscale, tem de eliminar todos os objetos OLTP em memória e as respetivas dependências. Depois de a base de dados ser migrada, pode recriar estes objetos. Atualmente, no Hyperscale, não são suportadas tabelas otimizadas para memória, tanto duráveis quanto não duráveis, e estas devem ser alteradas para tabelas de disco.
Verificação da integridade do banco de dados	`DBCC CHECKDB`e `DBCC CHECKFILEGROUP` atualmente não são suportados para bases de dados Base de Dados SQL do Azure Hyperscale. Como solução alternativa, use `DBCC CHECKTABLE ('TableName') WITH TABLOCK`. Para detalhes sobre gestão de integridade de dados no Base de Dados SQL do Azure, consulte Data Integrity in Base de Dados SQL do Azure.
Trabalhos elásticos	Não há suporte para o uso de um banco de dados Hyperscale como o banco de dados Job. No entanto, no Base de Dados SQL do Azure, as tarefas elásticas podem direcionar bases de dados Hyperscale da mesma forma que qualquer outra base de dados.
Sincronização de Dados	Não há suporte para o uso de um banco de dados Hyperscale como um banco de dados de metadados de hub ou de sincronização. No entanto, uma base de dados Hyperscale pode ser uma base de dados membro numa topologia de Sincronização de Dados.
Hardware de camada de serviço Hyperscale da série premium	Atualmente, o hardware da série premium e otimizado para memória não suporta a camada de computação sem servidor. O Serverless só é suportado em hardware da série Standard (Gen5).
Disponibilidade regional	Hardware da série premium e hardware otimizado para memória da série premium no nível de serviço Hyperscale está disponível em regiões limitadas do Azure. Para uma lista, consulte a disponibilidade da série premium Hyperscale em .

Comentários

Esta página foi útil?

Last updated on 2026-06-23