Actualizacion artículos: 100.000 líneas y rendimiento

"Gonzalo Rodríguez Carrera" escribió en el mensaje
news:3f5ccec7-7e48-4fac-ab27-

Hombre si es un proceso batch .. pues lo que te comenta Alberto tampoco vá a
ser gran problema. Ejecutalo a una hora en la que no haya uso de la base de
datos y punto.

Por detallar más, las operaciones de dicha tabla son por un lado
logico/matemáticas y por otro lectura de ficheros planos, asi que no
veo como usar un procedimiento almacenado.

Si eso vá a ser frecuente, pues yo tendría la infromación prepararia lo mas
preprocesada posible para que la actualización sea solo despues hacer un
append de datos.

Si puedes hacer lo que quieras de operaciones matematicas en un
procedimiento almacenado de SQL Server ... mirate los procedimientos
almacenados CLR (donde puedes escribir codigo en un lenguaje de .NET)


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

On 23 nov, 15:17, "Pablo Roca" wrote:

>"Gonzalo Rodríguez Carrera" escribió en el mensaje
>news:3f5ccec7-7e48-4fac-ab27-

Hombre si es un proceso batch .. pues lo que te comenta Alberto tampoco vá a
ser gran problema. Ejecutalo a una hora en la que no haya uso de la base de
datos y punto.

>Por detallar más, las operaciones de dicha tabla son por un lado
>logico/matemáticas y por otro lectura de ficheros planos, asi que no
>veo como usar un procedimiento almacenado.

Si eso vá a ser frecuente, pues yo tendría la infromación prepararia lo mas
preprocesada posible para que la actualización sea solo despues hacer un
append de datos.

Si puedes hacer lo que quieras de operaciones matematicas en un
procedimiento almacenado de SQL Server ... mirate los procedimientos
almacenados CLR (donde puedes escribir codigo en un lenguaje de .NET)


Saludos,

Pablo Roca
La Coruna - Spainhttp://www.portalfox.com

Bueno, por si a alguien todavía le interesa he conseguido dejar el
proceso en 13 minutos de media.

1. Al inicio cargo todos los elementos que vayan a intervenir en la
operacion a memoria, prácticamente todos serán datatables.
2. Cargo todos los productos que van a ser actualizados (solo los que
van a ser actualizados, ya que me reduce en un 30% aproximadamente el
número de registros) en un datatable "especial" (un objeto que usamos
en la empresa con muchos métodos y props y a mayores un datatable) y
por otro lado los datos de la actualización.
3. Hago un for recorriendo este segundo datatable y voy actualizando
el primero (en memoria) esto se hace en unos cuantos segundos (34"07
de media)
4. Descargo de memoria el segundo datatable y todos los datatables de
apoyo.
5. Lanzo un método de ese objeto datatable nuestro y creo "páginas" de
100 en 100 updates y se las mando una a una a SQLServer (unos 3 min de
actualización). Enviarselas en grupo a SQLServer da mejor resultado
que enviarselas una a una, pero ojito, no obtengo información de en
donde rompe en caso de que falle alguna (asi que testea los datos
previamente).

6. Finalmente repito el proceso para las inserciones nuevas, 30% de
los articulos aprox.

Despues, eso sí hubo mucho trabajo de depuración de código (fue una
tarea ardua pero muy reconfortante). Aprovechar ciclos que
aparentemente no podrias, cargar y descargar la memoria segun se
necesite, no tener cosas "demás", tener cuidado en las querys e
intentar traer e-xac-ta-men-te lo que se necesita, etc...

Me resulto muy interesante.

Como punto y final. Millones de gracias a todos los que me habéis oido
y echado un cable.
Gracias.