SQL muy lenta la 1ª vez

[Casimiro Noteví]

Bastante difícil es poder ayudar sin tener el equipo a mano y probar, que además lo pones más difícil. Por ejemplo, esas sqls que has puesto no son las que estás usando, evidentemente.

De todas formas, si la primera vez va lento y después va rápido, está claro que hay algo que no tiene que ver con la base de datos, deberías probarlo en local, luego en otro ordenador haciendo de servidor y así comprobar.
Desde luego, que aunque dices que lo has verificado, está claro que algo hace el sistema para tardar tanto la primera vez.

Si en lugar de probar antes esas consultas, pruebas otras diferentes, ¿también va lento la primera vez y después no?.

En fin, que no das mucha información para poder hacernos una idea real del sistema.

[lbuelvas]

Hola amigos, la situacion puede ser la siguiente: primero revisar la extension de la base de datos, evitar .gdb y colocarle .fdb, esto es debido a que no me acuerdo desde que version de Windows los archivos con extension .gdb estan relacionados con el sistema operativo y este hace una copia de seguridad la primera vez que se abre el archivo y si es de buen tamañao pude durar unos minutos. Lo segundo es que la consulta es un producto cartesiano puro, es decir, si tienes en la tabal a 1.000 registros y en la b unos 2.000, la tabla resultante endra 2.000.000 de registros y eso es demoradp escribir tantos registros en una tabla mas si tienes indicies y llaves priamrias y foráneas.

Puedes darnos un poco más de información del contenido de las tablas, volumen de registros y la consulta completa para tratar de colaborarte.

[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. Por varias razones necesito que todos los artículos (tabla2) que entran en la consulta estén en todos los almacenes (tabla3) del cliente.
Ya probé en otro equipo (el mío) con diferentes protocolos (local y tcp_ip), me psa lo mismo. Buena idea esa de probar otras consultas, de momento he lanzado el producto cartesiano "sin condiciones", más duro todavía, y lo ha resuelto rápido. Me queda probarlo con udf's por ver si es tema de reserva de memoria.
La consulta real es la siguiente:

Código SQL [-]
Merge into Artal using (
  Select artic.artic, almac.cod as almac, 
    asCreaTalla(Artic.Tope1, Artic.Tope2) as MTallas,
    asIniTalla(asCreaTalla(Artic.Tope1, Artic.Tope2), 0) as MCeros
  from artic, almac
  where Artic.Activo = 'S' and Artic.Filtro = 'MP'
Datos on (Artal.Artic = Datos.artic and Artal.Almac = Datos.Almac)
When not matched then
  insert (ARTIC, ALMAC, MTALLAS, MSTOCK, MSTMAX, MPRECIBIR, MSTMIN, MUCOMPRAS, MUVENTAS, MPSERVIR, MCURSOFA)
  values (Datos.Artic, Datos.Almac, Datos.MTallas, Datos.MCeros, Datos.MCeros, Datos.MCeros, Datos.MCeros, Datos.MCeros, Datos.MCeros, Datos.MCeros, Datos.MCeros)

Artal: tabla de poco más de un millón de registros con esos 14KB de longitud
Artic: unos 52.000 registros
Almac: 40 registros
asCreaTalla, asIniTalla son udf's que tratan cadenas de texto. Como he mencionado probaré a quitarlas de la consulta por ver si es ese el problema.
Toda la información que necesitéis la pedís, no hay problema, es por no extenderme mucho ya que los mensajes largos a mí me asustan.
Un slaudo.

[Casimiro Noteví]

Yo nunca he necesitado usar merge ni matched, seguramente puedas hacerlo de otra forma.
Es más, es que ni siquiera sabía de la existencia de ellos.
Aunque tampoco debería ser motivo de lentitud la primera 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.