SQL muy lenta la 1ª vez

[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...

[Casimiro Noteví]

Ya sé que no va a ser posible, pero no estaría mal tener una copia de la BD para probar

[ARPE1]

Hola

Empezado por Casimiro Notevi

Ya sé que no va a ser posible, pero no estaría mal tener una copia de la BD para probar

Me gustaría poder compartir más a fondo el problema y las pruebas, pero sabéis que no se puede, si fueran míos los datos pues sí, no habría problema en haceros llegar una copia (¡¡¡de casi 3GB!!!). LOPD, LOPD, LOPD. Con un cantito en los dientes que se me permita tenerla a mi, ¡¡¡menos mal!!!.

No sé si podría generar un FDB con las tres tablas implicadas y datos aleatorios hasta llegar al volumen que tienen ellos, y si es así si nos encontraríamos con el mismo problema. Lo estudiaré, de momento me he dado cuenta que tengo el unix muuuuuy olvidado y no soy capaz de echar a andar el fbserver en suse.

Un saludo y os sigo poniendo resultados.

[ARPE1]

Hola

Empezado por mamcx

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?

Desde el principio estoy con dos consultas: la del "merge" (origen del hilo) y esta del "exists":
Código SQL [-]Select artic.artic, almac.cod as almac from artic, almac where artic.activo = 'S' and artic.filtro = 'MP' and not exists ( Select artal.artic from artal where artal.artic = artic.artic and artal.almac = almac.cod)

Todas las pruebas que os voy poniendo están hechas con la consulta anterior (pensando en un "insert into" en lugar de un "merge"). La tabla "almac" es una auxiliar de código/descripción con clave primaria por código, si no usa ese índice es porque no hay condiciones para el uso y porque necesita todos los registros (en eso consiste la consulta: los artículos seleccionados en todos los almacenes).

Empezado por mamcx

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...

El disco lo tengo desfragmentado: manías de uno que una vez al mes pasa ese proceso (más al andar con archivos de grandes volúmenes de aquí para allí. Los índices están bien, como ya dije no he dado de alta ningún registro y otra manía que tengo es al recibir una BD de un cliente pasarle una serie de procesos de mantenimiento. Así que sinceramente creo que es rápido por lo primero que has dicho (tienen IO superveloz), unos 450 MB/s en lectura secuencial que es lo que toca. ¿Al hacer un backup/restore también tiene el plan de la consulta calculado?

Por cierto no sé a qué te refieres con los tiempos, la consulta la ejecuté con iSQL calculando sólo el plan (Set planonly on).

un saludo y gracias por el interés