SQL muy lenta la 1ª vez

[mamcx]

Empezado por ARPE1

Hola y gracias por el interés.
La BD ya tiene extensión FDB. El producto cartesiano puro y duro, en este caso, es obligado.

Siempre hay mas de 1 manera de resolver un problema. Si nos cuentas cual es el problema, pones ejemplos con datos, quizas te podamos dar una luz.

El porque la 1era vez es lento y luego rapido me parece obvio. Al principio la tabla de destino esta "vacia", luega la llenas, luego al repetir ya esta llena y solo copia los registros faltantes. El filtro de la consulta hace todo rapido.

Lo que no entiendo, es porque hay que preocuparse al siguiente dia por esto. Siempre la tabla de destino esta "vacia" al arrancar???

[ARPE1]

Hola

Empezado por mamcx

Lo que no entiendo, es porque hay que preocuparse al siguiente dia por esto. Siempre la tabla de destino esta "vacia" al arrancar???

Ahí está el misterio, nunca la tabla Artal (Artículo-Almacén) está vacía. Como mucho, y como ya os comenté, se pueden dar de alta 1 ó 2 registros. Más misterio todavía es que recién arrancado el equipo si hago un Backup/restore la consulta se resuelve en un abrir y cerrar de ojos.
Tuve un profe en EGB que nunca ponía un 10, decía que siempre hay más caminos y que seguro que hay otro mejor. El producto cartesiano que tanto nos preocupa no es el problema, ese producto, incluso sin condiciones que filtren las tablas, lo resuelve en milisegundos (con fetch all).
Por cierto lo probé en un FB2.5.2 64bits en modo superClassic y... lo mismo.
Sigo con que es problema de caché, ¿de Windows?, . Casimiro, estoy contigo, posiblemente en un Linux "pelao" la cosa cambie, de hecho lo probaré por curiosidad.

Un saludo y no me harto de agradeceros vuestro interés, muchas gracias

[Casimiro Noteví]

Empezado por ARPE1

... recién arrancado el equipo si hago un Backup/restore la consulta se resuelve en un abrir y cerrar de ojos.

¿Y si no está recien arrancado el equipo, si haces un backup/restore también va rápido la primera vez?

[ARPE1]

Hola, así es, en el momento que hago un backup/restore o ejecuto una vez la consulta va como la seda.
Mi última prueba va a ser con un OpenSUSE y salga lo que salga ahí terminaré. Os cuento resultados.
un saludo.

[mamcx]

Podrias darnos el plan de ejecucion? Cuando mencionas que el producto cartesiano se resuelve rapido, has identificado EXACTAMENTE en que paso esta la demora? El comando EXPLAIN podria dar una luz...

Lo ultimo que se me ocurre es eliminar los indices y triggers antes de la insercion y reagregarlos al final. Tambien, meter los datos en una tabla temporal y de alli traspasarlos.

Pero quizas debes analizar esta presentacion sobre desempeño:

http://www.slideshare.net/ibsurgeon/...mance-problems

[[Al González]]

Empezado por mamcx

Lo ultimo que se me ocurre es eliminar los indices y triggers antes de la insercion y reagregarlos al final.

En el caso de los disparadores, no es necesario llegar a tanto, ya que pueden simplemente ser desactivados y activados nuevamente, sin necesidad de borrarlos.

Creo que este tema me va a ser de lo más valioso, ya que tengo una aplicación que presenta una situación muy parecida a la de ARPE1. En mi caso es Windows XP + Firebird 1.5 + Delphi 7 + DBX con el controlador de InterBase (que hasta esa versión de Firebird sí es compatible, según entiendo). El archivo .fdb ocupa unos 535 MB, hago uso adecuado de los índices y pasa lo mismo: con ciertas y muy particulares consultas, la primera vez que las realizo se demora un par de minutos, mientras que haciéndola de nuevo resultan instantáneas. Esto pasa incluso habiendo ya hecho otras consultas y actualizaciones en la base de datos (la conexión puede tener ya varias horas de vida y uso antes de hacer esa primera consulta extrañamente lentificada, o puede ser en cuanto se abre dicha conexión).

El problema no ocurre si hago lo mismo desde IBExpert (ahí siempre es rápido) o bien en red. Es decir, sólo pasa cuando ejecuto la aplicación conectándome a la base de datos localmente (misma PC para cliente y servidor). Con IBExpert, ya sea remoto o local, anda rapidísima la consulta.

Ya comprobé que la demora no ocurre en el código Delphi. Sino en la llamada que finalmente hace este código a Firebird. ¿Debería pensar en cambiar el controlador DBX InterBase?

Extraños saludos.

[Casimiro Noteví]

Empezado por Al González

En el caso de los disparadores, no es necesario llegar a tanto, ya que pueden simplemente ser desactivados y activados nuevamente, sin necesidad de borrarlos.

Los índices también pueden ser desactivados, aunque si son clave primaria no recuerdo si es posible en ese caso.

Empezado por Al González

Ya comprobé que la demora no ocurre en el código Delphi. Sino en la llamada que finalmente hace este código a Firebird. ¿Debería pensar en cambiar el controlador DBX InterBase?

Pues no recuerdo si ARPE1 ha mencionado el controlador que usa, vaya a ser algo de eso.

[ARPE1]

Hola

Empezado por mamcx

Podrias darnos el plan de ejecucion? Cuando mencionas que el producto cartesiano se resuelve rapido, has identificado EXACTAMENTE en que paso esta la demora? El comando EXPLAIN podria dar una luz...

Así es, el producto se resuelve en milisegundos, la demora está en la comparación de registros con la tabla grande (ARTAL), de todas formas ahí pego el plan
Código SQL

Código SQL [-]
Select artic.artic, almac.cod CON> from artic, almac CON> where artic.activo = 'S' and artic.filtro = 'MP' and CON>   not exists (Select artal.artic CON>   from artal CON>   where artal.artic = artic.artic and artal.almac = almac.c  PLAN (ARTAL INDEX (PK_ARTAL)) PLAN JOIN (ALMAC NATURAL, ARTIC INDEX (ARTIC_IDX3, ARTIC_IDX4))

Aunque veamos ALMAC NATURAL , no preocupa sólo tiene 40 registros y los lee una vez (analizado con IBExpert).

Empezado por mamcx

Lo ultimo que se me ocurre es eliminar los indices y triggers antes de la insercion y reagregarlos al final. Tambien, meter los datos en una tabla temporal y de alli traspasarlos.

La tabla ARTAL es una tabla final, es decir, no tiene triggers, sólo recibe datos de triggers de otras tablas para después consultarlos. Y los índices sólo tiene el que necesita esta consulta (PK_ARTAL = ARTIC+ALMAC), lo sé, lo sé, un índice compuesto de datos alfanuméricos pero es lo que hay. De todas formas ya dije que como mucho se dan de alta 1 ó 2 registros, no pierde tiempo, por tanto, en actualizar los índices. Es más, tengo una copia de la BD del cliente y llevo semanas sin dar de alta registros y me pasa lo mismo.

Empezado por mamcx

Pero quizas debes analizar esta presentacion sobre desempeño:

http://www.slideshare.net/ibsurgeon/...mance-problems

Precisamnete en este documento me basé para modificar el firebird.conf, la reestructuración de discos y particiones, etc... Por cierto ya que tengo posibilidad voy a probarlo en un SSD, todo lo que vaya saliendo os lo cuento.

un saludo y gracias.

[mamcx]

Empezado por ARPE1

Código SQL [-]
JOIN (ALMAC NATURAL, ARTIC INDEX (ARTIC_IDX3, ARTIC_IDX4))

Aunque veamos ALMAC NATURAL , no preocupa sólo tiene 40 registros y los lee una vez (analizado con IBExpert).

Ese no es el mismo query del principio -pero pasa igual?-, y no estan los tiempos. Sin embargo si es un producto cartesiano no importa que ALMAC sea pequeña, igual deberia tener los indices. Segun el plan, hay una lectural natural (ie: lee cada registro de la tabla). Probaste poniendo indices?

Y por favor, usa el mismo dato para hacer evaluaciones y medidas, si cambias los querys cada vez pues como se puede determinar exactamente la causa?

Lo ultimo se me ocurre, es que el disco este fragmentado, o que las estadisticas de los indices esten desincronizadas. El que vuele con SSD muestra en parte eso (los SSD no se fragmentan, y tienen IO superveloz). Es claro, desde mi punto de vista, que FB esta leyendo datos del disco y no desde los indices (en memoria). La 2da vez es rapido porque tiene los planes, indices, etc precalculados y las estadisticas corregidas...