SQL muy lenta la 1ª vez

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

Empezado por Casimiro Notevi

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

Tienes buena memoria, pues no lo he dicho. Uso IBO, de todas formas las pruebas las estoy haciendo con IBExpert y me da que también usan IBO pero esto último no lo sé.

Un saludo.

[ARPE1]

Hola de nuevo, más resultados.
iSQL de firebird (por evitar herramientas de terceros):
1. 1ª vez esos 6 minutos
2. siguientes >>> 3 segundos

FDB copiada, tal cual, sobre un SSD.
1. 1ª vez ¡¡¡¡¡ 17 segundos !!!!!
2. siguientes >>> 3 segundos
Es curioso, los archivos temporales de FB los tengo redirigidos sobre un mecánico (TempDirectories = G:\FBTemp). Lo único que he hecho ha sido mover el FDB a un SSD. De aquí casi se puede sacar que la caché ¿la guarda en el mismo FBD?. Una pasada el rendimiento, creo que es una buena inversión para los clientes, aunque sea uno pequeño para almacenar sólo el FDB.

Y otras cosillas, al tocar lso tamaños de página se reduce algo el tiempo (a más tamaño menos tiempo, al menos en esta consulta). Tampoco para tirar cohetes.

Un saludo y os seguiré contando

PD. Creo que a estas alturas deberíamos olvidarnos de la consulta SQL y tratar temas de caché, memoria, firebird.conf... es decir de las configuraciones de los sistemas. Voy por SUSE a ver qué me cuenta.

[Casimiro Noteví]

IBO es buenecito, aunque IBX y FIBplus son algo más rápidos.
Alguna vez leí o escuché que ibexpert usa, o usaba, IBO.

Un par de cosas, ese disco G: es una partición del mismo o es otro disco físico. Debería ser otro disco para mejorar. Si es una partición del mismo entonces estamos en las mismas, no sirve de mucho, más bien de nada.

Otra cosa, por probar que no quede, mira de cambiar not exists por not in

[ARPE1]

Hola

Empezado por Casimiro Notevi

Un par de cosas, ese disco G: es una partición del mismo o es otro disco físico. Debería ser otro disco para mejorar. Si es una partición del mismo entonces estamos en las mismas, no sirve de mucho, más bien de nada.

Es otro disco físico. Lo único que la memoria virtual de Windows (swap) la tengo en el mismo.

Empezado por Casimiro Notevi

Otra cosa, por probar que no quede, mira de cambiar not exists por not in

La que dices que por probar que no quede, aunque en todas las ocasiones que me he tropezado con esta situación tiene mayor rendimiento un "exists" que un "in", ya que en el "exists" se puede filtrar.

un saludo

[ARPE1]

Hola

Empezado por ARPE1

La que dices que por probar que no quede, aunque en todas las ocasiones que me he tropezado con esta situación tiene mayor rendimiento un "exists" que un "in", ya que en el "exists" se puede filtrar.

Probado y cuando llevaba 50 minutos sin resolver lo he cancelado, y eso que era ya de segundas, es decir, los 3 segundos del otro modo de consulta.
Un saludo.