Consulta muy sencilla, extrañamente lenta

[Angel Fernández]

Saludos al foro.

Quería consultaros un problemilla muy tonto que tengo pero que no acierto a ver cual podría ser el origen. Me explico: Tengo una base de datos enorme donde se recogen datos de unos sensores. Tengo una tabla de sensores con la siguiente estructura:

Nombre del Campo Tipo Not null Explicación
-------------------------------------------------------------------------------------------------
IDSENSOR * INTEGER TRUE (Clave primaria,autoincremento)
IDPROYECTO INTEGER TRUE (Apunta a la tabla de proyectos)
IDTIPOSENSOR * INTEGER TRUE (Apunta a la tabla tiposensor)
REF CHAR(6) TRUE (Referencia corta) *
UBICACION VARCHAR(150) FALSE (Lugar donde se encuentra, no obligatorio)
NOMBRE * VARCHAR(50) FALSE (Nombre largo, no obligatorio)
ACTIVO SMALLINT TRUE (0 Inactivo, 1 Activo)
BUENAFUNCION SMALLINT TRUE (0 No va bien, 1 Va bien)

* = indica que hay índice ascendente.

Un ejemplo de los datos que contiene:

IDSENSOR IDPROYECTO IDTIPOSENSOR REF UBICACION NOMBRE ACTIVO BUENAFUNCION
------------------------------------------------------------------------------------------------------------------------------------------------
184 1 1 TEM001 Azotea SENSOR TEMPERATURA 001 1 1
185 1 1 TEM002 Azotea SENSOR TEMPERATURA 002 1 1
186 1 1 TEM003 Azotea SENSOR TEMPERATURA 003 1 1
187 1 1 TEM004 Azotea SENSOR TEMPERATURA 004 1 1
188 1 1 TEM005 Azotea SENSOR TEMPERATURA 005 1 1
189 1 1 TEM006 Azotea SENSOR TEMPERATURA 006 1 0
190 1 1 TEM007 Azotea SENSOR TEMPERATURA 007 1 1

Y así hasta 70 registros (setenta, menos de cien, no setenta mil, es decir, muy pocos registros).

La tabla Tiposensor tiene la siguiente estructura:

Nombre del Campo Tipo Not null
-------------------------------------------------------------------------------------------------
IDTIPOSENSOR * INTEGER TRUE (clave primaria, autoincremento)
TIPO_LARGO * VARCHAR(20) TRUE (Nombre largo, obligatorio)
TIPO* CHAR(3) TRUE (Nombre corto, obligatorio) *
ACTIVO SMALLINT TRUE (1=activo, 0=no activo) (No lo uso)
IDTABLADATOS * INTEGER TRUE (Apunta a otra tabla)
IDTIPODATO * INTEGER TRUE (Apunta a otra tabla)

* = indica que hay índice ascendente.

Esta tabla sólo tiene 6 registros:

IDTIPOSENSOR TIPO_LARGO TIPO ACTIVO IDTABLADATOS IDTIPODATO
----------------------------------------------------------------------------------------------------------------
0 INDEFINIDO NOT 1 0 0
1 TEMPERATURA EN ºC TEM 1 1 2
2 HUMEDAD HUM 1 1 1
3 LLUVIA LLU 1 2 4
4 ENCHARCAMIENTO ENC 1 2 5
5 TEMPERATURA EN ºK TEK 1 1 3

Y en fín, el problema:
Tengo un MDODataSet con el siguiente SelectSQL: 'select * from sensores order by ref' Esto me devuelve 70 registros y tarda ¡30 segundos!
Pero esta tardanza ocurre sólo la primera vez que se abre el MDODATASET; las siguientes veces tarda menos de 1 segundo que es lo lógico y esperable.
El MDODATASET tiene los campos de datos y además un campo lookup que apunta a la tabla TipoSensor para traer el tipo de sensor, y dos campos calculados que son del tipo booleano para convertir los campos ACTIVO y BUENAFUNCION al tipo true/false.

He probado de todo: quitar la apertura del mdodataset del evento formshow, quitar los campos calculados y lookup .... y ya no se me ocurre nada más.
Estoy desesperadico.

¿Alguna idea? ¿A alguien le ha pasado algo parecido? ¿Es un bug de los MDO?

Uso D7, Firebird 2.0 y componentes MDO.

Gracias de antemano.

PD: Perdón por el rollo.

[[Al González]]

¡Hola!

Prueba si la conexión por sí misma tiene esa demora, abriéndola explícitamente antes de lanzar ninguna consulta.

Algo como "ConexionMDO.Open;" (desconozco los componentes MDO). Podría tratarse de un retardo provocado por un factor externo a la base de datos, como un contrafuegos o algo por el estilo (aunque me parece mucho tiempo).

También puedes verificar si te da tiempos similares abriendo la base de datos y ejecutando la consulta desde IB Expert o el programa administrativo que uses.

Por otro lado, puede que tu programa esté realizando (quizá desde algún evento) alguna operación que demora mucho tiempo cuando se abre la base de datos o ejecuta la consulta. Sería cuestión de revisar el código.

La depuración paso a paso (F7/F8) puede ayudarte a indagar en qué punto del código se está demorando la operación.

No dejes de retroalimentar el hilo pa' saber que jue.

Saludos.

Al.

[juanelo]

Hola Angel,
Puedes revisar esta informacion
Saludos

[luchifer]

Una vez tuve un problema similar trabajando con oracle y se debio a la configuracion del rollback del mismo.

No se que base de datos estes usando pero para que se te ponga tan lenta es que la conexion con esa base de datos esta usando los drives incorrectos por ejm si usas oracle en lugar de usar el driver de orcl estes usando el de odbc o mssql.

Otra posible causa es que tue equipo tenga virus, especificamente gusanos

Avisame como te fue

[Casimiro Notevi]

La consulta debería ser instantánea, comprueba, tal y como te ha comentado Al González, depurar el programa paso a paso y asegurarte de que lo lento no es el abrir/conectar a la base de datos.

[RolphyReyes]

Saludos.

Prueba a ver si te falta algún indice por el campo que vas a ordenar, si usas IbExpert te marcara si esta consulta utiliza un PLAN NATURAL y podrás poner el indice adecuado.

Hasta luego.

[Angel Fernández]

Gracias a todos por vuestras intervenciones.
Hasta ahora todos los intentos son infructuosos. Como me indican Al y Casimiro he mirado el programa paso a paso y el parón se produce al hacer open.
Lo de los drivers que apunta luchifer no es porque uso firebird 2.0 y no tengo problema en otros programas.
Lo de un posible virus, hombre nunca se puede descartar eso, pero me llevo el programa a otro ordenador y produce el mismo resultado. Que haya el mismo gusano en dos ordenadores distintos es poco probable, a no ser que sea mi programa el que lo lleva. Acabo de pasarle el antivirus y nada.
Ahora mismo, lo único que se me ocurre es que sea un bug de los componentes MDO. Curiosamente, desde IBManager la consulta es rápida, y desde otro programa mío que no usa MDO sino FIBPLUS también es rápida. Y también curioso que todo este problema me lo da única y exclusivamente con una tabla, la de sensores, que sólo tiene 70 datos aunque estoy haciendo pruebas continuamente y estoy añadiendo y borrando datos. Y la lentitud se produce también si accedo a sensores desde un MDOQUERY.
Tengo otra tabla que recoge los datos de los sensores, con 5 millones de datos y consultas mucho más complicadas tardan 40 segundos.

Ahorita mismo estoy totalmente perdido. Sólo se me ocurre sustituir el MDO por FIBPLUS.
¡Ah! Lo que me apuntaba juanelo: he leído la información que me sugerías pero no he sacado nada en claro. Al parecer a aquella persona le pasaba lo mismo que a mí pero no logró solucionarlo o no lo indica.
Otro dato: la base de datos FB tiene extensión FDB y no GDB que, al parecer, da problemas.
Si consigo alguna solución, la comentaré.
Un saludo.

[Angel Fernández]

Añadido:

Lo que comenta Rolphi de los índices ya lo he revisado y todos los campos por los que ordeno tienen índice.

Un saludo.

[[Al González]]

¡Hola!

Te agradezco que hayas retroalimentado el hilo.

Empezado por Angel Fernández

...Hasta ahora todos los intentos son infructuosos...he mirado el programa paso a paso y el parón se produce al hacer open....Sólo se me ocurre sustituir el MDO por FIBPLUS...

Compila el programa con la opción "Use Debug DCUs" (opciones del proyecto) y coloca un punto de ruptura (break point) en la sentencia que hace el "Open". Cuando llegue ahí el programa, usa la tecla F7 para entrar a ese método y luego combina F7 con F8 según convenga para navegar en los fuentes y ver en qué parte concreta de MDO/VCL se está demorando y por qué.

Esperamos tus comentarios.

Al.