FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
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...
__________________
Popayán-Colombia |
#2
|
|||
|
|||
No vaya a ser q al restaurar la BD se desactivaron los indices?
tiene toda la pinta |
#3
|
||||
|
||||
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. |
#4
|
||||
|
||||
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.
__________________
Guía de Estilo de los Foros Cita:
|
#5
|
|||
|
|||
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.
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
__________________
Popayán-Colombia Última edición por andresenlared fecha: 28-01-2010 a las 16:21:11. |
#6
|
||||
|
||||
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 Última edición por guillotmarc fecha: 28-01-2010 a las 17:27:36. |
#7
|
||||
|
||||
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. |
#8
|
|||
|
|||
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. 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??
__________________
Popayán-Colombia Última edición por andresenlared fecha: 28-01-2010 a las 18:31:01. |
#9
|
||||
|
||||
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. Última edición por guillotmarc fecha: 29-01-2010 a las 12:10:51. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Lentitud en acceso remoto a Firebird | rretamar | Firebird e Interbase | 10 | 07-04-2009 20:59:33 |
Lentitud Firebird | mjjj | Conexión con bases de datos | 16 | 13-01-2008 17:35:06 |
Lentitud en Cliente FireBird.... | AGAG4 | Firebird e Interbase | 7 | 29-03-2005 16:56:51 |
Lentitud de FireBird 1.03 en Windows 2003 | El_Perrito | Firebird e Interbase | 1 | 12-08-2004 09:21:25 |
problemas de lentitud | Giniromero | Conexión con bases de datos | 3 | 28-07-2003 13:24:55 |
|