Explorar cenários de desempenho

Concluído

Para decidir como usar ferramentas e recursos de desempenho, é importante examinar o desempenho do SQL do Azure por meio de cenários.

Entender cenários comuns de desempenho

Uma técnica comum para solução de problemas de desempenho do SQL Server é examinar se um problema de desempenho está em execução (CPU alta) ou aguardando (aguardando um recurso). O diagrama a seguir mostra uma árvore de decisão para determinar se um problema de desempenho do SQL Server está em execução ou aguardando e como usar as ferramentas de desempenho para determinar a causa e a solução.

Primeiro, examine o uso geral dos recursos. Para uma implantação do SQL Server padrão, você pode usar ferramentas como o Monitor de Desempenho no Windows ou Linux. Para o SQL Azure, você pode usar os seguintes métodos:

• Portal do Azure/PowerShell/alertas

  O Azure Monitor tem métricas integradas para exibir o uso de recursos do SQL Azure. Você também pode configurar alertas para buscar condições de uso de recursos.

• sys.dm_db_resource_stats

  Para o Banco de Dados SQL do Azure, você pode examinar essa DMV para ver o uso de recursos de CPU, memória e E/S para a implantação do banco de dados. Essa DMV faz um instantâneo desses dados a cada 15 segundos.

• sys.server_resource_stats

  Essa DMV se comporta exatamente como sys.dm_db_resource_stats, mas é usada para ver o uso de recursos da Instância Gerenciada de SQL em termos de CPU, memória e E/S. Essa DMV também faz um instantâneo a cada 15 segundos.

• sys.dm_user_db_resource_governance

  Para o Banco de Dados SQL do Azure, este DMV retorna as definições reais de capacidade e de configuração usadas pelos mecanismos de governança de recursos no banco de dados atual ou no pool elástico.

• sys.dm_instance_resource_governance

  Para a Instância Gerenciada de SQL do Azure, esta DMV retorna informações semelhantes a sys.dm_user_db_resource_governance, mas da Instância Gerenciada do Banco de Dados SQL atual.

Em execução

Se você determinou que o problema é a alta utilização da CPU, trata-se de um cenário de execução. Um cenário de execução pode envolver consultas que consomem recursos por meio da compilação ou da execução. Use as seguintes ferramentas para análise adicional:

• Repositório de Consultas

  Use os relatórios de Recursos com maior consumo de recursos no SSMS, s exibições de catálogo do Repositório de Consultas ou a Análise de Desempenho de Consultas no portal do Azure (somente para o Banco de Dados SQL do Azure) para descobrir quais consultas estão consumindo a maioria dos recursos da CPU.

• sys.dm_exec_requests

  Use essa DMV no SQL Azure para ter um instantâneo do estado das consultas ativas. Procure consultas com o estado RUNNABLE e o tipo de espera SOS_SCHEDULER_YIELD para ver se você tem capacidade de CPU suficiente.

• sys.dm_exec_query_stats

  Essa DMV pode ser usada de maneira muito semelhante ao Repositório de Consultas para detectar as consultas com maior consumo de recursos. Ele só está disponível para planos de consulta armazenados em cache, enquanto o Repositório de Consultas fornece um registro histórico persistente de desempenho. Essa DMV também permite localizar o plano de consulta de uma consulta armazenada em cache.

• sys.dm_exec_procedure_stats

  Essa DMV fornece informações muito parecidas àquelas fornecidas por sys.dm_exec_query_stats, exceto pelo fato de que as informações de desempenho podem ser exibidas no nível do procedimento armazenado.

  Após determinar quais consultas estão consumindo mais recursos, talvez você precise examinar se tem recursos de CPU suficientes para sua carga de trabalho. Você pode depurar os planos de consulta com ferramentas como a criação de perfil de consulta leve, as instruções SET, o Repositório de Consultas ou o rastreamento de eventos estendidos.

Aguardando

Se o problema não parece ser o uso elevado de recursos da CPU, pode se tratar de um problema de desempenho relacionado à espera por um recurso. Cenários que envolvem a espera por recursos incluem:

• Esperas de E/S
• Esperas de bloqueio
• Tempos de espera de trava
• Limites de pool de buffers
• Concessões de memória
• Remoção do cache de planos

Para executar a análise em cenários de espera, você normalmente utiliza as seguintes ferramentas:

• sys.dm_os_wait_stats

  Use essa DMV para ver os principais tipos de espera para o banco de dados ou a instância. Ela pode orientar você quanto à próxima ação a ser adotada dependendo dos principais tipos de espera.

• sys.dm_exec_requests

  Use essa DMV para localizar tipos de espera específicos para consultas ativas e ver qual recurso elas estão aguardando. Poderia ser um cenário de bloqueio padrão com espera por bloqueios de outros usuários.

• sys.dm_os_waiting_tasks

  Você pode usar essa DMV para encontrar tipos de espera para uma tarefa específica para uma consulta específica que está em execução no momento, talvez para ver por que ela está demorando mais do que o normal. sys.dm_os_waiting_tasks contém as estatísticas de espera ao vivo que sys.dm_os_wait_stats agrega ao longo do tempo.

• Repositório de Consultas

  O Repositório de Consultas fornece relatórios e exibições do catálogo que mostram uma agregação das principais esperas para a execução do plano de consulta. É importante saber que uma espera de CPU é equivalente a um problema de execução.

Cenários específicos do SQL Azure

Alguns cenários de desempenho, tanto de execução quanto de espera, são específicos do SQL Azure. Entre eles, estão a governança de logs, os limites de trabalho, as esperas que ocorrem ao usar a camada de serviço Comercialmente Crítico e as esperas específicas de uma implantação da Hiperescala.

Governança de log

O SQL Azure pode usar a governança de taxa de log para impor limites de recursos quanto ao uso do log de transações. Essa imposição pode ser necessária para garantir os limites de recursos e atender ao SLA prometido. A governança de log pode ser vista nos seguintes tipos de espera:

• LOG_RATE_GOVERNOR: espera pelo Banco de dados SQL do Azure
• POOL_LOG_RATE_GOVERNOR: espera por Pools Elásticos
• INSTANCE_LOG_GOVERNOR: espera pela Instância Gerenciada de SQL do Azure
• HADR_THROTTLE_LOG_RATE*: espera pela latência de replicação geográfica e Comercialmente Crítica

Limites de trabalho

O SQL Server usa um pool de trabalho de threads, mas tem limites quanto ao número máximo de trabalhadores. Aplicativos com um grande número de usuários simultâneos podem ficar perto dos limites de trabalho impostos para o Banco de Dados SQL do Azure e a Instância Gerenciada SQL:

• O Banco de Dados SQL do Azure tem limites com base na camada de serviço e no tamanho. Se você ultrapassar esse limite, uma nova consulta receberá um erro.
• No momento, a Instância Gerenciada de SQL usa max worker threads, de modo que os trabalhos que ultrapassarem esse limite poderão apresentar esperas THREADPOOL.

Esperas do HADR Comercialmente Crítico

Se você usar uma camada de serviço Comercialmente Crítico, poderá ver inesperadamente os seguintes tipos de espera:

• HADR_SYNC_COMMIT
• HADR_DATABASE_FLOW_CONTROL
• HADR_THROTTLE_LOG_RATE_SEND_RECV

Embora essas esperas possam não deixar o aplicativo mais lento, talvez você não espere vê-las. Normalmente, elas são específicas do uso de um grupo de disponibilidade Always On. As camadas Comercialmente Crítico usam a tecnologia de grupo de disponibilidade para implementar os recursos de SLA e disponibilidade de uma camada de serviço Comercialmente Crítico, de modo que esses tipos de espera são esperados. Tempos de espera longos podem indicar um gargalo, como latência de E/S ou réplica atrasada.

Hiperescala

A arquitetura de Hiperescala pode levar a alguns tipos de espera exclusivos prefixados com RBIO (uma possível indicação de governança de log). Além disso, DMVs, visualizações de catálogo e eventos estendidos foram aprimorados para mostrar métricas de leituras do servidor de páginas.

No próximo exercício, você aprenderá a monitorar e a resolver um problema de desempenho no SQL do Azure usando as ferramentas e os conhecimentos adquiridos nesta unidade.