Firebird - Inserts lentísimos en Linux

[mcs]

Empezado por Casimiro Notevi

Yo siempre uso:

read_committed
rec_version
nowait

tengo estas mismas opciones...

[mcs]

Hola,

He estado mirando el rendimiento de mi aplicación mediante el dbMonitor de DevArt (la utilidad de monitoreo de funciones SQL y tal), y la cosa es bastante "simple":
- Los "SELECT * FROM tabla" tardan aproximadamente 0,00 segundos (son tablas pequeñitas, de máximo 1500 registros)
- Los "SELECT COUNT(*) FROM tabla" tardan aproximadamente 0,016 segundos
- Los "DELETE FROM ..." tardan aproximadamente 1,172 segundos (y estaba borrando UN registro)
- Los "INSERT INTO..." tardan aproximadamente 1,562 segundos (y estaba insertando UN registro)
- Después de los DELETE e INSERT, se ejecuta una cosa que se llama "CommitRetaining:" (que no sé que es y yo no lo llamo, debe ser cosa del componente) y tarda 1,152 seg en el caso del DELETE, y 1,547 seg en caso del INSERT

Que hago mal? Y que es esto del "CommitRetaining"? Que puedo hacer para mejorar el rendimiento? Pruebo de poner un Firebird (server) en una máquina con Windows XP y miro si el rendimiento es el mismo que en el servidor Linux?

[Casimiro Notevi]

El commit y el commitretaining sirven para confirmar el cambio hecho en la BD (insert, update, delete), si no haces commit entonces no se guardan los datos.

Creo que el problema va a ser de tu BD, que no tenga bien definido los índices, relaciones, etc. imposible de saber si no la podemos ver y no sabemos las sentencias exactas que haces.

[mcs]

Creación de la base de datos:

Código SQL [-]
create database "ttpv.fdb" user "sysdba" password "masterkey"
  default character set utf8

Creación de una de las tablas:

Código SQL [-]
create generator gen_fam;
set generator gen_fam to 0;

create table familias (
   id int not null primary key,
   cod int,
   nom varchar(50),
   dto integer
   );

create trigger familias_bi for familias
active before insert 
position 0 as 
begin 
  if (new.id is null or new.id=0) then 
  new.id=gen_id(gen_fam, 1);
end!!

Inserción de un registro en la tabla familias:

Código SQL [-]
INSERT INTO familias (cod, nom, dto) 
VALUES (:COD, :NOM, :DTO);

Borrado de un registro en la tabla familias:

Código SQL [-]
DELETE FROM familias
 WHERE id=:ID;

Como puedes ver, es más simple que el mecanismo de un botijo... No hay ningún índice (a excepción del ID que es una primary key), y no creo que sea culpa del trigger, no?

La verdad, es que ya no sé por dónde buscar... :(

Gracias por tu ayuda!

[Casimiro Notevi]

Las pruebas que has hecho antes, ¿cómo han sido?, ¿en local, en red, desde el programa, desde isql?

[mcs]

Las pruebas que hecho antes son:
- En red (wifi)
- Usando el programa, más el "espía" dbMonitor (simplemente guarda las secuencias SQL que se mandan al Firebird)
- Al servidor Linux

[Casimiro Notevi]

Esas pruebas no se pueden considerar concluyentes en ningún caso.

Usar wifi no es válido, (es algo muy "oscilante").
Si tienes un programa espía, tampoco es válido, (estás poniendo otra capa intermedia).

Debes hacer pruebas reales. Una red cableada normal, nada de espías. Abres isql, ibexpert, flamerobin, etc. y ejecutas una sentencia. Punto. Si va bien entonces es que va bien, no hay más. Si va mal mal entonces es cuando hay que buscar culpables.