Início / dba / Perguntas / 37028
Accepted
Vadim Samokhin
Asked: 2013-03-20 07:45:49 +0800 CST

VACUUM retornando espaço em disco para o sistema operacional

  • 772

VACUUMgeralmente não retorna espaço em disco para o sistema operacional, exceto em alguns casos especiais.
Dos documentos:

A forma padrão de VACUUMremove versões de linhas inativas em tabelas e índices e marca o espaço disponível para reutilização futura. No entanto, ele não retornará o espaço para o sistema operacional, exceto no caso especial em que uma ou mais páginas no final de uma tabela ficam totalmente livres e um bloqueio de tabela exclusivo pode ser facilmente obtido. Em contraste, VACUUM FULLativamente compacta as tabelas escrevendo uma nova versão completa do arquivo de tabela sem espaço morto. Isso minimiza o tamanho da tabela, mas pode levar muito tempo. Também requer espaço em disco extra para a nova cópia da tabela, até que a operação seja concluída.

A questão é: como esse estado de banco de dados pode one or more pages at the end of a table become entirely freeser alcançado? Isso pode ser feito via VACUUM FULL, mas não tenho espaço suficiente para implementá-lo. Então, existem outras possibilidades?

postgresql postgresql-9.2

1 respostas

  1. Best Answer

    Para devolver espaço ao SO, use VACUUM FULL. Enquanto estiver nisso, suponho que você corra VACUUM FULL ANALYZE. Cito o manual :

    FULL

    Seleciona vácuo "completo", que pode recuperar mais espaço , mas leva muito mais tempo e bloqueia exclusivamente a mesa. Esse método também requer espaço em disco extra, pois grava uma nova cópia da tabela e não libera a cópia antiga até que a operação seja concluída. Normalmente, isso só deve ser usado quando uma quantidade significativa de espaço precisa ser recuperada de dentro da tabela.

    Minha ênfase em negrito.

    CLUSTERconsegue isso, também, como um efeito colateral.

    Plain VACUUMnormalmente não atinge seu objetivo ( "uma ou mais páginas no final de uma tabela totalmente gratuita" ). Ele não reordena as linhas e apenas remove as páginas vazias do final físico do arquivo quando surge a oportunidade - como revela sua citação do manual.

    Você pode obter páginas vazias no final do arquivo físico quando você adiciona INSERTum lote de linhas DELETEantes que outras tuplas sejam anexadas. Ou pode acontecer por coincidência se linhas suficientes forem excluídas.

    Há também configurações especiais que podem impedir VACUUM FULLa recuperação de espaço. Ver:

    Preparar páginas vazias no final de uma tabela para teste

    A coluna do sistema ctidrepresenta a posição física de uma linha. Você precisa entender essa coluna:

    Podemos trabalhar com isso e preparar uma tabela excluindo todas as linhas da última página:

    DELETE FROM tbl t
USING (
   SELECT (split_part(ctid::text, ',', 1) || ',0)')::tid     AS min_tid
        , (split_part(ctid::text, ',', 1) || ',65535)')::tid AS max_tid
   FROM   tbl
   ORDER  BY ctid DESC
   LIMIT  1
   ) d
WHERE  t.ctid BETWEEN d.min_tid AND d.max_tid;

    Agora, a última página está vazia. Isso ignora gravações simultâneas. Ou você é o único a escrever nessa tabela ou precisa fazer um bloqueio de gravação para evitar condições de corrida.

    A consulta é otimizada para identificar rapidamente as linhas qualificadas. O segundo número de a tidé o índice da tupla armazenado como unsigned int2e 65535é o máximo para esse tipo ( 2^16 - 1), portanto, esse é o limite superior seguro.

    db<>fiddle aqui (reutilizando uma tabela simples de um caso diferente.)
    Old sqlfiddle

    Ferramentas para medir o tamanho da linha/tabela:

    Disco cheio

    Você precisa de espaço de manobra no disco para qualquer uma dessas operações. Há também a ferramenta da comunidade pg_repackcomo substituto para VACUUM FULL/ CLUSTER. Evita travas exclusivas, mas também precisa de espaço livre para trabalhar. O manual:

    Requer espaço livre em disco duas vezes maior que a(s) tabela(s) e índices de destino.

    Como último recurso, você pode executar um ciclo de despejo/restauração. Isso também remove todo o inchaço das tabelas e índices. Pergunta intimamente relacionada:

    A resposta ali é bem radical. Se sua situação permitir (sem chaves estrangeiras ou outras referências impedindo a exclusão de linhas) e sem acesso simultâneo à tabela), você pode apenas:

    Despeje a tabela em disco conectando de um computador remoto com bastante espaço em disco ( -apara --data-only):

    De um shell remoto, despeje os dados da tabela:

    pg_dump -h <host_name> -p <port> -t mytbl -a mydb > db_mytbl.sql

    Em uma sessão pg, TRUNCATEa tabela:

    -- drop all indexes and constraints here for best performance
TRUNCATE mytbl;

    Do shell remoto, restaure para a mesma tabela:

    psql -h <host_name> -p <port> mydb -f db_mytbl.sql
-- recreate all indexes and constraints here

    Agora está livre de quaisquer linhas mortas ou inchaço.

    Mas talvez você possa ter isso mais simples?

    • Você pode liberar espaço suficiente no disco excluindo (movendo) arquivos não relacionados?

    • Você pode VACUUM FULLdiminuir as tabelas primeiro, uma por uma, liberando espaço em disco suficiente?

    • Você pode executar REINDEX TABLEou REINDEX INDEXliberar espaço em disco de índices inchados?

    Faça o que fizer, não seja precipitado . Em caso de dúvida, faça backup de tudo em um local seguro primeiro.

    • 53

relate perguntas