Há um DB com uma quantidade desconhecida de índices exclusivos corrompidos. Atualmente, eu os descubro um por um quando tento REINDEX DATABASE CONCURRENTLY <db_name>
, lidar com a violação de duplicação específica (manipulação de dados, principalmente exclusão de duplicações usando scripts), reindexar a tabela ou índice específico e continuar para o próximo índice (novamente, apenas logo após descobri-lo usando REINDEX DATABASE CONCURRENTLY
).
Sem mencionar que cada vez que recebo índices com o sufixo '_ccnew', que AFAIK são índices que tentaram ser criados por uma reindexação anterior simultaneamente, mas não puderam ser feitos, geralmente porque estão violando uma verificação de exclusividade. As tentativas fracassadas de reindexação simultânea ficarão lá e devem ser descartadas manualmente.
A reindexação simultânea é usada para evitar um desligamento.
Quero reduzir essas "viagens de ida e volta" de busca pela próxima violação e me pergunto se há uma maneira mais eficiente de obter dados gerais sobre o status de todas as corrupções de índice ou violações exclusivas que um banco de dados Postgres possui.
Você pode usar a extensão amcheck para verificar se há corrupção em um índice B-tree. Para outros tipos de índice, não há alternativa para reconstruir o índice.
Você pode executar o seguinte para verificar se há corrupção em um índice:
Isso pode ser automatizado para ser executado em todos os índices do seu banco de dados:
bt_index_check()
tem um segundo parâmetro opcional; se você fornecerTRUE
, a verificação levará muito mais tempo, mas verifique se todas as linhas da tabela estão indexadas.Note que isso
bt_index_check()
não cobre todos os tipos de corrupção de índice. Há tambémbt_index_parent_check()
, que testa mais completamente, mas requer umSHARE
bloqueio que impede a modificação simultânea de dados.