Olá Mozart e Turma, Obrigado pela dica.
Havíamos pensado em "quebrar" os bancos em porções baseado em seus padrões, porém não vimos muita disponibilidade de dados para tal, chegou-se ao ponto de tentar criar tabelas para depositarmos estatísticas de uso, tais como, acesso por tabelas, deleções, updates, inserts, gráfico de uso por horário, transações abortadas, iniciadas, load geral etc. Todavia, ainda estamos estudando como chegar a este produto final (somos originários do Oracle onde tudo vinha ou era produzido com certa facilidade através das inúmeras views etc.). Você e ou a turma pode me indicar o "caminho das pedras" em relação aos hits do banco? Isto quer dizer alguma documentação, relato de experiência etc. Desde já agradeço a todos, 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 _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
