Database Autonomy Service:Slow query logs

Conceito principal: Grupo de usuários

Os grupos de usuários são um componente central do recurso de análise de logs lentos. Um grupo de usuários funciona como um painel personalizado de monitoramento de instâncias. Crie um grupo de usuários para realizar as seguintes operações:

• Agrupamento lógico: agrupe instâncias de banco de dados de diferentes linhas de negócio para facilitar o gerenciamento. Cada grupo de usuários pode conter até 10 instâncias.

• Visualização unificada: visualize as tendências de logs lentos, a distribuição de eventos e as estatísticas de SQL de todas as instâncias de um grupo em uma única página.

• Alternância eficiente: alterne rapidamente entre diferentes áreas de foco do negócio sem precisar selecionar instâncias repetidamente.

Pré-requisitos

• Mecanismos de banco de dados compatíveis: sua instância de banco de dados deve usar um dos seguintes tipos de mecanismo:

  • Bancos de dados relacionais:

    • RDS for MySQL, PolarDB for MySQL, MyBase for MySQL

    • RDS for SQL Server, MyBase for SQL Server

    • RDS for PostgreSQL, PolarDB for PostgreSQL, PolarDB for PostgreSQL (Compatible with Oracle)

    • PolarDB-X 2.0

  • Bancos de dados NoSQL:

    • Tair (compatível com Redis OSS), MyBase for Redis

    • ApsaraDB for MongoDB

• Acesso à instância: a instância de banco de dados de destino deve estar conectada ao DAS. Para mais informações, consulte {{XREF_0}}.

• Suporte a regiões:

  • Detalhes do log de consultas lentas: este recurso é compatível com todas as regiões.

  • Estatísticas de log de consultas lentas em tempo real: este recurso é compatível com as regiões Chinese mainland, Hong Kong (China), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Japan (Tokyo), Germany (Frankfurt), UK (London), US (Silicon Valley) e US (Virginia).

• Bancos de dados autogerenciados: a página de análise de logs lentos não é compatível com instâncias de banco de dados autogerenciadas.

• Limiar do log de consultas lentas: o kernel do banco de dados controla o registro dos logs de consultas lentas. O DAS é responsável pela análise e não define o limiar. Para configurar o limiar do log de consultas lentas, como o parâmetro long_query_time para MySQL, faça login na instância de banco de dados específica.

Procedimento

Perguntas frequentes

• P: Por que não consigo ver nenhum dado de log de consultas lentas?

  R: Isso pode ocorrer porque são usadas técnicas de computação em tempo real e agregação de janelas, o que faz com que as estatísticas mais recentes do log de consultas lentas sejam exibidas com um atraso de cerca de 3 minutos. Você também pode verificar o seguinte:

  • Confirme se o recurso de log de consultas lentas está ativado para a instância de banco de dados e se o limiar está definido com um valor razoável.

  • Confirme se os logs de consultas lentas foram gerados dentro do intervalo de tempo selecionado.

  • Para um banco de dados MySQL autogerenciado, confirme se a tabela mysql.slow_log não contém muitos registros. Um número excessivo de registros causa tempo limite na coleta do dbgateway. Trunque a tabela slow_log ou use o modo de host do dbgateway para coletar logs de consultas lentas de arquivos locais.

  • Confirme se a conta atual tem permissões de acesso ao DAS para a instância de destino.

• P: O que devo fazer se um usuário RAM não tiver permissão para visualizar ou gerenciar grupos de usuários?

  R: Um administrador deve conceder permissões de ação no nível da conta ao usuário RAM. Essa autorização afeta apenas as permissões para operar em grupos globais de logs lentos e não altera as permissões de dados do usuário RAM para outras instâncias.

  • Política de administrador de grupo global: por exemplo, DASGlobalGroupAdmin. Essa política permite que o usuário crie, exclua, modifique e consulte grupos globais.

    {
      "Version": "1",
      "Statement": [
        {
          "Action": "hdm:DescribeGlobalGroups",
          "Resource": "*",
          "Effect": "Allow"
        }
      ]
    }

  • Política de somente leitura de grupo global: por exemplo, DASGlobalGroupReadOnly. Essa política permite que o usuário apenas visualize grupos globais.

    {
      "Version": "1",
      "Statement": [
        {
          "Action": "hdm:DescribeGlobalGroups",
          "Resource": "*",
          "Effect": "Allow"
        }
      ]
    }

• P: Por que algumas instâncias são destacadas em amarelo, indicando que o usuário atual não tem permissões de acesso?

  R: O destaque amarelo indica que o usuário RAM não tem permissões de acesso aos dados da instância. Você pode resolver esse problema de uma das duas maneiras a seguir:

  • Contate um administrador: solicite ao administrador que conceda permissões de acesso à instância para o usuário RAM.

  • Conceda permissões de grupo global: conceda a permissão {{XREF_4}} ao usuário RAM. Isso permite que o usuário RAM crie grupos de usuários e visualize dados de instâncias às quais ele tem permissão de acesso em lotes.

• P: Por que o número de linhas retornadas (Rows_sent) no log de consultas lentas é 0, mesmo que a consulta realmente retorne dados?

  R: Isso geralmente ocorre porque o aplicativo usa o modo de cursor do lado do servidor. No modo de cursor, a execução de uma instrução SQL é dividida em duas etapas:

  • Estágio EXECUTE: o servidor executa a consulta e gera um conjunto de resultados, mas não envia imediatamente as linhas de dados para o cliente. Ele retorna apenas metadados, como definições de colunas.

  • Estágio FETCH: o cliente puxa as linhas de dados em lotes usando o comando FETCH.

  O log de consultas lentas registra estatísticas do estágio EXECUTE. Nesse estágio, o MySQL verificou os dados (portanto, Rows_examined não é 0), mas ainda não enviou nenhuma linha de dados para o cliente (os dados são enviados no estágio FETCH subsequente). Portanto, Rows_sent é registrado como 0.

  Cenários comuns:

  • Java/JDBC: useCursorFetch=true está ativado na URL de conexão, e PreparedStatement.setFetchSize() está definido com um valor maior que 0 ou como Integer.MIN_VALUE.

  • Python: MySQLdb.cursors.SSCursor ou pymysql.cursors.SSCursor é usado.

  • Frameworks ORM: alguns frameworks de Mapeamento Objeto-Relacional (ORM) usam consultas de streaming por padrão ao processar consultas de grandes conjuntos de dados, o que é baseado no modo de cursor.

  Para confirmar se essa é a causa, verifique se fetchSize está configurado ou se um cursor de streaming é usado no código do seu aplicativo. Você também pode executar o comando SHOW GLOBAL STATUS LIKE 'Com_stmt_fetch'; no banco de dados para verificar se há solicitações FETCH.

• P: Por que o tempo de conclusão no log de consultas lentas é diferente do tempo de execução real da instrução SQL?

  R: Esse problema geralmente ocorre porque o fuso horário foi alterado quando a instrução SQL foi executada. O fuso horário do tempo de execução do SQL registrado no log de consultas lentas pode estar no nível da sessão, do banco de dados ou do sistema. A lógica para determinar o tempo no log de consultas lentas é a seguinte: se um fuso horário estiver definido para o banco de dados, o fuso horário do banco de dados será usado. Caso contrário, o fuso horário do sistema será usado. Se o fuso horário no nível da sessão for modificado usando uma instrução SQL, o fuso horário no registro do log de consultas lentas poderá não ser convertido corretamente.

• P: O que é um SQL ID?

  R: Para facilitar a análise estatística de logs de consultas lentas do mesmo tipo, o DAS remove comentários de um log de consulta lenta e substitui parâmetros por pontos de interrogação para gerar um modelo de log de consulta lenta. Em seguida, o DAS realiza um cálculo de hash no modelo para gerar um SQL ID de 32 caracteres. Os registros com o mesmo SQL ID são considerados logs de consultas lentas do mesmo tipo.

• P: Por que um log de consulta lenta é truncado? Como obtenho o log de consulta lenta não truncado?

  R: Devido aos limites de armazenamento subjacentes, o comprimento máximo de um único log de consulta lenta é de 16 KB. O conteúdo que excede esse limite é truncado. Esse limite de comprimento não pode ser modificado, e logs de consultas lentas não truncados não podem ser obtidos. Para visualizar instruções SQL completas, ative o recurso de log de auditoria.

• P: Por que os dados do log de consultas lentas retornados por uma API são inconsistentes com os dados no console?

  R: Isso pode ser causado por um dos dois motivos a seguir:

  • Você está usando a API de log de consultas lentas fornecida pelo mecanismo do banco de dados. Para garantir que os dados sejam consistentes com o console, use a API de log de consultas lentas fornecida pelo DAS (DescribeSlowLogStatistic). A maneira mais simples de usar a API: após filtrar os dados de destino no console, clique em Go to Debug para visualizar como usar a API para obter os dados da página.

  • Se você consultar logs de consultas lentas próximos ao ponto atual no tempo, os dados podem chegar com atraso, o que faz com que a mesma API retorne dados inconsistentes em duas consultas.

Referências

Você pode ativar o recurso de administração automática de banco de dados do DAS para otimizar automaticamente instruções SQL lentas quando elas ocorrerem na sua instância de banco de dados.

• {{XREF_5}}

• {{XREF_6}}