Compartilhar via

Gerenciamento de recursos no Banco de dados SQL do Azure

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

Este artigo fornece uma visão geral do gerenciamento de recursos no Banco de Dados SQL do Azure. Ele fornece informações sobre o que acontece quando os limites de recursos são atingidos e descreve os mecanismos de governança de recursos usados para impor esses limites.

Para obter limites específicos de recursos por tipo de preço para bancos de dados individuais, consulte

Para limites de recursos do pool elástico, consulte:

Para os limites do pool de SQL dedicado no Azure Synapse Analytics, consulte:

Limites de vCore da assinatura por região

A partir de março de 2024, as assinaturas têm os seguintes limites de vCore por região por assinatura:

Tipo de subscrição Limites padrão de vCore
Enterprise Agreement (EA) 2000
Avaliações gratuitas 10
Microsoft para Startups 100
MSDN/MPN/Imagine/AzurePass/Azure para Estudantes 40
Pagamento conforme o uso (PAYG) 150

Considere o seguinte:

  • Esses limites são aplicáveis a assinaturas novas e existentes.
  • Os bancos de dados e pools elásticos provisionados com o modelo de compra de DTU também são contabilizados na cota de vCore e vice-versa. Cada vCore consumido é considerado equivalente a 100 DTUs consumidas para a cota no nível do servidor.
  • Os limites padrão incluem os vCores configurados para bancos de dados/pools elásticos de computação provisionados e os vCores máximos configurados para bancos de dados sem servidor.
  • Você pode usar a chamada Usos de Assinatura – Obter da API REST para determinar o uso atual do vCore para sua assinatura.
  • Para solicitar uma cota de vCore superior ao valor padrão, envie uma nova solicitação de suporte no portal do Azure. Para mais informações, consulte Solicitar aumentos de cotas para Banco de Dados SQL do Azure.

Limites do servidor lógico

Recurso Limite
Bancos de dados por servidor lógico 5.000
Número padrão de servidores lógicos por assinatura numa região 250
Número máximo de servidores lógicos por assinatura numa região 250
Máximo de pools elásticos por servidor lógico Limitado pelo número de DTUs ou vCores. Por exemplo, se cada pool tiver 1.000 DTUs, um servidor poderá dar suporte a 54 pools.

Importante

Como o número de bancos de dados aproxima-se do limite por servidor lógico, pode ocorrer o seguinte:

  • Aumento de latência nas consultas em execução no banco de dados master. Isso inclui modos de exibição de estatísticas de utilização de recursos, como sys.resource_stats.
  • Aumento de latência nas operações de gerenciamento e pontos de vista do portais de renderização que envolvem a enumeração de bancos de dados no servidor.

O que acontece quando os limites de recursos são atingidos

CPU de computação

Quando a utilização da CPU de computação de banco de dados aumenta, a latência da consulta aumenta e as consultas podem até atingir o tempo limite. Sob essas condições, as consultas podem ser enfileiradas pelo serviço e são fornecidos recursos para execução à medida que os recursos são liberados.

Se você observar alta utilização de computação, as opções de mitigação incluem:

Armazenamento

Quando o espaço de dados usado atinge o limite máximo de tamanho de dados, seja no nível do banco de dados ou no nível do pool elástico, as inserções e atualizações que aumentam o tamanho dos dados falham, e os clientes recebem uma mensagem de erro. As instruções SELECT e DELETE permanecem não afetadas.

Nas camadas de serviço Premium e Comercialmente Crítico, os clientes também recebem uma mensagem de erro se o consumo de armazenamento combinado de dados, log de transações e tempdb para um banco de dados individual ou um pool elástico exceder o tamanho máximo do armazenamento local. Para obter mais informações, consulte Governança de espaço de armazenamento.

Se você observar uma alta utilização do espaço de armazenamento, as opções de mitigação incluem:

  • Aumente o tamanho máximo de dados do banco de dados ou do pool elástico ou escale verticalmente para um objetivo de serviço com um limite mais alto de tamanho máximo de dados. Consulte limites de recursos do banco de dados individual em escala e limites de recursos do pool elástico.
  • Se o banco de dados estiver em um pool elástico, então, como alternativa, o banco de dados poderá ser movido para fora do pool, de modo que seu espaço de armazenamento não seja compartilhado com outros bancos de dados.
  • Encolher 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.
    • Em pools elásticos, a redução de um banco de dados fornece mais armazenamento para outros bancos de dados no pool.
  • Verifique se a utilização de espaço alta é devido a um aumento no tamanho do armazenamento de versão persistente (PVS). O PVS é uma parte de cada banco de dados e é usado para implementar a Recuperação de banco de dados acelerada. Para determinar o tamanho atual do PVS, consulte Solução de problemas do PVS. Um motivo comum para o tamanho de PVS grande é uma transação que fica aberta por um longo tempo (horas), impedindo a limpeza de versões mais antigas de linha no PVS.
  • Para bancos de dados grandes nas camadas de serviço Premium e Comercialmente Crítico que consumem grandes quantidades de armazenamento, você pode receber um erro de espaço insuficiente, mesmo que o espaço usado no banco de dados ou no pool elástico seja inferior ao limite de tamanho de dados máximo. Isso pode acontecer se o tempdb ou os arquivos de log de transações consumirem uma grande quantidade de armazenamento que se aproxime do limite máximo de armazenamento local. Faça fail over do banco de dados ou do pool elástico para redefinir o tempdb para seu tamanho inicial menor ou reduza o log de transações para reduzir o consumo de armazenamento local.

Sessões, funções de trabalhos e solicitações

As sessões, as funções de trabalhos e as solicitações são definidas da seguinte forma:

  • Uma sessão representa um processo conectado ao mecanismo de banco de dados.
  • Uma solicitação é a representação lógica de uma consulta ou lote. Uma solicitação é emitida por um cliente conectado a uma sessão. Com o tempo, várias solicitações podem ser emitidas na mesma sessão.
  • Um thread de trabalho, também conhecido como um trabalho ou thread, é uma declaração lógica de um thread do sistema operacional. Uma solicitação pode ter muitas funções de trabalhos quando executados com um plano de execução de consulta paralelo, ou um único função de trabalho quando executado com um plano de execução serial (threading simples). As funções de trabalhos também são obrigados a dar suporte a atividades fora de solicitações: por exemplo, uma função de trabalho é necessário para processar uma solicitação de logon à medida que uma sessão se conecta.

Para obter mais informações sobre esses conceitos, confira o Guia de arquitetura de threads e tarefas.

O número máximo de trabalhos é determinado pelo nível de serviço e tamanho da computação. Novas solicitações serão rejeitadas quando os limites de sessão ou de trabalho forem atingidos, e os clientes receberão uma mensagem de erro. Embora o número de conexões disponíveis possa ser controlado pelo aplicativo, o número de trabalhos simultâneos costuma ser mais difícil de ser estimado e controlado. Isso é especialmente verdadeiro durante os períodos de aumento de carga, quando os limites de recurso de banco de dados são atingidos e os trabalhos acumulam devido a consultas mais longas, grandes cadeias de bloqueio ou paralelismo excessivo de consultas.

Observação

A oferta inicial do Banco de Dados SQL do Azure suportava apenas consultas com thread único. Nesse momento, o número de solicitações sempre foi equivalente ao número de funções de trabalhos. A mensagem de erro 10928 no Banco de Dados SQL do Azure contém o texto The request limit for the database is *N* and has been reachedapenas para fins de compatibilidade com versões anteriores. O limite atingido é, na verdade, o número de funções de trabalhos.

Se seu grau máximo de paralelismo (MAXDOP) for igual a zero ou for maior do que um, o número de funções de trabalhos poderá ser muito maior do que o número de solicitações, e o limite poderá ser atingido muito mais cedo do que quando MAXDOP for igual a um.

É possível reduzir a aproximação ou atingir limites de trabalho ou sessão:

Encontre limites de trabalho e sessão para Banco de Dados SQL do Azure por camada de serviço e tamanho de computação:

Saiba mais sobre como solucionar erros específicos para limites de sessão ou de trabalho em Erros de governança de recursos.

Conexões externas

O número de conexões simultâneas com pontos de extremidade externos feitos por meio de sp_invoke_external_rest_endpoint é limitado a 10% dos threads de trabalho, com um limite rígido de no máximo 150 trabalhos.

Memória

Ao contrário de outros recursos (CPU, trabalhos, armazenamento), atingir o limite de memória não afeta negativamente o desempenho da consulta e não causa erros e falhas. Conforme descrito em detalhes no Guia de Arquitetura de Gerenciamento de Memória, o mecanismo de banco de dados geralmente usa toda a memória disponível, por design. A memória é usada principalmente para dados de cache, para evitar acesso mais lento ao armazenamento. Portanto, a maior utilização de memória geralmente melhora o desempenho da consulta devido a leituras mais rápidas da memória, em vez de leituras mais lentas do armazenamento.

Após a inicialização do mecanismo de banco de dados, à medida que a carga de trabalho começa a ler dados do armazenamento, o mecanismo de banco de dados armazena dados na memória de forma agressiva. Após esse período de partida inicial, é comum e esperado que as colunas avg_memory_usage_percent e avg_instance_memory_percent em sys.dm_db_resource_stats e a métrica sql_instance_memory_percent do Azure Monitor sejam próximas ou iguais a 100%, especialmente para bancos de dados que não estão ociosos e não cabem inteiramente na memória.

Observação

A métrica sql_instance_memory_percent reflete o consumo total de memória pelo mecanismo de banco de dados. Essa métrica pode não chegar a 100% mesmo quando cargas de trabalho de alta intensidade estiverem em execução. Isso ocorre porque uma pequena parte da memória disponível é reservada para alocações de memória crítica diferentes do cache de dados, como pilhas de threads e módulos executáveis.

Além do cache de dados, a memória é usada em outros componentes do mecanismo de banco de dados. Quando há demanda de memória e toda a memória disponível foi usada pelo cache de dados, o mecanismo de banco de dados reduz o tamanho do cache de dados para disponibilizar a memória para outros componentes e aumenta dinamicamente o cache de dados quando outros componentes liberam a memória.

Em casos raros, uma carga de trabalho exigente pode causar uma condição de memória insuficiente, levando a erros de falta de memória. Erros de memória insuficiente podem acontecer em qualquer nível de utilização de memória entre 0% e 100%. É mais provável que erros de memória insuficiente ocorram em tamanhos de computação menores que têm limites de memória proporcionalmente menores ou com cargas de trabalho que usam mais memória para o processamento de consulta, como em pools elásticos densos.

Se você receber erros de memória insuficiente, as opções de mitigação incluem:

Solução Descrição
Reduzir o tamanho das concessões de memória Para obter mais informações sobre concessões de memória, confira a postagem do blog Entenda a Concessão de Memória do SQL Server. Uma solução comum para evitar concessões de memória excessivamente grandes é manter as estatísticas atualizadas. Isso resulta em estimativas mais precisas de consumo de memória pelo mecanismo de consulta, evitando grandes concessões de memória.

Por padrão, em bancos de dados que usam o nível de compatibilidade 140 e superiores, o mecanismo de banco de dados pode ajustar automaticamente o tamanho de concessão de memória usando os comentários de concessão de memória do modo de lote. Em bancos de dados usando os níveis de compatibilidade 150 e superiores, o mecanismo de banco de dados usa de forma semelhante os Comentários de concessão de memória de modo de linha, ara consultas de modo de linha mais comuns. Essa funcionalidade interna ajuda a evitar erros de memória insuficiente devido a grandes concessões de memória grandes.
Reduzir o tamanho do cache do plano de consulta O mecanismo de banco de dados armazena em cache os planos de consulta na memória, para evitar a compilação para cada execução de consulta. Para evitar a sobrecarga do cache de planos de consulta causado por planos de cache que são usados apenas uma vez, certifique-se de usar consultas parametrizadas e considere habilitar a configuração OPTIMIZE_FOR_AD_HOC_WORKLOADS no escopo do banco de dados.
Reduzir o tamanho da memória de bloqueio O mecanismo de banco de dados usa memória para bloqueios. Quando possível, evite transações grandes que possam adquirir um grande número de bloqueios e causar alto consumo de memória de bloqueio.

Consumo de recursos por cargas de trabalho do usuário e processos internos

O banco de dados SQL do Azure requer recursos de computação para implementar recursos de serviço principais, como alta disponibilidade e recuperação de desastre, backup e restauração de banco de dados, monitoramento, Repositório de Consultas, ajuste automático etc. O sistema separa uma determinada parte limitada dos recursos gerais para esses processos internos usando mecanismos de governança de recursos, tornando os demais recursos disponíveis para cargas de trabalho do usuário. Às vezes, quando os processos internos não estão usando recursos de computação, o sistema os disponibiliza para cargas de trabalho do usuário.

O consumo total de CPU e memória por cargas de trabalho do usuário e processos internos é relatado nas exibições sys.dm_db_resource_stats e sys.resource_stats, nas colunas avg_instance_cpu_percent e avg_instance_memory_percent. Esses dados também são relatados por meio das sql_instance_cpu_percent e sql_instance_memory_percent métricas e Azure Monitor, para sql_instance_cpu_percent e sql_instance_memory_percent no nível do pool.

Observação

As métricas do Azure Monitor sql_instance_cpu_percent e sql_instance_memory_percent estão disponíveis desde julho de 2023. Eles são totalmente equivalentes às métricas sqlserver_process_core_percent e sqlserver_process_memory_percent disponíveis anteriormente, respectivamente. As duas últimas métricas permanecem disponíveis, mas serão removidas no futuro. Para evitar uma interrupção no monitoramento do banco de dados, não use as métricas antigas.

Essas métricas não estão disponíveis para bancos de dados que usam objetivos de serviço Básico, S1 e S2. Os mesmos dados estão disponíveis nas exibições de gerenciamento dinâmico abaixo.

O consumo de CPU e memória pelas cargas de trabalho do usuário em cada banco de dados é relatado nas exibições sys.dm_db_resource_stats e sys.resource_stats, nas colunas avg_cpu_percent e avg_memory_usage_percent. Para pools elásticos, o consumo de recursos no nível do pool é relatado na exibição sys.elastic_pool_resource_stats (para cenários de relatório histórico) e em sys.dm_elastic_pool_resource_stats para monitoramento em tempo real. O consumo de CPU da carga de trabalho do usuário também é relatado por meio da métrica cpu_percent do Azure Monitor para bancos de dados únicos e pools elásticos no nível do pool.

Uma análise mais detalhada do consumo de recursos recente por cargas de trabalho do usuário e processos internos é relatada nas exibições Sys.dm_resource_governor_resource_pools_history_ex e Sys.dm_resource_governor_workload_groups_history_ex. Para obter detalhes sobre pools de recursos e grupos de carga de trabalho referenciados nessas exibições, consulte Governança de recursos. Essas exibições demonstram a utilização de recursos por cargas de trabalho do usuário e processos internos específicos nos pools de recursos e grupos de carga de trabalho associados.

Dica

Ao monitorar ou solucionar problemas de desempenho de carga de trabalho, é importante considerar o consumo de CPU pelo usuário (avg_cpu_percent, cpu_percent) e o consumo total de CPU por cargas de trabalho do usuário e processos internos (avg_instance_cpu_percent, sql_instance_cpu_percent). O desempenho poderá ser notavelmente afetado se uma dessas métricas estiver no intervalo de 70 a 100%.

O consumo de CPU do usuário é definido como uma porcentagem dos limites de carga de trabalho de CPU do usuário em cada objetivo de serviço. Da mesma forma, o consumo total da CPU é definido como a porcentagem em relação ao limite de CPU para todas as cargas de trabalho. Como os dois limites são diferentes, o usuário e o consumo total da CPU são medidos em escalas diferentes e não são diretamente comparáveis entre si.

Se o consumo de CPU dos usuários alcançar 100%, isso significa que a carga de trabalho dos usuários está usando totalmente a capacidade de CPU disponível para eles no objetivo de serviço selecionado, mesmo que o consumo total de CPU permaneça abaixo de 100%.

Quando o consumo total da CPU atinge o intervalo de 70% a 100%, é possível ver o nivelamento da produtividade da carga de trabalho do usuário e o aumento da latência de consulta, mesmo que o consumo de CPU do usuário permaneça significativamente abaixo de 100%. Isso é mais provável de ocorrer ao usar objetivos de serviço menores com uma alocação moderada de recursos de computação, mas cargas de trabalho de usuário relativamente intensa, como em pools elásticos denso. Isso também pode ocorrer com objetivos de serviço menores quando processos internos exigem recursos adicionais temporariamente, por exemplo, ao criar uma nova réplica do banco de dados ou ao fazer backup do banco de dados.

Da mesma forma, quando o consumo de CPU dos usuários alcançar o intervalo de 70% a 100%, a produtividade da carga de trabalho dos usuários será nivelada, e a latência da consulta aumentará, mesmo se o consumo total de CPU estiver bem abaixo de seu limite.

Quando o consumo de CPU do usuário ou o consumo total de CPU são altos, as opções de mitigação são as mesmas mencionadas na seção CPU de computação e incluem aumento de objetivo de serviço e otimização de carga de trabalho do usuário.

Observação

Mesmo em um banco de dados completamente ocioso ou pool elástico, o consumo total de CPU nunca será zerado devido às atividades do mecanismo de banco de dados em segundo plano. O consumo pode flutuar em uma ampla gama, dependendo das atividades específicas em segundo plano, do tamanho da computação e da carga de trabalho do usuário anterior.

Governança de recursos

Para impor limites de recursos, o Banco de Dados SQL do Azure usa uma implementação de governança de recursos baseada no Resource Governor do SQL Server, modificado e estendido para execução na nuvem. No banco de dados SQL, vários pools de recursos e grupos de carga de trabalho, com limites de recursos definidos no pool e nos níveis de grupo, fornecem um Banco de dados como serviço equilibrado. Carga de trabalho do usuário e cargas de trabalho internas são classificadas em pools de recursos e grupos de carga de trabalho separados. A carga de trabalho do usuário nas réplicas secundárias e primárias para leitura, incluindo réplicas geográficas, é classificada no pool de recursos SloSharedPool1 e no grupo de carga de trabalho UserPrimaryGroup.DBId[N], em que [N] significa o valor da ID do banco de dados. Além disso, há vários pools de recursos e grupos de carga de trabalho para várias cargas de trabalho internas.

Além de usar Resource Governor para controlar os recursos no mecanismo de banco de dados, o Banco de Dados SQL do Azure também usa Objetos de trabalho do Windows para a governança de recursos de nível de processo e o FSRM (Gerenciador de recursos de servidor de arquivos) do Windows para gerenciamento de cota de armazenamento.

A governança de recursos do banco de dados SQL do Azure é hierárquica por natureza. De cima para baixo, os limites são impostos no nível do sistema operacional e no nível do volume de armazenamento usando mecanismos de governança de recursos do sistema operacional e Resource Governor, em seguida, no nível do pool de recursos usando Resource Governor e, em seguida, no nível do grupo de carga de trabalho usando Resource Governor. Os limites de governança de recursos em vigor para o banco de dados atual ou o pool elástico são exibidos na exibição de sys.dm_user_db_resource_governance.

Governança de E/S de dados

A governança de E/S de dados é um processo no Banco de Dados SQL do Azure usado para limitar a E/S física de leitura e gravação em arquivos de data de um banco. Os limites de IOPS são definidos para cada nível de serviço a fim de minimizar o efeito de "vizinho ruidoso", proporcionar imparcialidade na alocação de recursos em um serviço multilocatário e permanecer dentro das capacidades do hardware e do armazenamento subjacentes.

Para bancos de dados únicos, os limites do grupo de carga de trabalho são aplicados a todo o E/S de armazenamento no banco de dados. Para pools elásticos, os limites de grupo de carga de trabalho se aplicam a cada banco de dados no pool. Além disso, o limite do pool de recursos se aplica também à E/S cumulativa do pool elástico. Em tempdb, a E/S está sujeita aos limites de grupo de carga de trabalho, com exceção da camada de serviço Básico, Standard e Uso Geral, onde os limites de E/S de tempdb mais altos se aplicam. Em geral, os limites do pool de recursos podem não ser obtidos pela carga de trabalho em relação a um banco de dados (individual ou em pool), pois os limites do grupo de carga de trabalho são inferiores aos limites do pool de recursos e limitam o IOPS/taxa de transferência mais cedo. No entanto, os limites de pool podem ser alcançados pela carga de trabalho combinada em vários bancos de dados no mesmo pool.

Por exemplo, se uma consulta gerar 1000 IOPS sem nenhuma governança de recursos de E/S, mas o limite máximo de IOPS do grupo de carga de trabalho for definido como 900 IOPS, a consulta não poderá gerar mais de 900 IOPS. No entanto, se o limite máximo de IOPS do pool de recursos for definido como 1500 IOPS e a E/S total de todos os grupos de carga de trabalho associados ao pool de recursos exceder 1500 IOPS, então a E/S da mesma consulta poderá ser reduzida abaixo do limite do grupo de trabalhos de 900 IOPS.

Os valores máximos de IOPS e taxa de transferência retornados pela exibição de Sys.dm_user_db_resource_governance atuam como limites/Caps, não como garantias. Além disso, a governança de recursos não garante nenhuma latência de armazenamento específica. A melhor latência, IOPS e taxa de transferência atingíveis para uma determinada carga de trabalho do usuário dependem não apenas dos limites de governança de recursos de E/S, mas também da combinação de tamanhos de E/S usados e dos recursos do armazenamento subjacente. O Banco de Dados SQL usa operações de E/S que variam entre 512 bytes e 4 MB de tamanho. Para fins de imposição de limites de IOPS, cada E/S é contabilizada independentemente de seu tamanho, com a exceção de bancos de dados com arquivos de dados no armazenamento do Azure. Nesse caso, as E/S maiores que 256 KB são contabilizados como várias E/S de 256 KB, para alinhar com a contabilidade de E/S do Armazenamento do Microsoft Azure.

Para bancos de dados Básico, Standard e Uso Geral, que usam arquivos de dado no armazenamento do Azure, o primary_group_max_io valor pode não ser atingível se um banco de dados não tiver arquivos de dado suficientes para fornecer esse número de IOPS, ou se os dados não forem distribuídos uniformemente entre arquivos ou se o nível de desempenho dos blobs subjacentes limitar do IOPS/taxa de transferência for abaixo dos limites de governança de recursos. Da mesma forma, com pequenas operações de E/S de log geradas por confirmações frequentes de transações, o valor de primary_max_log_rate pode não ser alcançável por uma carga de trabalho devido ao limite de IOPS no blob de armazenamento do Azure subjacente. Para bancos de dados que usam o Armazenamento Premium do Azure, o banco de dados SQL do Azure usa blobs de armazenamento suficientemente grandes para obter IOPS/taxa de transferência necessários, independentemente do tamanho do banco de dados. Para bancos de dados maiores, vários arquivos de data são criados para aumentar a capacidade total de IOPS/taxa de transferência.

Os valores de utilização de recursos, como avg_data_io_percent e avg_log_write_percent, relatados nas exibições sys.dm_db_resource_stats, sys.resource_stats, sys.dm_elastic_pool_resource_stats e sys.elastic_pool_resource_stats são calculados como porcentagens de limites máximos de governança de recursos. Portanto, quando fatores diferentes da governança de recursos limitam o IOPS/taxa de transferência, é possível ver o nivelamento de IOPS/taxa de transferência e as latências aumentando à medida que a carga de trabalho aumenta, embora a utilização de recursos relatada permaneça abaixo de 100%.

Para monitorar a leitura e gravação de IOPS, taxa de transferência e latência por arquivo de banco de dados, use a função Sys.dm_io_virtual_file_stats (). Essa função mostra todas as E/S no banco de dados, incluindo a E/S de segundo plano que não é contabilizada avg_data_io_percent, mas usa IOPS e taxa de transferência do armazenamento subjacente e pode afetar a latência de armazenamento observada. A função reporta latência adicional que pode ser introduzida pela governança de recursos de E/S para leituras e gravações, nas colunas io_stall_queued_read_ms e io_stall_queued_write_ms, respectivamente.

Taxa do log de governança

A governança da taxa do log de transações é um processo no banco de dados SQL do Azure usado para limitar altas taxas de ingestão para cargas de trabalho, bulk insert, SELECT INTO e compilações de índice. Esses limites são rastreados e aplicados no nível de subsegundos à taxa de geração de registro de log, limitando a taxa de transferência, independentemente de quantos as E/S podem ser emitidas em relação aos arquivos de dados. As taxas de geração de log de transações são escaladas verticalmente de forma linear para um ponto que depende do hardware e da camada de serviço.

As taxas de log são definidas de modo que possam ser alcançadas e mantidas em vários cenários, enquanto o sistema geral pode manter sua funcionalidade com impacto minimizado na carga do usuário. A governança de taxa de log garante que os backups de log de transações permaneçam dentro dos SLAs de recuperação publicados. Essa governança também impede uma pendência excessiva em réplicas secundárias, o que poderia levar a tempo de inatividade mais longo do que o esperado durante failovers.

As E/S físicas reais para os arquivos de log de transações não são governadas ou limitadas. À medida que os registros de log são gerados, cada operação é avaliada e avaliada, para saber se deve ser atrasada para manter uma taxa máxima de log desejada (MB/s por segundo). Os atrasos não são adicionados quando os registros de log são liberados para armazenamento, em vez disso, a governança de taxa de log é aplicada durante a própria geração de taxa de log.

As taxas de geração de log reais impostas no tempo de execução também podem ser influenciadas pelos mecanismos de comentários, reduzindo temporariamente as taxas de log permitidas para que o sistema possa se estabilizar. O gerenciamento de espaço de arquivo de log, evita a execução de condições de espaço de log e os mecanismos de replicação de dados que podem diminuir temporariamente os limites gerais do sistema.

A modelagem de tráfego do administrador da taxa de log é apresentada por meio dos seguintes tipos de espera (expostos nas exibições Sys.dm_exec_requests e Sys.dm_os_wait_stats ):

Tipo de Espera Observações
LOG_RATE_GOVERNOR Limitação de banco de dados
POOL_LOG_RATE_GOVERNOR Limitação de pool
INSTANCE_LOG_RATE_GOVERNOR Limitação de nível de instância
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE Controle de comentários, replicação física do grupo de disponibilidade em Premium/Comercialmente Crítico não está acompanhando
HADR_THROTTLE_LOG_RATE_LOG_SIZE Controle de comentários, limitando as taxas para evitar uma condição de espaço de log insuficiente
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO Controle de comentários de replicação geográfica, limitando a taxa de log para evitar alta latência de dados e indisponibilidade de secundários geográficos

Ao encontrar um limite de taxa de log que está atrasando a escalabilidade desejada, considere as seguintes opções:

  • Escale verticalmente para um nível de serviço superior a fim de obter a taxa máxima de log de uma camada de serviço ou alterne para uma camada de serviço diferente. A camada de serviço de Hiperescala fornece taxa de log de 100 MB/s por banco de dados e 125 MB/s por pool elástico, independentemente do nível de serviço escolhido.
  • Se os dados que estão sendo carregados forem transitórios, como dados de preparo em um processo de ETL, eles poderão ser carregados em tempdb (que é minimamente registrado).
  • Para cenários analíticos, carregue em uma tabela columnstore clusterizada ou uma tabela com índices que usam compactação de dados. Isso reduz a taxa de log necessária. Essa técnica aumenta a utilização da CPU e somente é aplicável a conjuntos de dados que se beneficiam de índices columnstore clusterizados ou da compactação de dados.

Governança de espaço de armazenamento

Nas camadas de serviço Premium e Comercialmente Crítico, os dados do cliente, incluindo arquivos de dados, arquivos de log de transações e arquivos tempdb são armazenados no armazenamento SSD local do computador que hospeda o banco de dados ou o pool elástico. O armazenamento local SSD fornece alta IOPS e taxa de transferência e baixa latência de E/S. Além dos dados do cliente, o armazenamento local é usado para o sistema operacional, o software de gerenciamento, os dados de monitoramento e os logs, entre outros arquivos necessários à operação do sistema.

O tamanho do armazenamento local é finito e depende dos recursos de hardware, que determinam o limite máximo de armazenamento local ou o armazenamento local reservado para dados do cliente. Esse limite é definido para maximizar o armazenamento de dados do cliente, garantindo, ao mesmo tempo, a operação segura e confiável do sistema. Para localizar o valor máximo de armazenamento local para cada objetivo de serviço, consulte a documentação de limites de recursos para bancos de dados individuais e pools elásticos.

Você também pode encontrar esse valor e a quantidade de armazenamento local usado atualmente por um determinado banco de dados ou pool elástico, usando a seguinte consulta:

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();
Coluna Descrição
server_name Nome do servidor lógico
database_name Nome do banco de dados
slo_name Nome do objetivo de serviço, incluindo a geração de hardware
user_data_directory_space_quota_mb Armazenamento local máximo, em MB
user_data_directory_space_usage_mb Consumo de armazenamento local atual por arquivos de dados, arquivos de log de transações e arquivos tempdb, em MB. Atualizado a cada cinco minutos.

Essa consulta deve ser executada no banco de dados de usuário e não no banco de dados master. Para pools elásticos, a consulta pode ser executada em qualquer banco de dados no pool. Os valores relatados se aplicam a todo o pool.

Importante

Nas camadas de serviço Premium e Comercialmente Crítico, se a carga de trabalho tentar aumentar o consumo de armazenamento local combinado por arquivos de dados, arquivos de log de transações e arquivos tempdb no limite máximo de armazenamento local, ocorrerá um erro de espaço insuficiente. Isso acontecerá mesmo se o espaço usado em um arquivo de banco de dados não tiver alcançado o tamanho máximo do arquivo.

O armazenamento SSD local também é usado por bancos de dados em camadas de serviço diferentes de Premium e Comercialmente Crítico para o banco de dados tempdb e o cache RBPEX de Hiperescala. À medida que os bancos de dados são criados, excluídos, aumentados ou reduzidos em tamanho, o consumo de armazenamento local total em um computador flutua ao longo do tempo. Se o sistema detectar que o armazenamento local disponível em um computador está baixo e um banco de dados ou pool elástico estiver em risco de ficar sem espaço, ele moverá o banco de dados ou o pool elástico para um computador diferente com armazenamento local suficiente disponível.

Essa mudança ocorre de modo online, de forma semelhante a uma operação de dimensionamento de banco de dados, e tem um impactosemelhante, incluindo um failover curto (segundos) no final da operação. Esse failover encerra as conexões abertas e reverte as transações, potencialmente afetando os aplicativos que usam o banco de dados naquele momento.

Como todos os dados são copiados para um volume de armazenamento local em um computador diferente, mover bancos de dados maiores nas camadas de serviço Premium e Comercialmente Crítico pode exigir uma quantidade significativa de tempo. Durante esse tempo, se o consumo de espaço local por um banco de dados, pool elástico ou banco de dados tempdb aumentar rapidamente, o risco de ficar sem espaço aumenta. O sistema inicia a movimentação do banco de dados de forma balanceada para minimiza erros de espaço insuficiente e, ao mesmo tempo, evitar failovers desnecessários.

tempdb tamanhos

Os limites de tamanho do tempdb no Banco de Dados SQL do Azure dependem do modelo de compra e de implantação.

Para saber mais, revise os limites de tamanho do tempdb para:

Hardware disponível anteriormente

Esta seção inclui detalhes sobre o hardware disponível anteriormente.

  • 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 com suporte para obter uma variedade mais ampla de escalabilidade de vCore e armazenamento, rede acelerada, melhor desempenho de E/S e latência mínima. Para obter mais informações, confira O suporte terminou para hardware Gen 4 no Banco de Dados SQL do Azure.

Você pode usar o Azure Resource Graph Explorer para identificar todos os recursos do Banco de Dados SQL do Azure que atualmente usam hardware Gen4 ou pode marcar o hardware usado pelos recursos para um servidor lógico específico no portal do Azure.

Você deve ter pelo menos permissões read para o objeto ou grupo de objetos do Azure para ver os resultados no Azure Resource Graph Explorer.

Para usar o Resource Graph Explorer para identificar recursos do SQL do Azure que ainda estão usando hardware Gen4, siga estas etapas:

  1. Acesse o portal do Azure.

  2. Pesquise Resource graph na caixa de pesquisa e escolha o serviço Resource Graph Explorer nos resultados da pesquisa.

  3. Na janela de consulta, digite a seguinte consulta e selecione Executar Consulta:

    resources
| where type contains ('microsoft.sql/servers')
| where sku['family'] == "Gen4"

  4. O painel Resultados exibe todos os recursos implantados atualmente no Azure que estão usando o hardware Gen4.

    Captura de tela do Azure Resources Graph Explorer no portal do Azure mostrando os resultados da consulta para identificar o hardware gen4.

Para verificar o hardware usado pelos recursos de um servidor lógico específico no Azure, siga estas etapas:

  1. Acesse o portal do Azure.
  2. Pesquise SQL servers na caixa de pesquisa e escolha servidores SQL nos resultados da pesquisa para abrir a página de servidores SQL e exibir todos os servidores para a(s) assinatura(s) escolhida(s).
  3. Selecione o servidor de interesse para abrir a página Visão geral do servidor.
  4. Role a tela para baixo até os recursos disponíveis e verifique a coluna Tipo de preço para recursos que estão usando hardware gen4.

Captura de tela da página Visão geral de um servidor lógico no Azure, da página de visão geral selecionada e da gen4 realçada.

Para migrar recursos para hardware de série padrão, examine Alterar hardware.

Conteúdo relacionado