none
Cómo optimizar un Insert en un Data Flow Task? RRS feed

  • Pregunta

  • Buenas, 

    Mi consulta surge porque al insertar datos en una tabla con sentencias SQL en una Execute SQL Task tarda unos segundos, y la misma operación desarrollada en un Data Flow Task tarda horas. Hay propiedades de OLE DB Source Task u OLE DB Destination Task que podría considerar para optimizar esta operación?

    Saludos.


    lunes, 29 de abril de 2013 13:56

Respuestas

  • Hola.

    En grandes volúmenes de datos (a partir de decenas de miles de registros), usar procedimientos de bulk insert como los que se emplean en SSIS es mucho mejor para el rendimiento, y más si tenemos en cuenta que no vaya todo en una única transacción. Si estamos hablando de llevar datos de un servidor a otro, la diferencia es mucho mayor, ya que las sentencias por servidor vinculado o sentencias remotas en general tienen un rendimiento bastante inferior.

    Ahora bien, SSIS aporta otra serie de ventajas, como la posibilidad de manipular los datos en tiempo de ejecución (cosas como dividir un flujo o hacer un lookup), por no entrar a valorar otras cuestiones como derivar los registros no válidos para un tratamiento posterior, la posibilidad de almacenar la información en memoria para tratarla en repeticiones sucesivas, el control del flujo, etc. Ese tipo de cosas, en una tarea SQL Task, o lo que es lo mismo, con T-SQL, no es algo especialmente eficaz.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    viernes, 3 de mayo de 2013 17:45
    Moderador

Todas las respuestas

  • Hola.

    Habría que ver qué realiza ese proceso. Sobre cómo optimizar el Data Flow Task, hay muchas cuestiones a considerar. Si únicamente tienes un origen y un destino OLE DB, asegúrate de usar "Fast Load", de no generar bloqueos, de adecuar el tamaño de la caché, etc.

    Te sugiero revisar esta presentación de Salva Ramos sobre el tema:

    http://www.slideshare.net/sramosl/optimizando-la-carga-de-datos-con-integration-services-ssis


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    martes, 30 de abril de 2013 18:31
    Moderador
  • Hola, aprovecho el hilo para comentar una duda que tengo.

    Tiene ventaja hacer las transformaciones mediante SSIS o mejor mediante SQL Task?

    ¿En principio mediante SQL el rendimiento es mejor no? Pues se trabaja con conjuntos de datos.

    Sobre todo si el servidor de SSIS y el servidor de Datos no están en la misma máquina.

    Gracias de antemano y un abrazo.

    Héctor.

    martes, 30 de abril de 2013 22:55
  • Hola.

    En grandes volúmenes de datos (a partir de decenas de miles de registros), usar procedimientos de bulk insert como los que se emplean en SSIS es mucho mejor para el rendimiento, y más si tenemos en cuenta que no vaya todo en una única transacción. Si estamos hablando de llevar datos de un servidor a otro, la diferencia es mucho mayor, ya que las sentencias por servidor vinculado o sentencias remotas en general tienen un rendimiento bastante inferior.

    Ahora bien, SSIS aporta otra serie de ventajas, como la posibilidad de manipular los datos en tiempo de ejecución (cosas como dividir un flujo o hacer un lookup), por no entrar a valorar otras cuestiones como derivar los registros no válidos para un tratamiento posterior, la posibilidad de almacenar la información en memoria para tratarla en repeticiones sucesivas, el control del flujo, etc. Ese tipo de cosas, en una tarea SQL Task, o lo que es lo mismo, con T-SQL, no es algo especialmente eficaz.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    viernes, 3 de mayo de 2013 17:45
    Moderador
  • Concuerdo con qwal. Hay que ser muy astuto para usar el componente correcto.


    MVP MCT MCTS Daniel Calbimonte

    http://elpaladintecnologico.blogspot.com

    miércoles, 8 de mayo de 2013 3:11