Muy lento al insertar registro >100.000

[pjjorda]

Saludos, utilizo Delphi7 con fb1.5
con un ibdataset hago un append, relleno los valores de los campos y después un post, y un commitretainning de la transacción.

cuando la tabla tiene pocos registros funciona rápido,
pero en tablas con mas de 100.000 regs. va lentísimo,
seguramente será algo sencillo, pero no lo veo.

No se que mas información dar...

Agradecería la ayuda del foro

windows xp, pIV a 1.5GHz, 640MbRam.

[Neftali [Germán.Estévez]]

¿Porqué utilizas CommitRetainning el lugar de Commit?
Piensa que esta instrucción es menos eficiente, aunque no dices si llevas "mucho rato" haciendo CommitRetaining cuando "va lento".

[pjjorda]

Gracias Neftali por tu pronta respuesta,

ocurre igual con commit que commitretainning, se trata por ejemplo de una entrada de registros por pantalla, al primer registro que entro, ya va lento.
Un saludo

[pjjorda]

Saludos,
he estado parando el programa antes y después de las instrucciones con el ibdataset y la lentitud está en el Post (no tiene eventos afterpost ni beforepost),
el append y el commit van como las balas. Gracias

[Casimiro Notevi]

¿Puedes dejarnos el script de creación de la tabla para que hagamos pruebas?, ¿puedes poner el código delphi de cómo lo haces?, así será más facil que se te pueda ayudar

[pjjorda]

Gracias por anticipado, aqui teneis:
hago APPEND
asigno los valores de T, TIP, NUM igualando de otras variables
el resto de los campos vienen de DBEDITs
hago POST (aquí es donde va lento) tiene 125.000 regs

/**** Generated by IBExpert 13/07/2005 20:33:56 ****/
SET SQL DIALECT 3;
SET NAMES NONE;
CREATE TABLE ALMACEN (
T SMALLINT,
TIP VARCHAR(1),
NUM INTEGER,
FEC DATE,
HOR TIME,
ART VARCHAR(11),
DES VARCHAR(50),
CLI INTEGER,
CAN NUMERIC(5,2),
CANB NUMERIC(5,2),
PRE NUMERIC(5,3),
ALB INTEGER,
AUT INTEGER
);
/**** Indices ****/
CREATE UNIQUE INDEX ALMACEN_IDX1 ON ALMACEN (T, TIP, NUM);

[jachguate]

Es probable que la tabla tenga triggers que sean los que relentizan el sistema. Para comprobarlo, desactivá los triggers asociados y cronometrá nuevamente.

Es probable también que haya una relación que no esté soportada con un índice. Interbase/Firebird crea automáticamente los índices necesarios cuando declaras un foreign key, pero recuerdo que es posible borrar estos, lo que obliga al sistema a hacer un full scan de la tabla cada vez que se comprueba la integridad.

Hasta luego.

[pjjorda]

Gracias de nuevo,
no hay triggers, ni eventos after before ni nada que no haya expuesto, es esa tabla asi de sencilla,
con Ibexpert me crea los registros de inmediato, pero desde delphi tarda 9 seg.,
he probado con Fibplus y lo mismo.
Pienso que la database está bien configurada, porque ibexpert trabaja bien,
creo que el delphi será el culpable, no se...
Gracias por vuestro interés.
Un saludo

[jachguate]

Bien!

Al menos se ha despejado la duda del motor... ahora, yo creo que hay algo errático en la forma en que vos estas enviando la actualización... o en la forma que lo implementa tu capa de acceso a datos.

Podes comprobarlo con el propio IBExpert, que hasta donde yo recuerdo, está hecho en delphi, y donde vos mismo asegurás que va bien.

Hasta luego.

[tulio]

Hola PJJOrdan

Te cuento que me pasaba lo mismo, despues que la tabla llegaba a unos 50000 registro cuando hacia un append (metodologia usada en las tablas plana ) se me volvia una tortuga.
La solucion fue hacer todas las altas y modificaciones con Store Procedure, de esta forma se te acaban los problemas, por mas que la tabla tenga 500000 registro , el tiempo de insercion no varia

saludos

tulio

[pjjorda]

Gracias Tulio, muy amable tu respuesta,
he creado un stroredproc, le paso los parametros, executo y lo mismo, 9 seg. el primer reg.
, sin salirme del programa y haciendo commitretainning creo otros y ya rapidísimo, igual que con el insert del ibdataset. (si hago commit vuelve a tardar los 9seg.).

Yo no quiero haceros perder mas tiempo con el tema, será algo particular mio, de mi instalación, bueno ya veré..

Gracias de todos modos.

[rastafarey]

Una cosa no tiene que ver con la otra.

Si haces un asimple insercion A firebird no le importa cuanto s registros tengas. y si dice que desde ibexpert te funciona perfecto.
Entonces verifica qeu no estes haciendo un refresh o algo por el estiloluego del insert que quisas el insert no e slo que te esta poniendo l acosa lenta si no otro codigo fastidioso.

Peropor que dame codigo y asi es mas facio ayudar.

[pjjorda]

Saludos, contestando a Rastafarey
como ya dije:
"Gracias por anticipado, aqui teneis:
hago APPEND
asigno los valores de T, TIP, NUM igualando de otras variables
el resto de los campos vienen de DBEDITs
hago POST (aquí es donde va lento) tiene 125.000 regs"

y también:
"no hay triggers, ni eventos after before ni nada que no haya expuesto, es esa tabla asi de sencilla,
con Ibexpert me crea los registros de inmediato, pero desde delphi tarda 9 seg.,
he probado con Fibplus y lo mismo.
Pienso que la database está bien configurada, porque ibexpert trabaja bien,
creo que el delphi será el culpable, no se..."

Supongo que tendrá algo que ver la cantidad de registros puesto que en otras tablas con mas campos similares de 200, 1000, 3000regs. funciona perfectamente, y en esta de 125000 tarda 9segs., y en otra que tengo con 260000 también lento,
si os preguntáis como han llegado a tener tantos registros, he convertido ficheros y aplicaciones de cobol-85 a firebird con delphi7.

Gracias de nuevo a todos.

[Rufus]

Una curiosidad, ¿como es que tienes que insertar de golpe 125.000 registros?. ¿Eso es al pasar de cobol a firebird?.

Por otra parte dices que se trata de una inserción de registros por pantalla, ¿vas a meter uno a uno por pantalla 125.000 registros? Supongo que es una prueba que estas haciendo.

Por cierto, hace como un año hice unas pruebas para ver lo rápido que iba firebird para ver si me quedaba definitivamente con este SGDB. Lo hice de dos maneras, mediante un script para isql y mediante Delphi con fibplus. Para la prueba de insertar 100.000 registros tardó mas o menos 35 segundos (en insertar los 100.000). Puedes configurar cada cuantos registros se hace un commit automático.

Las causas pueden ser varias. Sólo tienes un índice creado, quizá no sea suficiente. Tabien puede tener que ver la forma de crear los identificadores únicos. O una mala conjunción planetaria¿?... . No, en serio, sigue posteando, queremos ver si se te soluciona el problema, firebird tiene que ir volando, da igual que sean 100.000 o 1 millón de registros.

[pjjorda]

Se bienvenido Rufus, agradezco tu interés,
no me he explicado correctamente, he traducido una aplicación hecha en rm-cobol85 a delphi7, los ficheros cobol los he convertido a una base de datos Firebird, el diseño de la tabla ejemplo es la de arriba, que ya tenía 125000 regs, y que con el programa nuevo en Delphi irá aumentando mediante un formulario.
Espero que ahora si esté claro, puse showmessages antes y después de cada instruccion Delphi,
y la que tarda en correr es la de IBDATASET1.POST, espero no resultar cansino,
me acabo de descargar e instalar el IBX 7.09, y ahora no puedo compilar, me sale un error diciendo que no encuentra IBDATABASE.PAS,
así que una cosa detrás de la otra y paciencia.

Recibid un agradecido saludo.

[pjjorda]

Saludos al foro, este mensaje es para dar la solución a mi problema,
el arbol no deja ver el bosque
como ya dije:
hago APPEND
asigno los valores de T, TIP, NUM igualando de otras variables
el resto de los campos vienen de DBEDITs
hago POST (aquí es donde va lento) .....
bien la solución ha sido:
antes de pedir datos para el registro, estas dos líneas
ibdataset.selectsql.text:='SELECT * FROM IBDATASET WHERE T=0 AND TIP=''E'' AND NUM=380663';
ibdataset.open;
siendo los valores de T, TIP, NUM los que luego iba a asignar a la key en el insert.
debía posicionar primero....
el arbol no deja ver el bosque.
Gracias a todos por vuestro interés.

[jachguate]

Esta solución me hace pensar que el problema es un refresh (implicito o explicito) que está ocurriendo.

El tiempo simplemente se minimiza porque después de insertar el registro físicamente, solo hay un registro que traer de vuelta, gracias al nuevo where.

En todo caso, lo ideal es que ese refresh no se de. Te recomiendo revisar, ya que aseguras que no hay eventos, los valores establecidos a las propiedades, tanto de la transacción como del dataset... aunque jamás he visto este comportamiento.

Saludos.