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, analise o modelo de compra baseado em vCore e compare os modelos de compra.
Unidades de transação de banco de dados (DTUs)
A unidade de transação de base de dados (DTU) representa uma medida combinada de CPU, memória, leituras e escritas. Os níveis de serviço no modelo de compra baseado em DTU são diferenciados por uma variedade de tamanhos de computação com uma quantidade fixa de armazenamento incluído, período de retenção fixo para backups e preço fixo. Todas as camadas de serviço no modelo de compra baseado em DTU oferecem flexibilidade de alterar tamanhos de computação com tempo de inatividade mínimo , no entanto, há uma mudança ao longo do período em que a conectividade é perdida para o banco de dados por um curto período de tempo, o que pode ser atenuado usando a lógica de repetição. Bancos de dados únicos e pools elásticos são cobrados por hora com base na camada de serviço e no tamanho da computação.
Para um único banco de dados 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 (independente de qualquer outro banco de dados). Esta garantia proporciona um nível previsível de desempenho. A quantidade de recursos alocados para um banco de dados é calculada como um número de DTUs e é uma medida agrupada de recursos de computação, armazenamento e E/S.
A proporção entre esses recursos é originalmente determinada por uma carga de trabalho de referência OLTP (processamento de transações online) projetada para ser típica de cargas de trabalho OLTP do mundo real. Quando sua carga de trabalho excede a quantidade de qualquer um desses recursos, sua taxa de transferência é limitada, resultando em desempenho e tempos limite mais lentos.
Para bancos de dados únicos, os recursos usados pela sua 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 afetam os recursos disponíveis para seu banco de dados.
As DTUs são mais úteis para compreender os recursos relativos alocados para bancos de dados em diferentes tamanhos de computação e camadas de serviço. Por exemplo:
- Duplicar as DTUs aumentando o tamanho de 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 de camada de serviço Premium com 1750 DTUs fornece 350 vezes mais poder de computação de DTU do que um banco de dados de camada de serviço básico com 5 DTUs.
Para obter informações mais detalhadas sobre o consumo de recursos (DTU) de sua carga de trabalho, use insights de desempenho de consulta para:
- Identifique as principais consultas por contagem de CPU/duração/execuçã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 uma determinada camada de serviço e tamanho de computação.
- Analise detalhadamente os detalhes de uma consulta para exibir seu texto e seu histórico de uso de recursos.
- Exiba recomendações de ajuste de desempenho que mostram as ações executadas pelo Consultor do Banco de Dados SQL.
Unidades de transação de banco de dados elástico (eDTUs)
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 única 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 unidades de transação de banco de dados elástico (eDTUs). Os pools elásticos fornecem uma solução simples e econômica para gerenciar metas de desempenho para vários bancos de dados com padrões de uso amplamente variados e imprevisíveis. Um pool elástico garante que todos os recursos não possam ser consumidos por um banco de dados no pool, ao mesmo tempo em que garante que cada banco de dados no pool sempre tenha uma quantidade mínima de recursos necessários disponíveis.
Um pool recebe 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 uma carga mais pesada consome mais eDTUs para atender à demanda. Bancos de dados sob cargas mais leves consomem menos eDTUs. Bancos de dados sem carga não consomem 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 o mínimo de tempo 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 eDTUs que os bancos de dados podem usar sob uma carga pesada. Se um banco de dados tiver uma utilização de recursos consistentemente alta que afete outros bancos de dados no pool, mova-o para fora do pool e configure-o como um único banco de dados 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 baixa média de utilização de recursos e picos de utilização relativamente pouco frequentes. Para obter mais informações, consulte 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ê quiser migrar uma carga de trabalho de máquina virtual local ou SQL Server existente para o Banco de dados SQL, consulte Recomendações de SKU para aproximar o número de DTUs necessárias. Para uma carga de trabalho existente do Banco de dados SQL, use insights de desempenho de consulta para entender seu consumo de recursos de banco de dados (DTUs) e obter informações mais detalhadas para otimizar sua carga de trabalho. A sys.dm_db_resource_stats visualização de gerenciamento dinâmico (DMV) permite visualizar o consumo de recursos da última hora. A exibição de catálogo sys.resource_stats exibe o consumo de recursos dos ú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 de DTU/eDTU em relação ao limite de 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 esta fórmula podem ser obtidos de sys.dm_db_resource_stats, sys.resource_stats e sys.elastic_pool_resource_stats DMVs. Em outras palavras, para determinar a porcentagem de utilização de DTU/eDTU em relação ao limite de DTU/eDTU de um banco de dados ou pool elástico, escolha o maior valor percentual entre os seguintes: avg_cpu_percent, avg_data_io_percente avg_log_write_percent em um determinado momento.
Nota
O limite de 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 seu cache de dados para melhorar o desempenho, o avg_memory_usage_percent valor geralmente será próximo de 100%, independentemente da carga atual do banco de dados. Portanto, mesmo que 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 um tipo específico de hardware por um longo tempo (geralmente por vários meses), há certos eventos que podem fazer com que um banco de dados seja movido para hardware diferente.
Por exemplo, um banco de dados pode ser movido para hardware diferente se for dimensionado para cima ou para baixo 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.
Se um banco de dados for movido para hardware diferente, o desempenho da carga de trabalho poderá mudar. O modelo DTU garante que a taxa de transferência e o tempo de resposta da carga de trabalho de benchmark 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 amplo espectro de cargas de trabalho de clientes 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 mais pronunciado. Cargas de trabalho diferentes podem se beneficiar de diferentes configurações e recursos de hardware. Portanto, para cargas de trabalho diferentes do benchmark DTU, é possível ver diferenças de desempenho se o banco de dados for movido de um tipo de hardware para outro.
Os clientes podem usar o modelo vCore para escolher sua configuração de hardware preferida durante a criação e o dimensionamento do banco de dados. No modelo vCore, limites de recursos detalhados de cada objetivo de serviço em cada configuração de hardware são documentados para bancos de dados únicos e pools elásticos. Para obter mais informações sobre hardware no modelo vCore, consulte Configuração de hardware para Banco de dados SQL ou Configuração de hardware para instância gerenciada SQL.
Comparar níveis de serviço
A escolha de um nível de serviço depende principalmente dos requisitos de continuidade de negócios, armazenamento e desempenho.
| Básica | 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% |
| Cópia de segurança | 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 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 até 10 anos |
Uma opção 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 |
| Processador | Mínimo | Baixo, Médio, Alto | Média, Alta |
| 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 | Suportado |
| OLTP na memória | N/A | N/A | Suportado |
* Todas as IOPS de leitura e gravação em arquivos de dados, incluindo IO de fundo (ponto de verificação e gravador preguiçoso).
Importante
Os objetivos de serviço Basic, 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 de S3 ou superior.
Nos objetivos de serviço Básico, S0 e S1, os arquivos de banco de dados são armazenados no Armazenamento Padrão do Azure, que usa mídia de armazenamento baseada em unidade de disco rígido (HDD). Esses objetivos de serviço são mais adequados para desenvolvimento, testes e outras cargas de trabalho acessadas com pouca frequência que são menos sensíveis à variabilidade de desempenho.
Gorjeta
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 único banco de dados, uma linha é retornada. Para um banco de dados em um pool elástico, uma linha é retornada para cada banco de dados no pool.
Nota
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 Criar 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 únicos e agrupados.
Limites de armazenamento de banco de dados único
No Banco de Dados SQL do Azure, os tamanhos de computação são expressos em termos de DTUs (Unidades de Transação de Banco de Dados) para bancos de dados únicos e Unidades de Transação de Banco de Dados (eDTUs) elásticas para pools elásticos. Para saber mais, revise Limites de recursos para bancos de dados únicos.
| Básica | Standard | Premium | |
|---|---|---|---|
| Tamanho máximo de armazenamento | 2 GB | 1 TB | 4 TB |
| DTUs máximos | 5 | 3000 | 4000 |
Importante
Em algumas circunstâncias, pode ser necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte Gerenciar espaço de arquivo no Banco de Dados SQL do Azure.
Limites da piscina elástica
Para saber mais, consulte Limites de recursos para bancos de dados em pool.
| Básica | 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
Mais de 1 TB de armazenamento no nível Premium está atualmente disponível em todas as regiões, exceto: Leste da China, Norte da China, Alemanha Central e Nordeste da Alemanha. Noutras regiões, o armazenamento máximo no escalão Premium está limitado a 1 TB. Para obter mais informações, consulte Limitações atuais do P11-P15.
Importante
Em algumas circunstâncias, pode ser necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte gerenciar espaço de arquivo no Banco de Dados SQL do Azure.
Referência da DTU
As características físicas (CPU, memória, E/S) associadas a cada medida DTU são calibradas usando um benchmark que simula a carga de trabalho do banco de dados do mundo real.
Saiba mais sobre o esquema, os tipos de transação usados, a combinação de carga de trabalho, os usuários e o ritmo, as regras de dimensionamento e as métricas associadas ao benchmark da DTU.
Compare 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, em comparação, o modelo de compra vCore para o Banco de Dados SQL do Azure permite que você escolha e dimensione recursos de computação e armazenamento de forma independente.
O modelo de compra baseado em vCore também permite que você use o Benefício Híbrido do Azure para SQL Server para economizar custos e oferece opções sem servidor e hiperescala para o Banco de Dados SQL do Azure que não estão disponíveis no modelo de compra baseado em DTU.
Saiba mais em Comparar modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.
Próximos passos
Saiba mais sobre modelos de compra e conceitos relacionados nos seguintes artigos:
- Para obter detalhes sobre tamanhos de computação específicos e opções de tamanho de armazenamento disponíveis para bancos de dados únicos, consulte Limites de recursos baseados em DTU do Banco de dados SQL para bancos de dados únicos.
- Para obter detalhes sobre tamanhos de computação específicos e opções de tamanho de armazenamento disponíveis para pools elásticos, consulte Limites de recursos baseados em DTU do Banco de dados SQL.
- Para obter informações sobre o benchmark associado ao modelo de compra baseado em DTU, consulte Benchmark DTU.
- Compare os modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.