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).

En el último proyecto de desarrollo en el que estoy involucrado me he encontrado con la necesidad de comprobar si las sentencias SQL generadas desde la aplicación llegaban correctamente al servidor de base de datos (SQL Server 2005 Express Edition) para su posterior ejecución.

En las versiones Express de SQL Server no se incluye la herramienta SQL Profiler, que nos permite analizar lo que está sucediendo en el servidor en distintos momentos. De esta manera podemos analizar, por ejemplo, las sentencias o procedimientos almacenados que se están ejecutando, el tiempo que tardan en ejecutarse o los usuarios que lanzan esos comandos, entre otros.

Para resolver este problema estuve buscando un poco y finalmente encontré una aplicación llamada Profiler for Microsoft SQL Server 2005/2008 Express Edition, que proporciona la misma funcionalidad que SQL Profiler, ¡y de forma totalmente gratuita! Además es un proyecto con el código fuente abierto, con lo que podemos modificar la aplicación a nuestro gusto o necesidades, además de comprobar como está hecha.

Según mi punto de vista, una aplicación muy útil y recomendable si no disponemos de SQL Profiler.

¡Espero que os sirva!

PD: En otro post os explicaré las utilidades de SQL Profiler y como sacar el máximo de esta herramienta, no tan conocida por los programadores como lo debería ser.

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!

Recientemente estuve realizando algunas tareas de optimización de una base de datos SQL Server en un cliente. Una de las problemáticas que se detectaron fue la fragmentación de índices, hecho que penalizaba en el rendimiento de las consultas. Para solventar este problema tuvimos que recurrir a la desfragmentación de los índices, ya sea recreándolos o bien reorganizándolos.

Una explicación fenomenal sobre la fragmentación de índices, y qué es mejor para resolver esta problemática (recrear o reorganizar) la podéis encontrar en el blog El Rincón del DBA, en el artículo Nos gustan las DMVs, gracias al cual aprendí a usar correctamente las DMV (Dynamic Management Views, o lo que es lo mismo, vistas que permiten obtener datos sobre nuestro sistema). De hecho, yo estaba habituado a resolver este tipo de situaciones mediante la sentencia DBCC SHOWCONTIG, pero pasará a ser obsoleta en próximas versiones de SQL Server, con lo que ya os podéis ir acostumbrando a usar las DMVs.
En el artículo mencionado también se presenta un script para detectar los índices mayormente fragmentados, e incluso la sentencia de T-SQL recomendada que debería ejecutarse para solventar esa fragmentación. En mi caso, adapté ese script (¡ muchas gracias por publicarlo, Enrique !) para recorrer únicamente los índices de una sola base de datos, y ejecutar la sentencia recomendada. Ese script lo incluí en un procedimiento almacenado, que acepta como parámetro el nombre de la base de datos a tratar, de forma que se puede programar su ejecución con cierta periodicidad.

El script para crear el procedimiento almacenado os lo podéis bajar de este vínculo: ADMIN_Mantenimiento_Indices.sql (3,32 kb)

Ya para acabar, comentaros que en nuestro caso dejamos los índices con un factor de relleno de un 90%, ya que en nuestra base de datos también se realizan con frecuencia operaciones de inserción y actualización (con un factor de relleno de un 100% rellenaríamos todas las páginas, con lo que optimizaríamos el espacio ocupado, pero penalizaríamos las operaciones de inserción y/o actualización, aparte de generar nuevas fragmentaciones rápidamente).

¡Espero que les sirva!