A migração para a nuvem promete eficiência, mas para cargas de trabalho do Microsoft SQL Server, uma infraestrutura “mais barata” geralmente leva a um desperdício exorbitante. Ao implantar em instâncias expansíveis, como Azure B-Series, AWS T-Series ou GCP E2, as organizações frequentemente caem em uma armadilha de licenciamento específica, onde modelos herdados baseados em núcleo colidem com a medição de serviços públicos modernos.
Este relatório disseca oRegra do “mínimo de 4 núcleos”, expõe o oculto“Imposto de E/S”da limitação do armazenamento expansível e explica por que as VMs de baixo custo podem estar custando o dobro em taxas de software e, ao mesmo tempo, oferecer desempenho limitado. Analisamos os riscos específicos de“Roubar Tempo”e esgotamento de crédito para ajudá-lo a evitar as armadilhas econômicas da execução de bancos de dados corporativos em hardware fracionário.
Licenciamento do SQL Server: uma análise entre nuvens | GigXP
ShowXP
Inteligência tecnológica / Banco de dados corporativo / Atualizado em outubro de 2025
A economia do desperdício: SQL Server em CPUs de nuvem expansíveis
Por equipe de pesquisa
A migração para a nuvem mudou a relação entre o provisionamento de infraestrutura e o licenciamento de software. A computação em nuvem promete elasticidade e eficiência. Você paga pelo que usa. As estruturas de licenciamento de software legado, especificamente as do Microsoft SQL Server, permanecem enraizadas em paradigmas de hardware físico. Esse atrito é mais óbvio ao implantar o SQL Server em instâncias de computação “expansíveis”: a série B no Microsoft Azure, a série T na Amazon Web Services (AWS) e os tipos de máquina de núcleo compartilhado E2 ou N1 no Google Cloud Platform (GCP).
As instâncias expansíveis são projetadas para democratizar o acesso à computação para cargas de trabalho intermitentes. Eles apresentam uma proposta de valor enganosa para aplicativos de banco de dados. O custo de infraestrutura de uma máquina virtual (VM) expansível de 2 vCPU é insignificante. As obrigações de licenciamento de software criam um elevado “custo mínimo” que distorce o Custo Total de Propriedade (TCO). A exigência de que cada Ambiente de Sistema Operacional Virtual (OSE) licencie um mínimo de quatro núcleos força as organizações a pagar por capacidade inexistente ao utilizar instâncias pequenas.
O problema central
Para pequenas instâncias expansíveis, o custo da licença de software não aumenta linearmente com a infraestrutura. Uma VM com 2 vCPUs incorre no mesmo custo de licenciamento que uma VM com 4 vCPUs. Isso dobra o custo de software por núcleo para máquinas menores.
1. A armadilha do licenciamento
A economia moderna da nuvem depende da medição granular. Uma instância expansível vende ciclos de CPU como um utilitário. O usuário compra uma fração básica de um núcleo físico e acumula créditos durante períodos ociosos. Este modelo baseia-se na probabilidade estatística de que nem todos os inquilinos de um host físico interrompam simultaneamente.
O Microsoft SQL Server usa um modelo de licenciamento baseado em núcleo projetado para capturar valor com base no poder computacional potencial. Desde 2012, a Microsoft vinculou o preço ao número de núcleos de processamento. A regra do “mínimo de quatro núcleos” determina que mesmo que uma máquina virtual atue em um único núcleo virtual, o cliente deve adquirir licenças de quatro núcleos. Isso se aplica ao SQL Server 2022 e às atualizações de 2025.
Figura 1: A “lacuna de valor” entre o custo da infraestrutura e o custo do licenciamento obrigatório (estimativa em dólares por hora).
A discrepância cria uma “armadilha de valor”. A baixa taxa horária da infraestrutura atrai os usuários para implantações onde os custos de licenciamento de software excedem significativamente o custo da infraestrutura.
2. Arquitetura Técnica: O Risco de “Roubar Tempo”
O desempenho em instâncias expansíveis depende da interação entre o agendador do mecanismo de banco de dados e a governança de recursos do hipervisor.
Em instâncias padrão, o hipervisor fornece um mapeamento rígido para vCPUs. Em instâncias expansíveis, os núcleos físicos estão com excesso de assinaturas. O hipervisor gerencia isso com um agendador de crédito. Quando uma demanda de VM excede seu direito de linha de base, o agendador verifica o saldo de créditos.
- Saldo Positivo:O agendador permite que a VM consuma ciclos físicos até o limite de intermitência.
- Saldo zero:O agendador limita a VM. Ele limita o tempo de execução à porcentagem da linha de base.
Para o SQL Server, essa limitação é opaca. O sistema operacional pode perceber a CPU como disponível. As instruções não são executadas pelo hardware físico. Isso cria “Steal Time” ou “Hypervisor Wait”. O sistema operacional convidado deseja ser executado, mas é pausado involuntariamente.
A espiral da morte
O SQL Server usa multitarefa cooperativa por meio do sistema operacional SQL Server (SQLOS). Threads cedem voluntariamente a CPU para permitir que outros trabalhadores sejam executados. Em uma instância limitada, o hipervisor desprograma a vCPU do núcleo físico. O thread SQL está travado. Outros threads que aguardam recursos bloqueados pelo thread congelado começam a girar. Isso queima a capacidade restante da CPU em um loop inútil.
Figura 2: Simulação em tempo real do algoritmo Token Bucket. Veja como o consumo rápido esgota o banco.
3. Os custos ocultos do “imposto de E/S”
Embora os créditos da CPU atraiam mais atenção, o subsistema de armazenamento de instâncias expansíveis apresenta uma ameaça mais imediata à estabilidade do banco de dados. O SQL Server usa um protocolo Write-Ahead Logging (WAL). Cada modificação deve ser gravada no log de transações no disco antes da transação ser confirmada.
Instâncias expansíveis (como Azure série B v1 ou AWS T3) limitam a taxa de transferência de armazenamento (MB/s) e IOPS com base no tamanho da instância. Uma instância de 2 vCPU geralmente tem uma taxa de transferência de linha de base tão baixa quanto 8 MB/s. Se uma liberação do log de transações atingir esse limite, o mecanismo SQL fará uma pausa, acumulandoPAGEIOLATCHespera.
Risco Operacional
Durante eventos de “intermitência”, os usuários geralmente atribuem lentidão à CPU, mas 60% dos tickets de desempenho de instâncias expansíveis são, na verdade, limitação de armazenamento. A CPU fica ociosa aguardando o disco, mas a lentidão “percebida” leva os administradores a atualizar a instância, aumentando ainda mais o desperdício de licenciamento.
4. O paradoxo da janela de manutenção
As tarefas de manutenção de banco de dados – reconstruções de índices, verificações de consistência (DBCC CHECKDB) e atualizações estatísticas – consomem muitos recursos. Em hardware dedicado, eles são executados fora do horário comercial sem penalidades. Em instâncias expansíveis, essas tarefas consomem créditos de CPU acumulados.
Uma reconstrução noturna do índice às 2h pode esgotar totalmente o banco de crédito. Quando o dia útil começa às 8h, a instância tem 0 créditos e opera com seu desempenho de linha de base (geralmente 10% a 20% de um núcleo). O “pico matinal” de logins de usuários atinge um servidor limitado, causando tempos limite.
Simulação de esgotamento de crédito
| Atividade | Duração | Carga da CPU | Impacto de crédito |
|---|---|---|---|
| Inativo (diurno) | 1 hora | 5% | +6 Créditos(Ganho Líquido) |
| Reconstrução de índice | 30 minutos | 100% | -30 créditos(Drenagem Rápida) |
| Login matinal | 15 minutos | 80% | Estrangulado(Se o banco estiver vazio) |
5. Confronto de plataforma e modelos de custo
Cada grande provedor de nuvem lida com essa arquitetura de maneira diferente. Use o filtro abaixo para ver detalhes da sua plataforma.
Todas as plataformas
Azul
AWS
GCP
| Plataforma | Família de instâncias | Mecanismo Chave | Risco de licenciamento |
|---|---|---|---|
| Azul | Série B (v1 e v2) | Crédito Bancário. Aceleração forte quando os créditos desaparecem na v1. | O preço PAYG inclui marcação mínima de 4 núcleos. O IO do disco geralmente apresenta gargalos antes da CPU. |
| AWS | Série T (T3/T3a) | Modo “Ilimitado” habilitado por padrão. | Risco financeiro. Você paga encargos excedentes se estourar por muito tempo. Pode exceder o custo da instância dedicada. |
| GCP | Núcleo Compartilhado E2 | Divisão de tempo rigorosa (por exemplo, 0,5 vCPU sustentada). | Não há descontos por uso prolongado (SUDs) no E2. O custo de licenciamento é alto em relação ao hardware fracionário. |
Análise da Série B do Azure
A série B sofre com baixos limites de rendimento do disco. As gravações do log de transações do SQL Server são sensíveis a isso. Se o log não puder ser liberado para o disco, o banco de dados parará independentemente dos créditos da CPU. O Benefício Híbrido do Azure permite que você traga licenças, mas você ainda queima 4 núcleos de direito para uma VM de 2 núcleos.
Análise da série T da AWS
As instâncias T3 são padronizadas para o modo “Ilimitado”. Quando os créditos se esgotam, a instância explode usando créditos excedentes cobrados a aproximadamente 0,05 USD por vCPU-hora. Se um SQL Server entrar em um loop spinlock, ele será executado com 100% da CPU indefinidamente, quadruplicando o custo por hora.
Análise GCP E2
O GCP usa tipos de máquinas com núcleo compartilhado, como e2-micro e e2-small. Eles oferecem garantias de desempenho sustentado. As instâncias E2 não se qualificam para descontos por uso prolongado, o que reduz a diferença de preço entre elas e as instâncias padrão.
6. Recomendações Estratégicas
A opção “mais barata” na lista de preços é muitas vezes a menos eficiente. O imposto mínimo de 4 núcleos torna marginal a economia de custos de instâncias expansíveis de 2 vCPU em comparação com os riscos de desempenho.
Usar a edição Web:Para cargas de trabalho públicas, o SQL Server Web Edition tem um custo mínimo muito mais baixo. Esta é a única maneira economicamente racional de usar instâncias expansíveis para produção.
Mude para PaaS:O Banco de Dados SQL do Azure Serverless ou AWS Aurora Serverless abstraem o licenciamento principal. Você paga por vCore-segundos. Se o banco de dados for pausado, o faturamento será interrompido.
Somente Desenvolvimento:Use a Developer Edition gratuita para ambientes que não sejam de produção em hardware expansível para eliminar custos de licenciamento.
Perguntas frequentes
O mínimo de 4 núcleos se aplica ao SQL Server Express?
Não. O SQL Server Express é gratuito para uso em qualquer número de núcleos, embora seja limitado por restrições de mecanismo (1 GB de RAM, tamanho de banco de dados de 10 GB).
Leia mais:Atualização do SQL Server 2022: corrigindo a degradação do desempenho do SQL 2016
Posso desativar o hyperthreading para economizar licenças?
Geralmente não. Embora você possa desabilitar o hyperthreading na AWS (Optimize CPU), o requisito mínimo de compra da Microsoft continua sendo 4 núcleos por OSE. Reduzir uma instância de 2 vCPU para 1 vCPU não diminui a conta.
O T3 Ilimitado é mais barato que o M5?
Somente se a utilização média da CPU permanecer abaixo da linha de base (20 a 40 por cento). Se você executar consistentemente alto, as cobranças de crédito excedente tornarão o T3 Unlimited mais caro do que uma instância M5 fixa.
O SQL Server no Linux (Containers) evita o núcleo mínimo?
Não. O licenciamento para contêineres (Kubernetes/Docker) exige que você licencie as vCPUs disponíveis para o contêiner. No entanto, a regra mínima de 4 núcleos ainda se aplica a cada contêiner (ou OSE). Você não pode ativar 10 contêineres com 1 núcleo cada e pagar por 10 núcleos; você deve pagar por 40 núcleos.
© 2025 Pesquisa GigXP. Todos os direitos reservados.