Rastreie e rastreie a atividade

  • 11 minutos

Uma grande parte da manutenção de bancos de dados é o ajuste de desempenho. Os mesmos arquivos de log que você está acostumado a revisar em seus bancos de dados locais ainda estão disponíveis com o Banco de Dados do Azure para MySQL/PostgreSQL.

Com seus bancos de dados migrados para o Azure, você precisa continuar revisando os arquivos de log para garantir que o desempenho dos bancos de dados seja mantido.

Nesta unidade, você verá onde os arquivos de log do PostgreSQL e do MySQL estão armazenados no Azure e o nível de detalhes que eles contêm.

Usar logs do servidor para rastrear a atividade do banco de dados

O Banco de Dados do Azure para MySQL/PostgreSQL também registra informações de diagnóstico nos logs do servidor. Os logs do servidor são os arquivos de log de mensagens nativos para MySQL e PostgreSQL (não os arquivos de log de transações, que são inacessíveis no Banco de Dados do Azure para MySQL/PostgreSQL). Esses arquivos contêm mensagens, status do servidor e outras informações de erro que você usa para depurar problemas com seus bancos de dados. Os logs do servidor são retidos por até sete dias (menos, se o tamanho total dos arquivos de log do servidor exceder 7 GB).

O Banco de Dados do Azure para MySQL e o Banco de Dados do Azure para PostgreSQL registram detalhes diferentes nos logs do servidor. As seções a seguir descrevem os logs do servidor para cada serviço separadamente.

Logs do servidor no Banco de Dados do Azure para MySQL

No Banco de Dados do Azure para MySQL, o log do servidor fornece as informações normalmente disponíveis no log de consulta lenta e no log de auditoria em um servidor MySQL.

Use as informações no log de consultas lentas para ajudar a identificar consultas de execução lenta. Por padrão, o log de consulta lenta está desabilitado. Para habilitá-lo, defina o parâmetro slow_query_log server como ON. Configure o log de consulta lenta para determinar o que significa uma consulta lenta usando os seguintes parâmetros de servidor:

  • log_queries_not_using_indexes. Este parâmetro é ON ou OFF. Defina-o como ATIVADO para registrar todas as consultas que provavelmente executarão uma verificação de tabela completa em vez de uma pesquisa de índice.
  • log_throttle_queries_not_using_indexes. Especifica o número máximo de consultas lentas que não usam índices que podem ser registrados por minuto.
  • log_slow_admin_queries. Defina esse parâmetro como ON para incluir consultas administrativas de execução lenta no log.
  • long_query_time. O limite (em segundos) para que uma consulta seja considerada de execução lenta.

Depois de habilitar o log de consulta lenta e o log de auditoria, os arquivos de log começarão a aparecer na página Logs do servidor para o servidor. Um novo log de consulta lenta é criado a cada dia. Clique em um arquivo de log para baixá-lo:

Image of the Server logs page for Azure Database for MySQL.

Para habilitar o log de auditoria, defina o parâmetro audit_log_enabled server como ON. Configure o log de auditoria com os seguintes parâmetros:

  • audit_log_events. Especifique os eventos a serem auditados. No portal do Azure, esse parâmetro fornece uma lista suspensa de eventos, como CONNECTION, DDL, DML, ADMIN e outros.
  • audit_log_exclude_users. Este parâmetro é uma lista separada por vírgulas de usuários cujas atividades não serão incluídas no log de auditoria.

Se precisar preservar o log de consulta lenta e o log de auditoria por mais de sete dias, providencie a transferência deles para o armazenamento do Azure. Use a página Configurações de diagnóstico para seu servidor e selecione + Adicionar configuração de diagnóstico. Na página Configurações de diagnóstico, selecione Arquivar em uma conta de armazenamento, selecione uma conta de armazenamento na qual salvar os arquivos de log (essa conta de armazenamento já deve existir), selecione MySqlSlowLogs e MySqlAuditLogs, e especifique um período de retenção de até 365 dias. Você pode baixar os arquivos de log do armazenamento do Azure a qualquer momento durante esse período. Selecione Salvar:

Image of the Diagnostic settings page for Azure Database for MySQL.

Os dados de log de consulta lenta serão gravados no formato JSON em blobs em um contêiner chamado insights-logs-mysqlslowlogs. Pode levar até 10 minutos para que os arquivos de log apareçam no armazenamento do Azure. Os registros de auditoria são armazenados no contêiner de blob insights-logs-mysqlslowlogs, novamente no formato JSON.

Logs do servidor no Banco de Dados do Azure para PostgreSQL

No Banco de Dados do Azure para PostgreSQL, o log do servidor contém log de erros e arquivos de log de consulta. Use as informações nesses arquivos para ajudar a localizar as fontes de quaisquer erros e consultas ineficientes.

Você habilita o registro em log definindo os vários parâmetros de configuração do servidor log_ como ON. Estes parâmetros incluem:

  • log_checkpoints. Um ponto de verificação ocorre sempre que cada arquivo de dados foi atualizado com as informações mais recentes do log de transações. Se houver uma falha no servidor, esse ponto marcará o momento em que a recuperação precisa começar rolando para frente a partir do log de transações.
  • log_connection e log_disconnections. Essas configurações registram cada conexão bem-sucedida e o final de cada sessão.
  • log_duration. Essa configuração faz com que a duração de cada instrução SQL concluída seja registrada.
  • log_lock_waits. Essa configuração faz com que os eventos de espera de bloqueio sejam gravados. As esperas de bloqueio podem ser causadas por transações mal implementadas no código do aplicativo.
  • log_statement_stats. Essa configuração grava informações cumulativas sobre o desempenho do servidor no log.

O Banco de Dados do Azure para PostgreSQL também fornece parâmetros adicionais para ajustar as informações registradas:

  • log_error_verbosity. Essa configuração especifica o nível de detalhe registrado para cada mensagem registrada.
  • log_retention_days. Este é o número de dias que o servidor retém cada arquivo de log antes de removê-lo. O padrão é três dias, e você pode defini-lo para um máximo de sete dias.
  • log_min_messages e log_min_error_statement. Use esses parâmetros para especificar os níveis de aviso e erro para gravar instruções.

Assim como no Banco de Dados do Azure para MySQL, os arquivos de log gerados pelo Banco de Dados do Azure para PostgreSQL estão disponíveis na página Logs do servidor. Você também pode usar a página Configurações de diagnóstico para copiar os logs para o armazenamento do Azure.

Controlar o desempenho da consulta

O Repositório de Consultas é um recurso adicional fornecido pelo Azure para ajudá-lo a identificar e rastrear consultas mal executadas. Você o usa com o Banco de Dados do Azure para MySQL e o Banco de Dados do Azure para PostgreSQL.

Habilitando o acompanhamento do desempenho da consulta

O Repositório de Consultas registra informações no esquema mysql no Banco de Dados do Azure para MySQL e em um banco de dados chamado azure_sys no Banco de Dados do Azure para PostgreSQL. O Repositório de Consultas pode capturar dois tipos de informações: dados sobre a execução da consulta e informações sobre estatísticas de espera. O Repositório de Consultas está desativado por padrão. Para ativar:

  • Se você estiver usando o Banco de Dados do Azure para MySQL, defina os parâmetros do servidor query_store_capture_mode e query_store_wait_sampling_capture_mode como ALL.
  • Se você estiver usando o Banco de Dados do Azure para PostgreSQL, defina o parâmetro do servidor pg_qs.query_capture_mode como ALL ou TOP e defina o parâmetro pgms_wait_sampling.query_capture_mode como ALL.

Analisando dados de desempenho de consulta

Você pode consultar as tabelas usadas pelo Repositório de Consultas diretamente. Se você estiver executando o Banco de Dados do Azure para MySQL, conecte-se ao seu servidor e execute as seguintes consultas:

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Se você estiver usando o Banco de Dados do Azure para PostgreSQL, execute as seguintes consultas:

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

Em ambos os casos, a primeira consulta exibirá o texto de cada consulta executada recentemente e uma série de estatísticas sobre quanto tempo a consulta levou para compilar e executar. A segunda consulta exibe informações sobre eventos de espera. Um evento de espera ocorre quando uma consulta é impedida de ser executada porque requer os recursos mantidos por outra.

Se você examinar o Repositório de Consultas diretamente, poderá gerar seus próprios relatórios personalizados e obter uma visão detalhada de como o sistema está funcionando. No entanto, a quantidade de dados disponíveis pode dificultar a compreensão do que está acontecendo. O Banco de Dados do Azure para MySQL/PostgreSQL fornece duas ferramentas adicionais para ajudá-lo a navegar nesses dados: Query Performance Insight e Query Recommendations.

O Query Performance Insight é um utilitário gráfico, disponível na página Query Performance Insight para o seu servidor. A guia Consultas de execução longa exibe as estatísticas das consultas de execução mais longa. Especifique o período de tempo e aumente o zoom em poucos minutos. A legenda mostra o texto de cada consulta, juntamente com a duração e o número de vezes que a consulta foi executada. O gráfico dá uma visão comparativa da duração de cada consulta. Você visualiza os dados pelo tempo médio de cada consulta, mas também é instrutivo exibir o tempo total (contagem de execução de duração * ) para cada consulta. A imagem abaixo mostra um exemplo:

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Long running queries tab.

A guia Estatísticas de espera mostra as informações de evento de espera para cada consulta. Você verá a quantidade de tempo gasto por uma consulta aguardando vários recursos.

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Wait statistics tab.

Os eventos de espera normalmente se enquadram em três categorias:

  • O bloqueio espera. Esses eventos ocorrem se uma consulta estiver tentando ler ou modificar dados bloqueados por outra consulta. Se você enfrentar um grande número de esperas de bloqueio, verifique se há transações de longa duração ou operações que usam um nível de isolamento altamente restritivo.
  • IO espera. Esse tipo de espera ocorre se uma consulta estiver executando uma quantidade significativa de E/S. Isso pode ser devido a uma consulta mal projetada (verifique a cláusula WHERE ), uma operação de junção ineficiente ou uma verificação de tabela completa incorrida devido a um índice ausente.
  • A memória espera. Uma espera de memória ocorre se não houver memória suficiente disponível para processar uma consulta. Sua consulta pode estar tentando ler uma grande quantidade de dados ou pode ser bloqueada por outras consultas que consomem memória. Novamente, isso pode indicar que os índices estão ausentes, fazendo com que as consultas leiam tabelas inteiras na memória.

Também é altamente provável que uma forma de espera desencadeie outra, então você não pode necessariamente examinar essas questões isoladamente. Por exemplo, uma transação que lê e atualiza dados em tabelas diferentes pode estar sujeita a uma espera de memória. Por sua vez, essa transação pode ter bloqueado dados que fazem com que outra transação incorra em uma espera de bloqueio.

A página Recomendações de Desempenho do servidor pega as informações mantidas no Repositório de Consultas e as usa para fazer recomendações para ajustar seu banco de dados para as cargas de trabalho que ele está enfrentando.