ETL no Postgresq
26/01/2012
0
Boa tarde,
Estou utilizando a ferramenta ETL da Informática Services para carregar uma tabela do Oracle para o Postgresql.
Quando a tabela de destino (postgresql) está vazia, a carga executa em torno de 4 minutos.
Quando a tabela já contém dados (carga incremental), a carga demora em torno de 12 horas.
Quando verifico as sessões, o usuário ETL está fazendo update e é bastante demorado o processo.
Alguém tem alguma dica ?
Estou utilizando o postgresql 8.4 num servidor com 8Gb de RAM e com as configurações:
max_connections = 140 # (change requires restart)
shared_buffers = 2GB # min 128kB
temp_buffers = 8MB # min 800kB
work_mem = 32MB # min 64kB
maintenance_work_mem = 512MB # min 1MB
Agradeço desde já,
Estou utilizando a ferramenta ETL da Informática Services para carregar uma tabela do Oracle para o Postgresql.
Quando a tabela de destino (postgresql) está vazia, a carga executa em torno de 4 minutos.
Quando a tabela já contém dados (carga incremental), a carga demora em torno de 12 horas.
Quando verifico as sessões, o usuário ETL está fazendo update e é bastante demorado o processo.
Alguém tem alguma dica ?
Estou utilizando o postgresql 8.4 num servidor com 8Gb de RAM e com as configurações:
max_connections = 140 # (change requires restart)
shared_buffers = 2GB # min 128kB
temp_buffers = 8MB # min 800kB
work_mem = 32MB # min 64kB
maintenance_work_mem = 512MB # min 1MB
Agradeço desde já,
Sandra Guedelha
Curtir tópico
+ 0
Responder
Posts
28/02/2012
Diego Lusa
Olá Sandra.
Normalmente as cargas incrementais são mais demoradas pois envolvem um número maior de testes
e de passos. O uso de índices na tabela de destino pode diminuir o tempo necessário para estes testes.
Outro fator que impacta no desempenho é onde são criadas as tabelas temporárias (não sei se a ferramenta
as usa, no caso). Se existir um comando NOT IN ou IN que opere sobre um conjunto muito grande de registros,
tente substituir pelas cláusulas EXISTS e NOT EXISTS
Normalmente as cargas incrementais são mais demoradas pois envolvem um número maior de testes
e de passos. O uso de índices na tabela de destino pode diminuir o tempo necessário para estes testes.
Outro fator que impacta no desempenho é onde são criadas as tabelas temporárias (não sei se a ferramenta
as usa, no caso). Se existir um comando NOT IN ou IN que opere sobre um conjunto muito grande de registros,
tente substituir pelas cláusulas EXISTS e NOT EXISTS
Responder
Clique aqui para fazer login e interagir na Comunidade :)
