Degradacion de servicio - Firebird

[IVAND]

Hola a todos .. Trabajo con firebird 1.5.1 y con delphi 6 +Ibx , cuando realizo una consulta a mi base de datos (Tablas cab_fac tiene unos 30000 registros y det_fac tiene unos 250000) , se me degrada totalmente el servicio es decir los terminales se vuelven lentos y por ende los ingresos a esas tablas el query que uso ademas se demora como unos 20 m en mostrar los resultados

este es el query

Código PHP:

Select v.cod_producto,v.nombre,  sum(d.cantidad) TcantVend,
sum(total_linea) tventa,Round(sum(d.cantidad*d.precio_prom),2) Tcosto

from cab_fac c,det_fac d,vi_producto_bodega v
Where ca.key_caja=c.key_caja
and c.estado_fac='T'
and  extractDate(c.fec_factura) between :desde and :hasta
And c.key_cab_fac=d.key_cab_fac
and d.key_producto_b=v.key_producto_b
Group by v.cod_producto,v.nombre 


como puedo hacer para mejora esta consulta la tabla cab_fac tiene indice a la fecha (fec_factura), porque se consume tantos recursos y porque es tan lenta con ese numero de registros

[Casimiro Notevi]

En principio es muy complicado responder con un select por qué tarda tanto. Habría que comprobar estado de la base de datos, índices, modo de acceso a los datos, tarjetas de red, cableado, servidor, memoria, programas en el servidor...

Echa un vistazo a estos consejos por si te sirven de algo.

[IVAND]

Gracias por tu respuesta

Pero por donde empezar, el servidor esta en perfecto estado es nuevesito , a que te refieres con el estado de base de datos todo el cableado esta certificado , porque cuando cambio por ejemplo no uniendo con Vi_producto_bodega y por ende no agrupando por cod_producto y nombre el resultado es mas rapido pero entonces como mostrare el nombre y el codigo

Seguire probando

[Casimiro Notevi]

La única manera de optimizar esa consulta es tener la base de datos, o sea, sólo puedes hacerlo tú.

Has dado una pista muy buena, mira esa vi_producto_bodega que parece que es la culpable.

Te aconsejo que uses un programa como IB Planalyzer para depurar la consulta hasta encontrar la forma óptima de hacerla.

[Casimiro Notevi]

Ha cambiado la dirección, ahora lo encontrarás aquí.

[IVAND]

Gracias por tu respuesta amigo

Estoy bajando el programa que me recomendaste , seria interesante si existiese una guia de la manera de colocar las tablas , indices para obtener un mejor rendimiento


Gracias de nuevo

[Casimiro Notevi]

Es cuestión de hacer pruebas, muchas pruebas, hasta encontrar la forma más óptima.
Cualquier consulta en un programa, que luego va a estar funcionando en una empresa, debe depurarse hasta encontrar la opción más efectiva, haciendo pruebas con muchos datos, lo más reales posibles.

[Ruitoquefly]

Te comento que yo tambien tuve este problema, tenia una tabla de 2500000 de registros y las consultas se demoraban minutos, investigando, encontre un ariculo que hablaba de ello , pero desafortunadamente no en acuerdo donde lo lei pero te puedo resumir que el problema consistia en la definicion de los indices,
porque si en las condiciones del where no existe el indice exacto que permita su busqueda, lo que hace el motor es generar un indice temporal, y es alli donde esta la demora.
Ejemplo
select * from tabla where fecha=mfecha and numero=mNumero and estado='c'

debes tener un indice para la fecha otro para el numero y otro para el estado

y como te comentan es cuestion de probar y probar

[IVAND]

Gracias amigo por tu respuesta

Les comento que me decidi por hacer un SP que de alguna manera se supero la velocidad pero no en mayor cosa , seguire probando pero tambien lei que si uno crea demasiados indices el Insert tambien se hace lento

El problema parece tambien en la vista :-) (salvo que este equivocado las vistas son una solucion y a la vez un problema , Tambien cuando se realizan agrupaciones por nombres (caracteres) y algunas cosas mas

Pero probare con indices aunque las tablas que tengo y las uniones que hago tienen indices (algunas son indices primarios )

[gabrielkc]

Alguna vez tube un problema parecido en un select con varios SUM, cuando unia las primeras dos tablas con una tercera se incrementaba escandalosamente el tiempo de la consulta. Haciendo pruebas me di cuenta que la tercera tabla generaba tuplas con campos en null, y al cuando firebird trata de sumar ese Null al resultado del SUM al no poder pierde algo de tiempo (supongo que cachando la excepcion) y luego se sigue con el siguiente registro, hacer esto en miles de registros le lleva una cantidad extraordinaria de tiempo.

No se si sea tu caso (porque yo usaba LEFT JOIN) pero si no para ti (hace 2 años de tu pregunta :P) espero a alguien le sirva