Esos $##@@&%$ Transaction Logs!!!

A quien no le ha tocado alguna vez que se haya llenado el disco por que los Transaction logs han crecido y crecido?? Tanto en SQL Server como Exchange.

Hoy me toco ver una base de datos SQL Server de solo 600Mb con un Transaction log de 54GB, no es primera vez que me toca ver algo así, había visto Tlogs de 30GB para bases de 2GB y había apagado mas de un incendio por disco lleno debido a esto mismo, es un tema que siempre se esta repitiendo y no muchos administradores entienden por que esta pasando.

 

Por que crece el Tlog?

Cuando una aplicación o una sesión en SQL Server envía una transacción a la base de datos, el motor lee los datos, los carga en memoria (Buffer Cache) y son modificados, esta modificación es registrada en el TLog en disco, cuando el Checkpoint ocurre, las paginas modificadas que están en memoria son escritas al archivo de data, de esta forma, si el server tiene algún problema, al levantar nuevamente con la información de los archivos de data mas el tlog es capaz de reconstruir la información que estaba en memoria y no había sido escrita a disco todavía, dejando la base de datos consistentes. Estas transacciones son las que hacen crecer el archivo.

 

Y cuando se “limpia”?

Eso depende (que me encanta esa palabra :P )

Si el recovery model de la base de datos esta en simple, las transacciones que ya finalizaron y fueron escritas a disco, son eliminadas del archivo, dejando ese espacio libre, sin embargo el tamaño físico del archivo no cambia.

Si el recovery model esta en Full o Bulk-logged, estas transacciones son limpiadas cuando se realiza el backup del Tlog.

 

Pero estoy haciendo un backup full todas las noches, porque no se limpia!

Ese es un error que cometen muchos administradores, piensan que el backup full también respalda el Tlog, sin embargo no es así.

El respaldo Full de la base de datos solo respalda la parte activa del Tlog, es decir, aquellas transacciones que aun no han sido escritas a disco.

 

Entonces que debo hacer para que el archivo no crezca?

Cambiar el recovery model a simple ;)

 

Pero tenia entendido que la recomendación para bases de datos de producción es con recovery model full.

Exactamente!! Pero si no los respaldas ni haces nada con ellos, para que los tienes en full??

 

Ok, creo que voy entendiendo, explícame mejor que es lo que debo hacer entonces para no seguir teniendo este problema.

Primero que nada, resolvamos el problema que tienes, disco lleno. Lo mas probable es que tengas problemas con la base por lo mismo, no creo que valga la pena en este momento realizar un respaldo de ese Tlog, así que lo vamos a truncar a la mala con el siguiente T-SQL

BACKUP LOG <basededatos> WITH TRUNCATE_ONLY

Ya tenemos el espacio liberado en el archivo, ahora devolvamos al sistema este espacio libre “achicando” este archivo a través del siguiente T-SQL

DBCC SHRINKFILE (<nombrelogicoarchivodelog>)

Con esto ya tenemos nuestro archivo chiquitito. Sin embargo comenzara a crecer nuevamente cuando empiecen a entrar los usuarios, mira, ya comenzó a crecer :D

Ahora para tener esto controlado y no vuelva a crecer y llenar el disco programemos un respaldo del Tlog por ejemplo cada una hora y guardémoslo junto a los otros respaldos, cuando necesitemos recuperar la base de datos podremos recuperar hasta casi la ultima transacción que se ejecuto, pero eso es para otro post.

 

También tengo un problema similar con Exchange, se me llena el disco con los archivos que se generan.

En Exchange el que los Tlog no se estén eliminando es una señal de que los respaldos no están terminando correctamente, estos son archivos de 5M para Exchange 2003 o anteriores y de 1M para Exchange 2007.

Al realizar el respaldo de la base de datos se aplican las transacciones y los archivos aplicados son eliminados de disco, por lo que no debieran eliminarse estos archivos a mano sin tomar algunas precauciones.

Los Tlog están relacionados al storage group mas que a un mailbox store en particular, por lo que para que se eliminen estos archivos deben estar correctamente respaldados todas las bases dentro del storage group.

La forma correcta de eliminar los Tlog en Exchange esta descrita en el KB 240145 para Exchange 2000 y 2003.

Si queremos evitar que se generen estos archivos, considerando que este hecho no nos permitirá recuperarnos de un desastre hasta la ultima transacción, podemos cambiar la modalidad de log a circular siguiendo el KB 314605 para Exchange 2000 y 2003 y en este Artículo para Exchange 2007

 

Conclusión.

Como conclusión final, la recomendación para servidores de producción de SQL Server es el recovery model full realizando backups periódicos de los Tlogs, para Exchange, deshabilitando Circular Logging y validando que los respaldos terminen correctamente y se estén respaldando todas las bases del Storage Group.

 

Saludos!!

Isa

 

Aclaración: Los diálogos que utilizo en el blog corresponden a conversaciones conmigo misma y no con segundos y/o terceros. A veces son media lenta para entenderme y debo explicarme con manzanitas :S