Modelo de compra do vCore – Banco de Dados SQL do Azure

2025-05-28

Aplica-se a:Banco de Dados SQL do Azure

Este artigo analisa o modelo de compra do vCore para o Banco de Dados SQL do Azure.

Visão geral

Um vCore (núcleo virtual) representa uma CPU lógica e oferece a opção para escolher as características físicas do hardware (por exemplo, o número de núcleos, a memória e o tamanho do armazenamento). O modelo de compra baseado em vCore fornece flexibilidade, controle, transparência do consumo de recursos individual e uma forma simples de mover os requisitos de carga de trabalho local para a nuvem. Esse modelo otimiza o preço e permite que você escolha recursos de computação, memória e armazenamento de acordo com suas necessidades de carga de trabalho.

No modelo de compra baseado em vCore, seus custos dependem da escolha e do uso de:

Nível de serviço
Configuração de hardware
Recursos de computação (o número de vCores e a quantidade de memória)
Armazenamento de banco de dados reservado
Armazenamento de backup real

Importante

Recursos de computação, E/S e armazenamento de dados e log são cobrados por banco de dados ou pool elástico. O armazenamento de backup é cobrado por cada banco de dados. Para obter detalhes sobre preços, confira a página de preços do Banco de Dados SQL do Azure.

Comparar modelos de compra vCore e DTU

O modelo de compra do vCore usado pelo Banco de Dados SQL do Azure oferece vários benefícios em relação ao modelo de compra baseado em DTU:

Computação, memória, E/S e limites de armazenamento mais altos.
Escolha de configuração de hardware para corresponder melhor aos requisitos de computação e memória da carga de trabalho.
Descontos de preços com o AHB (Benefício Híbrido do Azure).
Maior transparência nos detalhes de hardware que alimentam a computação, o que facilita o planejamento de migrações de implantações locais.
O preço da instância reservada só está disponível para o modelo de compra do vCore.
Granularidade de dimensionamento mais alta com vários tamanhos de computação disponíveis.

Para obter ajuda com a escolha entre os modelos de compra vCore e DTU, consulte as diferenças entre os modelos de compra baseados em vCore e DTU.

Computação

O modelo de compra baseado em vCore tem uma camada de computação provisionada e uma camada de computação sem servidor . Na camada de computação provisionada, o custo de computação reflete a capacidade de computação total provisionada continuamente para o aplicativo independentemente da atividade de carga de trabalho. Escolha a alocação de recursos que melhor atenda às suas necessidades de negócios com base nos requisitos de vCore e memória e, em seguida, dimensione os recursos para cima e para baixo conforme necessário para sua carga de trabalho. Na camada de computação sem servidor do Banco de Dados SQL do Azure, os recursos de computação são dimensionados automaticamente com base na capacidade de carga de trabalho e cobrados pela quantidade de computação usada, por segundo.

Para resumir:

Embora a camada de computação provisionada forneça uma quantidade específica de recursos de computação que são provisionados continuamente independentemente da atividade de carga de trabalho, a camada de computação sem servidor dimensiona automaticamente os recursos de computação com base na atividade de carga de trabalho.
Enquanto a camada de computação provisionada cobra a quantidade de computação provisionada a um preço fixo por hora, a camada de computação sem servidor cobra a quantidade de computação usada, por segundo.

Independentemente da camada de computação, três réplicas secundárias de alta disponibilidade adicionais são alocadas automaticamente na camada de serviço Comercialmente Crítico para fornecer alta resiliência a falhas e failovers rápidos. Essas réplicas adicionais tornam o custo aproximadamente 2,7 vezes maior do que na camada de serviço de Uso Geral. Da mesma forma, o custo de armazenamento mais alto por GB na camada de serviço Comercialmente Crítico reflete os limites de E/S mais altos e a latência mais baixa do armazenamento SSD local.

Na Hiperescala, os clientes controlam o número de réplicas adicionais de alta disponibilidade de 0 a 4 para obter o nível de resiliência exigido por seus aplicativos enquanto controlam os custos.

Para obter mais informações sobre computação no Banco de Dados SQL do Azure, consulte Recursos de computação (CPU e memória).

Limites de recursos

Para os limites de recursos do vCore, examine as configurações de Hardware disponíveis e examine os limites de recursos para:

Armazenamento de dados e de log

Os fatores a seguir afetam a quantidade de armazenamento usada para arquivos de log e dados e se aplicam às camadas Uso Geral e Comercialmente Crítico.

Cada tamanho de computação dá suporte a um tamanho de dados máximo configurável, com um padrão de 32 GB.
Quando você configura o tamanho máximo de dados, 30% extra do armazenamento faturável é adicionado automaticamente para o arquivo de log.
Na camada de serviço de uso geral, o tempdb usa o armazenamento SSD local, e esse custo de armazenamento é incluído no preço do vCore.
Na camada de serviço Comercialmente Crítico, tempdb compartilha o armazenamento SSD local com dados e arquivos de log, e o custo de armazenamento tempdb está incluído no preço do vCore.
Nas camadas Uso Geral e Comercialmente Crítico, você é cobrado pelo tamanho máximo de armazenamento configurado para um banco de dados ou pool elástico.
Para o Banco de Dados SQL, você pode selecionar qualquer tamanho máximo de dados entre 1 GB e o tamanho máximo de armazenamento com suporte, em incrementos de 1 GB.

As seguintes considerações de armazenamento se aplicam à Hiperescala:

O tamanho máximo do armazenamento de dados é definido como 128 TB e não é configurável.
Você é cobrado apenas pelo armazenamento de dados alocado, não pelo armazenamento máximo de dados.
Você não é cobrado pelo armazenamento de logs.
tempdb usa o armazenamento SSD local e seu custo está incluído no preço do vCore. Para monitorar o tamanho atual do armazenamento de dados alocado e usado no Banco de Dados SQL, use as métricasde allocated_data_storage e armazenamento do Azure Monitor, respectivamente.

Para monitorar o tamanho atual de armazenamento alocado e usado dos arquivos de dados e de log em um banco de dados usando T-SQL, utilize a visão sys.database_files e a função FILEPROPERTY(... , 'SpaceUsed').

Dica

Em algumas circunstâncias, talvez seja necessário reduzir um banco de dados para recuperar o espaço não utilizado. Para obter mais informações, consulte gerenciar o espaço de arquivo no banco de dados SQL do Azure.

Armazenamento de cópias de segurança

O armazenamento para backups de banco de dados é alocado para dar suporte aos recursos pitr (restauração pontual) e LTR (retenção de longo prazo) do Banco de Dados SQL. Esse armazenamento é separado do armazenamento de arquivos de dados e de log e é cobrado separadamente.

PITR: Em camadas de Uso Geral e Comercialmente Críticos, os backups de banco de dados individuais são copiados automaticamente para o armazenamento do Azure . O tamanho do armazenamento aumenta dinamicamente conforme backups são criados. O armazenamento é usado por backups completos, diferenciais e de log de transações. O consumo de armazenamento depende da taxa de alteração do banco de dados e do período de retenção configurado para backups. Você pode configurar um período de retenção separado para cada banco de dados entre 1 e 35 dias para o Banco de Dados SQL. Uma quantidade de armazenamento de backup igual ao tamanho de dados máximo configurado é fornecida sem encargos extras.
LTR: Você também pode configurar a retenção de longo prazo de backups completos por até 10 anos. Se você configurar uma política LTR, esses backups serão armazenados automaticamente no Armazenamento de Blobs do Azure, mas você poderá controlar a frequência com que os backups são copiados. Para atender a diferentes requisitos de conformidade, é possível selecionar diferentes períodos de retenção para backups semanais, mensais e/ou anuais. A configuração escolhida determina a quantidade de armazenamento que é usada para backups de LTR. Para obter mais informações, confira Retenção de backup de longo prazo.

Para armazenamento de backup na Hiperescala, consulte backups automatizados para bancos de dados de Hiperescala.

Níveis de serviço

As opções da camada de serviço no modelo de compra do vCore incluem Uso Geral, Comercialmente Crítico e Hiperescala. A camada de serviço geralmente determina o tipo de armazenamento e o desempenho, a alta disponibilidade e as opções de recuperação de desastre e a disponibilidade de determinados recursos, como In-Memory OLTP.

Caso de uso	de Uso Geral	Comercialmente Crítico	Hiperescala
Mais adequado para	A maioria das cargas de trabalho comerciais. Oferece opções de armazenamento e de computação voltadas para o orçamento, equilibradas e escalonáveis.	Oferece aos aplicativos de negócios a maior resiliência a falhas usando várias réplicas secundárias de alta disponibilidade e fornece o melhor desempenho de E/S.	A maior variedade de cargas de trabalho, incluindo essas cargas de trabalho com armazenamento altamente escalonável e requisitos de escala de leitura. Oferece maior resiliência a falhas, permitindo a configuração de mais de uma réplica secundária de alta disponibilidade.
Tamanho da computação	Dois a 128 vCores	Dois a 128 vCores	Dois a 128 vCores
Tipo de armazenamento	Armazenamento remoto Premium (por instância)	Armazenamento SSD local super rápido (por instância)	Armazenamento desacoplado com cache SSD local (por réplica de computação)
Tamanho de armazenamento	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
IOPS	320 IOPS por vCore com 16.000 IOPS no máximo	4.000 IOPS por vCore com máximo de 327.680 IOPS	327.680 IOPS com SSD local máximo A Hiperescala é uma arquitetura de várias camadas com cache em vários níveis. O IOPS efetivo 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 de backup com redundância geográfica, com redundância de zona ou com redundância local, retenção de 1 a 35 dias (padrão de 7 dias) Retenção de longo prazo disponível por até 10 anos	Uma opção de armazenamento de backup com redundância geográfica, com redundância de zona ou com redundância local, retenção de 1 a 35 dias (padrão de 7 dias) Retenção de longo prazo disponível por até 10 anos	Uma escolha 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 padrão), com até 10 anos de retenção de longo prazo disponíveis
Disponibilidade	Uma réplica, nenhuma réplica de escala de leitura, Alta disponibilidade (HA) com redundância de zona	Três réplicas, uma réplica de escala de leitura, Alta disponibilidade (HA) com redundância de zona	Alta disponibilidade (HA) com redundância de zona
Preço/cobrança	O vCore, o armazenamento reservado e o armazenamento de backup são cobrados. IOPS não são cobrados.	O vCore, o armazenamento reservado e o armazenamento de backup são cobrados. IOPS não são cobrados.	VCore para cada réplica e armazenamento usado são cobrados. IOPS não são cobrados.
Modelos de desconto	Reservas do Azure Benefício Híbrido do Azure (não disponível em assinaturas de desenvolvimento/teste) Assinaturas de ofertas de Desenvolvimento/Teste com Pagamento Conforme o Uso e Enterprise	Reservas do Azure Benefício Híbrido do Azure (não disponível em assinaturas de desenvolvimento/teste) Assinaturas de ofertas de Desenvolvimento/Teste com Pagamento Conforme o Uso e Enterprise	Benefício Híbrido do Azure (não disponível em assinaturas de desenvolvimento/teste) ¹ Assinaturas de ofertas de Desenvolvimento/Teste com Pagamento Conforme o Uso e Enterprise
Tabelas OLTP na memória	Não	Sim	Não

¹ Em breve, precificação simplificada para o Banco de Dados SQL Hiperescala. Consulte o blog de preços de Hiperescala para obter detalhes.

Para obter mais detalhes, examine os limites de recursos para servidor lógico, bancos de dados individuais e bancos de dados em pool.

Observação

Para obter mais informações sobre o SLA (Contrato de Nível de Serviço), consulte SLA para o Banco de Dados SQL do Azure

Uso Geral

O modelo de arquitetura da camada de serviço de uso geral é baseado na separação entre computação e armazenamento. Esse modelo de arquitetura baseia-se na alta disponibilidade e na confiabilidade do Armazenamento de Blobs do Azure, que replica os arquivos de banco de dados de modo transparente e garante que não haja perda de dados se ocorrer uma falha na infraestrutura subjacente.

A figura a seguir mostra quatro nós no modelo de arquitetura padrão com as camadas de computação e armazenamento separadas.

Diagrama ilustrando a separação de computação e armazenamento.

No modelo de arquitetura da camada de serviço de uso geral, há duas camadas:

Uma camada de computação sem estado que está executando o processo sqlservr.exe e contém apenas dados temporários e armazenados em cache (por exemplo, cache de plano, conjunto de buffers, conjunto de columnstore). Este nó sem estado é operado pelo Azure Service Fabric, que inicializa o processo, controla a integridade do nó e executa o failover para outro local, quando necessário.
Uma camada de dados com estado, com arquivos de banco de dados (.mdf/.ldf) que são armazenados no Armazenamento de Blobs do Azure. O Armazenamento de Blobs do Azure garante que não haja perda de dados de nenhum registro que seja colocado em qualquer arquivo de banco de dados. O Armazenamento do Azure tem disponibilidade/redundância de dados interna que garante que cada registro no arquivo de log ou página no arquivo de dados seja preservado mesmo se o processo falhar.

Sempre que o mecanismo de banco de dados ou o sistema operacional é atualizado, alguma parte da infraestrutura subjacente falha ou, se algum problema crítico for detectado no processo, o sqlservr.exe Azure Service Fabric move o processo sem estado para outro nó de computação sem estado. Há um conjunto de nós sobressalentes que está aguardando para executar um novo serviço de computação se ocorrer um failover do nó primário para minimizar o tempo de failover. Os dados na camada de armazenamento do Azure não são afetados e os arquivos de dados/log são anexados ao processo inicializado recentemente. Esse processo garante disponibilidade de 99,99% por padrão e 99,995% disponibilidade quando a redundância de zona estiver habilitada. Pode haver alguns impactos de desempenho em cargas de trabalho pesadas que estão em pré-lançamento devido ao tempo de transição e ao fato de que o novo nó começa com cache frio.

Quando escolher a camada de serviço de Uso Geral

A camada de serviço de Uso Geral é a camada de serviço padrão no Banco de Dados SQL do Azure projetada para a maioria das cargas de trabalho genéricas. Se você precisar de um mecanismo de banco de dados totalmente gerenciado com um SLA padrão e latência de armazenamento entre 5 ms e 10 ms, a camada de Uso Geral será a opção para você.

Comercialmente Crítico

O modelo de camada de serviço Comercialmente Crítico se baseia em um cluster de processos de mecanismo de banco de dados. Esse modelo de arquitetura depende de um quorum de nós do mecanismo de banco de dados para minimizar os impactos de desempenho em sua carga de trabalho, mesmo durante as atividades de manutenção. Atualizações e patches do sistema operacional subjacente, drivers e o mecanismo de banco de dados ocorrem de forma transparente, com tempo de inatividade mínimo para os usuários finais.

No modelo Comercialmente Crítico, a computação e o armazenamento são integrados em cada nó. A replicação de dados entre os processos do mecanismo de banco de dados em cada nó de um cluster de quatro nós resulta em alta disponibilidade, com cada nó usando o SSD anexado localmente como armazenamento de dados. O diagrama a seguir mostra como a camada de serviço Business Critical organiza um cluster de nós do mecanismo de banco de dados em réplicas de grupo de disponibilidade.

O processo do mecanismo de banco de dados e os arquivos .mdf/.ldf subjacentes são colocados no mesmo nó com armazenamento SSD anexado localmente, fornecendo baixa latência à sua carga de trabalho. A alta disponibilidade é implementada usando tecnologia semelhante ao SQL Server Grupos de Disponibilidade AlwaysOn. Cada banco de dados é um cluster de nós de banco de dados com uma réplica primária acessível para cargas de trabalho do cliente e três réplicas secundárias contendo cópias de dados. A réplica primária envia constantemente alterações para as réplicas secundárias para garantir que os dados estão disponíveis em réplicas secundárias se o primário falhar por algum motivo. O failover é tratado pelo Service Fabric e pelo motor de banco de dados – uma réplica secundária se torna a primária e uma nova réplica secundária é criada para garantir que haja nós suficientes no cluster. A carga de trabalho é redirecionada automaticamente para a nova réplica primária.

Além disso, o cluster Comercialmente Crítico tem a funcionalidade interna de Expansão de Leitura que fornece uma réplica somente leitura gratuita que pode ser usada para executar consultas somente leitura (por exemplo, relatórios) que não afetam o desempenho da carga de trabalho da sua réplica primária.

Quando escolher a camada de serviço Comercialmente Crítico

A camada de serviço Crítico para os Negócios foi projetada para aplicativos que precisam de respostas de baixa latência do armazenamento SSD subjacente (em média de 1 a 2 ms), recuperação mais rápida caso a infraestrutura subjacente falhe, ou que necessitem de alívio de carga para relatórios, análises e consultas somente leitura para a réplica secundária legível e gratuita do banco de dados primário.

Estes são os principais motivos pelos quais você deve escolher a camada de serviço Comercialmente Crítico em vez da camada de Uso Geral:

Requisitos de baixa latência de E/S – cargas de trabalho que precisam de uma resposta consistentemente rápida da camada de armazenamento (de 1 a 2 milissegundos em média) devem usar a camada Crítico para Negócios.
Carga de trabalho com relatórios e consultas analíticas para as quais uma única réplica secundária somente leitura gratuita é suficiente.
Resiliência superior e recuperação mais rápida de falhas. Caso haja uma falha no sistema, o banco de dados na instância primária será desabilitado e uma das réplicas secundárias se tornará imediatamente o novo banco de dados primário de leitura/gravação, pronto para processar consultas.
Proteção de corrupção de dados avançada. Como a camada Comercialmente Crítica usa réplicas de bancos de dados nos bastidores, o serviço usa o reparo automático de página disponível com espelhamento e grupos de disponibilidade para ajudar a reduzir a corrupção de dados. Se uma réplica não conseguir ler uma página devido a um problema de integridade dos dados, uma nova cópia da página será recuperada de outra réplica, substituindo a página ilegível sem perda de dados nem tempo de inatividade do cliente. Essa funcionalidade está acessível na camada de uso geral se o banco de dados tiver uma réplica geo-secundária.
Disponibilidade mais alta: a camada Comercialmente Crítico na configuração de múltiplas zonas de disponibilidade fornece resiliência para falhas zonais e um SLA de maior disponibilidade.
Recuperação geográfica rápida – quando a replicação geográfica ativa é configurada, a camada comercialmente crítica tem um Objetivo de Ponto de Recuperação (RPO) garantido de 5 segundos e um Objetivo de Tempo de Recuperação (RTO) de 30 segundos para 100% de horas implantadas.

Hiperescala

A camada de serviço Hiperescala é adequada para todos os tipos de carga de trabalho. Sua arquitetura nativa de nuvem fornece computação e armazenamento escalonáveis independentemente para dar suporte à maior variedade de aplicativos tradicionais e modernos. Os recursos de computação e armazenamento na Hiperescala excedem substancialmente os recursos disponíveis nas camadas Uso Geral e Comercialmente Crítico.

Para saber mais, revise a camada de serviço Hyperscale do Banco de Dados SQL do Azure.

Quando escolher a camada de serviço Hyperscale

A camada de serviço da Hiperescala elimina muitos dos limites práticos vistos tradicionalmente em bancos de dados de nuvem. Onde mais outros bancos de dados são limitados pelos recursos disponíveis em um único nó, bancos de dados na camada de serviço da Hiperescala não têm esses limites. Com sua arquitetura de armazenamento flexível, um banco de dados de Hiperescala cresce conforme necessário e você é cobrado apenas pela capacidade de armazenamento que você usa.

Além de seus recursos avançados de dimensionamento, a Hiperescala é uma ótima opção para qualquer carga de trabalho, não apenas para bancos de dados grandes. Com a Hiperescala, você pode:

Obtenha alta resiliência e recuperação rápida de falhas ao controlar o custo, escolhendo o número de réplicas de alta disponibilidade de 0 a 4.
Melhore a alta disponibilidade habilitando a redundância de zona para computação e armazenamento.
Obtenha baixa latência de E/S (de 1 a 2 milissegundos em média) para a parte acessada com frequência do banco de dados. Para bancos de dados menores, isso pode se aplicar a todo o banco de dados.
Implemente uma grande variedade de cenários de expansão de leitura com réplicas nomeadas.
Aproveite o dimensionamento rápido, sem esperar que os dados sejam copiados para o armazenamento local em novos nós.
Aproveite o backup de banco de dados contínuo de impacto zero e a restauração rápida.
Dê suporte aos requisitos de continuidade de negócios usando grupos de failover e replicação geográfica.

Configuração de hardware

As configurações de hardware comuns no modelo vCore incluem série padrão (Gen5), série premium, memória de série premium otimizada e série DC. A hiperescala também fornece uma opção para hardwares da série premium e otimizados para memória da série premium. A configuração de hardware define limites de computação e memória e outras características que afetam o desempenho da carga de trabalho.

Determinadas configurações de hardware, como a série padrão (Gen5), podem usar mais de um tipo de processador (CPU), conforme descrito em recursos de computação (CPU e memória). Embora um determinado banco de dados ou pool elástico tende a permanecer no hardware com o mesmo tipo de CPU por um longo tempo (geralmente por vários meses), há certos eventos que podem fazer com que um banco de dados ou pool seja movido para o hardware que usa um tipo de CPU diferente.

Um banco de dados ou pool pode ser movido para uma variedade de cenários, incluindo, mas não limitado a quando:

O objetivo do serviço é alterado
A infraestrutura atual em um datacenter está se aproximando dos limites de capacidade
O hardware atualmente usado está sendo desativado devido ao seu fim de vida útil
A configuração com redundância de zona está habilitada, movendo-se para um hardware diferente devido à capacidade disponível

Para algumas cargas de trabalho, uma mudança para um tipo de CPU diferente pode alterar o desempenho. O Banco de Dados SQL configura o hardware com a meta de fornecer desempenho previsível de carga de trabalho mesmo se o tipo de CPU for alterado, mantendo as alterações de desempenho dentro de uma banda estreita. No entanto, em todo o espectro de cargas de trabalho do cliente no Banco de Dados SQL e à medida que novos tipos de CPUs se tornam disponíveis, ocasionalmente é possível ver alterações mais perceptíveis no desempenho, se um banco de dados ou pool se mover para um tipo de CPU diferente.

Independentemente do tipo de CPU usado, os limites de recursos para um banco de dados ou pool elástico (como o número de núcleos, memória, IOPS de dados máximo, taxa máxima de log e trabalhos simultâneos máximos) permanecem os mesmos, desde que o banco de dados permaneça no mesmo objetivo de serviço.

Recursos de computação (CPU e memória)

A tabela a seguir compara os recursos de computação em diferentes configurações de hardware e camadas de computação:

Configuração de hardware	CPU (Unidade Central de Processamento)	Memória
Série Standard (Gen 5)	Computação provisionada – Processadores 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) – Provisionar até 128 vCores (hyper-threaded) Computação sem servidor* – Processadores 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) – Dimensionamento automático para até 80 vCores (hyper-threaded) – A taxa de memória para vCore se adapta dinamicamente à memória e ao uso da CPU com base na demanda de carga de trabalho e pode ser de até 24 GB por vCore. Por exemplo, em um determinado momento, uma carga de trabalho pode utilizar 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 para até 24 GB por vCore – Dimensionamento automático para um máximo de 240 GB
Fsv2-series**	– Processadores Intel® 8168 (Skylake) - Apresentando uma velocidade sustentada de turbo em todos os núcleos de 3,4 GHz e uma velocidade máxima de turbo em núcleo único de 3,7 GHz. - Provisionar até 72 vCores (hiper-threaded)	- 1,9 GB por vCore - Provisionar até 136 GB
Série DC	– Processadores Intel® Xeon® E-2288G - Apresentando a Extensão de Proteção de Software Intel (Intel SGX) - Provisionar até 8 vCores (físico)	4,5 GB por vCore

* No modo de exibição de gerenciamento dinâmico sys.dm_user_db_resource_governance, a geração de hardware para bancos de dados usando processadores Intel® SP-8160 (Skylake) aparece como Gen6, a geração de hardware para bancos de dados usando Intel® 8272CL (Cascade Lake) aparece como Gen7 e a geração de hardware para bancos de dados usando Intel® Xeon® Platinum 8370C (Ice Lake) ou AMD® EPYC® 7763v (Milan) aparecem como Gen8. Para um determinado 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 ou AMD Milan).

** O hardware da série Fsv2 será desativado em 1º de outubro de 2026.

Para saber mais, confira os limites de recurso para bancos de dados individuais e pools elásticos.

Para obter recursos de computação e especificação de banco de dados de Hiperescala, consulte Hyperscale compute resources.

Série Standard (Gen 5)

O hardware de série padrão (Gen5) fornece recursos de computação e memória equilibrados e é adequado para a maioria das cargas de trabalho de banco de dados.

O hardware da série standard (Gen5) está disponível em todas as regiões públicas em todo o mundo.

Hiperescala série-premium

As opções de hardware da série Premium usam a mais recente tecnologia de CPU e memória da Intel e da AMD. A série Premium fornece um aumento no desempenho de computação em relação ao hardware da série padrão.

A opção da série Premium oferece um desempenho mais rápido da CPU em comparação com a série Standard e um número maior de vCores máximos.
A opção otimizada para memória da série Premium oferece o dobro da quantidade de memória em relação à série Standard.

A série standard, as séries premium e a memória premium otimizadas estão disponíveis para pools elásticos de Hiperescala.

Para obter mais informações, consulte o comunicado do blog da série Premium da Hiperescala.

Para ver as regiões disponíveis, consulte disponibilidade da série premium Hyperscale.

Série DC

O hardware da série DC usa processadores Intel com tecnologia Intel SGX (Software Guard Extensions).
A série DC é necessária para Always Encrypted com enclaves seguros em cargas de trabalho que exigem uma proteção de segurança mais forte para enclaves de hardware, em comparação com enclaves baseados em Segurança de Virtualização (VBS).
A série DC foi projetada para cargas de trabalho que processam dados confidenciais e exigem recursos de processamento de consulta confidencial, fornecidos pelo Always Encrypted com enclaves seguros.
O hardware da série DC fornece recursos de computação e memória balanceados.

A série DC só tem suporte para computação provisionada (não há suporte para computação sem servidor) e não oferece suporte à redundância de zona. Para regiões em que a série DC está disponível, consulte a disponibilidade da série DC.

Tipos de oferta do Azure compatíveis com a série DC

Para criar bancos de dados ou pools elásticos no hardware da série DC, a assinatura deve ser um tipo de oferta paga, incluindo Pagamento conforme o uso (You-Go) ou Contrato Enterprise Agreement (EA). Para obter uma lista completa dos tipos de oferta do Azure compatíveis com a série DC, consulte as ofertas atuais sem limites de gastos.

Selecionar configuração de hardware

Você pode selecionar a configuração de hardware para um banco de dados ou pool elástico no Banco de Dados SQL no momento da criação. Você também pode alterar a configuração de hardware de um banco de dados ou pool elástico existente.

Para selecionar uma configuração de hardware ao criar um Banco de Dados SQL ou pool

Para obter informações detalhadas, consulte Criar um Banco de Dados SQL.

Na guia Noções básicas , selecione o link Configurar banco de dados na seção Computação + armazenamento e selecione o link Alterar configuração :

Selecione a configuração de hardware desejada:

Para alterar a configuração de hardware de um Banco de Dados SQL ou pool existente

Para um banco de dados, na página Visão geral, selecione o link Tipo de preço :

Para um pool, na página Visão geral , selecione Configurar.

Siga as etapas para alterar a configuração e selecione a configuração de hardware, conforme descrito nas etapas anteriores.

Disponibilidade de hardware

Para obter informações sobre a disponibilidade de hardware de geração atual, consulte Disponibilidade de recursos por região para o Banco de Dados SQL do Azure.

Hardware de geração anterior

Série Fsv2

O hardware da série Fsv2 para o Banco de Dados SQL do Azure será desativado em 1º de outubro de 2026. Para minimizar a interrupção do serviço e manter o preço-desempenho, faça a transição para o hardware da Série Premium ou Standard (Gen5) da Hiperescala. Para obter mais informações, consulte Aviso de desativação: oferta da série FSV2 do Banco de Dados SQL do Azure. Para a maioria dos bancos de dados e cargas de trabalho, o hardware da série Premium da Hiperescala ou Série Standard (Gen5) fornece um desempenho de preço semelhante ou melhor do que o Fsv2. Para garantir, valide isso com seu banco de dados e cargas de trabalho específicos.

O Fsv2 fornece menos memória e tempdb por vCore do que outros hardwares, portanto, cargas de trabalho sensíveis a esses limites podem ter um desempenho melhor na série padrão (Gen5).
A série Fsv2 é suportada apenas na camada Propósito Geral.

Gen4

O hardware Gen4 foi desativado e não está disponível para provisionamento, upscaling ou downscaling. Migre seu banco de dados para uma geração de hardware com suporte para obter uma variedade mais ampla de escalabilidade de vCore e armazenamento, rede acelerada, melhor desempenho de E/S e latência mínima. Examine as opções de hardware para bancos de dados individuais e opções de hardware para pools elásticos. Para obter mais informações, confira O suporte terminou para hardware Gen 4 no Banco de Dados SQL do Azure.

Próxima etapa

Guia de Início Rápido: Criar um banco de dados individual – Banco de Dados SQL do Azure

Compartilhar via