Voltando a falar um pouco sobre o banco de dados PostgreSQL, quero trazer aqui um tema básico que noto que alguns DBA’S iniciantes na carreira não tem conhecimento. Para iniciar este artigo quero deixar uma pergunta, o que ocorre no momento em que deletamos um registro em uma tabela no SQL Server.
Se você não conhece a resposta desta pergunta vou deixar como dica um artigo que postei já faz algum tempo aqui no Guia DBA onde falo um pouco mais sobre Ghost Cleanup, neste artigo pretendo dar uma pincelada e partir para o N_Tul_del do PostgreSQL.
Segue artigo sobre Ghost Cleanup:
Clique aqui para ler o artigo.
Ghost Cleanup – Introdução
No SQL Server no momento em que realizamos um DELETE FROM o registro não é deletado no momento exato em que verificamos a informação de 1 registro afetado, isso é dado pois o SQL Server teria um custo imenso para retornar os dados em um ROLLBACK, pois quando deletamos um registro pordemos afetar um numero x de índices nonclustered, índice clustered e a tabela fisica.
Para resolver isso o SQL Server “marca” o registro e de tempos em tempos os registros que estão marcados são deletados. Hoje no SQL Server podemos observar o ghost cleanup através do DBCC PAGE conforme mostrado no artigo acima indicado e na imagem 1.
Imagem 1 – Página de dados
No PostgreSQL temos uma operação parecida teóricamente com a do SQL Server, onde o registo não é deletado em um primeiro momento, sendo que isso se aplica a UPDATE e DELETE, na minha opinião isso faz com que a base de dados cresça desnecessáriamente, mas vamos acompanhar o artigo para verificarmos como ocorre.
Quando realizamos uma alteração ou exclusão no PostgreSQL é criado um novo registro no banco de dados e o registro anterior é marcado como “não valido” e a partir deste momento o PostreSQL passa a não mas acessa-lo.
A partir da imagem 2 podemos observar como é realizada a operação internamente no PostgreSQL quando realizamos UPDATE em um registro.
Imagem 2 – Operação de Update
Ao analisar a imagem 2 podemos notar que o registro 5 foi alterado e com isso foi criado um novo registro e assim o registro 5 é marcado como “não valido”.
Para comprovar está teoria utilizando o PostgreSQL temos que habilitar o coletor de dados e para isso é necessário que seja realizada uma alteração no arquivo de configuração do PostgreSQL (postgresql.conf).
Ao acessar o arquivo você deverá habilitar e descomentar o log_statement_stats conforme mostrado na imagem 3.
Obs: o caracter # indica que a linha está comentada.
Imagem 3 – Habilitando o coletor de estatísticas PostgreSQL
Após habilitar o log_statement_status você terá acesso a algumas views próprias do coletor de dados e a view pg_stat_all_tables é a responsável por guardar as informações de dados que foram alterados ou deletados que estão com o status de “não válidos”.
A view retorna informação de todas as tabelas do banco de dados e as colunas n_tup_upd e N_Tun_del que indicam que ali contem arquivos “não validos” seja por exclusão do registro ou por alteração conforme mostrado na imagem 4.
Imagem 4 – View pg_stat_all_tables
A imagem 4 foi retirada do Google Imagens
