Anterior

Seguinte

Monitorizar e resolver problemas de desempenho

Concluído

A monitorização e a resolução de problemas são elementos fundamentais para ter um desempenho consistente. O SQL do Azure tem as mesmas ferramentas e funcionalidades que o SQL Server para monitorizar e resolver problemas de desempenho, além de capacidades adicionais. Isto inclui funcionalidades como as vistas de gestão dinâmicas (DMVs), os eventos expandidos e o Azure Monitor. Também é importante saber como utilizar estas ferramentas e capacidades em vários cenários de desempenho do SQL do Azure. Esses cenários incluem alta utilização da CPU ou aguardando um recurso.

Ferramentas e capacidades para monitorizar o desempenho

O SQL do Azure fornece capacidades de monitorização e resolução de problemas no ecossistema do Azure, além de ferramentas familiares incluídas no SQL Server. As secções que se seguem descrevem as mesmas de forma breve.

Azure Monitor

O Azure Monitor pertence ao ecossistema do Azure e o SQL do Azure está integrado de forma a suportar as métricas, alertas e registos do Azure. Você pode visualizar os dados do Azure Monitor no portal do Azure e os aplicativos podem acessar esses dados por meio de Hubs de Eventos ou APIs do Azure. Assim como o Monitor de Desempenho do Windows, o Azure Monitor ajuda você a acessar métricas de uso de recursos para o SQL do Azure sem usar ferramentas do SQL Server.

Visualizações de gerenciamento dinâmico (DMV)

O Azure SQL fornece quase a mesma infraestrutura DMV que o SQL Server, com algumas diferenças. As DMVs são cruciais para a monitorização do desempenho, uma vez que pode ver os principais dados de desempenho do SQL Server através das consultas do T-SQL padrão. Por exemplo, pode ver informações como as consultas ativas, a utilização de recursos, os planos de consulta e os tipos de espera de recursos. Você aprenderá mais detalhes sobre DMVs com o Azure SQL posteriormente nesta unidade.

Eventos expandidos

O SQL do Azure fornece quase a mesma infraestrutura de eventos estendida que o SQL Server, com algumas diferenças. Os eventos alargados permitem-lhe rastrear eventos-chave de execução no SQL Server que fazem parte do SQL do Azure. Para fins de desempenho, os eventos alargados permitem-lhe rastrear a execução de consultas individuais. Você aprenderá mais detalhes sobre eventos estendidos com o Azure SQL posteriormente nesta unidade.

Criação de perfis 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 voo e consultas de alto valor. Devido à sua baixa sobrecarga, qualquer servidor que ainda não esteja vinculado à CPU pode executar perfis leves continuamente e permitir que os profissionais de banco de dados aproveitem qualquer execução em execução a qualquer momento; por exemplo, usando o Monitor de Atividade no SQL Server Management Studio (SSMS) ou consultando sys.dm_exec_query_profiles diretamente ou sys.dm_exec_query_statistics_xml.

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 uma funcionalidade essencial para depurar o desempenho de consulta das instruções durante a respetiva execução. Esta capacidade reduz o tempo de resolução de problemas de desempenho em comparação com as ferramentas de eventos alargados utilizadas para rastrear o desempenho das consultas. Você pode acessar a criação de perfil de consulta leve por meio de DMVs, e ela está ativada por padrão para o SQL do Azure como é para o SQL Server 2019 e versões posteriores.

Funcionalidades de depuração do plano de consulta

Em algumas situações, poderá necessitar de detalhes adicionais sobre o desempenho de consulta de uma instrução T-SQL individual. As instruções SET do T-SQL, como SHOWPLAN e STATISTICS, podem fornecer esses detalhes e são totalmente suportadas pelo SQL do Azure, uma vez que foram concebidas para o SQL Server.

Query Store (Arquivo de Consultas)

O Arquivo de Consultas é um registo histórico do desempenho de execução de consultas armazenadas na base de dados do utilizador. O SQL do Azure está ativado por predefinição e é utilizado para fornecer funcionalidades como a correção automática do plano e a otimização automática. Os relatórios do SQL Server Management Studio (SSMS) sobre o arquivo estão disponíveis no SQL do Azure. Utilize estes relatórios para localizar consultas que consumam recursos, incluindo diferenças no plano de consulta e os principais tipos de espera para analisar cenários de espera de recursos.

Visualizações de desempenho

Na Base de Dados SQL do Azure, pode ver as informações de desempenho integradas do Arquivo de Consultas no portal do Azure através de visualizações. Dessa forma, você pode ver algumas das mesmas informações para o Repositório de Consultas que veria com uma ferramenta de cliente como o SSMS. Use as opções Visão Geral do Desempenho e Visão Geral do Desempenho da Consulta no portal do Azure.

Detalhes das DMVs

As DMVs têm sido o catalisador por detrás da monitorização e da resolução de problemas de desempenho do SQL Server desde há muitos anos. O SQL do Azure disponibiliza DMVs comuns para o SQL Server, mas algumas DMVs adicionais são específicas ao Azure.

Instância Gerida do Azure SQL

Todas as DMVs do SQL Server estão disponíveis no SQL Managed Instance. Os principais DMVs gostam sys.dm_exec_requests e sys.dm_os_wait_stats são comumente usados para examinar o desempenho da consulta.

A sys.server_resource_stats exibição do sistema é específica para a Instância Gerenciada SQL do Azure e mostra o uso histórico de recursos. Esta é uma ferramenta valiosa para ver o uso de recursos, porque você não tem acesso direto às ferramentas do sistema operacional, como o Monitor de Desempenho.

Base de Dados SQL do Azure

A maioria dos DMVs comuns que você precisa para desempenho, incluindo sys.dm_exec_requests e sys.dm_os_wait_stats, estão disponíveis. Tenha em conta que estas DMVs só fornecem informações específicas à base de dados, e não de todas as bases de dados de um servidor lógico.

O sys.dm_db_resource_stats DMV é específico do Banco de Dados SQL do Azure e você pode usá-lo para exibir um histórico de uso de recursos para o banco de dados. Utilize esta DMV tal como utilizaria sys.server_resource_stats numa instância gerida.

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

DMVs necessárias

Necessita das seguintes DMVs para resolver determinados cenários de desempenho no SQL do Azure:

• A DMV sys.dm_io_virtual_file_stats é importante, uma vez que não tem acesso direto às métricas do sistema operativo para desempenho de E/S por ficheiro.
• A DMV sys.dm_os_performance_counters está disponível na Base de Dados SQL do Azure e no SQL Managed Instance para ver as métricas de desempenho comuns do SQL Server. Use este DMV para exibir informações do contador de desempenho do SQL Server que normalmente estão disponíveis no Monitor de Desempenho.
• A DMV sys.dm_instance_resource_governance permite-lhe ver os limites de recursos de uma instância gerida. Pode ver estas informações para saber quais são os limites de recursos expectáveis sem utilizar o portal do Azure.
• A DMV sys.dm_user_db_resource_governance permite-lhe ver os limites de recursos comuns de acordo com a opção de implementação, escalão de serviço e tamanho da implementação da Base de Dados SQL do Azure. Pode ver estas informações para saber quais são os limites de recursos expectáveis sem utilizar o portal do Azure.

DMVs para informações mais aprofundadas

Estas DMVs fornecem informações aprofundadas sobre os limites e a gestão de recursos do SQL do Azure. Não se destinam à utilização em cenários comuns, mas podem ser úteis se quiser analisar mais detalhadamente os problemas de desempenho mais complexos. Consulte a documentação para saber todos os detalhes destas DMVs:

• sys.dm_user_db_resource_governance_internal (apenas para SQL Managed Instance)
• sys.dm_resource_governor_resource_pools_history_ex
• sys.dm_resource_governor_workload_groups_history_ex

Detalhes dos eventos alargados

A funcionalidade de eventos alargados é o mecanismo de rastreio do SQL Server. Os eventos estendidos para o SQL do Azure são baseados no mecanismo do SQL Server e, portanto, é quase o mesmo para o Azure SQL, com algumas diferenças notáveis. As próximas secções abordam estas diferenças.

Eventos alargados da Base de Dados SQL do Azure

Você pode usar eventos estendidos para o Banco de Dados SQL do Azure, assim como o SQL Server, criando sessões e usando eventos, ações e destinos. Tenha os seguintes aspetos em consideração ao criar sessões de eventos alargados:

• Os eventos e ações mais utilizados são suportados.
• O ficheiro, ring_buffer e contadores de destino são suportados.
• Os destinos dos ficheiros são suportados através do armazenamento de Blobs do Azure, uma vez que não tem acesso aos discos do sistema operativo subjacente.

Pode utilizar 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 estendida ou a função sys.fn_xe_file_target_read_filedo sistema.

Nota

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

É importante saber que todos os eventos alargados acionados nas suas sessões são específicos à sua base de dados e não se aplicam ao servidor lógico.

Eventos alargados do Azure SQL Managed Instance

Pode utilizar eventos alargados do SQL Managed Instance, tal como o SQL Server, ao criar sessões e utilizar eventos, ações e destinos. Tenha os seguintes aspetos em consideração ao criar sessões de eventos alargados:

• Todos os eventos, destinos e ações são suportados.
• Os destinos dos ficheiros são suportados através do armazenamento de Blobs do Azure, uma vez que não tem acesso aos discos do sistema operativo subjacente.
• Alguns eventos específicos são adicionados ao SQL Managed Instance para rastrear eventos específicos de gestão e executar a instância.

Pode utilizar 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 estendida ou a função sys.fn_xe_file_target_read_filedo sistema. A capacidade do SSMS de exibir dados em tempo real é suportada para o SQL Server e a Instância Gerenciada SQL do Azure.

Cenários de desempenho do SQL do Azure

Antes de decidir sobre como aplicar as ferramentas e funcionalidades de monitorização e de resolução de problemas de desempenho, é importante observar o desempenho do SQL do Azure em vários cenários.

Cenários de desempenho comuns

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

Vamos explorar os detalhes de cada aspeto do diagrama.

Executar vs. aguardar

Comece por observar a utilização geral dos recursos. Para uma implantação padrão do SQL Server, você pode usar ferramentas como o Monitor de Desempenho no Windows ou superior no Linux. No SQL do Azure, pode utilizar os seguintes métodos:

• Portal do Azure/PowerShell/alertas

  O Azure Monitor tem métricas integradas para ver a utilização de recursos do SQL do Azure. Também pode configurar alertas para procurar condições de utilização de recursos.

• sys.dm_db_resource_stats

  Na Base de Dados SQL do Azure, pode utilizar esta DMV para ver a CPU, a memória e a utilização de recursos E/S na implementação da base de dados. Esta DMV tira um instantâneo destes dados a cada 15 segundos.

• sys.server_resource_stats

  Esta DMV tem um comportamento semelhante ao sys.dm_db_resource_stats, mas é utilizada para ver a utilização de recursos da instância gerida do SQL Managed Instance para a CPU, memória e E/S. Esta DMV também tira um instantâneo a cada 15 segundos.

• sys.dm_user_db_resource_governance

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

• sys.dm_instance_resource_governance

  Para a Instância Gerenciada SQL do Azure, esse DMV retorna informações semelhantes ao sys.dm_user_db_resource_governance, mas para a Instância Gerenciada do SQL atual.

Em Execução

Se determinou que o problema é a elevada utilização da CPU, isto chama-se um cenário de execução. Um cenário de execução pode envolver consultas que consomem os recursos através da compilação ou execução. Utilize as seguintes ferramentas para efetuar uma análise mais aprofundada:

• Query Store (Arquivo de Consultas)

  Utilize os relatórios de Top Consuming Resource (Recurso Mais Consumidor) no SSMS, vistas de catálogo do Arquivo de Consultas ou Query Performance Insight no portal do Azure (apenas Base de Dados SQL do Azure) para saber que consultas estão a consumir mais recursos da CPU.

• sys.dm_exec_requests

  Utilize esta DMV no SQL do Azure para obter um instantâneo do estado das consultas ativas. Procure consultas com um estado de e um tipo de espera para ver se você tem capacidade de RUNNABLESOS_SCHEDULER_YIELD CPU suficiente.

• sys.dm_exec_query_stats

  Esta DMV pode ser utilizada como Arquivo de Consultas para encontrar as consultas que consomem mais recursos. Tenha em atenção que só está disponível para planos de consulta que estão em cache, enquanto o Arquivo de Consultas fornece um registo histórico persistente do desempenho. Esta DMV também lhe permite encontrar o plano de consulta para uma consulta em cache.

• sys.dm_exec_procedure_stats

  Esta DMV fornece informações da mesma forma que sys.dm_exec_query_stats, exceto que as informações de desempenho podem ser vistas ao nível do procedimento armazenado.

  Após determinar que consulta ou consultas estão a consumir mais recursos, poderá ter de examinar se tem recursos da CPU suficientes para a carga de trabalho. Poderá depurar planos de consulta com ferramentas como a análise para otimização de consultas leve, as instruções SET, o Arquivo de Consultas ou o rastreio de eventos expandidos.

A aguardar

Se o seu problema não parecer estar relacionado com a utilização elevada de recursos da CPU, o problema de desempenho poderá envolver a espera por um recurso. Os cenários que envolvem a espera por recursos incluem:

• Esperas de E/S
• Esperas de bloqueio
• Tempos de espera de bloqueio temporário
• Limites de conjunto de memória intermédia
• Concessões de memória
• Expulsão de cache de planos

Para executar análises em cenários de espera, você normalmente examinaria as seguintes ferramentas:

• sys.dm_os_wait_stats

  Utilize esta DMV para ver os principais tipos de espera para a base de dados ou instância. Isto pode ajudá-lo a perceber que medidas tomar a seguir, consoante os principais tipos de espera.

• sys.dm_exec_requests

  Use este Detran para encontrar tipos de espera específicos para consultas ativas para ver em que recurso elas estão esperando. Este pode ser um cenário de bloqueio padrão à espera de bloqueios de outros utilizadores.

• sys.dm_os_waiting_tasks

  Você pode usar esse Detran para encontrar tipos de espera para uma tarefa específica para uma consulta específica que está sendo executada 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 em tempo real que sys.dm_os_wait_stats agrega ao longo do tempo.

• Query Store (Arquivo de Consultas)

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

Gorjeta

Pode utilizar os eventos expandidos em quaisquer cenários de execução ou espera. Para fazê-lo, tem de configurar uma sessão de eventos expandidos 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 DMVs.

Cenários específicos ao SQL do Azure

Existem alguns cenários de desempenho, tanto de execução como de espera, que são específicos do SQL do Azure. Estes incluem a governação de registos, os limites de trabalho, as esperas encontradas ao utilizar os escalões de serviço Crítico para a Empresa e as esperas específicas à implementação Hyperscale.

Governação de registos

O SQL do Azure pode utilizar a governação da taxa de registo para impor limites de recursos na utilização do registo de transações. Poderá necessitar desta imposição para garantir os limites de recursos e para cumprir o SLA prometido. A governação de registos poderá ser vista a partir dos seguintes tipos de espera:

• LOG_RATE_GOVERNOR: aguarda o Banco de Dados SQL do Azure
• POOL_LOG_RATE_GOVERNOR: espera por piscinas elásticas
• INSTANCE_LOG_GOVERNOR: aguarda a Instância Gerenciada SQL do Azure
• HADR_THROTTLE_LOG_RATE*: aguarda latência crítica para os negócios e replicação geográfica

Limites de trabalho

O SQL Server utiliza um conjunto de processos de trabalho de threads, mas tem limites sobre o número máximo de processos de trabalho. Aplicativos com um grande número de usuários simultâneos podem se aproximar dos limites de trabalho impostos para o Banco de Dados SQL do Azure e a Instância Gerenciada SQL:

• A Base de Dados SQL do Azure tem limites com base no tamanho e escalão de serviço. Se exceder este limite, uma nova consulta receberá um erro.
• No momento atual, a Instância Gerenciada SQL usa max worker threads, portanto, os trabalhadores que ultrapassaram esse limite podem ver THREADPOOL esperas.

Esperas HADR do Crítico para a Empresa

Se utilizar o escalão de serviço Crítico para a Empresa, poderá deparar-se com os seguintes tipos de espera inesperadamente:

• HADR_SYNC_COMMIT
• HADR_DATABASE_FLOW_CONTROL
• HADR_THROTTLE_LOG_RATE_SEND_RECV

Apesar de estas esperas poderem não tornar a sua aplicação mais lenta, poderão ser inesperadas. Por norma, são específicas da utilização de um grupo de disponibilidade AlwaysOn. Os escalões Crítico para a Empresa utilizam a tecnologia do grupo de disponibilidade para implementar as funcionalidades de disponibilidade e SLA de um escalão de serviço Crítico para a Empresa, para que estes tipos de espera sejam esperados. Tenha em atenção que longos tempos de espera podem indicar um estrangulamento, como uma réplica ou latência de E/S em segundo plano.

Hyperscale

A arquitetura Hyperscale pode resultar em alguns tipos de espera exclusivos com o prefixo RBIO (uma possível indicação de governação de registos). Além disso, as DMVs, as vistas de catálogo e os eventos expandidos foram melhorados para mostrar as métricas de leituras de servidor de páginas.

No próximo exercício, você aprenderá como monitorar e resolver um problema de desempenho para o SQL do Azure usando as ferramentas e o conhecimento adquiridos nesta unidade.

Continuar