Bom dia!!! Pessoal, agradeço os comentários!!! Vamos lá, pretendo não prolongar mais o assunto, apenas vou registrar algumas observações em cima das respostas dadas, e pedir apenas uma confirmação se o que pretendo fazer está coerente. Para o real problema, disco cheio, estamos em processo de compra e troca dos HD, mas todas as trocas vão demorar uns 3 meses (trocamos 2 sites por semana), por isso a necessidade de uma solução temporária. Sobre como identifiquei arquivos mortos, não usei a consulta mencionada, apenas rodei um 'ls -l' na pasta do database com problema, e cruzei a informação com o que recuperei do catálogo, aí achei os arquivos 'perdidos'. Como gostaria de não ter que excluir manualmente esses arquivos, acredito que a solução temporária de excluir e recriar os índices seja a melhor pra gente. Pensei até em fazer um dump/restore da base, pois fizemos esse teste e todo o lixo sumiu, mas temos o problema de ter que parar o site. Bom, tenho ainda 2 perguntas, que acredito ser bem pontuais: 1 ) Qual o % de tuplas mortas que justificam executar o reindex / vacuum? 2 ) Estou correto sobre como pretendo dropar/recriar os indices? Basicamente, minha intenção é aproveitar a sintaxe de criação armazenada no catálogo de cada site que tem a tabela, para evitar interferência humana (criação errada ou falta de algum índice), e com isso garantir que os índices estarão exatamente como antes. []´s
From: [email protected] Date: Wed, 4 Dec 2013 14:01:01 -0200 To: [email protected] Subject: Re: [pgbr-geral] HD lotou no meio de um reindex 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
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
