En esta respuesta, intentaré proporcionar información de la documentación oficial de SSIS y mencionaré mi experiencia personal con el destino de SQL Server.
1. Destino del servidor SQL
Según la documentación oficial de SQL Server Destination:
El destino de SQL Server se conecta a una base de datos local de SQL Server y carga datos de forma masiva en tablas y vistas de SQL Server. No puede usar el destino de SQL Server en paquetes que acceden a una base de datos de SQL Server en un servidor remoto. En su lugar, los paquetes deben usar el destino OLE DB.
El destino de SQL Server ofrece la misma inserción de datos de alta velocidad en SQL Server que proporciona la tarea de inserción masiva; sin embargo, al usar el destino de SQL Server, un paquete puede aplicar transformaciones a los datos de la columna antes de que los datos se carguen en SQL Server.
Para cargar datos en SQL Server, debe considerar usar el destino de SQL Server en lugar del destino OLE DB
2. Destino OLEDB
Según la documentación oficial de destino de OLEDB:
Destino OLEDB:opción de carga rápida:cargue datos en una tabla o vista en el destino OLE DB y use la opción de carga rápida, que está optimizada para inserciones masivas
3. Destino OLEDB vs Destino SQL Server
De acuerdo con SQL Server Destination Vs OLE DB Destination - MSDN topic:
Donald Farmer, ex Gerente de Programas de Grupo para Servicios de Integración, dijo que puede obtener un aumento del 5 al 10 % en el rendimiento usando el SQL Server Destination .
Además, haciendo referencia a la siguiente publicación de Matt Masson, especialista en integración de datos de Microsoft, donde respondió la siguiente pregunta:
¿Debo usar el destino de SQL Server?
La respuesta fue
No
...
Mi recomendación es que si necesita todo el rendimiento (un aumento del rendimiento del 10 % en una carga de 10 horas puede ser significativo), pruebe SQL Server Destination para ver cómo funciona para usted. Sin embargo, tenga en cuenta las siguientes limitaciones del destino de SQL Server:
- Debe tener SSIS ejecutándose en la misma máquina que la base de datos de destino
- Debe ejecutar el paquete como administrador
- Es muy difícil depurar cuando las cosas van mal
Dadas estas limitaciones, recomiendo usar el destino OLE DB incluso si ve un aumento en el rendimiento con SQL Server Destination.
3.1. La guía de rendimiento de carga de datos
(Actualización @ 2019-03-25)
Mientras buscaba las mejores prácticas de SSIS, encontré un artículo de Microsoft muy útil que se puede usar como referencia:
- La guía de rendimiento de carga de datos
En este artículo hicieron una comparación entre todos los métodos de carga de datos, incluido el destino de SQL Server y el destino de OLEDB, mencionaron que:
Destino del servidor SQL El destino de SQL Server es la forma más rápida de cargar datos de forma masiva desde un flujo de datos de Integration Services a SQL Server. Este destino admite todas las opciones de carga masiva de SQL Server, excepto ROWS_PER_BATCH.
Tenga en cuenta que este destino requiere conexiones de memoria compartida a SQL Server. Esto significa que solo se puede usar cuando Integration Services se ejecuta en la misma computadora física que SQL Server.
Destino OLE DB: El destino OLE DB admite todas las opciones de carga masiva para SQL Server. Sin embargo, para admitir la carga a granel solicitada, se requiere alguna configuración adicional. Para obtener más información, consulte "Datos de entrada ordenados". Para usar la API masiva, debe configurar este destino para "carga rápida".
El destino de OLE DB puede usar tanto TCP/IP como conexiones de canalizaciones con nombre a SQL Server. Esto significa que el destino de OLE DB, a diferencia del destino de SQL Server, se puede ejecutar en un equipo que no sea el destino de carga masiva. Debido a que los paquetes de Integration Services que utilizan el destino OLE DB no necesitan ejecutarse en la propia computadora de SQL Server, puede escalar horizontalmente el flujo de ETL con servidores de caballo de batalla.
3.2. Experiencia personal
(Actualización @ 2019-03-25)
Dado que muchos usan esta pregunta como referencia, y después de tener más experiencia en este dominio, agregué esta sección para mencionar mi experiencia personal con el destino de SQL Server.
Si bien la documentación oficial menciona que el destino de SQL Server aumentará el rendimiento, no recomiendo en absoluto usar estos componentes debido a muchas razones:
- Requiere que el servidor de destino y el servidor ETL sean los mismos (funciona solo con el servidor SQL local)
- Siempre arroja una excepción que no tiene ningún significado
- Después de probar en un gran volumen de datos, la diferencia de rendimiento con el destino OLEDB es insignificante (probado en aproximadamente 500 GB de datos cargados en fragmentos y la diferencia de tiempo es inferior a un minuto)
También puede consultar la siguiente publicación (de @billinkc) para obtener más información sobre este tema:
- ¿Deberían estar los paquetes SSIS y la base de datos SQL en el mismo servidor?
4. Conclusión
Según los artículos de Microsoft, puede decir que SQL Server Destination aumentar el rendimiento de la inserción de datos (utiliza BULK insert) , pero está diseñado para un caso específico que es el servidor SQL local. OLEDB Destination es más general y recomendado en los otros casos y usando el Fast Load modo de acceso a datos (que también usa inserción BULK) en el OLE DB destination aumentará el rendimiento de la carga de datos.
Por otro lado, según mi experiencia y de muchos artículos escritos por expertos en SSIS, no se recomienda en absoluto usar SQL Server Destination ya que no es estable y a menudo arroja excepciones y el rendimiento puede considerarse insignificante.
Información adicional
Recientemente, publiqué un artículo detallado sobre este tema. Puedes consultarlo en:
- Destino OLE DB de SSIS frente a destino de SQL Server
