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

Aplica-se a: Banco de Dados SQL do Azure

• Banco de Dados SQL do Azure
• Instância Gerenciada do SQL do Azure

Este artigo revisa o modelo de compra baseado em vCore do 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:

• Camada 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 log e dados 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 de vCore ou DTU

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

• Limites de computação, memória, E/S e armazenamento mais altos.
• Opção de configuração do hardware de maneira a corresponder melhor aos requisitos de computação e de memória da carga de trabalho.
• Descontos de preços para Benefício Híbrido do Azure (AHB).
• Maior transparência nos detalhes do hardware que executa 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 no modelo de compra baseado em vCore.
• Granularidade de escala mais alta com vários tamanhos de computação disponíveis.

Para ajudar a escolher entre os modelos de compra baseados em vCore e em DTU, confira as diferenças entre os dois modelos

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 da computação reflete a capacidade de computação total continuamente provisionada para o aplicativo, independente da atividade da carga de trabalho. Escolha a alocação de recursos mais adequada às suas necessidades comerciais de acordo com os requisitos de vCore e de memória e aumente e diminua os recursos conforme necessário para a carga de trabalho. Na camada de computação sem servidor do Banco de Dados SQL do Azure, os recursos de computação são escalados automaticamente de acordo com a capacidade da carga de trabalho e são 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 continuamente provisionados independentemente da atividade da carga de trabalho, a camada de computação sem servidor escala automaticamente os recursos de computação com base na atividade da carga de trabalho.
• Embora a camada de computação provisionada seja cobrada pela quantidade de computação provisionada a um preço fixo por hora, a camada de computação sem servidor é cobrada pela 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 Uso Geral. Da mesma forma, o custo de armazenamento mais alto por GB na camada de serviço Comercialmente Crítico reflete os limites maiores de E/S e a menor latência 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 pelos aplicativos, enquanto controlam os custos.

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

Limites de recursos

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

• servidores lógicos
• bancos de dados individuais
• bancos de dados em pools elásticos

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 máximo de dados, com um padrão de 32 GB.
• Quando você configura o tamanho máximo dos dados, 30% de armazenamento adicional faturável é adicionado automaticamente aos arquivos 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ê receberá uma cobrança pelo tamanho máximo de armazenamento configurado para um banco de dados ou um pool elástico.
• No Banco de Dados SQL do Azure, você pode selecionar qualquer tamanho máximo de dados entre 1 GB e o tamanho máximo do armazenamento compatível, 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 o custo está incluso no preço do vCore. A fim de monitorar o tamanho atual do armazenamento de dados alocado e usado no Banco de Dados SQL, use as métricasallocated_data_storage e storage do Azure Monitor, respectivamente.

Para monitorar o tamanho atual de armazenamento alocado e usado de dados individuais e arquivos de log em um banco de dados usando o T-SQL, use a exibiçã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 backup

O armazenamento para backups de banco de dados é alocado para dar suporte às funcionalidades de 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.

• Recuperação pontual: nas camadas Uso Geral e Comercialmente Crítico, os backups de bancos de dados individuais são copiados para o armazenamento do Azure automaticamente. 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. É possível 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ê pode configurar a LTR (retenção de longo prazo) de backups completos por até 10 anos. Se você configurar uma política de LTR, esses backups serão armazenados no armazenamento de blobs do Azure automaticamente, mas você poderá controlar a frequência com que os backups serã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, confira Backups automatizados para bancos de dados de Hiperescala.

Camadas de serviço

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

Caso de uso	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 maior desempenho de E/S.	A maior variedade de cargas de trabalho, incluindo cargas de trabalho com requisitos de armazenamento e escala de leitura altamente escalonáveis. Ela oferece maior resiliência a falhas, permitindo configurar 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. A IOPS efetiva 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, de zona ou local e com 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, de zona ou local e com 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 LRS (com redundância local), ZRS (com redundância de zona) ou GRS (com redundância geográfica) 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 em escala de leitura, HA (alta disponibilidade) com redundância de zona	Três réplicas, uma réplica de escala de leitura, HA (alta disponibilidade) com redundância de zona	HA (alta disponibilidade) 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.	O vCore de cada réplica e o armazenamento usado são cobrados. IOPS não são cobrados.
Modelos de desconto	Instâncias reservadas 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	Instâncias reservadas 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) 1 Assinaturas de ofertas de Desenvolvimento/Teste com Pagamento Conforme o Uso e Enterprise
Tabelas de OLTP in-memory	Não	Sim	Não

1 Preço simplificado para Hiperescala do Banco de Dados SQL em breve. Consulte o blog de preços de Hiperescala para obter detalhes.

Para obter mais detalhes, revise os limites de recursos de 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), confira SLA do 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.

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 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 cada página no arquivo de dados sejam preservados mesmo quando o processo do SQL Server falha.

Sempre que o mecanismo de banco de dados ou o sistema operacional é atualizado, alguma parte da infraestrutura subjacente falha ou, caso seja detectado algum problema crítico no processo do sqlservr.exe, o Azure Service Fabric move o processo sem estado para outro nó de computação sem estado. Há um conjunto de nós sobressalentes que fica esperando a execução do novo serviço de computação se ocorrer um failover do nó primário a fim de 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 recém-inicializado. Esse processo garante 99,99% de disponibilidade por padrão e 99,995% de disponibilidade quando a redundância de zona está habilitada. Pode haver alguns impactos no desempenho em cargas de trabalho pesadas que estão na versão piloto devido ao tempo de transição e ao fato de o novo nó ser iniciado com cache frio.

Quando escolher essa camada de serviço

A camada de serviço Uso Geral é uma camada padrão no Banco de Dados SQL do Azure que foi 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 Uso Geral será a opção ideal 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 se baseia no quorum dos nós do mecanismo de banco de dados para minimizar o impacto no desempenho na sua carga de trabalho, mesmo durante as atividades de manutenção. Upgrades e patches do sistema operacional subjacente, dos drivers e do mecanismo de banco de dados ocorrem de modo transparente com mínimo tempo de inatividade para 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 Comercialmente Crítico organiza um cluster de nós de 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 conectado localmente, que fornece baixa latência à sua carga de trabalho. A alta disponibilidade é implementada usando tecnologia semelhante ao SQL Server Grupos de Disponibilidade AlwaysOn. Todo o 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 que contêm cópias dos dados. A réplica primária efetua constantemente push de alterações para réplicas secundárias para garantir que os dados estejam disponíveis em réplicas secundárias, caso a réplica primária falhe por qualquer motivo. O failover é tratado pelo Service Fabric e pelo mecanismo de banco de dados. Uma réplica secundária se torna a primária e uma réplica secundária é criada para garantir que existam nós suficientes no cluster. A carga de trabalho é automaticamente redirecionada 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 essa camada de serviço

A camada de serviço Comercialmente Crítico foi projetada para aplicativos que requerem respostas de baixa latência do armazenamento SSD subjacente (de 1 a 2 ms em média), recuperação rápida se a infraestrutura subjacente falhar ou precisar transferir relatórios, análise e consultas somente leitura para a réplica secundária para leitura 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 rápida consistente da camada de armazenamento (de 1 a 2 ms em média) devem usar a camada de serviço Comercialmente Crítico.
• Carga de trabalho com consultas analíticas e de relatório em que uma réplica somente leitura secundária gratuita é suficiente.
• Resiliência superior e recuperação mais rápida de falhas. Em caso de falha do 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 que está pronto para processar consultas.
• Proteção de corrupção de dados avançada. Como a camada Comercialmente Crítico usa réplicas de bancos de dados nos bastidores, o serviço usa o reparo automático de página disponível com grupos de disponibilidade e espelhamento para ajudar a reduzir os dados corrompidos. 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 estará disponível na camada Uso Geral se o banco de dados tiver uma réplica geográfica 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 está configurada, a camada de serviço Comercialmente Crítico tem um RPO (objetivo de ponto de recuperação) garantido de 5 segundos e um RTO (objetivo de tempo de recuperação) de 30 segundos para 100% de horas implantadas.

Hiperescala

A camada de serviço Hiperescala é adequada para todos os tipos de carga de trabalho. A 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, leia Camada de serviço de Hiperescala para o Banco de Dados SQL do Azure.

Quando escolher essa camada de serviço

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 a arquitetura de armazenamento flexível, um banco de dados de Hiperescala cresce conforme necessário e você é cobrado apenas pela capacidade de armazenamento usada.

Além das funcionalidades avançadas de escala, a Hiperescala é uma ótima opção para qualquer carga de trabalho, não apenas para bancos de dados grandes. Com a Hiperescala, você consegue:

• Obter alta resiliência e recuperação rápida de falhas enquanto controla os custos, escolhendo o número de réplicas de alta disponibilidade de 0 a 4.
• Aprimorar a alta disponibilidade habilitando a redundância de zona para computação e armazenamento.
• Obter baixa latência de E/S (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 dos 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 a série Standard (Gen5), a série Fsv2 e a série DC. A Hiperescala também fornece uma opção para hardware série Premium e série Premium otimizado para memória. 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 Standard (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 período (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 um pool podem ser movidos em vários cenários, incluindo, entre outros, quando:

• O objetivo do serviço é alterado
• A infraestrutura atual em um datacenter está se aproximando dos limites de capacidade
• O hardware usado atualmente está sendo desativado devido ao fim de sua vida útil
• A configuração com redundância de zona está habilitada, sendo transferida para outro hardware por causa da 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 que o tipo de CPU seja 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 ficam disponíveis, ocasionalmente é possível ver alterações mais perceptíveis no desempenho se um banco de dados ou pool se move para um tipo de CPU diferente.

Independentemente do tipo de CPU usado, os limites de recursos para um banco de dados ou um pool elástico, como número de núcleos, memória, IOPS máxima de dados, taxa máxima de log e número máximo de trabalhos simultâneos, 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 recursos de computação em diferentes configurações de hardware e camadas de computação:

Configuração de hardware	CPU	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 (Milan) – 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 (Milan) – 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 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 para até 24 GB por vCore – Dimensionamento automático para um máximo de 240 GB
Série Fsv2	– Processadores Intel® 8168 (Skylake) – Incluindo velocidade turbo sustentada de 3,4 GHz em todos os núcleos e velocidade máxima de 3,7 GHz em apenas um núcleo. – Provisionar até 72 vCores (hyper-threaded)	– 1,9 GB por vCore – Provisionamento de até 136 GB
Série DC	- Processadores Intel® XEON E-2288G – Incluindo o Intel SGX (Software Guard Extension) – Provisionar até 8 vCores (físico)	4,5 GB por vCore

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

Para obter mais informações, confira limites de recurso para bancos de dados individuais e pools elásticos.

Para recursos de computação e especificação de banco de dados de Hiperescala, confira Recursos de computação de Hiperescala.

Série Standard (Gen 5)

• O hardware da série Standard (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 no mundo inteiro.

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 Standard.
• A opção da série Premium oferece um desempenho de CPU mais rápido e um número maior de vCores máximos em comparação com a série Standard.
• A opção otimizada para memória da série Premium oferece o dobro da quantidade de memória em relação à memória de série padrão.
• Memória de série padrão, série premium e série premium de memória otimizada estão disponíveis para pools elásticos de Hiperescala.

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

Para obter as regiões disponíveis, consulte Disponibilidade da série Premium da Hiperescala.

Série Fsv2

• A série Fsv2 é uma configuração de hardware que tem computação otimizada e oferece baixa latência de CPU e alta velocidade para a maioria das cargas de trabalho com maior demanda de CPU. Semelhante às configurações de hardware da série Premium de Hiperescala, a série Fsv2 é alimentada pela tecnologia mais recente de CPU e memória da Intel e AMD, permitindo que os clientes aproveitem o hardware mais recente ao usar bancos de dados e pools elásticos na camada de serviço Uso Geral.
• Dependendo da carga de trabalho, a série Fsv2 pode fornecer mais desempenho de CPU por vCore do que outros tipos de hardware. Por exemplo, o tamanho da computação de 72 vCores da Fsv2 pode fornecer mais desempenho de CPU do que 80 vCores na série Standard (Gen5), a um custo menor.
• A Fsv2 fornece menos memória e um tempdb para cada vCore em comparação com outros hardwares, portanto, as cargas de trabalho sensíveis a esses limites podem ter um desempenho melhor na série Standard (Gen5).

A série Fsv2 tem suporte somente na camada de Uso Geral. Para regiões em que a série Fsv2 está disponível, confira disponibilidade da série Fsv2.

Série DC

• O hardware da série DC usa processadores Intel com a tecnologia Intel SGX (Software Guard Extensions).
• A série DC é necessária para cargas de trabalho Always Encrypted com enclaves seguros que exigem maior proteção de segurança de enclaves de hardware, em comparação com enclaves de segurança baseada em virtualização (VBS).
• A série DC foi projetada para cargas de trabalho que processam dados confidenciais e exigem funcionalidades de processamento de consulta confidencial, fornecidas pelo Always Encrypted com enclaves seguro.
• O hardware da série DC fornece recursos de computação e de memória equilibrados.

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

Tipos de oferta do Azure com suporte da série DC

Para criar bancos de dados ou pools elásticos em hardware da série DC, a assinatura deve ser de um tipo de oferta paga, incluindo Pagamento Conforme o Uso ou EA (Contrato Enterprise). Para ver uma lista completa dos tipos de oferta do Azure com suporte da série DC, confira 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 em 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 pool ou Banco de Dados SQL

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

Na guia Básico, 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 pool ou Banco de Dados SQL 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 o hardware da geração anterior, confira Disponibilidade do hardware da geração anterior.

Série Standard (Gen 5)

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

Hiperescala série Premium

A camada de serviço da Hiperescala nas séries premium e o hardware otimizado para memória da série premium estão disponíveis para bancos de dados individuais e pools elásticos nas seguintes regiões:

• Leste da Austrália **
• Sudeste da Austrália
• Sul do Brasil **,*
• Canadá Central**
• Leste do Canadá
• Leste da Ásia
• Europa Setentrional **
• Europa Ocidental **
• França Central
• Centro-Oeste da Alemanha
• Centro da Índia
• Sul da Índia
• Leste do Japão **
• Oeste do Japão
• Sudeste Asiático **
• Norte da Suíça
• Suécia Central **,*
• Sul do Reino Unido **
• Oeste do Reino Unido *
• Centro dos EUA **
• Leste dos EUA **
• Leste dos EUA 2 **
• Centro-Norte dos EUA
• Centro-Sul dos EUA
• Centro-Oeste dos EUA
• Oeste dos EUA 1
• Oeste dos EUA 2 **
• Oeste dos EUA 3 **

* O hardware otimizado para memória da série Premium não está disponível no momento.

** Inclui suporte para redundância de zona.

Série Fsv2

A série Fsv2 está disponível nas seguintes regiões:

• Austrália Central
• Austrália Central 2
• Leste da Austrália
• Sudeste da Austrália
• Brazil South
• Canadá Central
• Leste da Ásia
• Norte da Europa
• Europa Ocidental
• França Central
• Centro da Índia
• Coreia Central
• Sul da Coreia
• Norte da África do Sul
• Sudeste Asiático
• Sul do Reino Unido
• Oeste do Reino Unido
• Leste dos EUA
• Oeste dos EUA 2

Série DC

A série DC está disponível nas seguintes regiões:

• Canadá Central
• Europa Ocidental
• Norte da Europa
• Sudeste Asiático
• Sul do Reino Unido
• Oeste dos EUA
• Leste dos EUA

Caso você precise da série DC em uma região em que não há suporte, envie uma solicitação de suporte. Na página Noções básicas, forneça estas informações:

1. Em Tipo de problema, selecione Técnico.
2. Forneça a assinatura desejada para o hardware. Selecione Avançar.
3. Em Tipo de serviço, selecione Banco de Dados SQL.
4. Em Recurso, selecione Pergunta geral.
5. Em Resumo, forneça a disponibilidade de hardware e a região desejadas.
6. Em Tipo de problema, selecione Segurança, Privacidade e Conformidade.
7. Em Subtipo de problema, selecione Always Encrypted.

Hardware de geração anterior

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

Conteúdo relacionado

• Página de preços do Banco de Dados SQL do Microsoft Azure
• Limites de recursos para bancos de dados individuais usando o modelo de compra de vCore
• Limites de recursos para pools elásticos usando o modelo de compra baseado no vCore