2013/12/3 Fabio Barros <[email protected]>
> Boa tarde!
>
> Estou postando minha primeira dúvida na lista, e agradeço possíveis
> comentários.
>
>
Opa. Seja bem-vindo.
> Fiz um REINDEX em uma tabela com cerca de 15 milhões de registros, com
> cerca de meia dúzia de índices, e como meu disco é pequeno, acabou o espaço
> no mesmo.
>
>
Isso realmente pode acontecer. Pois para fazer um REINDEX, o PostgreSQL de
fato reescreve cada índice num novo arquivo, e, somente ao final, apaga o
arquivo anterior. Ou seja, um REINDEX vai ocupar pelo menos o dobro de
espaço em disco (fora os logs de transação).
> Percebi que o tamanho físico do database subiu de 9GB para 15GB, e ao
> pesquisar, identifiquei vários arquivos perdidos na mesma, que justificam
> esse crescimento.
>
>
Acredito que os arquivos se referem aos indices da tabela em questão, e
> agora preciso 'limpar' esses arquivos do database.
>
>
Como você verificou que esses arquivos estão sobrando? Tem certeza que não
há logs de transação (diretório pg_xlog) que não foram arquivados?
Para verificar os data files, uma consulta que pensei aqui é a seguinte
(não vai funcionar com tablespaces, teria que adaptar):
SELECT * FROM (SELECT pg_ls_dir('base/'||(SELECT oid FROM pg_database WHERE
datname = current_database())) AS datafile) ls WHERE ls.datafile ~
'^[0-9]+$' AND ls.datafile NOT IN (SELECT pg_relation_filenode(oid)::text
FROM pg_class);
Elá irá retornar arquivos que são "fantasmas". Além desses podem ter outros
forks, por exemplo, a consulta pode retornar o 1234, daí pode ter de fato
também o 1234.1, 1234.2, 1234_vm, 1234_fsm, etc.
Olhando assim eu não vejo como esses arquivos poderiam estar sendo usados
pelo PostgreSQL, e, por isso, poderia apagá-los. Mas... Isso pode ser
ARRISCADO. Faça um backup base e faça testes em outro ambiente (não em
produção).
> Para testes, fizemos um dump/restore e o espaço ocupado fisicamente voltou
> para os 9GB, mas temos o inconveniente de não poder fazer nada na base de
> dados enquanto o processo é feito.
>
> Posso simplesmente remover os arquivos 'perdidos'?
>
>
Primeiro mapeie quais são esses arquivos, com a consulta acima. Poste o
resultado aqui e vamos analisar. Ok?
> Há outro meio, mais seguro, de se fazer isso?
>
> Desde já, agradeço as possíveis sugestões.
>
> []´s
>
>
>
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
