El blog de Ferran Chopo

Esta es la frase que me pasó por la cabeza despúes de estar trabajando unas cuántas horas en un proyecto de migración de los antiguos DTS (Data Transformation Services) de SQL Server 2000, a los nuevos paquetes de Integration Services de SQL Server 2008. La razón es muy simple… Los procesos de extracción, transformación y carga (también conocidos como procesos ETL) funcionan mucho más rápido en la primera plataforma que en la segunda.

¿Cómo puede ser que un producto realizado hace más de 9 años funcione mejor que un producto nuevo? ¡Pregunten a Microsoft! Ciertamente el diseño y la productividad en la creación de paquetes ha mejorado mucho respecto a la versión del 2000, con nuevas herramientas de desarrollo y depuración, que facilitan enormemente estas tareas. ¿Pero qué pasa con el rendimiento de los paquetes?

En el caso concreto que nos ocupó, los paquetes extraían datos de Oracle y de un DB2 (sobre un AS400), sobre los que se aplican algunas transformaciones y cálculos agregados, y que finalmente se guardan en una base de datos en SQL Server 2008. El proceso de extracción de datos del DB2 (6M de registros) pasó de 3 minutos a 1 hora. No comment…

Investigando un poco, descubrí que este es un problema conocido del producto, y que ya existen productos de terceros que mejoran el rendimiento en cuanto a la conectividad y extracción de datos de otras plataformas. Algunos productos que podemos destacar son:

• Microsoft Connectors for Oracle and Teradata by Attunity: Producto muy interesante, y ¡gratuito! Aumenta significativamente el rendimiento respecto a los conectores que vienen por defecto en SQL Server 2008.

• DataDirect Connect64 for SSIS: Un poco complicado para configurar, pero puede ser muy útil si tenéis plataformas de 64 bits. Desconozco el precio.

• SSIS Oracle Bulk Load Connectors: Una opción interesante (mirad las comparativas de rendimiento) si trabajáis con Oracle. Tampoco se informa del precio en la web.

Para finalizar este post, solo comentaros que mi compañero José Antonio encontró una solución salomónica para mejorar el rendimiento del paquete que se conectaba a DB2. Consistió en crear un fichero Access, vincular las tablas del DB2, y crear las consultas necesarias sobre ellas. Posteriormente, creamos un paquete que se conecta al fichero Access, y usa las consultas creadas para seleccionar los datos que se desean importar. ¿Increíble, verdad? De esta manera el paquete es más rápido que extrayendo los datos directamente del DB2.

Pasan los años, aparecen nuevos productos, y resulta que los antiguos tienen mejor rendimiento que los nuevos. De nuevo, no me lo puedo creer…

¡Alguien tiene experiencias similares? ¡No dudéis en compartirlas!

¡Espero que os sirva!

PD: Me dejé de incluir un vínculo al artículo How to Choose the Best Connectors for SSIS, donde se explica de forma clara y concisa qué criterios debemos seguir para elegir el mejor conector para Integration Services (se encuentra en la web sqlservercentral.com, que requiere registro, pero totalmente gratuito).

Hace unos días estuve realizando una formación sobre SQL Server 2005 Integration Services, o lo que es lo mismo, la nueva herramienta de desarrollo de los antiguos DTS (Data Transformation Services) de SQL Server 2000. Mediante esta herramienta se pueden crear de forma fàcil y rápida soluciones de transformación de datos, que pueden llegar una complejidad importante, pero que pueden ayudar, y mucho, a la automatización de tareas de mantenimiento de datos (no deja de ser una herramienta ETL: Extract, Transform, Load). Mediante Visual Studio 2005 o 2008 es posible desarrollar una solución de Integration Services, para después probarla antes de subirla a un entorno de producción. Cuando la solución es correcta, se puede programar para que se ejecute con cierta periodicidad, o bien se puede ejecutar manualmente.

El objetivo de este post no es más presentar una posible solución para ejecutar una paquete de Integration Services desde una aplicación .NET (Windows), de forma que la ejecución del paquete se puede llevar a cabo desde una aplicación externa (y no desde el propio SQL Server). Los pasos a seguir serían los siguientes:

1) Añadir una referencia a la librería Microsoft.SqlServer.ManagedDTS:

2) Añadir el siguiente bloque de código (Visual Basic .NET) en cualquier evento (el click de un botón, por ejemplo):

   1: Dim appDTS As New Microsoft.SqlServer.Dts.Runtime.Application

   2: Dim paquete As Microsoft.SqlServer.Dts.Runtime.Package

   3: Dim resultado As Microsoft.SqlServer.Dts.Runtime.DTSExecResult

   4: paquete = appDTS.LoadFromSqlServer("AgregadoVentas", "ferran-2a90840e", String.Empty, String.Empty, Nothing)

   5: resultado = paquete.Execute()MessageBox.Show(resultado.ToString)

En este caso, llamamos a un paquete llamado AgregadoVentas, que se encuentra almacenado en el servidor de SQL Server ferran-2a90840. De esta forma tan simple podremos llamar a cualquier paquete almacenado, provocando su ejecución de forma instantánea. Finalmente, se mostrará por pantalla el resultado de la ejecución del paquete.

Así mismo, cabe indicar que en este caso estamos cargando un paquete almacenado en el servidor de SQL Server, y por este motivo utilizamos el método LoadFromSqlServer, perteneciente a la clase Dts.Runtime.Application. Si quisiéramos cargar un paquete almacenado en el sistema de ficheros, deberíamos utilizar el método LoadPackage.

¡Espero que os sirva!