none
Que es mas Rápido? Origen ADO NET / Origen OLE DB RRS feed

  • Pregunta

  • Hola amigos; 

    Les cuento que tengo un flujo de datos en SSIS 2008, y debo implementar muchos procesos de flujo de datos entonces quería saber a su parecer cuál método es más rápido.

    Mi caso es que estoy transfiriendo tablas entre servidores SQL Server y al medio pongo un Lookup o Búsqueda para filtrar los campos que ya existen en la tabla y traer solo los nuevos, los flujos se ejecutarán a diario, entonces me gustaría saber si es mas rápido ADO NET u OLEDB.

    Gracias.

    jueves, 11 de diciembre de 2014 14:14

Respuestas

Todas las respuestas

  • Lo más probable es que no notes la diferencia. Lo que se lleva la mayor parte del procesamiento en un paquete SSIS es cualquier cosa menos si accedes por ADO.NET u OLEDB.


    Jesús López


    EntityLite a lightweight, database first, micro orm

    jueves, 11 de diciembre de 2014 14:39
  • Personalmente he tenido mejores resultados con oledb, al ser sql server a sql server es posible que no haya mejor opción aun, me gusto mucho esta respuesta asi que te la comparto.

    https://social.msdn.microsoft.com/Forums/en-US/1a9e3670-9685-4943-913b-123ecf248a9c/ole-db-vs-adonet

    jueves, 11 de diciembre de 2014 15:15
  • Listo amigos, realicé pruebas y les cuento los resultados:

    Transferencia desde un archivo plano de texto (.txt) delimitado por punto y coma (;) (8.400.000 Registros), Peso 6,5 GB (92 Columnas de datos)

    Resultados ADO NET Destination : En 3:00 minutos -> 81.400 registros transferidos.

    Resultados Destino de OLE DB : En 3:00 minutos -> 913.000 registros transferidos.

    Osea podemos concluir que al menos OLE DB para transferencia de datos desde un archivo plano a una tabla SQL Server es increíblemente mas rápido que ADO NET.

    * Las pruebas las realicé por un periodo solo de 3 minutos

    * La transferencia es a una tabla en un servidor SQL Server 2008

    Saludos.

    ------------------------------------------------------------------------------------------------------------

    Les cuento que realicé nuevamente pruebas pero desde una consulta hacia una tabla en base de datos SQL Server 2008.

    Lo que hice fue transferir el resultado de una Query hacia una tabla, y entre medio puse con un lookup (búsqueda) para distinguir los campos que ya existen en la tabla de destino y no copiarlos.

    Los resultados son : 

    - ADO NET : 11.983 filas en 30 segundos.

    - OLE DB : 11.983 filas en 08 segundos.

    Y ya puedo concluir que para transferir grandes cantidades de datos es siempre mas factible utilizar origen y destino OLE DB.

    Saludos y gracias por sus consejos.

    • Editado Hormix0 miércoles, 7 de enero de 2015 18:23 Nuevos Resultados!
    miércoles, 7 de enero de 2015 15:02
  • En lectura no debería de haber mucha diferencia. Otra cosa es en la carga, que yo sepa el destino ADO.NET no implementa "Bulk load", mientras que OLEDB sí. ¿Has habilitado la carga masiva "Fast Load" en el destino OLEDB?.

    En ADO.NET existe la clase SqlBulkLoad, que es el equivalente al interfaz Fast Load de OLEDB, pero creo que SSIS no la usa para las cargas de datos.



    Jesús López


    EntityLite a lightweight, database first, micro orm

    miércoles, 7 de enero de 2015 18:29
  • Busqué, pero no hay ningún parámetro o indicio que ADO.NET ocupe SqlBulkLoad, por otra parte, OLE DB la utilizo con Fast Load.

    Saludos.

    martes, 13 de enero de 2015 20:48
  • ¡Ahí está la clave entonces!


    Jesús López


    EntityLite a lightweight, database first, micro orm

    martes, 13 de enero de 2015 20:53
  • Es una lástima o más bien una vergüenza que SSIS después de que .NET esté disponible desde hace 15 años,  que todavía no soporte SqlBulkCopy en destinos ADO.NET. No es la única cosa que se dejan sin implementar, en general hay mucha más funcionalidad con OLEDB que con ADO.NET. 

    Ahora que ya hace tiempo que Microsoft considera obsoleto OLEDB, no sé qué van a hacer con SSIS. ODBC es ahora el estándar, pero no hay buen soporte de ODBC en SSIS, y tampoco de ADO.NET. ¡Una vergüenza!

    Y ¿Qué pasa con los servidores vinculados? Están basados en OLEDB, pero no parece que en un futuro próximo podamos crear servidores vinculados por ODBC.



    Jesús López


    EntityLite a lightweight, database first, micro orm


    martes, 13 de enero de 2015 21:01