Visão geral do modelo de compra baseado em DTU

Aplica-se a:Banco de Dados SQL do Azure

Neste artigo, saiba mais sobre o modelo de compra baseado em DTU para o Banco de Dados SQL do Azure.

Para saber mais, examine o modelo de compra baseado em vCore e compare modelos de compra.

DTUs (Unidades de Transação de Banco de Dados)

Uma DTU (unidade de transação do banco de dados) representa uma medida combinada de CPU, memória, leituras e gravações. As camadas de serviço no modelo de compra baseado em DTU são diferenciadas por uma variedade de tamanhos de computação com uma quantidade fixa de armazenamento incluído, um período de retenção fixo para backups e um preço fixo. Todas as camadas de serviço no modelo de compra baseado em DTU oferecem flexibilidade para mudar de tamanho de computação com um tempo mínimo de inatividade. No entanto, há uma opção ao longo do período em que a conectividade é perdida para o banco de dados por um breve período, o que pode ser atenuado usando a lógica de repetição. Os bancos de dados individuais e os pools elásticos são cobrados por hora com base na camada de serviço e no tamanho da computação.

Para um banco de dados individual em um tamanho de computação específico dentro de uma camada de serviço, o Banco de Dados SQL do Azure garante um determinado nível de recursos para esse banco de dados (independentemente de qualquer outro banco de dados). Essa garantia fornece um nível previsível de desempenho. A quantidade de recursos alocada para um banco de dados é calculada como um número de DTUs e é uma medida combinada de recursos de computação, armazenamento e E/S.

A proporção entre esses recursos originalmente foi determinada por uma carga de trabalho de parâmetro de comparação de OLTP (processamento de transações online) projetada para ser o cenário típico de cargas de trabalho OLTP reais. Quando sua carga de trabalho excede o valor de qualquer um desses recursos, a taxa de transferência é restringida, resultando em desempenho mais lento e inatividade.

Nos bancos de dados individuais, os recursos usados pela carga de trabalho não afetam os recursos disponíveis para outros bancos de dados na nuvem do Azure. Da mesma forma, os recursos usados por outras cargas de trabalho não impactam os recursos disponíveis para o seu banco de dados.

As DTUs são úteis para entender a quantidade relativa de recursos alocados para bancos de dados em diferentes tamanhos da computação e camadas de serviço. Por exemplo:

• Dobrar as DTUs aumentando o tamanho da computação de um banco de dados equivale a dobrar o conjunto de recursos disponíveis para esse banco de dados.
• Um banco de dados P11 da camada de serviço Premium com 1750 DTUs fornece 350 vezes mais potência de computação DTU do que um banco de dados de camada de serviço Basic com 5 DTUs.

Para ver informações mais detalhadas sobre o consumo de recursos (DTU) da sua carga de trabalho, use a análise de desempenho de consultas para:

• Identificar as principais consultas por contagem de CPU/duração/rxecução, que podem ser ajustadas para melhorar o desempenho. Por exemplo, uma consulta com uso intensivo de E/S pode se beneficiar de técnicas de otimização na memória para fazer melhor uso da memória disponível em um determinado tamanho da computação e camada de serviço.
• Analise detalhadamente os dados de uma consulta para exibir o texto e seu histórico de uso de recursos.
• Veja as recomendações de ajuste de desempenho que mostram as ações realizadas pelo Assistente do Banco de Dados SQL do Azure.

eDTUs (unidades de transação do banco de dados elástico)

Em vez de fornecer um conjunto dedicado de recursos (DTUs) que nem sempre são necessários, você pode colocar esses bancos de dados em um pool elástico. Os bancos de dados em um pool elástico usam uma só instância do mecanismo de banco de dados e compartilham o mesmo pool de recursos.

Os recursos compartilhados em um pool elástico são medidos por eDTUs (unidades de transação do banco de dados elástico). Pools elásticos fornecem uma solução simples e econômica para gerenciar as metas de desempenho para vários bancos de dados que têm padrões de uso muito variáveis e imprevisíveis. Um pool elástico garante que todos os recursos não possam ser consumidos por um banco de dados no pool, enquanto garantem que cada banco de dados no pool sempre tem uma quantidade mínima de recursos disponíveis.

Um pool é fornecido com um número definido de eDTUs por um preço definido. No pool elástico, os bancos de dados individuais podem ser dimensionados automaticamente dentro dos limites configurados. Um banco de dados sob carga mais pesada consume mais eDTUs para atender à demanda. Bancos de dados sob cargas mais leves consumem menos eDTUs. Bancos de dados sem carga não consumem eDTUs. Como os recursos são provisionados para todo o pool, em vez de por banco de dados, os pools elásticos simplificam suas tarefas de gerenciamento e fornecem um orçamento previsível para o pool.

Você pode adicionar mais eDTUs a um pool existente com um tempo mínimo de inatividade do banco de dados. Da mesma forma, se você não precisar mais de eDTUs extras, remova-as de um pool existente a qualquer momento. Você também pode adicionar ou remover bancos de dados de um pool a qualquer momento. Para reservar eDTUs para outros bancos de dados, limite o número de bancos de dados de eDTUs que podem ser usados sob uma carga pesada. Se um banco de dados tiver uma utilização consistentemente alta de recursos que afete outros bancos de dados no pool, remova-o do pool e configure-o como um banco de dados individual com uma quantidade previsível de recursos necessários.

Cargas de trabalho que se beneficiam de um pool elástico de recursos

Os pools são adequados para bancos de dados com uma média de baixa utilização de recursos e picos de utilização relativamente pouco frequentes. Para obter mais informações, confira Quando você deve considerar um pool elástico do Banco de Dados SQL?.

Determinar o número de DTUs necessárias para uma carga de trabalho

Se você quer migrar uma carga de trabalho de máquina virtual local ou do SQL Server existente para o Banco de Dados SQL, confira Recomendações de SKU para estimar o número de DTUs necessárias. Para uma carga de trabalho do Banco de Dados SQL existente, use a análise de desempenho de consultas para compreender o consumo de recursos do banco de dados (DTUs) e saber mais sobre como otimizar sua carga de trabalho. A DMV (exibição de gerenciamento dinâmico) sys.dm_db_resource_stats permite exibir o consumo de recursos da última hora. A exibição de catálogo sys.resource_stats mostra o consumo de recursos para os últimos 14 dias, mas com uma fidelidade menor de médias de cinco minutos.

Determinar a utilização da DTU

Para determinar a porcentagem média de utilização da DTU/eDTU em relação ao limite da DTU/eDTU de um banco de dados ou pool elástico, use a seguinte fórmula:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

Os valores de entrada para essa fórmula podem ser obtidos nas DMVs sys.dm_db_resource_stats, sys.resource_stats e sys.elastic_pool_resource_stats. Em outras palavras, para determinar a porcentagem de utilização da DTU/eDTU em direção ao limite da DTU/eDTU de um banco de dados ou pool elástico, escolha o maior valor percentual do seguinte: avg_cpu_percent, avg_data_io_percent e avg_log_write_percent em um determinado momento.

Observação

O limite da DTU de um banco de dados é determinado pela CPU, leituras, gravações e memória disponível para o banco de dados. No entanto, como o mecanismo do Banco de Dados SQL normalmente usa toda a memória disponível para o cache de dados para melhorar o desempenho, o valor avg_memory_usage_percent geralmente será próximo de 100%, independentemente da carga atual do banco de dados. Portanto, embora a memória influencie indiretamente o limite da DTU, ela não é usada na fórmula de utilização da DTU.

Configuração de hardware

No modelo de compra baseado em DTU, os clientes não podem escolher a configuração de hardware usada para seus bancos de dados. Embora um determinado banco de dados geralmente permaneça em uma configuração de hardware específica por um longo tempo (normalmente por vários meses), há certos eventos que podem fazer com que um banco de dados seja movido para outra geração de hardware.

Por exemplo, um banco de dados poderá ser movido para uma configuração de hardware diferente se ele for expandido ou reduzido para um objetivo de serviço diferente, se a infraestrutura atual em um datacenter estiver se aproximando de seus limites de capacidade ou se o hardware atualmente usado estiver sendo encerrado devido ao fim da vida útil.

Se um banco de dados for movido para um hardware diferente, o desempenho da carga de trabalho poderá ser alterado. O modelo da DTU garante que a taxa de transferência e o tempo de resposta da carga de trabalho de referência da DTU permanecerão substancialmente idênticos à medida que o banco de dados for movido para um tipo de hardware diferente, desde que seu objetivo de serviço (o número de DTUs) permaneça o mesmo.

No entanto, em todo o espectro de cargas de trabalho do cliente em execução no Banco de Dados SQL do Azure, o impacto do uso de hardware diferente para o mesmo objetivo de serviço pode ser maior. Cargas de trabalho diferentes se beneficiarão de diferentes recursos e configuração de hardware. Portanto, para cargas de trabalho que não sejam o parâmetro de comparação da DTU, será possível ver diferenças de desempenho se o banco de dados passar de uma geração de hardware para outra.

Os clientes podem usar o modelo vCore para escolher sua configuração de hardware preferencial durante a criação e o dimensionamento do banco de dados. No modelo vCore, os limites de recursos detalhados de cada objetivo de serviço em cada geração de hardware são documentados para bancos de dados individuais e pools elásticos. Para obter mais informações sobre gerações de hardware no modelo vCore, consulte Gerações de hardware para o Banco de Dados SQL ou Gerações de hardware para Instância Gerenciada de SQL.

Comparar camadas de serviço

Escolher uma camada de serviço depende principalmente da continuidade dos negócios, armazenamento e requisitos de desempenho.

	Basic	Standard	Premium
Carga de trabalho de destino	Desenvolvimento e produção	Desenvolvimento e produção	Desenvolvimento e produção
SLA de tempo de atividade	99,99%	99,99%	99,99%
Backup	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 7 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 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
CPU	Baixo	Baixo, Médio, Alto	Médio, Alto
IOPS (aproximado)*	1-4 IOPS por DTU	1-4 IOPS por DTU	>25 IOPS por DTU
Latência de E/S (aproximada)	5 ms (leitura), 10 ms (gravação)	5 ms (leitura), 10 ms (gravação)	2 ms (leitura/gravação)
Indexação ColumnStore	N/D	Standard S3 e superior	Com suporte
OLTP in-memory	N/D	N/D	Com suporte

* Todos os IOPS de leitura e gravação em arquivos de dados, incluindo E/S em segundo plano (ponto de verificação e gravador lento).

Importante

Os objetivos de serviço Básico, S0, S1 e S2 fornecem menos de um vCore (CPU). Para cargas de trabalho com uso intensivo de CPU, recomenda-se um objetivo de serviço S3 ou superior.

Nos objetivos de serviço Básico, S0 e S1, os arquivos de banco de dados são armazenados no Armazenamento Standard do Azure, que usa mídia de armazenamento baseada em HDD (unidade de disco rígido). Esses objetivos de serviço são mais adequados para desenvolvimento, teste e outras cargas de trabalho acessadas com pouca frequência que são menos sensíveis à variabilidade de desempenho.

Dica

Para ver os limites reais de governança de recursos para um banco de dados ou pool elástico, consulte a exibição sys.dm_user_db_resource_governance. Para um banco de dados individual, uma linha é retornada. Para um banco de dados em um pool elástico, uma linha é retornada para cada banco de dados no pool.

Observação

Você pode obter um banco de dados gratuito no Banco de Dados SQL do Azure na camada de serviço Básico com uma conta gratuita do Azure. Para obter informações, consulte Crie um banco de dados de nuvem gerenciado com sua conta gratuita do Azure.

Limites de recursos

Os limites de recursos diferem para bancos de dados individuais e em pool.

Limites de armazenamento de banco de dados individual

No Banco de Dados SQL do Azure, os tamanhos da computação são expressos em termos de DTUs (unidades de transação de banco de dados) para bancos de dados individuais e de eDTUs (unidades de transação do banco de dados elástico) para pools elásticos. Para saber mais, examine Limites de recursos para bancos de dados individuais.

	Basic	Standard	Premium
Tamanho máximo de armazenamento	2 GB	1 TB	4 TB
Máximo de DTUs	5	3000	4000

Importante

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.

Limites do pool elástico

Para saber mais, examine Limites de recursos para bancos de dados em pool.

	Basic	Standard	Premium
Tamanho máximo de armazenamento por banco de dados	2 GB	1 TB	1 TB
Tamanho máximo de armazenamento por pool	156 GB	4 TB	4 TB
Máximo de eDTUs por banco de dados	5	3000	4000
Máximo de eDTUs por pool	1600	3000	4000
Número máximo de bancos de dados por pool	500	500	100

Importante

Atualmente, há mais de 1 TB de armazenamento na camada Premium disponível em todas as regiões, exceto Leste da China, Norte da China, Alemanha Central e Nordeste da Alemanha. Nessas regiões, o armazenamento máximo na camada Premium é limitado a 1 TB. Para obter mais informações, confira Limitações atuais de P11-P15.

Importante

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, confira Gerenciar espaço para arquivo no Banco de Dados SQL do Azure.

Parâmetro de comparação de DTU

As características físicas (CPU, memória, E/S) associadas a cada medida de DTU são calibradas por meio de um parâmetro de comparação que simula a carga de trabalho do banco de dados real.

Saiba mais sobre o esquema, os tipos de transação usados, o mix de cargas de trabalho, os usuários e o ritmo, as regras de dimensionamento e as métricas associadas ao benchmark de DTU.

Comparar modelos de compra baseados em DTU e vCore

Embora o modelo de compra baseado em DTU seja baseado em uma medida agrupada de recursos de computação, armazenamento e E/S, por comparação, o modelo de compra do vCore para Banco de Dados SQL do Azure permite escolher e dimensionar independentemente os recursos de computação e armazenamento.

O modelo de compra baseado em vCore também permite que você use Benefício Híbrido do Azure para SQL Server para economizar custos e oferece opções sem servidor e hiperescala para Banco de Dados SQL do Azure que não estão disponíveis no modelo de compra baseado em DTU.

Saiba mais em Comparar os modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.

Próximas etapas

Saiba mais sobre os modelos de compra e os conceitos relacionados nos seguintes artigos:

• Para obter detalhes sobre os tamanhos da computação específicos e as opções de tamanho de armazenamento disponíveis para bancos de dados individuais, confira Limites de recursos baseados em DTU do Banco de Dados SQL para bancos de dados individuais.
• Para obter detalhes sobre os tamanhos da computação específicos e opções de tamanho de armazenamento disponíveis para pools elásticos, confira Limites de recursos baseados em DTU do Banco de Dados SQL.
• Para obter informações sobre o parâmetro de comparação associado ao modelo de compra baseado em DTU, consulte o benchmark de DTU.
• Comparar os modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.