¿Qué es y para que sirve el Log de Transacciones?

 

El día de hoy voy a hablar un poco del Log de Transacciones, para explicar su propósito y los posibles usos de esta clase de archivos.

Hace poco tiempo entré en un proyecto de migración de un DWH de SQL Server 2005 a SQL Server 2008 R2 Enterprise Edition.

El propósito de dicha migración era mejorar el tiempo de respuesta de los procesos, entonces se comprimieron las tablas mas grandes, con una ganancia de 3 a 1 en espacio (hablaré más de compresión de datos en otra entrada).

Unos días después, aún con la ganancia en espacio que tuvimos con la compresión de datos, el log de transacciones creció más de 400 GB en uno de los discos del servidor con un proceso de modificación de una de las tablas de hechos y entonces alguien sugirió...

Se debería deshabilitar el log de transacciones para no consumir espacio…

La solución en realidad fue optimizar el proceso de modificación de la tabla ya que había algunas deficiencias en el diseño de la transacción, lo que propiciaba una utilización deficiente del espacio el log… por que NO SE PUEDE DESHABILITAR EL LOG DE TRANSACCIONES!!!!!!

¿Que es una transacción para SQL Server? SE ESCUCHA ABURRIDO, PERO ESTO ES PARA LOS AMIGOS QUE AÚN NO CONOCEN MUCHO A SQL SERVER, como el amigo que sugirió.

Una transacción es una sentencia o un conjunto de sentencias T-SQL (T-SQL es la implementación del ANSI de SQL para MS SQL Server) que se ejecutan como una sola unidad y que le dan sentido lógico a los datos para convertirse en información.

Si la transacción falla, es decir, si alguna sentencia o alguna operación dentro de la sentencia falla, todas las sentencias que se hayan ejecutado en la transacción se deben deshacer para evitar que la información termine un estado inconsistente, a este proceso se le denomina ROLLBACK, también es posible hacer un ROLLBACK intencional de una transacción.

Si las operaciones se completan con éxito entonces se puede ya indicar a SQL Server que haga el compromiso de dejar fijas las modificaciones, lo que quiere decir que no importa lo que suceda, estas modificaciones ya existen en la base de datos. Este proceso se le llama COMMIT (compromiso).

El ejemplo clásico de una transacción es la del pago de tarjeta de crédito transfiriendo dinero desde la cuenta de debito, obviamente estas transacciones siempre deben completarse o deshacerse , a nadie le gusta que se metan con su dinero

BEGIN TRANSACTION DEBITO_CREDITO
  Reduce en la cuenta de debito $1000
  Abona en la cuenta de crédito $1000
COMMIT TRANSACTION DEBITO_CREDITO

NOTA 1.

En una transacción fallida o deshecha intencionalmente, por lógica, solo se desharán las sentencias que modificaron información.

NOTA 2.

En SQL Server toda sentencia de modificación esta dentro de una transacción implícita (INSERT, UPDATE, DELETE), es decir, si algo falla antes de terminar dicha sentencia se hará un ROLLBACK automático, y si concluye con éxito se hará un COMMIT automático también.

Este comportamiento cambia cuando se define una transacción explicita compuesta con un BEGIN TRANSACTION… COMMIT/ROLLBACK TRANSACTION, donde se puede agrupar más de una sentencia de consulta y modificación de información.

NOTA 3.

El manejo implícito / explícito de transacciones se puede modificar a nivel de la conexión que se establece al SQL Server mediante SET IMPLICIT_TRANSACTIONS, así se pueden tener conexiones a SQL Server más parecidas a las de Oracle, que maneja transacciones explicitas (Oracle requiere el COMMIT para fijar los cambios), si quieres saber más de esta sentencia SET dale aquí

¿Que es EL LOG DE TRANSACCIONES de las bases de datos de SQL Server?.

Cada transacción, modifique datos o no, debe dejar una bitácora de cuando inició, que se hizo dentro de ella y si se completó exitosamente. Con esta información ya es posible deshacer los cambios generados por una transacción, ya sea por un fallo o una orden explicitar para deshacer la transacción.

La bitácora justamente se lleva en el archivo del Log de transacciones, por eso es un archivo crítico en una base de datos Y NO SE PUEDE DESHABILITAR.

Si se pudiera deshabilitar el log no habría manera de asegurar el ROLLBACK de una transacción, y seguro habría muchos DBA’s y desarrolladores en la calle por transacciones dejadas a medias… jejejeje

NOTA 1.

La cantidad de transacciones que una base de datos sea capaz de aceptar en un lapso de tiempo depende directamente de la velocidad de escritura en el log de transacciones, así como de los cuellos de botella que afecten esa velocidad de escritura.

¿PARA QUE PUEDE SERVIR EL LOG DE TRANSACCIONES de las bases de datos de SQL Server?.

USO 1. Bitácora y recuperación de una transacción, lo que ya explique.

USO 2. Es posible recuperar una base de datos después de un desastre, inclusive hasta la ultima transacción buena si se cuenta con el respaldo del último log en operación(conocido como TAIL LOG), esto puede ser la diferencia en muchas empresas que requieren 0 perdidas de datos.

USO 3. Es posible recuperar una base de datos a un punto en el tiempo, o hasta una “marca” particular, esto sirve por ejemplo en procesamiento nocturno de información, para deshacer los cambios hasta cierto horario o hasta una transacción particular y así poder arreglar lo que falló y reprocesar sin perder todas las modificaciones realizadas.

USO 4. Los logs son indispensables cuando se desea tener una copia fuera de línea de una base de datos en otro sitio con soluciones de alta disponibilidad (LOG SHIPPING, DATABASE MIRRORING)

No me viene a la mente otro uso de los logs por ahora, pero como ven, son vitales, entonces NO DESACTIVEN SUS LOGS (NI LO INTENTEN… NO PODRÍAN), Y BUSQUEN SACAR VENTAJA DE ELLOS.

Saludos del Vago…