Solucionar problemas de desempenho com o Intelligent Insights - Banco de Dados SQL do Azure & Instância Gerenciada SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure Instância Gerenciada SQLdo Azure

Esta página fornece informações sobre o Banco de Dados SQL do Azure e os problemas de desempenho da Instância Gerenciada SQL do Azure detetados por meio do log de recursos do Intelligent Insights . As métricas e os logs de recursos podem ser transmitidos para logs do Azure Monitor, Hubs de Eventos do Azure, Armazenamento do Azure ou uma solução de terceiros para recursos personalizados de alertas e relatórios de DevOps.

Nota

Para obter um guia rápido de solução de problemas de desempenho usando o Intelligent Insights, consulte o fluxograma de solução de problemas recomendado neste documento.

O Intelligent Insights é um recurso de visualização, não disponível nas seguintes regiões: Europa Ocidental, Europa do Norte, Oeste dos EUA 1 e Leste dos EUA 1.

Padrões de desempenho detetáveis do banco de dados

O Intelligent Insights deteta automaticamente problemas de desempenho com base em tempos de espera de execução de consultas, erros ou tempos limites. As saídas do Intelligent Insights detetaram padrões de desempenho no log de recursos. Os padrões de desempenho detetáveis são resumidos na tabela abaixo.

Padrões de desempenho detetáveis	Base de Dados SQL do Azure	Instância Gerida do Azure SQL
Atingir os limites de recursos	O consumo de recursos disponíveis (DTUs), threads de trabalho de banco de dados ou sessões de logon de banco de dados disponíveis na assinatura monitorada atingiu seus limites de recursos. Isso está afetando o desempenho.	O consumo de recursos da CPU está a atingir os seus limites de recursos. Isso está afetando o desempenho do banco de dados.
Aumento da carga de trabalho	Foi detetado aumento da carga de trabalho ou acumulação contínua de carga de trabalho na base de dados. Isso está afetando o desempenho.	Foi detetado um aumento da carga de trabalho. Isso está afetando o desempenho do banco de dados.
Pressão da memória	Os trabalhadores que solicitaram concessões de memória têm que esperar por alocações de memória por quantidades estatisticamente significativas de tempo, ou existe um acúmulo maior de trabalhadores que solicitaram concessões de memória. Isso está afetando o desempenho.	Os trabalhadores que solicitaram concessões de memória estão aguardando alocações de memória por uma quantidade estatisticamente significativa de tempo. Isso está afetando o desempenho do banco de dados.
Bloqueio	O bloqueio excessivo do banco de dados foi detetado afetando o desempenho.	Foi detetado um bloqueio excessivo do banco de dados que afeta o desempenho do banco de dados.
Aumento do MAXDOP	A opção de grau máximo de paralelismo (MAXDOP) foi alterada afetando a eficiência de execução da consulta. Isso está afetando o desempenho.	A opção de grau máximo de paralelismo (MAXDOP) foi alterada afetando a eficiência de execução da consulta. Isso está afetando o desempenho.
Contenção Pagelatch	Vários threads estão simultaneamente tentando acessar as mesmas páginas de buffer de dados na memória, resultando em tempos de espera maiores e causando contenção de pagelatch. Isso está afetando o desempenho.	Vários threads estão simultaneamente tentando acessar as mesmas páginas de buffer de dados na memória, resultando em tempos de espera maiores e causando contenção de pagelatch. Isso está afetando o desempenho do banco de dados.
Índice em falta	Foi detetado um índice em falta que afeta o desempenho.	O índice ausente foi detetado afetando o desempenho do banco de dados.
Nova consulta	Nova consulta foi detetada afetando o desempenho geral.	Nova consulta foi detetada afetando o desempenho geral do banco de dados.
Aumento da estatística de espera	Foram detetados tempos de espera mais elevados na base de dados, afetando o desempenho.	Foram detetados tempos de espera aumentados no banco de dados, afetando o desempenho do banco de dados.
Contenção do TempDB	Vários threads estão tentando acessar o mesmo tempdb recurso, causando um afunilamento. Isso está afetando o desempenho.	Vários threads estão tentando acessar o mesmo tempdb recurso, causando um afunilamento. Isso está afetando o desempenho do banco de dados.
Escassez de DTU de piscina elástica	A escassez de eDTUs disponíveis no pool elástico está afetando o desempenho.	Não está disponível para a Instância Gerenciada SQL do Azure, pois usa o modelo vCore.
Regressão do plano	Foi detetado um novo plano ou uma alteração na carga de trabalho de um plano existente. Isso está afetando o desempenho.	Foi detetado um novo plano ou uma alteração na carga de trabalho de um plano existente. Isso está afetando o desempenho do banco de dados.
Alteração do valor de configuração do escopo do banco de dados	A alteração de configuração no banco de dados foi detetada afetando o desempenho do banco de dados.	A alteração de configuração no banco de dados foi detetada afetando o desempenho do banco de dados.
Cliente lento	O cliente de aplicativo lento não consegue consumir a saída do banco de dados com rapidez suficiente. Isso está afetando o desempenho.	O cliente de aplicativo lento não consegue consumir a saída do banco de dados com rapidez suficiente. Isso está afetando o desempenho do banco de dados.
Downgrade da camada de preços	A ação de downgrade da camada de preços diminuiu os recursos disponíveis. Isso está afetando o desempenho.	A ação de downgrade da camada de preços diminuiu os recursos disponíveis. Isso está afetando o desempenho do banco de dados.

Gorjeta

Para a otimização contínua do desempenho dos bancos de dados, habilite o ajuste automático. Esse recurso de inteligência integrado monitora continuamente seu banco de dados, ajusta automaticamente os índices e aplica correções do plano de execução de consultas.

A seção a seguir descreve padrões de desempenho detetáveis com mais detalhes.

Atingir os limites de recursos

O que é que está a acontecer

Esse padrão de desempenho detetável combina problemas de desempenho relacionados ao alcance dos limites de recursos disponíveis, limites de trabalho e limites de sessão. Depois que esse problema de desempenho é detetado, um campo de descrição do log de diagnóstico indica se o problema de desempenho está relacionado a limites de recursos, trabalhadores ou sessão.

Os recursos na Base de Dados SQL do Azure são normalmente referidos como recursos DTU ou vCore, e os recursos na Instância Gerida SQL do Azure são referidos como recursos vCore. O padrão de atingir os limites de recursos é reconhecido quando a degradação do desempenho da consulta detetada é causada pelo alcance de qualquer um dos limites de recursos medidos.

O recurso de limites de sessão indica o número de logins simultâneos disponíveis no banco de dados. Esse padrão de desempenho é reconhecido quando os aplicativos conectados aos bancos de dados atingem o número de logons simultâneos disponíveis no banco de dados. Se os aplicativos tentarem usar mais sessões do que as disponíveis em um banco de dados, o desempenho da consulta será afetado.

Atingir os limites de trabalhadores é um caso específico de atingir limites de recursos porque os trabalhadores disponíveis não são contados no uso de DTU ou vCore. Atingir os limites de trabalho em um banco de dados pode causar o aumento dos tempos de espera específicos de recursos, o que resulta em degradação do desempenho da consulta.

Resolução de Problemas

O registo de diagnóstico apresenta os hashes das consultas que afetaram o desempenho e as percentagens de consumo dos recursos. Você pode usar essas informações como um ponto de partida para otimizar a carga de trabalho do banco de dados. Em particular, você pode otimizar as consultas que afetam a degradação do desempenho adicionando índices. Ou você pode otimizar aplicativos com uma distribuição de carga de trabalho mais uniforme. Se você não conseguir reduzir cargas de trabalho ou fazer otimizações, considere aumentar a camada de preços da sua assinatura de banco de dados para aumentar a quantidade de recursos disponíveis.

Se você atingiu os limites de sessão disponíveis, você pode otimizar seus aplicativos reduzindo o número de logins feitos no banco de dados. Se você não conseguir reduzir o número de logins de seus aplicativos para o banco de dados, considere aumentar a camada de preços da sua assinatura de banco de dados. Ou você pode dividir e mover seu banco de dados em vários bancos de dados para uma distribuição de carga de trabalho mais equilibrada.

Para obter mais sugestões sobre como resolver limites de sessão, consulte Como lidar com os limites de logins máximos. Consulte Visão geral dos limites de recursos em um servidor para obter informações sobre limites nos níveis de servidor e assinatura.

Aumento da carga de trabalho

O que é que está a acontecer

Esse padrão de desempenho identifica problemas causados por um aumento da carga de trabalho ou, em sua forma mais grave, um acúmulo de carga de trabalho.

Esta deteção é feita através de uma combinação de várias métricas. A métrica básica medida está detetando um aumento na carga de trabalho em comparação com a linha de base da carga de trabalho anterior. A outra forma de deteção baseia-se na medição de um grande aumento de threads de trabalho ativos que é grande o suficiente para afetar o desempenho da consulta.

Em sua forma mais grave, a carga de trabalho pode se acumular continuamente devido à incapacidade de um banco de dados para lidar com a carga de trabalho. O resultado é um tamanho de carga de trabalho continuamente crescente, que é a condição de acumulação de carga de trabalho. Devido a essa condição, o tempo que a carga de trabalho aguarda pela execução cresce. Essa condição representa um dos problemas mais graves de desempenho do banco de dados. Esse problema é detetado através do monitoramento do aumento no número de threads de trabalho abortados.

Resolução de Problemas

O registo de diagnóstico apresenta o número de consultas cuja execução aumentou e o hash da consulta com a maior contribuição para o aumento da carga de trabalho. Você pode usar essas informações como um ponto de partida para otimizar a carga de trabalho. A consulta identificada como o maior contribuinte para o aumento da carga de trabalho é especialmente útil como ponto de partida.

Você pode considerar distribuir as cargas de trabalho de forma mais uniforme para o banco de dados. Considere otimizar a consulta que está afetando o desempenho adicionando índices. Você também pode distribuir sua carga de trabalho entre vários bancos de dados. Se essas soluções não forem possíveis, considere aumentar a camada de preços da sua assinatura de banco de dados para aumentar a quantidade de recursos disponíveis.

Pressão da memória

O que é que está a acontecer

Esse padrão de desempenho indica degradação no desempenho atual do banco de dados causada pela pressão da memória ou, em sua forma mais grave, uma condição de acúmulo de memória, em comparação com a linha de base de desempenho dos últimos sete dias.

A pressão de memória denota uma condição de desempenho na qual há um grande número de threads de trabalho solicitando concessões de memória. O alto volume causa uma condição de alta utilização de memória na qual o banco de dados não consegue alocar memória de forma eficiente para todos os trabalhadores que a solicitam. Uma das razões mais comuns para esse problema está relacionada à quantidade de memória disponível para o banco de dados, por um lado. Por outro lado, um aumento na carga de trabalho causa o aumento nos threads de trabalho e na pressão de memória.

A forma mais grave de pressão de memória é a condição de acumulação de memória. Essa condição indica que um número maior de threads de trabalho está solicitando concessões de memória do que há consultas liberando a memória. Esse número de threads de trabalho solicitando concessões de memória também pode estar aumentando continuamente (se acumulando) porque o mecanismo de banco de dados não consegue alocar memória de forma eficiente o suficiente para atender à demanda. A condição de acúmulo de memória representa um dos problemas mais graves de desempenho do banco de dados.

Resolução de Problemas

O log de diagnóstico produz os detalhes do armazenamento do objeto de memória com o funcionário (ou seja, thread de trabalho) marcado como o motivo mais alto para o alto uso de memória e carimbos de data/hora relevantes. Você pode usar essas informações como base para a solução de problemas.

Você pode otimizar ou remover consultas relacionadas aos funcionários com maior uso de memória. Também pode certificar-se de que não está a consultar dados que não planeia utilizar. Uma boa prática é sempre usar uma cláusula WHERE em suas consultas. Além disso, recomendamos que você crie índices não clusterizados para buscar os dados em vez de examiná-los.

Você também pode reduzir a carga de trabalho otimizando-a ou distribuindo-a em vários bancos de dados. Ou você pode distribuir sua carga de trabalho entre vários bancos de dados. Se essas soluções não forem possíveis, considere aumentar a camada de preços do seu banco de dados para aumentar a quantidade de recursos de memória disponíveis para o banco de dados.

Para obter sugestões adicionais de solução de problemas, consulte Memória concede meditação: o misterioso consumidor de memória do SQL Server com muitos nomes. Para obter mais informações sobre erros de falta de memória no Banco de Dados SQL do Azure, consulte Solucionar problemas de erros de falta de memória com o Banco de Dados SQL do Azure.

Bloqueio

O que é que está a acontecer

Esse padrão de desempenho indica degradação no desempenho atual do banco de dados no qual o bloqueio excessivo do banco de dados é detetado em comparação com a linha de base de desempenho dos últimos sete dias.

No RDBMS moderno, o bloqueio é essencial para a implementação de sistemas multithreaded nos quais o desempenho é maximizado pela execução de vários trabalhadores simultâneos e transações paralelas de banco de dados, sempre que possível. O bloqueio neste contexto refere-se ao mecanismo de acesso interno no qual apenas uma única transação pode acessar exclusivamente as linhas, páginas, tabelas e arquivos necessários e não competir com outra transação por recursos. Quando a transação que bloqueou os recursos para uso é feita com eles, o bloqueio desses recursos é liberado, o que permite que outras transações acessem os recursos necessários. Para obter mais informações sobre bloqueio, consulte Bloquear no mecanismo de banco de dados.

Se as transações executadas pelo mecanismo SQL estiverem aguardando por longos períodos de tempo para acessar recursos bloqueados para uso, esse tempo de espera causará a lentidão do desempenho de execução da carga de trabalho.

Resolução de Problemas

O log de diagnóstico gera detalhes de bloqueio que você pode usar como base para a solução de problemas. Você pode analisar as consultas de bloqueio relatadas, ou seja, as consultas que introduzem a degradação do desempenho de bloqueio, e removê-las. Em alguns casos, você pode ser bem-sucedido na otimização das consultas de bloqueio.

A maneira mais simples e segura de mitigar o problema é manter as transações curtas e reduzir a pegada de bloqueio das consultas mais caras. Você pode dividir um grande lote de operações em operações menores. Uma boa prática é reduzir a pegada de bloqueio de consulta, tornando a consulta o mais eficiente possível. Reduza verificações grandes porque elas aumentam as chances de bloqueios e afetam negativamente o desempenho geral do banco de dados. Para consultas identificadas que causam bloqueio, você pode criar novos índices ou adicionar colunas ao índice existente para evitar as verificações de tabela.

Para mais sugestões, consulte:

• Compreender e resolver problemas de bloqueio do Azure SQL
• Como resolver problemas de bloqueio causados pelo escalonamento de bloqueio no SQL Server

Aumento do MAXDOP

O que é que está a acontecer

Esse padrão de desempenho detetável indica uma condição na qual um plano de execução de consulta escolhido foi paralelizado mais do que deveria. O otimizador de consulta pode melhorar o desempenho da carga de trabalho executando consultas em paralelo para acelerar as coisas sempre que possível. Em alguns casos, os trabalhadores paralelos que processam uma consulta passam mais tempo esperando uns nos outros para sincronizar e mesclar resultados em comparação com a execução da mesma consulta com menos trabalhadores paralelos ou até mesmo, em alguns casos, em comparação com um único thread de trabalho.

O sistema especializado analisa o desempenho atual do banco de dados em comparação com o período de linha de base. Ele determina se uma consulta em execução anterior está sendo executada mais lentamente do que antes, porque o plano de execução da consulta é mais paralelizado do que deveria.

A opção de configuração do servidor MAXDOP é usada para controlar quantos núcleos de CPU podem ser usados para executar a mesma consulta em paralelo.

Resolução de Problemas

O registo de diagnóstico apresenta os hashes de consulta relacionados com as consultas cuja duração da execução aumentou devido a estarem em paralelo mais do que deveriam. O log também gera tempos de espera CXP. Esse tempo representa o tempo que um único thread organizador/coordenador (thread 0) está aguardando a conclusão de todos os outros threads antes de mesclar os resultados e seguir em frente. Além disso, o log de diagnóstico gera os tempos de espera que as consultas de baixo desempenho estavam aguardando na execução geral. Você pode usar essas informações como base para a solução de problemas.

Primeiro, otimize ou simplifique consultas complexas. Uma boa prática consiste em dividir os trabalhos em lotes longos em trabalhos mais pequenos. Além disso, certifique-se de criar índices para dar suporte às suas consultas. Você também pode impor manualmente o grau máximo de paralelismo (MAXDOP) para uma consulta que foi sinalizada como de baixo desempenho. Para configurar essa operação usando T-SQL, consulte Configurar a opção de configuração do servidor MAXDOP.

Definir a opção de configuração do servidor MAXDOP como zero (0) como um valor padrão indica que o banco de dados pode usar todos os núcleos de CPU disponíveis para paralelizar threads para executar uma única consulta. Definir MAXDOP como um (1) indica que apenas um núcleo pode ser usado para uma única execução de consulta. Em termos práticos, isto significa que o paralelismo está desligado. Dependendo da base caso a caso, dos núcleos disponíveis para o banco de dados e das informações de log de diagnóstico, você pode ajustar a opção MAXDOP ao número de núcleos usados para a execução de consultas paralelas que podem resolver o problema no seu caso.

Contenção Pagelatch

O que é que está a acontecer

Esse padrão de desempenho indica a degradação atual do desempenho da carga de trabalho do banco de dados devido à contenção de pagelatch em comparação com a linha de base da carga de trabalho dos últimos sete dias.

As travas são mecanismos de sincronização leves usados para habilitar o multithreading. Eles garantem a consistência de estruturas na memória que incluem índices, páginas de dados e outras estruturas internas.

Existem muitos tipos de fechos disponíveis. Para fins de simplicidade, as travas de buffer são usadas para proteger páginas na memória no pool de buffers. As travas de E/S são usadas para proteger páginas ainda não carregadas no pool de buffers. Sempre que os dados são gravados ou lidos de uma página no pool de buffers, um thread de trabalho precisa adquirir uma trava de buffer para a página primeiro. Sempre que um thread de trabalho tenta acessar uma página que ainda não está disponível no pool de buffers na memória, uma solicitação de E/S é feita para carregar as informações necessárias do armazenamento. Esta sequência de eventos indica uma forma mais grave de degradação do desempenho.

A contenção nas travas de página ocorre quando vários threads simultaneamente tentam adquirir travas na mesma estrutura na memória, o que introduz um maior tempo de espera para a execução da consulta. No caso da contenção de E/S pagelatch, quando os dados precisam ser acessados a partir do armazenamento, esse tempo de espera é ainda maior. Pode afetar consideravelmente o desempenho da carga de trabalho. A contenção Pagelatch é o cenário mais comum de threads esperando uns nos outros e competindo por recursos em vários sistemas de CPU.

Resolução de Problemas

O log de diagnóstico produz detalhes de contenção de pagelatch. Você pode usar essas informações como base para a solução de problemas.

Como um pagelatch é um mecanismo de controle interno, ele determina automaticamente quando usá-los. As decisões de aplicativos, incluindo o design do esquema, podem afetar o comportamento do pagelatch devido ao comportamento determinístico das travas.

Um método para lidar com a contenção de trava é substituir uma chave de índice sequencial por uma chave não sequencial para distribuir uniformemente as inserções em um intervalo de índice. Normalmente, uma coluna à esquerda no índice distribui a carga de trabalho proporcionalmente. Outro método a considerar é o particionamento de tabelas. Criar um esquema de criação de partições hash com uma coluna calculada numa tabela particionada é uma abordagem comum para mitigação da contenção excessiva do bloqueio temporário. No caso da contenção de E/S pagelatch, a introdução de índices ajuda a mitigar esse problema de desempenho.

Para obter mais informações, consulte Diagnosticar e resolver a contenção de trava no SQL Server (download de PDF).

Índice em falta

O que é que está a acontecer

Esse padrão de desempenho indica a degradação atual do desempenho da carga de trabalho do banco de dados em comparação com a linha de base dos últimos sete dias devido a um índice ausente.

Um índice é usado para acelerar o desempenho das consultas. Ele fornece acesso rápido aos dados da tabela, reduzindo o número de páginas do conjunto de dados que precisam ser visitadas ou verificadas.

Consultas específicas que causaram degradação do desempenho são identificadas por meio dessa deteção, para as quais a criação de índices seria benéfica para o desempenho.

Resolução de Problemas

O registo de diagnósticos apresenta os hashes das consultas que foram identificadas como consultas que afetam o desempenho da carga de trabalho. Você pode criar índices para essas consultas. Você também pode otimizar ou remover essas consultas se elas não forem necessárias. Uma boa prática de desempenho é evitar consultar dados que você não usa.

Gorjeta

Você sabia que a inteligência integrada pode gerenciar automaticamente os índices de melhor desempenho para seus bancos de dados?

Para otimização contínua do desempenho, recomendamos que você habilite o ajuste automático. Este recurso exclusivo de inteligência integrado monitora continuamente seu banco de dados e ajusta e cria índices automaticamente para seus bancos de dados.

Nova consulta

O que é que está a acontecer

Esse padrão de desempenho indica que uma nova consulta é detetada com desempenho insatisfatório e afetando o desempenho da carga de trabalho em comparação com a linha de base de desempenho de sete dias.

Escrever uma consulta de bom desempenho às vezes pode ser uma tarefa desafiadora. Para obter mais informações sobre como escrever consultas, consulte Escrevendo consultas SQL. Para otimizar o desempenho da consulta existente, consulte Ajuste de consulta.

Resolução de Problemas

O registo de diagnósticos apresenta as informações até às duas consultas de consumo de CPU mais recentes, incluindo os hashes das consultas. Como a consulta detetada afeta o desempenho da carga de trabalho, você pode otimizar sua consulta. Uma boa prática é recuperar apenas os dados que você precisa usar. Também recomendamos o uso de consultas com uma cláusula WHERE. Também recomendamos que você simplifique consultas complexas e as divida em consultas menores. Outra boa prática é dividir consultas de lote grande em consultas de lote menor. A introdução de índices para novas consultas geralmente é uma boa prática para mitigar esse problema de desempenho.

No Banco de Dados SQL do Azure, considere o uso do Query Performance Insight.

Aumento da estatística de espera

O que é que está a acontecer

Esse padrão de desempenho detetável indica uma degradação do desempenho da carga de trabalho na qual consultas de baixo desempenho são identificadas em comparação com a linha de base da carga de trabalho dos últimos sete dias.

Nesse caso, o sistema não pode classificar as consultas de baixo desempenho em nenhuma outra categoria de desempenho detetável padrão, mas detetou a estatística de espera responsável pela regressão. Portanto, considera-as como consultas com estatísticas de espera aumentadas, onde a estatística de espera responsável pela regressão também é exposta.

Resolução de Problemas

O registo de diagnóstico apresenta as informações sobre os detalhes do aumento do tempo de espera e os hashes das consultas afetadas.

Como o sistema não conseguiu identificar com êxito a causa raiz das consultas de baixo desempenho, as informações de diagnóstico são um bom ponto de partida para a solução manual de problemas. Você pode otimizar o desempenho dessas consultas. Uma boa prática é buscar apenas os dados que você precisa usar e simplificar e dividir consultas complexas em consultas menores.

Para obter mais informações sobre como otimizar o desempenho da consulta, consulte Ajuste de consulta.

Disputa da TempDB

O que é que está a acontecer

Esse padrão de desempenho detetável indica uma condição de desempenho do banco de dados na qual existe um afunilamento de threads tentando acessar tempdb recursos. (Esta condição não está relacionada com IO.) O cenário típico para esse problema de desempenho são centenas de consultas simultâneas que criam, usam e soltam tabelas pequenas tempdb . O sistema detetou que o número de consultas simultâneas usando as mesmas tempdb tabelas aumentou com significância estatística suficiente para afetar o desempenho do banco de dados em comparação com a linha de base de desempenho dos últimos sete dias.

Resolução de Problemas

O log de diagnóstico produz detalhes de tempdb contenção. Você pode usar as informações como ponto de partida para a solução de problemas. Há duas coisas que você pode buscar para aliviar esse tipo de contenção e aumentar a taxa de transferência da carga de trabalho geral: Você pode parar de usar as tabelas temporárias. Você também pode usar tabelas com otimização de memória.

Para obter mais informações, consulte Introdução às tabelas com otimização de memória.

Escassez de DTU de piscina elástica

O que é que está a acontecer

Esse padrão de desempenho detetável indica uma degradação no desempenho atual da carga de trabalho do banco de dados em comparação com a linha de base dos últimos sete dias. Isso se deve à escassez de DTUs disponíveis no pool elástico da sua assinatura.

Os recursos do pool elástico do Azure são usados como um pool de recursos disponíveis compartilhados entre vários bancos de dados para fins de dimensionamento. Quando os recursos de eDTU disponíveis em seu pool elástico não são suficientemente grandes para suportar todos os bancos de dados no pool, um problema de desempenho de falta de DTU do pool elástico é detetado pelo sistema.

Resolução de Problemas

O log de diagnóstico produz informações no pool elástico, lista os principais bancos de dados que consomem DTU e fornece uma porcentagem da DTU do pool usada pelo banco de dados que mais consome.

Como essa condição de desempenho está relacionada a vários bancos de dados que usam o mesmo pool de eDTUs no pool elástico, as etapas de solução de problemas se concentram nos principais bancos de dados que consomem DTU. Você pode reduzir a carga de trabalho nos bancos de dados que consomem mais, o que inclui a otimização das consultas que consomem mais nesses bancos de dados. Você também pode garantir que não está consultando dados que não usa. Outra abordagem é otimizar aplicativos usando os principais bancos de dados que consomem DTU e redistribuir a carga de trabalho entre vários bancos de dados.

Se a redução e a otimização da carga de trabalho atual em seus principais bancos de dados que consomem DTU não forem possíveis, considere aumentar o nível de preço do pool elástico. Tal aumento resulta no aumento das DTUs disponíveis no pool elástico.

Regressão do plano

O que é que está a acontecer

Esse padrão de desempenho detetável denota uma condição na qual o banco de dados utiliza um plano de execução de consulta subótimo. O plano subótimo normalmente causa maior execução de consultas, o que leva a tempos de espera mais longos para as consultas atuais e outras.

O mecanismo de banco de dados determina o plano de execução da consulta com o menor custo para a execução de uma consulta. À medida que o tipo de consultas e cargas de trabalho mudam, às vezes os planos existentes não são mais eficientes, ou talvez o mecanismo de banco de dados não tenha feito uma boa avaliação. Por uma questão de correção, os planos de execução de consultas podem ser forçados manualmente.

Esse padrão de desempenho detetável combina três casos diferentes de regressão de plano: regressão de novo plano, regressão de plano antigo e carga de trabalho alterada de planos existentes. O tipo específico de regressão de plano que ocorreu é fornecido na propriedade details no log de diagnóstico.

A nova condição de regressão de plano refere-se a um estado no qual o mecanismo de banco de dados começa a executar um novo plano de execução de consulta que não é tão eficiente quanto o plano antigo. A condição de regressão do plano antigo refere-se ao estado quando o mecanismo de banco de dados muda do uso de um plano novo e mais eficiente para o plano antigo, que não é tão eficiente quanto o novo plano. A regressão da carga de trabalho alterada dos planos existentes refere-se ao estado em que os planos antigos e os novos se alternam continuamente, com o saldo indo mais para o plano de baixo desempenho.

Para obter mais informações sobre regressões de plano, consulte O que é regressão de plano no SQL Server?.

Resolução de Problemas

O registo de diagnóstico apresenta os hashes de consulta, o ID de plano bom, o ID de plano mau e os IDs das consultas. Você pode usar essas informações como base para a solução de problemas.

Pode analisar que plano tem o melhor desempenho para as consultas específicas que conseguiu identificar com os hashes de consulta disponibilizados. Depois de determinar qual plano funciona melhor para suas consultas, você pode forçá-lo manualmente.

Para obter mais informações, consulte Saiba como o SQL Server impede regressões de plano.

Gorjeta

Você sabia que o recurso de inteligência integrado pode gerenciar automaticamente os planos de execução de consultas com melhor desempenho para seus bancos de dados?

Para otimização contínua do desempenho, recomendamos que você habilite o ajuste automático. Este recurso de inteligência integrado monitora continuamente seu banco de dados e ajusta e cria automaticamente planos de execução de consultas com melhor desempenho para seus bancos de dados.

Alteração do valor de configuração do escopo do banco de dados

O que é que está a acontecer

Esse padrão de desempenho detetável indica uma condição na qual uma alteração na configuração do escopo do banco de dados causa regressão de desempenho que é detetada em comparação com o comportamento da carga de trabalho do banco de dados dos últimos sete dias. Esse padrão indica que uma alteração recente feita na configuração do escopo do banco de dados não parece ser benéfica para o desempenho do banco de dados.

As alterações de configuração do escopo do banco de dados podem ser definidas para cada banco de dados individual. Essa configuração é usada caso a caso para otimizar o desempenho individual do seu banco de dados. As seguintes opções podem ser configuradas para cada banco de dados individual: MAXDOP, LEGACY_CARDINALITY_ESTIMATION, PARAMETER_SNIFFING, QUERY_OPTIMIZER_HOTFIXES e CLEAR PROCEDURE_CACHE.

Resolução de Problemas

O log de diagnóstico gera alterações de configuração no escopo do banco de dados feitas recentemente que causaram degradação do desempenho em comparação com o comportamento anterior da carga de trabalho de sete dias. Você pode reverter as alterações de configuração para os valores anteriores. Você também pode ajustar valor por valor até que o nível de desempenho desejado seja atingido. Você pode copiar valores de configuração do escopo do banco de dados de um banco de dados semelhante com desempenho satisfatório. Se você não conseguir solucionar problemas de desempenho, reverta para os valores padrão e tente ajustar a partir dessa linha de base.

Para obter mais informações sobre como otimizar a configuração do escopo do banco de dados e a sintaxe do T-SQL ao alterar a configuração, consulte Alter database-scoped configuration (Transact-SQL).

Cliente lento

O que é que está a acontecer

Esse padrão de desempenho detetável indica uma condição na qual o cliente que usa o banco de dados não pode consumir a saída do banco de dados tão rápido quanto o banco de dados envia os resultados. Como o banco de dados não está armazenando resultados das consultas executadas em um buffer, ele fica mais lento e espera que o cliente consuma as saídas de consulta transmitidas antes de prosseguir. Essa condição também pode estar relacionada a uma rede que não é suficientemente rápida o suficiente para transmitir saídas do banco de dados para o cliente consumidor.

Essa condição é gerada somente se uma regressão de desempenho for detetada em comparação com o comportamento da carga de trabalho do banco de dados dos últimos sete dias. Esse problema de desempenho é detetado somente se ocorrer uma degradação estatisticamente significativa do desempenho em comparação com o comportamento de desempenho anterior.

Resolução de Problemas

Esse padrão de desempenho detetável indica uma condição do lado do cliente. A solução de problemas é necessária no aplicativo do lado do cliente ou na rede do lado do cliente. O registo de diagnóstico apresenta os hashes de consulta e os tempos de espera que parecem ter o maior tempo de espera de consumo pelo cliente nas últimas duas horas. Você pode usar essas informações como base para a solução de problemas.

Você pode otimizar o desempenho do seu aplicativo para o consumo dessas consultas. Você também pode considerar possíveis problemas de latência de rede. Como o problema de degradação do desempenho foi baseado na alteração na linha de base de desempenho dos últimos sete dias, você pode investigar se as alterações recentes no aplicativo ou na condição da rede causaram esse evento de regressão de desempenho.

Downgrade da camada de preços

O que é que está a acontecer

Esse padrão de desempenho detetável indica uma condição na qual a camada de preços da sua assinatura de banco de dados foi rebaixada. Devido à redução de recursos (DTUs) disponíveis para o banco de dados, o sistema detetou uma queda no desempenho atual do banco de dados em comparação com a linha de base dos últimos sete dias.

Além disso, pode haver uma condição na qual o nível de preço da sua assinatura de banco de dados seja rebaixado e, em seguida, atualizado para um nível mais alto em um curto período de tempo. A deteção dessa degradação temporária do desempenho é gerada na seção de detalhes do log de diagnóstico como um downgrade e upgrade da camada de preço.

Resolução de Problemas

Se você reduziu seu nível de preço e, portanto, as DTUs disponíveis, e está satisfeito com o desempenho, não há nada que você precise fazer. Se você reduziu o nível de preço e não está satisfeito com o desempenho do banco de dados, reduza as cargas de trabalho do banco de dados ou considere aumentar o nível de preço para um nível mais alto.

Fluxo de solução de problemas recomendado

Siga o fluxograma para obter uma abordagem recomendada para solucionar problemas de desempenho usando o Intelligent Insights.

Aceda ao Intelligent Insights através do portal do Azure acedendo ao Azure SQL Analytics. Tente localizar o alerta de desempenho de entrada e selecione-o. Identifique o que está acontecendo na página de deteções. Observe a análise de causa raiz fornecida do problema, o texto da consulta, as tendências de tempo de consulta e a evolução do incidente. Tente resolver o problema usando a recomendação do Intelligent Insights para atenuar o problema de desempenho.

Gorjeta

Selecione o fluxograma para baixar uma versão em PDF.

O Intelligent Insights geralmente precisa de uma hora de tempo para executar a análise da causa raiz do problema de desempenho. Se você não conseguir localizar seu problema no Intelligent Insights e ele for crítico para você, use o Repositório de Consultas para identificar manualmente a causa raiz do problema de desempenho. (Normalmente, esses problemas têm menos de uma hora.) Para obter mais informações, consulte Monitorar o desempenho usando o Repositório de Consultas.

Próximos passos

• Aprenda os conceitos do Intelligent Insights .
• Use o log de diagnóstico de desempenho do Intelligent Insights.
• Monitore usando o Azure SQL Analytics.
• Aprenda a coletar e consumir dados de log de seus recursos do Azure.