Problemas de lentitud Firebird
 

Saludos....

Tengo un problema grande con una base de datos que esta en firebird 2.

Les comento lo que se ha realizado: la base de datos mide mas o menos unos 6 GB inicialmente se tenia la base de datos en firebird 1.5, se obtuvo el backup de 1.5 y se paso a firebird 2. La aplicacion genera una consulta SQL en firebird 1.5 en mas o menos 2 segundos, verifique el plan de la consulta y no tiene planes naturales todo esta indexado. Luego la misma consulta en firebird 2 se demora en mas de 3 minutos.....La verdad estoy desconsertado no se que le pudo pasar a la base de datos....no se que hacer...

:confused:

No vaya a ser q al restaurar la BD se desactivaron los indices?
tiene toda la pinta :cool:

Hola, como puedes imaginar, con tan poca información como das es imposible ayudarte.

¿ Porqué no nos pones la consulta, los índices que tienes definidos y el plan de ejecución ?.

NOTA: Tampoco estaría mal decirnos si lo has pasado a Firebird 2.0x, 2.1x o 2.5x.

Saludos.

Para salir de dudas sobre los índices, puedes abrir el ISQL e introducir la sentencia:

ISQL>SHOW INDICES;

Naturalmente una vez te hayas conectado con la base de datos.

Un Saludo.

Saludos...

La base esta en firebird 2.1.2.18118.0.
estoy trabajando con EMSInterbase/firebird para administrar la base de datos.
Esta montada en un servidor linux

verifique en rdb$indices y el campo rdb$index_inactive esta en 0

el plan de la consulta da lo siguiente.

Código SQL [-]
SELECT A.DesActividad, P.SecPortafDet,
A.CodActividad, A.secActividad, J.*,
P.RS_Cat_Id, M.DesTipo_Manual
FROM TblPortafDet P
LEFT JOIN TblActividad A ON P.Cod_Actividad = A.secActividad
LEFT JOIN J_CONTRATACION_Items J ON P.Cod_Actividad = J.ci_datakey
AND P.RS_Cat_Id = J.ci_cat_id

LEFT JOIN TblTipo_Manual M ON A.SecTipo_Manual = M.SecTipo_Manual
WHERE P.SecPortafolio = 402 and A.desactividad is not NULL ORDER BY A.DesActividad

esta tabla JOIN J_CONTRATACION_Items tiene 3 campos en total.




Plan:
PLAN SORT (JOIN (JOIN (JOIN (P INDEX (IDX_TBLPORTAFDET1), A INDEX (PK_ACTIVIDAD)), J INDEX (J_CONTRATACION_DATAKEY_IDX, IDX_J_CONTRATACION_ITEMS)), M INDEX (PK_TIPO_MANUAL)))

Plan tomado:
PLAN SORT (JOIN (JOIN (JOIN (P INDEX (IDX_TBLPORTAFDET1), A INDEX (PK_ACTIVIDAD)), J INDEX (J_CONTRATACION_DATAKEY_IDX, IDX_J_CONTRATACION_ITEMS)), M INDEX (PK_TIPO_MANUAL)))

al ejecutar la consulta se verifica el estado de CPU del servidor y pasa del 100%

este es el estado de la base de datos

[root@homero2 bin]# ./gstat -h /part1/jerarquias.fdb

Database "/part1/jerarquias.fdb"
Database header page information:
Flags 0
Checksum 12345
Generation 116
Page size 8192
ODS version 11.1
Oldest transaction 77
Oldest active 78
Oldest snapshot 78
Next transaction 107
Bumped transaction 1
Sequence number 0
Next attachment ID 10
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jan 27, 2010 18:50:53
Attributes

Variable header data:
Sweep interval: 0
*END*

///**************

se corrieron los siguientes comandos.

/opt/firebird/bin/gbak -backup -v -ignore -garbage -limbo -user sysdba -password zitiz jerarquias.fdb jerarquia.gbk

y para el gfix

gfix -v -full basededatos.gdb

gfix -mend -full -ignore basededatos.gdb

Para poder ver si la consulta está bien interpretada también deberías decirnos que campos componen los índices que aparecen en el plan.

En cualquier caso tu consulta es muy sencilla, y los índices que debe tener para que se pueda ejecutar de forma óptima son muy claros.

Deberías tener estos índices :

Tabla TblPortafDet -> Indice sobre : SecPortafolio
Tabla TblPortafDet -> Indice compuesto : Cod_Actividad, RS_Cat_Id
Tabla TblActividad -> Indice sobre : secActividad
Tabla TblActividad -> Indice sobre : desActividad
Tabla TblActividad -> Indice sobre : SecTipo_Manual
Tabla J_CONTRATACION_Items -> Indice compuesto : ci_datakey, ci_cat_id
Tabla TblTipo_Manual -> Indice sobre : SecTipo_Manual

Cuando no estás seguro de que índices necesitas, lo mejor es poner un índice a todos los campos involucrados en las uniones de tablas y en el filtro del where. Utilizando índices compuestos cuando en el mismo nivel de filtrado de la base de datos intervienen dos campos de la misma tabla. Esto da al optimizador de consultas de Firebird la mayor libertad para elegir el mejor camino para cruzar tus datos.


NOTA: Fíjate que la ordenación final la haces sobre un campo que no es de la tabla primaria de la consulta. Depende de como estén llenas las tablas esto puede confundir al optimizador de Firebird. Esta consulta hace lo mismo pero seguirá un plan distinto que puede resultar más eficiente :

SELECT A.DesActividad, P.SecPortafDet,
A.CodActividad, A.secActividad, J.*,
P.RS_Cat_Id, M.DesTipo_Manual
FROM TblActividad A
LEFT JOIN TblPortafDet P ON P.Cod_Actividad = A.secActividad
LEFT JOIN J_CONTRATACION_Items J ON P.Cod_Actividad = J.ci_datakey
AND P.RS_Cat_Id = J.ci_cat_id
LEFT JOIN TblTipo_Manual M ON A.SecTipo_Manual = M.SecTipo_Manual
WHERE P.SecPortafolio = 402 and A.desactividad is not NULL ORDER BY A.DesActividad

Saludos

Respecto a los comandos que ejecutaste, falta la restauración de la base de datos.

Siempre que pasas una base de datos de una versión de Firebird a otra superior, es conveniente hacer un Backup (preferiblemente desde la versión antigua, aunque no es imprescindible) y Restaurarla desde la nueva versión (durante la restauración se reconstruye la base de datos).

En concreto los pasos son ejecutar primero los gfix (aunque solo son necesarios si tu base de datos se ha corrompido, cosa que no parece el caso).

Después ejecutas el Backup, tal como lo tienes definido.

Y finalmente hay que restaurar la copia de seguridad. Es decir :

/opt/firebird/bin/gbak -rep -v -user sysdba -password zitiz jerarquias.gbk jerarquia.fdb

NOTA: No te olvides de hacer una copia física del archivo jerarquias.fdb antes de restaurar la base de datos, por si algo va mal durante la reconstrucción de la base de datos.

Muchas gracias por contestar....

El proceso de backup - restore...se realiza como dices...inicialmente el backup en firebird 1.5 y se restaura en 2...los comandos los coloque para que se mirara los parametros utilizados...respecto a los indices estan bien...el problema persiste, se realizan pruebas en equipos de menos caracteristicas con el mismo firebird y la consulta se genera en 2 segundos...pero en este super equipo se demora 3 minutos...verifique en la tabla de indices del sistema de la base, y el campo que relacione anteriormente esta nulo...me imagino que el nulo es tomado como un cero...igual lo coloque a cero y sigue lo mismo...no se para que sirve el campo rdb$index_type hay unos nulos y otros en cero. Verifique esa misma tabla cuando estaba en 1.5 y tiene los mismos datos..el cachepages del firebird.conf lo coloque a 8192 estaba a 16384 pero igual con las dos configuraciones se demora mucho en la consulta.:confused:

algo que probe en este moment si se le quita el order by queda rapida la consulta....a que se debe...si en otros equipos con firebird 2 la consulta tiene el order by y es rapida??

Hola.

Precisamente por el order by que tienes en la consulta te he sugerido una consulta alternativa que le facilita al optimizador de consultas de Firebird un camino óptimo a esa ordenación. ¿ La has probado ?.

Respecto a tus índices, ¿ como sabes que estan bien ?, ¿ has probado a crear los índices que te he sugerido ?, si quieres conocer la opinión que podamos tener los demás respecto a si tus índices estan bien, te sugiero que nos digas sobre que campos estan creados tus indices, tal y como ya te pedí.

Saludos.