Acelerar inserciones masivas en Firebird

[RaulChemical]

Buenas!
Os cuento el problema que tengo:

Necesitamos acelerar la inserción en tablas en Firebird (2.1).
Usamos los componentes FIBPlus (6.9).

Al realizar el proceso de inserción masiva, usamos un TpFIBScripter en el que añadimos las inserts y una vez relleno, ejecutamos el script. Al lanzarlo, el FBServer se come prácticamente el 100% de la máquina (windows) y tarda en torno a 20 segundos en insertar 10.000 líneas. Este proceso está dentro de un bucle y se ejecuta este proceso entre 10 y 15 veces (en total 100mil o 150mil registros).
20 seg cada inserción masiva x 10 = 200 seg (más de 3 min).

Necesitamos acelerar este proceso.

Hemos probado a cambiar el tamaño del caché. Por defecto trae el valor DefaultDbCachePages = 2048 (8Mb). Cambiándolo a 20480 (80Mb) y no hemos conseguido cambios. Cambiándolo a 204800 (800Mb) suelta un error del tamaño de lectura del caché.

Sabéis si existe algún otro truco para hacer este proceso más rápido?

Muchas gracias por todo.

[RolphyReyes]

Saludos.

Se me ocurre que puedes desactivar los indices si existen, verificar los triggers que se disparan y ver si se pueden desactivar también.

En cuanto al tamaño PageSize tienes: 1024, 2048, 4096, 8192 y 16384.

No entiendo el porque utilizar el componente TpFIBScripter, si el componente TpFIBDataSet puede realizar el Insert perfectamente.

Tanto el TpFIBDataSet como el TpFIBQuery tiene los siguientes métodos de Batch:
function BatchInput(InputObject: TFIBBatchInputStream) :boolean;
function BatchOutput(OutputObject: TFIBBatchOutputStream):boolean;
procedure BatchInputRawFile(const FileName:string);
procedure BatchOutputRawFile(const FileName:string;Version:integer=1);
procedure BatchToQuery(ToQuery:TFIBQuery; Mappings:TStrings);

Otra cosa que se me ocurre es que podrías hacer Soft Commit cada x cantidad de registro.

Espero haberte ayudado, hasta luego.

[RaulChemical]

Lo que hago es hacer commit cada 10.000 registros.
Relleno un script, lo lanzo al llegar a 10.000, lo limpio y sigo rellenando.

"Soft Commit"?


Voy a probar cambiando el caché a 16384.

Muchas gracias.

[RolphyReyes]

Saludos.

Soft Commit = CommitRetaining.

Realmente sigo sin entender el porque utilizar TpFIBScripter para rellenar y borrar y luego rellenar.....

El TpFIBScripter vendría siendo como la opción Script Execute de IbExpert donde pones el Script del tamaño que sea con las sentencias que sean (DML y DDL) y lo ejecutas de un golpe.

La misma opción tiene la opción, valga la redundancia, de que pones el COMMIT cada x cantidad de registro.

Si pudieras ser más especifico en cuanto a lo que quieres lograr sería un poco más facil para ayudarte.

Hasta luego.

[RaulChemical]

Lo que hace el programa es pasar los datos de una base de datos de un servidor a una base de datos firebird en local (desconozco la razón por la cual se decidió hacer esto).

Sincronizo los datos tabla a tabla.

Una de las tablas es la que me da estos problemas ya que tiene 150.000 registros, el resto no suele tener más de 2.000.

Por cada registro genero una insert que añado en el TpFibScripter.
Cuando he generado 10.000 inserts, ejecuto el script (TpFibScripter.ExecuteScript), lo limpio (TpFibScripter.Clear) y continuo generando inserts hasta EOF de la query del servidor.

Es la ejecución de esos scripts de 10.000 líneas las que tardan 20 segundos cada una.

Espero que con esto, me puedas ayudar.

Muchas gracias.

[RolphyReyes]

Saludos.

Ya entiendo la idea, lo que estas haciendo es un "replicador" de datos.

Se me ocurre dos cosas:

1.- Utilizar los métodos que te había mencionado Batchxxx.
2.- Si es una copia tal cual de como esta la BD del Servidor, entonces sería mejor si haces un Backup de la BD y luego un Restore en la PC local.

Otra cosa podría ser que consigas un programa como IBReplicator (http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1232460386:1419563&page=ibp_replicator) o similares, que ya están hechos y probados.

[RaulChemical]

El problema es que la base de datos del servidor no es Firebird, es MySQL.

Mi replicador lo que hace es pasar los datos de un lado al otro haciendo insert's.

Voy a probar lo de los Batchxxx.

Muchas gracias.

[jhonny]

Pregunto por curiosidad, ¿De que manera generas las sentencias "inserts" que traes de la base de datos "origen"?, o mejor... ¿Cual es el mecanismo que usas para ello?

[RaulChemical]

Tengo un xml donde tengo las tablas a sincronizar, los campos de cada tabla, con su nombre en firebird y su nombre en mysql y el tipo de dato (varchar, integer, timestamp).

Recorro mi lista de tablas. Por cada tabla hago una select de los campos que tiene en el xml y genero la insert con los campos que me trae el xml.

[jhonny]

Otra solución es que tal vez, te enfoques en optimizar el momento en que creas las sentencias Inserts. Seguramente optimizando la manera como creas estas sentencias (Inserts), podrias mejorar un poco o mucho el tiempo de respuesta total.

Por ejemplo, si haces una especie de concatenación con la función CONCAT de MYSQL para que traiga los Inserts ya "parseados" desde el principio y no tengas que recorrer el XML para generar los Inserts. Tal vez esto te ahorre algo o mucho de tiempo.

[RaulChemical]

Pues si, la verdad es que tienes razón. Podría quitar algo de tiempo al generar las inserts, pero de todas formas, el cuello de botella lo sigo teniendo al insertar en Firebird.

Lo tendré en cuenta.

Muchas gracias.

[jhonny]

Pues si, la verdad es que tienes razón. Podría quitar algo de tiempo al generar las inserts, pero de todas formas, el cuello de botella lo sigo teniendo al insertar en Firebird.

Lo tendré en cuenta.

Muchas gracias.

Bueno, es que es de esperar que al tener cada vez mas registro, mas se van a demorar en insertarse, eso sucedería en cualquier motor y así encuentres la manera de optimizar esta inserción (por ahora) mas adelante volverás a tener el mismo problema.

Lo otro que te sugiero es que filtres y traigas únicamente los registros que han tenido modificaciones o los que son nuevos (Desde la ultima actualización), mas no todos, pues como bien dices se te va creando un "Cuello de botella" bastante estrecho.

[Chris]

Estuve leyendo casualmente ayer documentación relacionada a los componentes UIB (Unified Interbase). Parece que para tu tarea son los mas adecuados. Además ellos recomiendan hacer un commit cada 1,000 registros, además utilizar queries con parámetros.

Puedes tomar en cuenta esos detalles, a lo mejor logras una mejoría apreciable.

Saludos.

[Kipow]

Podrias utilizar algun metodo de replicacion, que se yo en lugar de insertar los 150k registros de un solo podrias hacerlo cada 1000.