• 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 examinar 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 para PostgreSQL e MySQL são armazenados no Azure e o nível de detalhes que eles contêm.

Usar logs do servidor para acompanhar 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 de servidor são os arquivos de log de mensagens nativas 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 mantidos 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 de servidor para cada serviço separadamente.

Logs de 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 consultas lentas e no log de auditoria em um servidor MySQL.

Você usa as informações no log de consultas lentas para ajudar a identificar consultas de execução lenta. Por padrão, o log de consultas lentas está desabilitado. Para habilitá-lo, defina o parâmetro de servidor slow_query_log como ATIVADO. Você configura o log de consultas lentas para determinar o que se destina a uma consulta lenta usando os seguintes parâmetros de servidor:

• log_queries_not_using_indexes. Esse parâmetro está ATIVADO ou DESATIVADO. 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 ATIVADO para incluir consultas administrativas de execução lenta no log.
• long_query_time. O limite (em segundos) para uma consulta ser considerada lenta em execução.

Depois de você habilitar o log de consultas lentas e o log de auditoria, os arquivos de log começarão a aparecer na página de logs do servidor no servidor. Um novo log de consultas lentas é criado todos os dias. Para baixar um arquivo de log, clique nele:

Para habilitar o log de auditoria, defina o parâmetro do servidor audit_log_enabled como ATIVADO. 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 CONEXÃO, DDL, DML, ADMIN e outros.
• audit_log_exclude_users. Esse parâmetro é uma lista separada por vírgulas de usuários cujas atividades não serão incluídas no log de auditoria.

Se você precisar preservar o log de consultas lentas e o log de auditoria por mais de sete dias, poderá organizá-los para serem transferidos para o armazenamento do Azure. Use a página Configurações de diagnóstico no seu servidor e, em seguida, 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:

Dados de log de consulta lentos 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 de 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 erros e consultas ineficientes.

Habilite o log definindo os vários parâmetros de configuração do servidor log_ como ATIVADO. Os parâmetros incluem:

• log_checkpoints. Um ponto de verificação ocorre sempre que todos os arquivos de dados foram atualizados com as informações mais recentes do log de transações. Se houver uma falha no servidor, esse ponto marcará a hora em que a recuperação precisará ser iniciada ao rolar 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 eventos de espera de bloqueio sejam registrados. As esperas de bloqueio podem ser causadas por transações implementadas inadequadamente 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 gravadas:

• log_error_verbosity. Essa configuração especifica o nível de detalhes gravados para cada mensagem registrada.
• log_retention_days. Esse é o número de dias que o servidor retém cada arquivo de log antes de removê-lo. O padrão é de 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 de erro para a gravação de 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.

Rastrear desempenho de consulta

O Repositório de Consultas é um recurso adicional fornecido pelo Azure para ajudá-lo a identificar e acompanhar consultas com mau desempenho. Use-o com o Banco de Dados do Azure para PostgreSQL e o Banco de Dados do Azure para MySQL.

Habilitando o rastreamento de desempenho de consultas

O Repositório de Consultas registra as 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á desabilitado por padrão. Para habilitá-lo:

• 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 TODOS.
• Se você estiver usando o Banco de Dados do Azure para PostgreSQL, defina o parâmetro de servidor pg_qs.query_capture_mode como ALL ou OP e defina o parâmetro pgms_wait_sampling.query_capture_mode como ALL.

Analisando os 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 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 para cada consulta executada recentemente e um host 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 por esses dados —Análise de desempenho de consultas e Recomendações de consulta.

Análise de desempenho de consultas é um utilitário gráfico, disponível na página de Análise de desempenho de consultas no seu servidor. A guia Consultas execução prolongada exibe as estatísticas para as consultas de execução mais longa. Você especifica o período e amplia em alguns minutos. A legenda mostra o texto de cada consulta, junto com a duração e o número de vezes em que a consulta foi executada. O grafo fornece uma exibição comparativa da duração de cada consulta. Você exibe os dados pelo tempo médio de cada consulta, mas também é instrutivo exibir o tempo total (contagem de duração * da execução) para cada consulta. O código abaixo mostra um exemplo:

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 que aguarda vários recursos.

Eventos de espera normalmente se enquadram em três categorias:

• Esperas de bloqueio. Esses eventos ocorrerão se uma consulta estiver tentando ler ou modificar dados bloqueados por outra consulta. Se você tiver um grande número de esperas de bloqueio, verifique se há transações de execução prolongada ou operações que usam um nível de isolamento altamente restritivo.
• Esperas de E/S. Esse tipo de espera ocorrerá 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.
• Esperas de memória. Uma espera de memória ocorrerá 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 estar bloqueada por outras consultas sobrecarregando 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 dispare outra, para que você não possa examinar necessariamente esses problemas de forma isolada. 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 poderia ter dados bloqueados que fazem com que outra transação incorra em uma espera de bloqueio.

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