Es posible que en algún caso al realizar una copia completa de alguna base de datos os encontréis con que ésta ocupa más que el propio fichero de datos de la base de datos.
Lo primero que debemos de tener en cuenta es que un backup completo en SQL Server no es una imagen exacta en el tiempo de un instante particular. El backup se realiza a base de copiar extents (1 extent corresponde a 8 páginas físicas contiguas = 64 KB) sin realizar ningún tipo de bloqueo global sobre éstos, únicamente durante la lectura de cada extent individualmente. Es decir, la actividad de nuestra base de datos generada tras iniciar el backup puede ir modificando extents antes de que el thread de copia pase por ellos o después.
¿Cómo se mantiene la coherencia de los datos entonces? SQL Server registra el número de secuencia del log (LSN) al comenzar el backup y al finalizar el backup. Con esta información añadirá toda aquella porción del log relevante para la correcta restauración del backup. Se almacenará desde la transacción más antigua abierta en el instante del primer LSN registrado hasta alcanzar el segundo LSN registrado.
Vamos a mostrar con un ejemplo sencillo cómo esta diferencia de tamaño puede ser de significativa. Lo primero será comprobar que tamaño tienen nuestros ficheros actualmente con algo como “SELECT size,name FROM sysfiles”. A continuación, si realizamos un backup completo sin tener actividad en la base de datos ni transacciones pendientes, obtenemos un fichero de aproximadamente el mismo tamaño que el fichero de datos. Tras lanzar el siguiente script:
SELECT size,name FROM sysfiles where name=‘AdventureWorks_Data’
GO
BACKUP DATABASE AdventureWorks
TO DISK = N‘C:AdventureWorks.bak’
WITH INIT, COPY_ONLY
GO
SELECT size,name FROM sysfiles where name=‘AdventureWorks_Data’
Obtenemos los siguientes resultados:
20616 AdventureWorks_Data
Processed 20616 pages for database ‘AdventureWorks’, file ‘AdventureWorks_Data’ on file 1.
Processed 1 pages for database ‘AdventureWorks’, file ‘AdventureWorks_Log’ on file 1.
BACKUP DATABASE successfully processed 20617 pages in 14.435 seconds (11.699 MB/sec).
20616 AdventureWorks_Data
En nuestro caso tenemos 20616 páginas (161 MB) para el fichero de datos y el backup resultado ocupa 162 MB con lo que todo parece estar dentro de lo esperado. Sin embargo, si simulamos cierta actividad durante el proceso, veremos que el resultado puede ser bastante diferente. En nuestro caso vamos a simular unos updates que le “duelan” un poco y nos generen algo de actividad. Lo que haremos será, previamente a lanzar el proceso de backup, lanzar el siguiente update en otra sesión:
BEGIN TRANSACTION
UPDATE Sales.Individual
SET Demographics = Demographics
WHERE CustomerID%2=0
GO 100
COMMIT TRANSACTION
A continuación en la anterior sesión lanzamos de nuevo el script de backup y el resultado obtenido es el siguiente:
Processed 20616 pages for database ‘AdventureWorks’, file ‘AdventureWorks_Data’ on file 1.
Processed 5378 pages for database ‘AdventureWorks’, file ‘AdventureWorks_Log’ on file 1.
BACKUP DATABASE successfully processed 25994 pages in 20.609 seconds (10.335 MB/sec).
El backup resultado ocupa 204.18 MB lo cual es más de un 25% más que el tamaño del fichero de datos.
En conclusión diremos que cuando realicemos un backup completo y el tamaño del backup supere bastante el tamaño del fichero de datos debemos considerar evaluar la salud de nuestro sistema. Puede que tengamos alguna transacción abierta abandonada o que tengamos el backup planificado en un periodo de alta actividad y convenga que desplacemos la ventana de mantenimiento. Indicar también que todo esto sería aplicable también para los backups diferenciales.
