Bom dia Senhores,
Preciso de um procedimento para matar sessões inativas (idle) por mais de
08 horas, encontrei em (1) algumas dicas porém nenhuma delas funcionou na
minha versão (2).
Existe algo do próprio PostgreSQL que faça essa tarefa?
1 -
On 21-02-2014 09:25, Nildo Abreu wrote:
Preciso de um procedimento para matar sessões inativas (idle) por mais de
08 horas, encontrei em (1) algumas dicas porém nenhuma delas funcionou na
minha versão (2).
Existe algo do próprio PostgreSQL que faça essa tarefa?
Vide a documentação [1].
Pessoal,
Estou migrando 9.1 pra 9.3 e vou usar o pg_upgrade.(linux)
Temos uma base de 800GB, onde 700GB é de apenas um banco que armazena
binários.
Algumas dúvidas:
1-Terei que ter espaço equivalente ao data para migrar? Resumindo ele faz
uma cópia do data pro novo destino?
2-Por baixo dos panos
Pessoal,
Estou migrando 9.1 pra 9.3 e vou usar o pg_upgrade.(linux)
Temos uma base de 800GB, onde 700GB é de apenas um banco que armazena
binários.
Escolheu a ferramenta certa.
Algumas dúvidas:
1-Terei que ter espaço equivalente ao data para migrar? Resumindo ele
faz uma cópia do data pro
Para varchar, serve a mesma regra. O banco não guarda as delimitações dos
argumentos, apenas seus tipos.
Este comportamento é estranho para mim
Mesmo assim, a criação de domínios resolveria seu problema, porém, imagino
quantos deveria ter de criar.
teria de criar muuuitos... por isso seria
On 21-02-2014 10:34, Flavio Henrique Araque Gurgel wrote:
Você está parcialmente errado.
Leia a documentação.
*Faça um backup antes*.
... faltou dizer: *teste* antes de fazer a migração. O pg_upgrade ainda
*não* é uma ferramenta oficial para migrações; ele possui limitações.
--
Euler
Em 21 de fevereiro de 2014 09:57, Euler Taveira eu...@timbira.com.brescreveu:
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE (now() -
query_start) interval '8 hours' AND state ~ 'idle';
Se for somente as ociosas (aquelas que não estiverem executando
consultas), troque o ~ pelo
Em 21 de fevereiro de 2014 09:57, Euler Taveira eu...@timbira.com.brescreveu:
On 21-02-2014 09:25, Nildo Abreu wrote:
Preciso de um procedimento para matar sessões inativas (idle) por mais de
08 horas, encontrei em (1) algumas dicas porém nenhuma delas funcionou na
minha versão (2).
Pessoal,
Utilizo postgresql 9.1.9 em servidor debian.
Tenho uma tabela (principal tabela do banco de dados) que está com 18
milhões de registros e ocupando 21 GB de espaço.
Essa tabela é de histórico de leituras, portando muito utilizanda, tanto
para select quanto para inserts e updates.
Para
Em 21-02-2014 16:48, Danilo Silva escreveu:
1º Deletar registros mais antigos, algo em torno de 10 milhões de registros;
2º Particionar a tabela;
Penso em utilizar a 2ª opção visto ter acesso aos dados sem precisar
modificar a aplicação (que é para ambiente web).
Para a 2º opção o que vocês
On 21-02-2014 12:48, Danilo Silva wrote:
1º Deletar registros mais antigos, algo em torno de 10 milhões de registros;
Eu já acho que deveria seguir a primeira opção, minha visão para dados
antigos é para consultas históricas e não em base de produção. Se este
for seu caso é claro...
Em 21/02/2014 12:48, Danilo Silva escreveu:
Pessoal,
Utilizo postgresql 9.1.9 em servidor debian.
Tenho uma tabela (principal tabela do banco de dados) que está com 18
milhões de registros e ocupando 21 GB de espaço.
Essa tabela é de histórico de leituras, portando muito utilizanda, tanto
On 21-02-2014 13:16, Lucio Chiessi [VORio] wrote:
Eu também te recomendaria a 2ª opção, para que não tenhas que excluir
informações do seu banco que podem ser necessárias no futuro.
Tirar (entenda-se excluir) não significa apagar ou ficar inacessível.
Pode até ficar em outro repositório de
Boa Tarde Galera.
Estou querendo aumentar a disponibilidade do meu servidor que roda o
postgres, porem sem abalar o desempenho nem sobrecarregar a minha rede.
O meu servidor contém Raid 5 e insto já diminui um pouco o desempenho da
base de dados, e eu estou pensando e configurar outro servidor
2014-02-21 14:14 GMT-03:00 Thiago Haroldo thi...@sedcontabilidade.com.br:
O meu servidor contém Raid 5 e insto já diminui um pouco o desempenho da
base de dados
Passa para Raid 10 assim que possível. Sério. Raid 5 é medida de
economia porca, ou para casos muito específicos. Muito mais
Passa para Raid 10 assim que possível. Sério. Raid 5 é medida de
economia porca, ou para casos muito específicos. Muito mais simples e
barato que replicação, e previne problemas em vez de remediá‐los.
Pesquise um pouco, por exemplo nesta lista mesmo já discutimos isso
muito.
Eu já peguei o
2014-02-21 17:23 GMT-03:00 Thiago Haroldo thi...@sedcontabilidade.com.br:
Eu já peguei o servidor com Raid 5, já li que não presta para banco de
dados, baixa leitura e escrita.
O pior é a falta de confiabilidade. É muito comum Raid 5 causar
falhas catastróficas. Vide histórico da lista a
On 21-02-2014 11:58, Douglas Fabiano Specht wrote:
Ola..
por que vc nao utiliza as opções[1]:
#tcp_keepalives_idle = 0
#tcp_keepalives_interval = 0
#tcp_keepalives_count = 0
[1]-http://www.postgresql.org/docs/9.3/static/runtime-config-connection.html
Douglas,
Executando o man 7 tcp
18 matches
Mail list logo
