Tamaño Inicial Fichero de Registro

Por: Pablo Dueñas | Servicios Profesionales Danysoft

Introducción

Cuando creamos una base de datos, podemos tener la tentación de calcular el tamaño del fichero de registro y darle el tamaño de una sola vez.

En una base de datos muy volátil, si además tiene el modo de recuperación completo, el fichero de registro puede llegar a ser mayor que el de datos, especialmente si no se hacen copias de seguridad del registro muy seguidas. En este caso, bien sea por la volatilidad de los datos, por ser una recopilación que se puede reconstruir o por ser para informes, podemos decidir más adelante pasar al modo de recuperación simple. También podemos haber sobredimensionado el fichero de registro.

En todo caso, cuando queremos reducir el fichero, nos encontramos que es imposible más abajo de un tamaño grande. ¿Por qué pasa esto?

Arquitectura resumida del registro de transacciones
El registro de transacciones de SQL Server funciona internamente dividiendo el fichero físico en una cadena de entradas de registro. Cada entrada tiene un número de secuencia de registro (LSN por sus siglas en inglés) que la identifica. En caso de que crezca el fichero físico, las nuevas entradas se escriben incrementando el LSN.

Estas divisiones se llaman archivos de registro virtuales (VLF por sus siglas en inglés). No tienen un tamaño fijo ni un número fijo, depende del número de veces que haya crecido el registro y del tamaño de cada crecimiento.

Según se cree o crezca el fichero de registro, se divide en el siguiente número de VLF el espacio alojado:

• Tamaños hasta 64MB incluido; 4 VLF.
• A partir de 64MB y hasta 1 GB incluido: 8 VLF.
• Tamaños mayores que 1 GB: 16 VLF.

La sección del archivo de registro a partir de la primera entrada de registro, que debe estar presente para una reversión correcta en toda la base de datos, hasta la última entrada de registro escrita, se denomina parte activa del registro o registro activo. No se puede truncar ninguna parte del registro activo.

Dado que hay bastante literatura sobre el funcionamiento del registro de transacciones, no vamos a profundizar más en este punto.

Creación bases de datos
¿Cómo nos afecta esto en la creación de la base de datos? Microsoft nos dice que el «motor de  base de datos intenta mantener un número reducido de archivos virtuales». Además: «se recomienda que los archivos de registro se definan con un valor de size cercano al tamaño final necesario». Por lo tanto, si tenemos una base de datos que prevemos va a necesitar un tamaño de fichero de registro de al menos varios gigas, podemos caer en la tentación de definirlo completo de una vez con margen de sobra. Que es lo que nos puede traer problemas.

Vamos a verlo. Creamos una base de datos con un tamaño de varios gigabytes:

Como el tamaño es mayor que 1 GB, va a crear 16 VLF, cada una de unos 500 MB. Es decir, si ejecutamos la instrucción:

USE [Pruebas];
GO

DBCC loginfo;
GO

El tamaño del fichero virtual lo da en bytes y no todos son iguales porque tenemos que tener en cuenta que debe ajustar el tamaño a múltiplos de página, es decir, a múltiplos de 8 KB.

Reducir fichero de registro
Pero por la volatilidad de los datos, por ser una recopilación que se puede reconstruir o por ser para informes, o por lo que sea, podemos decidir más adelante pasar al modo de recuperación simple. O hacer copia de seguridad del registro con más frecuencia. O redimensionar el fichero de registro para que tenga VLF más pequeños.

En definitiva, tenemos un fichero de registro que ocupa demasiado espacio y queremos hacerlo más pequeño con VLF más pequeños. ¿Es posible?

Si ejecutamos:

DBCC SHRINKFILE(‘Pruebas_log’, 1);
GO

DBCC loginfo;

Vemos que lo máximo que va a reducir el fichero es alrededor de 1 GB y que lo mínimo que va a tener son dos VLF. Es decir, es bastante problemático el ajustar el fichero de registro. Además, va a influir en el tamaño de las copias de seguridad.

Usar un fichero puente
Se nos puede ocurrir que podemos usar un fichero adicional, configurarlo correctamente y dejarlo como único. Veamos si es posible. Para ello vamos a añadir un fichero de registro nuevo con el tamaño que queremos y ver cómo queda el registro:

Como podemos ver, ahora vamos a tener una mezcla de tamaños en los VLF, de unos 500 MB por un lado y unos 62,5 MB por otro. Lo que nos puede explicar ciertas cosas curiosas en la ejecución de SQL Server.

Cambiar al nuevo fichero de registro
Ahora podemos pensar que eliminamos el fichero 2 y nos quedamos con el 4. ¿Qué pasará?

ALTER DATABASE [Pruebas] REMOVE FILE [Pruebas_log];
GO

Efectivamente: no se puede porque es un fichero primario que no se puede quitar por las estructuras que contienen. Nos quedamos para toda la vida con estos dos VLF y no podemos bajar su tamaño de 1 GB, dado lo costoso que sería hacerlo, especialmente comparado con las molestias que genera.

Puede no parecer mucho, pero imaginemos que hemos calculado que vamos a necesitar un fichero de registro de 80 u 800 GB. Por lo que hemos visto, esto nos dice que o bien no debemos tener un registro tan grande y algo estamos haciendo mal, o mejor lo creamos de varias veces para que tenga unos 50 VLF y funcionen correctamente los reinicios de SQL Server y las copias de seguridad.

Conclusión
Cuando se crea una base de datos, es conveniente no solo calcular correctamente el tamaño del fichero de registro, sino planificar la forma en que vamos a llegar a dicho tamaño. En caso que hagamos un cálculo grande, de decenas de gigas para arriba, es conveniente crearlo al principio con un tamaño alrededor de una décima parte y luego alcanzar el tamaño final de varias veces.