Aula - 7 - Apostila Funcionamento Interno Do PostgreSQL - Transações

Sidymar Ramos Prexedes / sprexedes@hotmail.
com
Curso 801
Administração
PostgreSQL com Alta
Performance
Versão 2015_3.0
Sidymar Ramos Prexedes / sprexedes@hotmail.com
Administração PostgreSQL com Alta

Performance
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Funcionamento Interno do Postgres –

Transações
Objetivos da aula:
➢ MVCC – Multiversion Concurrency Control
➢ Vacuum e analyze
➢ Vacuum Full
➢ Freeze e Autovacuum
➢ Locks e deadlocks
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
IT Experience
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
MVCC
➢ Permite aderência a norma ACID;

➢ Permite o uso de uma mesma linha por várias transações
concorrentes, shared row lock;
➢ Transação que altera linha, cria nova versão alterada e a
identifica com seu número;
➢ Através do número da transação sabe-se a versão vigente
da linha para cada transação concorrente;
➢ Tuplas mortas.
O controle de versão é a característica do PostgreSQL que permite que ele

atenda plenamente à norma ACID. O MVCC permite o isolamento entre as diversas
transações de banco de dados ocorrendo simultaneamente.
O princípio de funcionamento de um controle de versão é simples: uma

transação deve manter consistência durante sua vida, mesmo que outras transações
estejam modificando os dados ao mesmo tempo. Na prática, os dados utilizados por
uma transação só podem ser modificados por ela mesma, para ela.
Mas como fazer com que uma transação que alterou um dado não propague
esta alteração para uma transação concorrente?
Alguns bancos de dados implementam o full row lock, ou trava completa da

linha. Se uma linha foi alterada por uma transação, transações concorrentes não
podem visualizar esta linha, até que a transação que a modificou termine. Isto não
implementa completamente a norma ACID.
O MVCC implementado pelo PostgreSQL utilize um modelo share row lock, ou

trava compartilhada da linha. Quando uma linha é alterada por uma transação ela
pode ser lida por outra transação simultânea, porém, essa transação simultânea verá
uma versão do dado original, até que termine sua vida.
A transação que alterou o dado já terá a nova versão, assim como novas
transações que venham após o término daquela que fez a alteração, respeitando
totalmente a norma ACID.
O MVCC funciona internamente de maneira igualmente simples. Ao alterar

uma linha em uma tabela, o PostgreSQL não altera a linha original, mas sim, cria
uma nova linha semelhante, com as alterações solicitadas. Essa nova linha é
chamada de nova versão.
Para identificar as versões, o PostgreSQL utiliza duas colunas xmin e xmax, e

utilizando o número de transação – xID – . Na coluna xmin é definido a partir de qual
transação esta tupla é visível, na xmax até qual transação a tupla é visível
O número das transações é sequencial de 32 bits. Cada transação recebida

pelo PostgreSQL recebe esse número.
Laboratório Dexter
Informações sobre transações:
● Verificar o xID de uma transação através da função

txid_current()
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
Executar os comandos na
máquina DB Master
# su - postgres
1
$ psql dexter;
2
=# BEGIN;
3
=# SELECT txid_current();
4
=# COMMIT;
5
=# BEGIN;
6
=# SELECT txid_current();
7
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
máquina DB Master
8=# INSERT INTO clientes

(cpf_cnpj,nome_razao,email,telefone) VALUES
('12345678901','SuperX','vendas@superx.com','1133445
566');
9=# COMMIT;
10 =# SELECT xmin,xmax,* FROM clientes where

nome_razao = 'SuperX';
Quando uma tupla é inserida, apenas a coluna “xmin” é preenchida com a

número da transação atual, de forma que a tupla só é visível a partir da transação
<VALOR_DA_TRANSAÇÃO>;
Quando uma linha é atualizada a tupla atual tem seu xmax preenchido pelo
número da transação atual e seu conteúdo copiado para uma nova tupla contendo o
xmin com o número da transação atual.
Quando uma linha é deletada, apenas seu xmax é preenchido com o número
da transação corrente.
Para saber com qual versão de uma linha é valida para uma transação, basta
verificar se o número da transação atual (txid) for maior que o xmin e menor que o
xmax. Matematicamente txid > xmin e txid < xmax.
Quando todas as transações que dependem de uma determinada versão da

linha terminaram, esta versão da linha se torna obsoleta, porém, ela permanece no
arquivo de dados ocupando espaço físico. As versões de uma linha são chamadas de
tuplas (tuples). Uma versão obsoleta é chamada de tupla morta (dead tuple).
Vacuum e Analyze
➢ Tuplas mortas:
● update
● delete
● insert
➢ Vacuum – Marca tuplas mortas para
reaproveitamento;
➢ Analyze – Gera estatística das tabelas.
10
Como visto anteriormente, no modelo MVCC, algumas operações deixam

tuplas mortas nas tabelas, de forma que é necessário existir um mecanismo para
prevenir o acumulo destas tuplas, pois do contrario as tabelas iriam crescer
indefinidamente e ficarem inchadas de tuplas mortas. Para que isso não ocorra o
PostgreSQL possui um mecanismo chamado vacuum, o qual marca tuplas mortas de
uma tabela para reaproveitamento.
Operações que geram tuplas mortas:
● UPDATE
● DELETE
● INSERT (somente quando ocorre rollback)
Laboratório Dexter
máquina DB Master
Informações sobre tuplas mortas:
● Verificar a quantidade de tuplas mortas presente em

uma tabela utilizando a view pg_stat_user_tables:
=# SELECT relname,n_live_tup,n_dead_tup FROM

1
pg_stat_user_tables where relname = 'clientes';
2 =# ANALYZE clientes;
3 =# SELECT relname,n_live_tup,n_dead_tup FROM

11
Neste caso o resultado indica que existem 4 tuplas mortas e 1 tupla viva.
Porém, quando consultada a tabela, verifica-se que o número de registros da tabela
não reflete no número de tuplas vivas apresentada. Isso ocorre devido ao fato das
estatísticas estarem desatualizadas.
Outra rotina fundamental no PostgreSQL é o analyze, cuja função é gerar

estatísticas das tabelas, as quais serão utilizadas pelo planejador de consultas para
decidir o tipo de busca mais eficiente.
Tanto o vacuum quanto o analyze podem ser executados manualmente

através de comandos SQL.
Laboratório Dexter
máquina DB Master
Informações sobre tuplas mortas:
4=# VACUUM clientes;
5=# ANALYZE clientes;
6=# SELECT relname,n_live_tup,n_dead_tup FROM

7=# \q
8$ exit
12
Vale ressaltar que o vacuum não elimina as tuplas mortas, ele apenas as
marca para serem reutilizadas por novos dados modificados na tabela.
Vacuum
➢ Para evitar picos de IO é possível definir custos e limites:
● vacuum_cost_delay = 0ms
● vacuum_cost_page_hit = 1
● vacuum_cost_page_miss = 10
● vacuum_cost_page_dirty = 20
● vacuum_cost_limit = 200
13
Para evitar picos de IO durante a execução do vacuum, é possível definir um

custo máximo através da opção vacuum_cost_limit e um período de pausa definido
na opção vacuum_cost_delay.
Este custo é baseado nos valores das seguintes opções:
● vacuum_cost_page_hit: “Custo” estimado para fazer limpeza de uma página

encontrada em memória.
● vacuum_cost_page_miss: Similar ao item anterior, porém para páginas
encontradas em disco.
●
vacuum_cost_page_dirty: Similar ao item vacuum_cost_page_miss, só que com
modificação da página.
Autovacuum
➢ Dispara rotinas de vacuum e analyze conforme
necessidade;
➢ Deve permanecer ligado “autovacuum=on”;
➢ Não deve impactar;
➢ Para manter histórico de execução recomenda-se habilitar
o log através da opção:
“log_autovacuum_min_duration=0”
14
Agendar ou executar o vacuum e o analyze manualmente não são maneiras

eficientes de manter seu banco de dados, pois as operações realizadas por
aplicações na maioria dos bancos de dados não seguem uma ordem cronológicas
fixa.
Para manter seu banco livre de tuplas mortas e com as estatísticas

constantemente atualizadas o PostgreSQL utiliza-se do autovacuum, que é o
mecanismo que dispara operações de vacuum e analyze conforme necessidade.
Autovacuum é um processo fundamental para o PostgreSQL e não deve

impactar no desempenho banco, porem é possível desabilitá-lo na opção
autovacuum.
Para manter histórico e auxiliar em futuros ajustes é possível registrar em log

as operações realizadas pelo autovacuum através da opção
log_autovacuum_min_duration. Nesta opção definimos o tempo mínimo de execução
para que seja registrada, caso definido para 0 todas as operações serão registradas.
A memória utilizada pelas operações de vacuum e analyze são limitadas ao

valor definido na opção maintenance_work_mem, caso este valor seja ultrapassado a
operação continua, porem utilizando arquivos temporários em disco.
É importante ajustar este valor corretamente, pois se for muito pequeno

acarreta na demora para finalização dos processos de vacuum ou analyze e se for
muito grande pode levar o servidor a utilizar swap e prejudicar o desempenho do
banco.
Um bom número para se utilizar na autovacuum_max_workers é o número de

tabelas grandes(que se destacam) acrescido de 1, pois dessa forma mesmo que os
processos fiquem muito tempo nas tabelas grandes, sempre terá um processo
sobrando para outras tabelas.
Autovacuum
➢ autovacuum_max_workers = 3
➢ autovacuum_naptime = 1min
➢ autovacuum_vacuum_threshold = 50
➢ autovacuum_analyze_threshold = 50
➢ autovacuum_vacuum_scale_factor = 0.2
➢ autovacuum_analyze_scale_factor = 0.1
➢ autovacuum_vacuum_cost_limit = -1
16
Assim como os processos do WAL writer e BgWriter o autovacuum também

pode ''dormir'' em intervalos de tempo, o qual é definido na opção
autovacuum_naptime.
O autovacuum possui uma série de opções que determinam quando as

operações devem executadas:
● autovacuum_max_workers: Número máximo de processos autovacuum (exceto

o lançador autovacuum) que possam estar em execução a qualquer momento. O
padrão é três. Este parâmetro só pode ser definido na inicialização;
● autovacuum_naptime: Especifica o atraso mínimo entre autovacuum executado

em um determinado banco de dados. Em cada rodada o daemon examina o
banco de dados e questões VÁCUO e analisar comandos conforme necessário
para tabelas no banco de dados. O atraso é medido em segundos, e o padrão é
um minuto (1min);
● autovacuum_vacuum_threshold: Número mínimo de tuplas atualizadas ou

removidas para disparar um VACUUM em uma tabela. (Valor padrão: 50);
● autovacuum_analyze_threshold: Número mínimo de tuplas inseridas,

atualizadas ou removidas para disparar um ANALYZE em uma tabela. (Valor
padrão: 50).
● autovacuum_analyze_scale_factor: Fração da tabela a adicionar sobre

autovacuum_analyze_threshold ao decidir quando disparar um VACUUM. (Valor
padrão: 0.1);
● autovacuum_vacuum_cost_delay: Especifica o intervalo de tempo a esperar

após atingido o limite de custo do VACUUM. Um valor -1 fará com que seja
obedecido o parâmetro vacuum_cost_delay.(Valor padrão: 20ms);
● autovacuum_vacuum_cost_limit: Especifica o custo limite que pode ser atingido

pelo VACUUM antes de esperar pelo tempo em autovacuum_vacuum_cost_delay.
Um valor -1 fará com que vacuum_cost_limit seja obedecido. O custo a ser
atingido será a somatória dos custos de todos os processos que estiverem
rodando simultaneamente. (Valor padrão: -1).
Para permitir ajustes finos, as opções acima podem ser configurados por tabela.
Autovacuum
➢ Levando em conta os valores padrões e supondo que

a tabela X tenha 100 registros, a operação de vacuum
só sera disparada quando o número de tuplas
modificadas/inseridas for 50 + (100*0.2) = 70, e
operação de analyze quando o número de tuplas
modificadas/inseridas for de 50 + (100*0.1) = 60.
18
Os valores padrões de autovacuum_vacuum_threshold e

autovacuum_analyze_threshold, na maioria dos casos, são relativamente altos e
podem acabar deixando muito trabalho acumulado o que podem causar picos de
atividade. O ideal é que se evite estes picos, e que se mantenha o autovacuum
trabalhando continuamente e assim evitando acumulo de trabalho.
Inicialmente pode-se utilizar valores por volta de 0.05 para

autovacuum_vacuum_threshold e 0.02 para autovacuum_analyze_threshold.
Vacuum Full
➢ Normalmente não tem necessidade;
➢ Somente em casos extremos;
➢ Dump e restore pode substituir o procedimento.
19
O vacuum full é um comando que só pode ser realizado manualmente, e ao

contrario do ``vacuum'' ele realmente remove as tuplas mortas e diminui o tamanho
físico da tabela pois a tabela é copiada e totalmente reescrita.
O vacuum full, tem vários aspectos negativos:
● Para realizar esta operação é necessário ter espaço livre em disco equivalente ao
dobro do tamanho atual da tabela, pois a tabela é duplicada durante a operação
(versão 9.1 ou superior).
● É um processo lento (foi aprimorado na versão 9.1)
●
Faz lock exclusivo em toda a tabela.
● Recomenda-se recriar os índices após esta operação.
● Não pode ser executado sobre tabelas em produção.
Com o autovacum ativado e bem configurado, não existe necessidade de se

utilizar o vacuum full. O vacuum full só deve ser utilizado em casos extremos.
A operação de vacuum full pode ser substituída pela exportação e importação

(pg_dump e pg_restore). Nas versões 9.0 ou anteriores, prefira a operação cluster ao
invés do vacuum full. Ela é similar ao funcionamento do vacuum full nas versões 9.1
ou superiores e também permite organizar a tabela na ordem de um índice.
Freeze
➢ O modelo MVCC, o PostgreSQL utiliza o número de

transação (XID) para determinar a visibilidade da tuplas. O
XID é um número inteiro de 32bits, o que limitaria a 4
bilhões de transações até que tenha que ser zerado.
➢ Porém esta volta ao 0 poderia trazer problemas, pois
todas as tuplas estariam no futuro e não seriam mais
acessíveis. Para evitar que isto ocorra, antes que se atinja
o limite o vacuum marca as tuplas com um XID especial
denominado FroozenXID, de modo a indicar que esta
tupla encontra-se no passado.
20
Durante a execução do vacuum todas as tuplas analisadas que tiverem idade

(em número de transações) maior que o valor definido em vacuum_freeze_min_age
terão seus XIDs substituídos pelo o FroozenXID.
Sabe-se que o vacuum, por padrão, só analisa as páginas onde existem tuplas
mortas, porem é necessário que a tabela seja analisada por completo quando
alcança determinada idade, a qual é definida em vacuum_freeze_table_age.
Através da opção autovacuum_freeze_max_age é definido o limite de idade

para que seja executado vacuum em uma tabela (mesmo com o autovacuum
desligado).
Locks e Deadlocks
➢ Implícitos ou explícitos;
➢ Compartilhados ou exclusivos;
➢ Timeout para deadlocks “deadlock_timeout”;
➢ É possível registrar em log transações aguardando
por lock em tempo maior que “deadlock_timeout”
habilitando através da opção “log_lock_waits”
21
O uso de locks no PostgreSQL pode ser implícito em algumas operações, ou

de forma explicita (solicitada pelo cliente). Os locks podem ser exclusivos ou
compartilhados.
Situações onde uma transação depende da liberação de um lock de uma

segunda transação para finalizar, porem a segunda também depende da primeira é
chamada de deadlock. Pelo fato dos deadlocks serem uma situação onde as
transações são dependentes entre si, elas ficarão aguardando indefinidamente e
nunca seriam finalizadas.
Para evitar que transações em deadlock fiquem presas para sempre, o

PostgreSQL utiliza um tempo de timeout definido na opção deadlock_timeout para
finalizar transações neste estado.
Laboratório Dexter
Alteração do postgresql.conf - Máquina DB Master
➢ Tarefas:
● Testar diretivas de configurações no postgresql.conf;

● Verificar o funcionamento do armazenamento físico;
● Verificar o funcionamento do Multiversion Concurrency
Control;
● Verifique através dos logs o acontece ao servidor;
● Restaure o valor das diretivas para o padrão.
22
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
máquina DB Master
Diretivas do postgresql.conf:
a) max_connections
1# vim /etc/postgresql/9.4/main/postgresql.conf
....
max_connections = 3000
23
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
máquina DB Master
b) shared_buffers
....
shared_buffers = 256MB
24
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
máquina DB Master
c) maintenance_work_mem
....
maintenance_work_mem = 256MB
25
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
máquina DB Master
d) checkpoint_segments
....
checkpoint_segments = 50
26
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
máquina DB Master
e) autovacuum
....
autovacuum = off
6# service postgresql restart
7# tail -f /var/log/postgresql/postgresql-9.4-main.log
27
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
máquina DB Master
Funcionamento do armazenamento físico:
a) Descubra o OID do banco de dados "dexter" e encontre-

o no seu sistema de arquivos. Descreva a estrutura
encontrada;
# su - postgres
1
$ psql
2
# SELECT datid FROM pg_stat_database WHERE datname =

3
'dexter';
28
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Laboratório Dexter
máquina DB Master
Funcionamento do armazenamento físico:
b) Descubra o OID da tabela "clientes" e encontre-a no
seu sistema de arquivos. Descreva a estrutura encontrada.
4# SELECT relid FROM pg_stat_all_tables WHERE relname

= 'clientes';
29
Neste momento existe um lock compartilhado na tupla atualizada.

Laboratório Dexter
máquina DB Master
Verificar o funcionamento do MVCC:
● Terminal A
1=# \c dexter
2=# BEGIN;
3=# UPDATE clientes SET nome_razao = 'SuperX10' WHERE

id = 1;
● Terminal B
4=# SELECT * FROM clientes WHERE id = 1;
O QUE ACONTECEU?
30
Neste momento a transação B vai obter lock compartilhado na tupla de id 2 e

ficar esperando para obter o lock compartilhado na tupla de id 1;
Laboratório Dexter
máquina DB Master
Verificar funcionamento do MVCC:
➢ Terminal B
=# UPDATE clientes SET nome_razao = 'SuperX10' WHERE

5
id = 1;
➢ Terminal C
#
6 ps aux | grep idle
O QUE ACONTECEU?
31
Neste momento ocorre a situação de deadlock, temos a transação B

aguardando para obter o lock compartilhado na tupla 1 (que no momento pertence a
transação A) e a transação A aguardando para obter o lock compartilhado na tupla 2
(que no momento pertence a transação B). Após a detecção do deadlock a transação
é finalizada.
Existe também a opção log_lock_waits, que quando habilitada, registra em log

qualquer transação que esteja esperando para obter lock a um tempo maior que o
tempo definido na opção deadlock_timeout. Esta opção é útil para determinar se
locks estão causando problemas de desempenho.
Laboratório Dexter
máquina DB Master
Verificar funcionamento do MVCC:
➢ Terminal A
=# COMMIT;
7
➢ Terminais B e A
=#
8 SELECT * FROM clientes WHERE id = 1;
QUAL FOI O RESULTADO?
32
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Próximos Passos
Para que você tenha um melhor aproveitamento do curso, participe

das seguintes atividades disponíveis no Netclass:
➢ Resolver o Desafio para exibir as senhas dos funcionários a

partir do armazenamento físico e postar o resultado no Fórum
Temático;
➢ Responder as questões do Teste de Conhecimento.
Mãos à obra!
33

Aula - 7 - Apostila Funcionamento Interno Do PostgreSQL - Transações

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula - 7 - Apostila Funcionamento Interno Do PostgreSQL - Transações

Enviado por

Direitos autorais:

Formatos disponíveis

Sidymar Ramos Prexedes / sprexedes@hotmail.

Administração PostgreSQL com Alta

Funcionamento Interno do Postgres –

➢ MVCC – Multiversion Concurrency Control

➢ Permite aderência a norma ACID;

O controle de versão é a característica do PostgreSQL que permite que ele

O princípio de funcionamento de um controle de versão é simples: uma

Alguns bancos de dados implementam o full row lock, ou trava completa da

O MVCC implementado pelo PostgreSQL utilize um modelo share row lock, ou

O MVCC funciona internamente de maneira igualmente simples. Ao alterar

Para identificar as versões, o PostgreSQL utiliza duas colunas xmin e xmax, e

O número das transações é sequencial de 32 bits. Cada transação recebida

Informações sobre transações:

● Verificar o xID de uma transação através da função

8=# INSERT INTO clientes

10 =# SELECT xmin,xmax,* FROM clientes where

Quando uma tupla é inserida, apenas a coluna “xmin” é preenchida com a

Quando todas as transações que dependem de uma determinada versão da

Como visto anteriormente, no modelo MVCC, algumas operações deixam

Operações que geram tuplas mortas:

● Verificar a quantidade de tuplas mortas presente em

=# SELECT relname,n_live_tup,n_dead_tup FROM

pg_stat_user_tables where relname = 'clientes';

3 =# SELECT relname,n_live_tup,n_dead_tup FROM

Outra rotina fundamental no PostgreSQL é o analyze, cuja função é gerar

Tanto o vacuum quanto o analyze podem ser executados manualmente

4=# VACUUM clientes;

5=# ANALYZE clientes;

6=# SELECT relname,n_live_tup,n_dead_tup FROM

➢ Para evitar picos de IO é possível definir custos e limites:

Para evitar picos de IO durante a execução do vacuum, é possível definir um

Este custo é baseado nos valores das seguintes opções:

● vacuum_cost_page_hit: “Custo” estimado para fazer limpeza de uma página

➢ Dispara rotinas de vacuum e analyze conforme

➢ Deve permanecer ligado “autovacuum=on”;

➢ Não deve impactar;

➢ Para manter histórico de execução recomenda-se habilitar

o log através da opção:

Agendar ou executar o vacuum e o analyze manualmente não são maneiras

Para manter seu banco livre de tuplas mortas e com as estatísticas

Autovacuum é um processo fundamental para o PostgreSQL e não deve

Para manter histórico e auxiliar em futuros ajustes é possível registrar em log

A memória utilizada pelas operações de vacuum e analyze são limitadas ao

É importante ajustar este valor corretamente, pois se for muito pequeno

Um bom número para se utilizar na autovacuum_max_workers é o número de

Assim como os processos do WAL writer e BgWriter o autovacuum também

O autovacuum possui uma série de opções que determinam quando as

● autovacuum_max_workers: Número máximo de processos autovacuum (exceto

● autovacuum_naptime: Especifica o atraso mínimo entre autovacuum executado

● autovacuum_vacuum_threshold: Número mínimo de tuplas atualizadas ou

● autovacuum_analyze_threshold: Número mínimo de tuplas inseridas,

● autovacuum_analyze_scale_factor: Fração da tabela a adicionar sobre

● autovacuum_vacuum_cost_delay: Especifica o intervalo de tempo a esperar

● autovacuum_vacuum_cost_limit: Especifica o custo limite que pode ser atingido

➢ Levando em conta os valores padrões e supondo que

Os valores padrões de autovacuum_vacuum_threshold e

Inicialmente pode-se utilizar valores por volta de 0.05 para

➢ Normalmente não tem necessidade;

➢ Somente em casos extremos;

➢ Dump e restore pode substituir o procedimento.

O vacuum full é um comando que só pode ser realizado manualmente, e ao

O vacuum full, tem vários aspectos negativos:

Com o autovacum ativado e bem configurado, não existe necessidade de se