Anterior

Avançar

Monitorar e solucionar problemas de desempenho

Concluído

O monitoramento e a solução de problemas são elementos fundamentais para o fornecimento de um desempenho consistente. O SQL Azure tem as mesmas ferramentas e funcionalidades que o SQL Server para monitorar e solucionar problemas de desempenho, além de funcionalidades adicionais. Isso inclui recursos como as DMVs (exibições de gerenciamento dinâmico), os eventos estendidos e o Azure Monitor. Também é importante aprender a usar essas ferramentas e funcionalidades em diferentes cenários de desempenho com o SQL Azure. Esses cenários incluem alta utilização de CPU ou ao esperar por um recurso.

Ferramentas e funcionalidades para monitorar o desempenho

O SQL Azure fornece funcionalidades de monitoramento e solução de problemas no ecossistema do Azure, bem como ferramentas conhecidas que acompanham o SQL Server. As seções a seguir descrevem brevemente esses elementos.

Azure Monitor

O Azure Monitor faz parte do ecossistema do Azure, e o SQL Azure é integrado para dar suporte às métricas, aos alertas e aos logs do Azure. Você pode visualizar os dados do Azure Monitor no portal do Azure e os aplicativos podem acessá-los por meio de APIs ou dos Hubs de Eventos do Azure. De maneira bastante semelhante ao que ocorre com o Monitor de Desempenho do Windows, o Azure Monitor permite acessar métricas de uso de recursos do SQL do Azure sem usar as ferramentas do SQL Server.

DMVs (exibições de gerenciamento dinâmico)

O SQL do Azure fornece quase a mesma infraestrutura de DMV que o SQL Server, com algumas diferenças. As DMVs são cruciais para o monitoramento de desempenho, pois você pode ver os principais dados de desempenho do SQL Server usando consultas T-SQL padrão. Por exemplo, você pode ver informações como consultas ativas, uso de recursos, planos de consulta e tipos de espera de recurso. Você aprenderá mais detalhes sobre as DMVs com o SQL do Azure mais adiante nesta unidade.

Eventos estendidos

O SQL do Azure fornece quase a mesma infraestrutura de eventos estendidos que o SQL Server, com algumas diferenças. Os eventos estendidos permitem rastrear os principais eventos de execução no SQL Server, que alimenta o SQL Azure. Com relação ao desempenho, os Eventos Estendidos permitem que você rastreie a execução de consultas individuais. Você aprenderá mais detalhes sobre os eventos estendidos com o SQL do Azure mais adiante nesta unidade.

Criação de perfil de consulta leve

A criação de perfil leve é um método avançado para solucionar problemas de cenários que exigem a recuperação do plano de execução real para solicitações em andamento e consultas de alto valor. Devido à sua baixa sobrecarga, qualquer servidor que ainda não esteja vinculado à CPU pode executar criação de perfil leve continuamente e permitir que os profissionais de banco de dados acessem qualquer execução em andamento a qualquer momento; por exemplo, usando o Monitor de Atividade no SSMS (SQL Server Management Studio) ou consultando sys.dm_exec_query_profiles ou sys.dm_exec_query_statistics_xml diretamente.

Você pode usar a criação de perfil de consulta leve para examinar o plano de consulta e o estado de execução de uma consulta ativa. Trata-se de um recurso importante para depurar o desempenho de consulta das instruções enquanto elas estão em execução. Essa funcionalidade reduz o tempo necessário para solucionar problemas de desempenho, comparada ao uso de ferramentas como os eventos estendidos para rastrear o desempenho da consulta. Você pode acessar a criação de perfil de consulta leve por meio de DMVs e fica ativada por padrão para o SQL do Azure, assim como para o SQL Server 2019 e versões posteriores.

Funcionalidades de depuração do plano de consulta

Em algumas situações, você pode precisar de detalhes adicionais sobre o desempenho da consulta para uma instrução T-SQL individual. Instruções T-SQL do tipo SET, como SHOWPLAN e STATISTICS, podem fornecer esses detalhes e têm suporte completo no SQL Azure, assim como ocorre com o SQL Server.

Repositório de Consultas

O Repositório de Consultas é um registro histórico da execução de desempenho das consultas armazenadas no banco de dados de usuário. O Repositório de Consultas fica ativado por padrão para o SQL Azure e é usado para fornecer funcionalidades como a correção automática de plano e o ajuste automático. Relatórios do SSMS (SQL Server Management Studio) sobre o repositório estão disponíveis para o SQL Azure. Use-os para detectar as consultas que consomem mais recursos, incluindo diferenças com relação ao plano de consulta, e os principais tipos de espera ao examinar cenários de espera de recursos.

Visualizações de desempenho

Para o Banco de Dados SQL do Azure, você pode ver informações de desempenho do Repositório de Consultas integradas no portal do Azure por meio das visualizações. Dessa forma, você pode ver algumas das mesmas informações no Repositório de Consultas que veria com uma ferramenta de cliente como o SSMS. Use as opções Visão Geral de Desempenho e Análise de Desempenho de Consultas no portal do Azure.

Detalhes da DMV

As DMVs são um elemento muito importante do monitoramento e da solução de problemas de desempenho há muitos anos no SQL Server. DMVs comuns do SQL Server estão disponíveis no SQL Azure, bem como algumas adicionais específicas do Azure.

Instância Gerenciada de SQL do Azure

Todas as DMVs do SQL Server estão disponíveis para a Instância Gerenciada de SQL. As principais DMVs como sys.dm_exec_requests e sys.dm_os_wait_stats são comumente usadas para examinar o desempenho da consulta.

O modo de exibição do sistema sys.server_resource_stats é específico da Instância Gerenciada de SQL do Azure e mostra o histórico do uso de recursos. Trata-se de uma ferramenta valiosa para ver o uso de recursos, pois você não tem acesso direto a ferramentas do sistema operacional como o Monitor de Desempenho.

Banco de Dados SQL do Azure

A maioria das DMVs comuns que você precisa para desempenho, incluindo sys.dm_exec_requests e sys.dm_os_wait_stats, estão disponíveis. Observe que essas DMVs fornecem apenas informações específicas do banco de dados, e não informações de todos os bancos de dados de um servidor lógico.

A DMV sys.dm_db_resource_stats é específica do Banco de Dados SQL do Azure e você pode usá-la para exibir um histórico do uso de recursos do banco de dados. Use-a de maneira semelhante a como usaria sys.server_resource_stats para uma instância gerenciada.

A DMV sys.elastic_pool_resource_stats é semelhante ao sys.dm_db_resource_stats, mas você pode usá-la para exibir o uso de recursos de bancos de dados de pool elástico.

DMVs de que você precisa

Você precisará das seguintes DMVs para resolver determinados cenários de desempenho no SQL Azure:

• sys.dm_io_virtual_file_stats é importante porque você não tem acesso direto às métricas do sistema operacional relacionadas ao desempenho de E/S por arquivo.
• sys.dm_os_performance_counters está disponível para o Banco de Dados SQL do Azure e para a Instância Gerenciada de SQL para a visualização de métricas de desempenho comuns do SQL Server. Use essa DMV para exibir informações do contador de desempenho do SQL Server que normalmente ficam disponíveis no Monitor de Desempenho.
• sys.dm_instance_resource_governance permite exibir os limites de recursos de uma instância gerenciada. Você pode exibir essas informações para ver quais devem ser os limites de recursos esperados sem usar o portal do Azure.
• sys.dm_user_db_resource_governance permite ver os limites de recursos comuns de acordo segundo a opção de implantação, a camada de serviço e o tamanho da implantação do Banco de Dados SQL do Azure. Você pode exibir essas informações para ver quais devem ser os limites de recursos esperados sem usar o portal do Azure.

DMVs para insights mais profundos

Essas DMVs fornecem insights mais profundos sobre os limites de recursos e a governança de recursos do SQL Azure. Elas não são destinadas a cenários comuns, mas podem ser úteis ao examinar profundamente problemas complexos de desempenho. Confira a documentação para conhecer todos os detalhes destas DMVs:

• sys.dm_user_db_resource_governance_internal (apenas na Instância Gerenciada de SQL)
• sys.dm_resource_governor_resource_pools_history_ex
• sys.dm_resource_governor_workload_groups_history_ex

Detalhes dos eventos estendidos

O recurso de eventos estendidos é o mecanismo de rastreamento do SQL Server. Os Eventos estendidos do SQL do Azure se baseiam no mecanismo do SQL Server e, portanto, são quase iguais no SQL do Azure, com algumas diferenças notáveis. As seções a seguir abordam essas diferenças.

Eventos estendidos para o Banco de Dados SQL do Azure

Você pode usar os eventos estendidos no Banco de Dados SQL do Azure da mesma forma que no SQL Server, criando sessões e usando eventos, ações e destinos. Lembre-se destes aspectos importantes ao criar sessões de evento estendido:

• Há suporte para os eventos e as ações usadas com mais frequência.
• Há suporte para destinos de contador, ring_buffer e arquivo.
• Os destinos de arquivo têm suporte no Armazenamento de Blobs do Azure porque você não tem acesso aos discos do sistema operacional subjacente.

Você pode usar o SSMS ou o T-SQL para criar e iniciar sessões. Você pode usar o SSMS para exibir os dados de destino da sessão de evento estendido ou a função do sistema sys.fn_xe_file_target_read_file.

Observação

Não é possível usar o SSMS para exibir os dados ativos do Banco de Dados SQL do Azure.

É importante saber que os eventos estendidos acionados para suas sessões são específicos de seu banco de dados e não se aplicam a todo o servidor lógico.

Eventos estendidos para a Instância Gerenciada de SQL do Azure

Você pode usar eventos estendidos na Instância Gerenciada de SQL do Azure, assim como são usados no SQL Server, criando sessões e usando eventos, ações e destinos. Lembre-se destes aspectos importantes ao criar sessões de evento estendido:

• Todos os eventos, destinos e ações têm suporte.
• Os destinos de arquivo têm suporte no Armazenamento de Blobs do Azure porque você não tem acesso aos discos do sistema operacional subjacente.
• Foram adicionados alguns eventos específicos à Instância Gerenciada de SQL para rastrear eventos específicos do gerenciamento e da execução da instância.

Você pode usar o SSMS ou o T-SQL para criar e iniciar sessões. Você pode usar o SSMS para exibir os dados de destino da sessão de evento estendido ou a função do sistema sys.fn_xe_file_target_read_file. A capacidade do SSMS de exibir dados dinâmicos tem suporte no SQL Server e na Instância Gerenciada de SQL.

Cenários de desempenho do SQL Azure

Para decidir como aplicar as funcionalidades e as ferramentas de monitoramento e de solução de problemas de desempenho, é importante examinar o desempenho do SQL Azure em alguns cenários.

Cenários de desempenho comuns

Uma técnica comum de solução de problemas de desempenho do SQL Server é examinar se um problema de desempenho está Executando (alto uso da CPU) 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.

Vamos nos aprofundar mais nos detalhes de cada aspecto do diagrama.

Executando versus aguardando

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.

Executando

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. No entanto, lembre-se de que ela está disponível apenas para planos de consulta armazenados em cache, enquanto o Repositório de Consultas fornece um registro histórico de desempenho persistente. 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 de uma consulta específica que está sendo executada no momento, talvez para saber 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.

Dica

Você pode usar os eventos estendidos para qualquer cenário de execução ou de espera. Para fazer isso, é necessário configurar uma sessão de eventos estendidos para rastrear consultas. Esse método para depurar um problema de desempenho é mais avançado e pode retornar muitas informações em troca de mais sobrecarga de desempenho do que as DMVs.

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. Observe que tempos de espera longos podem indicar um gargalo, por exemplo, latência de E/S ou réplica.

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, as DMVs, as exibições de catálogo e os eventos estendidos foram aprimorados para mostrar métricas de leituras do servidor de página.

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.

Continuar