Uma equipe de infraestrutura de uma organização pública utiliza o PostgreSQL para o armazenamento de dados de processos eletrônicos com alto volume de operações de escrita (insert/update/delete). O DBA notou que o tamanho dos arquivos do banco de dados está crescendo de forma descontrolada e que mesmo após a exclusão de grandes volumes de dados, a performance das consultas tem diminuído progressivamente devido à fragmentação.
Considerando a arquitetura transacional do PostgreSQL e suas práticas de manutenção, o procedimento técnico mais adequado que um analista da equipe de infraestrutura recomendou para mitigar o crescimento excessivo dos arquivos de dados (bloat) e otimizar a performance do SGBD foi:
ARealizar o comando TRUNCATE em todas as tabelas afetadas, pois ele remove todas as tuplas e libera imediatamente o espaço em disco. Essa ação é mais eficiente do que o DELETE para operações de escrita e não causa bloqueios no sistema.
BDesabilitar o processo de Vacuuming (limpeza) automático, pois ele consome recursos da CPU durante o horário de pico. A equipe passaria a confiar apenas na exclusão de linhas com o DELETE, já que o sistema operacional se encarregaria de liberar o espaço não utilizado.
CAumentar o parâmetro shared_buffers no arquivo postgresql.conf para o valor máximo permitido pela memória RAM. Essa ação é a única necessária para garantir que todos os dados residam na memória e que o bloat seja completamente evitado.
DExecutar o comando VACUUM FULL nas tabelas mais afetadas periodicamente. Para o dia a dia, otimizar os parâmetros do Autovacuum (como autovacuum_vacuum_scale_factor e autovacuum_vacuum_cost_delay) e monitorar o bloat com a visão pg_stat_user_tables.
EMudar o IsolationLevel de todas as transações para SERIALIZABLE. Isso garante que não haja inconsistências de dados e, por consequência, o banco de dados não precisará do Multiversion Concurrency Control (MVCC), eliminando a raiz do problema de bloat.
Revelar gabarito e comentário▾
GabaritoD — Executar o comando VACUUM FULL nas tabelas mais afetadas periodicamente. Para o dia a dia, otimizar os parâmetros do Autovacuum (como autovacuum_vacuum_scale_factor e autovacuum_vacuum_cost_delay) e monitorar o bloat com a visão pg_stat_user_tables.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
PostgreSQL: Controle de Bloat e Manutenção com VACUUM
Gabarito: letra D. Para mitigar o crescimento excessivo dos arquivos de dados (bloat) e otimizar a performance, o procedimento mais adequado é executar o VACUUM FULL periodicamente nas tabelas mais afetadas, além de otimizar os parâmetros do Autovacuum e monitorar o bloat com a visão pg_stat_user_tables. Essa é a prática recomendada na arquitetura transacional do PostgreSQL, que utiliza o MVCC (Multiversion Concurrency Control) e, por isso, mantém tuplas mortas ocupando espaço até que o VACUUM seja executado.
O PostgreSQL, como um SGBD objeto-relacional, utiliza o controle de concorrência multiversão (MVCC) para permitir que leituras e escritas ocorram simultaneamente sem bloqueios. Nesse modelo, quando uma linha é atualizada ou excluída, a versão antiga da linha (tupla morta) não é removida fisicamente do arquivo de dados imediatamente. Ela permanece no disco até que o processo de limpeza (VACUUM) seja executado. Esse acúmulo de tuplas mortas é o que chamamos de bloat — o crescimento descontrolado dos arquivos de dados que, além de ocupar espaço, degrada a performance das consultas, pois o banco precisa varrer mais páginas para encontrar as tuplas vivas.
O comando VACUUM (sem o FULL) é a operação de manutenção rotineira que remove as tuplas mortas e marca o espaço como reutilizável para novas inserções. Ele pode ser executado manualmente ou, de forma automática, pelo processo Autovacuum, que é habilitado por padrão e gerencia a limpeza conforme a atividade do banco. Já o VACUUM FULL é uma operação mais agressiva: ele reescreve o conteúdo da tabela em um novo arquivo, compactando o espaço e eliminando a fragmentação. Porém, por exigir um bloqueio exclusivo na tabela durante a execução, ele não deve ser usado com frequência em tabelas de alto volume de escrita — apenas periodicamente, em janelas de manutenção.
Na prática, a estratégia recomendada para um ambiente com alto volume de operações de escrita é: (1) manter o Autovacuum ativo e ajustar seus parâmetros (como autovacuum_vacuum_scale_factor e autovacuum_vacuum_cost_delay) para que a limpeza ocorra de forma mais frequente e com menor impacto; (2) monitorar o nível de bloat nas tabelas usando a visão pg_stat_user_tables, que fornece estatísticas sobre o número de tuplas mortas e a atividade de VACUUM; e (3) executar o VACUUM FULL em tabelas específicas, em horários de baixa atividade, para eliminar a fragmentação residual que o VACUUM comum não resolve.
A pegadinha central desta questão é a confusão entre VACUUM e VACUUM FULL, e entre DELETE e TRUNCATE. O DELETE marca as linhas como mortas (gerando bloat), enquanto o TRUNCATE remove todas as linhas de uma vez e libera o espaço imediatamente — mas não é aplicável quando se deseja manter os dados ou quando a exclusão é seletiva. Além disso, desabilitar o Autovacuum ou mudar o nível de isolamento para SERIALIZABLE não resolve o problema do bloat, pois o MVCC é a base da arquitetura do PostgreSQL e não pode ser eliminado.
Guarde a distinção entre a manutenção rotineira (VACUUM + Autovacuum) e a manutenção pesada (VACUUM FULL): é exatamente essa fronteira que separa a alternativa correta das demais.
Procedimento
Descrição
Efeito sobre o bloat
Indicação
VACUUM (comum)
Remove tuplas mortas e marca espaço como reutilizável
Reduz o bloat, mas não compacta o arquivo
Rotina contínua (manual ou via Autovacuum)
VACUUM FULL
Reescreve a tabela em novo arquivo, eliminando fragmentação
Elimina o bloat residual e compacta o arquivo
Periódico, em janelas de manutenção (bloqueia a tabela)
TRUNCATE
Remove todas as linhas e libera espaço imediatamente
Elimina o bloat, mas destrói todos os dados
Não indicado para produção com dados seletivos
DELETE
Marca linhas como mortas (gera tuplas mortas)
Aumenta o bloat até que o VACUUM seja executado
Operação comum, mas exige limpeza posterior
Autovacuum
Processo automático que executa VACUUM e ANALYZE
Controla o bloat continuamente, sem intervenção manual
Habilitado por padrão; ajustar parâmetros (scale_factor, cost_delay)
Monitoramento (pg_stat_user_tables)
Fornece estatísticas de tuplas mortas e atividade de VACUUM
Permite identificar tabelas com maior acúmulo de bloat
Uso contínuo para orientar manutenção
Bloat no PostgreSQL: Causa (MVCC) (Tuplas mortas de UPDATE/DELETE, Espaço não liberado sem VACUUM); Manutenção rotineira (VACUUM (sem FULL), Autovacuum (padrão), Ajuste de parâmetros); Manutenção pesada (VACUUM FULL, Reescreve a tabela, Bloqueio exclusivo); Monitoramento (pg_stat_user_tables)
Alternativa A — ❌ Incorreta
O TRUNCATE remove todas as linhas de uma tabela de uma só vez e libera o espaço imediatamente, mas é uma operação destrutiva que não pode ser usada para mitigar o bloat em um ambiente de produção com dados de processos eletrônicos. Além disso, a afirmação de que ele "não causa bloqueios" é incorreta: o TRUNCATE adquire um bloqueio exclusivo (ACCESS EXCLUSIVE) na tabela, impedindo qualquer operação concorrente durante sua execução. O DELETE, por sua vez, gera tuplas mortas que precisam ser limpas pelo VACUUM — não é uma alternativa ao VACUUM, mas sim uma das causas do bloat.
Alternativa B — ❌ Incorreta
Desabilitar o Autovacuum é exatamente o oposto do que se deve fazer. O Autovacuum é o mecanismo automático que executa o VACUUM e o ANALYZE em segundo plano, evitando o acúmulo de tuplas mortas e a degradação da performance. Sem ele, o bloat cresceria de forma descontrolada, e o sistema operacional não tem nenhuma função de liberação de espaço dentro dos arquivos do banco — o espaço só é liberado pelo VACUUM. A exclusão com DELETE apenas marca as linhas como mortas, não libera espaço.
Alternativa C — ❌ Incorreta
Aumentar o shared_buffers é uma configuração importante para o desempenho, pois define a quantidade de memória compartilhada para o cache de páginas do banco. No entanto, não é "a única necessária" para evitar o bloat, e não é verdade que todos os dados residirão na memória — o shared_buffers é um cache, e os dados continuam sendo persistidos em disco. O bloat é causado pelo acúmulo de tuplas mortas no disco, e o shared_buffers não tem relação direta com esse problema. A memória RAM é limitada, e um banco de dados com alto volume de escrita sempre terá dados em disco.
Alternativa D — ✅ Correta ⟵ GABARITO
Esta alternativa descreve corretamente a prática recomendada. O VACUUM FULL é a operação que reescreve a tabela e elimina a fragmentação, sendo indicado para ser executado periodicamente nas tabelas mais afetadas pelo bloat. Para o dia a dia, a otimização dos parâmetros do Autovacuum (como autovacuum_vacuum_scale_factor, que define a fração de tuplas mortas que dispara a limpeza, e autovacuum_vacuum_cost_delay, que controla o impacto do processo na performance) é essencial para manter a limpeza automática eficiente. O monitoramento com a visão pg_stat_user_tables permite identificar quais tabelas estão acumulando mais tuplas mortas e quando o VACUUM foi executado pela última vez, orientando a tomada de decisão.
Alternativa E — ❌ Incorreta
O nível de isolamento SERIALIZABLE é o mais alto do PostgreSQL e garante a serialização das transações, evitando anomalias de concorrência. No entanto, ele não elimina o MVCC — pelo contrário, o MVCC é o mecanismo que permite implementar o SERIALIZABLE sem bloqueios excessivos. O bloat é uma consequência direta do MVCC, pois as versões antigas das linhas precisam ser mantidas para garantir o isolamento. Mudar o nível de isolamento não resolve o problema do bloat; a solução continua sendo o VACUUM.
NÃO CAIA NESSA!
A banca explora a confusão entre VACUUM (limpeza rotineira, sem bloqueio pesado) e VACUUM FULL (reescrita da tabela, com bloqueio exclusivo). A alternativa D é a única que combina corretamente a manutenção pesada periódica com a manutenção automática contínua. Cuidado também com a alternativa A: o TRUNCATE libera espaço, mas destrói os dados e bloqueia a tabela — não é uma solução para bloat em produção.
PEGA ESSA DICA!
Para questões sobre bloat no PostgreSQL, lembre-se do ciclo: DELETE/UPDATE geram tuplas mortas → o VACUUM (automático ou manual) remove as tuplas mortas e libera espaço para reutilização → o VACUUM FULL compacta o arquivo e elimina a fragmentação. O Autovacuum é o mecanismo padrão que executa o VACUUM automaticamente, e a visão pg_stat_user_tables é a ferramenta de monitoramento. Decore essa sequência e você acertará a maioria das questões sobre o tema.