Início / dba / Perguntas / 323452
Accepted
EM0
Asked: 2023-02-14 01:25:48 +0800 CST

pg_stat_user_tables tem n_live_tup = 0 e last_autonalyze = null para a maioria das tabelas - por que as tabelas não estão sendo analisadas?

  • 772

Semelhante a Quais são os possíveis significados de NULL e zero para autovacuum_count, last_autovacuum e autoanalyze_count no PostgreSQL? exceto no meu caso, é PostgreSQL 15.1 e não há exclusões - apenas os dados são inseridos.

Eu tenho um banco de dados com algumas tabelas particionadas e algumas não particionadas também. Algumas das partições têm centenas de milhões de linhas, mas n_live_tup é 0 para elas e vacuum_count, autovacuum_count, analyze_count, autoanalyze_count são todos 0.

Apenas as 2 últimas tabelas criadas (ambas as partições) têm autoanalyze_count = 1 e 4, respectivamente, e têm n_live_tup > 0. Existem, no entanto, algumas outras tabelas com n_live_tup > 0 (apesar de nenhuma análise ter sido executada nelas).

        select relname, n_live_tup, last_vacuum, last_autovacuum, last_analyze, last_autoanalyze, vacuum_count, autovacuum_count, analyze_count, autoanalyze_count
        from pg_catalog.pg_stat_user_tables
        where schemaname = 'myschema'

resultados

Observe que n_live_tup para event_59 está totalmente errado aqui e a tabela realmente tem> 1,1 bilhão de linhas (essa é a maior).

Tentei configurar log_autovacuum_min_duration = 0conforme sugerido na pergunta vinculada, mas parece não ter registrado nada até agora.

Por que minhas tabelas não estão sendo analisadas?

Editar 1: agora até as estatísticas dessas tabelas foram redefinidas:

estatísticas atualizadas

O servidor não travou desde então - pg_postmaster_start_time()retorna 2023-02-13 17:02:32.365095+00(foi quando eu o reiniciei). Como você pode ver na primeira captura de tela, a análise automática foi executada logo depois disso. Os logs mostram que ele foi executado novamente às 20:10:18, mas, apesar disso, todas as contagens de análise/vácuo são 0 e n_live_tup diminuiu.

Corri manualmente analyze event_241e n_live_tup tornou-se preciso. Reiniciei o PG depois e isso não redefiniu a contagem, então não sei por que foi redefinido durante a noite.

Editar 2: Acontece que o servidor está travando todas as noites quando os backups do pg_dump são executados, mas aparentemente sem que o processo do postmaster seja reiniciado, porque pg_postmaster_start_time()continua retornando o mesmo valor. Posso reproduzir facilmente a falha pg_dumping de um banco de dados específico (não aquele sobre o qual esta postagem é).

2023-02-17 09:04:16.607 UTC [27083] postgres@problematic_database LOG:  connection authorized: user=postgres database=problematic_database application_name=pg_dump
2023-02-17 09:04:16.609 UTC [27083] postgres@problematic_database PANIC:  could not open critical system index 2662
2023-02-17 09:04:16.610 UTC [11922] LOG:  server process (PID 27083) was terminated by signal 6: Aborted
2023-02-17 09:04:16.610 UTC [11922] LOG:  terminating any other active server processes
2023-02-17 09:04:16.645 UTC [11922] LOG:  all server processes terminated; reinitializing
2023-02-17 09:04:17.176 UTC [27945] LOG:  database system was interrupted; last known up at 2023-02-17 09:03:24 UTC

Corrigir essa falha é um tópico separado, mas, para esta pergunta, estou me perguntando:

  1. Qual é a melhor maneira de monitorar se isso está acontecendo? Poderíamos verificar os logs em busca de palavras-chave, mas parece melhor verificar diretamente se as estatísticas estão sendo redefinidas, pois isso detectará isso e outros erros. É apenas uma questão de executar manualmente a análise em pelo menos uma tabela e, em seguida, pesquisar regularmente analyze_count = 0ou existe uma maneira melhor?
  2. Se detectarmos que as estatísticas foram redefinidas (devido a uma falha), parece uma boa ideia preencher analyzemanualmente as estatísticas novamente, certo? Mas então por que o PG não faz isso automaticamente após se recuperar de uma falha?
  3. Ou talvez seja uma boa ideia apenas executar o ANALYZE regularmente, digamos, semanalmente ou mesmo todas as noites? (Atualmente, leva ~ 200 segundos neste banco de dados - muito menos tempo do que o backup!)
postgresql

1 respostas

  1. Best Answer

    Existem múltiplas explicações possíveis:

    • uma falha redefinir as estatísticas

    • alguém ligou pg_stat_reset()ou uma função relacionada para redefinir as estatísticas

    • o banco de dados foi atualizado pg_upgradee ninguém executou ANALYZEdepois

    Para verificar quando as estatísticas foram redefinidas pela última vez para seu banco de dados, execute

    SELECT pg_stat_get_db_stat_reset_time(oid)
FROM pg_database
WHERE datname = current_database();

    Se for NULL, as estatísticas nunca foram redefinidas explicitamente.

    Sua investigação mais aprofundada mostrou que você tem corrupção de dados de catálogo, que trava o banco de dados diariamente. Se você tiver um bom backup, restaure-o. Caso contrário, desative o banco de dados imediatamente e faça um backup frio de todos os arquivos. Você pode tentar corrigir o problema iniciando o PostgreSQL com a -Popção e tente reconstruir o índice como superusuário:

    REINDEX INDEX pg_catalog.pg_class_oid_index;

    O objetivo é colocar o banco de dados em um estado em que você possa descartá-lo com êxito. Em seguida, restaure-o em um cluster recém-criado em um hardware bom. Não continue trabalhando com este cluster, mesmo que pareça OK novamente.

    • 1

relate perguntas