Modelo de compra vCore - Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure

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

Descrição geral

Um núcleo virtual (vCore) representa uma CPU lógica e oferece a opção de 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 oferece flexibilidade, controle, transparência do consumo de recursos individuais e uma maneira direta de traduzir 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 com base em suas necessidades de carga de trabalho.

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

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

Compare os modelos de compra vCore e DTU

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

• Maiores limites de computação, memória, E/S e armazenamento.
• Escolha de configuração de hardware para melhor corresponder aos requisitos de computação e memória da carga de trabalho.
• Descontos de preços para o Benefício Híbrido do Azure (AHB).
• 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 vCore.
• Maior granularidade de dimensionamento com vários tamanhos de computação disponíveis.

Para obter ajuda na 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 total de computação continuamente provisionada para o aplicativo, independentemente da atividade de carga de trabalho. Escolha a alocação de recursos que melhor se adapta à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 da carga de trabalho e cobrados pela quantidade de computação usada, por segundo.

Para resumir:

• Enquanto a camada de computação provisionada fornece uma quantidade específica de recursos de computação que são continuamente provisionados 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 da 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 adicionais de alta disponibilidade são alocadas automaticamente na camada de serviço Business Critical 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 maior custo de armazenamento por GB na camada de serviço Business Critical reflete os limites de E/S mais altos e a menor latência do armazenamento SSD local.

No Hyperscale, 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 e, ao mesmo tempo, controlar 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 limites de recursos vCore, revise as configurações de hardware disponíveis e, em seguida, revise os limites de recursos para:

• Servidores lógicos
• bases de dados únicas
• Bancos de dados em pools elásticos

Armazenamento de dados e logs

Os fatores a seguir afetam a quantidade de armazenamento usada para dados e arquivos de log e se aplicam às camadas de uso geral e críticas para os negócios.

• Cada tamanho de computação suporta um tamanho máximo de dados configurável, com um padrão de 32 GB.
• Quando você configura o tamanho máximo de dados, um extra de 30% do armazenamento faturável é adicionado automaticamente para o arquivo de log.
• Na camada de serviço de uso geral, tempdb usa armazenamento SSD local e esse custo de armazenamento está incluído no preço do vCore.
• No nível de serviço Business Critical, compartilha o armazenamento SSD local com dados e arquivos de log, tempdb e tempdb o custo de armazenamento está incluído no preço do vCore.
• Nos níveis de uso geral e crítico para os negócios, 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 suportado, em incrementos de 1 GB.

As seguintes considerações de armazenamento se aplicam ao Hyperscale:

• O tamanho máximo de armazenamento de dados é definido como 100 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 será cobrado pelo armazenamento de logs.
• tempdb usa armazenamento SSD local e seu custo está incluído no preço do vCore. Para monitorar o tamanho atual de armazenamento de dados alocado e usado no Banco de Dados SQL, use as métricas allocated_data_storage e armazenamento do Azure Monitor, respectivamente.

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

Armazenamento de cópias de segurança

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

• PITR: Nas camadas de uso geral e crítica para os negócios, os backups de banco de dados individuais são copiados automaticamente para o armazenamento do Azure. O tamanho do armazenamento aumenta dinamicamente à medida que novos 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 máximo de dados configurado é fornecida sem custo extra.
• 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 no armazenamento de Blob do Azure automaticamente, mas você poderá controlar a frequência com que os backups serão copiados. Para atender a diferentes requisitos de conformidade, você pode selecionar diferentes períodos de retenção para backups semanais, mensais e/ou anuais. A configuração escolhida determina quanto armazenamento é usado para backups LTR. Para obter mais informações, consulte Retenção de backup de longo prazo.

Para armazenamento de backup em Hyperscale, consulte Backups automatizados para bancos de dados Hyperscale.

Escalões de serviço

As opções da camada de serviço no modelo de compra vCore incluem Propósito Geral, Crítica para os Negócios e Hiperescala. A camada de serviço geralmente determina o tipo e o desempenho de armazenamento, as opções de alta disponibilidade e recuperação de desastres e a disponibilidade de determinados recursos, como OLTP na memória.

1 Preços simplificados para o SQL Database Hyperscale em breve. Consulte o blog de preços do Hyperscale para obter detalhes.

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

Fins Gerais

O modelo de arquitetura para a camada de serviço de uso geral é baseado em uma separação de computação e armazenamento. Esse modelo de arquitetura depende da alta disponibilidade e confiabilidade do armazenamento de Blob do Azure que replica arquivos de banco de dados de forma 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 para a camada de serviço de uso geral, há duas camadas:

• Uma camada de computação sem estado que está executando o sqlservr.exe processo e contém apenas dados transitórios e armazenados em cache (por exemplo: cache de plano, pool de buffers, pool de armazenamento de coluna). Esse nó sem estado é operado pelo Azure Service Fabric que inicializa o processo, controla a integridade do nó e executa failover para outro local, se necessário.
• Uma camada de dados com estado com arquivos de banco de dados (.mdf/.ldf) armazenados no armazenamento de Blob do Azure. O armazenamento de Blob 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 todos os registros no arquivo de log ou página no arquivo de dados sejam preservados, 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 é detetado no processo, o sqlservr.exe Azure Service Fabric move o processo sem estado para outro nó de computação sem monitoração de 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 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á ativada. Pode haver alguns impactos no desempenho de cargas de trabalho pesadas que estão em voo devido ao tempo de transição e ao fato de que o novo nó começa com cache frio.

Quando escolher esta camada de serviço

A camada de serviço de Propósito 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 é a opção para você.

Crítico para a Empresa

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

No modelo Business Critical, a computação e o armazenamento são integrados em cada nó. A replicação de dados entre processos do mecanismo de banco de dados em cada nó de um cluster de quatro nós alcança alta disponibilidade, com cada nó usando SSD conectado 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.

Tanto o processo do mecanismo de banco de dados quanto os arquivos .mdf/.ldf subjacentes são colocados no mesmo nó com armazenamento SSD conectado localmente, proporcionando baixa latência à sua carga de trabalho. A alta disponibilidade é implementada usando tecnologia semelhante aos grupos de disponibilidade Always On do SQL Server. 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 de clientes 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 estejam disponíveis nas réplicas secundárias se a primária falhar por qualquer motivo. O failover é tratado pelo Service Fabric e pelo mecanismo de banco de dados – uma réplica secundária se torna a principal 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 Business Critical tem um recurso interno de Expansão de Leitura que fornece uma réplica somente leitura gratuita usada para executar consultas somente leitura (como relatórios) que não afetarão o desempenho da carga de trabalho em sua réplica principal.

Quando escolher esta camada de serviço

A camada de serviço Business Critical foi projetada para aplicativos que exigem respostas de baixa latência do armazenamento SSD subjacente (1-2 ms em média), recuperação mais rápida se a infraestrutura subjacente falhar ou precisam descarregar relatórios, análises e consultas somente leitura para a réplica secundária legível gratuita do banco de dados primário.

Os principais motivos pelos quais você deve escolher a camada de serviço Crítica para os Negócios em vez da camada de Uso Geral são:

• Requisitos de baixa latência de E/S – cargas de trabalho que precisam de uma resposta consistentemente rápida da camada de armazenamento (1 a 2 milissegundos em média) devem usar a camada crítica para os negócios.
• Carga de trabalho com relatórios e consultas analíticas em que uma única réplica secundária somente leitura gratuita é suficiente.
• Maior resiliência e recuperação mais rápida de falhas. Em caso de falha do sistema, o banco de dados na instância primária é desativado e uma das réplicas secundárias se torna imediatamente o novo banco de dados primário de leitura-gravação, pronto para processar consultas.
• Proteção avançada contra corrupção de dados. Como a camada Business Critical 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 puder ler uma página devido a um problema de integridade de dados, uma nova cópia da página será recuperada de outra réplica, substituindo a página ilegível sem perda de dados ou tempo de inatividade do cliente. Essa funcionalidade estará disponível na camada de uso geral se o banco de dados tiver réplica geosecundária.
• Maior disponibilidade - A camada Crítica de Negócios em uma configuração de zona de multidisponibilidade fornece resiliência a falhas zonais e um SLA de maior disponibilidade .
• Recuperação geográfica rápida - Quando a replicação geográfica ativa é configurada, a camada crítica de negócios tem um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) garantido de 5 segundos e um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) de 30 segundos para 100% das horas implantadas.

Hyperscale

A camada de serviço Hyperscale é adequada para todos os tipos de carga de trabalho. Sua arquitetura nativa da nuvem fornece computação e armazenamento escaláveis de forma independente para suportar a maior variedade de aplicativos tradicionais e modernos. Os recursos de computação e armazenamento em Hyperscale excedem substancialmente os recursos disponíveis nas camadas de uso geral e crítica para os negócios.

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

Quando escolher esta camada de serviço

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

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

• Obtenha alta resiliência e rápida recuperação de falhas enquanto controla os custos, 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 (1-2 milissegundos em média) para a parte acessada com frequência do seu 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 escalonamento rápido, sem esperar que os dados sejam copiados para o armazenamento local em novos nós.
• Aproveite o backup contínuo de banco de dados de impacto zero e a restauração rápida.
• Ofereça suporte aos requisitos de continuidade de negócios usando grupos de failover e replicação geográfica.

Configuração do hardware

As configurações de hardware comuns no modelo vCore incluem séries padrão (Gen5), séries Fsv2 e DC. O Hyperscale também oferece uma opção para hardware otimizado para memória de séries premium e 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.

Certas 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 tenda 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 hardware que usa um tipo de CPU diferente. Por exemplo, um banco de dados ou pool pode ser movido se você aumentar ou diminuir a escala para um objetivo de serviço diferente, ou se a infraestrutura atual em um datacenter estiver se aproximando de seus limites de capacidade, ou se o hardware usado atualmente estiver sendo desativado devido ao seu fim de vida útil.

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 o objetivo de fornecer desempenho previsível da carga de trabalho, mesmo se o tipo de CPU mudar, mantendo as alterações de desempenho dentro de uma banda estreita. No entanto, em todo o amplo espectro de cargas de trabalho de clientes no Banco de dados SQL, e à medida que novos tipos de CPUs se tornam disponíveis, ocasionalmente é possível ver alterações mais percetíveis no desempenho, se um banco de dados ou pool for movido 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 máximo de dados, taxa máxima de log e máximo de trabalhadores simultâneos) permanecem os mesmos enquanto o banco de dados permanecer 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:

* Na visualizaçã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 (Milão) aparece 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).

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

Para recursos e especificações de computação de banco de dados Hyperscale, consulte Recursos de computação Hyperscale.

Série padrão (Gen5)

• O hardware da 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 padrão (Gen5) está disponível em todas as regiões públicas do mundo.

Série premium de hiperescala

• As opções de hardware da série Premium usam a mais recente tecnologia de CPU e memória da Intel e AMD. A série Premium proporciona 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 de CPU mais rápido 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.
• As séries Standard, Premium e Premium estão disponíveis para pools elásticos Hyperscale (visualização).

Para obter mais informações, consulte o anúncio do blog da série premium Hyperscale.

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

Série Fsv2

• A série Fsv2 é uma configuração de hardware otimizada para computação que oferece baixa latência da CPU e alta velocidade de clock para as cargas de trabalho mais exigentes da CPU. Semelhante às configurações de hardware da série premium Hyperscale, a série Fsv2 é alimentada pela mais recente tecnologia de CPU e memória da Intel e AMD, permitindo que os clientes aproveitem o hardware mais recente enquanto usam bancos de dados e pools elásticos na camada de serviço de uso geral.
• Dependendo da carga de trabalho, a série Fsv2 pode oferecer mais desempenho de CPU por vCore do que outros tipos de hardware. Por exemplo, o tamanho de computação 72 vCore Fsv2 pode fornecer mais desempenho de CPU do que 80 vCores na série Standard (Gen5), a um custo mais baixo.
• O Fsv2 fornece menos memória e tempdb por vCore do que outro hardware, portanto, cargas de trabalho sensíveis a esses limites podem ter um desempenho melhor na série padrão (Gen5).

Série Fsv2 suportada apenas na camada de uso geral. Para regiões onde a série Fsv2 está disponível, consulte Disponibilidade da série Fsv2.

Série DC

• O hardware da série DC usa processadores Intel com tecnologia Software Guard Extensions (Intel SGX).
• A série DC é necessária para cargas de trabalho Always Encrypted com enclaves seguros que exigem proteção de segurança mais forte 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 recursos confidenciais de processamento de consultas, fornecidos pelo Always Encrypted com enclaves seguros.
• O hardware da série DC fornece recursos de computação e memória equilibrados.

A série DC só é suportada para computação provisionada (sem servidor não é suportada) e não suporta redundância de zona. Para regiões onde a série DC está disponível, consulte Disponibilidade da série DC.

Tipos de oferta do Azure suportados pela 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 Pay-As-You-Go ou Enterprise Agreement (EA). Para obter uma lista completa dos tipos de oferta do Azure suportados pela série DC, consulte 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 existente ou pool elástico.

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 pool ou Banco de Dados SQL existente

Para um banco de dados, na página Visão geral, selecione o link Nível 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 hardware de geração anterior, consulte Disponibilidade de hardware de geração anterior.

Série padrão (Gen5)

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

Série premium de hiperescala

O hardware otimizado para memória da série premium e da série premium da camada de serviço Hyperscale está disponível para bancos de dados únicos e pools elásticos nas seguintes regiões:

• Leste da Austrália
• Sul do Brasil
• Canadá Central **
• Índia Central
• E.U.A. Central
• Ásia Leste
• Leste dos EUA **
• E.U.A. Leste 2
• França Central
• Alemanha Centro-Oeste
• Índia do Sul
• Leste do Japão
• Oeste do Japão *
• E.U.A. Centro-Norte
• Norte da Europa **
• Sudeste Asiático
• E.U.A. Centro-Sul
• Sul do Reino Unido
• E.U.A. Centro-Oeste
• Europa Ocidental **
• Oeste dos EUA 1
• E.U.A. Oeste 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
• Austrália Sudeste
• Sul do Brasil
• Canadá Central
• Ásia Leste
• E.U.A. Leste
• França Central
• Índia Central
• Coreia do Sul Central
• Sul da Coreia do Sul
• Europa do Norte
• Norte da África do Sul
• Sudeste Asiático
• Sul do Reino Unido
• Oeste do Reino Unido
• Europa Ocidental
• E.U.A. Oeste 2

Série DC

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

• Canadá Central
• E.U.A. Leste
• Europa do Norte
• Sul do Reino Unido
• Europa Ocidental
• E.U.A. Oeste
• Sudeste Asiático

Se você precisar da série DC em uma região atualmente sem suporte, envie uma solicitação de suporte. Na página Noções básicas, forneça o seguinte:

1. Em Tipo de problema, selecione Técnico.
2. Forneça a assinatura desejada para o hardware. Selecione Seguinte.
3. Em Tipo de serviço, selecione Banco de dados SQL.
4. Em Recurso, selecione Pergunta geral.
5. Para Resumo, forneça a disponibilidade de hardware e a região desejadas.
6. Em Tipo de problema, selecione Segurança, Privado e Conformidade.
7. Para o subtipo Problema, selecione Sempre criptografado.

Hardware da 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 suportada para uma ampla gama de vCore e escalabilidade de armazenamento, rede acelerada, melhor desempenho de E/S e latência mínima. Analise as opções de hardware para bancos de dados únicos e as opções de hardware para pools elásticos. Para obter mais informações, consulte O suporte para hardware Gen 4 terminou no Banco de Dados SQL do Azure.

Conteúdos relacionados

• Página de preços do Banco de Dados SQL do Azure
• Limites de recursos das bases de dados individuais com o modelo de compra baseado em vCore
• Limites de recursos dos conjuntos elásticos com o modelo de compra baseado em vCore

Próximo passo