Otimização, monitoramento e solução de problemas de operações VACUUM no PostgreSQL
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento descreve os princípios básicos da operação VACUUM nos bancos de dados do PostgreSQL. Ela também descreve os mecanismos para monitorar e ajustar o mecanismo do banco de dados que mantém a integridade das instâncias do banco de dados.
O PostgreSQL usa um protocolo de simultaneidade baseado em snapshots que cria várias versões de linhas de dados durante a modificação de dados. Essas versões da linha de dados são usadas para ler uma versão visível dos dados usando um snapshot computado sem a necessidade de bloquear a leitura na linha de dados. O PostgreSQL mantém os IDs de transação (inseridos e excluídos) para cada linha de dados e os utiliza junto com o snapshot calculado para determinar a visibilidade da linha. Como os dados continuam crescendo devido às versões antigas de dados, o tempo necessário para verificar os dados (verificação de tabelas ou de índice) aumenta. Para otimizar o tempo de resposta da operação de verificação e usar o espaço de maneira eficiente, é preciso recuperar as versões e os metadados (por exemplo, ID da transação) que são usados para manter as versões.
A operação VACUUM recupera as versões excluídas (coleta de lixo) e os IDs de transação (congelar o ID da transação). A operação VACUUM atua em dados de modos diferentes com níveis diferentes de disponibilidade de dados. O congelamento dos IDs de transações é essencial para a integridade do sistema de banco de dados porque que ele bloqueia os gravadores sempre que o espaço do ID de transação usado entra no espaço reservado.
Os jobs autovacuum configurados tentam recuperar constantemente o
ID da transação, mas podem falhar. Essa falha ocorre devido à configuração insuficiente ou porque a taxa de criação dos IDs de transação é tão alta que o job autovacuum não consegue acompanhar a carga de trabalho. O objetivo deste documento é mostrar como usar as operações VACUUM com os mecanismos para ajustar e monitorar diferentes aspectos das operações VACUUM.
Visão geral
Este documento abrange o seguinte:
Como liberar IDs de transação.
Como monitorar IDs de transação.
Reivindicação de espaço de armazenamento.
Como configurar alertas automatizados do Cloud Monitoring.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-08 UTC."],[],[],null,["# Optimizing, monitoring, and troubleshooting VACUUM operations in PostgreSQL\n\nThis document describes the fundamentals of the `VACUUM` operation in\n[PostgreSQL](https://www.postgresql.org/)\ndatabases. It also describes the mechanisms to monitor and tune the database\nengine that maintains the health of database instances.\n\nPostgreSQL uses a snapshot-based concurrency protocol that creates multiple\nversions of data rows while modifying the data. These data row versions are used\nto read a visible version of the data using a computed snapshot without\nacquiring read-lock on the data row. PostgreSQL maintains transaction IDs\n(inserted and deleted transaction IDs) for every row of data and uses the\ntransaction IDs along with the computed snapshot to determine the visibility of\nthe row. As the data keeps growing due to old versions of data, the time taken\nto scan the data (table scan or index scan) increases. To optimize the response\ntime of the scan operation and to use space efficiently, you need to reclaim the\nversions and the metadata (for example, transaction ID) that is used to maintain\nthe versions.\n\nThe `VACUUM` operation reclaims the deleted versions (garbage collection) and\ntransaction IDs (freeze transaction ID). The `VACUUM` operation operates on data\nin different modes with different levels of data availability. Freezing\ntransaction IDs is crucial to the health of the database system because the\nsystem blocks writers whenever the used transaction ID space enters reserved\nspace.\n\nThe `autovacuum` jobs that you configure constantly try to reclaim the\ntransaction ID, but they can fail. This failure is either due to insufficient\nconfiguration or because the creation rate for transaction IDs is so high that\nthe `autovacuum` job cannot catch up with workload. The purpose of this document\nis to show how to use the `VACUUM` operations along with the mechanisms to tune\nand monitor different aspects of `VACUUM` operations.\n\nOverview\n--------\n\nThis document covers the following:\n\n- Freezing transaction IDs.\n- Monitoring transaction IDs.\n- Reclaiming storage space.\n- Configuring automated Cloud Monitoring alerts.\n\nTo read the full white paper, click the button:\n\n[Download the PDF](/static/solutions/optimizing-monitoring-troubleshooting-vacuum-operations-postgresql.pdf)"]]
