Visão geral do modelo de compra baseado em DTU
Aplica-se a: do Banco de Dados SQL do Azure
Este artigo fornece uma visão geral do modelo de compra baseado em DTU para o Banco de Dados SQL do Azure. O modelo de compra baseado em DTU é uma medida simples e agrupada de recursos de computação, armazenamento e E/S. É mais adequado para a maioria dos clientes com cargas de trabalho típicas. O modelo de compra baseado em DTU está disponível nas camadas de serviço Basic, Standard e Premium. O modelo de compra baseado em DTU também está disponível para piscinas elásticas.
O modelo de compra baseado em DTU é diferente do modelo de compra baseado em vCore , para que você possa comparar modelos de compra.
Unidades de transação de banco de dados (DTUs)
Uma unidade de transação de banco de dados (DTU) representa uma medida combinada de CPU, memória, leituras e gravações. 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. Todos os níveis de serviço no modelo de compra baseado em DTU oferecem flexibilidade de alterar tamanhos de computação com o mínimo de tempo de inatividade ; No entanto, há um período de alternância em que a conectividade é perdida para o banco de dados por um curto período de tempo, que pode ser atenuada 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 certo 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 uma compreensão mais profunda sobre o consumo de recursos (DTU) da sua carga de trabalho, utilize insights de desempenho de consulta para:
- Identifique as principais consultas por utilização de CPU, duração e contagem de execução que podem ser ajustadas para otimizar o desempenho. Por exemplo, uma consulta intensiva de E/S pode beneficiar-se de técnicas de otimização em memória para fazer melhor uso da memória disponível em um nível de serviço e dimensão de computação específicos.
- 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 tomadas pelo Supervisor de Banco de Dados .
Unidades de transação de banco de dados elástico (eDTUs)
Em vez de fornecer um conjunto dedicado de recursos (DTUs) que nem sempre é necessário, 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 muito 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 carga elevada. 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 pools elásticos no Banco de Dados SQL do Azure
Determinar o número de DTUs necessários para um 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 da Base de Dados SQL, utilize os insights de desempenho de consulta de para entender o consumo de recursos da sua base de dados (DTUs) e obter informações mais detalhadas para otimizar a sua carga de trabalho. A sys.dm_db_resource_stats visão de gestão dinâmica (DMV) permite que você visualize o consumo de recursos da última hora. A vista de catálogo sys.resource_stats exibe o consumo de recursos dos últimos 14 dias, mas com menor fidelidade de médias a cada 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_statse 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_percent
e avg_log_write_percent
em um determinado momento.
Observação
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 valor de avg_memory_usage_percent
geralmente estará 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 do benchmark DTU permanecerão substancialmente idênticos à medida que o banco de dados for movido para um tipo de hardware diferente, desde que o 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 observar diferenças de desempenho caso a base de dados seja transferida 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, consulte configuração de hardware.
Comparar níveis de serviço
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 Criar um banco de dados de nuvem gerenciado com sua conta gratuita do Azure.
A escolha de um nível de serviço depende principalmente dos requisitos de continuidade de negócios, armazenamento e desempenho.
Básico | Padrão | Prémio | |
---|---|---|---|
Carga de trabalho de destino | Desenvolvimento e produção | Desenvolvimento e produção | Desenvolvimento e produção |
SLA de Uptime | 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 |
CPU | Baixo | Baixo, Médio, Alto | Médio, Alto |
IOPS (aproximadamente)1 | 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 de Columnstore2 | N/A | Standard S3 e superior | Suportado |
OLTP na memória | N/A | N/A | Suportado |
1 Todas as IOPS de leitura e gravação em arquivos de dados, incluindo operações de entrada/saída em segundo plano (ponto de verificação e escritor preguiçoso).
2 Para obter mais informações, consulte Alterar camadas de serviço de bancos de dados que contêm índices columnstore.
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 Basic, 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, 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 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.
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, consulte Limites de recursos para bancos de dados únicos.
Básico | Padrão | Prémio | |
---|---|---|---|
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 espaço não utilizado. Para obter mais informações, consulte Gerenciar espaço de arquivo para bancos de dados no Banco de Dados SQL do Azure.
Limites da piscina elástica
Para saber mais, consulte Limites de recursos para pools elásticos com o modelo de aquisição DTU.
Básico | Standard | Premium | |
---|---|---|---|
Tamanho máximo de armazenamento por base 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 base 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. Nessas regiões, o armazenamento máximo no nível Premium é limitado a 1 TB. Para obter mais informações, consulte P11-P15 limitações atuais.
Importante
Em algumas circunstâncias, talvez seja necessário reduzir um banco de dados para recuperar espaço não utilizado. Para obter mais informações, consulte gerir o espaço de ficheiros na Base de Dados SQL do Azure.
DTU benchmark
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, o mix de carga de trabalho, os usuários e o ritmo, as regras de dimensionamento e as métricas associadas ao de referência de 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 de Benefício Híbrido do Azure para SQL Server para economizar custos e oferece camada de computação sem servidor para do Banco de Dados SQL do Azure e opções de camada de serviço Hyperscale 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 Compare modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.