lentidão com firebird 2.0, sendo o 1.5 mais rápido
Meu problema é meio inusitado, por isso eu peço ajuda.
Num computador semprom com 512 de ram e windows 2003 server, um relatório com o firebird 1.5 demorava cerca de 3 segundos.
Atualizando para o firebird 2.0, passou a demorar de 3 a 15 minutos!!!
e o que é pior, se pegar o mesmo banco, o mesmo ambiente e o firebird 2.0, mas usar windowsXP home, no lugar do windows 2003 server, o relatório sai quase que instantaneamente.
Que tipos de configurações ´finas´ que existem no firebird ou no windows 2003 para lidar com isso? alguém poderia me ajudar.
As queries mais lentas são as que usam ´not in´
Grato!
Num computador semprom com 512 de ram e windows 2003 server, um relatório com o firebird 1.5 demorava cerca de 3 segundos.
Atualizando para o firebird 2.0, passou a demorar de 3 a 15 minutos!!!
e o que é pior, se pegar o mesmo banco, o mesmo ambiente e o firebird 2.0, mas usar windowsXP home, no lugar do windows 2003 server, o relatório sai quase que instantaneamente.
Que tipos de configurações ´finas´ que existem no firebird ou no windows 2003 para lidar com isso? alguém poderia me ajudar.
As queries mais lentas são as que usam ´not in´
Grato!
Vitor Rubio
Curtidas 0
Respostas
Gm.gui
21/03/2007
Tmb estou com o mesmo, problema, e se faço um backup com o Gbak, e tento restaurar com o Firebird 2, acontece alguns erros,
GOSTEI 0
Vitor Rubio
21/03/2007
se você fizer o backup de um bd fib1.5 com gbak e restaurar no gbak 2.0, funciona, veja o help do gbak. O contrário já não pode ser feito, pois ao restaurar (recriando) o gbk do 1.5 sob ambiente 2.0 ele se torna um arquivo do firebird 2.0.
Com relação a lentidão, criei um indice para um campo que estava sendo usado e ficou 40 vezes mais rápido. (de 2 minutos para 6 segundos)
a ordem dos filtros no where também faz diferença, veja: QUERO CONSULTAR ORDEM DE SERVIÇO SEM LANÇAMENTOS NO FINANCEIRO NUMA DETERMINADA DATA DE FINALIZAÇÃO
você só nota essa diferença numa tabela com muitos registros.
Com relação a lentidão, criei um indice para um campo que estava sendo usado e ficou 40 vezes mais rápido. (de 2 minutos para 6 segundos)
a ordem dos filtros no where também faz diferença, veja: QUERO CONSULTAR ORDEM DE SERVIÇO SEM LANÇAMENTOS NO FINANCEIRO NUMA DETERMINADA DATA DE FINALIZAÇÃO
/*a ordem dos fatores altera o produto*/ /*exemplo de select lento*/ select O.dataosfin as dtlanc, O.total, O.os as lanc from os O where (O.codos not in (select distinct codaux from finan)) and ((O.dataosfin >= ´03/19/2007´) and (O.dataosfin <= ´03/19/2007´)) group by O.dataosfin, O.total, O.os order by O.os /*o mesmo select UMA PÁ DE vezes mais rápido*/ select O.dataosfin as dtlanc, O.total, O.os as lanc from os O where ((O.dataosfin >= ´03/19/2007´) and (O.dataosfin <= ´03/19/2007´)) and (O.codos not in (select distinct codaux from finan)) group by O.dataosfin, O.total, O.os order by O.os /*numa query sempre colocar o que trará menos resultados como primeiro filtro de um where*/
você só nota essa diferença numa tabela com muitos registros.
GOSTEI 0
Rodolpho123
21/03/2007
Cara,
Utilize NO EXSTIS em vez de NOT IN...Vai funcionar perfeitamente...
Utilize NO EXSTIS em vez de NOT IN...Vai funcionar perfeitamente...
GOSTEI 0
Vitor Rubio
21/03/2007
Realmente, o not exists funciona muito bem, porque já restrige a consulta. Mas mesmo assim a ordem faz diferença.
Uma coisa que eu achei interessante: usando o not in no firebird 1.5, o firebird exclui os registros que trariam oreferido campo como null. Já o firebird 2.0 traz os campos que retornariam null, porque ão sabe se está dentro ou não.
Esta é a diferença crucial na velocidade do firebird.
Uma coisa que eu achei interessante: usando o not in no firebird 1.5, o firebird exclui os registros que trariam oreferido campo como null. Já o firebird 2.0 traz os campos que retornariam null, porque ão sabe se está dentro ou não.
Esta é a diferença crucial na velocidade do firebird.
GOSTEI 0