Oi Rubens, > b) Por necessidade desabilitamos o autovacuum por termos experimentado > alguns dissabores (quem sabe por deficiência em sua compreensão).
Compreendo perfeitamente. > c) Implementamos scripts de manutenção (vacuumdb, analyze, reindex) semanais > e individuais para cada base de dados respeitando suas propriedades e > aplicações. Ótimo. > 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. Se a transação se resolve sozinha (mesmo que demore), então não há nada que você possa fazer senão deixá-la trabalhar. > Para resolver temos as opções de terminate backend dos clientes ou do script > de manutenção para voltar. Aborte sua manutenção. Veja o padrão de uso de cada tabela e agende as manutenções para os horários em que elas não estiverem sendo usadas. Acho pouco provável que seu usuário atualize de madrugada a mesma tabela que é atualizada durante o dia. Se for o caso, só te resta escolher quem precisa esperar em qual horário de qual dia da semana e pronto. > 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? Você pode estimar que uma transação aberta esteja aberta sem motivo, porém não há como ter certeza. Pense naquele cara que esperou o fim do expediente para rodar um script monstro de várias horas para atualizar sei lá o que numa tabela gigante, crucial para seu chefe no dia seguinte. Imagine a cara dele quando voltar no dia seguinte esperando usar os dados atualizados e descobrir que algum desinformado do suporte matou a conexão do script dele... > 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? Nem pensar. Você não sabe qual a maior consulta que todos os seus usuários podem fazer. Imagine um gerente tentando colocar na mesa do chefe aquele relatório gerencial urgentíssimo que costumava levar 6 minutos e agora leva 5 para dizer que não dá... > 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? A empresa mantenedora tem razão, isso é problema de administração de banco, não do ERP. > d) Quem já experimentou algo deste gênero e como chegou a um consenso > funcional? Consenso não imagino que haja nem que vá haver. Lamento, sem um conhecimento profundo e detalhado do padrão de uso de todas as suas tabelas, o jeito é abortar manutenções e particionar tabela a tabela, espalhando pelos horários de menor uso. Atenciosamente, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
