PolarDB:SQL Explorer

Parâmetros

• Execution Duration Distribution: Mostra a distribuição da duração de execução de todas as instruções SQL no intervalo de tempo selecionado. A duração da execução é dividida em sete intervalos, calculados uma vez por minuto:

  • [0,1]ms indica a porcentagem de execuções de SQL com duração de 0 ms a 1 ms (inclusivo).

  • (1,2]ms indica a porcentagem de execuções de SQL com duração maior que 1 ms e até 2 ms.

  • (2,3]ms indica a porcentagem de execuções de SQL com duração maior que 2 ms e até 3 ms.

  • (3,10]ms indica a porcentagem de execuções de SQL com duração maior que 3 ms e até 10 ms.

  • (10,100]ms indica a porcentagem de execuções de SQL com duração maior que 10 ms e até 100 ms.

  • (0.1,1]s indica a porcentagem de execuções de SQL com duração maior que 0,1 s e até 1 s.

  • >1s indica a porcentagem de execuções de SQL com duração maior que 1 s.

  Nota

  Quanto mais próxima do azul for a Execution Duration Distribution de uma instância, melhor será seu desempenho de SQL. Quanto mais próxima do laranja e vermelho, pior será o desempenho.

  • Execution Duration (SQL RT): Exibe a duração da execução das instruções SQL no intervalo de tempo selecionado.

  • Full Request Statistics: Exibe o texto do SQL, porcentagem de duração, duração média de execução e tendência de execução para cada tipo de instrução SQL no intervalo de tempo selecionado.

    Nota

    A porcentagem de duração representa a duração total de execução de um tipo específico de SQL como uma porcentagem da duração total de execução de todos os tipos de SQL. Tipos de SQL com maior porcentagem de duração consomem mais recursos na instância MySQL.

  • SQL ID: Clique em um SQL ID para visualizar a tendência de desempenho e amostras de SQL dessa instrução.

  • SQL Sample: Use uma SQL Sample para identificar qual aplicativo cliente iniciou a instrução SQL.

    Nota

    As amostras de SQL usam codificação UTF-8.

  Modifique a duração de armazenamento de logs de SQL

  Aviso

  Se você reduzir a duração de armazenamento, o DAS excluirá imediatamente os logs de auditoria que excederem a nova duração. Exporte e salve seus logs antes de reduzir a duração de armazenamento.

  1. Faça login no console do PolarDB. No painel de navegação à esquerda, clique em Clusters. Selecione a região onde o cluster está localizado e clique no ID do cluster para acessar a página de detalhes do cluster.

  2. No painel de navegação à esquerda, escolha Logs and Audit > SQL Explorer.

  3. No canto superior direito, clique em Service Settings.

  4. Modifique a duração de armazenamento e clique em OK.

     Nota

     • Com o DAS Enterprise Edition V3, é possível definir durações de armazenamento por sub-recurso.

     • O DAS armazena os dados do SQL Explorer and Audit, sem consumir o armazenamento do cluster.

  Desativar o SQL Explorer and Audit

  Aviso

  Desativar o SQL Explorer and Audit exclui todos os logs de auditoria. Exporte e salve seus logs antes de desativar. Se você reativar o recurso, o registro será retomado a partir desse ponto.

  1. Faça login no console do PolarDB. No painel de navegação à esquerda, clique em Clusters. Selecione a região onde o cluster está localizado e clique no ID do cluster para acessar a página de detalhes do cluster.

  2. No painel de navegação à esquerda, escolha Logs and Audit > SQL Explorer.

  3. Clique em Service Settings para desativar o SQL Explorer and Audit.

     Para o DAS Enterprise Edition V3, desmarque todas as caixas de seleção dos recursos do SQL Explorer and Audit.

     Nota

     • Se a coleta de logs de auditoria estiver ativada para o PolarDB for MySQL no Simple Log Service CloudLens for PolarDB, o sistema também ativará o SQL Explorer para o cluster PolarDB for MySQL. Desative também a coleta de logs de auditoria para este cluster PolarDB for MySQL. Ativar o recurso de coleta de dados.

     • Desativar o SQL Explorer exclui todos os logs de auditoria. Exporte seus registros primeiro. Exportar registros de log de SQL.

  4. Clique em OK.

  Visualize tamanho e consumo de logs de auditoria

  1. Faça login no Console do Alibaba Cloud. No canto superior direito da página, escolha Expenses.

  2. No painel de navegação à esquerda Costs, escolha Bills > Bill Details. Visualize os detalhes de custo onde a coluna Billable Item é sql_explorer.

  3. Na aba Bill Details, clique na aba Detailed Bills e pesquise por Instance ID. Visualize os detalhes de custo onde a coluna Billable Item é sql_explorer.

     

  Migrar para a nova versão

  Nota

  A migração para a nova versão é suportada apenas nas regiões China (Hangzhou), China (Shanghai), China (Beijing) e China (Shenzhen).

  1. Faça login no console do PolarDB. No painel de navegação à esquerda, clique em Clusters. Selecione a região onde o cluster está localizado e clique no ID do cluster para acessar a página de detalhes do cluster.

  2. No painel de navegação à esquerda, clique em Logs and Audit > SQL Explorer.

  3. Na caixa de diálogo Upgrade SQL Explorer To 'SQL Explorer and Audit', clique em Upgrade.

  Migrar dados entre Enterprise Editions

  O Enterprise Edition V2 usa uma arquitetura de armazenamento híbrido quente-frio para reduzir custos. O Enterprise Edition V3 aprimora essa estrutura com faturamento itemizado por recurso para gerar ainda mais economia.

  Se o cluster suportar o Enterprise Edition V3, migre da versão V1 ou V2 para reduzir custos. Como migrar dados entre diferentes DAS Enterprise Editions?

  FAQ

  • As taxas do SQL Explorer podem ser compensadas por um plano de recursos?

    Não. O SQL Explorer suporta apenas faturamento conforme o uso. Os modelos de assinatura e planos de recursos não são suportados.

  • Na área Full Request Statistics do SQL Explorer, o que significa a instrução logout!?

    logout! indica uma desconexão. A duração do logout! corresponde ao tempo ocioso desde a última interação até o evento logout!. Um valor de 1158 na coluna Status indica uma desconexão de rede. As possíveis causas incluem:

    • A conexão do cliente atingiu o tempo limite.

    • O servidor desconectou de forma anormal.

    • A conexão do servidor foi redefinida porque a duração de interactive_timeout ou wait_timeout foi excedida.

  • Nas Source Statistics do SQL Explorer, por que aparece uma fonte de acesso como %?

    Isso pode ocorrer ao usar um procedimento armazenado, conforme mostrado abaixo:

    Nota

    Este exemplo usa um cluster PolarDB for MySQL com uma conta de teste (test_user) e banco de dados (test_db).

    1. No console do PolarDB, crie uma conta padrão e um banco de dados autorizado. Criar uma conta padrão.

    2. Conecte-se ao cluster usando a conta de teste. Conectar-se a um cluster pela linha de comando.

    3. Mude para o banco de dados de teste e crie o seguinte procedimento armazenado.

       -- Switch to the test database
       USE test_db;

       -- Create a stored procedure
       DELIMITER $$
       DROP PROCEDURE IF EXISTS `das` $$
       CREATE DEFINER=`test_user`@`%` PROCEDURE `das`()
       BEGIN
           SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID();
       END $$
       DELIMITER ;

    4. Conecte-se ao cluster usando uma conta privilegiada. Criar uma conta privilegiada e Conectar-se a um cluster pela linha de comando.

    5. Chame o procedimento armazenado.

       -- Switch to the test database
       USE test_db;

       -- Call the stored procedure
       CALL das();

       -- Call result
       +-----------+-----------+---------+---------+---------+------+-----------+-------------------------------------------------------------------------+
       | ID        | USER      | HOST    | DB      | COMMAND | TIME | STATE     | INFO                                                                    |
       +-----------+-----------+---------+---------+---------+------+-----------+-------------------------------------------------------------------------+
       | 269660316 | test_user | %:46182 | test_db | Query   |    0 | executing | SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID() |
       +-----------+-----------+---------+---------+---------+------+-----------+-------------------------------------------------------------------------+

  • Por que o nome do banco de dados exibido na lista de logs de auditoria difere daquele na instrução SQL?

    A lista de logs mostra o nome do banco de dados do contexto da sessão, enquanto a instrução SQL contém o banco de dados especificado pelo usuário (por exemplo, em consultas entre bancos de dados). Esses valores podem ser diferentes.

  • Ativar o SQL Explorer and Audit afeta o desempenho do banco de dados? Em caso afirmativo, qual é o impacto?

    Sim, mas o impacto é mínimo.

    Uso de recursos:

    • CPU e memória: Insignificante.

    • Espaço de armazenamento: O DAS armazena os dados de auditoria, sem consumir o armazenamento do cluster.

    • Rede: Sem impacto.

    • Desempenho de disco: Sem impacto. O DAS armazena os dados de auditoria externamente.

  • Uma instrução UPDATE foi executada em um cluster e o log de auditoria mostra que uma linha foi afetada. No entanto, os dados na tabela não foram atualizados. Como diagnosticar e resolver esse problema?

    • Procedimento de solução de problemas:

      1. Localize a instrução SQL no log de auditoria e obtenha seu Thread ID. Em seguida, clique em Enable Advanced Search e pesquise pelo Thread ID. Verifique se o AUTOCOMMIT estava desativado para o thread atual e, nesse caso, se um COMMIT explícito foi emitido.

         Nota

         Filtre primeiro por Thread ID. Adicione outras condições se os resultados forem muito extensos.

         

      2. Se o método anterior falhar, considere restaurar o banco de dados e analisar os logs para confirmar se existe um registro de modificação bem-sucedida.

      Nota

      Este procedimento pressupõe que o UPDATE seja a etapa final da lógica de negócios. Se ocorrerem modificações ou exclusões subsequentes, continue investigando as operações de SQL relacionadas.

    • Cenários:

      • AUTOCOMMIT está desativado e a instrução SQL não foi confirmada: O AUTOCOMMIT estava desativado e nenhum COMMIT explícito foi emitido, portanto os dados não foram alterados.

      • ROLLBACK do thread: Todas as operações em uma transação têm sucesso ou falham juntas. Verifique se ocorreu um ROLLBACK após esta solicitação.