Uno de los puntos de SSIS que muchas veces nos pasa desapercibido y que sin embargo conviene conocer, utilizar y amar, es el soporte para transacciones. Estamos cargando un DataMart, y ¡zas! la carga falla a mitad de camino. ¿Qué hacemos? ¿Parece mentira que la ejecución de un ETL que puede hacer infinidad de cambios en nuestro DataMart se pueda deshacer en caso de fallo, verdad? ¡Pues se puede!
Para controlar las transacciones, todos los objetos del «Control Flow» (incluido el propio control flow) tienen una propiedad llamada «TransactionOption», que puede tomar los siguientes valores:
- Required: Este elemento se ejecuta en el contexto de una nueva transacción.
- Supported: El elemento se ejecuta en el contexto de la transacción que ya estuviese abierta (por alguno de sus «padres»). En caso de que no se hubiese iniciado ninguna transacción, el objeto no es transaccional. Es el valor por defecto que da Integration Services a todos los elementos del flujo de control.
- NotSupported: El objeto no es transaccional, aunque esté ejecutándose en el contexto de una transacción
Entonces, hacer un ETL transaccional es tan sencillo como pulsar en el fondo del «Control Flow» de un paquete y establecer TransactionLevel a «Required». Eso hará que todos los elementos que arrastremos al flujo se ejecuten por defecto en el contexto de una transacción. Si uno de estos elementos falla, se desharán los cambios realizados por el resto de elementos que se hubiesen ejecutado dentro de la misma transacción.
El segundo parámetro a tener en cuenta es IsolationLevel, que especifica cómo gestionará SSIS la transacción. Podéis buscar información en MSDN sobre este parámetro… yo sólo os dejo caer un par de notas:
- Cuanto menos restrictivo sea el modo de funcionamiento de la transacción, mayor será el rendimiento. Por ejemplo, ReadUncommited y Chaos permiten ver los cambios antes de que estos se hagan permanentes con un Commit. O sea, que si estamos cargando un DataMart y mientras tanto alguien accede al mismo, obtendrá datos inconsistentes. Si nuestras circunstancias permiten «evitar» el acceso al DataMart mientras esté siendo cargado, puede ser una buena opción.
- Serializable es el más restrictivo, pero a la vez más seguro: evita que se pueda acceder a los datos nuevos que insertemos en el DataMart hasta que se haga un Commit, y evita que se modifiquen los datos anteriores al inicio de la transacción. Generalmente es el más adecuado para cargar un DataMart (es la opción por defecto).
- Snapshot es nuevo en SQL Server 2005, y permite trabajar a la transacción sobre una «copia» de los datos tal y como estaban al inicio de la transacción, sin bloquearlos. Al finalizar la transacción, se consolidan los cambios. Esta es la que menos impacto supondrá en el resto de aplicaciones que accedan al DataMart mientras lo estamos cargando, pero a costa de usar parte de nuestro espacio de almacenamiento. Personalmente no le veo demasiado uso en la carga de un DataMart, porque por su propia naturaleza, los datos del DataMart no suelen sufrir modificaciones (por lo que Serializable puede ser una mejor opción)
Espero que después de esto en vuestras oficinas dejen de oirse gritos y lamentos debido a ese corte de luz que sucede siempre justo en medio de la ejecución de un ETL…
Y ya sabés, feliz navidad…. ¡y prósperas transformaciones!