O teu pessoal de infla no momento de fazer o vacuum, se certifica que não há conexões/trasações abertas? é interessante rodar esse comando vacuum sem o risco de haver nenhuma transação em aberto no banco de dados, desta forma vai garantir que todas sem nenhuma exeção "linhas" sejam lockadas , sem risco de problemas de reiniciar o ID da transação. Abaixo texto explicativo.
"21.1.3. Prevenção de falhas devido ao reinício do ID de transação A semântica de transação do MVCC do PostgreSQL depende de poder comparar números identificadores de transação (XID): uma versão de linha com XID de inserção maior que o XID da transação corrente está "no futuro", não devendo ser enxergada pela transação corrente. Como os IDs de transação possuem tamanho limitado (32 bits quando esta documentação foi escrita), um agrupamento em funcionamento por um longo período de tempo (mais de 4 bilhões de transações) sofre um reinício do ID de transação: o contador do XID volta a zero e, de repente, a transações que estavam no passado parecem estar no futuro - significando que suas saídas se tornam invisíveis. Em resumo, uma perda de dados catastrófica (Na verdade os dados ainda estão lá, mas isto não serve de consolo se não é possível acessá-los). Antes do PostgreSQL 7.2 a única defesa contra o reinício do XID era executar novamente o initdb pelo menos a cada 4 bilhões de transações. É claro que não era muito satisfatório para instalações com alto tráfego e, por isso, foi concebida uma solução melhor. A nova abordagem permite o servidor permanecer ativo indefinidamente, sem executar o initdb ou qualquer forma de reinício. O preço é a necessidade desta manutenção: todas as tabelas do banco de dados devem ser VACUUM-nizadas pelo menos uma vez a cada um bilhão de transações. Na prática este não é um requisito oneroso, mas uma vez que a conseqüência de não respeitá-lo pode ser a perda total dos dados (e não apenas desperdício de espaço em disco ou degradação do desempenho), foram introduzidos alguns dispositivos especiais para ajudar os administradores de banco de dados a terem conhecimento do tempo decorrido desde que o comando VACUUM foi executado pela última vez. O restante desta seção fornece os detalhes." Att Claudio Tavares Coordenador de Tecnologia rs :) ----- Original Message ----- From: "João Paulo Siqueira" <[EMAIL PROTECTED]> To: <pgbr-geral@listas.postgresql.org.br> Sent: Thursday, August 16, 2007 11:18 AM Subject: [pgbr-geral] Problema com Vacuum Bom dia pessoAll, primeiramente gostaria de me apresentar, sou o coordenador de ti do portal meucarronovo.com.br e utilizamos o postgres como solução desde o ano de 2004. E, devido ao nosso crescimento em 2007, começaram a ocorrer alguns problemas que estão deixando o nosso pessoal de infra estrutura com uma certa dor de cabeça, principalmente em relação ao comando vacuum que é agendado para execução todas as madrugadas e que ultimamente não está concluindo em um tempo aceitável, bloqueando o acesso dos usuários às tabelas que acabam "travadas" pelo vacuum. Gostaria de opiniões da lista de como isso poderia ser resolvido, levando-se em consideração que por se tratar de um portal, a aplicação deve estar disponível 100% do tempo, ou com o minimo de interrupções possíveis. Informações do Server intel xeon 3.0 4gb ram 15gb utilizados pelas nossas bases de dados. Ainda não utilizamos replicação Obrigado, João Paulo www.meucarronovo.com.br _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
