Hola
Cita:
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).
Cita:
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.
Cita:
Empezado por mamcx
|
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.