Olá pessoal, boa tarde!

 

Estamos num dilema onde temos de apontar para uma solução, como segue:

 

Pontos

a) Temos 3 bases de dados, respectivamente (400GB, 800GB, 900MB)  sendo bi,
olap, middleware. 

b) Por necessidade desabilitamos o autovacuum por termos experimentado
alguns dissabores (quem sabe por deficiência em sua compreensão).

c) Implementamos scripts de manutenção (vacuumdb, analyze, reindex) semanais
e individuais para cada base de dados respeitando suas propriedades e
aplicações.

 

Dilema

Verificamos em algumas oportunidades que o helpdesk (nós) estamos sendo
contatados com muita freqüência pela madrugada devido ao “travamento”
(alegação de usuário) das aplicações (ou parte dela), ao “entrarmos no
circuito” de cara matamos a charada.

Determinados usuários deixam transações abertas, aplicativos abertos etc...
e com isto o vacuumdb para por ali “esperando” uma ação (ou finalização)
para que ele continue.

Para resolver temos as opções de terminate backend dos clientes ou do script
de manutenção para “voltar”.

 

Duvida

a) Será que nossa abordagem está equivocada quanto ao vacuumdb em relação a
estas oportunidades (que possivelmente irão ocorrer outras vezes) de os
clientes “esquecerem” a aplicação com transações em aberta?

b) Temos a possibilidade de implementar a opção statement_timeout, onde
determinaríamos um período de inatividade tipo (5 min), mas vimos no proprio
manual que não é recomendavel, o que acham?

c)  Nosso ERP nos permite esta opção, mas a empresa mantenedora disse que a
melhor opção é via banco de dados e plano de manutenção, será o caminho,
usar o ERP para controlar o timeout dele mesmo?

d) Quem já experimentou algo deste gênero e como chegou a um consenso
funcional?

 

Cenario

PostgreSQL 8.3.7 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.3.real
(Ubuntu 4.3.2-1ubuntu11) 4.3.2

Raid 1+0 (4 TB) SAS Hot

6 GB Ram

 

Conto com a opnião de vocês,

 

Att.

----------------------------------------------------------------------------

Rubens José Rodrigues

 

_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a