Consulta muy sencilla, extrañamente lenta

[Angel Fernández]

Empezado por Delfino

Aunque no estoy convencido de ello, intenta preparar la query antes de abrirla, la query tiene un metodo llamado Prepare,
por otra parte intenta remplazar el MDOQuery por un MDODataset asignando la string de la SQL de la primera a la SelectSQL de la segunda..
Has mirado si esta linea existe tb en los Fibplus?

Gracias Delfino por tu ayuda.

He hecho un prepare como me dices y el problema sigue. En cuanto a reemplazar el mdoquery por el mdodataset no ha lugar, porque siempre he usado mdodataset; es decir, el problema lo da con el mdodataset (aunque la línea del parón esté en una unidad llamada MDOSQL.prepare, esa unidad la llama mdodatset).

He mirado, pero muy por encima, y no encuentro esa línea en los fibplus.

Un saludo.

[[Al González]]

¡Hola!

Normalmente no hay ninguna ganancia de velocidad por reemplazar un componente XQuery por un XDataSet, la mayoría de las veces ambos comparten gran parte de su código / herencia.

Quisiera que nos concentráramos en la sentencia que nos muestras:

Empezado por Angel Fernández

...la línea con el problema. Es ésta:

Código Delphi [-]
Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0,
      PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True);

Para fortuna, descubrí que la misma sentencia es utilizada por los IBX (estos señores de los MDO se la copiaron tal cual , a no ser que MDO llame a unidades de los IBX ):

Código Delphi [-]
    Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0,
               PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True);

(se encuentra en la unidad IBSQL.pas de Delphi 7).

A partir de este punto de la investigación hay todavía mucha tela de donde cortar, Ángel:

1. Has mencionado que algunas de las tablas tienen millones de registros. Aunque creo que no mencionaste cuántos hay solamente dentro de la tabla Sensores, ante tal cantidad de datos (que es perfectamente soportable por Firebird) conviene darle una "afinación" a los índices de cuando en cuando. Para ello, suelo tener en todas mis bases de datos Firebird este procedimiento almacenado utilitario, el cual me ha resuelto problemas similares al tuyo:

Código SQL [-]
CREATE PROCEDURE SPACTUALIZARINDICES 
AS
DECLARE VARIABLE NOMBRE VARCHAR(31);
Begin
  For Select RDB$Index_Name From RDB$Indices Into :Nombre Do
    Execute Statement 'Set Statistics Index ' || :Nombre;
End

2. Si lo anterior no arregla nada, coloca un punto de ruptura en la sentencia que señalas y, una vez que se detenga ahí el programa, coloca otro en el Begin del método Call y presiona F9. Si demora un buen rato en llegar a ese segundo punto de ruptura, significa que efectivamente es isc_dsql_prepare y no el método Call el que se pone lento.

3. Una vez comprobado lo anterior, puedes crear un nuevo proyecto de "prueba aislada" con lo mínimo necesario para acceder a tu base de datos haciendo la misma consulta con un componente MDODataSet. Esto te ayudará a descartar que el problema sea causado por un elemento no evidente de otro lugar del programa.

4. Si no descubres nada relevante con el punto 3, existe la opción de hacer la misma prueba aislada, pero utilizando componentes IBX (aunque hay un pequeño riesgo de incompatibilidad con Firebird 2, pero por ser una prueba bien vale la pena intentarlo). Con esta opción, podrás detener el programa en la sentencia de IBSQL.pas que señalé arriba y probar que tan rápido se ejecuta presionando la tecla F8. Si en este caso no se presenta problema alguno de velocidad, conviene usar la ventana de observaciones ("watches") del depurador, para averiguar con qué parámetros se está llamando a la función isc_dsql_prepare y comparar los valores de esos parámetros contra la misma llamada que hacen los MDO, con el fin de encontrar alguna diferencia en los mismos que pueda ayudarte a inferir la razón del problema. Los parámetros interesantes a comparar serían: el arreglo al que apunta StatusVector, FProcessedSQL.Text y Database.SQLDialect.

5. Una quinta opción sería volver a crear, llenar con los mismos registros y probar nuevamente la consulta, pero en Firebird 1.5. Esto para descartar que la versión del motor esté relacionada con el problema.

Seguimos en contacto, no dejes de comentarnos lo que hagas y observes. Gracias.

Al González.

[Casimiro Notevi]

Empezado por Al González

Para fortuna, descubrí que la misma sentencia es utilizada por los IBX (estos señores de los MDO se la copiaron tal cual , a no ser que MDO llame a unidades de los IBX ):

Son iguales porque MDO, IBX y FIBplus son hijos de FreeIB, el padre de todas ellas.

[[Al González]]

Empezado por Casimiro Notevi

Son iguales porque MDO, IBX y FIBplus son hijos de FreeIB, el padre de todas ellas.

Vale.

[Angel Fernández]

De nuevo gracias a todos, especialmente a Al que me pone "deberes" . Disculpad si no paso por aquí todos los días pero es que ahora andamos de exámenes finales y voy un poquito de cráneo.
Cuando haga algunas pruebas os digo algo.

Un saludo.

[bismarck_sierra]

Que tal

Yo también tengo el mismo problema que Angel, yo utilizo Delphi7, DBExpress, Firebird 1.554926.

La primera consulta me tarda aproximadamente 30 segundos, después de eso se ejecutan en un tiempo normal de menos de un segundo. Mis tablas no rebasan el millón de registros, apenas lo están alcanzando: 935,113. El tamaño de la base de datos es de 400 MB

Intenté con otros componentes de conexión para probar si DBExpress era la causa, pero no fue así.


Ya probé la opción que da Al sobre la afinación a los índices pero no solucionó el problema.

Haré algunas pruebas con Linux para poder culpar sin dudas a Windows y también haré las pruebas aisladas que comenta Al.

Saludos.
Bismarck

[Angel Fernández]

Empezado por bismarck_sierra

Que tal

...
La primera consulta me tarda aproximadamente 30 segundos, después de eso se ejecutan en un tiempo normal de menos de un segundo. Mis tablas no rebasan el millón de registros, apenas lo están alcanzando: 935,113. El tamaño de la base de datos es de 400 MB

Intenté con otros componentes de conexión para probar si DBExpress era la causa, pero no fue así.

...

Haré algunas pruebas con Linux para poder culpar sin dudas a Windows y también haré las pruebas aisladas que comenta Al.

Saludos.
Bismarck

Bienvenido Bismark al hilo de las lentitudes. No dejes de decirnos si las pruebas que haces con Linux son satisfactorias.

¿Has probado con FIBPLUS? Yo he probado y ha desaparecido el parón aunque, extrañamente, hay alguna otra lentitud en momentos muy puntuales, pero no soy capaz de detectar un hilo conductor. De todos modos, con fib ha mejorado considerablemente.

Mi BD tiene 6 millones y pico de datos y ocupa más de un 1.5 GB. Estoy un poco asustado porque ahora mismo tenemos datos de 3 meses. Cuando tengamos todo un año de datos tendremos una base de 4.5 Gb aprox. En windows un fichero tan grande se fragmenta muchísimo y hay que estar desfragmentando cada semana. Si en linux esto no ocurre, puede ser un puntazo a favor.

Los deberes que me puso Al, siento decir que aún no me he puesto con ello. Es final de curso y tengo muchísimo trabajo. A ver si en 15 días hago las pruebas.

Un saludo.

[Angel Fernández]

Compañeros:

He logrado solucionar el problema... de forma accidental, como se logran los mayores avances en la ciencia.

Aún no he tenido tiempo de hacer las pruebas que el maestro Al me puso como deberes (este final de curso se está complicando demasiado; por poner un ejemplo, casi pierdo mi puesto de trabajo y aún no está todo solucionado) pero trasteando con otras cosas creo haber hallado la solución.

La solución pasa por hacer un gbak y luego restaurar la base de datos con un tamaño de página muy grande; yo le he puesto el mayor: 16384. Con esto he logrado hacer desaparecer la lentitud en la consulta a la tabla de sensores. Y no sólo eso: una consulta muy complicada que sobre una base FDB con tamaño de página de 1024 tarda más de 7 minutos, he logrado reducirla a menos de dos minutos con la base FDB con tamaño de página de 16384.

Una advertencia: quizá esta solución no sirva para cualquier base fdb. Mi base es enorme: ahora mismo tiene unos 7 millones de registros y ocupa en disco 1,2 GB.

Estoy hablando de una base fdb sobre Win XP SP2, usando firebird 2.0 y Delphi 7.

Espero haber ayudado a otra gente con el mismo problema.

Un saludo para todos y muchísimas gracias a todos los que me habéis ayudado.

[Delfino]

Podemos entender q el problema no tenia q ver con componentes?
y eso de q con FibPlus se soluciono y con los otros no?

a Ver si das mas detalles

[Angel Fernández]

Empezado por Delfino

Podemos entender q el problema no tenia q ver con componentes?
y eso de q con FibPlus se soluciono y con los otros no?

a Ver si das mas detalles

Pues la verdad no puedo dar muchos más detalles porque lo he solucionado de rebote. No puedo decir que no tenía nada que ver con componentes porque, como dije, con fibplus el problema mejoró pero no se arregló del todo. Es decir, había una cierta lentitud pero no tanta como cuando accedía a la tabla de sensores la primera vez desde mdo.
Hay que recordar que el problema ocurría sólo la primera vez que se accedía a la tabla. Las veces sucesivas todo iba como la seda.

Lo que sí puedo decir al 90% (no al 100% porque no he hecho muchas pruebas) es que aumentando el tamaño de paginación de la BD el acceso mejora y mucho. Ya no tengo esa demora de 30 segundos en el primer acceso a la tabla. Ahora es de menos de 1 segundo. He hecho varias pruebas y va bien. Pero muchísimo mejor. Todas las consultas tardan menos de la mitad de tiempo.

Tengo que añadir una cosa que enturbia un poco esto que digo: también le he aumentado la ram a mi ordenador. De 1 GB he pasado a tener 2,5 GB. Sin embargo, con 2,5 GB he hecho pruebas con la base de datos con tamaño de página de 1024 y vuelve a ser lento todo. Con lo cual concluyo que sin duda el aumento de ram ayuda y mucho, pero el problema se ha "resuelto" con el aumento del tamaño de página. (Pongo "resuelto" entre comillas porque parece que no me lo termino de creer).

Os iré diciendo si hago más pruebas y logro sacar más conclusiones.

Un saludo.

[[Al González]]

¡Hola Ángel!

Cuando tengas oportunidad, prueba el procedimiento almacenado de "afinación de índices" que te recomendé, bajo las mismas condiciones en que se encontraba tu base de datos.

Código Delphi [-]
CREATE PROCEDURE SPACTUALIZARINDICES 
AS
DECLARE VARIABLE NOMBRE VARCHAR(31);
Begin
  For Select RDB$Index_Name From RDB$Indices Into :Nombre Do
    Execute Statement 'Set Statistics Index ' || :Nombre;
End

Sospecho que eso hubiese ayudado en buena medida.

Saludos desde Zacatecas (camino a Chihuahua ).

Al.

[Angel Fernández]

Al, lamento decir que no funciona el código que tan amablemente me propones. Lo ejecuto antes de lanzar la consulta y nada, tarda 30 segundos.

Sin embargo, puedo aportar algún dato más a este laberinto. Cuando he tratado de hacer un restore (de un archivo fbk) con tamaño de página 1024, para que la bd resultante fuera "lenta", me he encontrado con que no era "lenta". Iba bien. He tenido que recuperar una copia de la bd original "lenta" para realizar la comprobación que me dice Al.

Haciendo un pequeño esquema, esto es lo que obtengo:

Código a emplear BD_tamaño de página_lenta/OK (Ej: BD1_1024_lenta)

Esquema:

BD1_1024_lenta -- backup --> FBK1 -- restore (con opción -p 16834) --> BD2_8024_OK.

Si ahora hago FBK1 -- restore (con opción -p 1024) --> BD3_1024_OK (??? No entiendo que vaya OK)

No sé si el esquema ayuda a entender o lo complica aún más. El caso es que restaurando el fichero FBK, sin importar el tamaño de página, la base de datos resultante funciona bien.

¿Al final va a resultar que un simple backup-restore soluciona el problema?

Quizá sí. Sin embargo, me reafirmo en lo dicho de que a mayor tamaño de página, mejor rendimiento.

Espero vuestros comentarios.

Un saludo. (Muchas gracias Al, guardo tu código como oro en paño).

[Casimiro Notevi]

Empezado por Angel Fernández

[..] Sin embargo, me reafirmo en lo dicho de que a mayor tamaño de página, mejor rendimiento. [..]

Es conveniente que sea de 8 Kb al menos, 8192.

En tu caso, si se soluciona haciendo un backup/restore, entonces puede ser que tuvieras algún problemilla en la base de datos o los índices muy "desbalanceados". Seguramente será esto último.

[Delfino]

o los índices muy "desbalanceados"

Seguramente era eso

Se recomienda el tamaño de 4k, q es el mismo q usa el sistema operativo, pero si hay campos blob voluminosos se recomienda el del 8k..

al final va a ser q el tamaño importa en tu caso, como en muchos otros casos de la vida