Consulta muy sencilla, extrañamente lenta

[Angel Fernández]

Hola a todos. Por aquí de nuevo, con algo de retraso pero es que voy muy liado últimamente.

Casi he conseguido localizar dónde se produce el parón. Con F8 como me indicaba Al va mucho mejor que F7 que era para salir loco .

Al grano: he dicho "casi" porque tengo el procedimiento donde se produce el parón, pero no la línea. El procedimiento es el siguiente:
TMDOSQL.Prepare

Ahora no puedo pasarle otra vez el F8 porque el problema, recordad, era sólo para la primera vez. (Manda huevos).

En fín, aquí sigo, investigando...

Un saludo.

[[Al González]]

Empezado por Angel Fernández

...tengo el procedimiento donde se produce el parón, pero no la línea. El procedimiento es el siguiente:
TMDOSQL.Prepare...

Coloca un punto de ruptura en el Begin de ese método. Ejecuta el programa de manera normal y cuando tu consulta se ejecute y se detenga en ese punto de ruptura, continúa de nuevo con F8/F7 dentro de las sentencias de esa rutina.

Ya acorralaste a la anomalía, casi la has cazado.

Seguimos leyéndote.

Al.

[Delfino]

Pero esta tardanza ocurre sólo la primera vez que se abre el MDODATASET

No creo q la causa sean los MDO, a mi me paso una vez y la causa era el campo lookup, mas concretamente abrir la tabla lookup en un momento inadecuado..

[Angel Fernández]

Hola, de nuevo por aquí con algo más de información.

Empezado por Al González

Ya acorralaste a la anomalía, casi la has cazado.
Al.

Gracias Al por tu apoyo pero me temo que voy a defraudarte. He encontrado la línea de código que ocasiona el parón.
Concretamente es la unit MDOSQL.PAS procedure TMDOSQL.PREPARE (copio y pego directamente del editor para tratar de ubicar un poco mejor el problema):

Código Delphi [-]procedure TMDOSQL.Prepare;
var stmt_len: Integer; res_buffer: array[0..7] of Char;
type_item: Char;
begin if FCursor = '' then FCursor := Name + RandomString(8); CheckClosed; FBase.CheckDatabase; FBase.CheckTransaction; if FPrepared then exit; if (FSQL.Text = '') then MDOError(mdoeEmptyQuery, [nil]);
if not ParamCheck then FProcessedSQL.Text := FSQL.Text else PreprocessSQL; if (FProcessedSQL.Text = '') then MDOError(mdoeEmptyQuery, [nil]);
try Call(isc_dsql_alloc_statement2(StatusVector, DBHandle, @FHandle), True); {PROBLEMA --> } Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0, PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True);
{ After preparing the statement, query the stmt type and possibly
create a FSQLRecord "holder" } { Get the type of the statement } type_item := Char(isc_info_sql_stmt_type); Call(isc_dsql_sql_info(StatusVector, @FHandle, 1, @type_item, SizeOf(res_buffer), res_buffer), True); if (res_buffer[0] <> Char(isc_info_sql_stmt_type)) then MDOError(mdoeUnknownError, [nil]);
stmt_len := isc_vax_integer(@res_buffer[1], 2);
FSQLType := TMDOSQLTypes(isc_vax_integer(@res_buffer[3], stmt_len));
{ Done getting the type } case FSQLType of SQLGetSegment, SQLPutSegment, SQLStartTransaction: begin FreeHandle; MDOError(mdoeNotPermitted, [nil]);
end;
SQLCommit,
SQLRollback,
SQLDDL, SQLSetGenerator,
SQLInsert, SQLUpdate, SQLDelete, SQLSelect, SQLSelectForUpdate,
SQLExecProcedure: begin { We already know how many inputs there are, so... } if (FSQLParams.FXSQLDA <> nil) and (Call(isc_dsql_describe_bind(StatusVector, @FHandle, Database.SQLDialect, FSQLParams.FXSQLDA), False) > 0) then MDODatabaseError; FSQLParams.Initialize; if FSQLType in [SQLSelect, SQLSelectForUpdate,
SQLExecProcedure] then begin { Allocate an initial output descriptor (with one column) } FSQLRecord.Count := 1; { Using isc_dsql_describe, get the right size for the columns... } Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True); if FSQLRecord.FXSQLDA^.sqld > FSQLRecord.FXSQLDA^.sqln then begin FSQLRecord.Count := FSQLRecord.FXSQLDA^.sqld; Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True); end else if FSQLRecord.FXSQLDA^.sqld = 0 then FSQLRecord.Count := 0; FSQLRecord.Initialize; end;
end;
end;
FPrepared := True;
if not (csDesigning in ComponentState) then MonitorHook.SQLPrepare(Self); except on E: Exception do begin if (FHandle <> nil) then FreeHandle; raise;
end;
end;
end;


Y ya no sé qué mas hacer. Yo no soy capaz de resolver el problema ni aún sabiendo que está en esa línea.

Lo que dije en un post anterior que con FIBPLUS se solucionaba, no es del todo cierto. Se soluciona al acceder a la tabla sensores en un primer momento, pero extrañamente, aparece el parón con retardo.

Entiendo que debe ser algo relacionado con los registros que dependen de la tabla sensores. Hay que recordar que de esta tabla dependen dos tablas más que son las que almacenan los datos, y ahora mismo tienen más de 6 millones de datos entre las dos. Esto lo he deducido de una de mis múltiples pruebas a ciegas: he quitado los datos de las tablas de datos y el parón en la tabla de sensores desaparece (al menos así parece). ¿Es posible que un número muy grandes de datos de una tabla dependiente ocasione retardo en la tabla madre? Todo esto me da un dolor de cabeza tremendo y me temo que lo voy a dejar así.

De lo que apunta Delfino de un campo lookup abierto en un momento inadecuado, no creo que sea eso porque ya desactivé el campo lookup y el problema persistía.

Gracias a todos por vuestras aportaciones y en especial a Al que me ha animado a "cazar" la anomalía (aunque el cazador en este caso es un novato con un rifle de perdigones que no mataría ni un pollito). Si se te ocurre alguna otra prueba, Al, dímela y encantado la hago.

Un saludo.

[Angel Fernández]

Perdón, al hacer vista previa de mensaje, el código delphi se veía bien, pero al enviar la respuesta definitiva me lo formatea mal.

Vuelvo a enviar el código delphi formateado:

Código Delphi [-]
procedure TMDOSQL.Prepare;
var
  stmt_len: Integer;
  res_buffer: array[0..7] of Char;
  type_item: Char;
begin
  if FCursor = '' then
    FCursor := Name + RandomString(8);
  CheckClosed;
  FBase.CheckDatabase;
  FBase.CheckTransaction;
  if FPrepared then
    exit;
  if (FSQL.Text = '') then
    MDOError(mdoeEmptyQuery, [nil]);
  if not ParamCheck then
    FProcessedSQL.Text := FSQL.Text
  else
    PreprocessSQL;
  if (FProcessedSQL.Text = '') then
    MDOError(mdoeEmptyQuery, [nil]);
  try
    Call(isc_dsql_alloc_statement2(StatusVector, DBHandle,
                                    @FHandle), True);
    Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0,
               PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True);
    { After preparing the statement, query the stmt type and possibly
      create a FSQLRecord "holder" }
    { Get the type of the statement }
    type_item := Char(isc_info_sql_stmt_type);
    Call(isc_dsql_sql_info(StatusVector, @FHandle, 1, @type_item,
                         SizeOf(res_buffer), res_buffer), True);
    if (res_buffer[0] <> Char(isc_info_sql_stmt_type)) then
      MDOError(mdoeUnknownError, [nil]);
    stmt_len := isc_vax_integer(@res_buffer[1], 2);
    FSQLType := TMDOSQLTypes(isc_vax_integer(@res_buffer[3], stmt_len));
    { Done getting the type }
    case FSQLType of
      SQLGetSegment,
      SQLPutSegment,
      SQLStartTransaction: begin
        FreeHandle;
        MDOError(mdoeNotPermitted, [nil]);
      end;
      SQLCommit,
      SQLRollback,
      SQLDDL, SQLSetGenerator,
      SQLInsert, SQLUpdate, SQLDelete, SQLSelect, SQLSelectForUpdate,
      SQLExecProcedure: begin
        { We already know how many inputs there are, so... }
        if (FSQLParams.FXSQLDA <> nil) and
           (Call(isc_dsql_describe_bind(StatusVector, @FHandle, Database.SQLDialect,
                                        FSQLParams.FXSQLDA), False) > 0) then
          MDODatabaseError;
        FSQLParams.Initialize;
        if FSQLType in [SQLSelect, SQLSelectForUpdate,
                        SQLExecProcedure] then
        begin
          { Allocate an initial output descriptor (with one column) }
          FSQLRecord.Count := 1;
          { Using isc_dsql_describe, get the right size for the columns... }
          Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True);
          if FSQLRecord.FXSQLDA^.sqld > FSQLRecord.FXSQLDA^.sqln then
          begin
            FSQLRecord.Count := FSQLRecord.FXSQLDA^.sqld;
            Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True);
          end else if FSQLRecord.FXSQLDA^.sqld = 0 then
            FSQLRecord.Count := 0;
          FSQLRecord.Initialize;
        end;
      end;
    end;
    FPrepared := True;
    if not (csDesigning in ComponentState) then
      MonitorHook.SQLPrepare(Self);
  except
    on E: Exception do
    begin
      if (FHandle <> nil) then
        FreeHandle;
      raise;
    end;
  end;
end;

Disculpad.

[Angel Fernández]

Y ahora me olvido indicar la línea con el problema.
Es ésta:

Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0,
PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True);

Ruego a los moderadores perdonen mi torpeza (aunque en mi descargo diré que es un problema del botón "Vista Previa de Mensaje")

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

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