Con la llegada de 2008 la tan socorrida solución para truncar el log mediante BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY desaparecerá.
¿Cuando se recurría a este comando? Normalmente cuando alguien encontraba una base de datos parada por problemas de espacio en disco provocados por un fichero de log de gran tamaño. La “solución” sin embargo tiene la contrapartida que lo que estamos haciendo es descartar todo el log de transacciones desde el último backup realizado. Las implicaciones pueden ser tan serias como perder todos aquellos cambios realizados desde el último backup. Es por ello que si lanzamos dicho comando el siguiente que deberíamos lanzar sería un comando de backup de la base de datos. Aún así, no es una práctica recomendada pues si algo ocurre durante el proceso de backup perderemos todos los cambios desde el último backup.
Como alternativa a este proceso tenemos la realización de un backup del log de transacciones seguido de una operación de recuperación de espacio. Debemos de tener en cuenta que la reducción del tamaño de los ficheros no se realiza normalmente de forma automática (salvo que activemos la opción AUTO_SHRINK en la base de datos). Por ello utilizaremos DBCC SHRINKDATABASE o DBCC SHRINKFILE para realizar esta recuperación de espacio de forma manual tras el backup del log. Utilizar la opción AUTO_SHRINK en la base de datos no se recomienda en entornos de producción pues puede resultar contraproducente si la operación se lleva a cabo cuando el sistema está bajo carga.
A título personal, siempre he visto esas operaciones de truncado de log bastante “peligrosas” por lo que apoyo esta decisión de eliminarlas 🙂 La alternativa en 2008 para aquellos casos en los que no sea posible realizar un backup será conmutar la base de datos a modo de recuperación sencillo.
El dimensionamiento de los ficheros de datos es importante pero no podemos dejar de lado el de los ficheros de log. Debemos intentar estimar el tamaño necesario para el log y vigilar el crecimiento de éste pues puede significar que tenemos algún problema (por ejemplo una transacción que quedó abierta, falta de backups del log, problemas con las replicaciones/ mirroring, etc.) Un comando útil en este caso es DBCC SQLPERF (LOGSPACE) que nos devuelve el tamaño de los ficheros de log de todas las bases de datos así como el porcentaje de uso de éstos. Tanto tamaños anormalmente altos como bajos nos deberían preocupar. Si el tamaño es muy alto podemos estar a punto de llegar al límite de uso con el grave problema que conlleva. Si es muy bajo es posible que tengamos configurado el log para que crezca de forma dinámica y en algún momento puntual alcanzara un tamaño muy grande por algún problema ya solucionado (comunicaciones, poca frecuencia de backups, etc.)
Finalmente tener en cuenta un punto importante, y muchas veces no considerado: No siempre necesitamos el modelo de recuperación completo. Si no necesitamos el compromiso de poder recuperar el sistema hasta un punto exacto en el tiempo (por ejemplo en una base de datos de pruebas, con muy pocas escrituras) podemos utilizar el modo de recuperación simple y evitar estas situaciones.
