SQL Server, ideas y experiencias

FIX para el Error 315 The backup set holds backup of a database other than the existing database

por Jose Mariano Alvarez 25. noviembre 2010

Hace poco migrando de equipo y edición (pero no de versión) una base de datos de SQL Server utilizada por Blackberry que estaba en un SQL Server 2005 SP3 me dio un error al realizar un RESTORE con el siguiente comando en el nuevo servidor:


RESTORE
DATABASE [BESMgmt] FROM DISK = N'O:\MSSQL\Blackberry\BESMgmt20101125.bak' WITH MOVE N'BESMgmt_data' TO N'O:\MSSQL\Blackberry\BESMgmt.mdf', MOVE N'BESMgmt_log' TO N'O:\MSSQL\Blackberry\BESMgmt.ldf', NOUNLOAD, STATS = 10 GO

El error fue el siguiente

Error 3154: The backup set holds a backup of a database other than the existing database.

Lo extraño fue que había hecho el Backup con el siguiente comando con lo cual estaba totalmente seguro que el archivo de Backup contenía la base de datos correcta.

BACKUP DATABASE [BESMgmt] 
TO  DISK = N'C:\Backup\BESMgmt20101125.bak' 
WITH NOFORMAT, NOINIT,  
NAME = N'BESMgmt-Full Database Backup', 
SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

La solución

La solución es simple e ingeniosa. Únicamente debemos “mentirle” para que crea que debe sobrescribir una base de datos existente utilizando WITH REPLACE. Aunque la base de datos no existe la ejecución es exitosa y resuelve el problema, permitiendo realizar el RESTORE.

Ejemplo

RESTORE DATABASE [BESMgmt] 
FROM  DISK = N'O:\MSSQL\Blackberry\BESMgmt20101125.bak' 
WITH REPLACE,  
MOVE N'BESMgmt_data' 
TO N'O:\MSSQL\Blackberry\BESMgmt.mdf',  
MOVE N'BESMgmt_log'      
TO N'O:\MSSQL\Blackberry\BESMgmt.ldf',  
NOUNLOAD,  STATS = 10
GO

Tags: , ,

Artículos

Como reducir y truncar el Log de Transacciones

por Jose Mariano Alvarez 4. abril 2009

Introducción

Uno de los problemas recurrentes y más comunes es el reducir el tamaño del archivo del log de transacciones (transaction log) cuyo crecimiento desmedido en general se produce debido al desconocimiento de la función que cumple y que debe hacerse para que no ocurra.

La función del log de transacciones

En el SQL server el log de transacciones cumple un rol importante y es el de garantizar la integridad de la base de datos. Antes de que las modificaciones realizadas por un usuario en la base de datos sean escritas en alguno de los archivos de datos (archivos MDF y NDF), se realiza la escritura en el log de transacciones (archivos LDF). Las modificaciones son confirmadas al cliente como terminadas (commit de la transacción) cuando la escritura en el log de transacciones se completa aunque las páginas de datos aun permanezcan en memoria y no hayan sido grabadas en los correspondientes archivos de datos. Esto provoca que ante una falla sea necesario recurrir al log de transacciones para recuperar la base de datos porque allí es el único lugar donde se encuentra la información de las modificaciones. Por lo tanto, NO SE DEBE forzar al SQL Server a construir un nuevo archivo de log de transacciones parando el servicio del SQL Server para borrar el log de transacciones desde el sistema operativo.

Solución a problemas

Si el log de transacciones ha crecido es porque SQL Server ha precisado espacio adicional para garantizar que pueda recuperarse ante una falla del disco de datos. Por lo tanto existen varias estrategias básicas una vez que se ha llegado a este punto:

  1. Truncar el log de transacciones, lo que significa hacer un backup de log de las entradas correspondientes a las modificaciones realizadas y así reutilizar el espacio del log de transacciones. El SQl Server usa una estrategia de estructura de datos en añillo para reutilizar el log de transacciones. Luego usar una de las siguientes opciones:
    • Mantener el espacio ocupado por el archivo del log de transacciones.
    • Reducir el archivo del log de transacciones porque ha crecido demasiado.
  2. Dejar seguir creciendo el log de transacciones.
  3. No utilizar el log de transacciones para garantizar la recuperación sino únicamente para la integridad de cada transacción y hacer que lo trunque automáticamente al teminar la misma. El tamaño en este caso no crece a menos que haya alguna transacción que no quepa en el log de transacciones actual. Luego usar una de las siguientes opciones:
    • Mantener el espacio ocupado por el archivo del log de transacciones.
    • Reducir el archivo del log de transacciones porque ha crecido demasiado.

Aquí entran en juego los modelos de recuperación de las bases de datos

  • En el modelo de recuperación Full la modificaciones permanecen en los archivos del log de transacciones hasta que se hace un backup del log de transacciones,  luego del backup el espacio de log de transacciones no activas respaldadas puede reutilizarse.
  • En el modelo de recuperación simple, las modificaciones son marcadas automaticamente como completadas en el log de transacciones y el espacio puede reutilizarse.

Por lo tanto es importante tener bien claro que el Backup de las bases de datos NO TRUNCA el log de transacciones pero el backup del log de transacciones SI LO PUEDE HACER.

Por lo tanto para mantener el tamaño del log de transacciones bajo control y para garantizar la recuperabilidad es recomendable realizar el backup del log de transacciones frecuentemente.

 

Ejemplos y alternativas para truncar el log de transacciones.

Se debe tener en cuenta que estas son acciones correctivas y solo deben ser realizadas por única vez. El backup periódico del log de transacciones es la manera correcta de mantener el log de transaciones bajo control.

Ejemplo 1: Usando el backup del log de transacciones:

BACKUP LOG [AdventureWorks] 

TO DISK = N'C:\Backup\AdventureWorks.bak' 
WITH NOFORMAT, NOINIT, 
NAME = N'AdventureWorks-Transaction Log Backup', 
SKIP, NOREWIND, NOUNLOAD, STATS = 10 

Ejemplo 2: Pasar la base de datos temporariamente de full a simple para forzar el truncado del log de transacciones. Es recomendable realizar esta operacion en single user para evitar que haya posibles transacciones de otros usurios durante el tiempo que la base de datos esta en modo simple y no permanezcan respaldados en el log de transacciones definitivo. Es recomendable realizar un backup de la base de datos para garantizar la recuperabilidad.

USE [master] 
GO 

ALTER DATABASE [AdventureWorks] SET RECOVERY SIMPLE WITH NO_WAIT 
GO 
ALTER DATABASE [AdventureWorks] SET RECOVERY SIMPLE 
GO 

CHECKPOINT 
GO 
CHECKPOINT 
GO 

ALTER DATABASE [AdventureWorks] SET RECOVERY FULL WITH NO_WAIT 
GO 
ALTER DATABASE [AdventureWorks] SET RECOVERY FULL 
GO

 

La recomendación general es:

  • Utilizar una estrategia de backup que realice BACKUP FULL de la base de datos con Backup del log de transacciones periódicamente.
  • No borrar el log de transacciones manualmente salvo una causa de fuerza mayor

 

Como reducir el tamaño del archivo del log de transacciones

Hasta ahora solo logramos truncar el log de transacciones pero no reducir el tamaño del archivo. Al ejecutar DBCC SHRINKFILE le indicamos al SQL Server que queremos reducir el tamaño físico del archivo, en nuestro caso podemos hacerlo sobre los archivos fisicos que componen el del log de transacciones.

Importante: Solo se podrá truncar la parte inactiva del log de transacciones.

 

Más información en el sitio de microsoft

Truncación del registro de transacciones

Reducir el registro de transacciones

Cómo detener el crecimiento inesperado del registro de transacciones de una base de datos de SQL Server

Tags: , , ,

Artículos

Powered by SQL Total Consulting


View Jose Mariano Alvarez's profile on LinkedIn

 Add to Technorati Favorites 

Calendar

<<  octubre 2017  >>
lumamijuvido
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

View posts in large calendar

Locations of visitors to this page

Widget Twitter not found.

Root element is missing.X


Valid XHTML 1.0 Transitional

Valid CSS!